Hello Roo

Durante o segundo semestre de 2009 tomei conhecimento a respeito da iniciativa de produtividade da Springsource conhecida como Spring Roo. Posteriormente, tive um contato muito convincente com essa ferramenta durante a passagem de Rod Johnson no Brasil no evento TDC 2009.
Atualmente utilizo essa ferramenta em um projeto, e espero compartilhar algumas experiências no Casual Class de Spring, dia 26 fev 2010. Este evento marcará o lançamento do Spring Brasil User Group.

 O que é Spring Roo ?
 - Roo é uma ferramenta Open Source de produtividade Java, baseada em
    - uma plataforma modularizável capaz de evoluir através de add-ons
    - um terminal de comandos, chamado Roo Shel.
 - Sem dúvida o principal atrativo de produtividade do Roo é a geração de código. Justamente por utilizar uma plataforma modularizável não podemos dizer que o Roo é apenas um gerador de código, e entendo que muitas etapas do ciclo de vida de um projeto Java poderão se beneficiar dessa ferramenta. Por exemplo, Roo já oferece suporte para automação de testes.
 - Roo representa uma evolução em relação a outros geradores de código, ao suportar desenvolvimento interativo, onde o código gerado (camadas web, persistência e testes) não é definitivo. Em outras palavras, através do Roo, o código gerado evolui automaticamente, junto com o modelo de entidades.
 - A distribuição atual do Roo (1.0.1):
    - fornece geradores de código para aplicações web baseadas em Spring MVC 3.0, AspectJ e nos padrões Bean Validation e JPA
    - fornece geradores de testes JUnit e Selenium
    - é baseada no Apache Maven
 - Além do terminal de comandos (Roo Shell) há o suporte no IDE SpringSoruce Tools Suite (STS), onde encontramos um Roo Shell embutido.
 - Outro destaque é o grau de dependência introduzido: mínimo. Um projeto iniciado com o Roo não precisa utilizá-lo eternamente, sendo razoavelmente simples continuar o projeto desenvolvendo "na mão", sem utilizar o Roo Shell.

O que não é Spring Roo:
 - Roo não é um framework: um projeto criado em Roo não necessita de nenhuma biblioteca Roo em tempo de execução. Sim, existem annotations @Roo, entretanto estas possuem retenção no código fonte, e servem para orientar o gerador de código do Roo e o AspectJ.
 - Roo não determina uma arquitetura para seus projetos: como foi dito a distribuição atual gera aplicações Spring MVC / JPA, mas não tardatá surgir add-ons para outras arquiteturas (a Springsource tem demonstrado um interesse muito grande em add-ons para GWT).
 - Roo não é a salvação para desastres iminentes em projetos, onde pelo menos dois dos seguintes fatores estão presentes: requisitos mal especificados / cronogramas e orçamentos surreais / equipes de desenvolvimento inexperientes. Suspeito que, nesses casos a salvação não se encontrá em uma ferramenta, em um framework ou em promessa alguma de mágica tecnológica.

Gostinho de Produtividade
No vídeo abaixo, Massimiliano Dessi (Spring Framework Italian Group) demonstra a construção de um projeto com o Roo Shell.
Notem que o vídeo utiliza uma versão antiga (Milestone 2) do Roo, e a versão atual (Release) possui vários comandos simplificados, como veremos a seguir.

Preparando seu Hello World

- JDK 6
- Apache Tomcat 6
- Apache Maven 2.0.9 ou superior
   -  http://maven.apache.org/index.html
   -  http://docs.codehaus.org/display/MAVENUSER/Getting+Started+with+Maven
- instale o Roo 1.0.x com Roo Shell (terminal de comandos)
  - download em http://www.springsource.com/download/community?project=Spring%20Roo
  - descompacte o zip em um diretório de sua preferência
  - crie uma variável de ambiente ROO_HOME, apontando para o diretório de instalação
  - ajuste sua variável de ambiente PATH, acrescentando o caminho ROO_HOME/bin

Criando um projeto via terminal de comandos
Como exemplo criaremos um cadastro de bookmarks. Na primeira execução do Roo o Maven será acionado para fazer diversos downloads de bibliotecas - uns 10 minutos de paciência.
- crie um diretório (ex: roo_teste1) posicione-se (cd roo_teste1)
- inicie o Roo Shell (aqui começa a diversão), digitando roo.sh ou roo.bat

Dois comandos iniciais no Roo Shell: help e hint. O comando help exibe todos os comandos disponíveis no shell. Já comando hint fornece uma ajuda contextualizada, sugerindo o que você pode fazer em determinado estágio do seu projeto.
Não deixe de utilizar autocomplete do Roo Shell, que é ativado com a tecla TAB no terminal de comandos (ou com CTRL+SPACE no STS).
Digite no Roo Shell os seguintes comandos (em negrito).
Para criar o projeto e definir a esturura de pacotes principal:
project --topLevelPackage globalcoders.bookmarks
Para definir a camada de persistência:
persistence setup --database HYPERSONIC_IN_MEMORY --provider HIBERNATE
Para definir uma classe de entidade, para as categorias de bookmarks (o símbolo ~ significa o pacote top level)
entity --class ~.model.Categoria
Para definir um campo ná última entidade:
field string --fieldName nome
Mais uma entidade, para os bookmarks:
entity --class ~.model.Bookmark
Campos, com restrições e relacionamentos:
field string --fieldName url --sizeMin 5 --sizeMax 200 --notNull
field reference --fieldName categoria --type ~.model.Categoria
field date --fieldName dataCadastro --type java.util.DatePara gerar a camada web, com controllers Spring MVC e views .jspx e Tiles:
controller all --package ~.web
Para compilar e gerar um .war (via Maven):
perform package
Para adaptar o projeto para o Eclipse:
perform eclipse
Para fechar o Roo Shell:
quit

Vamos executar a aplicação, colocando o Tomcat no ar e fazendo o deployment via Maven.
No terminal de comandos, com o Roo Shell fechado (quit), execute:
mvn tomcat:run
No browser de sua preferência: http://localhost:8080/bookmarks

Onde estão os métodos das Entidades e Controllers ?
Você pode conferir o código gerado na pasta src/main do seu projeto.
Ao inspecionar os arquivos Categoria.java e Bookmark.java verificamos que não existem métodos get/set ou toString().
E inspecionando os contollers CategoriaController.java e BookmarkController.java não encontramos métodos.
As implementações de tais métodos ocorrem através de um mecanismo suportado em AspectJ chamado Inter-type declarations (ITD). Ao navegar nos diretórios onde se encontram os arquivos .java das entidades e controllers encontraremos arquivos com a extensão .aj que implementam os métodos em questão.
Uma dica importante: os ITDs são gerados automaticamente pelo Roo e não devem ser editados. É possível editar os arquivos .java - no  vídeo do Massimiliano o método toString de uma das classes foi redefinido em um arquivo .java.
Outra dica: utilizar a IDE (baseada no Eclipse) Springsource Tool Suite 2.3.0 ou superior pois suporta AspectJ, e consequentemente os ITDs.

Sugestões para experiências adicionais
 - Edite diretamente o arquivo Bookmark.java, adicionando um atributo String descricao com annotations @Size e @NotNull (da especificação Bean Validation, JSR 303). Execute o Roo Shell novamente e observe as mensagens geradas. Saia do Roo Shell, e execute o tomcat (mvn tomcat:run) e via browser verifique o que mudou no formulário de criação de Bookmarks.
 - Em Categoria.java defina um método toString ao seu gosto  e remova a annotation @RooToString. Que mensagem surge no Roo Shell após salvar este arquivo código fonte ? Execute novamente o tomcat e verifique o combo box de Categorias no formulário de Bookmarks;
 - No Roo Shell digite finder list --class ~.model.Bookmark. Ainda no Roo Shell digite finder add findBookmarksByDataCadastroLessThan. Execute o tomcat e veja o que mudou no menu da aplicação.

Onde encontrar mais informações:

- Muitos links em http://forum.springsource.org/showthread.php?t=71985
- Não perca o Casual Class da Globalcode
- Acompanhe meu blog

Renato Bellia
http://twitter.com/renatobellia
http://notasingleshot.blogspot.com

Desenvolvimento Softwares Vs. Construção Civil

Eu sei que a metáfora da construção civil tem sido utilizada para referenciar modelos mais rígidos, porém, analisando de um novo ponto de vista, o de um pedreiro, eu vejo uma analogia interessante. 

Já são conhecidas as inúmeras comparações entre "engenharia" de software e engenharia civil: pilares da arquitetura Java EE, diagramas como planta e código como a casa construida, a função de arquiteto, engenheiro e a famosa frase que o programador é o pedreiro do software... Tudo isso nos perseguiu muito nos últimos 20 anos e muitos dos profissionais de T.I. não gostam dessas comparações.

O fato é que influenciado por tais comparações, há exatamente 9 anos atraz quando tinhamos uma equipe enxuta e dinâmica de desenvolvimento, eu costumava dizer: "Vamos fazer uma imersão em uma obra e entender quais são as razões de uma casa ser levantada aparentemente com menor esforço organizacional e corportativo que um software". Nunca fizemos.

Porém refletindo recentemente achei que isso vem mais ainda a tona com toda a onda de metodologias ágeis e resolvi escrever mais uma paródia:

"Certa vez um experiente desenvolvedor de softwares tirou férias para reformar sua casa de praia. Sendo sua personalidade um mashup de geek com work-a-holic, não parava de pensar em métodos de construção de softwares, afinal de contas aquele cenário de reforma era bastante sugestivo.

Neste dia a obra seria iniciada e tal desenvolvedor já havia passado as principais especificações da reforma: abrir uma nova porta de passagem, pintar, reformar madeiras e colocar piso em uma nova área.

Preocupou-se o dono da casa com o fato do orçamente ter tido como base tão poucas especificações: ninguém perguntou a cor da tinta a ser usada, ninguém perguntou se o piso seria simples ou porcelanato, mas enfim, o valor era justo.

As 8:00 chegou a equipe pronta para trabalhar, e o "pedreiro mais experiente", reuniu todos rapidamente (e em pé), e definiou como seria o andamento da obra naquela semana e quais seriam os principais objetivos.

Em 15 minutos todos estavam trabalhando.

E o dono da casa continuou a observar o trabalho de pessoal, em especial chamou a atenção que a quebradeira para abrir a nova porta estava sendo feita por dois pedreiros que se revezavam.

Religiosamente eles pararam de trabalhar as 17:00 horas.

Algumas dúvidas surgiram no dia seguinte, mas como o proprietário estava sempre lá, rapidamente puderem resolve-las.

E assim a obra foi seguindo até sua conclusão em 3 semanas: toda semana definiam o que seria feito, no término da semana eles faziam um pequeno churrasco na sexta depois do expediente, trabalhos pesados ou complexos eram feitos em duplas sempre, não havia alguém que simplesmente coordenasse tal processo. Tinha sim um pedreiro "master" que era um líder nato e carismático.

O desenvolvedor de softwares e dono da casa ficou satisfeito com o resultado apesar dos pequenos desvios (que alguns ele mesmo causou) e também uma diferença no valor cobrado pelos serviços.

Depois de 3 semanas cuidando da obra, quando voltou para sua empresa na semana seguinte ele estabeleceu novas regras:

• Vamos fazer uma reunião no começo da semana para definir as funcionalidades que queremos prontas no final dela;
• Se atingirmos esta meta, vamos fazer um churrasco, opa, na av. Paulista não rola. Vamos tomar sorvete por conta da empresa.
• Todo software complexo será programado por dois;
• Teremos um desenvolvedores mais experiente e com mais espirito de liderança que conduzirá a equipe
• O cliente deverá sempre estar disponível para tirar nossa dúvidas
• Todos trabalharão apenas 8 horas por dia

E para finalizar ele refletiu: se isso der certo, vou ter que dar um nome.

FIM.

Vinicius
http://twitter.com/vsenger
http://program-me.ning.com
http://www.eletronlivre.com.br

Spring Brasil User Group nasceu saudável em 2010

O Spring Brasil User Group nasceu forte e saudável junto com o ano novo e, com menos de um mês de vida, já conta com mais de 100 membros. Venha participar também desta comunidade! Se ainda não é um membro, clique aqui!.

Este grupo é uma rede social dedicada a fortalecer e fomentar a comunidade de usuários e desenvolvedores das tecnologias relacionadas ao Spring Framework.

Fórum, Blog, Notícias e Chat <=> Comunidade

O Spring Brasil User Group, carinhosamente apelidado de SBUG, está baseado na infraestrutura do site de redes sociais chamado Ning e, por isso, disponibiliza os mecanismos de fórum, blog, publicação de fotos e vídeos, divulgação de eventos e troca de mensagens entre os integrantes do grupo. Portanto, esta rede social permitirá a todos os participantes enviar dúvidas ou abrir discussões através do fórum, escrever notícias ou mini-tutoriais sobre Spring no blog e acompanhar as novidades e possíveis reuniões virtuais ou presenciais do grupo.

De maneira tímida alguns membros começaram a escrever no fórum e no blog do SBUG. Alguns outros membros escreveram comentários nas postagens. Mas as ferramentas da comunidade estão abertas para qualquer um contribuir. Se desejar, coloque lá as suas dúvidas sobre o framework, compartilhe a sua experiência em forma de tutoriais ou responda as dúvidas.

Casual Class #10 - Spring Platform

Através de um grande apoio e incentivo da Globalcode realizaremos uma reunião presencial do SBUG em formato de Casual Class no auditório da Globalcode em São Paulo. Neste Casual Class abordaremos a plataforma da SpringSource e não somente o produto mais famoso Spring Framework. Este evento será muito especial, reunindo diversos profissionais com experiência prática. Contaremos com a participação de membros do Spring Brasil User Group e instrutores da Globalcode que farão uma apresentação do framework, o lançamento oficial do grupo, uma apresentação sobre a integração do Spring com o cenário de Cloud Computing, uma apresentação da ferramenta de produtividade Spring Roo e as ferramentas de produtividade como SpringSource Tool Suite, tc Server e dm Server. As inscrições estão abertas através do site www.casualclass.com.br.

Marque na sua agenda: 26 fevereiro 2010 de 19:00 a 22:30 no auditório da Globalcode em São Paulo. Exporte agendamento para Outlook ou iCal (.ics).

Spring 2.5 e Cloud Foundry

Recentemente disponibilizei para download, através do SBUG, uma aplicação web simples e completa usando Spring Framework, JSF, Richfaces e JPA. Os detalhes técnicos desta aplicação foram apresentados num artigo no periódico Java Magazine com o titulo Criando uma aplicação web com Spring. Outros detalhes sobre esta aplicação e link para download podem ser encontrados clicando aqui. Esta aplicação será evoluída para aplicar os novos recursos do Spring Framework 3.0 e será apresentada no Casual Class agendado. Em breve, o código fonte desta nova versão estará disponível para download.

Por enquanto (até 05/fev), a aplicação web de exemplo baseado no Spring Framework 2.5 estará disponível para acesso online na plataforma de computação em nuvem da SpringSource e, chamada de SpringSource Cloud Foundry, acessível através de um endereço disponibilizado pela Amazon Web Services (Elastic Cloud Computer): Exemplo Globalcode Casual Class Spring 2.5.

Para outros detalhes leia o post no SBUG: Aplicação web com Spring 2.5 no Cloud Foundry.

JAVA + PIZZA + CERVEJA + VOCÊ = CASUAL CLASS

Venha fazer networking, trocar conhecimento, conhecer outros membros do grupo além de se divertir bastante no Casual Class!


Aguardamos a sua presença no Spring Brasil User Group! Venha participar, contribuir, fortalecer e fomentar a comunidade de usuários do Spring Framework no Brasil.

By Spock
http://blog.spock.com.br/
http://twitter.spock.com.br/
http://springbrasil.ning.com/

Sun, Oracle, JavaOne e mais algumas páginas desta longa história...

Desde abril de 2009 estamos acompanhando todo o processo de aquisição da Sun pela Oracle, que aconteceu muito perto da crise, e no ambiente de negativismo da crise. Parte da comunidade, principalmente os mais velhos tinham um relacionamento de admiração à Sun e e aos engenheiros da Sun. E tantas carreiras e mesmo famílias sendo sustentadas pelo capital gerado ao redor da tecnologia Java. É natural sentir um pouco de medo do impacto deste negócio milionário:

O que a Oracle vai fazer com o Java? Vai continuar OpenSource ? Vão mudar a política de distribuição da JVM ? E o JCP está seguro ? Haverá impacto negativo para o Java ? E para as outras ferramentas e tecnologias da Sun ? Com esta enorme mudança de poder dentro da comunidade Java como as outras empresas irão reagir ?

Foi realizado hoje um WebCast gratuito "Sun Oracle Strategy", com quatro horas de duração, bastante marketing, muitos adjetivos, resolvi resumir os fatos mais importantes para a nossa comunidade nos com uma seleção de tweets das pessoas que estavam ouvindo a conferência como eu, por isto, fiz uma seleção de tweets em ordem cronológica que fazer a cobertura do Web Cast de hoje.

Antes do inicio do WebCast:

@jasondlee: Shaved. Showered. Wearing my Sun shirt. I'm ready for whatever today brings. Please make it good news!

Primiras notícias:

@edburns:  Keep the Sun brands: Java, Solaris, Sparc.

Apresentação de Charles Philps, presidente da Oracle:

@fribeiro1: People like Philips bother me very freaking much they can talk for hours and say nothing.
@edburns:  here comes the open standards. Listen for JCP?
@arungupta: Charles Phillips: "Committed to investing in the Java community, we have a vested interest to see Java is successful"
@fribeiro1: Now it is when they bring customers who say there are terribly excited just so to get renewal discounts. 
@edburns: exposure to the defense industry. The first customer on stage is from atomic weapons
@edburns: Nice to see a slide that says: "We're Hiring".
@fribeiro1: Of course they are hiring, they must have lost a lot of engineers along the way. @edburns:  Charles Phillips gives a not-so-subtle shout out to the Obama jobs program.
@fribeiro1: Vai ter JavaOne no Brasil
@yarasenger And OracleWorld is in setember... RT @mr__m: Now it makes sense: JavaSE7 deadline'd been moved to Sep2010; JavaOne has been moved to Sep2010
@binkyscave @yarasenger JavaOne will happen the same time as Oracle One but will be in three hotels and not in the Moscone Center
@edburns: I'm very glad they are keeping the JavaOne brand. It would have been silly to scuttle that brand.

...tempo depois:

@fribeiro1: Loosing my faith that they will answer any of the questions developers have.
@renatobellia @joshbloch: Been listening to Oracle/Sun strategy webcast for the past two hours. I still haven't a clue as to the future of Java.

Mais notícias: 

@fribeiro1: Good thing they will merge HotSpot and JRockit.
@fribeiro1: GlassFish remains Java EE RI and for tactical applications, Weblogic remains strategic Enterprise Application Server
@fribeiro1: Glassfish survived, but only as the RI, Oracle will continue to push WebLogic.
@edermagalhaes:  "javafx to rich internet application"
@jasondlee OpenOffice gets continued support and development. Excellent news!
@rafanunes  Unifying JSE and JME! WOW!!
@arungupta: NetBeans continues as light-weight IDE for Java developers, focus on Java EE 6, ME, and Scripting #oraclesun
@fribeiro1: NetBeans survived as a "lightweight" IDE, whatever it means to Oracle.
@fribeiro1: Oh, I got it, "strategic" means "actual portfolio".
@fribeiro1: All open source SOA from Sun needs to be forked now.

Piadinha:

@rafanunes: Uma coisa é certa, agora vai todo mundo trabalhar sério, de terno e gravata.....hehehe
@binkyscave: @yarasenger I am refusing to wear a suit. Have at least six in my closet. They come out for funerals and weddings. Ok, maybe it's the former
@fribeiro1: MySQL and OpenOffice survived, god knows how.

Mais notícias:

@jasondlee Nice! The SunRay also gets some loving. Those little machines are FANTASTIC!
@fribeiro1:Oracle just increased my confidence that open source is the best model for our industry.
@jasondlee: VirtualBox will be part of the Oracle VM family.

Larry's presentation in the end:

@fribeiro1: Nothing really to say about Larry's words.

Ainda tem muita gente twittando, então, quem quiser saber mais busque #sunoracle.

Nem tudo foi definido neste WebCast de hoje, por isto separei outros vários links e fatos interessantes que foram publicados recentemente: 

• Notícia da aprovação da União Europeia: 
  
• A união europeia ainda não havia aprovado a aquisição por causa do possível monopólio em relação a banco de dados da Oracle na aquisição da Sun, que era dona do MySQL. 
• Se a compra fosse vetada haveria pelo menos duas possibilidades: Vender o MySQL para outra empresa, ou cancelar a aquisição da Sun, o que poderia ser um problema enorme segundo a especulação da comunidade.
• Página atualizada com principais links e documentos e a notícia da aprovação pela União Europeia: http://www.oracle.com/us/sun/index.htm
• Blog do James Gosling: 
• O James Gosling sempre gostou de ilustrações com o Duke, e com a finalização do projeto de aquisição não poderia ser diferente, ele se expressou com uma imagem, que sugere a morte da Sun. O que não deixa de ser uma realidade. Mas, vale reforçar, não é a morte do Java.
• http://blogs.sun.com/jag/date/20100121
• JavaOne 2010 :
• Esta publicação foi surpreendente, quando fui no SunTechDays ouvi uma pessoa falar que haveria JavaOne, e logo depois outras pessoas negaram, e o principal argumento era, não foi aberto o processo de submissão, portanto não haverá JavaOne. Felizmente, parece que haverá JavaOne, em junho no Moscone Center. 
• Como mostra o agendamento do Moscone Center em São Francisco : http://www.moscone.com/site/do/event/view?nav.type=0&nav.filter=1005&nav.base=0911&id=440
• Carta que dizem ter sido enviada por Jonathan Swartz para todos os funcionários:
  
• Muitas pessoas têm criticado muito o Jonathan Swarts e questionado a sua competência dentro da Sun, eu particularmente não me sinto capaz de julgá-lo, mas acredito que ele fez pelo menos uma coisa importante: transformou o Java em OpenSource.
• Eu gostei muito do discurso que ele fez no JavaOne sobre a coragem de um líder, a coragem de realizar um novo projeto, investir em uma ideia que pode dar certo... ou pode dar errado. 
• Confesso que também gostei da carta, que dizem ter sido enviada por ele para os funcionários: http://digitaldaily.allthingsd.com/20100121/sun-ceo-go-oracle-internal-memo/
• Últimas palavras do Scott McNealy no seu blog
• http://news.cnet.com/8301-30685_3-20000017-264.html
  

Conforme já publiquei no post "Muitas vagas, otimismo e sensação de reaquecimento da economia", eu estou otimista com  a plataforma Java e Java EE 6 que chega madura e finalizada marcando uma história de sucesso da Sun, e valorizando ainda mais a história da Oracle.
Muitas destas notícias chegaram até mim pelo Twitter (Twitter: porque? como? quem?) :
Fernando Ribeiro, Arun Gupta, Jason Lee e Ed Burns.


Seguindo a mesma linha dos "disclamers" no inicio do WebCast: Tudo o que está escrito aqui é apenas uma coleção de dados da internet, e não me responsabilizo pela informação, tem alguma coisa errada ? Me fala que eu corrigo. Foi apenas uma forma de tentar persistir esta informação que está jorrando no twitter, que por sua vez é "volátil".

Desejo sucesso e comprometimento aos que ficam na Oracle, bem como para aqueles que não querem ficar.
[]s
Yara
http://twitter.com/yarasenger
http://twitter.com/globalcode
http://twitter.com/globalcode/globalcode-team

A terceira camisa: os exemplos estão virando fashion

Um olhar diferente sobre 3 formas de expressar o comportamento esperado de um sistema:

requisitos, testes e exemplos. Temperadas por uma metáfora esportiva.

Neste feriado, li uma matéria na revista Veja sobre as terceiras camisas dos clubes de futebol, que chamou minha atenção.

Os clubes de futebol sempre tiveram uma camisa oficial. Sempre houve também a camisa reserva, tradicionalmente usada quando o time não tem mando de campo e o padrão da camisa é parecido com o do rival. Mas, de um tempo para cá, a estrela é uma terceira camisa alternativa, utilizada para comemorar algum fato relevante: o centenário do clube, a obtenção de um título, a contratação de um craque ou, no fim das contas, para alavancar as vendas dos itens oficiais do clube. Camisas corinthianas listradas com roxo, torcedores da Lusa com uma cruz metaleira, cruzeirenses em degradé: campeões de vendas nas lojas esportivas.

Assim, algo ao qual que a maioria não dava muita importância (a existência de uma terceira camisa) virou um item fashion. De repente, descobriu-se que servia para alavancar a imagem e as finanças do clube, e passou a ser algo pensado, e se começou a descobrir o que funciona e o que não funciona: como deve ser o design, em que ocasiões o time deveria usar, quando lançar a nova camisa.

Afinal, eu não sou tão interessado assim em futebol ou em marketing esportivo, e o assunto deste blog deveria ser desenvolvimento de software. Acontece que tenho o vício de procurar metáforas para poder usar em sala de aula, e percebi uma analogia com a evolução na forma em que especificamos funcionalidade em sistemas de informação. Requisitos, testes e exemplos são formas diferentes de descrever o comportamento dos sistemas, e podemos associá-los a cada modelo de camisa.

Requisitos

Os requisitos são a camisa oficial. A partir do trabalho de Ivar Jacobson, como formalizar esses requisitos mereceu muita discussão: falava-se em desenvolvimento baseado em casos de uso. A notação de diagramas de casos de uso, desde o início, fez parte das notações de modelagem da UML. Quando foi proposto o processo unificado, diagramas e documentos de caso de uso passaram a fazer parte do conjunto de artefatos sugeridos (ou melhor, prescritos). Discussões intermináveis sobre minúcias dessas notações passaram a fazer parte de quem se interessava por metodologia.

Assim como os esquimôs têm muitos nomes para a neve, por conta da importância que esta tem para eles, passaram a ser utilizados muitos nomes para as atividades referentes a requisitos: levantamento, análise, elicitação, gerenciamento, especificação. Foram elaborados corpos de conhecimento e provas de certificação. Foram escritos livros inteiros e criados cargos específicos para lidar com requisitos: primeiro, o analista de requisitos e, depois, o analista de negócios. Cursos sobre a disciplina de requisitos são ministrados regularmente.

No caso dos esquimôs, podemos imaginar motivos pelos quais seria importante identificar diferentes tipos de neve. Numa viagem de trenô pela tundra, identificar sutis diferenças pode ajudar a evitar uma avalanche ou o mergulho nas águas geladas do Ártico: é questão de vida ou morte.

A sofisticação no tratamento dos requisitos poderia ser motivada pela percepção de perigos equivalentes ? Há três décadas, Barry Boehm alertava para o fato de que, no modelo vigente à época, errar nos requisitos tinha um impacto proporcionalmente muito maior, em termos de custo, nas etapas posteriores do ciclo de vida no software.

A mensagem passou a ser: não erre, seja muito cuidadoso com os requisitos, porque depois as consequencias serão desastrosas. Muitos interpretaram isso como perseguir um santo graal de requisitos completos, formalizados, detalhados e assinados com sangue no início do projeto. Hoje, sabemos que a cura foi pior que a doença, mas isso é assunto para outro post.

Testes

A camisa reserva é representada pelos testes, já que estes também são uma alternativa para a descrição do comportamento. Até pouco tempo atrás, não se dava importância real ao teste de software. Por quê ? Na verdade, já fiz antes essa pergunta: testar seria uma arte perdida ? As pessoas sabiam que o funcionamento de um sistema precisaria ser verificado de maneira adequada, mas as pressões de curto prazo sempre faziam com que o esforço de testes fosse empurrado com a barriga.

Na primeira década do século XXI, alguns fatores conspiraram para que o interesse em teste de software aumentasse. Um deles é a crescente penetração dos sistemas de informação no dia a dia das pessoas: os sistemas se tornam ao mesmo tempo mais críticos e mais complexos. O resultado das empresas depende cada vez mais do software que suporta suas operações, e o impacto direto dos defeitos no software passa a ser cobrado pelos seus usuários e percebido pelos tomadores de decisão.

Outro fator relevante foram as metodologias ágeis de desenvolvimento, que acordaram muitos profissionais de TI para a necessidade de testes, e passaram a utilizar testes automatizados como uma forma de especificação do comportamento dos sistemas. Note-se que esta visão invade a praia dos requisitos, e que contraria uma premissa tradicional da disciplina de testes: distinção entre requisitos e testes. Na visão tradicional, os artefatos de requisitos são uma das fontes para criar artefatos de teste, e se discute como derivar estes a partir daqueles.

Nesse processo, novas técnicas e ferramentas foram desenvolvidas, novas práticas e formas de gestão do esforço de testes surgiram. O papel dos profissionais de teste está sofrendo mudanças radicais e modelos estão sendo propostos para entender a disciplina de testes neste novo contexto.

Assim como na disciplina de requisitos, existe todo um ecossistema em torno de testes: associações profissionais, cursos, programas de certificação, modelos, empresas dedicadas exclusivamente a testes e cargos específicos. Testes têm um status emergente na sociedade.

Exemplos

A terceira camisa são os exemplos. De fato, são o patinho feio, a forma menos estudada de descrever o comportamento de um sistema. No entanto, são a forma intuitiva de captura regras de negócio junto a um especialista de domínio: as pessoas conseguem raciocinar melhor a partir de exemplos concretos. Os modelos abstratos, desde um ponto de vista cognitivo, são inferidos a partir de conjuntos suficientemente abrangentes de casos concretos. Agora, começa a haver um interesse em formular melhor práticas relacionadas a exemplos.

No entanto, muitas das propostas em metodologia de sistemas foram focadas em abstração. Apenas para citar um caso, uma das premissas dos documentos de casos de uso era a de serem uma especificação do comportamento do sistema, do ponto de vista do usuário: em muitas organizações, no entanto, eles foram sequestrados pelos técnicos e transformados em especificações formais em uma linguagem para iniciados, procurando abranger todos os caminhos alternativos, validações de domínio, exceções, regras de negócio e passos atrelados a uma certa implementação. Códigos como RN077, UC045 e A12 estão espalhados em um texto com dezenas (ou até centenas) de páginas.

Será que, nesse caso, não se seguiu a trilha errada ? Um especialista de domínio teria condições de entender esse formato ? Para efeito de compreensão da funcionalidade, isso funciona melhor que um conjunto consistente de exemplos concretos ?

Os exemplos começaram a ser estudados a partir do surgimento de ferramentas que usavam esse modelo de conjuntos de exemplos como forma de especificação de comportamento. A primeira destas ferramentas que adquiriu um uso amplo foi o FIT (framework for integration testing): os exemplos são expressos em formato de tabela, que é interpretada através de um adaptador (fixture), que aciona o sistema sendo desenvolvido usando como parâmetros os dados da tabela. Estes exemplos são chamados de testes de aceitação automatizados (talvez teste não seria a melhor forma de descrever: falo disso mais adiante). O FIT evoluiu para incorporar um front-end Wiki, chamado FitNesse, que torna o formato ainda mais próximo de um especialista de domínio.

A ideia é que o próprio especialista do domínio, ou um analista de negócios, ou um analista de testes seja responsável por essa especificação em forma de exemplo. No mínimo, o exemplo deve estar em um formato que todos consigam entender, e que não fique restrito a um perfil técnico.

Por quê prefiro chamar de exemplos e não de testes: a diferenciação é sutil. Se enfatizamos o aspecto do exemplo, não nos preocupamos tanto com classes de equivalência, cobertura e casos interessantes do ponto de vista de detecção de defeitos. Na qualidade de exemplo, o foco é na comunicação, no formato acessível. De fato, muito do que normalmente chamamos de testes no contexto de práticas ágeis poderia ser melhor descrito como exemplos.

As técnicas de TDD (desenvolvimento guiado pelos testes) e, por extensão, ATDD (desenvolvimento guiado pelos testes de aceitação) talvez seriam melhor entendidas se trocarmos "testes" por "exemplos". Brian Marick, justamente, propõe trocar a sigla TDD por XDD (eXample driven development). O objetivo principal é guiar o desenvolvimento, e para tal o papel de detecção de defeitos não é seu principal objetivo: o nome "testes" parece sugerir o contrário.

O BDD (desenvolvimento guiado pelo comportamento) utiliza este modelo de especificação baseada em exemplos, adicionando alguns formalismos e ferramentas. Mas o seu uso é suficientemente interessante para garantir livros inteiros apenas tratando do assunto. Fico devendo um post específico, podem cobrar.

A utilização de exemplos em geral, ATDD e BDD, têm provocado bastante barulho nos últimos tempos.

Exemplos agora estão virando fashion.

Eu ia discutir também a convergência entre esses três aspectos da especificação de comportamento em artefatos comuns, e seu efeito sobre a comunicação entre os envolvidos, mas essa elaboração fica para a próxima entrega. Até.

Jorge Diz
http://twitter.com/jorgediz

Outros posts:

http://blog.teamware.com.br/2010/01/o-dna-dos-padroes-de-gestao.html
http://blog.teamware.com.br/2009/12/arte-perdida-de-testar-o-software.html

Construindo um império com R$40,00

Algo que nós da YaW temos nos dedicado com bastante afinco nos últimos meses é o Google AppEngine(GAE).

Para quem ainda não conhece, o GAE é um ambiente de runtime
disponibilizado pelo Google onde você hospeda a sua aplicação sem
precisar se preocupar com manutenção de servidores. E ainda ganha com
tudo isso a escalabilidade proporcionada pelos servidores do próprio
Google.

Hoje ele dá suporte a duas linguagens: Python e Java(e a grande maioria
dos seus frameworks de mercado como Struts 1 e Struts 2, JSF 1 e JSF 2,
JPA com algumas limitações, EhCache, GWT, SpringMVC, etc. Lista
completa aqui).

Um detalhe importante sobre o GAE é que de início ele é completamente gratuito, e possui uma quota(beeeem generosa) de utilização, a partir do momento que você ultrapassar esta quota você tem de pagar pelo que ultrapassou. Detalhes sobre as quotas aqui.

O próprio site da YaW está hospedado no GAE.

E o que isso tudo tem ha ver com os R$40,00 e o império que você quer criar? Absolutamente tudo.

Imagino que como a grande maioria dos desenvolvedores que conheço, você tem seu trabalho diário, alguns projetos pessoais, e também está aguardando surgir alguma idéia genial(o próximo Facebook, Youtube, Twitter) que vai surpreender o mundo e te deixar mais rico que o Bill Gates.
Muito bem, o GAE pode te dar uma mãozinha nisso.

Hoje o registro de um domínio custa R$30,00 anuais no http://registro.br, porém um detalhe é que o GAE não tem suporte a 'naked domains', ou seja, você não pode registrar um domínio no registro.br e colocar os servidores do Google como servidores DNS do seu domínio.
Mas quanto a isso sem problemas, você pode utilizar um serviço de DNS gratuito como o Zone Edit e tantos outros como servidores DNS e direcioná-los para a sua aplicação no GAE.

Pronto. Você investiu R$30,00 e algumas horas desenvolvendo a sua idéia genial, hospedou gratuitamente, e está pronto para colher os louros da fama e riqueza.

Conhecem o BuddyPoke do Orkut? Pois é, ele foi assim. Um desenvolvedor, um notebook, hospedado no GAE, e hoje possui mais de 42 milhões de usuários e já foram enviados mais de 1 bilhão de pokes.

Está esperando o que? O conhecimento quem é desenvolvedor já tem, e quem não tiver basta chamar um desenvolvedor e compartilhar a idéia. As ferramentas necessárias(máquina de desenvolvimento e servidores) você também já têm. Agora é só botar a cabeça pra funcionar, se mexer, deixar de lado o medo e a preguiça, e compartilhar com o mundo suas idéias.

Este post não é só para fazer propaganda gratuita do GAE, nas próximas semanas vou postar aqui no blog tutoriais de como se utilizar alguns frameworks Java no GAE, como Struts 2 e JSF 2(que apresentei no TDC 2009) e JPA. E também enquanto isso teremos tempo de vocês conhecerem o ambiente, fazerem alguns testes com o plugin do Eclipse para o GAE e publicarem suas próprias aplicações.

Obs: Os R$10,00 que sobraram é para me pagarem de cerveja quando ficarem milionários.

http://twitter.com/rafanunes

Novas Tecnologias, Velhos Problemas

Estou envolvido em projetos que demandam diversas integrações com webservices de parceiros comerciais. Ao adotar o stack JAX-WS 2.1 do NetBeans e do Glassfish nossas aplicações facilmente se beneficiam de representações Java das operações e estruturas de dados com as quais temos que interagir. O JAX-WS também tem permitido  velocidade para expor funcionalidades implementadas em Java, para aplicações internas desenvolvidas em outras plataformas.

Toda essa facilidade de integração pode nos animar a princípio, de modo a utilizarmos intensamente esses benefícios. As armadilhas residem em :
 - ignorar o acoplamento com modelos de dados externos ao consumir webservices
 - permitir a transitividade do modelo de dados interno ao prover webservices

O fato é que um contrato de webservice estabelecido hoje pode se tornar obsoleto em alguns meses. Naturalmente existem patterns de arquiteturas orientadas a serviço, adotados do lado do provedor dos webservices, que minimizam o impacto de tais evoluções. Uma prática interessante que tenho observado é o versionamento de serviços. Quando uma nova versão de serviço é disponibilizada a versão antiga continua operante, durante mais uma ou duas evoluções.

Entretanto, o surgimento de uma nova versão de um serviço ocorre por novas necessidades de negócio, e o consumidor do webservice se verá obrigado a migrar mais cedo ou mais tarde. Sob este ponto de vista a manutenção de versões antigas simplesmente permite adiar o impacto da evolução.

Se a aplicação consumidora estabeleceu dependência indireta com as representações Java geradas por ferramentas como o JAX-WS, esta ficará protegida do impacto de evolução dos serviços consumidos. A idéia não é novidade, e é bem discutida em uma publicação de Jens Coldewey, particularmente no tópico Subsystem-Façade (uma releitura do pattern GoF Façade).

Considerando o serviço a ser consumido e sua estrutura de dados como um subsistema, procuramos evitar a utilização direta das classes geradas pelo JAX-WS. Além de utilizar um componente Façade para converter as estruturas de dados do serviço consumido para as estruturas internas da aplicação consumidora, encontramos espaço para outra prática de integração, que eu tenho nomeada como 'Wrapper', e que devo comentar num próximo post.

O mesmo princípio de separação de subsistema é aplicado quando assumimos papel de provedor de serviços via JAX-WS. Considerando que nosso modelo de dados interno pode evoluir, este não é utilizado diretamente na interface dos serviços oferecidos. Combatemos a transitividade de nosso modelo de dados interno, seguindo o design pattern Value Object: criamos um modelo de dados customizado, que pretende permanecer estável para os consumidores dos serviços, ao longo de mudanças internas.

Considero que essas práticas podem ser adotas ao criar webservices em Java utilizando outros mecanismos como o JAX-RS para REST, ou ainda com os precursores JAX-RPC e Apache Axis.

Para expor webservices sem transitividade há também a abordagem Contact-First, utilizada pelo Spring Web Services. Tal abordagem também pode ser utilizada em JAX-WS. Neste caso sempre definimos o schema de dados e operações expostas em primeiro lugar, colocando a geração dos artefatos Java como uma atividade secundária.

A versão original desta discussão pode ser lida em meu blog.