Hey pessoal, quick post: acabei de jogar no github mais um projeto que uso a tempo e contribui com algum código: o jquery-maskMoney plugin. É basicamente um plugin pra fazer o trabalho chato de ficar controlando formatação de campos numéricos(com ou sem precisão decimal).

Pra usar ele é mega simples:

<script src="jquery.js" type="text/javascript"></script>
<script src="jquery.maskMoney.js" type="text/javascript"></script>
<script>
$(function(){
  $("#currency").maskMoney();
  $("#real").maskMoney({symbol:"R$", decimal:",", thousands:"."});
  $("#precision").maskMoney({precision:3})
})
function removeMask(){
  $("#currency").unmaskMoney();
}
</script>

Dúvidas, sugestões, críticas, etc, basta entrar em contato, abrir uma issue no projeto ou deixar um comentário!

Faz um bom tempo que tenho uma mania chata: gosto de ter tudo sempre atualizado. Confesso que é quase uma frescura (nada de piadinhas sobre gaúchos, ok?), mas automatizando um pouco, é um vício que da pra conviver. Para as apps do Mac OS X eu uso o AppFresh, que funciona muito bem e tem integração com o iUseThis. Mas ainda tinham algumas coisas que eu ainda fazia manualmente: MacPorts e RubyGems eram duas delas.

Depois do post que fiz sobre o rmagick-osx-installer tive a idéia de fazer um script que fizesse o trabalho sujo por mim também. E depois de muita procastinação: update_cadabra!

É basicamente, um script bash que roda os comandos pra atualização do Ruby Gems+gems+MacPorts+ports – e de quebra, ainda faz uma faxina no que está sobrando. Espero que usem, sugiram coisas novas e poupem ainda mais nosso tempo.

Pra usar, é só baixar o script, dar permissão de execução pro script e executá-lo:

chmod u+x update_cadabra.sh
sudo update_cadabra.sh

ps: se você por algum motivo não pode atualizar suas gems, ou ainda tem algumas gems antigas instaladas para algum sistema legado, não recomendo usar o script
ps2: use por sua conta e risco

• Cuidado com os getters e setters: tentadores, eles tem preparo extremamente simples (ainda mais com ferramentas como o Eclipse e o IntelliJ), porém, assim como a gordura, se consumidas em excesso são prejudiciais a saúde, então, moderação!
• As saborosas interfaces: são deliciosas e extremamente nutritivas. Porém, cuidado: elas não são adequadas pra todas as ocasiões. Porque iriamos colocar interfaces onde vamos ter apenas uma implementação?
• Não coma somente pra agradar os outros: quem nunca teve uma tia que ofereceu uma porção de um prato que você não suporta e acaba comendo só pra agradar? Se você se flagra frequentemente alterando xmls, pare um pouco e pense se aquilo é realmente necessário ou se você não está fazendo só pra agradar o framework.
• Evite repetir: a feijoada da vovó é bem tentadora einh? Mas repetir pode resultar em uma indigestão enorme. Código repetido também não desce bem.
• Experimente antes de servir: essa é uma dica que serve mais quando você está cozinhando. Mesmo os mais experientes cozinheiros, experimentam sua comida durante o preparo. Você deveria fazer o mesmo.
• Menos é mais: a cozinha francesa tem a fama de ser a mais saborosa do mundo – e também por servir pratos com quantidades bem reduzidas. Guarde bem: mais essência, menos quantidade.
  

  Success only grows when work(pain, strain, effort) decreases and non-work (fun, love, effort-lessness) increases. – Fred Gratzon, The lazy way to success

• Prefira um bom restaurante à um posto de conveniências: prefira comer um bom prato em um restaurante do que um hamburguer em um posto de conveniências. Usar herança pode parecer mais prático que usar interfaces, mas seu estômago prefere as interfaces.

Com o tempo (e com os comentários relevantes), vou adicionando novas dicas para que todos (inclusive eu), tenhamos uma vida mais saudável.

Hoje resolvi fazer uma atualização do Rails e cia aqui e dei de cara com um problema chato de resolver. Além de instalar as versões novas dos gems, queria me livrar as antigas. Mas sempre que tentava fazer o gem cleanup, recebia o seguinte erro:

~ plentz$ sudo gem cleanup
Cleaning up installed gems...
Attempting to uninstall mongrel-1.0.1
ERROR: While executing gem ... (Gem::InstallError)
Unknown gem mongrel = 1.0.1

Depois de fazer um find (find . -iname mongrel* mesmo) no / inteiro, descobri um diretório com vários gems antigos. Ele fica em:

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8

Entrei nele e fiz literalmente um limpa. Apaguei todos arquivos dentro das pastas specifications, doc, cache e gems. Então se quizer deixar sua instalação 100% fresh, rode os comandos abaixo, e caso encontre algum problema, siga a dica acima:

sudo gem update --system
sudo gem update
sudo gem cleanup

Depois confira que você ficou só com as últimas versões rodando: gem list.

Além disso, hoje também foi oficialmente lançado o Github, que é basicamente um host especializado em Git. E quem acompanha blogs gringos porai, deve ter percebido que não param de pipocar posts em tudo quanto é lado, explicando como usar Git e porque git é melhor que Subversion (acho que ninguém tem coragem de tentar comparar Git com CVS né?) então nem vou perder meu tempo escrevendo mais um. E como provavelmente daqui a algum tempo (pouco, inclusive), você vai estar abandonando seu querido Subversion, siga os links do post e comece a usar. Não dói. Give It a Try.

Volta e meia vemos pela internet alguém falando que open source não dá dinheiro. Quem tem um pouco mais de conhecimento (e vivência) em ambientes desse tipo, sabe que muitas vezes o dinheiro pode não vir diretamente da empresa “guarda-chuva” do projeto, mas através de reconhecimento por se ter participado do desenvolvimento de algum software que é usado por dezenas, centenas ou mesmo milhares de desenvolvedores. E com um pouco mais de dedicação(e expertise), é possível ser contrato pela empresa (e ainda ganhar um bom dinheiro). No Brasil mesmo, temos excelentes exemplos de gente trabalhando para projetos open source full time, como o Fernando Meyer, que trabalha no projeto Jboss Drools contratado pela RedHat e também o Rodrigo Kumpera (ou louds), trabalhando pela Novell no projeto Mono, ambos amigos pessoais. Além deles, com certeza devem existir outros que não conheço.

Pensando nesse pessoal, Jason Allen e Scott Collison criaram um site de relacionamentos para desenvolvedores: o Ohloh. O nome é tão estranho quanto o “primo” famoso, orkut, mas o foco é bem diferente. O Ohloh oferece uma série de recursos para quem participa de projetos open source, como possibilidade de criar “profiles” dos seus projetos e indexar o código fonte, permitindo que os desenvolvedores linkem seu profile aos seus commits no repositório. Também é possível dar um kudo(segundo a definição que está no site: (ku·do) a statement of praise or approval; accolade; compliment.) como forma de demonstrar sua confiança/admiração em algum desenvolvedor. Excenlente oportunidade pra quem colabora em algum projeto mostrar seu trabalho. Quem se cadastrar e tiver curiosidade pode dar uma passada no meu profile lá.

Na mesma linha, nas últimas semanas (ok, fazia meses que não postava), acabei ganhando alguns “pontos de confiança” em alguns projetos. Me tornei commiter (é, versão aportuguezada de quem pode dar commit no repositório), dos projetos Hibernate (e seus subprojetos) e do Vraptor (junto com o pessoal da Caelum) – tanto o Hibernate quanto o VRaptor já estão indexados no Ohloh. Motivo à mais pra gatar um tempo extra codando na frente do micro

Já estava com esse post em draft à séculos, mas como o tempo andava curto, acabava sempre procastinando de terminar. Algum tempo atrás (ok, bastante tempo, foi dia 30 de abril, 2007), ocorreu mais um encontro do Spin RS, fórum regional voltado para a melhoria das práticas de Engenharia de Software. Nessa edição em especial, diversas “celebridades” da IEEE estavam presentes, então vale a pena dar uma olhada, mesmo que seja somente nos slides das palestras.

Rebecca Wirfs-Brock: sensacional. Candidata forte à melhor palestra. A palestra dela foi basicamente uma aula de como contar histórias (uma habilidade importantíssima pra quem desenvolve orientado à objetos, já que precisamos saber fazer um “roteiro” de como os objetos interagem, etc). O nome da palestra era “Trends on Object-Oriented Software Design”, mas acabou virando “The Art of Telling your Design Story”.
PS: recomendo mesmo o livro da Rebecca, Object Design: Roles, Responsibilities, and Collaborations.

Outra palestra bacana foi a do Philippe Kruchten, sobre Arquitetura de software, onde ele levantou algumas questões sobre quem, como e quando deve fazer a arquitetura de um sistema. Mas a parte que mais me chamou atenção foi durante as perguntas da platéia, onde alguém perguntou alguma dica de como se tornar um bom arquiteto de software, e ele respondeu bem tranquilamente “troque muitas vezes de emprego”. Reações curiosas puderam ser observadas.

Dessa vez só o Phillip Calçado e o Marcello Azambuja que vieram, mas próxima vez espero ver mais gente por aqui, até para valorizar mais o evento (e também pra participar do churrasco pós-evento).

Quem programa em Java e nunca passou por esse problema? Você está desenvolvendo, tudo funciona perfeitamente, quando a aplicação vai para produção e os usuários começam a usar você percebe que o contador de conexões disponíveis no seu pool só diminui.

As razões para isso podem ser as mais variadas (sendo a maioria deles problemas da aplicação e não algo ligado ao data source, servidor de aplicação ou mesmo driver jdbc), mas as mais comuns são:

• ausência de chamada ao connection.close();
• falta de um tratamento de excessões, e conseqüentemente, o método close() não é chamado;

É importante saber, que sempre que você estiver lidando diretamente com Connection (o que não é algo muito aconselhável, sabendo que já existem diversos frameworks que abstraem/simplificam a utilização de jdbc), você deve fechar ela através do método close() e o mesmo deve estar dentro de um bloco finally{}, para que ele seja executado mesmo se ocorrer um problema durante a execução do seu código.

Mas e quando você já revisou “todo” seu código e mesmo assim as conexões continuam vazando? Você olha as conexões do seu pool e elas simplesmente parecem ir para o limbo. Aqui alguns já podem começar a se perguntar, “mas tem como eu monitorar as conexões do meu pool?”. E é aqui que entra um recurso não muito conhecido (e menos ainda, usado): Java Management Extensions ou simplesmente JMX.

Copiando o site da Sun:

JMX technology provides the tools for building distributed, Web-based, modular and dynamic solutions for managing and monitoring devices, applications, and service-driven networks. By design, this standard is suitable for adapting legacy systems, implementing new management and monitoring solutions, and plugging into those of the future.

A maioria (se não todos) dos application servers já vem com recursos JMX prontos pra monitoramento e diagnóstico de connection leaks. Ativar o monitoramento do data source pode muitas vezes sacrificar um pouco da performance da aplicação (principalmente em um arquitetura Database-Centered), mas normalmente é um custo aceitável para descobrir os pontos de perda das conexões.

No JBoss, servidor de aplicação que eu utilizo no meu atual projeto, ligar o monitoramento é bem simples. Quando ativo, ele basicamente armazena o stack trace de todos os pontos onde temos chamadas à getConnection(), até que essa conexão sehja devolvida ao pool. Para ligar o monitoramento, altere o arquivo de configuração do seu data source(provavelmente um *-ds.xml) adicionando a linha abaixo
<local-tx-datasource>
.....
<track-statements>true</track-statements>
</local-tx-datasource>

Agora basta acessar o mbean CachedConnectionManager através da interface JMX do Jboss e invocar listInUseConnections() para ver o stack trace das conexões que não foram fechadas. Provavelmente vai ser algo semelhante à essa. Se você quizer apenas ver como anda seu pool, acesse o mbean ManagedConnectionPool, procurando principalmente pelos seguinte valores:

• AvailableConnectionCount – total de conexões disponíveis no pool
• InUseConnectionCount – total de conexões sendo usadas atualmente
• ConnectionCount – indica o total de conexões abertas atualmente no pool

Utilizando esses recursos e tendo um pouco de paciência, fica bem mais fácil achar os pontos de vazamento da aplicação.

Mais informações:

• Jboss DataSources
• Connection Leak Tracing – Sun Application Server
• Bea WebLogic – Profile Connection Leak
• IBM Web Sphere Aplication Server – Connection Leak Diagnostics
• The Joy of Finding Connection Leaks

Depois de quebrar a cabeça por um bom tempo, descobri que após adicionar a lib Prototype ao projeto, algumas validações javascript simplesmente deixaram de funcionar. O for in, que antes funcionava corretamente, muda seu comportamento devido à magia negra que o Prototype faz, adicionando algumas propriedades extras aos objetos (e também à arrays).

Se eu tivesse feito uma dúzia de JSUnits teria evitado mais de duas horas de tempo perdido, literalmente.

O que antes era:

o.isCNPJ = function(){
var d = this.split("");
var m1 = [d[0]*5,d[1]*4,d[2]*3,d[3]*2,d[4]*9,d[5]*8,d[6]*7,d[7]*6,d[8]*5,d[9]*4,d[10]*3,d[11]*2];
var s1 = 0;
for(i in m1){ s1 += m1[i]; }
var d1 = (s1%11<2)?0:11-(s1%11);
var m2 = [d[0]*6,d[1]*5,d[2]*4,d[3]*3,d[4]*2,d[5]*9,d[6]*8,d[7]*7,d[8]*6,d[9]*5,d[10]*4,d[11]*3,d1*2];
var s2 = 0;
for(i in m2){ s2 += m2[i]; }
var d2 = (s2%11<2)?0:11-(s2%11);
return (d1 == d[12] && d2 == d[13])? true: false;
}

Teve que virar:

o.isCNPJ = function(){
var d = this.split("");
var m1 = [d[0]*10,d[1]*9,d[2]*8,d[3]*7,d[4]*6,d[5]*5,d[6]*4,d[7]*3,d[8]*2];
var s1 = 0;
for(var i=0;i < m1.length; i++){ s1 += m1[i]; }
var d1 = (s1 % 11 < 2)?0:11-(s1 % 11);
var m2 = [d[0]*11,d[1]*10,d[2]*9,d[3]*8,d[4]*7,d[5]*6,d[6]*5,d[7]*4,d[8]*3,d1*2];
var s2 = 0;
for(var i=0;i < m2.length; i++){ s2 += m2[i]; }
var d2 = (s2%11<2)?0:11-(s2%11);
return (d1 == d[9] && d2 == d[10])? true: false;
}

Nessas horas que vemos que testes unitários sempre se pagam.

O Villela recém postou no seu blog, um pequeno recado pro pessoal do JCP, que espero que seja lido, re-lido e repassado até que alguém lá da nave-mãe veja: static reflection. A idéia seria prover alguma forma de reflexão estaticamente, algo do tipo:

Foo.class.instanceMethods.bar(String.class)

Ócio criativo faz bem para qualquer linguagem.

Segundo a Wikipedia,

Hot swapping can also refer to the ability to alter the running code of a program without having to interrupt its execution, although only a few languages support it. Those that do include Lisp, Erlang, and Smalltalk. The Java programming language also supports this technology, but only through the Java Platform Debugger Architecture (JPDA) : it is only possible to change the code while the program is in the control of a Debugger. Interactive programming is a paradigm that makes extensive use of hot swapping so that the programming activity becomes part of the program flow itself.

O post do Daniel (Hot Code Replacement), contando como fazer hot swap de classes com o OC4J, me fez pensar numa coisa: será que realmente são poucos que conhecem a “feature” de trocar classes em tempo de execução, sem parar sua aplicação, e nem a VM?

Bom, mesmo sem ter 1/3 de conhecimento sobre VMs que o Rodrigo (louds), por exemplo, vou tentar explicar. Parada para comentário de utilidade pública: se você não assina o blog dele, faça um favor a si mesmo e vai lá. Hoje mesmo ele anunciou que vai liberar os fontes da máquina virtual que ele começou a desenvolver.

Voltando ao assunto, desde a JDK 1.4 (sim, hot swap é relativamente velho), é possível trocar a implementação de métodos sem reiniciar a aplicação. Notem bem, implementação, ou seja, se você trocou qualquer coisa na assinatura de um método, criou algum novo, adicionou uma variável de instância da classe, você precisa parar a VM, compilar a classe, e iniciar novamente.

No entando, linguagens dinâmicas, como Ruby (com site novo), permitem trocar trocar qualquer coisa das suas classes em tempo de execução, seja métodos, atributos, whatever. Parece covardia comparar, né?

Porém, lendo um pouco mais à respeito, fazer com que a JVM suporte isso também é perfeitamente possível tecnicamente (louds!!), mas precisariam ser feitas enormes mudanças no seu funcionamento, e acredito que seja esse, um dos principais motivos de não terem feito nos primórdios do hot swap – JDK 1.4.

O assunto parece estar realmente chamando ateção, pois acabou de sair um artigo no Artima, The JVM as an (Un)Common Language Runtime, e um dos pontos que o autor destaca como sendo um dos principais desafios para a implementação de linguagens dinâmicas na JVM:

Hotswapping: The main idea is to allow code changes on the fly, while they are running. The full capability of hotswapping implies any kind of change to be supported, addition/modification/removal of methods and attributes including changes in inheritance hierarchy.

Se isso não fosse suficiente, existe um tópico na SDN, Hotswap support for schema / shape changes discutindo o assunto, e o bug report 4910812 – Enhance Hot Code Replacement com 300+ votos.

Isso permitiria baixar para praticamente zero o turnaround de desenvolivmento de aplicações, dando um grande fôlego para Java como linguagem, pois já aumentaria significantemente a velocidade de desenvolvimento, evitando a perda de minutos que já estamos acostumados entre parar servidor de aplicação, fazer re-deploy, iniciar aplicação, …

Classloader tricks only take you so far.

Uma linguagem de programação deve seguir algumas premissas importantes: ajudar o desenvolvedor à resolver problemas de forma simples e tornar o desenvolvimento o mais agradável e produtivo possível. A escolha de uma linguagem de programação apropriada pode reduzir drasticamente o custo da construção de novas aplicações, como também na sua manutenção. Uma linguagem de programação eficiente pode aumentar incrivelmente a produtividade de um programador, permitindo que ele escreva código mais escalonável, genérico, legível e de fácil manutenção.

Linguagens não são somente ferramentas para comunicação. Mais que isso, são ferramentas para pensar, que influenciam na forma que as pessoas pensam. As linguagens de programação, assim como as outras linguagens naturais, tem o propósito de estabelecer uma comunicação – neste caso, entre o programador e o computador.

Uma DSL (Domain specific language) é uma linguagem dedicada à resolver uma problema específico, ou melhor, um problema referente à um domínio (seja ele uma área de negócio ou uma necessidade não funcional). Por ter esta característica de se aproximar mais do problema, uma DSL tende a trazer mais benefícios que em uma GPL (General Purpose Language), deixando o programador à vontade para se preocupar somente (ou o máximo possível) em resolver problemas ligados ao negócio – e não em atender necessidades do compilador.

“Programming focuses on what to compute as opposed to how to compute.”

Mais que isso, novas DSL’s podem ser usadas para melhorar aspectos da engenharia de software: domain-specific analysis, testes, manutenção, modelagem e rápida prototipação. O próprio desenvolvimento de uma DSL já é uma tarefa significante de engenharia de software, necessitando de considerável investimento de tempo e recursos, pois exige do desenvolvedor tanto conhecimento do domínio, quanto expertise para o desenvolvimento de uma linguagem. Poucos possuem ambos.

DSL’s vem sendo usadas em várias áreas como: computação gráfica, sistemas financeiros, protocolos, sistemas operacionais, robot languages, etc. Estas aplicações tem mostrado claramente vantagens das DSL’s sobre as GPL’s no que diz respeito à produtividade, confiabilidade e flexibilidade no domíno em questão. Alguns exemplos de DSL’s conhecidas são: SQL (database queries), HTML (hypertext web pages), Make (software building), Excel (spreadsheets), VHDL (hardware design).

Para praticamente qualquer implementação de um problema lógico existe um design pattern no qual ele se encaixa. A criação de uma DSL não é exceção: existem basicamente oito design patterns que abordam a implementação de uma DSL:

• Piggyback
• Pipeline
• Lexical Processing
• Language Extension
• Language Specialisation
• Source to source transformation
• Data Structure Representation
• System Front-End

Estes oito design patterns podem ser redistribuídos em três grupos maiores:

• Domain-specific libraries / embedded languages: são provavelmente as DSL’s mais comuns. Nessa abordagem, ao invés de criar uma nova linguagem, com um compilador/interpretador, utiliza-se de uma GPL e cria-se extensões que atendam ao domínio em forma de funções e library’s, por exemplo.
• Preprocessing / macro processing: nesta abordagem, basicamente são feitas “traduções” das sentenças da DSL para uma linguagem base por um preprocessasor. A principal vantagem desta abordagem é a simplicadade. Em contrapartida, a desvantagem é que o feedback para o usuário da DSL é obtido à nível da linguagem base ou mesmo em tempo de execução.
• Extensible compiler / interpreter: segue praticamente a mesma linha da anterior, mas com a vantagem que a fase de preprocessamento é integrada com o compilador.

A definição de DSL em si, já se encaixa em um GOF Design Pattern: Interpreter. As DSL’s também podem ser chamadas de litle languages, micro languages ou mesmo application languages.

Talvez você esteja se perguntando agora: “mas o que diferencia uma API de uma DSL?”. Para mim esta linha não está totalmente clara, porque você não poderia dizer : “se sua API contém menos que N aspectos que não são escíficos do domínio, então ela é uma DSL”.

DSL’s são abstrações. Você pode criar DSL’s melhores em linguagens(embedded DSL’s nesse caso) que provêm melhores maneiras de abstração. Algumas linguagens como Python, Ruby, Smalltalk e Lisp possuem um histórico bem sucedido na criação de DSL’s devido à sua simplicidade.

Como puderam ver, as DSL’s oferecem duas principais vantagens: granho de produtividade para o programador oferecendo facilitadores para a resolução dos problemas e provendo uma forma de aproximação entre o time de desenvolvimento e os conhecedores do domínio.

Programming should be fun. Humans, should take care of human business and machines should take care of their side. – Yukihiro “Matz” Matsumoto

Leia mais em:

• Writing Domain Specific Languages, Jamis Buck
• Keywords, Magic and (E)DSLs, Keith Braithwaite
• Domain Specific Language, Martin Fowler
• Domain-Specific Languages: An Annotated Bibliography
• Domain-specific programming language, Wikipedia
• Language Workbenches: The Killer-App for Domain Specific Languages?, Martin Fowler
• Notable Design Patterns for Domain-Specific Languages, Diomidis Spinellis

irb(main):001:0> def question?
irb(main):002:1> bb || !bb
irb(main):003:1> end
=> shakespeare