@billing
Feature: Verify billing

  @important
  Scenario: Missing product description

  Scenario: Several products

No caso do VRaptor temos anotações para poder classificar um controller como recurso REST ou especificar o acesso a uma action:

@Resource
public class ShoppingCartController {
    ...
}

public class ProductsController {
    @Post
    @Path("/products")
    public void add(Product product) {...}
    ...
}

Em Ruby, duas anotações que utilizamos bastante são os métodos private e protected, que sem argumentos restringem a visibilidade dos métodos definidos embaixo deles:

class User
  def jump; end;

  protected
  def eat; end;
  def flirt; end;

  private
  def sleep; end;
  def dream; end;
end

Dependendo do caso, podemos querer anotar nosso código nesse estilo, como por exemplo para especificar que um método esta depreciado, funcionalidade que podemos obter com a gem Canivete do Douglas Campos:

class Bomb
  deprecate
  def explode; end
end

No código acima, quando alguém chamar o método Bomb#explode, o interpretador ira efetivamente executar o método, mas além disso ira imprimir: Warning: calling deprecated method Bomb.explode.

Esse comportamento pode ser obtido por causa do método method_added, presente em todos os módulos do Ruby, que é chamado toda vez que um método e definido, recebendo o nome do mesmo como parâmetro.

Podemos utilizar esse método então por exemplo para criar uma anotação que serva para especificar que os métodos declarados após ela somente podem ser chamados por um admin, algo assim:

class Module
  def method_added(name)
    unless @_admin_only.nil? or @_proxy_method
      @_proxy_method = true
      alias_method "_admin_#{name}", name
      module_eval <<-STRING
        def #{name}(*args, &block)
          _admin_#{name}(*args, &block) if admin?
        end
      STRING
      @_proxy_method = false
    end
  end

  def admin_only
    @_admin_only = true
  end
end

class User
  def admin?
    [true, false][rand(2)]
  end

  admin_only

  def update_password
    puts "password updated"
  end

  def restart_server
    puts "server restarted"
  end
end

Nó código acima, #admin? ira devolver verdadeiro ou falso aleatoriamente e dependendo do resultado, o método chamado ira ser executado ou não.

Quando utilizei o Pivotal com uma equipe remota senti falta de saber o que estava acontecendo em tempo real, pelo que decidi criar o Kilt.

O Kilt é um daemon criado em Ruby que fica solicitando as atualizações dos projetos do usuário configurado e mostra uma notificação de alerta para cada uma recebida:

Com o Kilt consigo ficar programando e ao mesmo tempo ficar sabendo de tudo o que esta acontecendo com os projetos nos quais estou envolvido no Pivotal.

Para instalar o Kilt basta baixar a gem e chamar kilt-install com o token do usuário desejado:

sudo gem install kilt
kilt-install TOKEN

Caso não conheçam o token do usuário, podem executar:

curl -u USERNAME:PASSWORD -X GET https://www.pivotaltracker.com/services/v3/tokens/active

o que devolvera um documento xml com o id e o token do usuário. Caso desejem outro método para solicitar o token, podem se referir à documentação do Pivotal.

Uma vez instalado o Kilt, para rodar ele basta executar:

kilt-app

Tal comportamento pode ser desejado ao querer implementar algo similar ao asset_url do Shopify:

module SitesFilter
  def asset_url(input)
    "/system/assets/#{@context['company'].id}/#{input}"
  end
end

Liquid::Template.register_filter(SitesFilter)

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.

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.

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.

Caso queiramos avaliar x vezes o mesmo script e estejamos chamando o método eval mencionado, o script ira ser compilado x vezes.

O mesmo script precisa ser compilado x vezes?

Não!

O que fazer ao respeito?

A especificação JSR-233 conta com uma classe chamada CompiledScript que como o mesmo nome diz, representa um script compilado, de modo que quando queiramos avaliar o script o único que vamos ter que fazer é executar ele.

Para compilar um script primeiro temos que realizar um casting do engine para a interfase Compilable e logo chamar o metodo compile:

CompiledScript compiledScript = ((Compilable) engine).compile(script)

Logo, quando queiramos avaliar o script compilado o único que vamos ter que fazer e chamar o método eval, passando como parâmetro o contexto (opcional):

Object result = compiledScript.eval(context)