SPIDER on Rails no Demoiselle (projeto do governo)

Bruno Braga on February 2nd, 2010

Uma boa notícia: o Demoiselle – framework do governo (SERPRO) para desenvolvimento Java avaliou e divulgou em seu blog um post sobre a ferramenta SPIDER on Rails:

http://sourceforge.net/apps/wordpress/demoiselle/2010/01/26/spider-on-rails-gerando-codigo-demoiselle/

O resultado da analise detalhada (ver link acima) e criação de um template para o Demoiselle foram bastante positivos e podemos destacar alguns trechos dessa analise:

“Continuando minha busca por alternativas legais para geração automática de código usando templates encontrei na InfoQ o interessantíssimo projeto open source SPIDER On Rails, um plug-in Eclipse bastante customizável que possibilita a criação de aplicações completas em várias linguagens”

“A geração automática de código costuma ser bastante criticada pela impossibilidade em se controlar a qualidade do que é produzido. O SPIDER permite uma grande flexibilidade para que deixemos o código do “nosso jeito” ou do “jeito da nossa organização”.”

“Vale destacar aqui uma funcionalidade muito interessante do SPIDER. O uso de incrementos com base em Expressões Regulares, permite incluir um pequeno trecho de código (incremento) em arquivos já existes sem perder configurações e/ou customizações do desenvolvedor realizadas anteriormente. Isso permite, por exemplo, alterar conteúdo de classes, páginas e arquivos de propriedades, a cada geração de um novo CRUD” (sem perder nada).

Subscribe to this blog's RSS feed

Mitos sobre geração de código

Bruno Braga on December 24th, 2009

Segue abaixo um artigo que escrevi no site do projeto SPIDER on Rails:

O termo “mito” é, por vezes, utilizado de forma pejorativa para se referir às crenças comuns.
E existe uma cresca comum que geração de código é algo ruim em projetos.

Encarnando os MythBusters vamos tentar analisar objetivamente se esse mito é válido.

A geração de código é a capacidade de gerar artefatos a partir de diagramas, templates ou até comandos.

Um fato constatável é que alguns desenvolvedores são um pouco resistentes ao termo “Geração de Código”.
As principais reclamações são:

  • O código gerado não respeita nenhuma regra de arquitetura, é simplesmente “um monte de código” de má qualidade;
  • Não é possível manter o código gerado porque ele não segue nenhum padrão e é difícil de entender, sempre é necessário regerar o código em caso de mudanças;
  • Após gerar o código a minha aplicação fica sempre depedente da ferramenta de geração, sem ela o projeto não pode ser alterado;

Dada à diversidade de ferramentas dessa área, estes pontos parecem estar corretos. É fácil encontrar esses tipos de problemas e limitações.
Indo mais além, muitos de nós já se deparou com projetos que prometiam criar um sistema por completo usando geração de código (ferramentas CASE), porém sabemos que isso não é a realidade. Não podemos substituir as pessoas, os programadores, criar regras de negócios automaticamente, prever e implementar soluções para todos os cenários somente gerando código. O computador não possui autonomia para sozinho atender aos nossos clientes exigentes =)… Muito menos foi projetado para tomar todas as decisões no lugar das pessoas.

Então o mito tem fundamento? Geração de código é realmente algo ruim? Vai gerar código que não preciso e atrapalhar o meu projeto?

Essas questões são interessantes, e para buscar uma resposta precisamos isolar os problemas e conceitos, entender o que de fato é geração de código e de onde vem todo o problema.

Ferramentas CASE e similares

Essas ferramentas criadas na década de 90 são responsáveis por boa parte das promessas de “mágica” utilizando geração de código através de modelos. Muitas dessas ferramentas prometiam criar sistema inteiros sem programar nenhuma linha de código. Foi uma estratégia que nunca deu certo e essas falsas promessas surgiram de algumas empresas e das ferramentas e não do conceito de geração de código que é utilizado até hoje (mesmo sem percebermos) em quase todos os softwares que desenvolvemos.

Geração de código

Neste tópico o objetivo é descobrir porque praticamente todo projeto usa geração de código e o que de fato é isso.

Alguns exemplos comuns a todos os projetos:

  • Um wizard da IDE para criar novos projetos é um gerador de código. A partir de dados informados pelo usuário, a ferramenta vai gerar artefatos (arquivos) que inicializem um novo projeto.
  • Por mais estranho que possa parecer, a compilação de código fonte em arquivos binários é geração de código. A partir de comandos de uma linguagem de alto nível são gerados artefatos de outra linguagem de máquina (baixo nível).

Esses exemplos podem parecer polêmicos para alguns pontos de vista, mas a verdade é que não existe uma definição precisa sobre o conceito de geração de código. Existem opiniões e interpretações diferentes que nos levar a ter um certeza – geração de código é algo muito mais amplo do que conhecemos na maioria das ferramentas e é utilizado com muito mais frequencia do que imaginamos.

Vejamos por exemplo o que diz a Wikipedia:
“Gerador de Código é aquela ferramenta que possui a capacidade de gerar código a partir de um determinado modelo de software. Inclusive, de acordo com alguns pontos de vista e a partir das características específicas do tipo de Gerador de Código, ele passa a ser conversor de códigos de linguagens distintas. Isso acontece, por exemplo, com o compilador, que transforma um código escrito através de uma linguagem de programação para código de máquina ou código objeto.”

Já Kathleen Dollard em 2004 no livro Code Generation in Microsoft .NET, foi mais genérica ainda ao definir: “Geração de código é o código que gera código”. Em 2003, Jack Herrington no livro Code Generation in Action preferiu dividir a geração de código entre passiva e ativa. Onde os wizards seriam um exemplo de geração passiva, pois não mantém responsabilidade com o código gerado – qualquer alteração depois da geração é realizada pelo desenvolvedor manualmente, e o tipo ativo que segundo ele mantém a responsabilidade – um código poderia ser gerado em ciclos e quando precisasse de alterações o desenvolvedor recorreria novamente a ferramenta de geração, forneceria novos dados e seria gerado o código de novo.

Aqui não vamos dividir a geração de código em tipos, até porque seguindo ao pé da letra as definições de Herrington, o projeto SPIDER on Rails não faz geração de código 100% ativa nem passiva, ele é orientado as necessidades do desenvolvedor, podendo se comportar das duas formas no mesmo projeto inclusive. O que temos que ter em mente é que se havia alguma dúvida, agora é fato: a Geração de Código faz parte do dia a dia dos desenvolvedores e todos a utilizam, mesmo sem perceber. Ela é extremamente importante para evitar tarefas repetitivas ou trabalhosas, já que muitas podem ser automatizadas de alguma forma para ganhar produtividade. Só devemos lembrar que em nenhum momento a geração de código tem como objetivo fazer tudo sozinha.

Conclusão

Voltando a pergunta: “Geração de código é realmente algo ruim? Vai gerar código que não preciso e atrapalhar o meu projeto?”

A resposta é não! Geração de código não é ruim, não vai atrapalhar o seu projeto e nem tem o objetivo de criar código totalmente pronto.

Existem algumas características que devem que existir para que a geração de código seja algo útil, entre elas:

  • Suporte a templates para alterar o comportamento da ferramenta;
  • Seja fácil de utilizar;
  • O projeto tem que continuar sem depender da ferramenta de geração de código;
  • Ao gerar o código novamente a ferramenta não pode apagar as customizações do desenvolvedor;
  • Não tentar fazer o projeto todo gerando código, as pessoas são importantes e elas devem tomar as maiores decisões. A ferramenta é apenas um suporte para melhorar a produtividades em alguns pontos;

São esses e outros pontos que valorizamos no projeto SPIDER on Rails.

fonte: http://www.spideronrails.org/cnf/pages/viewpage.action?pageId=5111911

J2EE Spider 1.0.0-M3

Bruno Braga on May 26th, 2008

Bom o projeto está indo bem, a cada dia novas melhorias. Está dando muiiito trabalho, mas está ficando bacana.

O curioso é que o país onde as pessoas mais interagem e sugerem as coisas é a Índia =) O pessoal lá parece ser muito ligado na área de desenvolvimento mesmo.

Fora um ou outro bug a versão 1.0.0-M3 trás 15 melhorias enquanto a 1.0.0-M2 tinha 7. E cada melhoria dessas são significativas, então essa é uma boa release. Espero ter tempo para dedicar a JSF logo e adicionar essa opção no template da ferramenta até porque meu interesse pessoal é mais por JSF por enquanto.

Como detalhamento segue o changelog:

——————————————-
Version 1.0.0-M3 (2008-05-25)

Bug
* [Template] – Acertos no template para Struts – cruds com campo date, javascripts e outros.
* [Template] – Resolvido problema na geração da pasta /jsp/velocity usada para o struts-menu.
* [Plugin - Core] – Quando algum package tinha o mesmo nome do projeto o mapping gerava as classes na pasta errada.

Improvement
* [Plugin - Core] – Distribuição do plug-in usando jar e em arquivo separado do template.
* [Plugin - Core] – Adicionada validação de compatibilidade entre o template e o plug-in.
* [Plugin - Core] – Criação de aba exclusiva para gerenciar templates.
* [Plugin - Core] – Melhoria de performance do build.
* [Plugin - Core] – Adicionado botão para selecionar todos os atributos de uma classe no CRUD.
* [Plugin - UI] – Novo wizard para abrir o SPIDER Editor.
* [Template] – Mais traduções para o i18n do projeto.
* [Template] – Criado atributos para armazenar um resumo das características de cada template.
* [Template] – Adicionado ao template a possibilidade de executar scripts ant para completar o build.
* [Template] – Utilização da feature de executar scripts ant para rodar o xdoclet-build.xml após a geração de CRUDs com Struts.
* [Template] – Alinhamento do código HTML das páginas jsp geradas.
* [Others] – Utilização do Atlassian Bamboo como software de integração contínua e do Fisheye.
* [Others] – Criado um Eclipse Update Site para instalação e atualização do plug-in.
* [Documentation] – Site: tradução de mais páginas para o idioma inglês (mais documentação).
* [Documentation] – Nova sessão “Getting Started” no site.

——————————————-

http://www.j2eespider.org

Palestra SPIDER em evento M$…

Bruno Braga on April 24th, 2008

Parece estranho mas sábado dia 26 vou pegar carona em um evento do pessoal de .Net (Microsoft) e fechá-lo com uma palestra Java sobre o projeto J2EE Spider.

Como o povo do MG-JUG está um pouco parado em relação a palestras, vai ser uma oportunidade de ter algo sobre Java por aqui.

O evento vai ser o dia todo, mas a palestra do SPIDER será na parte da tarde por volta das 15:30h.

A palestra é mais um bate papo sobre geração de código e apresentação da ferramenta.

Quem quiser chegar antes, desde as 9h tem palestras sobre tecnologias da Microsoft inclusive SilverLight que é concorrente do Java FX.

Até lá!

Nova versão do J2EE Spider

Bruno Braga on February 1st, 2008

Ontem lancei a versão 1.0.0-M1 do J2EE Spider.

Temos muitas novidades. Agora já está disponível a criação de projetos com CRUD, o layout do plugin foi revisto, tem funcionalidades novas como mapeamento e muitas outras coisas…

Deu muito trabalho, mas está ficando bacana. Para ver você mesmo assista o vídeo abaixo:

- versão windows (auto-executável)
- versão multiplataforma (visualizado no browser)

Só gostaria de fazer uma consideração importante sobre a ferramenta:

Apesar da ferramenta estar ficando bastante interessante, ou em outras palavras – fácil de criar projetos com alguns clicks, devemos lembrar mais uma vez que o objetivo não é substituir as pessoas e sair criando projetos utilizando somente o SPIDER. O objetivo é eliminar as tarefas repetitivas que temos no dia a dia, como configuração de projetos, erros na integração de frameworks ou tirar das costas do desenvolvedor a responsabilidade de codificar artefatos que não possuem regras de negocio e uma ferramenta poderia criar em determinados contextos. As pessoas (nós desenvolvedores) podemos ser mais produtivos se estivermos mais focados nas decisões tecnológicas e regras de negocio da aplicação (só para citar alguns) e menos focado em infra-estrutura do projeto.
A idéia é ir mais direto ao ponto sobre as necessidades do cliente ou dos projetos usando uma IDE fácil, intuitiva, com muitos recursos e customizável.

Para visualizar o site do projeto, acesse: http://www.j2eespider.org

Palestras J2EE Spider

Bruno Braga on October 23rd, 2007

Em agosto foi publicado no Jornal da Universidade FUMEC (na qual fiz graduação) a seguinte notícia:


fonte: http://www.fumec.br/jornal/?p=306

Além disso fui convidado e estarei realizando uma palestra sobre o projeto amanhã dia 24 a noite e dia 25 de manhã na FUMEC.

E aproveitando o embalo, dia 26 estarei na UFOP apresentando uma palestra sobre o mesmo assunto no III Workshop de Computação UFOP / UNIPAC.

Segue o link do evento:

http://www.unipacto.com.br/workshop

Aproveitando o assunto sobre o projeto, espero terminar a parte de CRUD até o fim do ano (tempo é um grande problema) e realizar mais algumas palestras em outros lugares ano que vem. Até lá… =)

Novo Artigo

Bruno Braga on May 14th, 2007

Já está nas bancas meu novo artigo na revista Mundo Java.
Dessa vez falando sobre um projeto Open Source que eu estou desenvolvendo.

O tema principal do artigo é sobre como aumentar a produtividade em projetos JEE.

Não deixem de ler. A revista (número 23) trás ainda vários assuntos interessantes ligados a detecção e eliminação de bugs.

Uma introdução sobre o tema que escrevi: “Qual desenvolvedor ou empresa não quer ganhar produtividade, eliminar as tarefas repetitivas do dia-a-dia, diminuindo custos e prazos do desenvolvimento de projetos? Não podemos dizer que são tarefas fáceis, mas também não são impossíveis. Vamos mostrar como conseguir isso neste artigo…”

Post sobre produtividade em JEE

Bruno Braga on March 14th, 2007

Fui convidado e ontem publiquei um post no blog do Rodrigo Urubatan sobre produtividade em JEE.
É uma prévia do artigo da revista que estou escrevendo para a Mundo Java. O tema envolve geração de código e o projeto Open Souce J2EE Spider.

Para quem tiver interesse no assunto, segue o link abaixo:

Java on Rails – Produtividade em Java (Parte 2 – J2EE Spider)

=)

Logo do projeto J2EE Spider

Bruno Braga on February 4th, 2007

Meu amigo italiano Benedetto (colega da GlobalValue) fez uma logo para o projeto J2EE Spider, do qual sou responsável.

Vejam abaixo:

Achei bacana =)
Acho que vou usar ela de avatar nos fóruns… hehe

SPIDER 0.2.0 saiu do forno =)

Bruno Braga on January 18th, 2007

Disponibilizei agora a pouco a nova versão do SPIDER, que é meu projeto Open Source voltado para geração de código em Java.

Não tenho muito tempo para me dedicar, e por enquanto estou fazendo sozinho. Mas está ficando bem bacana. Estou procurando colocar bons recursos para que seja útil e poderoso, mas ao mesmo tempo mantê-lo simples, prático e flexível. Onde o estilo de código gerado possa ser customizado por qualquer pessoa ou equipe. Acho que parte dessas metas deviam ser as metas de qualquer software :)….
É, talvez não sejam porque eu sei bem que nem sempre é tão simples… Mas tudo começa de boas idéias, vontade e determinação.

Nesta release eu dei uma força para outros projetos brasileiros, e coloquei suporte ao Mentawai e ao Spring-Annotations.

Temos bons profissionais e bons projetos por aqui… Então gogogo Brasil!!!

http://www.j2eespider.org