Deixo aqui meus agradecimentos aos organizadores e ao público presente. Abaixo, segue minha apresentação sobre aplicações Rack.

O fato é que este segundo semestre de 2009 foi um turbilhão (no bom sentido) na minha vida. Em alguns meses fiz muito mais coisas que havia feito em anos. Entre elas, posso citar algumas realizações importantes.

ThoughtWorks

Após 5 anos trabalhando na HP, anuncio feliz que estou me transferindo para a ThoughtWorks! Me sinto extremamente orgulhoso de sair de uma empresa da importância da HP e assumir novos desafios no recém criado escritório brasileiro da TW.

Mestrado

Após quase pirar tendo que trabalhar 40 horas semanais e cumprir a agenda de trabalhos/aulas/provas do mestrado, finalmente posso dizer que estou prestes a vencer a primeira etapa do processo todo. Agora terei “apenas” a dissertação pela frente. :-)

Realizações Técnicas

Como se as atividades citadas acima não fossem suficiente, estou quase acabando o desenvolvimento de meu primeiro aplicativo para Iphone e já posso considerar Objective-C mais uma linguagem na minha caixa de ferramentas! Além disso, consegui comparecer nos dois primeiros Conding Dojos de Porto Alegre, conheci pessoalmente caras incríveis do mundo Ágil brasileiro, como Manoel Pimentel e Vinicius Telles, no Agile Day e realizei mais uns freelas por aí. Tudo isso e mais os diversos experimentos relativos ao mestrado, que incluiram tópicos como HTML 5, CSS 3, Processamento de Linguagem Natural, Simulação…

Tá, mas e o Blog?

Voltarei agora a dedicar mais tempo ao Blog. Farei algumas modificações aqui para que o blog não fique com o escopo muito fechado, e tratarei de alguns temas que venho estudando e que considero interessante de compartilhar com todos. Com certeza não abandonarei o Ruby como assunto principal, mas acho que é bom sempre discutirmos assuntos relevantes da área também.

Que venha 2010!!

Nosso primeiro middleware

Se pegarmos o exemplo simples do HelloWorld apresentado no início desta sequência de posts sobre Rack, podemos acomplar um middleware a ele, adicionando funcionalidades extras à aplicação original.

Primeiros, vamos criar nosso Middleware. O exemplo é muito simples. Após imprimirmos um “Hello World!”, vamos informar a hora.

class Middleware
  def initialize(app)
    @app = app
  end

  def call(env)
    status, headers, response = @app.call(env)
    response_body = ""
    response.each { |part| response_body += part }
    response_body += " --- #{Time.now}"
    headers["Content-Length"] = response_body.length.to_s
    [status, headers, [response_body]]
  end
end

Não se assuste se você não entender tudo de cara. A parte mais complicada é cocatenar a informação de tempo na resposta, e isso é feito usando um each, devido ao fato de o response poder ser qualquer objeto que responda a esse método. Além disso, para que nossa resposta seja válida, é interessante colocar no cabeçalho HTTP o comprimento do nosso body.

Mas além do middleware, devemos dizer que nossa aplicação original quer usar ele. E isso deve ser feito em um arquivo .ru:

#config.ru
require 'rack'
require 'middleware'
require 'hello_world'      

use Middleware
run HelloWorld.new

Agora rodando “rackup config.ru” na linha de comando, teremos o seguinte no nosso servidor:

Hello World! — 2009-10-05 14:05:58 -0300

Outros Exemplos de Middlewares

Na primeira parte dessa série de artigos, citei o projeto rack-contrib, que consistia em uma coleção de Middlewares criados pela comunidade e disponibilizado em um único projeto. Além de serem de extrema utilidade no desenvolvimento, eles também servem como um ótimo objeto de estudo para quem quer aprender sobre o funcionamento de um Middleware. Se olharmos o código do exemplo garbagecollection.rb, veremos que o funcionamento é extremamente simples, consistindo apenas de uma chamada forçada do Garbage Collector a cada request na aplicação.

module Rack
  # Forces garbage collection after each request.
  class GarbageCollector
    def initialize(app)
      @app = app
    end

    def call(env)
      @app.call(env)
    ensure
      GC.start
    end
  end
end

Sem entrar no mérito da utilidade do exemplo, é interessante notar a simplicidade do código. Em outro exemplo, podemos ver integração fácil do código do Google Analytics em sua aplicação a com 2 linhas:

require "rack/google_analytics"
use Rack::GoogleAnalytics, :web_property_id => "UA-000000-1"

E o código, propriamente dito, é algo simples:

module Rack #:nodoc:
  class GoogleAnalytics < Struct.new :app, :options

    def call env
      status, headers, response = app.call(env)

      if headers["Content-Type"] =~ /text\/html|application\/xhtml\+xml/
        body = ""
        response.each { |part| body << part }
        index = body.rindex("")
        if index
          body.insert(index, tracking_code(options[:web_property_id]))
          headers["Content-Length"] = body.length.to_s
          response = [body]
        end
      end

      [status, headers, response]
    end

    private

      # Returns JS to be embeded. This takes one argument, a Web Property ID
      # (aka UA number).
      def tracking_code web_property_id
        return <<-EOF


EOF
      end

  end
end

Um outro exemplo interessante é o Middleware CommonLogger, incorporado ao código do projeto Rack. É uma implementação de logs para aplicações Rack, baseada no projeto Commons Logging da Apache . Primeiro, vejamos o código para depois analisar-mos seu funcionamento.

module Rack
  # Rack::CommonLogger forwards every request to an +app+ given, and
  # logs a line in the Apache common log format to the +logger+, or
  # rack.errors by default.
  class CommonLogger
    # Common Log Format: http://httpd.apache.org/docs/1.3/logs.html#common
    # lilith.local - - [07/Aug/2006 23:58:02] "GET / HTTP/1.1" 500 -
    # %{%s - %s [%s] "%s %s%s %s" %d %s\n} %
    FORMAT = %{%s - %s [%s] "%s %s%s %s" %d %s %0.4f\n}

    def initialize(app, logger=nil)
      @app = app
      @logger = logger
    end

    def call(env)
      began_at = Time.now
      status, header, body = @app.call(env)
      log(env, status, header, began_at)
      [status, header, body]
    end

    private

    def log(env, status, header, began_at)
      now = Time.now
      length = extract_content_length(header)

      logger = @logger || env['rack.errors']
      logger.write FORMAT % [
        env['HTTP_X_FORWARDED_FOR'] || env["REMOTE_ADDR"] || "-",
        env["REMOTE_USER"] || "-",
        now.strftime("%d/%b/%Y %H:%M:%S"),
        env["REQUEST_METHOD"],
        env["PATH_INFO"],
        env["QUERY_STRING"].empty? ? "" : "?"+env["QUERY_STRING"],
        env["HTTP_VERSION"],
        status.to_s[0..3],
        length,
        now - began_at ]
    end

    def extract_content_length(headers)
      headers.each do |key, value|
        if key.downcase == 'content-length'
          return value.to_s == '0' ? '-' : value
        end
      end
      '-'
    end
  end
end

Como podemos ver, este é outro exemplo simples de um Middleware muito útil. No método call, é criado um registro simples do momento em que a aplicação principal é chamada, e um método de log pega todas as informações recebidas e formata em uma string que será impressa no servidor. Apesar de parecer difícil de entender a primeira vista, o método log apenas coleta e formata informações contidas no objeto env para adicionar ao log.

Outros Middleware

Existem outros ótimos exemplos de Middlewares pela rede. Optei por citar os mais simples aqui por questões didáticas. Dentre os que eu poderia citar como fundamentais, estão o rack-cache do Ryan Tomayko, que é utilizado largamente em aplicações desenvolvidas com Rails. Posso citar também o “encolhedor” de javascript Javascript Minifier, o criador de responses JSON “Rack::JSONP” também é um bom exemplo, bem como “Rack::MailExceptions” e outros contidos no projeto rack-contrib.

Até o próximo post!

class HelloWorld
  def call(env)
    [200, {"Content-Type" => "text/html"}, "Hello World"]
  end
end

O método def call(env)

Env

O parâmetro recebido pelo método call é uma hash com as propriedades do ambiente do visitante da aplicação. Se alterarmos o nosso HelloWorld para imprimir o objeto env ao invés da string, teremos algo parecido com isso:

{
"REQUEST_METHOD"=>"GET",
"REQUEST_PATH"=>"/",
"REQUEST_URI"=>"/",
"HTTP_VERSION"=>"HTTP/1.1",
"HTTP_HOST"=>"localhost:9292",
"HTTP_USER_AGENT"=>"Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us) AppleWebKit/530.18 (KHTML, like Gecko) Version/4.0.1 Safari/530.18",
"HTTP_ACCEPT"=>"application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5", "HTTP_ACCEPT_LANGUAGE"=>"en-us", "HTTP_ACCEPT_ENCODING"=>"gzip,deflate",
"HTTP_CONNECTION"=>"keep-alive", "GATEWAY_INTERFACE"=>"CGI/1.2",
"SERVER_NAME"=>"localhost",
"SERVER_PORT"=>"9292",
"SERVER_PROTOCOL"=>"HTTP/1.1",
"SERVER_SOFTWARE"=>"Mongrel 1.1.5",
 "PATH_INFO"=>"/",
 "SCRIPT_NAME"=>"",
 "REMOTE_ADDR"=>"127.0.0.1", "rack.version"=>[0, 1], "rack.input"=>#, "rack.errors"=>#>, "rack.multithread"=>true, "rack.multiprocess"=>false, "rack.run_once"=>false, "rack.url_scheme"=>"http",
 "QUERY_STRING"=>""}
 

Dentre as informações impressas, algumas são bem importantes, como:

• REQUEST_METHOD: Informa qual o verbo HTTP (GET, PUT, DELETE…) usado pelo usuário ao acessar a página.
• HTTP_USER_AGENT: Informa o browser do usuário, facilitando o tratamento para browsers diferente em sua aplicação.
• QUERY_STRING: Informa os argumentos passados após o “?” da url, útil para fazer parsing dos parâmetros.

Status

O primeiro objeto retornado no array de resposta é um inteiro, representando o status da resposta que sua aplicação retornará no método. O 200 do nosso exemplo, representa “OK” segundo a especificação do HTTP. É aqui seu controle de exceção jogará aquele lindo “Erro 404″ quando o usuário digitar incorretamente um sub-caminho de sua aplicação. ;-)

HTTP Headers

Cabeçalhos HTTP informam o tipo de retorno do pacote. O segundo objeto do nosso retorno deve OBRIGATORIAMENTE responder a um método “each” e devolver chaves e valores de seus elementos, tipicamente um Hash, como no nosso exemplo. A chave Content-Type, por exemplo, deve retornar o tipo de retorno a ser esperado, podendo ser HTML(“Content-Type” => “text/html”), XML, MP3 (‘Content-Type’ => ‘audio/mp3′), entre outros.

Response Body

O retorno “Body” deve responder ao método each retornando um array de strings. Este será o conteúdo que será apresentado ao usuário no navegador.

ATENÇÃO: Segundo a documentação atual do Rack, o Body não deve mais ser uma simples string(como nos exemplos do post anterior). Aparentemente isto quebrará no Ruby 1.9.

Rack:Builder

É uma ferramenta que nos permite construir aplicações Rack utilizando uma DSL para “costurar” diferentes middlewares e aplicações. Os Builders são os parafusos das estantes, ou a cola que une as estruturas separadas criando uma inteiramente nova. Na verdade, o Builder é o cara que torna o a idéia do Rack tão genial. A facilidade que ele proporciona na criação de Middlewares ficará bem claro no próximo post.

Os métodos fornecidos pela DSL do Buider são:

• run
• use
• map

Rack::Builder#run

É o método que o servidor web procurará para a execução da aplicação Rack. No exemplo abaixo, nosso builder é informado para rodar o bloco chamado clock a cada resquisição à porta 9292. Nada demais, por enquanto. Mas na medida que a aplicação for crescendo, é possível criar estruturas extremamente complexas que veremos posteriormente.

clock = Proc.new {|env| [200, {"Content-Type" => "text/html"}, ["#{Time.now}"]]}
builder = Rack::Builder.new do
  run clock
end
Rack::Handler::Mongrel.run builder, :Port => 9292

Rack::Builder#use

É o método utilizado para acomplar novas middlewares à sua aplicação. No exemplo abaixo, o middleware CommonLogger é adicionado à nossa aplicação com apenas uma linha de código:

clock = Proc.new {|env| [200, {"Content-Type" => "text/html"}, ["#{Time.now}"]]}
builder = Rack::Builder.new do
  use Rack::CommonLogger
  run clock
end
Rack::Handler::Mongrel.run builder, :Port => 9292

CommonLogger é um Middleware que adiciona a funcionalidade de log ao seu servidor. Rodando este exemplo, você terá um log semelhante ao de Rails e Sinatra em seu console, como no exemplo abaixo:

127.0.0.1 – - [25/Sep/2009 17:17:03] “GET / HTTP/1.1″ 200 30 0.0002
127.0.0.1 – - [25/Sep/2009 17:17:14] “GET / HTTP/1.1″ 200 30 0.0002
127.0.0.1 – - [25/Sep/2009 17:17:15] “GET /2 HTTP/1.1″ 200 30 0.0002
127.0.0.1 – - [25/Sep/2009 17:17:28] “GET /testand_log HTTP/1.1″ 200 30 0.0002

Rack::Builder#map

Método utilizado para mapear (jura?) suas rotas HTTP. Não a toa, é semelhante ao routes.rb do Rails, afinal, ambos são implementações diretas das best practices de desenvolvimento web atual.

Para ilustrar, criaremos um exemplo de aplicação que além de informar as horas, oferece um caminho para que o usuário seja informado em que ano ele se encontra.

clock = Proc.new {|env| [200, {"Content-Type" => "text/html"}, ["#{Time.now}"]]}
builder = Rack::Builder.new do
  use Rack::CommonLogger
  map '/' do
    run clock
  end

  map '/year' do
    run Proc.new {|env| [200, {"Content-Type" => "text/html"}, ["#{Time.new.year}"]] }
  end
end
Rack::Handler::Mongrel.run builder, :Port => 9292

Com este exemplo, se após iniciarmos a nossa aplicação tentarmos acessar a url http://localhost:9292/year, receberemos o ano atual em nosso browser.

Ok, mas e rotas aninhadas? Extremamente simples também! Acompanhem o exemplo abaixo.

builder = Rack::Builder.new do
  use Rack::CommonLogger
  map '/' do
    run Proc.new {|env| [200, {"Content-Type" => "text/html"}, ["Welcome to my page"]]}
  end

  map '/clock' do
    map '/' do
      run Proc.new {|env| [200, {"Content-Type" => "text/html"}, ["#{Time.now}"]] }
    end

    map '/year' do
      run Proc.new {|env| [200, {"Content-Type" => "text/html"}, ["#{Time.now.year}"]] }
    end

    map '/hour' do
      run Proc.new {|env| [200, {"Content-Type" => "text/html"}, ["#{Time.now.hour}"]] }
    end    

  end
end
Rack::Handler::Mongrel.run builder, :Port => 9292

Ok, mas nós podemos seguir o conceito de DRY para evitar código desnecessário:

def create_proc(body_return)
  Proc.new {|env| [200, {"Content-Type" => "text/html"}, ["#{body_return}"]]}
end

builder = Rack::Builder.new do
  use Rack::CommonLogger
  map '/' do
    run create_proc('Welcome to my page')
  end

  map '/clock' do
    map '/' do
      run create_proc(Time.now)
    end

    map '/year' do
      run create_proc(Time.now.year)
    end

    map '/hour' do
      run create_proc(Time.now.hour)
    end    

  end
end
Rack::Handler::Mongrel.run builder, :Port => 9292

Desta maneira, criamos uma aplicação com as seguintes rotas disponíveis:

• http://localhost:9292/
• http://localhost:9292/clock
• http://localhost:9292/clock/year
• http://localhost:9292//clock/hour

Cenas do Próximo Capítulo

Após aprendermos o conceito do Rack, sua estrutura e os 3 principais métodos oferecidos para criação de aplicações, nos focaremos na criação de Middlewares no próximo post. Entenderemos seus conceitos e investigaremos alguns exemplos bem sucedidos disponíveis na web. Fiquem ligados!

Introdução da Introdução

Em fevereiro de 2007, Christian Neukirchen postou em seu blog um artigo chamado “Introduzindo Rack” no qual falava sobre a quantidade de código duplicado que ele achava em diferentes Frameworks Web escritos em Ruby. Ao anunciar a sua criação, o autor tocava em um ponto importante aonde escrevia, com razão, sobre um assunto que na verdade não era culpa dos desenvolvedores.

Sendo todos frameworks web, era de se esperar que muitas coisas fossem parecidas. A grande sacada do criador de Rack, foi o fato de ter percebido que web pode, em grande parte, ser resumida como uma série de requisições e respostas HTTP. O resto é framework que vai por cima.

HTTP pode ser resumido de maneira muito simples, como uma série de REQUESTS e RESPONSES. Rack utiliza-se muito bem dessa “simplicidade” para encapsular praticamente todo o controle dessa troca de mensagens em um objeto Ruby. Ao encapsular as requisições HTTP, Rack é capaz de prover interfaces para aplicações entre web servers, web frameworks e middlewares.

O que é Rack?

Podemos considerar o Rack uma especificação para a criação de aplicações web desenvolvidas com ruby. Segundo Dan Webb em sua apresentação “8 minutes on Rack“:

“Se você tem um objeto Ruby que possui um método call cujo o único argumento é env e retorna um array com 3 elementos ([200, {"Content-Type" => "text/html"}, "Hello World!"] ), então ele pode ser conectado a qualquer web server que suporte Rack”

Mas a definição mais simples possível é a que Rack provê uma interface mínima entre web servers e web frameworks escritos em Ruby.

Essa definição é interessante, mas Rack nos proporciona mais que isso. Com seu Builder (que será explorado em um post mais adiante) é possível integrar e ordenar módulos (ou middlewares) empilhados formando uma aplicação com os recursos desde módulos agrupados.

Por que usar Rack?

Oferece controle de requisições, sessões e cookies automaticamente.

Como Rack é uma especificação, desenvolvedores podem criar códigos que funcionam em qualquer aplicação e compartilhar módulos para uso de outros desenvolvedores. Dessa idéia já surgiu o rack-contrib, uma coleção de Midlewares e ferramentas disponível para que qualquer um utilize em sua aplicação.

Desenvolva middlewares que funcionam com Rails, Sinatra, Ramaze…

Qualquer servidor web que ofereça suporte a Rack rodará sua aplicação normalmente. Além disso, ela poderá ser transferida e replicada em servidores diferentes sem a necessidade de configurações diferentes.

A lista de servidores que já suportam Rack é grande. Até agora, os seguintes já suportam:

• Mongrel
• EventedMongrel
• SwiftipliedMongrel
• WEBrick
• FCGI
• CGI
• SCGI
• LiteSpeed
• Thin
• Ebb
• Fuzed
• Phusion Passenger
• Unicorn

Além dos servidores, praticamente todos os frameworks web desenvolvidos em Ruby já possuem adaptadores para Rack. A lista atual inclui os seguintes frameworks:

• Camping
• Coset
• Halcyon
• Mack
• Maveric
• Merb
• Racktools::SimpleApplication
• Ramaze
• Ruby on Rails
• Rum
• Sinatra
• Sin
• Vintage
• Waves
• Wee

Um exemplo minúsculo

O Rack possui uma ferramenta chamada rackup, que roda arquivos do tipo .ru. Neste exemplo, crie um arquivo chamado hello.ru e digite a seguinte linha:

    run Proc.new {|env| [200, {"Content-Type" => "text/html"}, "Hello Horld!"]}

Agora rode o arquivo via linha de comando usando rackup:

> rackup hello.ru

E acesse o seguinte endereço em seu browser: http://localhost:8765/.

Pronto, você acabou de criar a página web no com o menor número de caracteres possível!

Um segundo exemplo um pouco maior

require 'rubygems'
require 'rack'
class HelloWorld
  def call(env)
    [200, {"Content-Type" => "text/html"}, "Hello Horld!"]
  end
 end
Rack::Handler::Mongrel.run HelloWorld.new, :Port => 9292

Apesar de sua função ser a mesma do anterior, este exemplo merece ser explicado. Como todo objeto Rack, nosso exemplo responde a um método call, retornando um array com os três elementos principais do Rack (que serão explicados no próximo post). Após definirmos esse simples método na nossa classe, basta instanciarmos um servidor (Mongrel nesse caso) que receberá requisições por uma porta (9292) e retornará o conteúdo do terceiro objeto do array do método call.

Se esse início já clareou um pouco mais as idéias sobre o Rack, fique ligado para os posts que seguirão a série para saber mais sobre Middlewares, Rails Metal, Builders e todos os outros elementos do maravilhoso mundo ro Rack!

Por curiosidade, resolvi tentar descobri todas as maneiras possíveis de se executar um loop com Ruby, e tentarei lista-las aqui.

While

Loops do tipo While no Ruby são exatamente iguais aos encontrados em Java, C# e outros. Um bloco deve ser executado enquanto uma condição for verdadeira.

x = 1
while(x <4)
	puts x
	x +=1
end

=> 1
   2
   3

O while também pode ser usado ao final de um bloco, de maneira semelhando ao “DO…WHILE” de outras linguagens.

x =1
begin
	puts x
	x+=1
end while (x<4)

=> 1
   2
   3

Irmão inverso do while, o until executa um bloco de código até que uma condição seja verdadeira.

x = 1
until(x>3)
  puts x
  x +=1
end

=> 1
   2
   3

E, como no while, também pode ser usado como condição de execução ao fim de um bloco.

x = 1
begin
  puts x
  x+=1
end until (x>3)

=> 1
   2
   3

For

Outro loop clássico das linguagens, o for assume algumas particularidades no Ruby. Os ranges de Ruby podem ser usados em um for. Tanto na versão “intervalo aberto e fechado”.

#Intervalo aberto
for i in 1..3
  puts i
end

=> 1
   2
   3
#Intervalo fechado
for i in 1...4
  puts i
end

=> 1
   2
   3

Além disso, podemos iterar sobre letra do alfabeto, como no exemplo abaixo:

for x in 'a'..'d'
  puts x
end

=> a
   b
   c
   d

Iteradores

O iterator, é um padrão de projeto que nos permite percorrer objetos agregados sem que sua verdadeira relação com o grupo ao qual pertence seja exposto. Ruby já fornece o padrão iterator através do método each.

[1,2,3].each do |i|
  puts i
end

=> 1
   2
   3

Que também pode ser usado com ranges:

(1..3).each do |i|
  puts i
end

=> 1
   2
   3

Métodos da Classe Fixnum

As opções não param nas citadas acima. Ainda temos alguns métodos da flasse Fixnum que nos fornecem comportamentos semelhante aos loops clássicos.

O método Fixnum#times recebe um bloco como parâmetro, e o executa o mesmo número de vezes do objeto Fixnum que o executou.

i = 1
3.times do
  puts i
  i+=1
end

=> 1
   2
   3

Temos também os métodos upto e downto que, como o times, também recebe um bloco e o executa, porém com um objeto de índice do bloco.

1.upto(3) {|i| puts i}

=> 1
   2
   3

3.downto(1) {|i| puts i}

=> 3
   2
   1

Outras Esquisitices

Em Ruby também temos um loop infinito, semelhante a um while(true), que deve ser quebrado mediante alguma condição definida dentro do bloco de execução. Um exemplo prático poderia ser uma verificação de senha via linha de comando:

loop do
  puts "Enter your password"
  gets
  chomp
  break if $_ =="123"
  puts "WRONG! Try again!"
end

E por fim, algumas malandragens típicas do Ruby. Como eu usei o mesmo exemplo em todo esse post, aqui vão algumas outras maneiras de imprimir na tela os números:

puts (1..3).to_a* "\n"

puts (1..3).to_a

puts *(1..3)

puts 1,2,3

Será que eu me esqueci de algum?

Pois há dois dias atrás aconteceu, o Delicious sofreu reformulações e a implementação que eu tinha foi pro espaço.

Já consertei todos os problemas e consegui implementar já algumas funções novas, como a busca por “Fresh links” que retornam páginas mais atuais, seguindo a tendência de instant search que anda sendo discutida bastante atualmente. Algumas features novas ainda não foram mapeadas, mas estas não afetam o funcionamento das atuais.

Hoje eu dei um push das correções pro Github e atualizei o readme para quem quiser usar. O código atualizado pode ser encontrado aqui:
http://github.com/tbueno/delicious-ext/tree/master

O Poder do JRuby

Uma das melhores vantagens fornecidas pelo JRuby é a possibilidade de utilizarmos as trocentas ferramentas já existentes no mundo Java utilizando Ruby. E foi exatamente isso que Jeremy Ashkenas fez. Perceba que a integração é relativamente simples entre as duas linguagens:

require 'java'

module Processing

  # Conditionally load core.jar
  require "#{RP5_ROOT}/lib/core/core.jar" unless Processing.online? || Processing.embedded?
  import "processing.core"
  .
  .
  .
class App < PApplet
  .
  .

Ao importar o .jar do Processing , temos à disposição todas as classes, inclusive a PApplet que é a que nos disponibiliza as principais funções de desenho. O resto do código é praticamente formado apenas por wrappers e funções auxiliares de integração. A lógica toda já está pronta, e em Java.

Aconselho fortemente uma olhada no código do ruby-processing para quem quiser aprender como se faz uma aplicação completa usando JRuby

Os Corais de Bach

Em uma disciplina de Visualização de Dados, um trabalho consistia em escolher um dataset do site Machine Learning Repository e criar uma maneira de visualizar esses dados. Escolhi os Corais de Bach, devido ao fato de eu ser fã do magnífico compositor alemão.

O primeiro desafio foi destrinchar a base de dados. Para vocês terem uma idéia, aqui segue um exemplo de uma peça de coral contida na coleção:

(1 ((st 8 ) (pitch 67) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 12) (pitch 67) (dur 8 ) (keysig 1) (timesig 12) (fermata 0))((st 20) (pitch 74) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 24) (pitch 71) (dur 6) (keysig 1) (timesig 12) (fermata 0))((st 30) (pitch 69) (dur 2) (keysig 1) (timesig 12) (fermata 0))((st 32) (pitch 67) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 36) (pitch 67) (dur 6) (keysig 1) (timesig 12) (fermata 0))((st 42) (pitch 69) (dur 2) (keysig 1) (timesig 12) (fermata 0))((st 44) (pitch 71) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 48 ) (pitch 69) (dur 8 ) (keysig 1) (timesig 12) (fermata 1))((st 56) (pitch 71) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 60) (pitch 74) (dur 8 ) (keysig 1) (timesig 12) (fermata 0))((st 68 ) (pitch 72) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 72) (pitch 71) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 76) (pitch 69) (dur 8 ) (keysig 1) (timesig 12) (fermata 0))((st 84) (pitch 67) (dur 8 ) (keysig 1) (timesig 12) (fermata 1))((st 92) (pitch 71) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 96) (pitch 71) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 100) (pitch 72) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 104) (pitch 74) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 108 ) (pitch 74) (dur 6) (keysig 1) (timesig 12) (fermata 0))((st 114) (pitch 72) (dur 2) (keysig 1) (timesig 12) (fermata 0))((st 116) (pitch 71) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 120) (pitch 69) (dur 8 ) (keysig 1) (timesig 12) (fermata 1))((st 128) (pitch 67) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 132) (pitch 71) (dur 8 ) (keysig 1) (timesig 12) (fermata 0))((st 140) (pitch 72) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 144) (pitch 74) (dur 8 ) (keysig 1) (timesig 12) (fermata 0))((st 152) (pitch 72) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 156) (pitch 71) (dur 12) (keysig 1) (timesig 12) (fermata 0))((st 168) (pitch 67) (dur 8 ) (keysig 1) (timesig 12) (fermata 1))((st 176) (pitch 71) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 180) (pitch 74) (dur 8 ) (keysig 1) (timesig 12) (fermata 0))((st 188 ) (pitch 72) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 192) (pitch 71) (dur 8 ) (keysig 1) (timesig 12) (fermata 0))((st 200) (pitch 69) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 204) (pitch 67) (dur 6) (keysig 1) (timesig 12) (fermata 0))((st 210) (pitch 69) (dur 2) (keysig 1) (timesig 12) (fermata 0))((st 212) (pitch 71) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 216) (pitch 69) (dur 8 ) (keysig 1) (timesig 12) (fermata 1))((st 224) (pitch 71) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 228 ) (pitch 74) (dur 8 ) (keysig 1) (timesig 12) (fermata 0))((st 236) (pitch 72) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 240) (pitch 71) (dur 4) (keysig 1) (timesig 12) (fermata 0))((st 244) (pitch 69) (dur 8 ) (keysig 1) (timesig 12) (fermata 0))((st 252) (pitch 67) (dur 8 ) (keysig 1) (timesig 12) (fermata 1)))


Pra quem conhece Lisp, essa bizarrice não assusta tanto, mas eu precisava de uma maneira de tornar essa maçaroca em algo entendível. Aí vem a beleza do Ruby e sua facilidade para processamento de texto. Com poucas linhas, um arquivo com 100 peças de corais como a mostrada acima vira uma estrutura simples com tudo que eu preciso para minha visualização:

lines = []
  File.open("bach.lisp", "r") do |infile|
       while (line = infile.gets)
           lines << "#{line}" unless line.size == 1 #ignora linhas em branco
       end
  end

Com tudo mastigado, basta partirmos para as operações matemáticas.

Hora do Desenho

Na minha busca por reconhecer padrões nas músicas em minhas visualizações, escolhi arcos, porque eles passam uma noção de duração facilmente perceptível, e as cores foram escolhidas para as notas, ficando o eixo X para o momento em que as notas iniciam.

def draw
  background 0,0,0
  draw_labels
  draw_rectangles
  @arcs.each do |ar|
    noFill
    stroke(ar.c)
    smooth
    semicircle(ar.st+ar.duration, X_AXIS, ar.st,X_AXIS )
    line(ar.st+ar.duration, X_AXIS+10, ar.st+ar.duration, X_AXIS+10+(ar.pitch*2))
  end

end

def semicircle xLeft, yLeft, xRight, yRight
  pushMatrix
    diameter = dist xLeft, yLeft, xRight, yRight
    angle = atan2(yRight - yLeft, xRight - xLeft)
    arc((xLeft + xRight)/2, (yLeft + yRight) / 2, diameter, diameter, angle, angle + PI)
  popMatrix
end

O resultado, pode ser conferido nos screenshots abaixo:

Se levarmos em conta o tempo curto entre os trabalho, o resultado alcançado foi interessante. Meu código possui muitas duplicações e o algoritmo não está nada otimizado. Com mais tempo, faço uma versão melhor, aonde qualquer arquivo de música MIDI possa ser interpretado.

O Working With Rails, mais conhecido como wwr, é uma app que indexa todos os desenvolvedores que trabalham com Rails. Oferece formas de analisar a comunidade por autoridade, popularidade e por país.

Falando em país, posso dizer que já estivemos quase no top, mas hoje estamos amargando a 4 posição – atrás dos United States, United Kingdom e India.

Temos muito mais que 1000 desenvolvedores por aqui e precisamos mostrar isto. Nós, brasileiros, não estamos acostumados a cuidar do nosso marketing pessoal, perdemos feio para os Indianos – nossos maiores concorrentes no mercado de offshore outsourcing.

A lembrança é muito pertinente, e resolvi ecoar por aqui também o chamamento dele. Vamos fortalecer a imagem do Brasil como celeiro de grandes desenvolvedores Rails. Indique as pessoas que você acredita que agregam conhecimento à comunidade Rails Brasil.

Este é o meu perfil, e este é o do Oséias, caso achem que a gente merece indicação. ;-)

Tudo começou na quarta, as 9:00 com a palestra de TDD e Rails do Lucas Húngaro. Quando cheguei, cerca de 15 pessoas assistiam ao começo da apresentação. Confesso que senti medo e uma certa vergonha, afinal, sou da cidade organizadora e não gostaria de um evento dessa magnitude entregue às moscas. Mas o povo foi chegando…chegando…e quando me dei conta, assistia a uma ótima palestra sobre diversas ferramentas de teste acompanhado de mais de 100 pessoas. Um começo com chave de ouro. Recomendo a todos que dêem uma olhada no materia do Lucas aqui. Foi uma palestra excelente.

A palestra seguinte seria sobre o Seaside, framework web feito em SmallTalk, que seria apresentado com paralelos sendo traçados com Rails, mas o Fábio Kung não pôde aparecer. Foi uma pena, pois Seaside era um dos assuntos que eu mais queria conhecer no FISL. Enfim, a palestra substituta acabou sendo legal, mas fugiu completamente do que eu esperava.

A Propaganda é a alma do negócio. Crédito: Akita.

Na sexta, o negócio começou a pegar fogo. A visita do nosso PRESIDENTE atraiu curiosos de todos os tipos. Helicópteros sobrevoavam o campus da PUCRS, detectores de metais e batalões de repórteres que tiravam fotos até de mascotes fazendo embaixadinhas tornavam o ambiente um caos. Saí do trabalho e rumei para ver a palestra do Akita.

Ao chegar, tomei um susto ao receber o aviso que não poderia entrar pois o auditório estava LOTADO. Sim, um auditório pra, sei lá, umas 300 pessoas, LOTADO. Com sorte, consegui entrar e perceber porque o Akita é sem dúvida, nosso Ruby Rockstar. Uma palestra sensacional, passeando alucinadamente por todos os pontos importantes do ecossistema do Rails, com demos, vídeos, live-coding e tudo mais. Sério, mais alguns minutos e eu acho que o cara iria dançar e cantar! Tenho certeza que os que não conheciam Rails – cerca de metade do público levantou a mão quando Akita questionou -, sairam impressionados da sala.

Os slides estão aqui e o código aqui (Note que os capítulos estão separado por branches).

Em seguida foi a vez de Sylvestre Mergulhão apresentar outra palestra interessantíssima sobre escalabilidade em projetos Rails, afinal, todos sabemos que Rails não escala :-P. O mais interessante da palestra de Sylvestre, pelo menos pra mim, foi a oportunidade de conhecer um bom exemplo de site com um bom número de visitas, rodando completamente em Rails, sobre nginx, hospedado na Engine Yard. Ou seja, um case que utiliza tudo que volta e meia a gente lê em blogs no exterior, portado e mantido por brasileiros!

Infelizmente, tive que voltar voando para o trabalho e não consegui trocar uma idéia com o Akita no estande da Locaweb. O papo terá que ser adiado para a Rails Summit desse ano :-). Aliás, foi uma pena minha falta de tempo para aproveitar mais as palestras. Queria ter visto outras apresentações como a do Boo-Blox ou a do Peter Sunde, criador do Pirate Bay que lotou 3 auditórios e engasgou as transmissões streaming do evento.

A parte rubista no FISL foi encerrada com a palestra de PubSub do Pablo Lorenzzoni. Infelizmente, não consegui comparecer, mas espero achar informações na internet para saber como foi este encerramento.

O saldo final foi extremamente positivo ao meu ver. Posso afirmar que estamos, como Rubistas, maduros suficientes para entrar em qualquer evento de informática e fazer bonito e surpreender outros desenvolvedores com a força de nosso conhecimento e o poder das ferramentas criadas em torno de nós.