Então nós temos o HTTP a muito tempo e algumas coisas que foram revistas na versão 1.1 (RFC 2616) do protocolo só estão estão sendo implementadas para valer agora.

Uma parte importante do REST é a preocupação com o uso e implementação de alguns metodos HTTP esquecidos até agora.

Outra nova preocupação é sobre as implementações de cache do protocolo.
O protocolo HTTP vem com várias especificações sobre como cache pode ser feito nessa camada, porém, até agora foi uma parte esquecida tanto nas aplicações como nos clientes de HTTP.

Como várias aplicações (não pense somente em navegadores, mas também Web Services) começaram a seguir essas especificações para fazer cache local, era lógico que viriam implementações para os servidores que utilizamos hoje em dia.

Eu não sei você, mas eu já estou com Nginx + Rack a muito tempo. Rack é uma interface entre o servidor HTTP e o framework Ruby. No meu caso o framework é o Merb e o servidor é o Thin. O Nginx só dá uma de proxy reverso. E é ai que entra um grande potencial para ele. Com alguns cabeçalhos HTTP sendo trocados corretamente o Nginx consegue funcionar como servidor de cache facilmente.

Rack::Cache é um adapter para Rack (que servidores como Thin e Ebb usam e frameworks como Merb e Sinatra também). Além de usar corretamente os cabeçalhos HTTP sobre cache, o Rack::Cache age como um mecanismo de caching completo e totalmente fora da aplicação. Permitinde inclusive que o armazenamento seja feito no Memcached.

Por enquanto é necessário a inclusão manual do código na aplicação que está executando o Rack. Em breve espero que os próprios servidores ou frameworks incorporem as funcionalidades dessa gem Ruby.

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?

* 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”…

(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!