CEJUG completa 7 anos

Como o tempo passa rápido. Lembro-me de quando ainda era um mero estagiário, por volta do início de 2005, e havia acabado de entrar para o grupo de discussão do CEJUG.

No início era só mais um “observer” entre tantos, apenas lia as threads que ali rolavam e por poucas vezes postei algo ou até mesmo respondi alguma dúvida. Na época meu conhecimento ainda era muito limitado, e minha timidez e baixa-estima não me permitiam colaborar com o grupo.

Aos poucos fui (re)conhencendo certos nomes, membros que postavam e ajudavam bastante com o grupo. Ficava claro quem realmente tinha alguma estima pelo grupo. Ficava claro quem realmente eram os verdadeiros formadores de opinião no grupo e mais ainda, porque eles realmente tinham o respeito merecido na lista.

Graças aos poucos eventos da época e a estas pessoas eu, sem perceber, me envolvi com o grupo. Passei a participar ativamente da lista, a fazer questão de ir aos eventos e principalmente divulga-los em outras listas de discussão, instituições e empresas.

Estava mais que óbvio que o grupo, CEJUG, se tornara algo importante no meu dia-a-dia, e principalmente era importante para o nosso mercado de trabalho, aqui em Fortaleza. Cada dia mais eu passei a me dedicar de alguma maneira para grupo, e foi daí que, depois de algum tempo, tive a oportunidade e o privilégio de ajudar o grupo de uma forma mais direta: minha primeira palestra no CEJUG.

Houveram muitos altos e baixos no grupo, tenho o orgulho de dizer que participei da maioria deles. Fiz muitos amigos, e até mesmo alguns poucos “inimigos”. Mas tudo que houve agregou valor a minha vida profissional e como pessoa.

Café com Tapioca
Café com Tapioca

Hoje, depois de quase 5 anos caminhando junto com o grupo, eu tenho o prazer de anunciar que no dia 19 de Setembro irá ocorrer o Café com Tapioca do 7º Aniversário do CEJUG.

Assim como nos eventos de aniversário anteriores, este será um grande evento para o nosso mercado e trará grandes nomes nacionais e locais. Alias, o número de palestras, e o próprio evento em si, está bem maior que nos anos anteriores.

Teremos 7 palestras sobre vários assuntos técnicos, desde TDD, JME, frameworks web, até metodologias ágeis. Todos os assuntos estão diretamente relacionados ao atual cenário do nosso mercado. Vale ressaltar que as palestras serão ministradas por Paulo Silveira, Rodrigo Yoshima, Jeveaux, Bruno Pereira, Tarso Bessa, eu, Régis Melo e Victor Oliveira.

Com toda certeza este será um evento que marcará, com Java, o ano de 2009 no Ceará. Um dia inteiro de palestras, networking com grandes profissionais, brindes (quem não gosta!) e muita troca de informações sobre a plataforma Java. Vale muito a pena sair de casa neste sábado, dia 19 de Setembro, e investir seu tempo neste evento.

Espero encontrar todos lá, se não a maioria dos profissionais e estudantes membros dos CEJUG no evento. Até o dia 19.

Managed Beans. Não complique, simplifique.

Já é sabido de todos que JSF é um framework web MVC com uma filosofia voltada a component-based. E não diferentemente dos bons frameworks action-based existentes hoje em dia, o JSF também se utiliza de POJOs como parte do controller.

Sim, eu estou falando dos, já muito conhecidos, managed beans. Eles são os responsáveis por intermediar a comunicação entre nossas páginas e o nosso modelo. Até aí tudo bem, não existe qualquer mistério, basta entender um pouco sobre MVC que isso torna-se óbvio.

Se você observar, quando está trabalhando com JSF, notará que cerca de 50-70% do seu esforço é dedicado na implementaçao do managed bean. E que as futuras alterações e correções de bugs estão intimamente ligados a ele. Implementar corretamente um managed bean pode evitar muita dor de cabeça e facilitar na manutenção da aplicação.

Mas você já se perguntou como e qual seria a melhor forma de implementá-los? Não que exista apenas uma única maneira de escreve-los, longe disso, mas em contra partida existem inúmeras maneiras de torna-los realmente ruins.

Escrever um managed bean de forma porca incorreta pode dificultar e muito sua vida e da sua equipe. Falta de legibilidade, dificuldade para escrever testes de unidade e principalmente medo de alterar o código são apenas alguns dos possíveis problemas.

Agora pare e imagine a vida do próximo desenvolvedor que deverá manter tal código. É, não parece algo divertido.

Managed Beans mais responsáveis

A principal responsabilidade de um managed bean é intermediar a comunicação entre as páginas (componentes do JSF) e nosso modelo. Escutar eventos, processa-los e delegar para a camada de negócios são apenas algumas de suas responsabilidades.

Talvez devido a experiência com frameworks action-based muitos desenvolvedores acabam subutilizando os managed beans e sobrecarregando as páginas com lógicas e dados desnecessários. Os managed beans e as páginas usam a abusam do modelo “pull” durante a renderização e (re)construção da árvore de componentes, isto é, basicamente as páginas é quem decidem (através de EL) quais os dados e lógica necessária para que possam ser processadas.

Graças a este modelo nós conseguimos retirar toda lógica de renderização da página e colocando-a onde jamais deveria ter saído, no managed bean. Esta lógica estará localizada nos métodos públicos do managed bean que serão acessados através de EL pela página.

Não importa se a lógica é simples ou complexa, é quase que mandatório que ela esteja localizada no seu managed bean. Então bizarrices lógicas de apresentação nas páginas, que não são difíceis de se encontrar por aí, como esta deveriam ser evitadas:

<h:panelGrid id="pnl" rendered="#{loginBean.usuario.admin == 1 or loginBean.permissao('exibir_painel_de_usuarios')}" />
	...
</h:panelGrid>

Reparem que a lógica de apresentação está, representada através de EL, na página. Se você teve a infelicidade de encontrar códigos assim então há grandes possibilidades de você também encontrar regras de negócio nas páginas, o que é muito pior que encontra-las no controller.

E olha que este foi apenas um exemplo simples e ligeiramente legível, já encontrei códigos mais complicados que este de dificil leitura e horrível de dar manutenção.

O problema disso é se houver a necessidade de mudar a regra (o que muitas vezes ocorre), mas e se ela estiver duplicada por dezenas de páginas, como você faria? Como testa-la? Pense um pouco sobre isso.

Imaginem um código um pouco pior que este (com 3 ou 4 condicionais), mas dentro de um componente de iteração (como h:dataTable ou ui:repeat). É, você nem vai querer imaginar.

A regra de visualização acima deveria está encapsulada no managed bean, a página não deveria conhecer a regra, mas apenas quem a conhece. Então pensando nisso nós poderíamos alterar nosso código para algo melhor, algo como isto:

<h:panelGrid id="pnl" rendered="#{loginBean.permitidoExibirPainelDeUsuariosLogados}" />
	...
</h:panelGrid>

O componente não conhece a regra, mas sabe exatamente a quem perguntar. O código está bem mais legível pois revela sua intenção. Agora está bem mais fácil mudar a regra (pois temos apenas um único ponto de manutenção) e principalmente testa-la através de testes automatizados.

Um managed bean deveria ao máximo tentar esconder a complexidade das páginas através de métodos que revelem a devida intenção, ou seja, a nomenclatura dos métodos é realmente importante e você deveria dar importância a legibilidade do seu código.

Comunicação entre managed beans

O que eu tenho para falar, de longe, se iguala ao que pode ser encontrado no excelente conteúdo sobre comunicação no JSF neste post no blog do BalusC, além de que para mim ele aborda 99% sobre como managed beans podem se comunicar.

O que pretendo falar está mais relacionado em como manter uma conversa (troca de mensagens) saudável entre managed beans. Em como explicitar os parâmetros esperados e como passar parâmetros de um managed bean para outro de maneira coerente.

A comunicacão entre managed beans não difere da troca de mensagens entre componentes de software na orientação a objetos. Cada componente (managed bean) conhece a interface pública do outro componente para que eles possam trocar mensagens.

Sendo, ter esta interface pública bem definida pode facilitar muito a “conversa” entre os managed beans, facilitar os testes, evitar problemas inesperados, diminuir o acoplamento, aumentar a coesão e assegurar contratos e invariantes do componente.

Nada mais claro que um exemplo para assimilar a idéia:

<h:dataTable var="item" value="#{compraBean.itensNoCarrinho}">
    <h:column>
        <h:commandLink value="detalhe" action="#{itemBean.exibirDetalhesDoItem}">
            <f:setPropertyActionListener value="#{item}" target="#{itemBean.itemSelecionado}" />
        </h:commandLink>
    </h:column>
</h:dataTable>

O código acima não tem nada de errado ou anormal, nada do que não estejamos acostumados a ver quase todos os dias. Se repararem há um pequeno “dialogo” entre dois managed beans – compraBean e itemBean – que estão trocando informações.

O problema não está na comunicação em si, pois isso teria que acontecer de um jeito ou de outro, mas sim em como eles se comunicam. O managed bean compraBean conhece detalhes de como o itemBean se comporta, ou seja, ele sabe mais do que o necessário.

Um maneira de melhorar isso seria ter uma interface pública bem definida no itemBean. Algo semelhante ao código abaixo:

<h:dataTable var="item" value="#{compraBean.itensNoCarrinho}">
    <h:column>
        <h:commandLink value="detalhe" action="#{itemBean.exibirDetalhesDoItem(item)}" />
    </h:column>
</h:dataTable>

Além de todos os benefícios (baixo acoplamento, alta coesão etc) citados acima, nós ganharíamos de cara maior legibilidade no código, o que é algo realmente importante quando a comunicação foge do trivial.

Vale ressaltar que independente da comunicação ocorrer na página (por meio da JBoss-EL) ou diretamente dentro do managed bean, essa abordagem poderia -e até deveria- ser utilizada. Para o segundo caso, frameworks como JBoss Seam ou Spring ajudam a injetar as dependências de maneira simples através de anotações.

Um ou vários managed beans?

Não tenho uma opinião realmente formada quanto a isso, ainda não. Já pensei várias vezes sobre o assunto, e sempre me pego vislumbrando cenários nada comuns. Que no caso os considero como casos excepcionais.

Desde 2006 eu trabalho com JSF, ministro cursos e treinamentos e presto consultoria para algumas empresas. E posso dizer que somente três vezes eu precisei ter mais de um managed bean para resolver uma tarefa. Dentre todas eu tenho a ligeira impressão que segui o caminho errado mais complicado, e que se tivesse pensado mais um pouco eu poderia ter evitado tais soluções.

Managed beans são componentes, em sua grande maioria, intimamente ligados a(s) página(s) e que deveriam ter apenas o estritamente necessário para representar a GUI. Dificilmente você terá um managed bean genérico (CRUD não conta) que poderia funcionar em todo lugar. Você precisa fazer um esforço hercúleo para conseguir isso, e as vezes parece que não vale a pena.

A idéia de um managed bean ter dados (entrada pelo usuário e estados) e comportamentos (eventos e regras ligadas a apresentação) juntos segue o princípio básico da OOP, o que torna o trabalho mais simples e coeso. Tentar ir contra isso (ao estilo ActionForm e Action do Struts) pode te trazer muita dor de cabeça a médio-longo prazo.

Neste post do Neil Griffin, um dos autores do primeiro livro de JSF2.0, ele sugere alguns “rótulos” para os diversos tipos de managed beans que podem haver numa aplicação, e ainda por cima ele incita que seria uma boa prática trabalhar com vários managed beans por questões de SoC, baixo acomplamento etc.

De fato, devido ao modelo “pull” podemos ter managed beans atuando como componentes menores, mais reutilizáveis e mais orientados a objetos. Ter componentes (managed beans ou não) de granularidade fina colaborando para construção da página é algo bastante comum, e eu mesmo me utilizo muito disso. Mas não são destes tipos de componentes que falo, muito menos o Neil.

Eu, particularmente, não concordo com quase nada no post do Neil. Para mim ele se utilizou de argumentos isolados e vagos para defender sua idéia. Managed beans por sua natureza deveriam ser simples, contudo a abordagem do Neil, definifitivamente, vai contra tudo isso. Eu a considero um overkill, e ela torna qualquer aplicação web difícil de manter.

Bem, se dois ou mais managed beans relacionados -delimitados a um contexto- estão servindo para você e sua equipe, ótimo. Continue assim, não tem porque mudar. O framework (JSF) te permite isso, contudo eu tenho sérias dúvidas se essa abordagem vale a pena.

Conclusão

Este post estava em draft faz um bocado de tempo, mas a falta de tempo e a coragem não me permitiam finaliza-lo. Felizmente resolvi tira-lo do baú e posta-lo.

Tudo que comentei aqui está mais ligado a minha experiência e o que aprendi durante estes anos como desenvolvedor (e conversando com outros profissionais) do que eu pude encontrar em livros de JSF sobre o assunto. Existem muitos livros bons, assim como artigos em blogs e sites especializados sobre o assunto, mas nada melhor que a experiência do dia a dia para nos mostrar caminhos mais adequados de como solucionar determinados problemas.

Por mais longo que o post tenha ficado, eu ainda sinto que falta complementa-lo em alguns aspectos e pontos. Pois o que falei acima acaba te levando a aderir outras soluções não menos importantes, mas que já foram bastante citadas neste blog e discutidas em listas de discussão.

Entre os três tópicos abordados aqui eu ainda tenho algumas dúvidas quanto ao último, principalmente depois desta resposta do @edburns a minha pergunta no Twitter. Hoje minha opinião está mais para o lado “um managed bean é suficiente” por não ter encontrado respostas que me convencessem do contrário.

Enfim, como disse antes, se vários managed beans intrinsecamente relacionados estão resolvendo teu problema por algum motivo, ótimo! Continue assim. Se você tiver um tempinho e puder comentar sobre tua decisão eu ficaria grato.

Não existe segredo: desenvolvedores e designers precisam colaborar entre si

Durante o desenvolvimento “Enterprisey” de aplicações web temos dois papéis realmente importantes dentro da equipe: o desenvolvedor e o [web] designer. Cada um possui suas atividades bem definidas durante o desenvolvimento do software, mas em algum momento será necessário que eles sentem juntos e colaborem para definir os detalhes da GUI.

Eles não irão colaborar entre si para definir a identidade visual da aplicação [não que não seja possível], mas sim para acertarem os detalhes “baixo nível” da interface ou mesmo como definir melhor a experiência do usuário. No final das contas, eles podem discutir sobre css, javascript, tags de marcação XHTML ou uma melhor disposição dos componentes visuais.

E isso é comum com qualquer tecnologia para web, seja ela PHP, RubyOnRails, .Net ou mesmo Java.

Mas o que eu realmente não entendo é porque muitos profissionais (desenvolvedores, gerentes, designers etc) encaram que desenvolvedor e designer não precisam -ou mesmo não deveriam- discutir sobre o design da interface da aplicação.

O que difere a comunicação entre um desenvolvedor e um analista de negócios que tentam definir ou acertar detalhes sobre o modelo de domínio da aplicação, e a comunicação entre um desenvolvedor (ou analista) e um designer que tentam acertar detalhes da interface com o usuário?

Nenhuma! Não há qualquer diferença, eles conversam e colaboram entre si com a mesma finalidade: terem software funcionando e que agregue valor ao cliente.

O que leva tantos profissionais a pensarem que desenvolvedor e designer são “peças” isoladas durante o desenvolvimento do software? Um modelo em cascata, talvez. Por estarem trabalhando num processo fabril de fábrica de software, talvez.

Não sei ao certo o motivo, mas sei que uma boa parte da culpa está na “balela” que algumas empresas-de-três-letrinhas tentam empurrar sobre seus clientes e/ou desenvolvedores que utilizam suas tecnologias/ferramentas. Um bom exemplo disso é a tecnologia JSF, na qual temos a descrição abaixo dada pela Sun:

Ease-of-use being the primary goal, the JavaServer Faces architecture clearly defines a separation between application logic and presentation while making it easy to connect the presentation layer to the application code. This design enables each member of a web application development team to focus on his or her piece of the development process, and it also provides a simple programming model to link the pieces together. For example, web page developers with no programming expertise can use JavaServer Faces UI component tags to link to application code from within a web page without writing any scripts.

Por mais bonito que isto pareça ser, eu tenho o dever de alertar aos mais desavisados: isso dificilmente irá funcionar durante o desenvolvimento com JSF – para falar a verdade, eu acho muito dificil que qualquer tecnologia hoje em dia consiga prover tamanha separação de responsabilidade (entre designer e desenvolvedor) de forma transparente e produtiva.

Qualquer desenvolvedor web que se preze possui, ao menos, os conhecimentos mínimos sobre XHTML, css e javascript para entender e manter algum código escrito por outra pessoa ou mesmo por um web designer. Se você é um desenvolvedor web e não possui qualquer conhecimento sobre o que eu disse acima então já está mais do que na hora de você aprender.

Não subestimando os designers, pois eu conheço alguns muito bons, mas se levássemos essa separação de responsabilidades ao pé da letra você acha mesmo que eles conseguiriam desenhar excelentes interfaces utilizando apenas as taglibs dos componentes ou conjuntos de componentes JSF?

Alias, você acha mesmo que um designer teria produtividade ou conseguiria expressar sua criatividade limitado apenas a algumas dezenas de tags, por mais ricos que sejam os componentes, visualmente falando? Isso pode piorar ainda mais se este designer for obrigado a utilizar algum editor -com o qual ele nunca trabalhou- apenas por causa do suporte a code-completion para as tags dos componentes.

JSF é uma boa tecnologia, e por mais que ela nos forneça centenas de componentes, frameworks para templating de páginas e estes componentes possuam um sistema de skinning ainda assim no final das contas teremos XHTML (css e javascript também) gerado. Sendo, de duas, uma: ou o designer deve ter conhecimento sobre o código gerado pelos componentes ou ele deve ter conhecimento de como trabalhar com o suporte a skinnking dos componentes.

Qualquer que seja a opção acima, o designer estará com mais responsabilidades do que o necessário. Por isso é tão importante a interação entre um designer e um desenvolvedor para solucionar problemas decorrentes da tecnologia adotada.

Eu falo tudo isso por experiência própria, pois há alguns meses eu tive uma razoável dificuldade para aplicar o css, definido no prótotipo do sistema, nos componentes JSF da aplicação, atividade esta que deveria ser relativamente simples. Sim, o conjunto de componentes que eu utilizei suportava skinning, mas quem disse que isso é suficiente quando o XHTML gerado por alguns componentes mais complexos é totalmente diferente do XHTML escrito pelo designer?

Foram vários dias adaptando o css da aplicação e, ao mesmo tempo, discutindo e redefinindo com os designers alguns pontos do css do prótotipo para que no final tivessemos o resultado ideal. E com certeza eu não teria sucesso nesta atividade se não fosse pelos dois grandes designers da equipe, Carlinhos e Anderson, que sentaram ao meu lado algumas longas horas durante a semana para me ajudar.

Certamente que há casos onde não podemos contar com um designer na equipe, como:

  • projetos em que a presença do designer é inexistente na equipe e algum desenvolvedor precisa assumir mais este papel;
  • o designer faz parte da equipe, mas por algum motivo ele sempre encontra-se impossibilitado de interagir com ela nos momentos de maior necessidade;
  • ou nos piores casos, o protótipo da aplicação foi criado por outra empresa.

Para cada situação é possível chegarmos a uma solução milhares de vezes melhor do que apenas ignorar o problema de que não há um designer na equipe – mas não é esta a questão do post.

Enfim, é muita ingenuidade (ou falta de conhecimento) destas pessoas que acreditam que desenvolvedores e designers [ou quaisquer membros da equipe] não precisam colaborar entre si para alcançar um resultado ideal que agrade o cliente.