Boas Práticas: Devo ou não utilizar plugins no Grails?
31/01/2013 19:31
0
Pessoal,
Tenho visto muita gente seguindo a regra de evitar utilizar plugins no Grails.
É um fato que alguns plugins não atualizam e causam bastante dor de cabeça no upgrade de versões do Grails. Já passei por uma situação em que sabia qual era o erro mas não podia ajustar e o criador do plugin só conseguiu ajustar depois de uma semana. Pior ainda se não der pra ter contato com o criador.
Porém existem vários plugins muito bem suportados, que inclusive foram agregados ao Grails como por exemplo o Resources Plugin e o JQuery Plugin. A maioria do Burt Beckwith e do Marc Palmer.
O que faço normalmente é utilizar o plugin somente se ele estiver sendo bem suportado (verificar qual foi o ultimo commit no repositorio do plugin). Caso não esteja, verificar se este plugin utiliza alguma biblioteca Java que pode lhe ajudar e tentar utilizá-la diretamente. Mas se o plugin vai adiantar muito seu trabalho de integração com o Grails ou tem um código mais elegante, basta instalar o plugin no modo "in-place".
Na instalação do plugin no modo "in-place" todo o código do plugin fica expandido localmente. Desta forma, caso ocorra um problema em uma possível migração de versão você tem a possibilidade de consertar o código.
E se você for um mestre Grails e o plugin estiver no Git, faça um fork, ajuste o plugin e continue contribuindo!
E você? Como utiliza os plugins do Grails? Quais plugins você utiliza com mais frequência? Já teve problemas de migração?
Tenho visto muita gente seguindo a regra de evitar utilizar plugins no Grails.
É um fato que alguns plugins não atualizam e causam bastante dor de cabeça no upgrade de versões do Grails. Já passei por uma situação em que sabia qual era o erro mas não podia ajustar e o criador do plugin só conseguiu ajustar depois de uma semana. Pior ainda se não der pra ter contato com o criador.
Porém existem vários plugins muito bem suportados, que inclusive foram agregados ao Grails como por exemplo o Resources Plugin e o JQuery Plugin. A maioria do Burt Beckwith e do Marc Palmer.
O que faço normalmente é utilizar o plugin somente se ele estiver sendo bem suportado (verificar qual foi o ultimo commit no repositorio do plugin). Caso não esteja, verificar se este plugin utiliza alguma biblioteca Java que pode lhe ajudar e tentar utilizá-la diretamente. Mas se o plugin vai adiantar muito seu trabalho de integração com o Grails ou tem um código mais elegante, basta instalar o plugin no modo "in-place".
Na instalação do plugin no modo "in-place" todo o código do plugin fica expandido localmente. Desta forma, caso ocorra um problema em uma possível migração de versão você tem a possibilidade de consertar o código.
E se você for um mestre Grails e o plugin estiver no Git, faça um fork, ajuste o plugin e continue contribuindo!
E você? Como utiliza os plugins do Grails? Quais plugins você utiliza com mais frequência? Já teve problemas de migração?
0
Como usar inplace Plugin no Grails?
Grails inplace plugin tip - BuildConfig.groovy
http://johnrellis.blogspot.com.br/2010/03/grails-inplace-plugin-tip.html
Grails inplace plugin tip - BuildConfig.groovy
http://johnrellis.blogspot.com.br/2010/03/grails-inplace-plugin-tip.html
31/01/2013 19:34
1
Outro bom motivo para utilizar plugins é modularizar uma aplicação Grails.
A técnica é chamada Plugin-Oriented Architecture e foi explicada de forma extensa em 2010 no blog da Spring.
What's Plugin-Oriented Architecture?
http://blog.springsource.com/2010/06/01/whats-a-plugin-oriented-architecture/
Recentemente houve uma apresentação sobre o assunto na 2GX muito boa, que seja abaixo:
Modularizing your Grails Application with Private Plugins - SpringOne 2GX 2012
http://www.slideshare.net/kennethaliu/modularizing-your-grails-application-with-private-plugins-springone-2gx-2012
Bons códigos!
A técnica é chamada Plugin-Oriented Architecture e foi explicada de forma extensa em 2010 no blog da Spring.
What's Plugin-Oriented Architecture?
http://blog.springsource.com/2010/06/01/whats-a-plugin-oriented-architecture/
Recentemente houve uma apresentação sobre o assunto na 2GX muito boa, que seja abaixo:
Modularizing your Grails Application with Private Plugins - SpringOne 2GX 2012
http://www.slideshare.net/kennethaliu/modularizing-your-grails-application-with-private-plugins-springone-2gx-2012
Bons códigos!
31/01/2013 19:38
0
Utilizo plugins de acordo com a necessidade. Acredito que o uso deva ser moderado, pq assim como vc citou, embora a modularização seja uma excelente prática, a utilização de plugins não muito bem suportados acaba sendo um belo tiro no pé.
Ao escolher o plugin, sempre verifico a última versão, qual o percentual da comunidade que o utiliza, entre outras informações.
Atualmente prefiro somente os indispensáveis, como o Spring Security (E esse ainda dependendo da necessidade da aplicação, caso não existam níveis de permissão diferentes, não há necessidade de utilizar uma bomba atômica para matar uma formiga), Resources, JQuery...
[]'s
Ao escolher o plugin, sempre verifico a última versão, qual o percentual da comunidade que o utiliza, entre outras informações.
Atualmente prefiro somente os indispensáveis, como o Spring Security (E esse ainda dependendo da necessidade da aplicação, caso não existam níveis de permissão diferentes, não há necessidade de utilizar uma bomba atômica para matar uma formiga), Resources, JQuery...
[]'s
31/01/2013 19:47
0
Opa, dar meu pitaco aqui.
O grande lance dos plugins é que eles aumentam sua produtividade ordens de magnitude. Claro: é um componente, alguém já fez o trabalho pra você. Isto é óbvio e não há muito o que ser dito.
Porém tem um lado negro nesta história: o plugin pode ser um elemento do seu projeto sobre o qual você não tem controle. Basicamente você não sabe de primeira mão o que rola lá dentro, e eu vejo pouquíssimas pessoas tendo a curiosidade de dar uma olhada no código fonte do que está sendo incluído no seu projeto.
Pra piorar ainda mais a situação, há plguins que simplesmente deixam de ser suportados. E não estou falando de plugins pouco usados. Vejam por exemplo o que ocorreu com o Acegi Plugin, que inicialmente era o mais usado plugin de segurança e que, do dia pra noite, parou de ser mantido, entrou em desuso e tudo mais.
Então, qual a solução pra isto: não suar plugins? Nâo. Isto é estúpido. Verificar se o último commit foi recente? Bobagem: tem código que é tão bem escrito que sofre realmente poucas alterações ou não precisa de novos recursos. Parece que não mas acontece muito, especialmente em engenharia, aonde trabalhei muitos anos, por exemplo.
Minha solução é simples, e é um guia bastante fácil de ser seguido.
1) Guarde o código fonte do seu plugin SEMPRE. Assim, caso suma do repositório principal (o que acontece e já ocorreu comigo) você pelo menos está seguro.
2) LEIA o plugin. Só pra lembrar, o plugin é uma aplicação Grails como outra qualquer. A diferença é que vai ser mesclada no código fonte do seu projeto.
3) Minimize o uso de plugins. Sim, isto mesmo. Vamos supor que você tenha na sua aplicação 398439847 de plugins. Cara: se precisar atualizar a versão do Grails, tenha certeza de que sua vida será um inferno. Então, antes de usar um plugin, eu sempre me pergunto o seguinte: que valor real isto trás pro meu projeto hein? Será que esta funcionaldiade que ele vai me fornecer, eu vou usar algo próximo de 80%? Se a resposta for não, talvez seja mais interessante estudar a possibilidade de eu mesmo implementar a funcionalidade, nem que seja literalmente copiando partes do código fonte do plugin que quero usar.
O importante é você ter controle sobre o código fonte que está no seu projeto. No caso do Grails, tem algo maravilhoso que difícilmente você encontra em outras plataformas: você pode ENTENDER o código fonte dos plugins porque é código similar ao que você já escreve normalmente, são as mesmas convenções.
Então, no final das contas, é isto aí. Ao usar plugins, basta seguir estas dicas.
O grande lance dos plugins é que eles aumentam sua produtividade ordens de magnitude. Claro: é um componente, alguém já fez o trabalho pra você. Isto é óbvio e não há muito o que ser dito.
Porém tem um lado negro nesta história: o plugin pode ser um elemento do seu projeto sobre o qual você não tem controle. Basicamente você não sabe de primeira mão o que rola lá dentro, e eu vejo pouquíssimas pessoas tendo a curiosidade de dar uma olhada no código fonte do que está sendo incluído no seu projeto.
Pra piorar ainda mais a situação, há plguins que simplesmente deixam de ser suportados. E não estou falando de plugins pouco usados. Vejam por exemplo o que ocorreu com o Acegi Plugin, que inicialmente era o mais usado plugin de segurança e que, do dia pra noite, parou de ser mantido, entrou em desuso e tudo mais.
Então, qual a solução pra isto: não suar plugins? Nâo. Isto é estúpido. Verificar se o último commit foi recente? Bobagem: tem código que é tão bem escrito que sofre realmente poucas alterações ou não precisa de novos recursos. Parece que não mas acontece muito, especialmente em engenharia, aonde trabalhei muitos anos, por exemplo.
Minha solução é simples, e é um guia bastante fácil de ser seguido.
1) Guarde o código fonte do seu plugin SEMPRE. Assim, caso suma do repositório principal (o que acontece e já ocorreu comigo) você pelo menos está seguro.
2) LEIA o plugin. Só pra lembrar, o plugin é uma aplicação Grails como outra qualquer. A diferença é que vai ser mesclada no código fonte do seu projeto.
3) Minimize o uso de plugins. Sim, isto mesmo. Vamos supor que você tenha na sua aplicação 398439847 de plugins. Cara: se precisar atualizar a versão do Grails, tenha certeza de que sua vida será um inferno. Então, antes de usar um plugin, eu sempre me pergunto o seguinte: que valor real isto trás pro meu projeto hein? Será que esta funcionaldiade que ele vai me fornecer, eu vou usar algo próximo de 80%? Se a resposta for não, talvez seja mais interessante estudar a possibilidade de eu mesmo implementar a funcionalidade, nem que seja literalmente copiando partes do código fonte do plugin que quero usar.
O importante é você ter controle sobre o código fonte que está no seu projeto. No caso do Grails, tem algo maravilhoso que difícilmente você encontra em outras plataformas: você pode ENTENDER o código fonte dos plugins porque é código similar ao que você já escreve normalmente, são as mesmas convenções.
Então, no final das contas, é isto aí. Ao usar plugins, basta seguir estas dicas.
31/01/2013 20:10
0
Depois de varias dores de cabeça, comecei a tomar MUITO cuidado com os plugins.
Varios plugins vem com muita dependência, e que podem afetar o projeto
Já aconteceu de bugar do nada e descobrir que o plugin tinha dependencia de uma biblioteca 1.0.1 e o meu projeto da mesma biblioteca, só que 1.1.1
Se os plugins fizerem muita coisa e usarem outras biblitecas, tome cuidado (multifile uploader, bootstrap file upload, kickstart).
Se tiverem uma funcao especifica (resources, jquery, foundation, bootstrap, hibernate, etc) não costumam dar problema
Sempre acontece de um plugin entrar certinho para o que você quer, então use ué. Mas leia a documentação
Varios plugins vem com muita dependência, e que podem afetar o projeto
Já aconteceu de bugar do nada e descobrir que o plugin tinha dependencia de uma biblioteca 1.0.1 e o meu projeto da mesma biblioteca, só que 1.1.1
Se os plugins fizerem muita coisa e usarem outras biblitecas, tome cuidado (multifile uploader, bootstrap file upload, kickstart).
Se tiverem uma funcao especifica (resources, jquery, foundation, bootstrap, hibernate, etc) não costumam dar problema
Sempre acontece de um plugin entrar certinho para o que você quer, então use ué. Mas leia a documentação
01/02/2013 12:24
0
E se o desenvolvedor decidir modularizar sua propria aplicação com a criação de diversos plugins de sua própria produção, isso possui algum impacto no desempenho?
03/02/2013 19:14
0
@Mussato
No Grails 1.x, os plugins 'bem feitos' não deixam os jars embutidos (a maior causa de problemas nesta versão) mas deixam o próprio Grails resolver. Se o plugin tiver libs internas, o recomendado é utilizar a opção "in-place" e remover as libs que causam conflito.
A partir do Grails 2.0 este problema foi completamente resolvido com o Resources Plugin que já vem embutido. Ele também resolve dependências entre plugins (plugin que precisa de outro pra funcionar). Todo plugin mantido hoje *deve* suportar o Resources pois é a boa prática. Esta é outra dica pra verificar se o plugin está sendo suportado.
No Grails 1.x, os plugins 'bem feitos' não deixam os jars embutidos (a maior causa de problemas nesta versão) mas deixam o próprio Grails resolver. Se o plugin tiver libs internas, o recomendado é utilizar a opção "in-place" e remover as libs que causam conflito.
A partir do Grails 2.0 este problema foi completamente resolvido com o Resources Plugin que já vem embutido. Ele também resolve dependências entre plugins (plugin que precisa de outro pra funcionar). Todo plugin mantido hoje *deve* suportar o Resources pois é a boa prática. Esta é outra dica pra verificar se o plugin está sendo suportado.
04/02/2013 03:11
0
@Kico
O Acegi Plugin virou o Spring Security Plugin. Ele foi feito novamente seguindo boas práticas depois que a Spring comprou a G2X e renomeou o Acegi para Spring Security.
Verificar se tem commit de código está longe de ser bobagem. Todo bom plugin do Grails tem commits constantes. Se não tem é um sinal claro que o criador não está investindo tempo no plugin. Se ele é suportado, sempre irão surgir melhorias e extensões: criatividade para melhorar não falta.
O Acegi Plugin virou o Spring Security Plugin. Ele foi feito novamente seguindo boas práticas depois que a Spring comprou a G2X e renomeou o Acegi para Spring Security.
Verificar se tem commit de código está longe de ser bobagem. Todo bom plugin do Grails tem commits constantes. Se não tem é um sinal claro que o criador não está investindo tempo no plugin. Se ele é suportado, sempre irão surgir melhorias e extensões: criatividade para melhorar não falta.
04/02/2013 03:17
0
@llmon
Como o Kico disse, não há nenhum impacto. Porque o plugin tem a mesma estrutura de um projeto Grails e no ato do build ele é mesclado em 1 só projeto. :-D
PS.: A arquitetura de plugins é fantástica. Não sei de onde o Graeme Rocher tirou a idéia, mas quem pensou nisso é um gênio. Simples e poderoso.
Como o Kico disse, não há nenhum impacto. Porque o plugin tem a mesma estrutura de um projeto Grails e no ato do build ele é mesclado em 1 só projeto. :-D
PS.: A arquitetura de plugins é fantástica. Não sei de onde o Graeme Rocher tirou a idéia, mas quem pensou nisso é um gênio. Simples e poderoso.
04/02/2013 03:19
0
Alguns princípios que atualização de versão de plataforma/framework que pratico:
- Em desenvolvimento: atualizar imediatamente para as versões mais recentes.
- Se o sistema ou site for um produto (sistema para alguma vertical de indústria ou site que presta um serviço) e estiver em produção, negociar com a gerência de manutenção e evolução do produto uma agenda para atualização constante. O ideal é ter casos de testes funcionais para eliminar bugs de regressão, de preferência automatizados com Selenium ou Geb por exemplo.
- Se o sistema ou site for especialista (sistema pra um processo de negócio especifico da empresa ou site institucional), vai depender do contrato de manutenção. Se o contrato for longo (mais de 1 ano), vale a pena agendar atualizações para evitar que o sistema ou site 'quebre' futuramente. Caso contrário vale a máxima 'Não conserte o que não está quebrado'.
- Em desenvolvimento: atualizar imediatamente para as versões mais recentes.
- Se o sistema ou site for um produto (sistema para alguma vertical de indústria ou site que presta um serviço) e estiver em produção, negociar com a gerência de manutenção e evolução do produto uma agenda para atualização constante. O ideal é ter casos de testes funcionais para eliminar bugs de regressão, de preferência automatizados com Selenium ou Geb por exemplo.
- Se o sistema ou site for especialista (sistema pra um processo de negócio especifico da empresa ou site institucional), vai depender do contrato de manutenção. Se o contrato for longo (mais de 1 ano), vale a pena agendar atualizações para evitar que o sistema ou site 'quebre' futuramente. Caso contrário vale a máxima 'Não conserte o que não está quebrado'.
04/02/2013 05:30
Ainda não faz parte da comunidade???
Para se registrar, clique aqui.
Aprenda Groovy e Grails com a Formação itexto!
Newsletter Semana Groovy
Os melhores blogs de TI (e em português) em um único lugar!
