Estou estudando Scala, e a primeira coisa que procurei para começar o estudo foi uma IDE para começar a dar meus primeiros passos. O problema é que não existe ainda nenhuma IDE que seja boa o suficiente para Scala. Primeiro tentei o Eclipse, mas o plugin está incrivelmente instável, não deveria ser nem disponibilizado para download. O Netbeans não está muito a frente e o IDEA é o melhorzinho, porém com muitos bugs também. Resultado, fiquei com o IDEA e comecei a trabalhar. Por conta dos problemas e dificuldades em pouco tempo eu travei. Perdi a paciência por usar uma ferramenta com tantos problemas e parei os meus estudos práticos.

E agora? Vou ter que esperar meses (ou anos) para que alguém desenvolva uma IDE boa o suficiente? E quando não existia ferramentas com esse nível de recursos? Como a gente se virava?

Quando eu comecei a trabalhar, usava Turbo C 2.0. Alguém se lembra? Não tinha syntax highlight, abria apenas um arquivo por vez e code assist nem pensar. Tinha copy and paste e lamba os beiços. E que saber? Era uma ferramenta muito boa. Era boa e produtiva pela simples razão que EU SABIA O QUE ESTAVA FAZENDO.

As ferramentas de hoje em dia são tão sofisticadas, tem tantos recursos e facilidades, que criaram uma geração de programadores que são absolutamente dependentes delas. Programadores que não são capazes de saber que método de uma determinada classe ele precisa chamar. Se não tiver um code assist eles simplesmente não sabem o que fazer (muitos não sabem nem com o uso do code assist).

Precisamos abandonar um pouco nossas IDEs. Precisamos (re)aprender as linguagens e frameworks sem o uso dessas facilidades. Só quando finalmente estivermos seguros sobre o nosso conhecimento é que estamos autorizados a usar as IDEs. Bye bye IDEA, seja bem vindo o Notepad. Agora finalmente vou APRENDER Scala. Depois de um momento de negação estou finalmente me curando da IDE-dependência. Samuel, você estava CERTO!

O tempo passou e nos últimos anos alguns sinais começaram a aparecer. Erlang (linguagem funcional proprietária criada pela Ericsson) que foi banida e distribuida de forma open-source em 98, volta a ser utilizada pela Ericsson (e por muitos outros) em 2004. A Microsoft lança o F# (linguagem funcional para a plataforma .NET). O pessoal do Twitter reescreve seu back-end em Scala (linguagem funcional e OO para a plataforma Java). C# incorpora conceitos funcionais na sua linguagem para dar suporte ao LINQ. A Google publica artigos mostrando como utiliza o paradigma funcional para armazenar e recuperar dados. Porque esse interesse no paradigma funcional foi renovado? Qual o pulo do gato?

Devido a proximidade de limites técnicos e preocupação com consumo de energia, o pessoal de hardware está focando no desenvolvimento de novos processadores em soluções de múltiplos cores. Em breve teremos processadores com centenas de cores. Para se beneficiar deste panorama, temos que escrever softwares que executem de forma paralela. A boa notícia é que é muito mais fácil escrever código concorrente em liguagens funcionais do que em linguagens imperativas.

Não existe um único paradigma que seja indicado para resolver todos os tipos de problemas. Precisamos aprender (ou reaprender) o paradigma funcional, que foi abandonado por muito tempo. Precisamos de linguagens que incluam de forma coerente vários paradigmas, para que a gente possa escolher a melhor forma de resolver um determinado problema. Por fim, precisamos aprender Scala, que me parece a mais promissora nas novas linguagens multi-paradigma.

Banco de dados relacionais fazem parte da nossa vida há muito tempo. SQL e abstrações (HQL por exemplo) fazem parte da rotina de qualquer desenvolvedor de sistemas de informação. Agora, será que o domínio dessa tecnologia vai continuar prevalecendo na era da Internet?

Gigantes da Internet como Google, Amazon, Facebook, entre outros, descobriram há um bom tempo que os bancos de dados relacionais não atendem suas necessidades, especialmente as relacionadas com escalabilidade. Essas empresas investiram em outro tipo de tecnologia para armazenamento e recuperação de dados. Hoje essas soluções são conhecida coletivamente como NoSQL.

Agora vem a grande questão, para onde eu vou: SQL ou NoSQL?

Cada opção tem sua aplicabilidade, não seja dogmático (muitos nas duas comunidades são) e aproveite o que cada tecnologia tem de melhor. A única coisa que quero alertar é que a opção por NoSQL é uma realidade viável. Claro que as soluções NoSQL ainda tem que comer muita farinha para chegar a maturidade, mas podemos enxergar nisso uma oportunidade de pioneirismo. Como desenvolvedores de software temos que estar preparados, então arregace as mangas e vá ESTUDAR!

Vou começar pela instalação. Para instalar o WordPress, só é necessário verificar o "Famous 5-Minute Install". Pronto. Funciona de verdade. Na verdade não é você que instala o WordPress, ele se instala sozinho, você apenas manda ele se instalar. Não dá pra engolir softwares que só para instalar é preciso ler um livro cheio de procedimentos e depois acaba dando tudo errado e você ainda tem que ficar pesquisando na internet para ver ser descobre o que aconteceu.

Um dos procedimentos que ele faz na instalação é criar a estrutura do banco de dados. Hoje em dia não é difícil encontrar um framework que facilite isso (vide Hibernate), por então não fazemos isso sempre?

Outro exemplo que vi de como o WordPress é robusto foi quando eu resolvi mudar a configuração dos permalinks. Após alterar a configuração veja o que apareceu na tela:

Devido a minha escolha o wordpress precisava criar um arquivo .htaccess para atender minha necessidade, como ele sozinho descobriu que não tinha permissão de escrita no diretório, mostrou na tela as instruções detalhadas do procedimento que eu precisava fazer na mão para que os permalinks pudessem funcionar. Quantas vezes você já se deparou com algum erro desconhecido e teve que fuçar logs para descobrir qual o problema?

É verdade, Software Robusto demanda mais esforço mas devemos abrir mão da preguiça. Não podemos é abrir mão da qualidade dos softwares que escrevemos. Software frágeis acabam por consumir a falsa economia no desenvolvimento porque geram um imenso custo de suporte e manutenção. Siga o exemplo do Worpress.

Fiz a minha parte:

sessao.Delete("FROM Ocorrencia WHERE ...");

Não é que o maldito NHibernate ao invés de simplesmente criar a query de remoção, executa uma query de consulta, monta todos as entidades (no caso, Ocorrencia) e depois dá delete de um por um?

Por que diabos alguém em seu juízo perfeito escreveria um método tão estúpido quanto esse? Se eu já quero apagar esses objetos porque carrega-los na memória, consumindo o meu já escasso tempo de processamento?

Fica a lição: NÃO PROGRAME POR COINCIDÊNCIA. Não é apenas porque um método tem a assinatura perfeita que ele vai ser a solução do seu problema. LEIA A DOCUMENTAÇÃO. Certifique-se que está fazendo a coisa certa, ou caso contrário você vai se dar muito mal.

Aqui o caso em questão é o wicket. Um de nossos clientes resolveu adotar esse framework em sua arquitetura. Eles mesmo escreveram parte da aplicação utilizando o wicket e nós continuamos o desenvolvimento. A base que eles desenvolveram não era suficiente para atender todas as necessidades do projeto (nunca é), então tivemos que nos aprofundar na solução. Muitos envolvidos cairam na armadilha. Aprendem um pouco e começam a chutar e adivinhar como o negócio funciona através de tentativa e erro. NÃO FAÇA ISSO!

Agora eu mesmo estou aprendendo a trabalhar com wicket. Peguei um livro (Wicket in Action) e estou estudando TUDO. Em geral esse tipo de livro começa com um overview, passando para uma explicação sobre a arquitetura, depois vem o tutorial e depois vem seções que mostram de forma mais detalhadas suas funcionalidades. Normalmente durante o tutorial você já é capaz de implementar coisas mais simples, mas não pare por aí. ESTUDE O LIVRO TODO! Monte uma base SÓLIDA de conhecimentos. Depois de ter essa base, tudo fica mais fácil.

O Cenário:

O sistema utiliza EJB 2 e Hibernate 2. O cliente exige implementação de testes dos métodos da fachada utilizando JUnit e DbUnit.

Problemas:

A montagem dos cenários é complexa. O DbUnit entende apenas o modelo relacional, isto significa que o engenheiro tem que fazer um "desmapeamento hibernate" na cabeça dele para montar as tabelas e colunas com os valores necessários. Veja um exemplo:

Claro que esse é um modelo relacional simples, agora imagine modelos de classes complexos, com heranças, relacionamentos, etc. Neste caso, dá bastante trabalho.

Além da dificuldade em produzir a massa de dados, existe um problema muito grave. Dentro das classes de teste é necessário fazer validações contra os valores do arquivo xml (por exemplo em métodos de consulta). Neste caso podemos fazer as validações com valores hard coded, como neste exemplo:

assertEquals(employee.getFirstName(), "Jose");

Que é uma péssima idéia, pois viola o princípio DRY (Don't Repeat Yourself). Outra saída é obter os valores do xml através da API do DbUnit, que vai dar uma trabalheira danada, ainda mais se você quiser montar o objeto para fazer comparações deste tipo:

assertEquals(employeeActual, employeeExpected);

Já imaginou? Vai ter que construir outro hibernate só para pegar cada valor das tabelas e colunas do arquivo XML e remontar os objetos novamente.

Como Resolver?

O grande problema dessa abordagem é o fato do DbUnit entender apenas de tabelas e colunas. E se existisse um HibernateUnit? No hipotético HibernateUnit eu poderia especificar meus dados na forma de objetos. Além disso, poderia utilizar um formato mais legível e que pudesse ser transformado diretamente para objetos dentro do seu código. Esse formato pode ser o YAML. Veja como ficaria:

Inclui um relacionamento para employee só para ficar um pouco mais rico. A vantagem dessa abordagem é que além de ficar mais legível, existem frameworks que serializam e deserializam esse formato para objetos. Com esse recurso, seria possível obter os objetos diretamente do arquivo e em seguida fazer comparações com objetos obtidos no banco. Legal, hein?

Acho que uma solução deste tipo poderia trazer muitos benefícios para o nosso problema. Estou fazendo uma pesquisa e se não existir nada semelhante, devo implementar essa solução como um projeto open source.

Pena que nosso cliente EXIGE que usemos o DbUnit.