O que é o Rack?

O Rack é uma interface entre servidores web e aplicações Ruby, baseada no padrão WSGI do Python. Ele possui diferentes handlers para os mais diversos webservers, como: Passenger, Mongrel, Thin, Ebb, Webrick, entre outros.

Ele é usado pelos principais frameworks Ruby: Merb, Sinatra, Ramaze, Waves, e outros. O Rails 2.3 virá com suporte à Rack. Ele também pode ser considerado um framework para construir frameworks. O Nyane é um bom exemplo disto, mas existem muitos outros.

Ele tem suporte à Middlewares que são como mini-funcionalidades que podem ser compartilhadas entre todos os frameworks que suportam Rack. Este artigo possui uma lista de diversos middlewares interessantes.

Através do Rack::Cascade é possível utilizar diferentes frameworks dentro de uma mesma aplicação.

Aplicações Rack

Uma aplicação Rack nada mais é do que um simples objeto Ruby (não precisa ser uma classe) que responde ao método call. Ele precisa de apenas um argumento, o environment e retorna um Array com três valores: O status (200, 404, 500), o header (’Content-Type’ => ‘text/html’, ’Location’ => ‘/’, ) e um objeto que responde ao método each (’uma string’).

Exemplos

O seguinte código é um exemplo de uma aplicação Rack:

class Hello
   def call(env)
      [ 200, {}, 'Hello World!' ]
   end
end

Mas, como eu disse, não precisa ser uma classe, um simples lambda também é uma aplicação Rack válida:

lambda { |env| [200, {}, 'Hello World!' }

Isto é válido, porquê o método lambda retorna uma Proc, que responde pelo método call.

Nos dois exemplos, o retorno do método call é um Array com o status 200, headers em branco em uma string 'Hello World!'. Exatamente o que o Rack precisa para funcionar. :)

E esse environment, o que é?

O env (objeto passado ao método call), é um hash com diversas variáveis de ambientes, por exemplo: PATH_INFO, QUERY_STRING, REQUEST_METHOD, SERVER_PORT, entre outros.

E pra que ele serve?

Você usa o env para construir um objeto Rack::Request, que pode ser usado para obter os parâmetros GET e POST:

request = Rack::Request.new(env)
# returns the data received in the query string
request.GET
# returns the data received in the request body
request.POST

Eu sei receber um request, mas e como eu envio uma resposta?

O Rack::Response é usado para criar uma resposta HTTP. Com ele você pode configurar headers, criar cookies, entre outros:

# uma resposta simples
response = Rack::Response.new
response.status = 200
response.body("Hello World!")
response.finish
 
# um redirect
response = Rack::Response.new
response.status = 302
response.headers["Location"] = "/"
response.finish
 
# criando um cookie
response = Rack::Response.new
response.set_cookie('cookie-name', 'content')
response.finish
 

Rackup

O Rack vem com um binário chamado rackup que pode ser usado para servir aplicações Rack rapidamente. Ele lê arquivos .ru (não pode ser .rb), também chamados de “rack config files”, e usa o handler do Mongrel para servir a aplicação. Ele já adiciona os middlewares para Logging (Rack::CommonLogger) e Exceptions (Rack::ShowExceptions).

Exemplos

Usando uma classe:

class Hello
   def call(env)
      [ 200, {}, 'Hello World!' ]
   end
end
 
run Hello.new

Um lambda:

run lambda {|env| [200, {}, "Hello World!"]}

Isso mesmo, não precisa de nenhum require. :) Para rodar, é simples:

rackup app.ru

Por padrão, ele rodará na porta 9292.

Ou, se você preferir, pode rodá-lo com o Thin:

thin start -R app.ru

Você também pode usar o Handler do Mongrel diretamente:

require "rubygems"
require "rack"
 
app = lambda { |env| [200, {}, 'Hello World!'] }
Rack::Handler::Mongrel.run(app, :Port => 3000)

Neste caso, o require é necessário.

Finalizando

Espero que este post tenha ajudado você a entender melhor o que é o Rack e o porquê dele ser importante no mundo Ruby. Nos próximos posts, irei explicar como construir e usar Middlewares, e falarei de uma das novas features do Rails que usa o Rack, o Metal, muito discutido nessa última semana.

Por enquanto não temos muito conteúdo, mas a idéia é ter Artigos, Tutoriais e Documentação traduzida para o Merb. Temos também um Wiki e um Fórum configurados.

Ainda falta um layout definitivo e estou à procura de interessados para escrever artigos. 

Mas é isso! Agora é só fazer a comunidade crescer. :)

O Nyane nasceu depois que eu resolvi estudar o Rack, e me deparei com isto: Very Simple Rack Framework.

Construir um framework baseado no Rack, ao vivo, durante uma apresentação de 30 minutos? Não é possível! Olha a sintaxe, tão bonitinha, como construir isso de maneira rápida e fácil de apresentar? Aquilo me deixou muito intrigado. Passei horas procurando na internet como construir um framework que fosse capaz de aceitar aquela sintaxe. Infelizmente, a documentação do Rack para este tipo de finalidade é quase nula.

Fui atrás de alguns frameworks simples baseados no Rack. O primeiro que eu encontrei foi o Coset. Mas o código era meio difícil de entender. Quer dizer, o código do framework em si não é complicado, acontece que eu não enxergava a ligação entre aquele código e o Rack. Iria precisar de algo bem mais simples pra começar.

Foi aí que eu encontrei algumas apresentações sobre como construir aplicações Rack. Agora, todo aquele código começava a fazer sentido. Mesmo assim, eu queria algo mais simples. Foi quando eu encontrei o Invisible. A versão inicial era ainda mais simples. Ótimo! Achei meu ponto de partida.

No final de semana passado, estava em um quarto de hotel sem internet. Resolvi começar a “brincar sério” com o Rack. Foi aí que me saí com isso:

class Nyane
 
  def initialize(&block)
    @actions = []
    instance_eval(&block)
  end
 
  def get(route, &block)
    @actions << [route, block]
  end
 
  def call(env)
    action = @actions.detect { |route, block| env["PATH_INFO"].match(Regexp.new("^#{route}$")) }
 
    if action
      [200, {'Content-type' => 'text/html'}, action.last.call]
    else
      [404, {'Content-type' => 'text/plain'}, "Not found"]
    end
  end
 
end

22 linhas no total. 17 linhas de código. E mesmo assim, capaz de rodar isto:

require "nyane"
 
app = Nyane.new do
  get "/" do
    "Hello!"
  end
 
  get "/hello" do
    "Hello, hello, hello!"
  end
 
  get "/bye" do
    "Goodbye!"
  end
end
 
run app

Genial!

O código estava pronto. Queria liberar logo para que outras pessoas pudessem “brincar” com o Rack também. Conversando com o Nando, ele disse que o framework teria que ter “uma razão pra existir”. Mesmo eu dizendo que não era algo pra ser levado a sério, era só pra estudo. Aí ele disse que se fosse pra desenvolver um framework, teria que ter um motivo e se diferenciar dos outros. E eu continuava dizendo que era algo insignificante! :P

Bom, se é preciso motivos, e diferenciá-lo, então eu farei! :)

A idéia do Nyane é ser um framework extremamente simples. Nada de helpers, layouts, partial. Nem mesmo suporte à cookies, sessions. Quer saber? Vou liberar sem suporte à POST! Aí está a diferença dele pros outros. Duvido que exista um framework que não suporte POST. :P

Depois disso, faltava um nome. Mas escolher um nome para um projeto que não devia ser levado a sério? Parecia demais para mim. Resolvi brincar com o nome. Nyane, quer dizer insignificante em Sesotho. Sim, um framework insignificante. :P

Coloquei o código no GitHub no começo da semana. Mostrei apenas para alguns amigos. Apesar de ser algo bem simples e experimental, algumas pessoas se interessaram em usá-lo para alguma pequenas aplicações. Claro, você não vai construir nenhum site completo com ele, mas, quem sabe uma área do site que não necessite de sessões, cookies ou até mesmo POST. Quando eu construía este código, não via aplicação alguma, nem mesmo achava que pudesse ser usado em produção. Hoje, vejo algumas áreas (ou serviços) de sites maiores que podem ser reescritos sem a necessidade de nada acima, nem mesmo POST.

Sim, o suporte à POST pode ser algo que amplie o uso do framework, mas, qual seria a grande diferenciação dele para os outros? :P Bom, fica para uma próxima versão.

Melhor: que tal você experimentar um pouco com o código e implementar isto? Que acha? :)

O evento foi sensacional. A organização estava impecável, ainda mais para uma primeira edição. O melhor evento voltado para programadores que eu participei. 

Estiveram presentes grandes nomes da comunidade internacional como Chad Fowler, Dr. Nic, Chris Wanstrath, os caras da Phusion, Jay Fields, David Chelimsky, Obie Fernandez. O pessoal da comunidade brasileira também fizeram bonito: Fabio Akita, Carlos Brando, George Guimarães, Danilo Sato, Manoel Lemos e o pessoal da WebCo, Vinícius Telles, Fabio Kung, entre outros.

Com certeza, o mais interessante foi conhecer as pessoas por trás de URLs. Pessoas como: TaQ, Davis Cabral, Ozéias Santana, Spicee, Carlos Eduardo, Júlio Monteiro, Marcos Tapajós, e muitas outras pessoas. Rever todo o pessoal que eu já conhecia também foi muito legal.

Já estou no aguardo para o evento do ano que vem! :)

Acompanhe o relato de outros blogueiros sobre o evento.

Hoje, achei um desses scripts e finalmente fiz a migração. Depois escrevo um post detalhando o processo.

Este blog agora roda a última versão do Wordpress, mas ainda falta algumas coisinhas, como instalar um plugin decente pra Code Highlight, e alguns ajustes no layout. Caso você encontre algum probleminha (link quebrado, arquivo faltando, etc) entre em contato. :)

Porquê migrar do Mephisto para o Wordpress?

Bom, os motivos vão desde o número de plugins disponíveis para o Wordpress, até algumas features mais interessantes do Wordpress, mas o principal deles é a falta de desenvolvimento do Mephisto nos últimos tempos, como pode ser conferido no repositório do Mephisto no GitHub.

Update: Aqui estão os slides da palestra: Git: Controle de Versões do jeito certo

Um dos problemas que eu tinha era quando precisava usar o ruby-debug. Cheguei até a perguntar no IRC, mas ninguém sabia me dar uma resposta de como usá-lo em conjunto com o Passenger. Na época, resolvi usar o Mongrel para fazer o debugging e nem me preocupei mais.

Hoje, precisei de novo. E não queria usar o Mongrel. Então, fui novamente atrás de uma solução. Vamos à ela:

No arquivo: config/environments/development.rb coloque o seguinte código:

# Load ruby-debug
require "ruby-debug"
Debugger.start_remote

Este código ativa o modo remoto do ruby-debug.

Agora, vamos reiniciar o passenger:

$ touch tmp/restart.txt

Agora, vamos conectar remotamente ao ruby-debug através do terminal:

$ rdebug -c
Connected.

Pronto! Sempre que quiser depurar algum erro em sua aplicação, coloque a palavra chave debugger e espere o rdebug. Só não se esqueça dos testes para não depender tanto de debugging. :)

Neste artigo vou ensinar como instalá-los.

Instalando as dependências

Primeiro, vamos instalar as dependências do Merb, via RubyGems:

sudo gem install rack mongrel json erubis mime-types rspec hpricot mocha rubigen haml markaby mailfactory ruby2ruby

Agora, uma dependência do DataMapper, que só se encontra no GitHub:

git clone git://github.com/sam/extlib.git
cd extlib
rake install
cd ..

Você precisará do Git instalado. Caso não tenha, acompanhe este meu screencast, que ensina como compilar o Git à partir do fonte.

Instalando o Merb

Vamos clonar o repositório usando o GitHub:

git clone git://github.com/wycats/merb-core.git
git clone git://github.com/wycats/merb-plugins.git
git clone git://github.com/wycats/merb-more.git

Agora, vamos instalar, através do rake:

cd merb-core
rake install
cd ..
cd merb-more
rake install
cd ..
cd merb-plugins
rake install
cd ..

Instalando o DataMapper

Clonando o repositório:

git clone git://github.com/sam/do.git
git clone git://github.com/sam/dm-core.git
git clone git://github.com/sam/dm-more.git

Instalando o DataObjects:

cd do
cd data_objects
rake install
cd ..
cd do_mysql
rake install

Repita o último processo caso queira instalar os adaptadores para Sqlite3 (do_sqlite3) e PostgreSQL (do_postgres).

Agora, o DataMapper:

cd dm-core
rake install
cd ..
cd dm-more
rake install
cd ..

É isso! Agora, comecem a “brincar” com o Merb você também! :)

Não deixe de conferir (e assistir) as outras palestras que vão rolar esse ano, todas com excelentes temas para desenvolvedores web!

Quanto aos screencasts, não esqueci deles não, falta o áudio, mas acontece que eu coloquei aparelho ortodôntico esse mês e falta me acostumar a falar melhor com eles. :)

Ah, Nando, valeu pela idéia do nome da palestra! ;)

Update: Aqui estão os slides da palestra: Git: Controle de Versões do jeito certo

É uma das features mais interessantes do Git. E até hoje, eu nunca tinha usado o bisect. Mas o que ele faz? De acordo com o próprio site: “Find the change that introduced a bug by binary search”. Interessante, não?

Como funciona?

O bisect ajuda a encontrar quando um bug foi introduzido no seu código, marcando pontos nos commits como ‘bons’ e ‘ruins’, e examinando commits intermediários usando um algoritmo de busca binária que vai eliminando metade dos commits cada vez que você marca um commit como ‘bom’ ou ‘ruim’.

Exemplo

Suponha que tenhamos um projeto com o seguinte log:

commit 7dd0f15d4e9a5fc1f625c0ac6e4788de45e0c40f
Author: Homer Simpson <homer@simpsons.com>
Date:   Wed May 21 17:36:27 2008 -0300

    Commit 20

commit dc358142a0deb6e1ba8e15f55f5e851e7bcc1ecf
Author: Homer Simpson <homer@simpsons.com>
Date:   Wed May 21 16:50:44 2008 -0300

    Commit 19

commit 648160ea61e194f97c8e11a35866025dca46c9a4
Author: Homer Simpson <homer@simpsons.com>
Date:   Wed May 21 16:34:38 2008 -0300

    Commit 18

commit 786a02663af9aa8eed533ab574b79294eddff4fc
Author: Homer Simpson <homer@simpsons.com>
Date:   Wed May 21 16:34:22 2008 -0300

    Commit 17

commit 9b76092b44f714d780a45e99532593da7b744801
Author: Homer Simpson <homer@simpsons.com>
Date:   Wed May 21 16:14:08 2008 -0300

    Commit 16

commit a00ef3d4e836af6777350a5f157132a255804e67
Author: Homer Simpson <homer@simpsons.com>
Date:   Wed May 21 11:33:45 2008 -0300

    Commit 15

commit 526be2a6b652df597e4d5b7670d58e7f0767e2e3
Author: Bart Simpson <bart@simpsons.com>
Date:   Wed May 21 11:30:50 2008 -0300

    Commit 14

commit 67022233899f78aee7f120337f1ec434d238f23f
Author: Homer Simpson <homer@simpsons.com>
Date:   Wed May 21 11:30:31 2008 -0300

    Commit 13

commit 21b8739f2ff271baa492d358e426ea1fc87bb7d7
Merge: ecc25a6... 00560d4...
Author: Homer Simpson <homer@simpsons.com>
Date:   Tue May 20 19:32:29 2008 -0300

    Commit 12

commit 00560d4b5ff1a2d463bfa19ba3d6346566db8e12
Author: Homer Simpson <homer@simpsons.com>
Date:   Tue May 20 17:11:56 2008 -0300

    Commit 11

Nós temos uma funcionalidade que funcionava no Commit 11, mas que no Commit 20 não funciona, porém, não sabemos em que momento este bug foi introduzido. Mentira, eu sei que foi o Bart quem introduziu o bug no Commit 14, mas vamos supor que nós não sabemos disso ainda! :)

E agora, o Git poderá nos socorrer?

Aqui é que entra o bisect.

$ git bisect start
$ git bisect bad
$ git bisect good 00560d4b5ff1a2d463bfa19ba3d6346566db8e12
Bisecting: 4 revisions left to test after this
[a00ef3d4e836af6777350a5f157132a255804e67] Commit 15

Nós dizemos ao git que o commit atual é ‘bad’. E que o Commit 11 estava ok (passando o hash identificador do Commit 11). Sendo assim, o Git escolhe um ponto intermediário entre os 2 commits, resultando no Commit 15.

Nós testamos o sistema, e vimos que o bug já estava presente nesta versão, assim, ou ele foi introduzido neste commit ou antes dele. Se o bug não estivesse presente nesta versão, significa que ele foi introduzido depois. De qualquer maneira, eliminaremos a necessidade de checar metade dos commits.

Vamos dizer ao git que esta versão é ‘bad’:

$ git bisect bad
Bisecting: 2 revisions left to test after this
[21b8739f2ff271baa492d358e426ea1fc87bb7d7] Commit 12
$

O Git nos leva até o Commit 12, nós analisamos novamente e o bug não estava presente nesta versão, então, podemos dizer que esta versão é ‘good’.

$ git bisect good
Bisecting: 1 revisions left to test after this
[526be2a6b652df597e4d5b7670d58e7f0767e2e3] Commit 14
$

Voltamos ao processo novamente e descobrimos que esta versão estava ‘bugada’.

$ git bisect bad
Bisecting: 0 revisions left to test after this
[67022233899f78aee7f120337f1ec434d238f23f] Commit 13

Agora, se esta versão estiver ok, o bug foi introduzido no Commit 14, visto que já dissemos que os commits 12 e 15 estavam ok. Testamos, e esta versão encontra-se ok.

$ git bisect good
526be2a6b652df597e4d5b7670d58e7f0767e2e3 is first bad commit
commit 526be2a6b652df597e4d5b7670d58e7f0767e2e3
Author: Bart Simpson <bart@simpsons.com>
Date:   Wed May 21 11:30:50 2008 -0300

    Commit 14

:040000 040000 58adb210b90786fb300ae1d0f3b478adbe643fb0 4adb482917754cb560e3f0f586c4a0739ebab373 M    file.rb

Sendo assim, o Git nos informa que o Commit 14 é o primeiro ‘bad’ commit e que o bug foi introduzido ali. Após ter encontrado o bug, rodamos:

$ git bisect reset

E agora, podemos corrigir o bug. E reclamar com o Bart que foi quem introduziu ele! :)

Neste caso, era um intervalo de apenas 10 commits, mas se fosse um intervalo maior, o bisect também ajudaria, visto que ele usa um algoritmo de busca binária.

É ou não é, sensacional? :)