A cada dia que passa, evoluímos mais, aqui na empresa, para um cenário estável de integração contínua. O que isso quer dizer ? Bom, integração contínua, é você ter o status do seus sistema (testes, cobertura, javadoc, build, release, etc.) em um único ponto, e de fácil acesso. Com isso, fica simples ver quando alguém faz uma macacada e detona o software que você está fazendo.

Para atingir esse estado da arte de integração contínua, há vários métodos. Desde agendar tudo no crontab, criar scripts, ou utilizar softwares específicos para isso. Qua aliás, não faltam opções.

Aqui no trabalho, começamos a utilizar o continuum, porém, há apenas uma máquina para gerar uma grande quantidade de builds, sem contar com os testes automáticos. Dado isso, resolvi, colocar na minha máquina mesmo, uma tarefinha no crontab para gerar a build e rodar os testes automatizados, o que leva mais ou menos 8 horas (por isso optei em rodar na minha máquina e não no continuum server da empresa =p).

Até então estava tudo indo bem, com relatórios diários do status dos testes. Mas isso me abriu um horizonte. De repente me peguei fazendo uns scripts (em Ruby, lógico) para gravar no banco o resultado dos testes, para conseguir fazer um tracking da evolução desta tarefa. Apesar de ser divertido, estava meio complicado fazer este script. E eis, que numa conversa no café, um amigo me sugere a utilização do Hudson, que assim como o continuum é um software para integração contínua.

Ainda está cedo para disponibilizar qualquer análise, mas estou gostando muito, principalmente da facilidade que o software proporciona. Em poucos cliques consegui fazer o hudson baixar o codigo do subversion, fazer a build, gerar relatorio dos testes unitários, e ainda rodar a suite de testes automatizados. Ah, e de graça consegui um gráfico que mostra a variaca na quantidade de testes (e de falhas e erros nos testes também), ou seja, tudo o que eu queria!

Bom, fica ai a dica de pelo menos experimentarem o Hudson

Aqui vai uma dica que vi no excelente blog rubyinside:

Há um projeto no github, chamado whenever, que encapsula chamadas ao cron, utilizando a sitaxe e o jeitão do Ruby.  É possível fazer agendar tarefas no cron desta forma:

  every 3.hours do
    runner "MyModel.some_process"
    rake "my:rake:task"
    command "/usr/bin/my_great_command"
  end

  every 1.day, :at => '4:30 am' do
    runner "MyModel.task_to_run_at_four_thirty_in_the_morning"
  end

  every :hour do # Many shortcuts available: :hour, :day, :month, :year, :reboot
    runner "SomeModel.ladeeda"
  end

  every :sunday, :at => '12pm' do # Use any day of the week or :weekend, :weekday
    runner "Task.do_something_great"
  end

Para saber mais, visite o site do projeto, ou assista a este video.

Fonte: http://www.rubyinside.com.br/whenever-uma-dsl-ruby-para-programar-tarefas-no-cron-1514

…Porque nem só de programação vive um geek =p.Reebok 10k no sábado (20/06), na USP. Alguém mais vai ?

Boa prova a todos!

(e que eu consiga terminar os 10km…)

Veja como é simples invocar um session bean através de um cliente JRuby.

Obs: Não esqueça do jndi.properties e de adicionar, ao classpath (tem que ser via variável CLASSPATH), o seu jbossall-client.jar (caso seu servidor seja jboss =p) e o jar que contém as interfaces dos seu SessionBean.

#!/usr/bin/env jruby

require 'java'
include_class 'javax.naming.InitialContext'

ic = InitialContext.new
sb_home = ic.lookup("MySessionBean")
sb_remote = sb_home.create

value = sb_remote.sayHi
puts "Valor = #{value}"

Pois é, juro que com isso é possível invocar o EJB.

Isso abre várias portas, não ?