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.

O que temos feito lá no trabalho é usar o Scrum como forma de agilizar nosso processo, mas Scrum na mão é bem complicado, o jeito foi procurar uma ferramenta que desse um suporte. Começamos com uma ferramenta nacional, o Pronto, mas logo tivemos alguns problemas.

Não me entendam errado, o software é muito bom, mas o seu foco em um único projeto quebrou a nossa equipe. Após várias pesquisas chegamos a um bem completo, o IceScrum.

O legal do IceScrum é que permite gerenciar vários projetos, assim você vai colocando todas as informações em um lugar só. É claro que tem algumas limitações, mas por já estar na versão 15.x ele é bem maduro e estável. Tem duas coisas que me incomodam bastante, a primeira é que não podemos adicionar vários arquivos a uma User-Story, então se você tiver mais de um documento a coisa fica complicada; a segunda é que só podemos ter 5 defeitos por sprint, eu acho isso ruim, porque o que tivemos que fazer foi criar uma Tech-Story para colocar bugs.

Mas no geral, a ferramenta é muito boa mesmo, tem o dashboard para trabalharmos, você pode declarar os testes que precisam ser feitos. Um grande problema é você conseguir mudar a cultura da equipe para escrever as coisas na ferramenta (mas isso também é um problema no PMBOK/RUP).

Estou preparando um pequeno manual da ferramenta em português, mas ainda não estou com previsão de quando estará completo, espero que em breve

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.

Optamos (experimentalmente) por fazer os diagramas em um quadro branco, todo mundo participa e discute no final tira-se uma foto digital do quadro e guardamos a foto na documentação do projeto. Então na prática não abolimos o diagrama como ferramenta de entendimento, mas a etapa de migrar do quadro para uma ferramenta de modelagem acabou.

Eu venho usando essa alternativa de fotografar os quadros desde 2008, tanto para palestras quanto para aulas, no final aquele quadro que foi usado para alguma discussão contém muito mais informação do que seria concebida em uma sessão de análise isolada.

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.