Lançada a versão final do Grails 1.0

O Grails é realmente incrível, sendo possível criar uma aplicação CRUD com poucos (3 ou 4) comandos. O Gorm também está muito legal, é facílimo de fazer os mapeamentos, e tem por base nada mais nada menos do que o Hibernate, provavelmente o framework de ORM java mais maduro de hoje.

Parabéns a equipe do Grails!

Alguém conhece algum site ou projeto importante desenvolvido usando o Grails?

Duvido que muitas empresas tenham apostado no Grails antes da versão 1.0. Mas sei de um case, a SAP:

https://www.sdn.sap.com/irj/sdn/wiki?path=/display/Community/Composition+on+Grails

Mas agora vão aparecer outros. Grails facilita muito o desenvolvimento em Java e duvido que as empresas que trabalham na plataforma não abram os olhos para este framework.

Grails is like Rails?

Já que vi que o pessoal anda “incendiando” tanto sobre Ruby X Java, queria saber de quem é mais experiente:

O que ainda não dá pra fazer em Grails que dá pra fazer em Rails?
O que Ruby ainda faz que Groovy não faz?

Espero que o pessoal que conheça bem o Groovy e Grails ajude a debater esta situação.

Abraços

Até onde eu mexi nele, eu diria que sim. Tem facilidades espantosas, como Rails. Só que ele faz uma camada sobre Hibernate e Spring, o que não acho nem um pouco má idéia .

O maior problema de Groovy é que ela é próxima demais do Java, então muita coisa não tem como ser feita em Groovy, como mixins, definir novos métodos em tempo de execução (na verdade, até pode se você fizer umas gambis no despacho de métodos, mas é bem mas complicado do que seria em Ruby com um class_eval, module_eval ou ainda um define_method).

Não vi callbacks pra quando uma classe extende a outra (e isso é muito importante pra metaprogramação e seria ainda mais se Groovy tivesse suporte a módulos). Groovy também não tem open classes/modules, deixando você alterar o comportamento de classes já definidas no ambiente (como colocar novos métodos em String). Open classes são uma mão na roda quando voc está mexendo com código alheio que está versionado e você não pode fazer “patches” diretos.

Enfim, o grande problema de Groovy hoje ainda é o suporte fraquinho a metaprogramação e é isso que faz de Ruby uma linguagem bem mais flexível.

Mauricio, obrigado pelas respostas. Estou pesquisando sobre Groovy e é interessante saber o que ele pode ou não ter. Vi que Groovy tem a proposta para Mixins. Alguns também estão fazendo o mesmo para Open Classes. Bom, por enquanto não é oficial, então, Ruby ainda está na frente.
Mas JRuby ainda é lento para uma JVM. Aliás, não sei se fui só eu, mas constatei que JRUby roda bem no GlassFish e lentamente no Tomcat. Há alguma constatação quanto a isso ou foi só comigo?

Abraços

Grails tem uma coisa que o Ruby não tem: ele roda em uma JVM.

Não sei como anda o Rails para o JRuby, esta seria uma vantagem, porém convém lembrar que é importante sabermos aonde nossa aplicação está sendo executada, e a plataforma Java, convenhamos, é fantástica!

O simples fato de você poder reaproveitar TODO o seu código legado em uma aplicação feita em Grails já o coloca, na minha opinião, anos luz à frente do Ruby on Rails. O que me prendia um pouco com relação ao RoR era exatamente o fato de que seria mais difícil aproveitar trabalhos passados que eu havia desenvolvido em Java.

Andei dando uma fuçada no Grails e fiquei realmente impressionado com o que vi. Em um aspecto, inclusive, o GRails passa o RoR: você não precisa configurar nada, tal como ocorre no RoR. Isto porque o GRails já vem com o HSQLDB embutido. Claro, esta não é lá uma grande vantagem, mas é um passo à frente.

Com certeza o GRails está na lista de minhas apostas para 2008

kicolobo:

Grails tem uma coisa que o Ruby não tem: ele roda em uma JVM.

Não sei como anda o Rails para o JRuby, esta seria uma vantagem, porém convém lembrar que é importante sabermos aonde nossa aplicação está sendo executada, e a plataforma Java, convenhamos, é fantástica!

O simples fato de você poder reaproveitar TODO o seu código legado em uma aplicação feita em Grails já o coloca, na minha opinião, anos luz à frente do Ruby on Rails. O que me prendia um pouco com relação ao RoR era exatamente o fato de que seria mais difícil aproveitar trabalhos passados que eu havia desenvolvido em Java.

Andei dando uma fuçada no Grails e fiquei realmente impressionado com o que vi. Em um aspecto, inclusive, o GRails passa o RoR: você não precisa configurar nada, tal como ocorre no RoR. Isto porque o GRails já vem com o HSQLDB embutido. Claro, esta não é lá uma grande vantagem, mas é um passo à frente.

Com certeza o GRails está na lista de minhas apostas para 2008 :)

Oi Kico,
Acho que você se confundiu quando falou “Grails tem uma coisa que o Ruby”.Grails é um framework, ruby é uma linguagm.

Da última vez que eu parei pra olhar o rails 2 não funcionava com jruby, mas existe uma galera usando o rails “antigo” com jruby (tem até livro: http://www.apress.com/book/view/[telefone removido]).

O código legado pode ser usado com jruby também (google: java jruby integration), não sei até que ponto a coisa funciona. Onde bytecode é o denominador comum não devem ocorrer problemas.

HSQLDB embutido é uma grande vantagem?

Eu não conheço nada de Groovy, mas levando em conta o que o Mauricio falou, juntando com o que o mercado vem apresentado, jruby deve estar num andar a cima.

O JRuby 1.1R… funciona com Rails 2.0.2 sim. Abaixo acho que 1.0.3, se num me falha a memória.
JRuby é muito bom, mas tem a grande falha: lento. Muito mais lento que Groovy, e isso que irrita nele. Rails no GlassFish é lento, mesmo que mais rápido que no Tomcat. Grails é beeeeeeeeeeeem mais rápido. Claro que JRuby vai evoluir, mas até lá, pode ser que Groovy tb tenha evoluído, e muito.
Embora eu goste da sintaxe do Ruby, tenho que ver bem o Groovy, uma vez que o Grails possui uma facilidade gigantesca no desenvolvimento, coisa que ainda não havia visto em frameworks para a plataforma Java.

Não sei, pra mim Groovy vai ser o boi de piranha da plataforma Java, ela deve funcionar muito mais como um “meio” pra que gente que não acredita em linguagens dinâmicas ou que nunca mexeu com metaprogramação dar os primeiros passos.

Mas, invariavelmente, esse mesmo cara que começou a andar com Groovy vai perceber que a linguagem tem diversas fraquezas e pontos aonde outras linguagens que já rodam na JVM e se integram muito bem com código Java se dão bem melhor (como Scala e JRuby) e vai terminar largando Groovy.

De qualquer forma, eu acho que Groovy é uma ótima opção pra quando você não pode (ou não quer) dar uma virada muito brusca, ela ainda dá um falso sentimento de “segurança” pra um programador engessado em Java, gerentes que vieram da época dos escravagistas ou quando você quer adicionar capacidades dinâmicas a uma aplicação Java grande já existente sem fazer um refactoring muito grande no modelo de objetos dela.

Concordo com você, acredito que esta vai ser uma das razões principais para motivar a utilização do GRails.

Com certeza Scala e JRuby são mais interessantes que Groovy. A maior questão para a adoção do Groovy que vejo, nem é tanto por seu legado “quase java”, mas pelo seu desempenho na atualidade, simplificando o desenvolvimento com os diversos frameworks existentes que estão passando a suportá-lo. JRuby ainda precisa de ajustes para rodar razoavelmente bem com Rails em um Application Server da vida. Fora que, sem Rails, pra mim JRuby é como o Ruby, uma linguagem boa mas esquecida pela grande massa, adotada mais por administradores Unix/Linux da vida.

Opa! “Grande” vacilo!

Qualquer banco de dados embutido eu vejo como uma vantagem. Na realidade, olho para o Grails e para o RoR como ferramentas para trabalhos rápidos e pequenos,que o cliente quer com certa urgência.

Se você já tem um SGBD embutido, é uma preocupação a menos para este tipo de trabalho.

Agora, com relação ao uso destas ferramentas para trabalhos maiores… tenho cá minhas dúvidas.

Maurício Linhares:

O maior problema de Groovy é que ela é próxima demais do Java, então muita coisa não tem como ser feita em Groovy, como mixins, definir novos métodos em tempo de execução (na verdade, até pode se você fizer umas gambis no despacho de métodos, mas é bem mas complicado do que seria em Ruby com um class_eval, module_eval ou ainda um define_method).

Não vi callbacks pra quando uma classe extende a outra (e isso é muito importante pra metaprogramação e seria ainda mais se Groovy tivesse suporte a módulos). Groovy também não tem open classes/modules, deixando você alterar o comportamento de classes já definidas no ambiente (como colocar novos métodos em String). Open classes são uma mão na roda quando voc está mexendo com código alheio que está versionado e você não pode fazer “patches” diretos.

Enfim, o grande problema de Groovy hoje ainda é o suporte fraquinho a metaprogramação e é isso que faz de Ruby uma linguagem bem mais flexível.

Algumas coisas que poderia copiar na cara dura de Ruby seria null como object e mixins. O mais próximo que Groovy tem de mixins são marcações, no Grails, para indicar que uma classe deve ser alterada - veja só - em tempo de execução.

valeuz…

Veja que eu disse:

(na verdade, até pode se você fizer umas gambis no despacho de métodos)

Mas é muito mais complicado do que simplesmente fazer um define_method (ou module_eval e class_eval) em Ruby, você tem sempre que fazer override de “invokeMethod()” (a não ser que tenha mudado desde a última vez que eu mexi com isso em Groovy), o que termina sendo quase igual a ter sempre que fazer override de method_missig em Ruby, o que não é interessante, principalmente porque não tem um alias_method em Groovy.

Maurício Linhares:

Veja que eu disse:

(na verdade, até pode se você fizer umas gambis no despacho de métodos)

Mas é muito mais complicado do que simplesmente fazer um define_method (ou module_eval e class_eval) em Ruby, você tem sempre que fazer override de “invokeMethod()” (a não ser que tenha mudado desde a última vez que eu mexi com isso em Groovy), o que termina sendo quase igual a ter sempre que fazer override de method_missig em Ruby, o que não é interessante, principalmente porque não tem um alias_method em Groovy.

String.metaClass.reverse = { -> new StringBuilder(delegate).reverse() } 'Mauricio'.reverse()
É assim que funciona hoje em dia. Adicionar propriedades é simples também:

String.metaClass.getTamanho << { -> delegate.length() } 'minha string'.tamanho
valeuz…

Ah, então melhorou demais mesmo

Onde é que eu acho mais informações sobre isso?

O meu “Groovy In Action” não fala nada dessas mágicas.

Maurício Linhares:

Ah, então melhorou demais mesmo

Onde é que eu acho mais informações sobre isso?

Deve ser porque o livro foi escrito quando Groovy 1.1 - a versão na qual esses recursos foram adicionados - ainda estava em desenvolvimento.

valeuz,

Show de bola pessoal, tá realmente produtiva essa thread.
Aproveitando jack_-_ganzha, já que está por dentro do Groovy, tenho visto o pessoal lá fora elogiando o Grails 1.0. Tem tido alguma experiência com Grails? O que acha dele, na atualidade?

Valeu :thumbup:

muito boa mesmo! Obrigado Marcos pelas novidades e esclarecimentos.

Paulo, aproveitando que está por aqui, existem planos de adicionar Groovy no VRaptor?

djemacao,

É praticamente aceito na lista de usuários do Grails que ter uma versão 1.0 tem mais implicações culturais que técnicas. É realmente mais fácil vender algo com um 1.0 final do que com RCs e por aí vai. Onde trabalho um dos projetos é desenvolvido com o Grails e até agora os problemas é o costume de tentar encaixar algumas complicações (desnecessárias) que nós desenvolvedores Java tanto gostamos.

Pessoalmente tenho desenvolvido alguns projetos com o Grails e minhas reclamações são para o suporte a testes. Falta melhorarem alguns pontos:

1. Stack traces ilegíveis quando um teste falha
2. Faltam reports mais diretos sobre o porque o teste falhou
3. Falta um esquema para executar apenas os testes que falharam
4. Melhorar o plugin para cobertura de código (que se confunde com as closures)
5. Um plugin para Selenium, que eu acho bem melhor do que o WebTest.

O que eu faço para facilitar minha vida é:

1. Os testes são escritos para situações muito especificas e com nomes super descritivos
2. Um assert por teste, assim eu sei exatamente o que falhou
3. Todos os asserts com mensagens
4. Small steps para implementar/refatorar qualquer coisa

São práticas que ajudam mesmo quando vc desenvolve em Java, mas são ainda mais uteis para o Grails. Sobre o VRaptor, dá para usar Groovy para criar as classes de modelo e escrever os testes. É mais interessante do que fazer em Java.

valeuz…

Valeu jack_-_ganzha (Marcos), realmente estou muito interessado no Grails, e creio que muitos outros desenvolvedores também.

Abraços

Voltando ao Grails, alguém já viu o http://grails.org/Grails+vs+Rails+Benchmark de performance, comparando com Rails ?

Não creio que seja tanto a culpa do Rails e sim da plataforma do Ruby. Mas deve mudar consideravelmente com o Ruby 2, que vai sair sei lá quando, e também sei lá quando o Rails o suportará.

kicolobo:

Grails tem uma coisa que o Ruby não tem: ele roda em uma JVM.

Não sei como anda o Rails para o JRuby, esta seria uma vantagem, porém convém lembrar que é importante sabermos aonde nossa aplicação está sendo executada, e a plataforma Java, convenhamos, é fantástica!

O simples fato de você poder reaproveitar TODO o seu código legado em uma aplicação feita em Grails já o coloca, na minha opinião, anos luz à frente do Ruby on Rails. O que me prendia um pouco com relação ao RoR era exatamente o fato de que seria mais difícil aproveitar trabalhos passados que eu havia desenvolvido em Java.

Andei dando uma fuçada no Grails e fiquei realmente impressionado com o que vi. Em um aspecto, inclusive, o GRails passa o RoR: você não precisa configurar nada, tal como ocorre no RoR. Isto porque o GRails já vem com o HSQLDB embutido. Claro, esta não é lá uma grande vantagem, mas é um passo à frente.

Com certeza o GRails está na lista de minhas apostas para 2008 :)

David:

kicolobo:

Grails tem uma coisa que o Ruby não tem: ele roda em uma JVM.

Não sei como anda o Rails para o JRuby, esta seria uma vantagem, porém convém lembrar que é importante sabermos aonde nossa aplicação está sendo executada, e a plataforma Java, convenhamos, é fantástica!

O simples fato de você poder reaproveitar TODO o seu código legado em uma aplicação feita em Grails já o coloca, na minha opinião, anos luz à frente do Ruby on Rails. O que me prendia um pouco com relação ao RoR era exatamente o fato de que seria mais difícil aproveitar trabalhos passados que eu havia desenvolvido em Java.

Andei dando uma fuçada no Grails e fiquei realmente impressionado com o que vi. Em um aspecto, inclusive, o GRails passa o RoR: você não precisa configurar nada, tal como ocorre no RoR. Isto porque o GRails já vem com o HSQLDB embutido. Claro, esta não é lá uma grande vantagem, mas é um passo à frente.

Com certeza o GRails está na lista de minhas apostas para 2008 :)

O Rails para o JRuby é o mesmo Rails pra Ruby. Eu tenho um sistema que fiz usando Ruby on Rails em Mongrel e está em produção atualmente no Tomcat.

Seria interessante um comparativo com o JRuby, para saber a quanto anda o projeto nesse quesito.