Isso quer dizer que você pode gerar um scaffold numa aplicação Rails, ir no modelo, trocar ActiveRecord::Base por ActiveLucene::Document e tudo deveria continuar funcionando, com a diferença do modelo estar sendo salvo num índice do Lucene e não num banco de dados relacional.

Dado que os documentos são salvos num índice do Lucene, podemos procurar eles utilizando a sintaxe de query do Lucene, sem esquecer que por ter uma interface similar à do ActiveRecord, podemos também procurar eles por um id.

A classe base do ActiveLucene se chama Document porque ao igual que os documentos de outros sistemas, não tem uma estrutura definida e todos os atributos são dinâmicos, pelo que você não tem que se preocupar com eles.

o ActiveLucene foi extraído do Lunr, um servidor do qual vou falar num futuro post, mas hoje também pode ser utilizado em aplicações nas quais ter um banco de dados relacionais no faz muito sentido e especialmente nas quais se deseja procurar documentos por texto.

A restrição do ActiveLucene é que somente funciona com JRuby, dado que o Lucene é uma biblioteca em Java que roda sobre a JVM. Mesmo assim, caso isso não for um problema, utilizar o ActiveLucene deve ser bem mais simples e leve que utilizar uma solução como o Sphinx ou o Solr, onde dependendo do caso pode resultar numa grande vantagem.

O Lucene tem um monte de funcionalidades e o ActiveLucene não suporta todas elas, mas dependendo das necessidades das pessoas elas serão indo adicionadas ao projeto. Hoje existe um suporte a highlighting e um pouco a paginação, como pode ser visto no seguinte video, junto com uma demonstração básica de como funciona a ferramenta:

Full text search in JRuby with ActiveLucene from Diego Carrion on Vimeo.

Se você gostou do ActiveLucene, considera me recomendar no Working With Rails. Para ficar mais perto das novidades, não deixa de me seguir no Twitter.

A escolha das ferramentas Java foi livre pelo que felizmente conseguimos pegar o que tem de melhor no mercado: VRaptor e Hibernate. Essas duas ferramentas nos ajudaram a acelerar bastante o tempo de desenvolvimento. Não esquecer que o projeto foi feito em 4 semanas, por tres desenvolvedores (guardar esses valores para mais tarde).

Somente como momento propaganda, a versão utilizada do VRaptor foi a VRaptor Sexy URLS.

Uma vez terminado o ultimo sprint, dediquei um tempo à realizar uns testes de stress enquanto analisava tudo com o JProfiler. A aplicação não possuía nenhum memory leak ou coisa similar, mas mesmo assim algumas alterações melhoraram a performance.

Foi realizado um novo deploy da aplicação no ambiente de produção e o cliente gostou do produto, pelo que foi mantido assim.

Uma semana depois aproveitei um tempo livre que teve para desenvolver a aplicação novamente, dessa vez utilizando Rails. Lembram quanto tempo demoro utilizando os frameworks Java? Utilizando Rails + plugins consegui desenvolver a mesma aplicação em somente duas horas!

Mas isso não é tudo, queria comparar a performance da aplicação feita em Rails com a feita em Java. Eu tinha um script que simulava diversos usuários utilizando a aplicação, o mesmo script que utilizei para realizar o profiling da aplicação Java, pelo que aproveitei ele para medir o tempo de execução frente as duas aplicações, uma rodando sobre o Glassfish e a outra sobre o Passenger.

Para surpresa de muitos, a aplicação Rails rodando sobre Passenger respondeu bem mais rápido às diferentes requisições que a aplicação Java (32 vs 60 segundos)! Isso pode surpreender a muitos, mas não é a primeira vez que algo assim acontece. No Falando em Java 2008 o Fabio Kung mencionou que parte do Guj foi rescrito em Rails, ao mesmo tempo que a performance melhorou notavelmente. Mas sem lugar a dúvida, o exemplo maior de uma aplicação Java que foi rescrita em Rails sem perder a performance é o caso do YellowPages.com, aplicação com nada menos que 150 mil requisições por segundo. Mas detalhes sobre a rescrita podem ser vistos aqui.

Para ir terminando a historia, eu consegui gastar um bom tempo tunando a JVM e o servidor Glassfish, mas somente por diversão, como desafio, porque para o cliente não mudou nada! Não mudou nada porque a diferença somente pode ser percebida com MUITOS usuários, realizando MUITAS requisições, bem mais, mas bem mais mesmo das que a aplicação pretendia receber.

Se você é uma das pessoas responsáveis por escolher uma tecnologia num projeto e você pretende deixar de escolher Rails porque alega alguma coisa relacionada a performance, então você deve pensar no assunto uma vez mais.

Caso você seja uma rara exceção, vamos ser sinceros, tua aplicação bem desenvolvida nunca vai precisar da JVM e do servidor tunados ao máximo, nem sequer tunados ao ponto no qual uma aplicação em Rails não consiga chegar. Isso considerando que a aplicação vai estar bem desenvolvida, mas provavelmente ela não vai estar. Na maioria dos casos as aplicações Java tem problemas de performance a nível de código. Os desenvolvedores escrevem tanto mas tanto código que terminam deixando brechas para poder acontecer um processamento elevado ou ate alguns memory leaks.

Quanto menos código você escrever e quanto mais simples ele for, menores vão ser as possibilidades de um problema acontecer, e isso é algo que ajuda as aplicações feitas em Rails a terem uma boa performance com esforço mínimo, as chances de errar são muito menores.

VRaptor Sexy URLs

Estou publicando oficialmente o VRaptor Sexy URLs. O VRaptor Sexy URLs é um fork da versão oficial do VRaptor 2 que ao contrario de trabalhar sobre uma servlet, trabalha sobre um filtro, pelo que junto à outras configurações permite que chamemos nossas actions no estilo:

http://my.host.com/controller/action

Anteriormente tínhamos que chamar nossas actions de um jeito que, após trabalhar com Rails, nunca mais considerei tão legal:

http://my.host.com/controller.action.logic

Eu me comuniquei com o Fabio Kung para tentar colocar minhas alterações no repositório oficial mas eles já estão trabalhando na mesma solução, implementada de outro jeito. Parece que na próxima versão do VRaptor essas implementações já estarão disponiveis, ate lá podem ir utilizando o fork que se encontra no GitHub.

RSpec::VRaptor

O RSpec::VRaptor é talvez a melhor coisa que pode ser aproveitada ao utilizar o VRaptor Sexy URLs. O RSpec::VRaptor foi inspirado no RSpec::Rails e funciona de forma muito similar.

Para os que não conhecem o RSpec::Rails, ele é um plugin para
o Rails que permite, entre outras coisas, testar os controllers dele sem ter que se preocupar por criar um monte de mocks que simulem o stack do Rails. Legal ne? O RSpec::VRaptor faz o mesmo com o VRaptor Sexy URLs.

Em poucas palavras, você pode testar seu controllers assim:

describe UserController do

  context "no serviço xpto" do

    before :all do
      get "/user/xpto", :request => {'param1' => 'value1'},
                        :session => {'login' => 'dcrec1'},
                        :inject => {'user' => User.new},
                        :headers => {'Host' => '20.85.17.10'}
    end

    it "deve enviar à view um atributo 'logado' como true" do
      @request.attributes['logado'].should be_true
    end

    it "deve retornar como código de resposta 203" do
      @response.status.should eql(203)
    end

    it "deve salvar na sessão o valor do param1" do
      @session.attributes['param1'].should eql('value')
    end

  end

end

Acredito que não exista nenhuma solução na linguagem Java que permita criar testes funcionais tão elegantes. Se você é um programador Java e ainda não desenvolve em Ruby, essa aqui é uma excelente demostração de por que você deveria começar a aprender a linguagem. Pode ser que você não chegue a utilizar o VRaptor Sexy URLs, mas você poderia criar algo similar para teu framework de preferencia.

Se nos dirigirmos à documentação do VRaptor, na parte de testes, poderemos ver que eles sugerem testar os controllers instanciando eles e setando os parâmetros. Isso se deve a que as anotações não são interpretadas pelo que temos que realizar as injeções manualmente. Devemos modificar nosso código para que possa ser testável ate um certo ponto, dado que como as anotações não participam, não sabemos se colocamos elas certas ou se temos esquecido de alguma.

Com RSpec::VRaptor não temos esse problema, devido a que as anotações e as rotas são interpretadas normalmente, como se a requisição tivesse vindo via http! Podemos também utilizar os parâmetros opcionais :request, :inject, :session e :headers para definir os parâmetros do request, injetar objetos no controller, modificar a sessão http e também alguns headers, respetivamente.

Além de tudo isso também ganhamos as features do excelente RSpec, como os mocks, expectativas e a possibilidade de imprimir a saída dos testes em diversos formatos e poder integrar ele com ferramentas muito boas como o autotest-notification ou ate o Cucumber!

Tudo isto é possível por causa do JRuby, excelente tecnologia que nos permite integrar as linguagens Ruby e Java. De novo, se você programa em Java e ainda não aprendeu Ruby, não perda mais tempo. Aprendendo Ruby você vai ser tornar também um melhor programador Java, vai poder utilizar o RSpec::VRaptor é também as novas surpresas que estão por vir.

class MockedHttpSession
  include javax.servlet.http.HttpSession
  ...
end

Bonus

Caso estejam estendendo uma classe Java com JRuby e desejem chamar no construtor um dos métodos já implementados pela classe pai deverão utilizar antes a instrução super:

class MockedUser < User
  def initialize(password)
    super
    setPassword password
  end
  ...
end

Caso não chamem a instrução super irão receber a seguinte mensagem de erro:

invokee not a java object

Ultimamente estou mexendo bastante com JRuby. Se for do teu interesse, pode me seguir no Twitter para se manter ao tanto.

Os que me seguem no Twitter devem estar sabendo que nos últimos dias esteve trabalhando num projeto em Java porém utilizando RSpec para testar ele. Se você ainda testa código feito em Java utilizando Java, te recomendo sair dessa vida, gasta um dia ou o tempo que for necessário para poder criar testes utilizando RSpec e se feliz criando testes de qualidade.

No projeto mencionado, a maioria dos desenvolvedores se sentia confortável utilizando Maven pelo que teve que me adequar a essa ferramenta que eu tanto gosto (ironia mode on) e averiguar se existia algo que vinculasse ela ao RSpec.

Foi assim que achei esse post onde Bob apresenta o plugin rspec-maven-plugin que permite executar os testes criados en RSpec ao executar o target test do Maven, todo o que eu queria.

Configurei o plugin no meu pom.xml, executei a target test e… não funcionou. Como todo problema é também algo bom porque oferece a oportunidade de fazer algo legal, decidi realizar um fork do projeto e corrigir ele.

O plugin

Como o plugin não esta no repositório oficial, para instalar o plugin rspec-maven-plugin deve ser executado:

git clone git://github.com/dcrec1/rspec-maven-plugin.git
cd rspec-maven-plugin
mvn install

Caso não tenham o Git instalado, podem baixar as fontes de aqui.

Uma vez no repositório local, podem configurar o plugin adicionando o seguinte ao pom.xml:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>rspec-maven-plugin</artifactId>
    <executions>
        <execution>
            <id>test</id>
            <phase>test</phase>
            <goals>
                <goal>spec</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Depois disto, o único pre-requisito para executar o plugin é setar a variável de ambiente JRUBY_HOME.

Ao executar o target test, o Maven ira executar os testes dentro da pasta spec.

Obrigado JRuby, happy testing!

Algo que não foi muito divulgado é que o material das palestras esta disponível no próprio site, especificamente aqui. Algumas palestras que acho interessantes são: Da Vinci Machine, Parrot VM e JRuby. As três palestras abordam o tema de executar linguagens de script na JVM, o que é muito favorável para linguagens como Ruby.

Particularmente achei a palestra sobre JRuby muito legal. Como era de esperar, o nível dos atendentes era muito alto e com isso o Charles Nutter conseguiu encaprichar para tocar assuntos de bem baixo nivel, coisas internas da implementação JRuby, vale a pena conferir.

Algumas coisas ficam difíceis de entender somente vendo os slides, mas ainda bem as palestras vão estar disponíveis de aqui a pouco na InfoQ.

Quando trabalhamos com JRuby é muito provável que tenhamos objetos de Ruby ou de Java e que queiramos chamar algum método da outra linguagem que esteja esperando um objeto de uma classe similar nessa linguagem.

Isso acontece mesmo?

Um claro exemplo do problema acontece no Liquid4j, que foi apresentado no ultimo post. Na oportunidade mencionei que o Liquid4j conta com um método em Java chamado de render que recebe um objeto do tipo java.util.HashMap com as chaves e valores do template a ser renderizado. Também mencionei que por detrás dos panos o método utiliza o JRuby para chamar um método Ruby chamado igualmente de render. O problema é que esse ultimo método espera um objeto do tipo Hash, pelo que o processo seria similar a realizar o seguinte:

require "rubygems"
require "liquid"
map = java.util.HashMap.new
Liquid::Template.parse("hi").render(map)

que resultaria em:

Liquid::ArgumentError: Expect Hash or Liquid::Context as parameter

O que aconteceu?

Liquid é um livraria feita unicamente para Ruby e por tanto trabalha com objetos Ruby, ela não sabe trabalhar com objetos Java. Liquid4j é uma livraria feita unicamente para Java, ela utiliza o JRuby mas à nível da API tudo acontece em Java: métodos e objetos. Se Liquid4j chamasse o método render do Liquid com o objeto que recebeu como parâmetro, Liquid não iria reconhecer o tipo dele, pelo que nao iria saber como trabalhar com ele e por isso iria lançar a excepção mostrada.

“Ja chamei métodos Ruby a partir do Java e vice-versa e não precisei converter/traduzir nada!”

Existem alguns tipos de objetos que são convertidos automaticamente. Esses tipos são os tipos primitivos, como pode ser conferido aqui.

Por que JRuby não converte então automaticamente outros tipos de objetos?

Não seria uma boa idéia, porque por exemplo eu poderia querer criar uma função em Ruby que trabalhasse com o tipo java.lang.ArrayList.

A solução

Criei uma gem chamada Rhyme que se encarrega de traduzir objetos entre Ruby e Java. Rhyme traduz o objeto passado como parâmetro no método translate, assim como todos os objetos dentro dele. Isso quer dizer que se por exemplo a gente tiver um objeto do tipo Array que tiver um Hash num dos índices e aquele Hash tiver diferentes objetos nas diferentes keys, todos os objetos a partir do Array irão ser traduzidos para a contraparte em Java, como mostra o seguinte exemplo:

dcrec1:rhyme dcrec1$ jirb
irb(main):001:0> require "rubygems"
=> true
irb(main):002:0> require "rhyme"
=> true
irb(main):003:0> Rhyme.translate([{ "date" => Date.new}])[0]["date"].class
=> Java::JavaUtil::Date

Utilizacão

Se estivermos no Ruby, precisaremos incluir a gem Rhyme no nosso código e interpretar ele com JRuby:

require "rubygems"
require "rhyme"
...
java_obj = Rhyme.translate(ruby_obj)

Por outro lado, se estivermos programando em Java, precisaremos alem do engine do JRuby, os helpers em Java para o Rhyme. O código poderá então ser executado assim:

import com.mouseoverstudio.rhyme.Rhyme;
...
Object rubyObject = Rhyme.translate(javaObject)

Onde encontrar o helper do Java? Como contribuir?

As fontes do projeto estão hospedadas no GitHub. Caso queiram trabalhar com Java e nao estejam a fim de compilar as fontes, existe um jar disponível na pasta dist. As dependências para o helper em Java podem ser encontradas na pasta lib.

Como diz o próprio site, Liquid é uma livraria para renderizar templates seguros que não possam afetar a seguridade do servidor no qual a operação esta sendo realizada.

Ah?

Imaginemos que temos uma aplicação na qual nossos usuários podem criar templates personalizados com dados que disponibilizamos a partir do nosso controller. Por exemplo, no nosso controller carregamos os produtos que certo usuário tem para vender e ele pode criar uma pagina do jeito que ele quiser com dados sobre esses produtos. Para isso ele teria que ter controle sobre uma variável que referenciasse aqueles produtos, de modo que possa pegar os atributos ou ate chamar alguns métodos, como por exemplo product.name() ou product.calculate_price() . Ate ai tudo bem, mas que aconteceria se o produto tivesse um método chamado destroy, sale_to ou qualquer outro que pudesse ter algum impacto no negocio? Vamos deixar o usuário poder chamar essas operações? Claro que não!

Como Liquid soluciona o problema?

Liquid trabalha com um hash de valores que são obtidos a traves do método to_liquid do objeto com o qual se esta trabalhado. Se o usuário tiver a disposição uma lista de produtos e ele solicitar o atributo xpto de um deles, Liquid ira chamar o método to_liquid do produto e do hash que devera voltar como resultado ele ira pegar o atributo xpto. Se chamarmos produto.cor, Liquid ira chamar produto.to_liquid[”cor”]. Como Liquid trabalha com hashes, o cliente não consegue executar operações, somente solicitar dados!

Liquid em ação

Ryan Bates criou um tempo atras um screencast onde fala um pouco sobre Liquid e demostra como é utilizado.

Onde entra Liquid4j na historia?

Liquid4j permite utilizar todo o poder do Liquid na plataforma Java sem a necessidade de escrever uma linha de código Ruby. Isso quer dizer que se com Liquid utilizávamos a sintaxe:

result = Liquid::Template.parse("hi {{name}}").render("name" => "Diego")

com Liquid4j podemos utilizar:

String result = Liquid4j.parse("hi {{name}}").render(map);

onde map referencia uma variável que implementa a interface Map, por exemplo:

Map map = new HashMap();
map.put("name", "Diego");

Para conseguir tal objetivo Liquid4j utiliza JRuby por debaixo dos panos como interpretador da API do Liquid.

Onde aprender mais?

Existe uma boa documentação sobre o Liquid no wiki do projeto. Na seção Liquid para desenhadores existem um monte de exemplos sobre como utilizar Liquid nas views, exemplos que também são válidos para Liquid4j.

Onde se encontra o projeto?

As fontes do projeto estão aqui, no GitHub. Ainda não existe uma documentação la mas já ta vindo. Na pasta dist se encontra um arquivo jar funcional e na pasta lib as dependências do projeto.

Para quem nunca realizou a atividade e estiver procurando algum artigo ou tutorial em português, a primeira vez pode ser muito complicada devido à falta de exemplos; depois da primeira vez é só seguir a receita do bolo.

Vou postar aqui um exemplo de como criar uma conexão com um servidor de MBeans e invocar um método num Mbean determinado. No exemplo vou demonstrar como utilizar a API do JMX para cumprir nossos objetivos, mas para que a demonstração seja um pouco mais interessante, vou chamar a API a partir da linguagem Ruby, poder que o JRuby nos proporciona.

require "java"

import java.util.HashMap

import javax.management.MBeanServerConnection
import javax.management.ObjectName
import javax.management.remote.JMXConnector
import javax.management.remote.JMXConnectorFactory
import javax.management.remote.JMXServiceURL

environment = HashMap.new
credentials = ["system", "manager"].to_java
environment.put(JMXConnector::CREDENTIALS, credentials)
address = JMXServiceURL.new("service:jmx:rmi:///jndi/rmi://mouseoverstudio.com/JMXConnector")
connector = JMXConnectorFactory.connect(address, environment)
connection = connector.getMBeanServerConnection
name = "geronimo:J2EEServer=geronimo,name=com.mouseoverstudio/ejb-app/2.0.0.2/jar,J2EEApplication=null,j2eeType=EJBModule"
obj = ObjectName.new(name)
connection.invoke(obj, "doStop", nil, nil)

O que basicamente fazemos no código é criar um HashMap onde proximamente colocamos um array com nossas credenciais, as quais irão ser utilizadas na hora de realizar a conexão com o servidor. Na seguinte linha criamos um endereço da localização de serviço JMX (mais detalhes aqui) e continuamente utilizamos esse endereço, junto com os credenciais, para criar uma conexão com o serviço.

Uma vez estabelecida a conexão com o serviço JMX, solicitamos uma conexão com o servidor de MBeans e indicamos que queremos executar o método doStop no objeto com o nome indicado pela variável name. Esse objeto representa um MBean no servidor.

Para conhecer o nome do MBean que desejam gerenciar podem acessar o console JMX do servidor sento utilizado. Para realizar esse exemplo eu utilizei o Geronimo (como podem apreciar no nome do MBean), mas o mesmo console existe também tanto como para JBoss como para Glassfish.

Caso a operação invoke precise de parâmetros, podemos indicar eles no terceiro parâmetro do método invoke, passando eles como um array de objetos. Eu não entendo direito o quarto parâmetro (talvez porque nunca precisei utilizar ele) e por tal motivo não vou dizer para que eu acho que existe, devido a que posso terminar confundindo alguém. O mais seguro é que vocês também não precisem utilizar ele, mas se alguem conhece bem sua funcionalidade, por favor me explique!

Quem for precisar mandar uma mensagem para um servidor WQM a partir de um script em Ruby tem aqui um exemplo que também é valido para qualquer programador Java, devido a que a sintaxe é bem fácil de seguir:

require "java"
require "com.ibm.mqjms.jar"

import com.ibm.mq.jms.MQQueueConnectionFactory
import com.ibm.mq.jms.JMSC
import javax.jms.Session

factory = MQQueueConnectionFactory.new
factory.setHostName "wmq1.mouseoverstudio.com"
factory.setPort 1414
factory.setTransportType JMSC::MQJMS_TP_CLIENT_MQ_TCPIP
factory.setQueueManager "mouseoverstudio.queue.manager"
factory.setChannel "channel1"

connection = factory.createConnection
connection.start

session = connection.createSession false, Session::AUTO_ACKNOWLEDGE

message = session.createTextMessage "calling WMQ from JRuby"

queue = session.createQueue "queue:///mouseoverstudio.queue"

sender = session.createProducer queue
sender.send message

sender.close
session.close
connection.close

Para executar o programa acima o arquivo com.ibm.mqjms.jar deve estar dentro do classpath, o qual pode ser indicado com a variável de ambiente CLASSPATH.

Para os programadores Java que forem traduzir o programa, em Ruby :: indica uma constante da classe, similar ao static do Java, pelo que Session::AUTO_ACKNOWLEDGE se traduziria em Java como Session.AUTO_ACKNOWLEDGE.

Para os que desejem uma implementação 100% Ruby também existe o RubyWMQ, porém não testei ele é não sei se é bou ou não.