Desenvolvimento Ágil na Web com Seam

Este é o titulo de um artigo bem legal que o Rodrigo Yoshima postou em seu blog ontem. Se você se interessa por desenvolvimento Web, vale a pena conferir.

Aliás, falando em JBoss Seam, a Caelum lançou um super curso, rápido e objetivo, que você pode conferir o conteúdo programático aqui. Como sempre, qualidade indiscutível.

JRuby ou Groovy?

[Novo endereço: leandrosilva.com.br.]

Não, não quero começar nenhum flame war em torno de JRuby e Groovy.

O que ocorre é que ontem um cara que tem um blog legal, o Diego, fez um comentário num de meus posts que me fez pensar a respeito… Até agora…

Na hora, sinceramente, não tive nada de muito substancial para responder, porque ainda não havia pensado a respeito. Mas tenho que confessar que isso ficou martelando a minha cabeça o tempo todo… Existe alguma vantagem de se usar Groovy invés de JRuby?

Bem, lendo e pensando a respeito, cheguei a algumas simples conclusões:

Se você tem familiaridade com Java e quer permanecer 100% no ambiente Java, sem a perspectiva de migrar, Groovy é a melhor opção pra você.

Porque a sintaxe de Groovy é muito parecida com a de Java; Groovy traz consigo uma porção de vantagens de uma linguagem OO moderna e dinâmica, como meta-programação, duck type, e closures; e você ainda pode programar usando objetos Java e Groovy numa mesma classe, de forma totalmente transparente (já que .groovy ao ser compilado se transforma em um .class qualquer).

Só que, mais uma vez: Não há qualquer possibilidade de se rodar código Groovy fora de ambiente Java, porque Groovy foi especificamente criada para ser uma “alternativa” à linguagem Java.

Se você quer que seu código seja portável para outras plataformas de runtime, tal como .Net, por exemplo, JRuby é o melhor pra você.

Acho que este é um dos fatores primordiais na escolha de JRuby invés de Groovy. Porque o fato da sintaxe de Groovy ser próxima à de Java, sinceramente, pra mim não quer dizer nada – aprender uma nova sintaxe não é coisa de outro mundo; e é até legal. Agora, portabilidade, isto sim faz a diferença – quando necessário, claro.

Você pode escrever, por exemplo, uma aplicação Ruby on Rails comum e coloca-la para rodar em um web container Java, sem muito esforço. Aliás, se você estiver usando o NetBeans, ele faz isso pra você em um ou dois cliques. E se num dado momento decidir rodar, sei lá, num Mongrel, tudo bem, você pode fazer isso sem problema algum. Isto é fantástico!

Se você quiser se manter 100% compatível com a MRI, isto é totalmente possível, porque JRuby é uma implementação completa de Ruby para a plataforma Java. E se você quiser aproveitar algum código escrito em Java, você também pode fazer isto – mas neste caso, claro, sacrificando a portabilidade.

Outro fator primordial que vejo é “comunidade”.

A comunidade JRuby tem crescido a cada dia – claro que por conta do próprio Ruby/Rails. E a indústria de software tem investido nisto, aja vista o ótimo suporte do NetBeans a Ruby/Rails; e a própria contratação de membros chaves do JRuby pela Sun há algum tempo.

E a comunidade Groovy? Bem, acho que Grails tem ajudado a levanta-la. Mas o seu barulho ainda não é dos maiores não. (Espero que isto mude.)

E o fim deste pensamento, qual é?

Use JRuby. Use Groovy. Use o que melhor atender aos seus próprios requisitos e aos de seu cliente. Porque não há apenas uma linguagem de programação, nem uma única solução pra tudo!

Atualmente estou propenso a usar tanto JRuby [on Rails] quanto Groovy [on Rails]. O que vai me fazer decidir entre um e outro serão os requisitos do momento – e a expectativa futura.

Então, seja JRuby ou Groovy, o que importa é desenvolver o software certo, no tempo certo, com a qualidade certa.

(Valeu Diego, por me fazer pensar um pouco sobre isto.)

Até a próxima!

Groovy nos trilhos do desenvolvimento web ágil?

[Novo endereço: leandrosilva.com.br.]

Sei que já não é mais tão novidade assim, mas só agora pude gastar um tempo pesquisando e fazendo uns testes. Do que estou falando? Hammm… O titulo dá uma idéia do assunto… Grails! Ou, para os mais eruditos, Groovy on Rails.

O que Grails, afinal?

Grails é a resposta da Plataforma Java ao desenvolvimento web ágil, dinâmico, sem toda aquela parafernália de 7.203 arquivos XML para configurar, 3.412 classes dos frameworks jAbc, J-XPTO e JSeila Oq+ para estender, e mais uns 1.300 arquivos JAR para “bibliotecar”.

Esta maravilha do mundo Java segue a filosofia de frameworks web full stack, tais como Ruby on Rails e Django. E segue fundamentalmente o conceito de Convention over Configuration, que pode ser resumido em uma simples frase: “É ótimo poder configurar, mas é péssimo ser obrigado a fazer isto”. Sendo assim, tudo tem um padrão de nome a seguir e um local bem definido para estar.

O que está por trás?

Grails não foi construido a partir do nada. Muito pelo contrário. Ele está fundamentado sobre frameworks de mercado mais que consagrados:

Hibernate, sobre o qual esta o GORM (Grails ORM);
Log4J, controle de log;
Spring, injeção de dependência e MVC;
Jetty, web container embutido;
SiteMesh, templates de página web.

E tudo isto sendo “colado” e “manipudalo” pela linguagem Groovy, que para quem viveu os últimos anos em Marte, é uma linguagem orientada a objetos, fortemente tipada e dinâmica, desenvolvida para a Plataforma Java, como alternativa à própria linguagem Java.

Vale a pena usar Grails?

Para o seus projetos, só você mesmo pode responder. Mas o fato é que já existe muita coisa por ai rodando em cima de Grails. Um exemplo? O site da PepsiCo, por exemplo, que é um caso relatado no site do Grails.

Minha opinião? Se você quer uma alternativa dinâmica ao desenvolvimento web rápido para a Plataforma Java, dê uma olhada em Grails. Você não vai se arrepender.

Agora, se para você, desenvolvimento “confiável” e “bem feito” é sinônimo de centenas de milhares de XMLs, JARs, frameworks, e linguagem estaticamente tipada (porque o compilador te faz errar menos), esqueça Grails. (Mas… Uma dica: Sai dessa, meu chapa!!! rsrsrs)

Valeu!

Comparações podem ser enriquecedoras

Todo mundo sabe que eu amo escrever programas com Java. Se não todo mundo, pelo menos a maioria dos meus amigos programadores. E ao contrario do que muitos podem pensar, eu não acho que Java seja a última bolacha recheada do pacote, ou talvez a última Coca-Cola no deserto. Pra mim, Java é apenas uma opção. Uma ótima opção, mas ainda assim, uma opção.

Seguindo nesta linha de pensamento, penso que comparações podem ser enriquecedoras. Não pra depreciar, mas pra nos ajudar a otimizar e a programar melhor.

Bom, sem mais explicações, leiam este post…

Smalltalk x Java

Que linguagem aprender em 2008?

Seguindo o conselho dos programadores pragmáticos, decidi, definitivamente, que este ano vou aprender uma nova linguagem de programação. Aliás, desde o ano passado venho fazendo uns ensaios dessa tarefa, rabiscando uns códigos em Ruby, mas nada muito além disto.

Mas este ano… Ah, este ano… Tudo vai ser diferente… Este vai ser o Ano de Ruby pra mim!

Pretendo também, com muito esforço e otimismo, começar a aprender Python talvez a partir do meio do ano. Vamos ver como será meu progresso com Ruby.

Aproveitando, quero indicar também alguns posts sobre isso:

A próxima linguagem a aprender
Que linguagem você aprenderá em 2008

E você, vai aprender que linguagem em 2008? Responda aqui neste post…

Não há uma única linguagem de programação

[Novo endereço: leandrosilva.com.br.]

É gosado ver como de uns anos pra cá se proliferou a idéia de que há uma linguagem de programação que pode resolver todos os problemas computacionais. Essa idéia ganhou a maioria de seus adeptos entre os programadores Java, já que Java carrega consigo o conceito de “escreva uma vez, execute em qualquer lugar”. Doce ilusão. Não a de que programas escritos em Java podem ser executados em qualquer lugar, porque a Máquina Virtual Java já é uma realidade bem pouco virtual há anos. Mas a idéia pretenciosa de que todos os problemas computacionais da face da terra poderiam [e deveriam] ser resolvidos com Java. Poder ser executado em qualquer lugar não significa necessariamente ser a melhor opção em termos de resolução de um problema computacional, quando este tem uma plataforma computacional invariável.

Bem, antes que alguém pense o contrario, vou dizer clara e francamente, no bom e velho português de Luis Vaz de Camões: Eu adoro Java! É sério. Eu comecei aprender Java na versão 1.1.8, em meados de 1997, e ganho dinheiro com ela a mais de 7 anos. Fiz faculdade, comprei um apartamento, me casei, comprei um carro, viajei pra vários lugares, comprei uma centena de coisas, inclusive o laptop no qual estou escrevendo este post, programando com Java. Mas não me atrevo a pensar que Java é a linguagem de programação ideal para resolver todo e qualquer problema computacional. Não mesmo!

Voltemos um pouco no tempo. Década de 90, Sun Microsystems, Green Project, o princípio da linguagem Java.

A linguagem Java não foi projetada para resolver os problemas computacionais os quais são resolvidos com ela hoje. Ela foi projetada com um objetivo, mas ao longo dos anos foi se adaptando a outros bem diferentes. Por que então deveríamos pensar que ela é a única e melhor opção?

Isso parece lógico, não? Pois é… É o que é…

Cada problema computacional é diferente do outro, ainda que semelhantes. Assim, cada um deles deve ser analisado por diversos pontos de vista da engenharia de software:

– Ambiente de execução;
– Produtividade de implementação, teste e distribuição;
– Escopo topológico;
– Experiência de usuário;
– Custo e oferta de profissionais;
Apenas para citar alguns.

Fato é que, sempre há uma linguagem de programação mais aderente à resolução de um determinado problema computacional, e em um ambiente profissional, programadores, arquitetos e engenheiros de software não podem levar a cabo suas preferências pessoais. O sucesso do dado projeto vale mais.

É claro que sempre será mais divertido programar com a linguagem que se tem maior preferência, ou mesmo paixão. Mas linguagens de programação são o meio e não o fim.