Opa pessoal,
A ObjectCode.de publicou em seu site um relato da experiência que eles tiveram com a adoção do Grails para o desenvolvimento de suas aplicações.
Vale a pena dar uma conferida:
Até a próxima!
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:
-
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.
-
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?
-
A funcionalidade de “autocompletar” em arquivos .groovy é muito ruim, não colocando parentesis, por exemplo. De pouquinho em pouquinho vai se irritando com isso.
-
Não há um “debug” a como como para Java no Eclipse ou NetBeans.
-
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…
[quote=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?
-
A funcionalidade de “autocompletar” em arquivos .groovy é muito ruim, não colocando parentesis, por exemplo. De pouquinho em pouquinho vai se irritando com isso.
-
Não há um “debug” a como como para Java no Eclipse ou NetBeans.
-
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”).[/quote]
O IntelliJ Ultimate Edition tem tudo isso que vc falou… e pelo que dizem, o Netbeans melhou bastante o suporte a Grails, inclusive com debug, já deve ter a maioria dessas coisas que vc falou.
[]'s
Rodrigo C. A.
[quote]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… [/quote]
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!
[quote=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!!![/quote]
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:
-
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.
-
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:
-
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) -
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)) -
IDE é fundamental?
Pessoalmente, adoro trabalhar sem elas. E com Grails isto fica maravilhoso. -
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. -
Grails é bala de prata? NUNCA! Aqui explico o porquê. http://www.itexto.net/devkico/?p=496
-
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