Dica para quem usa o Nginx como web server de aplicações Rails e já apanhou para habilitar HTTP Basic Authentication ou para gerar as senhas criptografadas em MD5.

Para habilitar o auth_basic, basta adicionar dentro do bloco server do arquivo nginx.conf:

location ~ / {
        auth_basic            "Restricted";
        auth_basic_user_file  htpasswd;
        passenger_enabled on;
}

Um detalhe importante: se estiver rodando sua app com Passenger, inclua a linha passenger_enabled on;

Ah, já estava esquecendo das senhas. Elas devem ficar no arquivo htpasswd, no mesmo diretório do arquivo nginx.conf e precisam seguir o formato user:senha em cada linha. Por exemplo:

user:sd5dsjo23PwdSh
admin:mdePW2hgrPddSA

O detalhe é que a senha precisa ser criptografada em MD5. Uma maneira fácil (e que funciona) de fazer isso é executando:

ruby -e "puts 'usuario:' + 'senha'.crypt('md5')" >> htpasswd

Sucesso!

Se você ainda não trabalha com Ruby pois acha complicado demais instalá-lo, chega de desculpas! Esse tutorial for dummies ajudará a instalar o Ruby através do RVM de forma direta, sem enrolação.

Partindo de uma instalação do Ubuntu 11.04 zerada, começamos com os pré-requisitos para instalar o RVM:

user@ubuntu:~$ sudo apt-get install git-core curl

Basta confirmar a instalação dos pacotes, em seguida executar o comando (extraído do site oficial do RVM):

user@ubuntu:~$ bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)

A seguir, o output completo gerado por esse comando indicará os pacotes e libs necessários para a instalação do Ruby.

(...)

dependencies:
# For RVM
  rvm: bash curl git

# For Ruby (MRI & ree)  you should install the following OS dependencies:
  ruby: /usr/bin/apt-get install build-essential bison openssl libreadline6 libreadline6-dev curl git-core zlib1g zlib1g-dev libssl-dev libyaml-dev libsqlite3-0 libsqlite3-dev sqlite3 libxml2-dev libxslt-dev autoconf libc6-dev ncurses-dev automake

(...)

Installation of RVM to /home/user/.rvm/ is complete.

Agora, basta instalar essas libs através do apt-get:

user@ubuntu:~$ sudo apt-get install build-essential bison openssl libreadline6 libreadline6-dev curl git-core zlib1g zlib1g-dev libssl-dev libyaml-dev libsqlite3-0 libsqlite3-dev sqlite3 libxml2-dev libxslt-dev autoconf libc6-dev ncurses-dev automake

Com as dependências instaladas, abra um novo console (para re-carregar o RVM), e comece a instalar o Ruby, no caso, o MRI 1.8.7:

user@ubuntu:~$ rvm install 1.8.7

Esta operação levará alguns minutos. Quando concluída, você terá o Ruby 1.8.7 e o Rubygems 1.8.6 instalados. Para testar tudo, execute os seguintes comandos:

user@ubuntu:~$ rvm use --default 1.8.7
Using /home/user/.rvm/gems/ruby-1.8.7-p352

user@ubuntu:~$ ruby -v
ruby 1.8.7 (2011-06-30 patchlevel 352) [i686-linux]

user@ubuntu:~$ gem -v
1.8.6

Pronto! Agora você tem o Ruby e Rubygems instalados e prontos para o uso. Caso queira conferir, o output dos comandos acima está disponível neste gist.

Fique ligado no próximo post: Gemsets e Bundler. Qualquer dúvida, use os comentários.

Muito buzz se formou depois que o DHH tornou público que a versão 3.1 do Rails virá com CofeeScript por padrão.

Aproveitando a barulheira, que é comum a cada vez que o criador da plataforma abre a boca, vamos nos ater ao que é importante e apresentar uma introdução ao resumo simplificado do CoffeeScript básico.

Confesso que minha opinião sobre essa ferramenta mudou nos primeiros instantes em que comecei a usar. No site do CoffeeScript (ok se eu começar a chamar de CS daqui para frente?) existe um link onde você digita o código do lado esquerdo e, imediatamente, do lado direito aparece o equivalente em JavaScript.

Fiz uma brincadeira lá usando um código que sempre me vem à cabeça ao tentar explicar o básico de programação funcional para alguem. Segue:

mimimi = (operation, value) ->
   operation(value);

dobro = (value) ->
  value + value;

quadrado = (value) ->
  value * value;

zero = (value) ->
  value - value;

um = (value) ->
  value / value;

alert(mimimi(dobro, 3));
alert(mimimi(quadrado, 3));
alert(mimimi(zero, 3));
alert(mimimi(um, 3));

Nada de outro mundo, certo? O equivalente JS é o código abaixo:

var dobro, mimimi, quadrado, um, zero;
mimimi = function(operation, value) {
  return operation(value);
};
dobro = function(value) {
  return value + value;
};
quadrado = function(value) {
  return value * value;
};
zero = function(value) {
  return value - value;
};
um = function(value) {
  return value / value;
};
alert(mimimi(dobro, 3));
alert(mimimi(quadrado, 3));
alert(mimimi(zero, 3));
alert(mimimi(um, 3));

CS permite também a checagem automática de valores e parâmetros opcionais, conforme o exemplo retirado do site:

fill = (container, liquid = "coffee") ->
  "Filling the #{container} with #{liquid}..."

Ou o equivalente em JS:

var fill;
fill = function(container, liquid) {
  if (liquid == null) {
    liquid = "coffee";
  }
  return "Filling the " + container + " with " + liquid + "...";
};

Sem dúvida, muito mais legível e expressivo.

É uma ferramenta que eu pretendo usar em algum projeto pequeno, para testar e ver o quanto acelera meu trabalho. Em projetos maiores talvez eu demore um pouco mais para usar mas, considerando que umas das minhas aplicações já conta com 79% de código total escrito em JavaScript, segundo o GitHub, imagino que isso vai melhorar consideravelmente a manutenção do código.

E no mais, se o CS não te chamou a atenção e você não quer mesmo utilizar, basta remover o require do arquivo Gemfiles e a vida segue como se nada tivesse acontecido.

Links recomendados:

• Site do CoffeScript: http://jashkenas.github.com/coffee-script/
• Mais do mesmo: http://www.rubyinside.com/rails-3-1-adopts-coffeescript-jquery-sass-and-controversy-4669.html
• Exemplo bacana de como utilizar CS dentro da sua view: http://geekiriki.blogspot.com/2010/08/jquery-meets-coffeescript.html

Documentação é aquilo que você reclama para fazer e reclama quando não encontra.

Por Plínio “Chico Xavier” via Twitter.

Isto me fez refletir (bem rápido) sobre as possíveis causas da não-documentação:

• É muito chato ! Editar wiki, doc … é incrível como toda documentação geralmente é feita em algo não produtivo.
• Espaço e Tempo (ou seja, prazo!). Sempre é deixado por último e nunca sobra tempo pra ser feito.
• Não é levado a sério. Levanta a mão que já viu a secretária documentando “tela” de sistema …
• Normalmente o “investidor” do software não vê valor nisto, ou melhor, espera alguém pedir e repassa a tarefa com prioridade “faz rapidinho”.

Ok. Após reflexão feita, hora de atacar o problema.

Usando “guides” para criar um Guide !

Este é um resultado da experiência abaixo:

Com a gem guides, em segundos você tem um scaffold, pronto para ser preenchido.

$ gem install guides

 $ guides #mostra os comandos disponíveis

$ guides new sample

$ cd sample

$ guides build && guides preview

Pronto. Em http://localhost:9292 você terá acesso ao novo guia gerado.

Preenchendo o seu Guia

Em guides.yml (exemplo aqui), está o básico do seu Guia. Nele está o índice de “capítulos”, com resumo e nome do arquivo que o link deve seguir. Os arquivos textile  gerados/criados ficarão na pasta source, o resultado do “guides build” ficará na pasta output.

As páginas são em textile, o que facilita bastante. Mas o grande diferencial, está em alguns helpers disponibilizados pela gem, que torna muito simples criar áreas de destaque como INFO, WARNING … etc e adicionar comandos e códigos.

Para ter idéia de uma página em textile, segue o link source/getting_started.textile (raw).

Repensando a documentação

Com certeza, usando a gem guides, vocẽ consegue um boost na hora de documentar. Já evitando aquela chatice de editar wiki, .doc, controlando versão … etc. Usando textile, seu editor preferido e git, não tem mais desculpas.

Desenvolvendo Frameworks e APIs

Já faz um tempo que eu topo com a vibe Documentation Driven Development. Como tudo na vida, é questão de bom senso. Documentar uma API, nada mais é do que definir a interface dela, e dependendo do caso, isto ajuda bastante antes de começar o desenvolvimento.

Você é um Usuário !

Uma documentação com um monte de imagem e seta, descrevendo o óbvio não serve para nada (além de passar raiva). Uma documentação sucinta, com o básico, por exemplo Instalação, Modo de Usar, Configurações Disponíveis é bem melhor que muito dossiê por aí ! Tente ao máximo se colocar no lugar do usuário ao escrever alguma documentação ou ajuda.

—

Não deixe de contribuir com o post. Mande sugestões, comentários, reclamações etc.

No final do ano passado, ao ver um twitty do José Valim, fiquei tentando a comprar o livro, mas depois do post Crafting Rails Applications: Why I wrote this book, tive certeza que não perderia este presente de Natal.

Crafting Rails Applications: Expert Practices for Everyday Rails Development

Apesar de poucas páginas, o livro tem muito conteúdo. Logo no começo, em “Who should read this book ?” é avisado, não é para iniciantes. Os capítulos são separados em tópicos interessantes, abordando diferentes maneiras de extender o Rails 3.

Aliás, extender é a palavra chave do livro. Dos projetos que compõe o Rails, somente o Active Resource não foi citado. O livro com certeza pula o básico, ou seja, não espere por explicações em como usar as funcionalidades do Rails.

-

Detalhes que tornam o livro interessante.

• Enginex – é uma Ruby gem que cria um Rails 3 Engine com Rakefile, Gemfile e pronto para rodar testes em cima de uma aplicação “vendorizada”. Ou seja, no livro temos projetos reais, que são executados e tem testes !
• TDD – todo código apresentado, é feito seguindo o Test-driven Development, mostra-se o teste falhando e vai implementando aos poucos, até tudo ficar verde.
• Como melhorar o seu código – conhecendo Responders e o Renderer Stack do Rails 3, você com certeza irá ampliar o seu leque de possibilidades de como melhorar o fonte das suas aplicações. Tem bastante exemplos de Rails Generators também.
• Desmistificando Rails – o Valim realmente conseguiu de forma majestosa explicar as entranhas do Rails 3. A cada capítulo e detalhe explicado, pude ver o verdadeiro trampo que fizeram no projeto, em comparação com o 2.x, o Rails mudou muito (internamente!).

Finalizando…

Se você é um desenvolvedor que se preocupa em conhecer a fundo o framework que trabalha, compre agora! Confesso que depois da leitura, estou muito mais a vontade para navegar no fontes do Rails, inclusive passei a acompanhar os tickets no Lighthouse. Rails 3 definitivamente está mais flexível, e o José Valim conseguiu expor tudo isso com código e uma leitura agradável.

Quantas vezes você precisou buscar alguma informação externa para sua aplicação, como um número de telefone ou uma foto em algum site? A idéia é simples: criar um crawler script para fazer parse de algum conteúdo HTML. E basta apenas Ruby e Nokogiri.

Exemplo

Digamos que eu queira obter a última versão de uma dada gem consultando diretamente no site http://rubygems.org para me ajudar quando precisar instalar novas gems no meu ambiente. Vamos ao código:

#!/usr/bin/env ruby
 
require "rubygems"
require "open-uri"
require "nokogiri"
 
gem = ARGV[0]
site = open("http://rubygems.org/gems/#{gem}")
document = Nokogiri::HTML(site)
version = document.css(".title h3").text
 
puts "#{gem} version #{version}"

Vou salvar esse script no arquivo gem-version.sh, torna-lo executável com chmod +x gem-version.sh em seguida executar no terminal:

$ ./gem-version rails
  rails version 3.0.3

Pronto, agora você também pode brincar à vontade com Nokogiri no seu shell!

A API de rotas do Rails simplifica consideravelmente o desenvolvimento fornecendo um padrão de geração e utilização de URLs para toda aplicação. Porém algumas necessidades especificas e relativamente simples podem gerar dores de cabeça se forem implementadas incorretamente.

Um caso bastante comum são URLs compostas que sempre apontam para um mesmo recurso. Por exemplo, um blog que possua rotas para seus posts no formato /posts/autor/categoria/permalink provavelmente terá uma rota mapeada como map.post "posts/:author/:category/:permalink" gerando automaticamente os helpers post_path e post_url.

Muito bom, porém para usufruirmos desta facilidade precisamos fornecer os valores dos parâmetros dinâmicos nos controllers e views:

post_path(:author => @post.author, :category => @post.category, :permalink => @post.permalink)

E mesmo que você forneça os parâmetros em um array, vai dar muito trabalho além de deixar muito código repetido pela aplicação.

Entendi! Mas como resolvo este problema?

Para este caso, apenas implementar o método to_param do model não vai servir. Uma solução seria reescrever o método post_path (que é gerado automaticamente) no respectivo helper (posts_helper.rb):

def post_path(post, options = {})
  super(post, :author => post.author, :category => post.category, :permalink => post.permalink)
end

Outra solução seria sobrescrever o método default_url_options no controller para retorna os parâmetros padrões da rota:

def default_url_options(options = {})
  options.merge!(:author => @post.author, :category => @post.category, :permalink => @post.permalink) if options[:action] == "show"
end

A má notícia é que você terá que fazer isto para todos seus controllers e respectivos models.

A terceira solução (e mais elegante) é padronizar a maneira com que os parâmetros opcionais da rota são obtidos a partir do controller e seu respectivo model. Basta adicionar os seguintes métodos no seu ApplicationController:

def default_url_options(options = {})
  if (model = controller_model(options))
    dynamic_route_params(options).each do |param|
      options[param] = model.send(param) if model.respond_to?(param)
    end
  end
  options
end
 
def controller_model(options = {})
  clazz = (options[:controller].singularize.camelize.constantize rescue ActiveRecord)
  options.select { |key, value| value.is_a?(clazz) }.first.second
rescue
  nil
end 
 
def dynamic_route_params(options = {})
  returning [] do |dynamic_params|
    matched_routes = ActionController::Routing::Routes.routes.select do |route|
      route.matches_controller_and_action?(options[:controller], options[:action])
    end
    dynamic_segments = matched_routes.map(&:segments).flatten.each do |segment|
      dynamic_params << segment.key if segment.is_a?(ActionController::Routing::DynamicSegment)
    end
  end
end

Assim, os valores defaults dos parâmetros da rota serão obtidos diretamente do model. Caso queiram contribuir, este código está disponível no github.

Referências
Rails Routing from the Inside Out
Rails Guides: Routing

Qualquer um que comece a desenvolver com Active Record (AR), minha primeira recomendação é, para tudo e leia:  A Guide to Active Record Associations ou O Guia de Associações do Active Record. O guia é bem completo, e descreve muito bem os tipos de associações que estão disponíveis no AR.

Association Proxy, #wtf !

As associações:

• belongs_to
• has_one
• has_many
• has_and_belongs_to_many

Quando usadas, adicionam alguns métodos (veja Detailed Association Reference). Por exemplo, ao declarar uma associação belongs_to, o model “ganhará” os seguintes métodos:

• association(force_reload = false)
• association=(associate)
• build_association(attributes = {})
• create_association(attributes = {})

Onde association, será substituído pelo nome da associação. Exemplo retirado do guides:

class Order < ActiveRecord::Base
   belongs_to :customer
end

Cada instância de Order, conterá os métodos:

• customer
• customer=
• build_customer
• create_customer

O association proxy, é o objeto que faz a ligação do objeto que contém a associação, conhecido como owner, e o objeto associado, conhecido como target.

Legal e daí !?!

Graças ao association proxy, ao declarar uma associação, podemos extendê-la e adicionar comportamentos “customizados”. No guia, é citado como Association Extensions. O código de exemplo abaixo, está no github em random-samples.

Para exemplificar, vamos criar um modulo que adiciona o comportamento de uma galeria a qualquer coleção.

module GalleryColletion
 
  def current=(curr = nil)
    @current, @index = nil
 
    if curr.nil?
      @current = collection.first
      @index = 0
    else
      collection.each_with_index do |item, index|
        if item.id.to_i == curr.to_i
          @current = item
          @index = index
        end
      end
    end
    @current
  end
 
  def current
    @current
  end
 
  def position
    @index + 1
  end
 
  def previous?
    return false if @index.nil?
    !!(@index - 1 >= 0)
  end
  def previous
    collection[@index - 1] if previous?
  end
 
  def next?
    return false if @index.nil?
    !!(@index + 1 < collection.size)
  end
  def next
    collection[@index + 1] if next?
  end
 
  private
 
  def collection
    proxy_owner.send(proxy_reflection.name)
  end
 
end

Gallery Collection

Note que o modulo está na pasta lib, logo, a pasta tem que ser adicionada no path via config/environment.rb.

Para extender a associação, declare:

class Article < ActiveRecord::Base
  has_and_belongs_to_many :images, :extend => GalleryColletion
end

Article model, Image model aqui.

Agora para navegar entre as imagens, você pode usar:

a = Article.first
a.images.current = 1 #1 e o Image.id que deseja selecionar
a.images.current
a.images.position
a.images.next?
a.images.next
a.images.previous?
a.images.previous

Caso esteja com coragem, baixe o projeto e veja rodando.

Dúvidas, sugestões, algum “case” de sucesso, comente!

É engraçado como tudo é questão de treino e disciplina. Levei um tempo para me acostumar com TDD, Vim e não poderia ser diferente com testes funcionais, sendo mais especifico, Cucumber.

Até o momento, só tinha usado cucumber em projetos web. E quando voltei a desenvolver o rubygems_snapshot, senti falta de algo para testar funcionalmente. Baseado no pik, montei um esquema simples para validar qualquer aplicação de linha de comando.

Como instalar

Basicamente, será necessário (fontes via gist):

• rake para executar o cucumber
• env_terminal.rb
• terminal_steps.rb

Dado que você tem cucumber instalado, com o esquema da pasta “features”.

• Copie o cucumber.rake para a raiz.
• Copie o env_terminal.rb para a pasta features.
• Copie o terminal_steps.rb para a pasta features/step_definitions/terminal_steps.rb.
• Edite o  env.rb incluindo (pode ser no começo):

require "env_terminal"

• Dentro do Rakefile, pode ser no final mesmo, adicione:

load "cucumber.rake"

Como usar

Todas features:

rake cucumber

Features com a tag @wip, também conhecida como Work in Progress.

rake cucumber:wip

Informações Extras

Caso precise de mais informações, você tem a opção de ver a saída dos comandos, executando a rake assim:

rake cucumber show_output=true

ou

rake cucumber:wip show_output=true

No caso do snapshot, tive a necessidade de “modificar” o comando gem toda vez que era executado, ou melhor, passar um parâmetro para controlar o ambiente. Dentro do env_terminal.rb, existe o método gsub_command, nele você pode “redefinir” comandos, caso necessite.

Gostei, quero mais!

A solução acima, é bem “caseira”. Para projetos simples com funcionalidades simples, funciona bem.

Caso queira algo mais robusto, você tem a opção da gem Aruba.

Tem este post como introdução:

Aruba – Cucumber Goodness for the Command-Line

Nova versão do Rubygems_Snapshot no ar!

Fico feliz em dizer que este é o meu primeiro projeto que passou dos dez “watchers” ! E que realmente ajudou alguns developers mundo afora.

A primeira versão foi muito focada no uso pessoal, como “quebra-galho” mesmo. Resolvi investir algum tempo e praticamente refaze-lá, pois ao usar no dia-a-dia percebi algumas falhas e dificuldades de uso.

Basicamente, nesta nova versão:

- É possível trabalhar com mais de um formato. Yml e Tar, que é o padrão.

- Ao exportar, os arquivos “.gem” serão exportados.

- Ao importar, ocorre praticamente uma instalação “offlline”, muito mais rápido e livre de problemas com “sources” do rubygem !

- Usar o Snapshot como API !

Como tive um trabalhão para deixar o Readme legal, não pretendo escrever mais que isso!

Marcos, valeu pelo incentivo! Cara, forka lá e manda bala!