De lá para cá muita coisa mudou, embora algunas daqueles livros continuem válidos. Resolvi então colocar aqui uma lista dos livros que um desevolvedor Java EE da atualidade deve ler para conseguir dominar esse ambiente, pelo menos são os livros básicos

1. Utilizando UML e Padrões do Craig – livro obrigatório porque discute o que é desenvolver sistemas, fala de padrões de projeto e de como fazer a análise
2. Java Persistence com Hibernate – detalha como funciona a API de persistência do Java, mas utiliza muitos detalhes relacionados ao Hibernate. O livro é muito bom porque discute em detalhes todos os problemas relacionados ao uso de bancos de dados relacionais com linguagens de programação orientadas a objetos.
3. Core Java Server Faces -  apresenta o framework da Sun para o desenvolvimento de aplicações web, desde que comecei a usar o JSF não quero mais saber de Struts não vou falar mal do Struts porque usei muito no passado, mas o JSF realmente é um modelo mais robusto e interessante. Este livro cobre todos os detalhes de como usar e como escrever uma aplicação completa.
4. EJB3 em Ação – Nenhuma aplicação Java EE está completa sem o uso de EJB, que é o modelo de componentes proposto pela Sun para a linguagem Java. Neste livro aprendemos como usar a especificação mais recente e como o uso de anotações facilita a vida do desenvolvedor que fica livre de muitos arquivos XML.
   
5. EJB3 Profissional: Java Persistence API – Um complemento ao livro de Hibernate, neste livro o leitor vai achar material relacionado apenas a especificação o que é muito bom porque, como costumo trabalhar, pode-se ficar totalmente independente da implementação de persitência.
6. Desenvolvendo Relatórios Profissionais Com iReport Para Netbeans IDE – Como toda aplicação precisa de relatórios para estar completa, nada como usar uma ferramenta poderosa e baseada em ambiente gráfico para escrever os seus. Neste livro, aprendemos a usar o plugin para Netbeans de forma gradual e bem detalhada.

Usei então aquela API (hoje eu recomendo fortemente que você use iReport) para fazer os relatórios e boletos de pagamento, tudo impresso manualmente. É claro que quando rodou foi uma grande conquista, foi uma experiência bem legal. Mas vários anos se passaram e o Java evoluiu, até que recentemente colocamos o sistema para rodar sobre uma máquina virtual atual Java 6, tudo funcionou bem, e na hora não nos ocorreu de testar a impressão, já que toda a parte de telas e banco de dados estava funcionando.

Qual não foi nossa surpresa quando foi necessário imprimir boletos? Tudo fora de alinhamento, tudo fora de margem, mexemos, olhamos e nada. Troca a impressora, troca a máquina e nada. Só faltava trocar a máquina virtual, e não deu em outra, imprimiu corretamente.

É por isso que eu sempre falo que precisamos ter muito cuidado quando atualizamos as partes de um sistema, porque não sabemos o que outras pessoas podem ter mudado em suas próprias bibliotecas. É fundamental, antes de migrar, fazer um teste extenso de compatibilidade para garantir que tudo vai funcionar direitinho.

Mas é exatamente disso que os testes de usabilidade tratam, e no final das contas, temos mais é que testar isso tudo mesmo! Eu acho que quanto mais fácil se tornou desenvolver os sistemas, mais preguiçosos ficamos. Explico. Fácil de desenvolver porque hoje temos ferramentas de geração de código (que não existiam até bem pouco tempo) baseadas em padrões de projeto (que não estavam documentados até bem pouco tempo) que nos permitem simplesmente esquecer que certas partes precisam ser feitas. Muitas vezes tudo que precisamos fazer é introduzir pequenos detalhes específicos no código gerado, mas na maioria dos casos nem isso! Ficamos preguiçosos porque os sistemas cresceram, são agora corporativos, é muito menor a demanda de pequenas empresas por seus próprios softwares, com isso o analista que sai da faculdade demora a ter, se é que vai ter, contato direto com o cliente. Os analistas passam a ter um ponto focal centralizado a quem se reportam e acho que isso mascara a responsabilidade levando a uma negligência involuntária.

Antes que eu receba vários ataques de analistas raivosos, não estou aqui falando que todo analista de sistemas (e neste caso estou considerando a dualidade analista/programador) sejam negligentes. Embora eu já tenha trabalhado com muitos que eram realmente negligentes, estou falando aqui de uma negligência involuntária, é mais uma coisa de não fazer porque a percepção é de que o software é para uso próprio e poderemos conversar com o usuário e explicar.

Mesmo que o software seja para uso da própria empresa deve ser desenvolvido com todo o cuidado. Você pode ler mais sobre as minhas impressões sobre análise em:

• Como se faz análise
• Antes de resolver, defina o problema
• Artesanato de Software

Mas agora de volta aos testes de usabilidade. Um problema que temos com os sistemas corporativos é que são muito difíceis de testar pelo alto grau de dependência entre as partes, dessa forma, os testes unitários são quase testes de integração. Uma alternativa é fazer os testes unitários das camadas mais básicas de forma a garantir que estas estão funcionando de forma que os testes das camadas superiores possam se basear nessas camadas, mas se fizermos isso quebramos a possibilidade de paralelizar nossa equipe já que não haverão módulos básicos suficientes para todos. O que acaba ocorrendo é que as pessoas codificam antes de criar seus testes (acredite o Test Driven Development funciona!) e acabam por nunca mais fazer os testes.

Além disso os sistemas corporativos têm uma tendência forte a serem baseados em arquitetura Web ou SOA precisando estar instalados em um servidor de aplicação para executar, o problema disso é que a fórmula:

(a implantação do sistema em um servidor + iniciar o servidor de aplicação) * (obter referências aos componentes a serem testados + executar os testes)

Não é facilmente incluída nos scripts de testes unitários. O que estou pensando em adotar é um esquema de testes semiautomatizado, ou seja, a parte de iniciar o servidor e implantar a aplicação é feita manualmente, a parte de obter referências e executar testes é feita com JUnit.  Até existe um framework JSFUnit, mas infelizmente ele tem uns problemas com o ICEfaces, eu até achei o ponto onde é o problema (depois de baixar o código fonte do JSFUnit e do ICEFaces dos repositórios e gastar umas 4 horas nisso direto), mas precisa de uma modificação no código que ainda não tive tempo de implementar e testar. Embora esta seja uma parte importante, ainda assim não testaria todo o sistema, porque não resolveria a parte dos EJBs e depois de testar com EJBUnit (e mais alguns vários) chegamos a conclusão que não existe um suporte efetivo para essa camada.

Um pouco dessa dificuldade vem do fato que os frameworks *Unit são ferramentas independentes, se a Oracle/Sun adotassem o *Unit como padrão da implementação do Java isso seria incrível para os desenvolvedores, isto porque toda vez que saísse uma nova versão da plataforma e suas especificações já teríamos uma ferramenta de testes para usar.

Estou realmente achando que essa coisa de testes unitários semiautomáticos pode dar certo para a camada EJB.

Uma outra alternativa mais radical (e que na verdade eu gosto muito) é fazer o sistema todo isolado de tecnologias específicas tal como EJB, ou seja, as regras de negócio ficam em classes puramente Java, também conhecidos como POJO – Plain Old Java Objects – algo que em português seria (livremente) traduzido para Bom e Velho Objeto Java. Isto funciona porque os POJOs podem ser facilmente testados com JUnit básico, e se você usar o EJB apenas para envolver os POJOs então você garante que as regras de negócio estão sendo testadas o que já é um grande alívio. Mas porque então não tem muita gente fazendo isso?

Para separar as regras de negócio você terá mais uma camada, mais um nível de indireção e consequentemente mais classes para gerenciar. Acredito que esta seja a maior barreira para se adotar essa prática, mas eu vou criar um sistema de testes (digo sistema, porque para testar esse tipo de coisa não adianta criar uma classezinha de teste) para avaliar o impacto de se criar essa camada extra.

Outro fator é que muitas vezes as regras de negócio têm dependências de dados que precisam ser supridas, se você conseguir prever todas as necessidades de acesso a banco de dados por exemplo e executar isso antes de chamar o método fica mais fácil de tratar, mas as vezes precisamos fazer uma busca em banco no meio de um processamento de regra de negócio. Aí começa o dilema, porque se você usa JPA com EJB, então terá uma dependência do servidor de aplicação para resolver isso e quebramos a automatização do teste de novo. É claro que você pode usar Mock Objects, uma técnica de fornecer objetos que fingem ser os que realmente precisamos para efeitos de teste, mas ainda assim você terá uma proliferação de classes muito grande.

Assim que eu tiver resultados vou colocar aqui.

Se você parar para pensar, o seu PC em casa é desligado pelo menos uma vez por semana, se as coisas ficarem estranhas, ou o sistema lento, você pode formatar, instalar novamente e tudo volta a normalidade. Mas e quando o celular fica lento e estranho? Sim, porque quando você comprou o aparelho toda vez que acessava a pasta de fotos ele rapidamente carregava, independente da quantidade de arquivos que haviam, mas agora um ano e pouco depois você é obrigado a tirar a bateria porque o sistema travou, nem o botão de desligar está funcionando direito.

Isso está cada vez mais comum, mas muitas vezes as pessoas não percebem porque não ficam tanto tempo assim com seus aparelhos, a vida útil de um smartphone, ao que parece, é de pouco mais (ou pouco menos) que um ano, exatamente o período de tempo que leva para o sistema degradar.

1. Analisar Dados
2. Entender Risco
3. Dominar Robótica
4. Garantir a Segurança da Informação
5. Gerenciar a Rede

Desses, alguns chamam mais a atenção, e neste caso acho que são os itens 2 e 3, entender risco é uma coisa fundamental, essa é uma daquelas partes da TI em que o analista se aproxima mais do administrador de empresas, é uma habilidade mais relacionada ao negócio do que à técnica, no entanto, mesmo no desenvolvimento de sistemas temos que estar cientes das modificações que fazemos e entender os riscos disso. Risco não está relacionado apenas a problemas catastróficos ou eventos de desastre que podem ocorrer, podemos pensar também em quando não atingimos um prazo e temos que pagar uma multa, ou se o desenvolvedor chefe da equipe sofre um acidente e precisa ficar fora por um tempo.

Já a robótica é um assunto que me interessa muito! Isso pode ser visto pela quantidade de posts que coloco aqui sobre robôs. É fato que nós não temos mais como pensar em não conviver com os robôs, mas o profissional de TI deve saber como usá-los como ferramentas, e como programá-los também. As soluções do futuro vão contar com requisitos de robótica, e portanto devemos nos preparar para poder colocar robôs nas arquiteturas de sistemas e soluções propostas.