Hail for Grails

19.janeiro.2009
Infelizmente não estou tendo o tempo que gostaria para investir no Clojure. Porém, por uma coincidência, surgiu uma oportunidade para trabalhar com Grails (Groovy on Rails), uma versão Groovy do consagrado framework para Ruby.

Minha primeira impressão foi muito boa. Para montar um CRUD, são necessários menos de cinco minutos, caso você nunca tenha mexido antes com o framework.

“Ah, mas o Rails também tem isso”. Claro que tem, afinal de contas, o Grails é um ‘clone’ que roda com Groovy. É possível gerar um arquivo .war e publicar a aplicação num servidor Tomcat, como uma aplicação Java normal. Por trás dos panos, o que acontece é exatamente compilar o código Groovy para Java, e o Java para o bytecode da JVM. Caso você tenha uma aplicação Rails, pode também utilizar o JRuby para o mesmo fim.

Outro ponto que me chamou a atenção no Grails (ou no Groovy, se preferir) são as contraints. São checagens que você codifica na própria entidade, que funcionam como validações automáticas dos dados inseridos. Numa tela de login, por exemplo, você pode ter uma entidade User e informar que login é único, não pode estar em branco e deve ter entre 5 e 20 caracteres, por exemplo. Tudo isso em uma ou duas linhas de código facilmente legível.

Como o trabalho deve ser entregue rapidamente, não vou ter muito tempo de fuçar e experimentar funcionalidades não usuais, mas com certeza o framework já entra para a minha lista de ferramentas preferidas.

Aos mais puristas, deixo meu compromisso de estudar Ruby e olhar o Rails com mais atenção, já que, ao que me parece, esses frameworks atendem plenamente às minhas necessidades.


Sobre testes, Lisp, certificação e remédios para o estômago

08.dezembro.2008
Há alguns dias eu publiquei um diálogo imaginário (mas não muito) sobre testes e TDD. Não foi maldade, nem desejo de menosprezar alguém. Há pouco reli um artigo do Shoes chamado Programadores Profissionais Escrevem Testes, Ponto Final e lembrei disso. Leiam, pensem, tentem aplicar alguma coisa.

Sobre o estômago, gostaria de pedir a ajuda de algum leitor com ares de bom samaritano: estou tendo sérios problemas com branch/merge no Subversion. Posso estar ridiculamente enganado, mas estou sentindo falta do velho CVS.

Sobre o elisp (Emacs Lisp), deixei na geladeira. Tentei mais algumas brincadeiras no Clojure, mas algo me diz que vou precisar de um pouco mais de método se quiser realmente aprender a linguagem.

Finalizando, comecei oficialmente a estudar para minha próxima certificação. Para 2009 quero pelo menos mais duas.

😉


Lisp – Primeiros passos

03.dezembro.2008
Não é exatamente LISP, mas sim Clojure, um tipo de LISP que roda sobre a JVM.

Fatorial:

(ns org.pindureta.lisp)
(defn factorial [n]
   (if (<= n 1)
       1
       (* n (factorial (- n 1)))
    )
)
(defn main [args]
  (def n 10)
  (println (factorial 10))
)

A única diferença gritante que encontrei até agora foi o defn para declarar uma função. Pelo que li até agora, o padrão é defun.
Existe um plugin para NetBeans chamado Enclojure. Recomendo para quem quer sair um pouco da mesmice das linguagens imperativas com cara de C e expandir os horizontes.
A primeira coisa que estranhei foram os parênteses. Eles estão em toda a parte, seja para iniciar uma nova linha (esse conceito de linha de código não fica muito claro no LISP, e a tabulação no código acima foi feita só para facilitar a leitura), seja para separar blocos de código.
A notação é prefixa, ou seja, o operador vem antes dos argumentos. É o oposto do usado nas calculadoras da HP, e diferente da notação infixa que estamos acostumados.
Prefixa:(+ 1 1)
Infixa: (1 + 1)
Posfixa:(1 1 +)
No começo isso confunde um pouco, mas depois fica bem intuitivo. Caso você precise desenvolver uma operação composta, basta adicionar parênteses. Por exemplo: (* ( + 1 2) 3). Primeiro é resolvida a expressão dos parênteses internos, que retorna 3, e depois dos parênteses externos, que retorna 9. Muito simples, no geral.
Outro ponto interessante, e muito importante, é que no LISP tudo acaba se transformando em contante. Não existe alteração de valores, o que acaba com qualquer possibilidade de haver efeito colateral. É praticamente impossível você alterar um valor em um ponto e estragar outro ponto (efeito conhecido como Ação à distância).
Conforme for pegando mais macetes e aprendendo mais coisas, vou compartilhando por aqui.