O RS on Rails desse ano foi um sucesso absoluto. Auditório com ótima ocupação, palestras inspiradas e lightning talks interessantes marcaram esta segunda edição do evento.
Deixo aqui meus agradecimentos aos organizadores e ao público presente. Abaixo, segue minha apresentação sobre aplicações Rack.
Andei extremamente relapso em relação a este blog, e esse post é um pedido de desculpa aos leitores.
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.
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.
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. :-)
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…
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!!
Se você quer entender rapidamente o que é um Middleware, pense em um filtro. Algo que permite que todas as requisições e respostas passem por ele, permitindo assim, que ele altere-as como bem entender. Middlewares devem possuir o mesmo método call de qualquer outro objeto Rack, porém em seu construtor, eles devem receber outra aplicação como argumento. Esta é uma maneira simples de empilhar diversas aplicações. Se você vem de outras linguagens como Java ou C# e já leu sobre Design Patterns, deve estar reconhecendo o padrão Decorator. A idéia é semelhante, mas com Ruby as coisas se tornam muito mais simples.
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:
Continuando nossa saga iniciada no post anterior, voltaremos ao exemplo do HelloWorld para entendermos mais profundamente a estrutura de um objeto Rack. Como mencionado anteriormente, um este objeto deve possuir (na verdade responder a) um método call(env), retornando em sua resposta um array com 3 elementos. Veremos mais profundamente cada um desses elementos.
class HelloWorld
def call(env)
[200, {"Content-Type" => "text/html"}, "Hello World"]
end
end
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:
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. ;-)
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.
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.
É 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:
Este é o primeiro de uma série de posts dedicado ao Rack. No início, Rack me parecia muito obscuro e estes posts serão criados com o intuito de clarear as idéias de quem ainda possui dificuldade para entender este pequeno framework.
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.
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.
Read more…
Uma das coisas que mais me confundiu a cabeça quando comecei a aprender Ruby foram os loops. Vindo de Java e C, não me entrava na cabeça como uma coisa simples como um loop poderia ser escrito de tantas maneiras diferentes. Isso simplesmente não parecia certo pra mim. Passado um bom tempo, comecei a compreender essa liberdade dada ao programador e a creditar isso ao poder e dinamicidade do Ruby.
Por curiosidade, resolvi tentar descobri todas as maneiras possíveis de se executar um loop com Ruby, e tentarei lista-las aqui.
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
Quando eu fiz um post descrevendo a extensão da API do Delicious feita com scraping, um dos riscos que eu citei era de o site mudar sua estrutura, fazendo com que os scripts de scraping quebrassem.
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
Um dos motivos que me fizeram ficar distante do blog por uns tempos foi o meu mestrado, cujo semestre acabou essa semana. E como estou trabahando direto com Java atualmente, tive que usar a imaginação para continuar praticando meus conhecimentos em Ruby. Para quem não sabe, estou fazendo mestrado em Sistemas Interativos de Visualização, com muitas cadeiras ligadas a Computação Gráfica, Animação e Visualização de Dados. Em muito dos trabalhos, utilizei uma das minha ferramentas favoritas, o Processing, mais precisamente sua alternativa rubista: o ruby-processing.
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
.
.
O Ozéias Sant’ana posto no blog dele:
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. ;-)
Depois de muitos dias ausente, volto para postar um pequeno relato sobre o lado Rubista do décimo Fórum Internacional do Sofware Livre em Porto Alegre. Apesar da correria que permeia esses meus últimos meses, devido ao trabalho e ao mestrado, consegui acompanhar (quase) todas a palestras de Ruby do Fórum, pois trabalho a poucos metros de onde o evento ocorreu.
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.