Grails: O relato de uma experiência

O Grails já é bem forte, e curioso notar que em especial Inglaterra e Alemanha são heavy users.

Pena que no Brasil o Grails ainda não emplacou, apesar de achar que isso uma hora vai acontecer.

abs

O melhor é que a maioria ( todos?! ) dos erros que eles citam já foram corrigidos a bastante tempo, isso prova que o framework está em constante evolução.

E sobre o que eles falam que “o Grails é bom para uma aplicação pequena” já foi superado também, por exemplo a Sky:

E a SAP que fez uma integração com o Grails:

abs!!!

Eu quase use Grails em vez de Ruby on Rails pra poder usar Hiberate…

Eu já estou usando Grails para todos os meus projetos !!! Não tenho o que reclamar, a produtividade aumentou muito e a alegria em desenvolver voltou tb !!!

Herrera

Poxa, assim não dá! Outro dia, estava pensando se estudava Ruby ou Groovy (o que implica Rails ou Grails). :lol:
Embora sejam parecidos em alguns aspectos, tinha me decidido pelo Ruby por ter visto posts do pessoal reclamando da performance do Groovy. Não que Ruby tenha uma performance fantástica, mas sei lá… de repente o pessoal cisma com isso. Além disso, a comunidade de Ruby (& Rails) cresceu bastante por aqui, provavelmente hoje existe mais oportunidade para Ruby (mas isso é uma especulação minha…).

Se o pessoal realmente está evoluindo rápido, talvez o pessoal que tem postado sobre isso não saibia o que está fazendo.

Antes que o pessoal comece a jogar pedra, cheguei a essa conclusão por ter bastante posts reclamando da performance. Mas como a maioria deles data de 2007, não posso afirmar nada de como está hoje.

Alguém saberia dizer se conhece um bom comparativo de ambos? (Isso porque estou excluindo o Phyton…)

Nunca é bom colocar comparativos aqui no GUJ, sempre vira discussão não produtiva.

Sobre a performance, sim, ela melhorou MUITO desde 2007 e vai melhorar ainda mais com a chegada do InvokeDynamic do Java 7.

Para quem não puder usar o Java 7 existe o projeto Groovy++ que da ao Groovy uma tipagem estática melhorando ainda mais a performance dele.

Vendo casos como o da Sky não ficaria com receios sobre performance.

Abraços!!!

bem interessante!

Eu fiquei muito empolgado com o Grails ano passado. Realmente é cheio de coisas legais… MAS… fiquei decepcionado após ver que:

1. Não há ferramente de engenharia reversa “Banco -> GORM”. Imagina criar centenas de classes “no braço” para mapear centenas de tabelas. Imagine depois o tempo testando se os mapeamentos estão corretos, visto que foram feitos manualmente.

2. Não há ferramenta de “autocompletar” os códigos de taglib nos GSPs. Você tem que ficar lendo PDF ou HTML de documentação das taglibs. Depois de quanto tempo o individuo consegue decorar tudo?

3. A funcionalidade de “autocompletar” em arquivos .groovy é muito ruim, não colocando parentesis, por exemplo. De pouquinho em pouquinho vai se irritando com isso.

4. Não há um “debug” a como como para Java no Eclipse ou NetBeans.

5. Enfim, não há IDE produtiva para Grails (eu sei que existe a corrente que vai dizer que possuo “IDE dependência”, mas considero isso o mesmo que dizer que um bom engenheiro civil faz tudo sem AutoCad porque ele não quer “autocad dependência”).

Desenvolver em Struts2 ou VRaptor com uso das facilidades para Java e JSP que as IDEs oferecem acaba sendo mais produtivo, na minha opinião.

Isso não me incomoda. Acho muito mais produtivo o contrário, depois só dou uma melhorada nos índices do banco. E sinceramente, as classes GORM são tão simples, que acho que daria pra fazer uma ferramenta pra gerar a partir de um banco rapidinho…

jyoshiriro:

2. Não há ferramenta de “autocompletar” os códigos de taglib nos GSPs. Você tem que ficar lendo PDF ou HTML de documentação das taglibs. Depois de quanto tempo o individuo consegue decorar tudo?

3. A funcionalidade de “autocompletar” em arquivos .groovy é muito ruim, não colocando parentesis, por exemplo. De pouquinho em pouquinho vai se irritando com isso.

4. Não há um “debug” a como como para Java no Eclipse ou NetBeans.

5. Enfim, não há IDE produtiva para Grails (eu sei que existe a corrente que vai dizer que possuo “IDE dependência”, mas considero isso o mesmo que dizer que um bom engenheiro civil faz tudo sem AutoCad porque ele não quer “autocad dependência”).

[]'s

Rodrigo C. A.

jyoshiriro wrote:
Isso não me incomoda. Acho muito mais produtivo o contrário, depois só dou uma melhorada nos índices do banco. E sinceramente, as classes GORM são tão simples, que acho que daria pra fazer uma ferramenta pra gerar a partir de um banco rapidinho…

Tem certeza? Imagine 90 tabelas, sendo 50 delas com 20 campos. Pense agora em todos os relacionamentos. Por mais simples que GORM seja, dá MUITO trabalho configurar tudo “no braço”.
Repito: imagne tembém testar se tudo ficou certinho (campos, chaves, relacionamentos).
Veja, eu acho GORM brilhante, fantástico, fora de série. Mas a falta de uma ferramenta de eng. reversa é um baita ponto negativo, sim.

Bem, nunca usei o IntelliJ Ultimate Edition. Mas se for para usar ferramenta paga, prefiro usar o Visual Studio .NET que, mesmo sendo amante do Java, admito que é muito mais produtivo.
A versão free do IntelliJ não dá suporte a Grails, não é?
Quanto ao NetBeans, só dá suporte para a versão 1.1 do Grails que já está muito aquem da atual 1.3.x.

assim, errr… IDE grails não é o Spring Source Tool Suite?! O resto é resto?

Mas é exatamente essa “Spring Source Tool Suite” que não tem debug (tem mas é bem pior que os que estamos acostumados), que não tem autocompleter em GSP, que tem autocompleter meia boca para arquivos .Groovy, que não tem eng. reversa de GORM…

A saber, a última versão dela eu baixei e testei há cerca de 1 mês.

Antes que digam “mas tem autocomplete em GSP, sim”.
É, até tem, mas não acha todos os atributos da documentação e, quando acha, não aparece em “javadoc” dizendo para que serve o atributo. E depois de algumas mexidas no arquivo GSP, o autocomplete de taglib simplesmente some totalmente!
Dai, se você tentar declarar as taglibs do Grails na diretiva de página, ele até acha algumas coisas no autocomplete mas quando vai rodar diz que a diretiva de importação das tags Grails está duplicada! Aí é dose, né? Eu não tenho coragem de pedir para minha equipe decorar ou ficar dando “alt+tab” na documentação de tags do grails…

O Grails ainda é novo, e vem crescendo bastante e com isso o o suporte das Ide’s vai melhorar também. Já trabalhei com o NetBeans e Spring Tool Suite e gostei bastante, das duas, sem falar que a documentação é muito boa!

mcbarsotti:

E sobre o que eles falam que “o Grails é bom para uma aplicação pequena” já foi superado também, por exemplo a Sky:

abs!!!

Isso prova que Grails é um framework web funcional, mas um bom programador web consegue atender milhoes de pageviews com qualquer linguagem, isso porque HTTP escala.

O Grails me parece um excelente framework, porém não animei de usá-lo em produção pelos seguintes motivos:

1. Ausência de uma biblioteca de componentes estilo o PrimeFaces, onde existe uma quantidade boa componentes e não é necessário escrever “costuras” em JavaScript.

2. Conforme mencionado pelo jyoshiriro, quando testei o Grails no NetBeans o debug não funcionava.

Quanto ao uso de bases legadas, existe um plugin para integração com JPA, portanto acho que seria possível fazer a engenharia reversa pelo NetBeans e usar os Entity Beans gerados no Grails.

Opinião minha, mas sinceramente, eu prefiro usar Grails sem IDE e sem “bibliotecas de componentes” do que usar JSF com tudo isso…

Olha, um post sobre Grails no GUJ!

Bom: sou suspeito pra falar a respeito, mas aqui vão algumas informações legais:

1. Há ferramentas para fazer engenharia reversa a partir do BD? Yeap! Se chama GRAG: http://grag.sourceforge.net/
   É legal? Não sei: nunca usei. Mas conheço pessoas que tiveram bastante sucesso com a ferramenta.
   (ai entra a questão se realmetne é bacana criar uma apliacção a partir do BD ou vice-versa. Pessoalmente, vejo o BD como o resultado de um processamento, e não o contrário. Mas isto é papo para outra conversa)

2. Auto completar em IDEs.
   O mesmo problema vejo com a maior parte das linguagens dinâmicas, mas a coisa tem melhorado bastante. Netbeans e Eclipse tem cada vez melhorado o suporte.
   (pessoalmente, sei que auto completar é bacana e tal, mas o que observo é que emburrece uma galera, que fica viciada no recurso e sem ele não consegue se virar (papo para outro tópico))

3. IDE é fundamental?
   Pessoalmente, adoro trabalhar sem elas. E com Grails isto fica maravilhoso.

4. Ausência de componentes
   A biblioteca de plugins que podem ser reaproveitados é imensa (logo, não é problema): http://grails.org/Plugins
   E o que é mais bacana: depois da versão 1.2 você ainda pode usar bibliotecas de tag tradicionais sem problema.

5. Grails é bala de prata? NUNCA! Aqui explico o porquê. http://www.itexto.net/devkico/?p=496

6. Grails não pegou no Brasil.
   Mito. Pelo menos em BH práticamente todas as softwares house possuem ao menos um projeto baseado no framework (minha empresa que o diga )
   E dado o número de usuários ativos do Grails Brasil, comparado aos demais grupos de usuários, o mito morre de vez.

E pra finalizar, alguns links pra quem se interessar pelo framework:

Grails Brasil: o grupo de usuários brasileiros. http://www.grailsbrasil.com
Tenho escrito um guia sobre Grails online (é incompleto e sempre será, mas quem sabe ajuda alguém?) http://guiagrails.itexto.com.br

Quer aprender mais? Segue uma lista com diversos recursos legais pra quem estiver começando: http://www.itexto.net/devkico/?p=603

E, finalmente, como uso Grails, para que não fique a impressão de que você é obrigado a usar todo o stack do framework sempre: http://www.itexto.net/devkico/?p=739

Ah, e antes que me esqueça, um pedido.

É muito comum as pessoas se apaixonarem por Grails e se tornarem seres insuportáveis (fan boys). Sendo assim, caso seja o seu caso, segura a empolgação ok? Pessoas ultra empolgadas são muito, muito chatas.

+1.

Até acho que suporte das IDEs é importante, mas parece que a maioria do pessoal que reclama simplesmente não esta acostumado a essas novas linguagens dinâmicas para aproveitar o ganho de produtividade que elas oferecem.

Tópico antigo, mas só pra constar que:

mantenho minhas opiniões sobre o problema de IDE. Se alguém se acha um “super humano” capaz de decorar centenas de paginas de documentação à usar um “ctrl+espaço” para ver o que pode digitar e ver o java-doc do recurso, parabéns, mas não é o caso da maioria.

Dou aulas de Programação, Java, HTML e afins desde 2003 e sinto que a curva de aprendizado sem os “auto-completers” é MUUUUITO mais alta, mesmo para os melhores alunos. A ausência disso simplesmente vai criando uma tremenda antipatia! Eu aprendi a programar no DBase, passando por Basic e Clipper. Inclusive criei como que um “Show do Milhão” em Clipper. Portanto, sei que dá pra programar sem que a IDE te sugira algo e diga pra que serve. Mas que isso ajuda MUITO, mesmo os mais “safos” e experientes, isso ajuda. Não penso que isso deixe ninguém burro, ao contrário, ajuda a aprender e aumenta em muito a produtividade. Quem tem prequiça mental ou QI baixo mesmo será improdutivo com ou sem recursos como “autocompletar”. E mais: autocompletar não é obrigatório. Portanto só sua falta é sentida e não sua presença.

Quanto ao “GRAG”, desde sua criação só possui 44 dowloads (vejam no site)! E sua última atualização foi em 07/2009. De lá pra cá o GORM mudou muito!
Ora acredito que seja muito comum você fazer um sistema novo em cima de uma base de dados legada. Nesse caso, não tem saída: Deve-se reescrever e testar TODAS as classes de entidade. A existência dessa ferramenta não obrigaria ninguém a usá-la. Portanto, sua falta é sentida. Sua presença não seria incomodo pra ninguém. O Rails faz isso e é uma das funcionalidades que mais chamam atenção positivamente.

Se alguém acha “maravilhoso” trabalhar com grails sem IDE, parabéns pela memória fora de série ou “paciência de jó” pra ficar dando “alt-tab” e “crtl+f” em documentação porque imagino que 19 em cada 20 programadores não têem. Nesse caso, a produtividade do grails se daria pela genialidade do público que convence ou pelos seus próprios méritos?

Quanto às “bibliotecas”, nenhuma disponível chega perto, nenhum pouco, das “Icefaces”, “primefaces” ou “richfaces” da vida. Para componentes como abas, tabelas e diálogo com Grails haja braço pra escrever javascript em Jquery, Ext ou Prototype! Fora o montão de HTML no braço também! Até o Struts2 tem uma série de taglibs que deixa transparente o uso do Jquery para dezenas de componentes visuais. Se alguém diz que consegue ser mais produtivo escrevendo todo esse código na mão, meus parabéns, você tem QI e velocidade/taxa de acerto de digitação muito acima da média! Nesse caso, a produtividade do grails se daria pela genialidade do público que convence ou pelos seus próprios méritos?

Quanto ao Grails emplacar ou não… bem, se for no Google Trends e filtrar Grails contra Java, Rails ou outro framework web Java mais conhecido, Grails sempre leva sonoras “surras”. Isso tanto se gerar a estatística mundial quanto a brasileira somente. Até mesmo pro PHP o Grails perde feio! Vejamos quantos sites/blogs especializados em Grails existem no Brasil: O grailsbrasil, o blog itexto (do mesmo fundador do grailsbrasil) e uma dúzia de blogs e grupos… Muito pouco pra dizer “emplacou”, na minha opinião. E mais: Perguntei pra 2 amigos meus que trabalham em SP (cidades diferentes) e um que voltou há pouco do RS e só tinham “ouvido falar” de Grails. Sei que é uma amostragem muito insignificante, mas todos conheciam bem mais Rails, Seam e cia.

Não quero que ninguém pense que sou anti-grails. Ao contrário, sou apaixonado pela tecnologia. Faço até propaganda dela para conhecidos. Só que acredito que se ela tivesse uma IDE com debug melhor, com autocomplete melhor e com engenharia reversa banco->GORM teria bem mais destaque e uso no Brasil e no mundo. Novas taglibs viriam “por tabela” com essa popularização. Continuo apostando nela e sempre criando projetos pequenos “de brincadeira” aqui e ali.

De minha última postagem até hoje alguma coisas mudaram: O autocomplete de GSP melhorou muito no STS e o suporte ao Grails está bem melhor no Netbeans. Pena que no segundo simplesmente há 0 autocomplete de GSP, senão seria a melhor IDE para Grails, na minha opinião. Assim, mantenho minhas esperanças de que o Grails “emplaque” pra valer.

Por fim, espero que esse post melhore a qualidade e atualize essa thread para melhor orientar os que estão pensando em adotar Grails em novos projetos.

jyoshiriro:

Eu fiquei muito empolgado com o Grails ano passado. Realmente é cheio de coisas legais… MAS… fiquei decepcionado após ver que:

1. Não há ferramente de engenharia reversa “Banco -> GORM”. Imagina criar centenas de classes “no braço” para mapear centenas de tabelas. Imagine depois o tempo testando se os mapeamentos estão corretos, visto que foram feitos manualmente.

2. Não há ferramenta de “autocompletar” os códigos de taglib nos GSPs. Você tem que ficar lendo PDF ou HTML de documentação das taglibs. Depois de quanto tempo o individuo consegue decorar tudo?

3. A funcionalidade de “autocompletar” em arquivos .groovy é muito ruim, não colocando parentesis, por exemplo. De pouquinho em pouquinho vai se irritando com isso.

4. Não há um “debug” a como como para Java no Eclipse ou NetBeans.

5. Enfim, não há IDE produtiva para Grails (eu sei que existe a corrente que vai dizer que possuo “IDE dependência”, mas considero isso o mesmo que dizer que um bom engenheiro civil faz tudo sem AutoCad porque ele não quer “autocad dependência”).

Desenvolver em Struts2 ou VRaptor com uso das facilidades para Java e JSP que as IDEs oferecem acaba sendo mais produtivo, na minha opinião.

O que nos torna muito dependente desses recursos da IDE, infelizmente. Bom, mas pode-se ver o Play Framework, que tem todas facilidades desses frameworks ruby like e usa a própria linguagem Java, ou seja, todos os recursos da IDE são disponíveis. Achei muito bom.

Bem, não sei se podemos usar taaanto assim IDEs Java com o play. Vi lá que não usa taglibs e sim umas expressions. Dai recaimos no problema de ficar dando “alt-tab” e “ctrl+f” em documentação até decorar tudo. E fora a questão da criação de RIA, pois parece que nele deve-se apelar novamente para pilhas de HTML e Javascript “no braço” para tal (é isso mesmo que é feito no video de apresentação no site do framework).

E mais: As classes de entidade estendem uma classe lá “Model”. Logo, fica complicado engenharia reversa Banco -> Classe, né?

Bem, mas ainda assim é o mais perto que o Java parece ter chegado do Rails ^^’

jyoshiriro:

Tópico antigo, mas só pra constar que:

mantenho minhas opiniões sobre o problema de IDE. Se alguém se acha um “super humano” capaz de decorar centenas de paginas de documentação à usar um “ctrl+espaço” para ver o que pode digitar e ver o java-doc do recurso, parabéns, mas não é o caso da maioria.

Dou aulas de Programação, Java, HTML e afins desde 2003 e sinto que a curva de aprendizado sem os “auto-completers” é MUUUUITO mais alta, mesmo para os melhores alunos. A ausência disso simplesmente vai criando uma tremenda antipatia! Eu aprendi a programar no DBase, passando por Basic e Clipper. Inclusive criei como que um “Show do Milhão” em Clipper. Portanto, sei que dá pra programar sem que a IDE te sugira algo e diga pra que serve. Mas que isso ajuda MUITO, mesmo os mais “safos” e experientes, isso ajuda. Não penso que isso deixe ninguém burro, ao contrário, ajuda a aprender e aumenta em muito a produtividade. Quem tem prequiça mental ou QI baixo mesmo será improdutivo com ou sem recursos como “autocompletar”. E mais: autocompletar não é obrigatório. Portanto só sua falta é sentida e não sua presença.

…

Mandou bem. Por um instante achei que só eu gostava de usar IDE :lol:. No caso do .NET por exemplo, o que seria dele sem o Visual Studio?

Migrei do Grails para Rails, achei este último bem melhor, mais maduro, leve e estável. Tem Gems maravilhosas para fazer tudo o que é mais necessário em uma aplicação Web de forma simples, e a comunidade extremamente movimentada. O suporte a Rails no Netbeans é bem melhor também e sempre está evoluindo, ao contrário do de Grails que parece estar abandonado.

Bem, quanto ao suporte ao Rails no Netbeans, o que eu disse não é mais válido http://netbeans.org/community/news/show/1507.html

jyoshiriro:

Bem, não sei se podemos usar taaanto assim IDEs Java com o play. Vi lá que não usa taglibs e sim umas expressions. Dai recaimos no problema de ficar dando “alt-tab” e “ctrl+f” em documentação até decorar tudo. E fora a questão da criação de RIA, pois parece que nele deve-se apelar novamente para pilhas de HTML e Javascript “no braço” para tal (é isso mesmo que é feito no video de apresentação no site do framework).

E mais: As classes de entidade estendem uma classe lá “Model”. Logo, fica complicado engenharia reversa Banco -> Classe, né?

Bem, mas ainda assim é o mais perto que o Java parece ter chegado do Rails ^^’

Sim, mas não é a proposta do Play Framework. Ele, portanto, não é um framework de componentização (widgets como JSF), portanto, o seu foco talvez fosse mais adequado para sites e portais do que aplicações web, mas mesmo assim, não há como desmerecer a sua capacidade. Ele é MUITO bom, dei uma olhada breve, fiz pouca coisa nele, mas é sem dúvida, muito bom.

Ai galera.

Eu estou um pouco confuso. Agradeço que me expliquem o que eh groovy e grails e ruby on rails. Quais sao as diferencas com o java normal e se sao frameworks ou uma nova linguagem.

Obrigado!javascript:emoticon(’:lol:’);

Vc ressuscitou um tópico antigo só para perguntar coisas que são facilmente achadas em qualquer mecanismo de busca? Não faça isso. Se precisa mesmo ressuscitar um tópico, faça somente se for adicionar algo realmente relevante.

upss. Foi mal. Peço desculpas.