Bruno Pereira

Eis que num fim de semana chuvoso, com minha noiva viajando, fico eu várias horas em casa estudando para a prova de Arquiteto Java.

Tudo bem, a culpa é minha mesmo. No final do ano passado eu resolvi aproveitar uma das promoções de vouchers com retake da Sun, e comprei não 1, mas 2 vouchers de uma vez. Naquela época eu achava que iria gostar de estudar para as provas de EJB 3 e Web Services.

Bom, ao longo desse ano eu estudei bastante mesmo. E coisas muito legais. Mas em nenhum momento me senti tentado a fazer nenhuma dessas provas, e fui enrolando, enrolando, e meus vouchers vencem dia 30/11. Em setembro eu já sabia que não tinha nenhuma hipótese de eu fazer 2 certificações, então resolvi estudar para a de arquiteto, e usar 1 dos vouchers para a prova teórica, e o outro para a parte prática. E é pra isso que estou estudando, mas como é chato!!!

Para esta prova eu não sabia muito bem que material seguir, então estou lendo o único livro que me pareceu razoável:

Na verdade eu não estou gostando do livro, mas estou lendo alguns tópicos por ele. Os 4 primeiros capítulos falam de aspectos gerais de arquitetura, análise e projeto OO e aplicabilidade da arquitetura Java EE. Eu passei rapidamente por eles, e acho que deve ter sido tão divertido como escutar a “Voz do Brasil”. Teoricamente os assuntos poderiam ser interessantes, mas a exposição é feita de forma tão enfadonha e repetitiva que acho que não consegui obter nada de útil desse conteúdo.

Basicamente eu lia uma porção de coisas que eu já sei, algumas coisas que eu discordo, e alguns devaneios da Sun. É, por exemplo aquele papo insano de que designers podem escrever JSPs… hahahaha! Se eu tentasse ensinar JSP pro designer do meu time ele ia fazer dezenas de caricaturas e montagens minhas no Photoshop, pra eu aprender o que é trabalho de designer

Bom, nesse momento eu estou acabando a parte dedicada a estudar padrões de projeto. Certamente posso dizer que está sendo a melhor parte do estudo, mas me fez refletir um pouco também. Nessa prova são abordados todos os padrões do GoF e todos os Core J2EE Patterns. São 24 padrões do GoF e 22 do Core J2EE Patterns. Uma boa parte eu já conhecia e estou revendo, e outros eu nem conhecia.

Sempre é bom dedicar um tempo para estudar padrões de projeto, mas deveria ser possível filtrar apenas o que interessa. Eu não gosto de Singletons, não gosto de DTOs e não gosto de usar EJBs, então eu já poderia limar facilmente uns 10 padrões dessa lista. Eu gosto bem mais dos patterns do “Patterns of Enterprise Application Architecture (PEAA)”, mas esses infelizmente não estão na prova…

E outra coisa, é fundamental não ficar bitolado nesses patterns. Se você tiver uma overdose de patterns, sua criatividade ficará prejudicada e talvez você siga por um caminho não muito legal só porque existe um pattern para aquilo. Padrões de projeto são interessantes pela possibilidade de te trazer idéias novas para problemas comuns. Mas o importante é que você adquira o know-how e as ferramentas de raciocínio, e pense por si mesmo. Eu já peguei projetos em que parecia que os desenvolvedores estavam procurando problemas para aplicar os patterns, em vez de usar os patterns como idéias para resolver bem um problema que havia surgido. Mais importante do que qualquer padrão de projeto é raciocinar, pensar bem no problema. Rabisque qualquer abobrinha num papel e resolva bem o seu problema com bom software. Ser uma enciclopédia de patterns não faz de ninguém um programador ou arquiteto melhor.

Bom, para finalizar meus rabujos sobre esta prova, devo dizer que estou decepcionado com o que estou absorvendo em minha preparação para ela. Quando eu me preparei para as provas de SCJP e SCWCD, eu nitidamente evoluí como desenvolvedor neste processo. Foi muito válido fazer essas 2 provas e o tempo que dediquei estudando para elas me tornou um desenvolvedor mais eficiente.

Agora, esta prova de SCEA não está me agregando nada até o momento. Eu poderia estar estudando outras coisas mais interessantes e eu não vou ser um arquiteto melhor por ter este título. Talvez a parte prática dessa certificação seja mais legal, mas até agora ela está servindo apenas para eu não desperdiçar meus 2 vouchers que estão expirando.

Será que na prova prática eu posso usar os patterns do PEAA e montar uma arquitetura sem EJBs, sem SOAP, sem JSF e sem DTOs?? Ou será que isso vai ser censurado? Bom, acho que vou pagar pra ver, pelo menos vai ser bem mais divertido!

Yesterday the JSR-311 (Java API for RESTFul Web Services - JAX-RS) was finally approved!

I’m using Jersey (the JSR’s reference implementation) for more than 6 months and I was anxious to have the specification approved.

In my team we’re currently using Jersey 0.7 in production, and were waiting for the JSR to be approved to analyse the final version of its implementations. Now we’ll wait for both Jersey and JBoss RESTEasy to release their final versions and we’ll analyse both to see which one we’ll use in our RESTFul services.

If anyone wants to give me good reasons to use either one of the implementations, now it’s the perfect time! I’m hearing…

Bom, certamente o que eu estou falando não é nenhuma novidade, e nem fui eu que descobri isso ou falei isso pela primeira vez. Entretanto, devido à quantidade de vezes que eu já vi a utilização de atributos de classes para representar chaves estrangeiras (Foreign Keys - FKs), quis comentar isso por aqui para dar meus palpites.

Chaves estrangeiras são componentes importantes de um bom modelo de banco de dados. Elas são muito úteis no controle da integridade referencial e também são usadas com freqüência para indexar tabelas. Porém, não devemos nos esquecer que elas fazem parte do modelo relacional de dados, e não existem em um modelo orientado a objetos.

Esse assunto me veio à cabeça essa semana, quando eu estava analisando algumas coisas na JPetStore, a aplicação de exemplo do Ibatis, e que possui algumas das famigeradas chaves estrangeiras no modelo de domínio. Bom, se até projetos da Apache fazem isso, não me surpreende a quantidade de aplicações que já vi com uma porção de atributos long qualquerClasseReferenciadaId.

Pois bem, eu me lembrava de ter visto essa aplicação Pet Store em mais algum lugar além do Ibatis. Após uma breve pesquisa, encontrei de novo a aplicação da lojinha de bichinhos feita em Java, no catálogo de Blue Prints Java EE 5.

Claro que imediatamente baixei a aplicação e fui olhar as classes de domínio. Tamanha foi a minha surpresa ao constatar que também nesta implementação existem vários exemplos de atributos representando FKs. Na classe Product há um belo String categoryId. Na classe Item há um belo String productId. Achei curioso que nesta mesma classe Item há um atributo SellerContactInfo, que é uma outra classe de domínio, com atributos coerentes. Eles podiam ter colocado um atributo String contactInfoID, mas em vez disso colocaram a classe efetivamente. Ou seja, dentro de uma mesma classe há políticas diferentes de uso das FKs.

Me deixou um tanto desapontado ver isso num catálogo de Blue Prints (boas práticas). Provavelmente muita gente toma esses Blue Prints como referência de implementação, então isso me esclareceu um dos motivos pelos quais as FKs estão tão difundidas em modelos de domínio por aí.

Eu estou ainda com 2 vouchers da Sun que pretendo usar na certificação SCEA. Quando eu comprei esses vouchers eu achei que fosse usá-los na certificação de EJB 3 e na de Web Services, porém não estou animado para fazer nenhuma das 2, então me decidi pela prova de arquiteto.

Dentro do conteúdo da certificação de arquiteto está esse tipo de coisa dos Blue Prints, catálogos de padrões de projeto, entre outras coisas. Isso me lembrou mais uma vez que temos sempre que ler as coisas com olhar bastante crítico, para julgar de fato o que podemos aproveitar e o que temos que descartar.

It’s worth saying that these Blue Prints are looking more like Brown Prints, and some annoying smell is coming from them…

Essa semana fiquei sabendo pelo blog do Savio Rodrigues que a IBM investiu US$ 10 milhões no EnterpriseDB, uma derivação comercial do Postgresql, mas cujos desenvolvedores atuam no desenvolvimento do produto open source também.

Com isso, até o momento o EnterpriseDB já recebeu no total US$ 37,5 mi, o que é bem próximo dos US$ 39 mi que o MySql havia recebido antes de ser comprado pela Sun. Torço para que isso ajude bastante no desenvolvimento do banco de dados e que eles consigam trazer ainda mais qualidade aos seus produtos. O Postgresql é um banco open source muito maduro e confiável já há muitos anos e o EnterpriseDB adiciona recursos interessantes para grandes empresas. Entre as principais forças do EnterpriseDB está a sua garantia de compatibilidade com código feito para o Oracle. Eles garantem por contrato que a sintaxe SQL, tipos de dados, packages, stored procedures, trigger e views desenvolvidas para o Oracle irão funcionar conforme esperado no EnterpriseDB. Isto sem dúvida é um facilitador para empresas que possuam grandes bases Oracle e queiram progressivamente migrar seus bancos de dados.

Eu usei pela primeira vez o Postgresql no começo de 2003, e sempre o considerei melhor que o Mysql. A principal razão pela qual o Postgres perdeu espaço para o MySql foi o fato de que o Postgres não tinha um instalador nativo para Windows antes da versão 8.0, que saiu em janeiro de 2005. O MySql tinha muito menos funcionalidades e confiabilidade, mas como era fácil utilizá-lo no Windows, sua adoção aumentou rapidamente.

Eu ainda considero o Postgres melhor do que o MySql e ele é o meu banco de dados preferido quando eu tenho a liberdade de escolher. Espero que eles continuem desenvolvendo bastante o produto e recebam mais investimentos. Eles merecem um ótimo lugar no mercado de bancos de dados, e torço para que eles consigam tanto ou mais sucesso que o MySql.

Aproveitando esta discussão, algo que me veio à cabeça diz respeito à consolidação das pilhas de produtos no mercado. Será que faria sentido que a Red Hat comprasse o EnterpriseDB e a Oracle comprasse uma distribuição Linux?

A Sun atualmente possui a pilha completa, indo do sistema operacional até o middleware Java, e inclui um banco de dados (MySql). A IBM não vende mais sistemas operacionais próprios (até onde sei), mas suporta bastante o Linux e tem seu banco de dados e o middleware Java EE.

A Oracle tem tudo menos o sistema operacional, especialmente depois da compra da BEA. A Red Hat tem tudo menos o banco de dados. Ambas fizeram compras significativas no passado. Será que veremos as 2 empresas completando sua pilha de produtos em breve?

Isto é algo que eu gostaria de saber, e seria bem interessante ver como o mercado se comportaria depois de tais movimentos.

No meu tempo de experiência com Java EE já pude aprender e constatar bastante coisa. Um fenômeno que se repete com freqüência é a escolha de servidores e componentes que contêm muito mais do que se necessita para a resolução de um problema específico.Um exemplo claro disso é em aplicações que não precisariam de absolutamente nada que o Tomcat não ofereça, mas a escolha padrão acaba sendo um servidor de aplicações “mais parrudo”, como JBoss, WebSphere ou Weblogic. O curioso é que estes últimos servidores de aplicação suportam uma quantidade bem mais ampla de especificações e oferecem bem mais recursos, mas o que eles realmente oferecem de diferencial não é o que está nas especificações, na maioria dos casos.

Muitas vezes o diferencial destes produtos está em funcionalidades nos quais eles excedem as especificações e oferecem facilidades que não são obrigatórias. O fato de oferecer estas funcionalidades extras é muito bom, pois isto traz mais qualidade aos clientes, e isto possivelmente melhora os processos internos do cliente. Apesar disso, é comum vermos escolhas de tecnologia serem feitas porque a opção A oferece muito mais recursos do que a opção B, sendo que na prática as opções oferecidas pela opção B serão plenamente suficientes para atender a todos os “problemas reais” que virão a surgir. Isto quer dizer que é comum a opção A ser escolhida em vez de B sem que se saiba quais recursos de A serão úteis de verdade, mas pela percepção que “A oferece mais do que B”.

Talvez a justificativa para este comportamento seja escolher uma opção que “possua todos os recursos que necessitaremos”. Consigo entender isso. Porém, isto traz o caso comum de usar uma bazuca para matar uma mosca. Sim, com a poluição e evolução das espécies, podemos no futuro encontrar super moscas mutantes do tamanho de um helicóptero, e neste caso espero que você esteja com sua poderosa bazuca para matar essa mosca monstruosa!
Entretanto, para as moscas que eu costumo encontrar, um mata-moscas de plástico resolve o problema. Além disso, eu sei usar bem um mata-moscas de plástico, e foi bem mais fácil de aprender a usá-lo do que aprender a usar uma bazuca. Por oferecer bem menos e ser bem mais simples, o modo de operação do mata-moscas de plástico é algo que uma criança consegue aprender. Já para utilizar a poderosa bazuca matadora de moscas mutantes, é bom ler direitinho os manuais de utilização e se possível fazer o curso prático para fixar bem os conceitos. Afinal de contas você não quer correr o risco de se deparar com uma mosca mutante e não saber usar a bazuca né?

Da mesma forma que as moscas, as aplicações corporativas possuem este tipo de fenômeno. Antes de conhecer as necessidades reais da aplicação, já se definiu o uso do Weblogic com Oracle e possivelmente a configuração de um cluster de alta disponibilidade. Talvez fosse uma aplicação pequena ou média que o Tomcat + Derby ou Postgres ou Mysql pudesse dar conta sem problemas.

Eu venho estudando muito sobre web services nos últimos meses. Também nesta área isto ocorre bastante. Sem conhecer bem as necessidades que se quer resolver, já foi escolhida a pilha de componentes que “oferece tudo de web services”.

Este fenômeno é global, ocorre no mundo todo. Opiniões interessantes sobre isso foram dadas por Bill de hÓra e Rod Johnson. Uma abordagem que pode ser tomada é tomar as decisões de tecnologia baseando-se nos requisitos já inicialmente definidos. Pegar os requisitos funcionais e não-funcionais iniciais da aplicação e então decidir as tecnologias a se utilizar parece uma boa escolha. Desta forma, você possivelmente fará boas escolhas sem trazer desde o começo uma complexidade e custo que possivelmente nunca seriam necessários.

Claro, existem casos em que realmente se utilizará extensamente os recursos avançados do Weblogic e do Oracle, e eles são de fato necessários. Da mesma forma, podem existir web services com altos requisitos de segurança e confiabilidade que te façam depender de recursos do stack WS-*. Se este for o caso, escolha mesmo as opções com mais recursos e utilize tudo que precisar para atender aos requisitos críticos que lhe forem apresentados. Porém, saiba que estes casos são a minoria dentre as aplicações corporativas existentes mundialmente.

Se o seu problema for algo mais comum, escolha produtos e componentes que resolvam bem os problemas apresentados, e se algum dia eles deixarem de atender às necessidades, pondere novamente as suas escolhas. Isto sugere o “Grow as needed” do título. Cresça a sua estrutura conforme necessário, não compre inicialmente uma bazuca se ainda não existem moscas mutantes. E se os seus problemas não mostram claramente a necessidade da bazuca, aí provavelmente surge a sigla do título: YAGNI (You aren’t gonna need it)!

Antes de escolher as opções “mais ricas e robustas” disponíveis, estude se opções mais simples são capazes de resolver os seus problemas, pois se isto for o caso, você provavelmente terá uma configuração mais simples e mais barata e cheia de pessoas capazes de manipulá-la. Isto é melhor do que depender vitalmente de algum fornecedor e precisar contratar o super especialista que é um dos poucos no mundo capazes de resolver seus pepinos.

E claro, se suas decisões puderem ser de componentes open source, você não pagará nada de licença de software e terá uma grande variedade de profissionais disponíveis para te oferecer serviços