codificando.com

No mês passado, resolvi aplicar BDD em um projeto Java que estava desenvolvendo. Atualmente, existem ferramentas em outras linguagens que podem ser usadas para esse fim. Por uma série de razões, resolvi usar o JBehave para resolver o meu problema nesse projeto em específico (lembre-se, não existe bala de prata). Acontece que o JBehave é todo em Inglês e não dá suporte a i18n.

Quando comecei a usa-lo no meu projeto, logo percebi que usar em inglês não seria legal, pois o projeto só fazia sentido no Brasil e portanto o interessante era escrever os cenários em português. A partir desse momento, comecei a escrever algumas classes pra fornecer esse suporte. Felizmente, as classes Scenario e Steps permitem fácil extensão para resolver esse problema. Após as modificações necessárias, o arquivo de cenário passou a se chamar nome.cenario e o texto no arquivo ficou da seguinte forma:

Cenário: Nome em português do Brasil

Dado que eu quero rodar o Jbehave em português do Brasil
Quando eu usar o meu idioma
Então tudo deve funcionar perfeitamente

Feito isso, achei legal disponibilizar uma biblioteca para que outros desenvolvedores que precisem usar o JBehave no nosso idioma possam faze-lo de forma trivial. Nesse momento nasceu o projeto jbehave-br, extraido desse projeto e disponibilizado no GitHub aqui. O projeto é muito simples e pequeno, com o objetivo de resolver especificamente esse problema e nada mais.

Depois de criar o projeto, pervebi que seria simples modifica-lo para posteriormente suportar qualquer idioma. Em breve estarei liberando essa nova versão. Por conta disso o projeto talvez mude de jbehave-br para outro nome.

Alguns acontecimentos me fizeram refletir um pouco sobre a relação entre o desenvolvedor de software e os testes automatizados.

Muitas vezes parei pra explicar pra vários colegas de trabalho sobre a importância do assunto, fiz pair-programmming pra ensinar como se faz, em fim, investi muito tempo pra ajudar diversas pessoas com isso. Por incrível que pareça, tem muiiiiiita gente que ainda não entendeu muito bem. Portanto, resolvi classificar a relação entre o desenvolvedor e os testes automatizados em 5 níveis.

São eles:

1. Ignorante: Esse é o nível no qual o desenvolvedor não sabe direito o que são testes automatizados ou sequer ouviu falar sobre o assunto (acredite, ainda tem gente assim em pleno 2009).
2. Indiferente: Nesse nível, o desenvolvedor já sabe o que é, mas acha que essa prática/tecnica não serve pra nada. Apenas toma tempo e atrasa a entrega do produto que está sendo desenvolvido. A sensação dele é que sem os testes a entrega seria mais rápida (e a quantidade de bugs tb vão aparecer mais rápido).
3. Prequiçoso: Nesse nível eu encontro muita gente. É nesse nível onde a ficha caiu mas o camarada não toma coragem pra aprender a fazer os testes automatizados. Ainda existe o medo de perder muito tempo com essa prática e a preguiça impera, impedindo o progresso.
4. Decidido: Esse pra mim é o nível mais importante. É nessa hora que o desenvolvedor se dá conta que não dá mais pra desenvolver software sem testes automatizados. É nessa hora que o cara pensa: “como eu pude desenvolver sem testes até hoje?”. É nesse momento que inicia-se o aprendizado.
5. Profissional: Nesse nível, o desenvolvedor já não se sente mais confortável desenvolvendo sem testes automatizados. Desenvolver sem testes o incomoda profundamente. Nesse momento o mesmo está maduro quanto a importância dos testes e a aplicação na prática. O mesmo começa a se tornar um evangelista para os demais desenvolvedores e sempre que pode, fala sobre o assunto. Nesse momento o desenvolvedor pode realmente dizer que é um profissional, pois hoje em dia não se admite mais desenvolver sem ter testes automatizados que garantam qualidade daquilo que se desenvolve.

Em qual nível você está?

Amanhã estarei presente no Rails Summit Latin América em São Paulo.

O Evento promete ser bem legal, principalmente por ser o primeiro evento de Rails desse porte a ser realizado aqui no Brasil (se não me engano, rs).

Espero que esse evento ajude a alavancar ainda mais o desenvolvimento Ruby/Rails aqui no Brasil e que em breve esse mercado esteja tão aquecido quanto o mercado de Java.

Até amanhã então

Uma discussão que sempre vem a tona no forum do GUJ e em conversas entre colegas de trabalho, é sobre o uso do pattern TO/DTO (Antigo VO, que hoje em dia significa outra coisa). Eis o trecho do livro Core J2EE Patterns:

Transfer Object

Problem
You want to transfer multiple data elements over a tier.

Forces

• You want clients to access components in other tiers to retrieve and update data.
• You want to reduce remote requests across the network.
• You want to avoid network performance degradation coused by chattier applications that have high network traffic.

Solution
Use a Transfer Object to carry multiple data elements across a tier.

O Pattern Transfer Object, foi criado para solucionar os problemas dos Entity Beans (EJB 2.x), quando retornados para outro TIER, geralmente a apresentação, pois geralmente ficam em JVMs separadas. Quando você tenta retornar um Entity Bean, o que é retornado na verdade é um Stub para acesso ao mesmo. Quando são invocados os Getters deste, é aberto uma conexão de rede para cada invocação. Isso é extremamente custoso, gerando um overhead extremamente desnecessário.

Bem, mas nosso papo é tradução certo?

INI-UPDATE: Consegui o livro em português com um colega e estou adicionado a tradução em português também.

Vejamos a tradução para o português:

Transfer Object

Problema
Você deseja transferir diversos elementos de dados sobre uma camada.

Forças

• Você deseja que os clientes acessem componentes em outras camadas para recuperar e atualizar os dados.
• Você deseja reduzir as solicitações remotas ao longo da rede.
• Você deseja evitar a degradação do desempenho da rede causada pelas aplicações muito ruidosas que têm alto tráfego de rede.

Solução
Use um Transfer Object para enviar vários elementos de dados por uma camada.

O leitor atento perceberia que o segundo e terceiro item da seção Forças fala de tráfego de rede e degradação do desempenho da mesma.

FIM-UPDATE

Acontece que, o termo TIER, foi traduzido erradamente no livro em português para camada. O mais correto seria camada física ou nó. Em Java isso pode ser considerado simplesmente “em uma outra JVM”. Essa tradução gera confusão a todo momento. Se você conversar com 10 desenvolvedores, vai perceber que a maioria acredita que TO/DTO pode/deve ser usado entre LAYERS (i.e. camadas lógicas, usadas apenas para organização do software). Eis um grave problema de tradução, pois uma grande parte não sabe a diferença entre LAYER e TIER, e o uso do Pattern dessa forma se mostrou uma solução sem sentido, conforme diversas discussões no próprio GUJ.

Outro grave problema recorrente é a tradução dos livros de Patterns. Pegue por exemplo o PEAA traduzido e veja o Pattern Active Record. O nome do Pattern foi traduzido para Registro Ativo. Parece piada, considerando que um dos maiores valores de um Pattern é a criação de um vocabulário comum.

Em fim, existem diversos outros exemplos ruins, e só quem perde com isso é o leitor.

Mas nem tudo está perdido. Existem sim traduções bem aceitáveis, porém em quantidade extremamente reduzida e demoram a sair. Você está disposto a esperar? Não acha melhor comprar o livro em inglês mesmo?

Mas se eu não domino o inglês?

Sinto informar, mas você vai ficar refém de boas traduções, isso quando tiver tradução. Sem contar os podcasts, como por exemplo os videos disponibilizados no InfoQ. Na verdade, muita coisa não tem tradução e nem vai ter, isso é fato.

Esse cenário serve pra reforçar a idéia de que o inglês na área de TI é fundamental para o profissional se manter atualizado, visto que existem livros que não são traduzidos, e os que são, ou a tradução é horrível, ou demora muito para ser traduzido após o lançamento da versão original.

Mesmo que o cenário mude, ainda assim tem muita coisa que você estará perdendo. Quem sabe um emprego no exterior?

No último fim de semana (13 e 14 de junho/2008), participei com alguns amigos do Workshop de Modelagem ágil e DDD promovido pela Fratech em São Paulo.

O Workshop foi bem interessante, abordando temas atuais e de extrema importância no conhecimento do Desenvolvedor de Software.

No primeiro dia, o foco foi bastante em FDD, M3 e Agile Draw. Foi bem legal esse primeiro dia, pois eu experimentei algumas técnicas que nunca havia tentado. Confesso que não simpatizei muito com a modelagem com as figurinhas, nem muito com a FBS, mas eu vou pensar mais sobre o assunto e tentar me aprofundar um pouco pra tirar melhores conclusões.

Da esquerda pra direita: Colega de verde(rs), Gustavo, Eu, Colega de Branco(rs)

No segundo dia, o foco foi todo vontado para Domain Driven Design e UML em Cores. Foi bem interessante, pois o assunto tem um hype nos dias de hoje e é um assunto bastante motivador também.

A técnica de UML em Cores me ajudou um pouco a identificar algumas coisas em Model Driven Design, mas ainda assim, preciso testar mais pra definir se usarei essa técnica.

No mais gostaria de dar os parabéns ao Felipe Rodrigues e o Manoel Pimentel pelo evento que foi muito legal e tenho certeza que surgirão outros.

Da esquerda pra direita: Adndré, Eu, Felipe, Gustavo e Manoel

O unico problema é ter que se despencar do Rio de Janeiro toda vez, pois aqui estamos meio carentes de coisas do tipo, exceto pelo fato que as ultimas reuniões do RioJUG foram excelentes.

Na segunda-feira passada, tivemos uma palestra do Fábio Kung sobre JRuby on Rails no RioJUG. Basicamente foi um repeteco da palestra do Falando em Java 2008, a qual estive presente no dia 18/05 passado.

A palestra foi extremamente importante para abrir os olhos de muita gente que acha que Java vai ser Mainstream pra sempre. Pelo que tenho percebido, o tempo de Mainstream de uma linguagem tem diminuído bastante nos últimos tempos. Antigamente uma lingagem ficava na moda por muito mais tempo que hoje.

Em fim, voltando a palestra, foi bem interessante ver uma visão arquitetural de alto nível do GUJ 3.0, observar as escolhas das gems, o problema com as gems nativas e os contornos utilizados.

A escolha de rodar o Ruby na JVM, foi também um fator que foi muito falado durante a palestra. Os fatores principais foram a questão do compartilhamento de sessão entre os nós e o empacotamento do JForum junto na mesma aplicação, sem a necessidade de mágicas para não precisar de 2 logins.

Um fato que me surpreendeu até (já no Falando em Java 2008), foi quando o Fábio disse que a implementação JRuby está sendo considerada a implementação com melhor performance. Isso é muito legal, o que mostra o esforço grande para se obter alternativas à linguagem Java. E o melhor de tudo foi saber que já dá pra rodar o bichinho no Jetty, gerando a mesma produtividade encontrada na dupla Java/Jetty. O trabalho do Fábio foi tão fantástico no jetty_rails, que no RailsConf2008, Jeremy Kemper incluiu o jetty_rails em seu Keynote. O próprio Fábio falou sobre isso.

Pra concluir, apesar do JRuby on Rails e das novas oportunidades que irão surgir, o que mais me deixou feliz foi ver um projeto brazuca fazendo sucesso internacionalmente, no maior evento de Rails da atualidade.

Ontém tivemos a reunião mensal do RioJUG com a palestra de REST do Bruno Pereira. Mas pera lá, o que a Mundo Java tem a ver com a história? rs. Bem isso eu conto mais pra frente.

A palestra foi bem interessante e apesar de já conhecer REST, agente sempre aprende alguma coisa, sempre. Por isso que eu vou a diversos eventos, como por exemplo o Falando em Java 2008, que tinha algumas palestras que teoricamente não iriam acrescentar muito a mim, mas tem sempre alguma coisa que o palestrante fala que agrega, e as vezes muito.

A palestra do Bruno Pereira foi bem legal, explicando bem os conceitos do estilo arquitetural, falou um pouquinho do framework Jersey e deu bons exemplos de código. Quem não foi perdeu …

E a Mundo Java, heim? Bem vamos lá.

Quando saia da empresa para ir ao evento, comentei com um amigo o fato de eu nunca ganhar nada nesses sorteios de brindes que tem nos eventos (pronto, acabou o suspense ). No Falando em Java 2008 eu queria ter ganho o Nintendo WII, mas infelizmente não deu ). Então, voltando ao papo que eu estava tendo com meu amigo do trabalho, comentei que eu queria ganhar a assinatura da Mundo Java, pois é a publicação de Java que eu gosto mais aqui do Brasil.

O engraçado do sorteio é que o Guilherme Chapiewski deixou a assinatura Mundo Java por útimo e eu fiquei naquela espectativa por nunca ganhar nada nesses sorteios.

E o resultado foi …

QUE EU GANHEIIIIIIIIIIIII

Espero que agora que eu ganhei alguma coisa pela primeira vez eu consiga ganhar novamente em outras oportunidades.

Nos últimos meses, tenho ajudado a empresa onde trabalho a escolher um fornecedor para implantar SOA na casa. Infelizmente, não nos está autorizado a fazermos nós mesmos. Os fornecedores escolhidos pela empresa para nossa avaliação, são quase todos fornecedores [A-Za-z]{3}.

Tenho percebido de maneira geral que a maioria desses fornecedores não conhece muito do que nos tem apresentado. Uma simples pergunta sobre Message Broker e ninguém, absolutamente nenhum dos fornecedores soube responder direito. Na verdade, alguns deles confundiram com o produto Message Broker da IBM e outros com ESB.

Teve uma outra empresa, que não posso mencionar o nome por motivos óbvios, que conseguiu vender um projeto SOA aqui dentro, que não era nada mais que instalar um ESB, um servidor de processos e fazer um sisteminha de referência e só !!!! O Pior de tudo é que ganharam uma grana preta com isso.

O fato é que está muito difícil opinar sobre qual fornecedor a empresa deve confiar o “projeto” SOA, e o cenário atual, com a pressão vinda de cima pra baixo para implantar alguma coisa de SOA, só porque está na moda e sem as vezes nem entender o que é, faz como que muitos fornecedores consigam essa maravilhosa TETA pra mamar nas grandes corporações.