Nos dias 15 e 16 de Outubro acontece em São Paulo o Rails Summit Latin America.

O evento terá a presença de mágicos da comunidade Ruby como Dr. Nic, monstros como Chad Fowler, Chris Wanstrath (GitHub), Charles Nutter (jRuby) e a dupla Phusion (Ninh Bui e Hongli Lai). Estão também agendadas palestras de nomes da comunidade nacional: Manoel Lemos (BlogBlogs), Vinícius Manhães Teles (Improve it), George Guimarães (Pagestacker), Fabio Akita (LocaWeb) e outros que espero conhecer o trabalho assistindo as palestras.

O valor será R$300,00 se você comprar antes de 09/09/2008 e R$400,00 após 10/09/2008. Na minha opinião, um preço bem abaixo do valor real do evento.

A programação completa e a inscrição pode ser acessada aqui.

Obs: A quantidade absurda de links foi proposital. Se você está interessado em estudar Ruby/Rails, siga os caras!

Ok, eu não sou um jedi em Ruby ainda, mas lendo o Ruby Cookbook pretendo me tornar um. O comportamento que você vai perceber nas telas eu aprendi lá!

Wow - nós estamos deletando mais código do que estamos mantendo!

Yeah, claro que estamos. Você não faz isso sempre?

As duas imagens abaixo foram adaptadas da apresentação Rails Taking the Red Pill que o Demetrius Nunes fez lá no Rio on Rails. Ela demonstra no código o paradigma “Convenção sobre Configuração” adotado pelo Rails.

Tentar a perfeição na primeira implementação é uma forma de especulação. É extremamente difícil julgar a clareza de algo que você não pode ler, ou a performance de algo que você não pode executar.

Quanto mais fácil de refatorar, ou reescrever (uma forma de refatorar), melhor. Essa é uma das razões de eu ser a favor de linguagens densas.

As citações são traduções de trechos do artigo Wearing Out My Delete Key de James Golick, leia!

O pirado que desenvolveu o Thin web server, Marc-André Cournoyer também criou seu próprio framework: Invisible, que é bem parecido com o Sinatra (um outro mini-framework Ruby).

Seguindo a linha do Sinatra, ele é um pequeno suporte para fazer a ligação entre a aplicação e o web server, deixando toda a escolha de “como organizar a estrutura da aplicação”, “que ORM usar” ou até mesmo “usar ORM?” para o desenvolvedor.

Vale a pena dar uma olhada nessa aplicação exemplo e guarda-lo no seu Pagestacker, quem sabe um dia não surge um projetinho que encaixa com a estrutura desse frame, huh?

A época de ouro do Apache parece ter acabado há algum tempo. Após muitos anos sendo o servidor de aplicações para Web mais usado (na realidade ainda sendo o mais usado), o market-share do Apache está em queda há algum tempo segundo o Netcraft.

Mas eu não vim aqui para enterrar o coitado do Apache, provavelmente já fizeram muito disso por aí… sem necessidade na minha opinião. Muitos problemas ainda podem ser resolvidos com ele, sem contar que é muita falta de consideração jogar pedra em quem te alimentou por todo esse tempo (mais de 10 anos) não é?

Estou aqui para falar das entrelinhas no levantamento de Junho da Netcraft. Mais precisamente quando eles expõem o seguinte: “nginx mais que dobrou em números; com um ganho de mais de 1 milhão de sites”.

Nginx

Nginx para quem não sabe é um servidor web escrito pelo russo Igor Sysoev que também pode ser usado como proxy reverso ou e-mail proxy (fique ligado no RSS para receber atualizações sobre proxy reverso).

Dentre as vantagens do engine X (pronúncia de nginx) estão:

• estável
• configuração simplificada
• baixo consumo de recursos

Baixo consumo de memoria pode à primeira vista significar performance, mas nginx vai além, sendo desenvolvido para solucionar um grande problema de escalabilidade. Para isso possui um modelo de IO assíncrono e o já citado baixo consumo de memória que retornam além de performance, escalabilidade.

Trust Me / Thin

Há algum tempo atrás quando os widgets da boo-box foram para o ar eu não fazia idéia do poder do nginx. Sendo mais sincero do que deveria: ele só estava sendo usado pois era a opção que eu e o Maurício conhecíamos para colocar o nosso Merb no ar.

Logo no começo ele era um load balancer para um par de Mongrel em esquema Round-Robin, mas tão logo as requisições começaram a aumentar algo precisou ser feito.

Ezra Zygmuntowicz da EngineYard já havia enfrentado um problema com o modelo Round-Robin usado pela versão estável do nginx, então criou um patch para resolver isso com Fair queuing (ou quase isso).

A solução de Ezra foi de grande ajuda, pois o ponto mais díficil de escalar na aplicação que usei de exemplo é a ocorrencia de muitas requisições longas que ficam aguardando retorno de outras APIs, tornando Round-Robin impossível uma vez que algumas requisições poderiam cair em uma instância ocupada. Round-Robin não se importa se a instância está ocupada ou não e manda a requisição para fila da mesma forma e Fair resolve isso enviando requisições somente para instâncias desocupadas. Ponto para o nginx e sua crescente comunidade.

Mas outro problema é que uma vez que mais e mais requisições lentas vão entrando no sistema as instâncias ativas de Mongrel tendem a acabar. A solução poderia ser adicionar mais e mais instâncias até acabar com a memória ou com sobrecarregar a interface TCP/IP, uma vez que Mongrel não consegue trabalhar com Unix Sockets.

A solução então está sendo trabalhar com Thin, um ótimo webserver Ruby. Thin é uma solução alternativa ao Mongrel que merece um artigo dedicado, então o que posso dizer dele por enquanto é que suporta Unix Sockets (isso é bom) e tem um custo baixo de memória, possibilitando rodar várias instâncias diminuindo o desperdício de recursos.

Não estou muito certo quanto a possibilidade de se rodar qualquer aplicação Rails nele, mas de uma coisa eu sei: Merb + Thin + Nginx estão me deixando dormir tranquilamente. Se você ainda não conhece essas excelentes ferramentas do mundo Ruby acredite em mim, conheça.

Ps: nginx não é exclusivo do ambiente Ruby, ele é um proxy reverso que pode trabalhar com outras linguagens como PHP.

Ps 2: Phusion Passenger parece ser uma ótima opção para rodar Rails, mas mesmo suportando Rack não estou certo (fico devendo o benchmark) se haveria ganho para rodar Merb.

Ontem o desenvolvedor do Thin, Marc-André Cournoyer, lançou o que parece ser um release candidate para a primeira versão estável do seu servidor de aplicações Ruby.

Batizada de “Double Margarita” a versão 0.8.2 não vem com muitas funcionalidades novas mas corrige todos problemas graves das versões anteriores.

Para quem não sabe do que se trata, Thin é um web server Ruby que utiliza o que há de melhor para processamento HTTP no mundo Ruby:

• O Parser do Mongrel, de onde vem toda a velocidade e segurança do Mongrel
• Event Machine, uma biblioteca de network I/O com foco em escalabilidade, performance e estabilidade.
• Rack, a interface (API) entre web servers e frameworks Ruby

Essas características dão ao Thin o posto de “mais rápido que Mongrel com menos memoria que Mongrel”

Veja o artigo que compara Thin e Mongrel de onde reproduzi os gráficos

Porém ainda vejo outra vantagem além da performance atual que é a possibilidade de Thin rodar em Ruby 1.9 desde sua versão 0.5.1, permitindo aos desenvolvedores do “ambiente Thin” (leia-se Merb) desenvolverem suas bibliotecas compatíveis com o YARV (a famosa maquina virtual por trás da performance do próximo Ruby estável). Coisa que Mongrel e o “ecossistema” em volta dele ainda não permite.

Para saber mais:
Página Oficial
Como começar (em ingles)

* Esse artigo é baseado em Sinatra Tutorial. A good starting point por Ari Lerner. Você pode encontrar outras informações no RubyForge (Sinatra)

Sinatra é um framework para linguagem Ruby extremamente leve. Ele roda tendo como base o servidor Mongrel, servindo com muita rapidez as requisições.

Por não ter a extensa biblioteca de “helpers” que o Rails tem e também por não seguir a linha MVC de Rails e Merb, o seu uso não é indicado em grandes aplicações.

Com foco em Web Services e pequenos aplicativos, Sinatra é uma ótima solução para rodar pequenas aplicações desenvolvidas em Ruby com muita eficiência.

O propósito do artigo é ser um guia de inicio para quem quer aprender mais sobre o framework, para isso vamos desenvolver um pequeno “own-microblog”…

Leia mais »

Update:

Por servir muitas imagens para diversos sites, a aplicação se tornou muito pesada. Uma solução simples seria desviar a rota dos arquivos estáticos para serem servidos diretamente pelo Apache (sem passar pelo framework Sinatra). Mas devido a minha falta de tempo (preguiça) preferi desativar o serviço.

Você está cansado de ficar triste por seu Feedburner Count nunca passar de 10 leitores? Se sua mãe lê-se RSS seus problemas estariam resolvidos (lógico que ela iria assinar e obrigar as amigas dela a assinar também).

Como provavelmente isso não vai ocorrer eu tenho outra solução para você: FEEDDOIDO.COM. O Feeddoido é uma idéia do Newton Calegari que serviu de pretexto para eu perder um tempinho aprendendo novas tecnologias (jquery, imagemagick com ruby).

Com o feeddoido você escolhe o número de leitores que deseja ter para seu blog, ou melhor, número de leitores que você deseja mostrar. Não entendeu? Entre no site e brinque com a ferramenta - feeddoido.com.

Só pra avisar: papo geek. Se você não tem vocação pra bixo programador ou Capitão de Projeto, recomendo outras leituras. Mas se você curte, então coloque a porra da bandoleira no notebook, porra!

É indiscutível o ganho de produtividade trazido por frameworks no desenvolvimento de qualquer aplicação, seja desktop ou web. Muito do sucesso no uso de algumas linguagens para aplicações de grande porte na verdade vem dos frameworks disponíveis. É assim com Java, com VB/C# (.NET), com Python (Django) e principalmente com Ruby (Ruby On Rails).

Muitas pessoas na verdade não tem conhecimento que o mais importante no Ruby on Rails não é toda sua estrutura de métodos e facilidades para fazer uma simples aplicação CRUD de forma organizada. O mais importante do Rails na verdade é a linguagem em que ele se baseia.

O que torna Rails atraente é a elegância do Ruby, sua sintaxe intuitiva, métodos com nomes “humanos” e a facilidade de manipular coleções de objetos.

Porém como Ruby on Rails na verdade é a porta de entrada de muita gente para o mundo Ruby, a farandula de programadores acaba só tendo olhos para ele, o framework Rails. O pessoal acaba querendo usar a mesma porcaria de martelo pra pregos diferentes. O Akita fala bastante disso, do povo que acha que pode usar Java pra fazer café e desentupir a pia…

Pra você entender melhor o que quero dizer, vou transformar frameworks em carros, ok?

Vamos pensar que nosso querido Ruby on Rails é uma F350. Você viu a foto, ela é luxuosa e bonita. Provavelmente consegue carregar muitos objetos em suas devidas classes, ou seja, tudo bem organizado. Legal, mas reparem na foto: ela é gigante e parece muito pesada!

Você sabe o que acontece com coisas pesadas! Elas demoram a acelerar.

Se você quer apenas dar uma volta na cidade não é a melhor coisa tirar a F350 da garagem. Imagine, todos aqueles sinais e você precisando fazer um monte de barulho pra poder sair junto com um simples Palio 1.8!

Para uma simples voltinha na cidade ou até mesmo uma viagem sem muita carga, existem excelentes outros carros. Não tente fazer igual eu já fiz: usar Rails pra um ou dois controllers igual nessa lista de tuitadas do Intercon.

Use tipo uma BMW (Merb, MVC-ActiveRecord igual o Rails mas BEM mais leve) ou talvez um chevetinho com motor de BMW (Sinatra, NÂO MVC então útil quando não precisar de base de dados).

Ainda tem os Audis da vida por ai (Camping), mas o importante não é simplesmente pegar um desses e sair usando eles pra tudo. O importante é conhecer varias soluções para saber ao certo qual encaixa melhor no problema!

É essa a moral da história, do post ou da vida: não se apegue em uma só solução!

Não custa repetir: veja o Merb, veja o Sinatra! É legal pra caçalho!

Aproveitando o mesmo post (assim não encho muito seu RSS Reader), gostaria de agradecer o Newton Calegari pela indicação no Meme que não entendi o propósito, mas mesmo assim eu passo a bola e indico o Thiago - Pe Vermelho. É isso!

[update 01/10 - 6:35] Duh! Foi o que falei quando vi esse link. Uma lista com realmente todas postagens do Intercon no Twitter. Também né fí, Google! Ai ganha em quantidade, mas a minha lista continuar sendo listada pela ordem cronológica das postagens.[/update]

Se você só quer ver a lista, não perca tempo:
Lista de tuitadas do Intercon 2007

(para evitar broncas, não adicionei ninguém. se você quiser ver seus updates, deixa lá seu nick)

Se você quiser saber um pouco mais sobre a breve história dela, enjoy!

Ontem cedo eu soltei uma lista de “tuitadas” que gerei com um web scraper. Mas de automática aquela lista só tinha a parte de entrar em profiles pré-determinados e procurar postagens com #intercon. Assim eu teria que ficar adicionando a galera que pedisse, gerar uma lista local e subir por FTP, como disseram: W3T demais!

Já que eu odeio ir pra faculdade adoro estudar por contra própria, decidi brincar e fazer algo mais decente.

Essa nova lista permite que você envie seu twitter-name (com ou sem @) e então a aplicação vai atrás de scrapear, jogar em um mysql (updates e nick), limpar cache e exibir listagem atualizada.

Terreno ruim pra quem não estava muito familiarizado com debugar Rails. Quase tudo na aplicação dava erro e por isso ficou difícil acha-los. Talvez seja útil falar os problemas que tive: Instalar gems na DreamHost, Timeout do FastCGI e Impossibilidade de definir Timeout no Scrubyt.

A questão dos gems foi a que tomou mais tempo, não por ser complicada mas pela minha inexperiência em entender de onde surgia os erros. Fica uma dica: Se você criou a aplicação na DreamHost (rails app) e só depois instalou seus próprios ruby, rails e gems, delete e re-crie a estrutura de pastas do Rails (rails app). Isso porque alguns arquivos (dispatch.fcgi, …) vão com o local que o Ruby está quando você os cria (aquela primeira linha #!/usr/bin/ruby1.8)

Com a questão do Timeout eu já estava mais esperto, com um SSH aberto só pra ficar no tail do log (muitos termos geeks ehehe), a solução foi até mais complicada mas o processo de localizar mais rápido.

O Timeout do FastCGI que era provocado justamente pela falta de Timeout no Scrubyt quebrava a aplicação. O Scrubyt utiliza o Mechanize para ler as paginas da web, que possui Timeout implementado. Então fiz algumas alterações no código do Scrubyt e ele passou aceitar passagem de parâmetro para Timeout. A próxima versão já deve vim com essa minha contribuição.

Enfim, matei aula da faculdade e tive muitas horas de diversão e aprendizado com Ruby/SHH/Rails/Apache/FastCGI e XPath/DOM também, porque não? ;D

Legal!? Então comente ;D
Ruim? Então faça uma sugestão