Débito Técnico

Bem, nem só de Scrum vive esse blog! O propósito deste post é falar um pouco da nova arquitetura que adotamos para o projeto Hotmotors. Desde que publiquei aqui no Débito Técnico o artigo “UML não é documentação”, onde disse que a arquitetura (Struts 1 + Hibernate) de 2006 não me dava muito orgulho, várias pessoas entraram em contato para ajudar no desenvolvimento de uma nova arquitetura Seam. O Rafael Benevides foi o cara que topou a parada e começamos o trabalho.

Pra falar a verdade fiquei até surpreso como a conversão de uma arquitetura para outra foi rápida. O Rafael me entregou a primeira iteração em 2 dias (OK, talvez ele seja um code hose). O trabalho dele foi portar o Hibernate para JPA, passar todos os JSP para xhtml e retirar o Struts de cena implantando o JSF/Seam. Segundo o próprio Rafael, o fato de termos um bom design ajudou bastante, principalmente o fato de nosso Domain Model estar bem fundamentado.

Por que o Seam Framework?

Eu já trabalho com sistemas baseados em web a bastante tempo. A evolução que esse tipo de sistema foi desde escrever vários servlets na mão que cuspiam html, seguido a inclusão de JSPs, as infinitas Tag Libraries, a introdução de composite-views (como o Tiles), o Struts e a segunda geração de frameworks (WebWork, Spring MVC, VRaptor, Mentawai, só para citar alguns). Correndo meio que por fora disso temos o JSF. O JSF é controverso. A idéia do JSF era ter em Java a mesma idéia que existe no Web Forms do ASP.Net. Um event-based framework que melhorasse a produtividade na construção da view (junto com muitas outras coisas mais). Por que ele é controverso? Bem, primeiramente o JSF é um tipo de tecnologia que visava uma dependência de ferramenta (como uma boa IDE). Muitas outras coisas foram discutidas numa longa, mas muito longa thread do GUJ (note que ela iniciou em 2005).

http://www.guj.com.br/posts/list/29623.java

Um outro fato é que JSF-based tem várias implementações alternativas (ADF Faces, RichFaces, MyFaces só pra citar alguns). Se você usar a reference implementation da Sun você não terá coisas muito interessantes e ainda sofrerá de “configuration hell” com XML, mas usando essas alternativas você ganha uma view limpa e uma grande facilidade em fazer RIAs com Ajax.

O SeamFramework inicialmente era bem baseado no RichFaces, porém, atualmente na versão 2.x, ele é mais independente do framework web que você escolheu. De qualquer forma, o Seam é uma excelente alternativa para integrar sua camada view em JSF à sua camada de aplicação, oferecendo uma consistente implementação para ligar tudo isso. Como falei, eu já passei em vários frameworks web, principalmente os Action based. Usando o Seam, basicamente os benefícios que ví foram:

1. Convention Over Configuration (não é necessário configurar nada em XML - tenho nojo de XML)
2. Component-based e não Action-based (de fato, não há uma boa definição sobre essa diferença)
3. Boa integração entre JSF e EJB3.
4. Conversation Model (não ví nenhum framework web resolver isso da maneira que o Seam faz)
5. Menos Javascript para coisas banais
6. Injeção de Dependências via anotações
7. Integração com outras coisas como o JBpm.

Muitas outras razões você pode ver no site www.seamframework.org. O SeamFramework foi uma das razões para eu voltar a gostar de fazer aplicações web em Java. Faz mais ou menos 2 anos que estou utilizando o Seam, algumas coisas já estão no ar e realmente são aplicações confiáveis.

Algumas coisas que me incomodam… e outras que resolví.

Aos 4 ventos eu promovo o Seam como uma boa arquitetura de caixinha em JEE. Mas nem tudo é um mar de rosas. O Seam é um monstro. É um framework muito grande e precisa de uma infraestrutura no lugar para que ele possa rodar. Desde que iniciei com o framework tive dificuldades em fazer DI fora de um ambiente JEE. Isto é um problema quando você quer tomar uma estratégia TDD de verdade. Como exemplo, para fazer um SeamTest rodar você precisa ter um Embeddable Jboss. Isto é, você precisa de um JNDI, um EntityManager Factory e toda parafernália JEE no ar. Numa máquina mediana isso pode tomar de 20-50 segundos para subir. É irritante aplicar TDD com o Jboss Seam. Para falar a verdade, só para subir um EntityManager JPA com umas 100 entidades já toma aproximadamente 15 segundos. Isso é uma coisa para o pessoal do Hibernate pensar a respeito.

Esse “peso” para usar o Seam num ambiente “plain JSE” é uma das coisas que tinha me decepcionado muito no framework, isso foi bom pois me empurrou para estudar Rails/Ruby mais a fundo. Uma das coisas que encanta no Rails é a leveza. Tudo é leve! Desenvolver é leve, subir um WEBrick para desenvolvimento não toma mais que 2 segundos (é isso mesmo, 2 segundos). Você pode fazer o que quiser e não precisará reiniciar o servidor quase nunca. No PHP também é assim. Até no ASP é assim. Isso é chamado de development turnaround time. O turnaround do Ruby, PHP e outros citados é baixo. O Java causa uma cegueira técnica nesse sentido: qualquer coisinha que você mexa na implementação o Java chia que você tem que reiniciar o servidor para “pegar” as novas classes, anotações ou configuração que você fez. Nós nos acostumamos a perder tempo com isso e não reclamamos! Muito se discute, mas pouco se faz na prática.

Como o berço do Seam é a Jboss, não ví uma iniciativa por parte deles para melhorar isso (eles tem uma tendência a usar todos os outros produtos Jboss). Nesse ponto, usar o Jetty é algo que evolue pouco nas discussões da comunidade Seam e não consta em documentação. O Jetty é uma implementação leve de um servlet container que é muito usado para desenvolvimento (e também para produção). Olhando para o Seam, desde o início ví que teria uma maneira de usar o Jetty, mas não tive tempo de implementar isso. Vasculhei até achar um blog que dizia como fazer o Seam rodar no Jetty. Foi uma vitória, e além disso, este post ainda tinha esse projeto Seam Mavenizado (não sei se outras pessoas usam essa palavra).

A única pedra agora é que este projeto estava integrado com o Spring. Nada contra o Spring (fora o fato dele sofrer de configuration hell com XML, já falei que tenho nojo disso?), mas o ponto é que nossa aplicação Hotmotors seria simplesmente Seam. Bem, inicialmente coloquei o Maven para rodar dentro do Eclipse e depois, tratei de ver documentação e desplugar o Spring dessa implementação (e contornar alguns probleminhas do Jetty no Windows, meu MacBook Pro só vai chegar no final de agosto pra piorar minha vida miserável de programador).

Depois de tudo isso eu pude dormir mais contente: tenho uma referência do Seam Mavenizado e rodando no Jetty. Isso já melhorou muito o turnaround time em desenvolvimento. Creio que isso deixará mais alguns outros programadores felizes. Finalmente revivemos o Hotmotors! As próximas iterações vêm aí e nosso próximo passo é integrar as ferramentas de teste automatizado (provavelmente Fit e Selenium) e ver alternativas para o TDD. Aguardem!

Para baixar esse release, acesse a página do HotMotors.

O Seam é comparável com o Rails em produtividade? A comunidade Seam se posiciona como concorrente do Rails. Essa resposta eu não tenho ainda, mas minha idéia é reimplementar tudo em Rails para tirar essa dúvida.

Queria agradecer muito pela colaboração do Rafael para a comunidade. Valeu!

Obs. Veja mais informações de como rodar este release no blog do Rafael.

Nesta semana eu e o Phillip Calçado compartilhamos uma coisa: nós lemos artigos numa revista fora do mundo de tecnologia (se é que existe isso hoje em dia) e achamos conceitos ágeis lá. Veja este post no blog gringo dele:

BigPharma Problems & Solutions: Have You Seen This Before?

Na edição brasileira da Harvard Business Review de junho/2008, Tim Brown escreveu um artigo apresentando o “Design Thinking”. Ao ler o artigo ví que Design Thinking é recheado de conceitos ágeis. Muito recheado! É praticamente uma abordagem ágil para a inovação em todas as esferas empresariais.

A abordagem de [Thomas] Edison é um dos primeiros exemplos do que hoje se chama design thinking - metodologia que imbui todo o espectro de atividades de inovação de um etos de concepção centrado no homem… Edison não era um cientista especializado num campo apenas - era, antes, um generalista com aguçado tino comercial. Em seu laboratório em Menlo Park, New Jersey, Edison se cercava de gente com talento para improviso e experimentação. Na prática, derrubou o mito do “inventor genial e solitário” ao criar uma abordagem de equipe à inovação.

Preste atenção nesta parte:

A idéia era justamente não corroborar hipóteses preconcebidas - mas ajudar o investigador a aprender algo a cada lance iterativo.

(grifo meu)

É interessante ver como pragmatismos estão florescendo dentro no mundo empresarial das pessoas espertas e como mais e mais rigidez e controle estão obscurecendo a vida das empresas burras. Design Thinking é uma perspectiva humana para a solução dos problemas. É o envolvimento de cada indivíduo, de cada mente, na busca de uma solução viável e criativa. Isso envolve empatia, raciocínio integrativo, otimismo, experimentação e colaboração. O Design Thinking é a dinâmica de um processo colaborativo de inovação. Relatando um caso de solução para um problema de um grupo de enfermagem da Kaiser (não é a fábrica de cervejas), Tim Brown acrescenta o que colaborou para a solução:

…as equipes de inovação exploraram soluções potenciais por meio de brainstorming e prototipagem rápida… Um teste com protótipos não precisa ser complexo e nem caro. Um protótipo deve consumir apenas a quantidade de tempo, esforço e investimento necessária à geração de um feedback útil a evolução da idéia - nada mais. Quanto mais “acabado” parecer um protótipo, menor a probabilidade de que seus criadores ouçam o feedback - e se valham dele.

Olha que engraçado! A HBR, uma revista tradicionalíssima, está dizendo que meus protótipos visuais estão certos! Quando aquele gerentinho metido torcer o nariz poderei falar: “- Você leu o artigo sobre Design Thinking na Harvard Business Review?”

…o que ocorreu na equipe de enfermagem da Kaiser não foi um avanço súbito e revolucionário, nem o estalo de um gênio - foi fruto do trabalho árduo realçado por um processo criativo de descoberta centrado no ser humano, seguido de ciclos iterativos de testes com protótipos e aperfeiçoamento.

Esta é a parte que mais gostei (comentários meus entre parênteses):

O melhor jeito de descrever o processo de design é metaforicamente (Beck?) - como um sistema de espaços, em vez de uma série predefinida de passos ordenados (Gantt?). Esses espaços delimitam tipos distintos de atividades correlatas que, juntas, formam o continuum da inovação. O Design Thinking pode parecer caótico para um marinheiro de primeira viagem (seu chefe?). Mas, no decorrer de um projeto, os participantes acabam entendendo que o processo faz sentido e produz resultados (um release?), ainda que sua arquitetura seja distinta do processo linear fundado em marcos intermediários característico de outras atividades empresariais.

Este parágrafo no artigo é uma das melhores definições que já ví a respeito da natureza de um processo de design. Desenvolver software é 100% design. Isso foi tão contundente pra mim que contactei o Tim Brown - o autor do artigo - perguntando se ele tinha sido influenciado pelas práticas do Agile Software Development. Veja a resposta dele entre outras coisas:

From: Tim Brown
Date: 2008/7/2
Subject: Re: Article about Design Thinking on Harvard Business Review
To: Rodrigo Yoshima

Hi Rodrigo,
It doesn’t surprise me to hear that software design shares many of the same characteristics as design thinking. You are right that there has not been a lot of interaction between these two communities other than through the computer human interaction folks where I think a lot of these same issues have been discussed.

Thanks for making the link.

Best regards
Tim

On 6/30/08 5:53 PM, “Rodrigo Yoshima” wrote:

> Hi Tim,
> I’ve just read your article about Design Thinking and I’m
> just very very curious about how you put Design Thinking
> pratices together. Design Thinking concepts are very close
> to Agile Software Development Practices. Have you ever
> heard about it? Take a look at www.agilemanifesto.org.
>
> I see that the values of the Agile Manifesto is our flag of
> Design Thinking on Software Development. 100% of the
> software construction is design. Agile Practices are:
>
> - Human centered / Focused on Team Work
> - Iterative / Cyclical / Feed-back based
> - Use a lot of Prototypes / Sketches
> - Empirical
>
> I guess that you can really benefit from the contents
> that our community have being studying for the last 20 years.
>
> Cheers.
>
> Rodrigo Yoshima
> ASPERCOM / MundoJava

Sim! Mais uma vez provamos que o futuro do mundo empresarial é empírico e pragmático. Mais uma vez está provado que rigidez e processos inflexíveis impedem a inovação. Quem só tem martelo na mão só vê pregos pela frente… e sai martelando tudo.