Porém, classificar o Grails apenas como um Framework seria resumir conceitualmente sua verdadeira identidade, pois na realidade podemos afirmar que ele é Plataforma que implementa outras ferramentas e frameworks consolidados do mundo Java, tais como Hibernate, Spring, Hsqldb, JUnit, Apache Ant, Sitemesh, sendo que todo o ambiente de desenvolvimento já vem disponível no Grails, inclusive um servidor web.

Os desenvolvedores já habituados a essas tecnologias perguntarão:

Quantas semanas levaríamos para configurar arquivos XMLs para integrar tudo isso no Grails?

Resposta simples: Nenhuma, pois ele já possui todas essas tecnologias prontas e integradas, nos abstraindo dessas configurações chatas e repetitivas. Dessa forma, o desenvolvedor vai se preocupar mais com as regras de negócio e com o sistema do que com a implantação do ambiente de desenvolvimento.

Dentre as diversas vantagens do Grails, posso citar algumas que mais me chamam atenção:

• Antes de tudo, ele é Java. Isso quer dizer que podemos utilizar no Grails todo o leque de opções disponíveis para a Plataforma Java de forma transparente, inclusive os servidores WEB;
• Automatização de trabalhos repetitivos, reduzindo dessa forma esforço de trabalho em tarefas tediosas;
• Código baseado em convenção: padronização nos projetos;
• Foco nos modelos da aplicação, não no banco de dados;
• É extremamente divertido desenvolver com Grails.

Porém, tudo na vida tem seu lado bom e seu lado ruim. Sendo assim cito como desvantagens:

• A pouca aderência ao Grails de desenvolvedores Java. Costumo brincar que o desenvolvedor Java tem um perfil masoquista, gosta de sofrer com coisas mais difíceis, logo o Grails vai contra essa filosofia : P
• A outra desvantagem é decorrente da primeira, pois vejo que a Comunidade Grails de desenvolvedores ainda é pouco ativa comparada a outras comunidades como Java e Ruby on Rails.

Sendo o NetBeans uma das principais IDEs utilizadas pelos masoquistas…ops… desenvolvedores Java e levando em consideração que a mesma na sua nova versão (6.5) vem com um excelente suporte para desenvolvimento em Grails. Penso que essa aderência ao Grails tende aumentar e conseqüentemente virá o aumento da comunidade.

Enfim, uma coisa posso afirmar com certeza: Grails é o melhor Framework para desenvolvimento WEB do “mundo” Java que já trabalhei.

Abraços e até próxima!

–Ronny Peterson

Referências:

http://www.grails.org

http://www.grailsbrasil.com.br

http://www.devmedia.com.br – Vídeos-Aulas de Grails
Revista Java Magazine Edição 59

Sua utilização é bem simples:
$('#example1').priceFormat();
O código anterior retorna o seguinte formato :
US$ 0.00
O plugin que me agradou muito pela flexibilidade, onde é possível customizá-lo para qualquer tipo de moeda, exemplo:
$('#example2').priceFormat({
prefix: 'R$ ',
centsSeparator: ',',
thousandsSeparator: '.'
});
Agora, o código anterior retorna algo com o seguinte formato:
R$ 1.234,56
Sem contar que foi desenvolvido por um brasileiro.
Meus parabéns para Eduardo Cuducos pela iniciativa.

O plugin na versão 1.0 pode ser baixado aqui, para maiores informações, acesse o site do desenvolvedor.

Autor: Daniel Freire

No ambiente empresarial, a comunicação têm uma influência significativa, uma vez que as decisões tomadas pelos gestores, bem como as atividades que devem ser executadas pelos empregados, dependem da qualidade da informação e isso depende da forma como a mesma foi comunicada.

Aos domingos, costumo assistir aos conselhos do Prof.º Marins, e ele constantemente fala sobre a importância de uma boa comunicação nas empresas.

Achei interessante anotar seus conselhos e dividi-los com todos. Como desenvolvedor, achei útil, pois o sucesso de um projeto de desenvolvimento de sistemas depende – no meu ponto de vista – 60 % da comunicação entre os clientes e os desenvolvedores, bem como da comunicação interna da equipe.

O cliente que sabe informar exatamente o que deseja e uma equipe com uma boa comunicação interna, agiliza o processo e evita a correção desnecessária no código, porém a falha na comunicação pode gerar desenvolvimento desnecessário e erros na implementação.

Portanto, devemos melhorar nosso processo de comunicação com os clientes e também com a própria equipe de desenvolvimento. Aí vai algumas dicas do Prof.º Marins:

* Quanto melhor a qualidade de informação…melhor a qualidade da decisão;

* Devemos facilitar o fluxo da informação, deixando o mais direto possível, ou seja, evite “atravessadores” desnecessários, pois isso gera ruídos na informação e podem gerar decisões erradas;

* Incentive a liberdade de expressão dentro da equipe. As pessoas devem ter liberdade para dizer o que pensam, bem como devem ser incentivadas a sugerir melhorias no processo produtivo;

* Lembre-se: As decisões são frutos da informação.

Porém existe uma corrente de desenvolvedores ágeis que pregam o foco apenas no desenvolvimento e que as demais atividades são burocráticas e chatas, inclusive já ouvi o seguinte absurdo: “A documentação mais importante é realizada com comentários no código-fonte”.

Concordo com os comentários no código-fonte, isso é uma excelente prática e deve sim ser utilizada e incentivada, porém apenas isso não garante a qualidade. Desenvolver um software vai muito além de apenas sentar à frente do computador e programar, isso é uma visão limitada e deve ser combatida.

A construção civil é um bom exemplo para comparar com a engenharia de software, pois tentem construir uma casa ou prédio sem nenhum tipo de planejamento ou projeto, simplesmente comprando a cada dia o necessário e ir subindo as paredes…pode até sair, porém a possibilidade de não dar certo é muito grande. Por mais simples que seja a construção, você precisará de um desenho das divisões, saber o tamanho das paredes, portas, etc. Enfim, é necessário um planejamento e o acompanhamento da execução.

Para desenvolver sistemas também precisamos planejar e controlar a execução, é importante destinarmos esforços para documentação, porém temos que saber o que é importante documentar, quais modelos realmente são necessários. Para isso não existe uma fórmula única, pois um diagrama de classes pode ser desnecessário em um projeto e essencial em outro.

Lembre-se que o sistema terá a fase de manutenção e evolução, porém nem sempre serão as mesmas pessoas que realizarão essas atividades. Portanto, não documentar pode ser ágil em primeiro momento, mas pode ser prejudicial no futuro.

Mas o que seria um desperdício em um projeto de software?

É a execução de uma tarefa que não agregará valor ao negócio do cliente. Poderia citar inúmeros exemplos, porém antes, é melhor deixar bem claro que não existe uma regra geral (principalmente tratando em projetos de software), pois uma atividade de documentação das descrições de caso de uso pode ser desperdício para uma função de cadastro simples, tendo em vista sua pouca complexidade, mas pode ser imprescindível em uma funcionalidade mais complexa, é por isso que o gerente do projeto deve ter a capacidade de reconhecer uma tarefa desnecessária ou de pouca importância ao negócio do cliente.

Os desenvolvedores (analistas e programadores) também devem se policiar para evitar as “viagens na maionese” durante a modelagem e implementação das funções, pois muitas vezes temos a péssima mania de inventarmos arquiteturas complexas, uso de novos frameworks, padrões de projeto, linguagens de programação etc. só para termos o prazer de estudar a nova tecnologia.

Um projeto de software eficaz visa a satisfação do cliente e o mesmo visa o retorno o mais rápido possível do investimento realizado, logo, reduza as gorduras de seu projeto, não invente sem necessidade e procure fornecer funções que agreguem valor…da forma mais ágil possível.

Para mais informações:

• 5.ª Edição da Revista Ágil – http://www.visaoagil.com/

Depois de conversarmos, chegamos a conclusão que a criação de um blog seria interessante por diversos motivos; poderia enumerar vários, porém o tempo é curto e só vou citar o principal:

• Compartilhar conhecimentos e experiências -> Quantos problemas já resolvemos a partir de informações adquiridas em blogs…nossa, nem conseguiria contar. Muitas vezes implementamos soluções até melhores, porém a raiz do conhecimento era proveniente das informações “postadas” em blogs. Ora, temos know how suficiente para também começar a compartilhá-lo e, dessa forma, contribuir para o desenvolvimento de software com qualidade

Enfim, poderia citar vários motivos, mas tenho que trabalhar e não posso ficar muito tempo “postando” ; )

Abraços