Learn by Example

Alguns anos atrás pude conviver um pouco com minha cunhada arquiteta enquanto viajávamos por algumas cidades do interior da Itália. Uma das coisas que me surpreendeu na viagem foi a atenção que ela dava aos detalhes das construções, tirando fotos de calhas, paredes, janelas, portas, etc. Enquanto nos preocupávamos com um mundo novo que conhecíamos, ela ficava atenta a cada detalhe.

Fiquei, obviamente, intrigado com o comportamento dela. E fiquei ainda mais intrigado após entender por que ela observava o trabalho dos outros com tanto afinco. Na arquitetura, o processo de criação leva em consideração a observação do trabalho dos outros arquitetos.

O processo de desenvolvimento de software também é um processo criativo. No entanto, parece-me que neste processo a observação do software desenvolvido por outras pessoas não tem um papel tão fundamental. Pelo menos não tem o papel que deveria ter.

Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides (GoF) foram em um caminho parecido, ao utilizar a observação para identificar padrões de solução de problemas em software. Martin Fowler também é outro expoente deste tipo de observação e de sua aplicação na vida real. No entanto, a prática da observação realizada por estes grandes nomes da computação não foi absorvida pelos demais desenvolvedores (com exceções, claro). Apenas os resultados de sua observação é que se tornaram notáveis, e não o processo pelo qual estes resultados foram obtidos.

Os design patterns são exemplos de como a observação é efetiva. No entanto, o uso destes design patterns não é o benefício mais importante destes trabalhos. O benefício está no processo de observação e aprendizado. É este processo que precisamos exercitar constantemente e é nesta observação que devemos basear nosso aprendizado.

JavaEE vai morrer???

Spring versus JavaEE é uma daquelas discussões que são eternas. Não quero me prolongar nas qualidades de uma ou de outra tecnologia, mas apenas em um fenômeno muito forte que vem ocorrendo e que deveria deixar a maior parte das organizações atentas. Este fenômeno chama-se PaaS (Plataform as a Service).

O PaaS surge como forma de tornar praticamente transparente a gestão da infra-estrutura de um sistema computacional, trazendo a escalabilidade de forma flexível e com pouco ou nenhum overhead. No entanto, as soluções mais recentes apontam para o uso de plataformas mais leves como Python, Ruby on Rails, JavaScript, .NET e Java / Servlets, deixando completamente de lado a plataforma JavaEE. E há uma razão para isso: ninguém precisa de JavaEE de verdade. JavaEE nada mais é que uma solução em busca de um problema a ser resolvido.

Neste sentido, ferramentas úteis aos desenvolvedores fornecidas na plataforma JavaEE podem ser obtidas, usando apenas programação declarativa, através do Spring Framework, que pode ser executado em qualquer plataforma que suporte Java puro.

Ou seja, desenvolva com Spring (ou Guice, ou não use nada para injeção de dependências) e possibilite a realização de deploy na nuvem (BeansTalks e GAE, por exemplo). Em um mundo onde a infra-estrutura se torna transparente, JavaEE não parece ter muito futuro.