Utilizando Grails na NetSoft

Tchau querido desktop! Resolvemos desenvolver uma versão Web de um aplicativo comercial da NetSoft utilizando o framework Grails. O Resultado está sendo satisfatório, visto que não temos que nos preucupar com a complexa arquitetura envolvida na instalação da versão desktop que envolvia módulos EJB3 rodando no JBOSS AS.

Outro grande resultado é a rapidez com que um aplicativo WEB é desenvolvido em Grails. Sem XML, apenas convenções. Apesar de radicalmente termos mudado muito a arquitetura, o core ( o modelo de domínio) foi apenas adaptado à linguagem Groovy, pois eu não queria mais utilizar EJB (pra quê?) e o grande trabalho consiste em refazer as telas utilizando o framework DOJO para manter a consistência e o grau de interatividade em aplicações WEB, sem grandes traumas para os clientes advindos do mundo desktop.

Até agora não vejo problemas com a migração, só vantagens:

  • Os clientes não precisarão investir em novas estações de trabalho para suportar o sistema
  • A agilidade para adaptar o sistema à necessidades específicas e lançar releases de versões de correção
  • Convenção, não configuração, sem XML
  • A arquitetura e a quantidade de plugins do Grails é fantástica.
  • A comunidade em torno do framework é enorme
  • O Grails é um framework que pode ser visto como um nível de abstração acima de frameworks mais utilizados no mundo Java, entre eles: Hibernate, spring e sitemesh.
  • Acredite se quiser: Funcionalidades que ficaram prontas em intervalos de meses na versão desktop levaram apenas semanas para serem concluídas. Adicione à esse intervalo o tempo necessário para fazer mais testes unitários, de integração e interface (Selenium) o que não era tããããão prezado na versão desktop (eu confesso)

Daqui a alguns meses lançaremos uma release estável e a idéia futura é migrar tudo para WEB, inclusive nossa ferramenta de exportação de nota fiscal eletrônica (NF-e).

2 Comentários

Arquivado em Grails, Groovy, Java, Web

Usando QT no meu TCC

Eu acho que isso é digno de nota. Eu estou desenvolvendo o protótipo do meu trabalho de conclusão de curso usando a biblioteca QT, da Trolltech (Atualmente é a Nokia, a responsável pela biblioteca) . A aplicação implementa algumas rotinas estereológicas para determinação de parâmetros tridimensionais básicos (área de superfície, volume, perímetro … ) sobre corpos rígidos em uma simulação 3D em GPU. Antes, a GUI da aplicação era baseado no WxWidgets, mas depois de desenvolver boa parte da aplicação (tanto a GUI quanto a própria “estereologia”) utilizando a dita cuja, eu percebi algumas coisas não muito legais no estilo da biblioteca.  O código não é tão limpo assim, inteligível, é cheio de macros e a OO passou foi longe …. Também não me agradei do suporte à OpenGL, pois não consegui modular meu código de forma adequanda à separar códigos específicos da própria API OpenGL de algumas chamadas necessárias à API do WxWidgets p/, por exemplo,  carregar o contexto do dispositivo OpenGL e assim direcionar todos os comandos gl* e glu* p/ o buffer de visualização …  Isso definitivivamente me afastou de WxWidgets ….. Ah … tem a documentação tb que é uma mer&¨%$#@!

Procurando uma solução topei com a Qt, OpenSource (com algumas diferenças quanto ao licenciamento em relação à WxWidgets) e posso garantir a veracidade do slogan da biblioteca: Code less, Create More, Deploy everywhere! É verdade, e gostei muito do design da própria biblioteca, totalmente OO ! É tão OO que os caras desenvolveram um, digamos, fake-Runtime para reflexão em C++.

Qt abandona a abordagem orientada à #defines do WxWidgets e cerca o desenvolvimento com várias ferramentas auxiliares( Geradores de MakeFiles, projetos p/ VS2008, GUI Builder). A documentação da Qt é enorme, muito bem organizada, clara e vários exemplos atualizados estão disponíveis com código-fonte. A única coisa que não me agradou foi que a atual distribuição do SDK pré-compilado é somente para o MinGW (questões de licenciamento), embora facilmente ( e demoradamente ) você pode gerar as *.lib para o compilador C++ do Visual Studio pois há makefiles para vários compiladores (vários mesmo) junto com o código-fonte do SDK …. Code less, Create More, Deploy everywhere

Deixe um comentário

Arquivado em C++, QT, TCC, Trolltech

Experiências com Maven e Ant+Ivy …

Decididamente, fico com a combinação Ant+Ivy. Antes deixe-me expor o porquê  da escolha. Andei por umas semanas pesquisando e lendo em blogs opiniões de desenvolvedores experientes sobre essas ferramentas, e cheguei à uma conclusão: Eu mesmo terei que sentir a utilidade das duas no meu dia-a-dia. Bom, eu ainda não tinha usado o Maven à sério e fui atrás do livro Better Builds with Maven . Um tempo atrás eu li também um sobre Ant e, depois de empregrar ambos em projetos de porte e importância iguais e diferentes, formei uma opinião sobre isso.

Maven

Ao meu ver, Maven enxugou o Ant e acrescentou o que a comunidade sentia falta no Ant, o gerenciamento de todo o processo de desenvolvimento e não apenas o build. Eu sou adepto do Ant, mas assumo que há muito Ctrl+C e Ctrl+V quando se está escrevendo um build p/ projetos diferentes. Ou seja, todo projeto possui etapas semelhantes que levam deste a preparação do ambiente de desenvolvimento à implantação do sistema (deploy) seja em ambiente de produção ou testes. Além disso, o HD da máquina de um desenvolvedor Ant (sem Ivy) vai embora “rapidin”, pq vc acaba pegando o hábito de criar uma pasta “lib” na raiz do seu projeto ou sub-projetos e isso é redudante e torna-se estressante. O Maven gerencia todo o ciclo de desenvolvimento além das depenências do seu projeto, centralizando em um repositório todas as dependências de todos os seus projetos, isso é muito bacana. Bom, o que não me agradou muito foi a integração com o eclipse. EU não me agradei do plugin, achei-o muito simples. E outra coisa que não me agradou muito foi o POM . Eu já odeio XML, e p/ piorar a legibilidade do POM descrece à medida que seu projeto  cresce … Em projetos simples até que vai, mas vai inventar de usar ele p/ gerenciar um multi-projeto com sub-projetos que possuem as mesmas dependêcias, só que com versões diferentes e coloca tudo isso em um servidor de integração contínua …. Tudo bem que se vc for comparar com o equivalente em Ant, o Maven dá de pau quanto ao tamanho do arquivo, mas cabe aqui a frase de Einstein : ” Tudo deveria se tornar o mais simples possível, mas não simplificado”.

Ant+Ivy

Essa é a minha escolha. Com Ant eu esqueço o maldito paradigma declarativo e tenho a sensação de estar programando sobre uma plataforma imperativa. Você tem controle sobre todo o processo (embora é importante frisar que a intenção do Ant é o build, não o gerenciamento do seu projeto ) e se tiver experiência e for organizado seus scripts serão grandes completos, porém legíveis. O que faltava era um gerenciador de dependências, e o Ivy então ocupa essa lacuna. O ant integra-se com eclipse de forma completa e inteligente, embora o IvyDE (plugin do Ivy p/ o Eclipse) ainda tenha lá seus bugs …

Uma dica ….

Forme opinião, cada um tem seu modo de ver uma ferramenta, uma linguagem, um SO, mulheres, carros e a vida …. As ferramentas que citei tem vasta documentação da Web e a comunidade também é enorme, ambas em torno de cada ferramenta. E vc, Apache+Ivy ou Maven ????

1 comentário

Arquivado em Ant, Java, Maven

The Definitive Guide to Grails, Second Edition

AêÊÊ !!! O Ebook caiu na web (demorou!) . É uma boa, já terminei o Groovy in Action agora vou p/ o Grails. Enquanto não dê p/ comprar o livro eu fico com o ebook.

Download

Deixe um comentário

Arquivado em Grails, Groovy, Java

Keep it groovy!

Nessas férias coloquei a linguagem groovy na minha super-lista TODO, já conhecia o basicão, mais resolvi ir além. Groovy é uma resposta ao mundo das linguagens de scripting p/ a plataforma Java. Uma versão dinâmica, enxuta e moderna de linguagem de programação de propósito geral rodando na JVM e integrando-se 100% com a plataforma. Ela não é apenas um Java++ . Groovy é uma revisão 100% OO ( sim, tudo é objeto)  da plataforma Java reunindo características de linguagens como python, ruby e smalltalk além de incluir alguns novos conceitos, como Closures ( enquanto o Java 7 não vem e o Neal Gafter fica só no blá blá blá … )  e suporte a expressões regulares por operadores nativos da linguagem.  Estou terminando de ler o Groovy in Action e acreditem, groovy is really groovy !

Para matar a cobra e mostrar o pau, aqui vai algumas aplicações de groovy no meu dia-a-dia:

  • Estou usando o Ant p/ o processo de build e packaging da  minha aplicação. Só que ela possui dependências de bibliotecas de terceiros. Como faço para adicionar essas dependências no arquivo MANIFEST.MF do meu jar??

Simples. Programe em groovy, dentro do script ant, e gere a lista de dependências, mais ou menos assim:

<groovy>

//definindo atributos no Manifesto do Jar

def date = new Date()

def classPath = []

new File(‘lib’).eachFileRecurse(){ f -> classPath.add(f.path) }

properties.’currentTime’ = date

properties.’classPath’ =  classPath.split(‘,’)

</groovy>

<jar destfile=”${jar.fileName}” basedir=”build”>

<manifest>

<attribute name=”Packaging-Date” value=”${currentTime}” />

<attribute name=”Class-Path” value=”${classPath}” />

</manifest>

</jar>

  • Por acaso, estou precisando gerar uma classe que ainda nem sei o nome, nem qual a super-classe ou interfaces a serem implementadas e muito menos quais são seus atributos e métodos. Posso?

Claro. Isso parece meio dantesco, mas no proximo post quem sabe irei mostrar como utilizei essa loucura toda para criar beans apartir de tabelas de BD’s sem o nome e seus atributos conheçer. Estou implementando um mecanismo de migração de dados chamado Bridge (Ponte). A filosofia é nem saber de onde vem os dados e p/ onde eles vão, simplements migrá – los. Mais não para por aí. A maioria das ferramentas de migração de dados não são flexíveis o suficiente p/ permitir que vc especifique como uma tabela deve ser migrada p/ outra, em outro BD. Um exemplo meu. Imagine que vc tem uma base (sistema de arquivo?) dbase III e tem uma tabela cliente com o campo “flagAtivo” representando se o cliente pode ou não comprar. Caso possa, o valor é um asterisco ‘*’ , caso não possa é em branco.  Imagine que uma nova aplicação está sendo feita e uma nova base de dados deve ser remodelada, de forma que os dados dos clientes possam ser migrados facilmente. E agora o campo flagAtivo é do tipo booleano. E agora, como migrar ??? É essa a função da Bridge. Vc é quem diz como cada coisa vai p/ seu lugar correto. Isso é um caso simples … Imagine que sua tabela cliente tenha dados que só clientes físicos usam e outros que só jurídicos utilizam . No mundo OO uma das possibilidades é usar uma especialização da classe Cliente em ClienteFisico e ClienteJuridico. E no BD ? Vc vai especificar a lógica. Tudo isso em groovy.

  • Preciso ser mais ágil

–  Construa interfaces Swing (com S de sem-graça) mais rápido

– Utilize a API do Java de forma mais ágil, simples

– Desenvolva testes unitários em groovy

– Utilize arquivos xml de maneira simples

– Carregue e execute regras de negócios ou qualquer outro código dinamicamente dentro da sua aplicação Java

–  Closures, expressões regulares, ranges …

Keep it groovy!

Deixe um comentário

Arquivado em Groovy, Java

Acelerando o desenvolvimento de GUI’s

Um dia desses, estava refletindo sobre o processo de desenvolvimento de aplicações comerciais desktop. Fiz um retrospecto da minha evolução em um projeto e notei que estava gastando demasiadamente meu precioso tempo me precupando  com coisas chatas e repetitivas como o desenvolvimento de GUI. É muito chato se comportar como um “macaco digitador de código”.

Toda essa carga de precaução em cada código que crio para essa aplicação vem se acentuando desde que comecei a babar pelo Grails e pela plataforma WEB. Definitivamente, quando tiver a primeira oportunidade mudo a plataforma dessa aplicação p/ a WEB sem pena e nem dó, sorte minha que o core da lógica de negócio está bem separada da UI.

Enfim, voltemos ao Desktop. Aquela papagiada de CRUD tava me dando nos nervos … Eram JTextFields para cá, JComboBox para lá, os malditos JTables e seus TableModels … enfim Swing. Nuss …

Muito código repetido, requisitos transversais à lógica de negócio, setters p/ cá, getters p/ lá … aí estão os bedsmells em meu código. Na minha mente logo vem o Martin Fowler gritando, exigindo e experniando: REFRACTORING !!!!!!! Calma Fowler, todo esse código que estou fazendo no braço pode ser gerado automaticamente. Vejamos, cada tela representa um POJO que deve ser carregado através do mecanismo de persistência. Eu preciso encapsular esse objeto de forma a acessar cada um de seus atributos, assim como conhecer de ante-mão os próprios. Estudei a geração de código-fonte com templates através do FreeMarker .

Blz, montei toda a estrutura baseado no modelo MVC do framework CoCoa, tava indo muito bem e tava ganhando caras de um “Lucas MVC Style Framework”. Depois de um tempo, um incômodo: Por que telas de cadastro tão ridículas, com uma mísera quantidade de campos requer tanto código-fonte gerado ?? Comecei a pensar sobre o impacto na performance à longo prazo e na facilidade de manutenção. É … meu “Lucas MVC Style Framework”  tinha tomado o caminho errado …

Então fui em busca de soluções e lembrei-me de um tal de Gênesis, um framework brazuca que ouvi falar tempo atrás mas ñ havia dado confiança. O gênesis trazia tudo que estava precisando de forma clean:

  • Swing binding
  • Formatadores, conversores
  • Remoting
  • Suporte a transações
  • Paginação

O uso é simples, o framework é bem documentado, há uma lista de discussão p/ usuários, já tem alguns componentes out of the box “à lá” plug-and-play style e funcionalidades como o binding de componentes e atributos de beans que economizaram-me linhas de código e tempo p/respirar aliviado. Bendito sejão os @Forms e @ViewHandlers. Vale a pena conferir.

Deixe um comentário

Arquivado em desktop, freemarker, genesis, mvc

Hi! I’m here

Olá meus caros! Depois de uma longa temporada fora da blogosfera, cá estou.

Bom, para quem não me conhece, sou um estudante Piauiense de Computação e (em breve) Analista de Sistemas. Como a comunicação é uma das necessidades primordiais p/  nós seres humanos,  eu não seria a exceção heheh. Aqui, vou dar alguns pitacos sobre programação especificamente desenvolvimento Desktop/Web,  frameworks, scripting, computação gráfica, vivências de um desenvolvedor em seu habitat programacional e algumas notas sobre minhas leituras. Bom, até breve!

Deixe um comentário

Arquivado em Hello World