Pesquisa para um novo projeto – Parte II

Bom, continuando as pesquisas para o novo projeto, continuo falando com diversas pessoas e pesquisando. A decisão sobre que tipo de banco de dados suportar já está tomada, a primeira versão irá dar suporte para Firebird, Microsoft SQL Server e ORACLE, em uma futura versão vamos dar suporte para IBM DB2.

Porquê não inserir suporte ao IBM DB2 já nesta versão? Afinal, como diz o velho ditado (ou o velho deitado): já que estamos no inferno, não custa nada dançar uma valsa com o capeta né?
Bem, a principal questão é que já temos versões instaladas do Firebird, ORACLE a versão express e o MSDE, e já temos um domínio desses bancos de dados, o IBM DB2 eu sei que é muito bom e rápido, mas sinceramente não faço nem idéia de como criar ou manter uma tabela. Então vamos fazer a primeira versão sem tentar complicar muito a história, depois da primeira versão pronta, teremos tempo para aprender a mexer no DB2.

Existe também a questão comercial, em termos de marketing, o suporte ao ORACLE e ao SQL Server são significativos, representam uma importante característica para o mercado.

Agora a decisão sobre a camada de servidor que irá fazer a ponte entre o banco de dados e a interface com o usuário, a camada que irá conter as regras de negócio, é o próximo passo.

As opções representativas para mim ainda são Java, .Net ou Delphi, este último com preferência para uso do RemObjects.

Alguns me falaram do Lazarus, o Free Pascal com versão para Linux e Windows, mas com sinceridade não é uma opção que eu considere seriamente. Pense bem, pretendemos uma aplicação que possa ser vendida em nível mundial, que possa se integrar com aplicativos de ERP conhecidos no mercado, para empresas de todos os portes, com suporte multilingua, que possa ser customizado pela equipe de TI do cliente, ou por parceiros, apelo de marketing, que tenha evolução garantida.
O que o uso do Lazarus poderia agregar de valor ao projeto? Sem desprezar a ferramenta que, diga-se de passagem, é muito boa. Mas no caso de optar por linguagem Pascal, ou Object Pascal, a escolha seria naturalmente o Delphi, em comparação com o Lazarus, só perde no preço e na disponibilidade para Linux, mas ganha com uma vantagem imensa em termos de suporte, disponibilidade de componentes, tecnologias, evolução, maturidade, estabilidade, disponibilidade de serviços e profissionais que dominam a ferramenta.
O Lazarus é uma excelente ferramenta, mas ainda está no inicio de seu ciclo de vida, dentro de 1 ou 2 anos será uma ferramenta que deverá ser seriamente considerada, mas ainda não chegou lá.

Analisando as opções da camada servidor:

.NET

A tecnologia da Microsoft é madura, bem posicionada no mercado, mas não me encanta por algumas razões.
- Foi desenvolvida como uma indecisão da Microsoft, que queria barrar o avanço do Java na sua briga com a Sun, é uma tentativa de fazer com que o Windows se torne o padrão de sistema operacional de servidor para aplicativos Web.
- É pesado, e bota pesado nisso, o framework é imenso, existe uma divisão debulosa entre os objetos, componentes, rotinas, etc. As ferramentas que suportam desenvolvimento para .NET são uma carroça de tão pesadas e lentas, é um paquiderme com câimbras, algo que definitivamente que deixa muito desconfortável.
- Até quando a Microsoft vai continuar no .NET? Ela já mudou tanto de proposta de tecnologia que é de se perguntar: Qual será a próxima onda? Não há uma consistência, um caminho claro e seguro do que a Microsoft pretende fazer para o futuro.
Tradicionalmente a turma do tio Bill garante que a tecnologia é a definitiva, até eles pensarem a próxima sacada de marketing, quanto então mudam tudo e a nova tecnologia passa a ser o novo Santo Graal do desenvolvimento.
Tenho visto a Microsoft usar tão pouco a sua própria tecnologia, que me pergunto se seria prudente apostar em .NET.
- Só roda em Windows e pronto. Isso é um ponto negativo bem forte a se considerar, com o uso crescente de Unix e Linux nos servidores, desprezar estes SO não é uma prática muito recomendável.

Quanto ao Linux, uma observação interessante:
Quando começou a onda do Linux, eu já comentava que era algo a se considerar apenas no futuro, quem estava migrando para Linux não tinha representatividade no mercado. Eram instituições de ensino ou pesquisa, ou então pequenas e micro empresas em busca de economizar uns trocados em licenciamento de servidor. Ou seja, um mercado para o qual não valia a pena fazer investimentos, cujo retorno era insignificante. Só valeria investir nesse mercado se você tivesse grana suficiente para suportar alguns anos de desenvolvimento com nenhum ou muito pouco retorno financeiro, até que o mercado ficasse maduro suficiente para compensar o que se investiu.
Eu trabalhei muitos anos com servidores Unix, e para mim a grande vantagem do Linux sempre foi o mesmo que eu sempre considerei no Unix: estabilidade, escalabilidade, confiabilidade, mas o que o mercado via era somente o custo de licenciamento.
Bem, felizmente parece que as coisas mudaram, tenho visto muitas empresas, inclusive de grande porte, migrarem soluções de servidor para Linux, não por preço, mas pelas razões que mencionei para o Unix, até por que no final das contas o Linux pode sair até mais caro do que o Windows, o que geralmente ocorre, pois você começa a explorar e a usar muito mais recursos que estarão disponíveis no servidor, começa a visualizar opções muito mais sofisticadas e interessantes, e vai investir muito mais dinheiro no final, claro que também vai ter muito mais retorno, vai receber mais pelo seu dinheiro.

Delphi

Seria a opção natural, pois é a nossa ferramenta nativa de desenvolvimento para soluções desenvolvidas pela Spectrus. Como trabalhamos também como fábrica de software, outras soluções como .NET, C/C++ também são confortáveis para nós, pois muitas vezes o projeto para o cliente exige que se desenvolva em uma tecnologia que a equipe de TI domine.
O Delphi seria uma opção fácil de implementar, é uma ferramenta poderosa, com tecnologias maduras e consistentes, em constante evolução, com uma comunidade de desenvolvedores imensa (um grande número de malucos, o que é bom!), a oferta de componentes, códigos, e suporte é imensa, talvez a ferramenta com maior suporte na atualidade. Sem falar que é uma linguagem orientada a objetos de fato, fácil de implementar e usar.
As desvantagens:
Roda apenas em Windows;
O licenciamento é caro, se você for colocar uma equipe com 5 ou 6 desenvolvedores vai precisar de uma licença para cada um, considerando que para este projeto será necessário a versão Enterprise ou Architect, o investimento vai ser bem caro, antes do produto dar resultado.
A última versão rápida e confiável é a 7, o Delphi 8 foi um fiasco, a 2005 uma tragédia, a 2006 parece que melhorou, mas só se comparada com o Delphi 8 ou 2005, e a Borland ainda tem a cara de pau de apresentar algumas vantagens do Delphi 2006, omitindo que isso já tinha na versão 7 e desapareceu nas posteriores. A 2006 ainda está muito longe de ser a ferramenta fantástica que o Delphi 7 é, parece que a Borland está sofrendo da síndrome de espelhamento com a Microsoft, acham que basta ir acrescentando penduricalhos na ferramenta para dizer que é evolução, e deixam prá lá questões como performance e estabilidade.
A última versão que valeu a pena a grana do licenciamento foi a Delphi 7, grande parte do que foi acrescentado pela Borland de lá para cá, e que ela cobra uma boa grana por isso, pode ser conseguido com AddOns e componentes para o Delphi 7.

Java

Eis aqui uma opção bem interessante apesar, como já escrevi em outro post, do peso absurdo das ferramentas da Sun. Mas o JDK (o Java Develpment Kit) da Sun é bem razoável em termos de desempenho.
Estou experimentando diversas ferramentas de desenvolvimento: Sun JavaStudio Creator, Sun JavaStudio Enterprise, NetBeans, Eclipse e Oracle JDeveloper, e até um modesto TextPad.
Gostei no nível de facilidades e ferramentas disponíveis no Sun JavaStudio Creator, podemos dizer que é praticamente uma ferramenta RAD para desenvolvimento em Java, porém o peso da ferramenta é absurdo, simplesmente derruba a máquina, tornando inviável o seu uso.
O Sun JavaStudio Enterprise é outra ferramenta fantátisca, que também sofre dos mesmos males do JavaStudio Creator, um peso absurdo.
Mas ambas as ferramentas da Sun têm a vantagem de ter uma gama de recursos fantástica.
As 3 IDES mais interessantes, sem um peso absurdo, que eu experimentei: NetBeans, Eclipse e Oracle JDeveloper.
Se você for desenvolver em Java aplicativos stand alone, considere seriamente o uso do NetBeans, tem uma IDE excelente, recursos muito bons, e o GUI Builder dele não fica devendo nada à outras ferramentas RAD.
O ORACLE JDeveloper vai bem no desenvolvimento tanto no lado servidor quanto no cliente, é uma ferramenta também excelente para o desenvolvimento, considere seriamente, pois tem performance bem melhor do que as ferramentas da Sun.

Já faz alguns anos que você pode contar com artigos sobre Java em qualquer revista de programação, tem sido uma das soluções mais badaladas nos últimos tempos. E com justiça, se bem que eu não desenvolveria em Java uma aplicação Desktop (por enquanto), para isto usaria Delphi sem sombra de dúvidas.
A linguagem é fortemente tipada, e totalmente orientada a objetos, mais até do C++.
Tem uma comunidade de desenvolvedores tão grande e ativa quanto o pessoal de Delphi, roda em uma infinidade de arquiteturas de hardware/software, sem o ônus de alterações no código fonte para suportar outro sistema operacional ou arquitetura de hardware.
Os custos de licenciamento são zero.

As desvantagens é que é lenta para a carga inicial, pois o que é gerado é um pseudo código, e um código nativo compilado e linkado, como o Delphi, irá rodar com uma performance bem superior.
O treinamento para os desenvolvedores é um pouco mais dispendioso e trabalhoso, não é fácil fazer alguns desenvolvedores que vêm do VB, ou que aprenderam Delphi nos cursinhos meia boca da vida (que só ensinam a usar a linguagem em meio procedural, muito pouco OOP), a aprenderem a tecnologia.
A curva de aprendizagem para os novatos é bem mais áspera e íngreme, e não há atalhos.
O JRE (Java Runtime Environment) é um kit de tamanho considerável para ser instalado nas máquinas destino, se bem que isto não é desvantagem num produto como este, pois vai como parte da instalação padrão do aplicativo.


O Junior, lá de RO tem me falado muito de Ruby, e ele já me mandou algumas dicas muito boas sobre outras tecnologias, passei a usar o DBISAM para os produtos de prateleira por causa do (excelente) trabalho que ele faz de divulgação da tecnologia. Por causa da recomendação estou analisando o Ruby, principalmente com a IDE Ruby On Rails, que parece ser bem interessante. Vamos ver o que essa tecnologia promete.

Vou parando por aqui por hoje, o Brasil perdeu prá França, coisa já esperada com essa turma do Parreira, a turma do Quadrado Trágico, turma mesmo por que time nunca teve, é uma turma de grandes estrelas, mas eu preferia um time, que soubesse jogar junto, que tivesse pegada, honra, brios... O Dunga faz falta, pelo menos ele chamava os companheiros na cincha, e cobrava responsabilidade, esta turma de bundões não tem brios, não tem nem sequer garra. Agora é torcer pelo Felipão, ou Big Phil como dizem os ingleses.

Dúvidas e decisões sobre um novo projeto – Mais dúvidas do que decisões.

Como sempre, a única coisa permanente é mudança, certeza a gente só tem de que vai mudar, nem que seja para o arquivo geral da cidade, vulgarmente conhecido como cemitério. Bem, neste caso as coisas não são tão dramáticas assim, mas empresa nenhuma fica parada no mesmo lugar, ou cresce ou diminui, ou vai para a frente ou vai para trás, e a minha não foge à regra, já cresci, já diminui, já levei calote, já ganhei grana, já dei com a cara no muro, com o muro na cara, e tudo o mais.
Como as coisas estão evoluindo e melhorando, é hora de pensar no futuro, para onde crescer, para onde ir, em que fatia do mercado apostar? Enfim, uma penca de decisões cruciais, além das normais do dia a dia, como faturar a grana para pagar os funcionários, pagar o contador, o telefone, aluguel, internet, a Borland (que tá cobrando uma grana preta pelo Delphi, bem que eles podiam aliviar a mão um pouquinho né?), e principalmente o raio dos impostos (eita vida danada, o Lula pode não saber governar nem contar até dez, mas cobrar impostos sabe como ninguém, o que aumentou a carga tributária não é mole não, é no mínimo 1 funcionário a mais para cada 1 funcionário efetivo).
Então, deixando a choradeira de lado, e o lero-lero para depois, a decisão é:

- Que mercado atender? Qual seria o rentável?
- Que produto esse mercado quer?

E o que mais interessa para o pessoal de tecnologia que eventualmente ler este blog (que anda meio atirado às moscas, sem leitores nem postagem nos últimos tempos):

- Que premissas atender ?
- Que tecnologia usar?
- Quais os pré-requisitos?

Bem, vamos lá, tentando resolver as broncas uma de cada vez, e levando em consideração uma penca de opiniões do pessoal do news do delphi (news.netuno.com.br, grupo u-br.comp.ling.delphi), que é uma galera prá lá de non-sense, onde se discute de tudo um pouco, e onde nem o pessoal da Borland agüentou o tranco, que o diga o Lanusse, o pessoal lá é fera e doido, de tudo um pouco, por isso eu faço parte desde tempos imemoriais, no tempo em que ainda estávamos no news do uol, antes de nos banirem daquelas bandas, e como desenvolvedor bom tem que ter doses de doideira e habilidade em iguais proporções, por esses critérios o pessoal lá deve ser a melhor turma de desenvolvedor do Brasil.

- Como esse produto será posicionado no mercado?
Em principio, a idéia é de que o produto seja internacional (estamos chique agora!), com suporte fácil a diversas linguagens, que essas linguagens possam ser inseridas apenas com um arquivo de recursos.
Deve suportar diversos temas, para que se possa configurar o sistema com a identidade do cliente, cores e logotipia, de forma fácil e rápida.
As rotinas de moeda e configurações locais para cada país devem ser implementadas via recursos também, possivelmente um pacote de localização que contenha também a linguagem.
Não adianta malhar em ferro frio, como diria meu avô, quando você chega em um cliente de médio porte para cima, a marca da tecnologia começa a pesar, e nos pequenos clientes o que pesa é o custo, como compatibilizar isso?
Para esta última questão, começamos pelo banco de dados, o aplicativo vai ter que suportar tecnologia open source e comercial, então vamos de suporte para Firebird ( prefiro muito mais do que MySQL, nunca fui com as fuças de um banco de dados à lá Paradox, com cada tabela separada em um arquivo, e além do mais Firebird é bem mais rápido e poderoso, além do licenciamento ser totalmente royalty free), ORACLE e Microsoft SQL Server, dois nomões do mundo de banco de dados com um market share considerável, e futuramente um suporte também para IBM DB2, este nunca pode ser desconsiderado, pois é o rei nas grandes instalações, e as últimas versões estão com uma performance assombrosa.
Claro que isso vai dar um trabalho considerável para manter em sincronia todas as características rodando 100% em todos os bancos de dados, mas não se ganha dinheiro sem passar algum trabalho duro, salvo se você resolver traficar pasta base de cocaína, mas como isso é algo que o meu médico não recomenda para a preservação da minha saúde física, eu resolvi deixar essa solução prá lá, parece que só restou o trabalho duro, até por que eu queimei as outras chances de ficar rico: Não nasci rico, e casei com uma mulher tão dura quanto eu, e sou um verdadeiro fiasco jogando na mega sena.

Rodar em servidor IIS ou Apache, que são os significativos no mercado, o restante nem vale a pena o esforço, para uma empresa pequena, tenho que concentrar os esforços aonde possa render, não vale a pena tentar defender tese, no fundo o nosso negócio é ganhar dinheiro solucionando as encrencas dos outros, e não conseguir mais encrenca né?
Regras de negócio em camada de web services, para que o cliente possa consumir em aplicativos internos, ou que possa ser integrado e se integrar com outras soluções do mercado, logicamente estamos mirando integração com SAP, PeopleSoft, JDEdwards, Microsiga, DataSul, ORACLE ERP, etc, afinal é onde está a grana.
Interface de cliente magro (thin client, para usar um jargão de marketing corrente no mercado), apenas um browser, user name e senha, e o usuário já está usando o aplicativo, até de um quiosque em uma lan-house, instalação zero, configuração mínima, funcionamento com o mínimo de problemas, e a grana do suporte paga a evolução do dito cujo.

Receita legal né? Acho que dá prá crescer e fazer algum dindin, pelo menos até um Google da vida querer comprar a gente (estou aceitando ofertas generosas, que incluam 1 iate, apartamento em Paris, e o telefone da Juliana Paes, e claro um dos meus carros de sonho: uma Bugatti Veyron, um Aston Martin Vanquish Zagato, um Koenigsegg, uma Lamborghini Murciélago, uma Masserati MC12 Stradale ou Saleen S7, ou até um Jaguar, além de um punhado de dólares).

E o que usar?
Bem, na parte de banco de dados já defini o que quero, e na camada de web services?
As opções eram várias, agora estão reduzidas à 3: Delphi, .NET ou Java, pendendo fortemente para a última, em que pese o peso absurdo do JavaStudio Enterprise da Sun.

Bem, já foi um avanço até aqui, o resto no próximo post, que não vai demorar como os outros, agora eu prometi para o Tiago Hiller que vou escrever mais seguido, e o alemão vai pegar no meu pé se eu não postar, agora ele tá de papai, com mania de responsável, e como é um grande amigo, a gente deixa ele mandar um pouco, afinal em casa quem manda é a mulher mesmo, como na minha, onde eu dou a última palavra e aos berros: “SIM SENHORA! JÁ ESTOU INDO MEU AMOR!”.