Desta forma, se utilizarmos o ActiveSupport::Memoizable iremos receber o seguinte warning:

ActiveSupport::Memoizable is deprecated and will be removed in future releases,simply use Ruby instead

O que significa “simply use Ruby instead” ?

Podemos transformar isso:

class MyClass
  extend ActiveSupport::Memoizable
 
  def method
     @result = #some code
  end
 
  memoize :method
end

Nisso:

class MyClass
  def method
   @result ||= begin
     #some code
    end
  end
end

Durante o processo de autenticação, existe uma etapa em que o usuário é redirecionado para o serviço da estratégia(Facebook por exemplo) e neste momento a nossa aplicação registrada no serviço irá solicitar a autorização do usuário. Esta autorização varia de serviço para serviço, mas no caso do Facebook por exemplo, poderia ser pedido as informações básicas do usuário, como nome, e-mail etc, ou permissões extendidas, como por exemplo a possibilidade de postar no mural do usuário.

Para maiores detalhes sobre como implementar todo o processo de autenticação com o Omniauth sugiro que visite este link https://github.com/intridea/omniauth/wiki

Para este tutorial, a parte mais importante é a configuração.

Um exemplo padrão seria:

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :facebook, ENV['FACEBOOK_KEY'], ENV['FACEBOOK_SECRET'], 
                :scope => 'email,publish_stream,read_stream'
end

Perceba que no :scope estamos listando os tipos de permissões que iremos pedir ao usuário.
No caso do Facebook, se esta lista estivesse vazia, por padrão iria ser pedido apenas as informações básicas do usuário.

Para o cenário de autenticações, é recomendado pedir sempre o mínimo possível. Se não precisamos de nenhuma permissão de escrita para a autenticação, não faz sentido pedi-la.

O problema é que se em outro ponto de nossa aplicação necessitarmos a permissão de escrita, teremos que setar em nossa configuração inicial, e neste caso o usuário deverá aceitar o publish_stream(escrita) para fazer apenas a autenticação.

A solução para isso é pedir as permissões(scopes) dinamicamente.
Para isso basta fazer a configuração da seguinte forma:

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :facebook, ENV['FACEBOOK_KEY'], ENV['FACEBOOK_SECRET'], 
              :scope => 'email,publish_stream,read_stream',
              :setup => lambda {|env| env['omniauth.strategy'].options[:scope] = env['rack.session']['facebook_scopes'] }
end

Adicionando o parâmetro setup conseguimos definir quais scopes desejamos usar dinamicamente. Neste caso estamos recuperando a lista de scopes da sessão, com a chave ‘facebook_scopes’

Desta forma, basta setar a lista de scopes dentro de um controller, e em seguida redirecionarmos o usuário para a URL de redirecionamento para o serviço. Normalmente esta URL segue o padrão /auth/provider. No caso do Facebook seria /auth/facebook

Esta URL irá redirecionar o usuário para o Facebook onde deverá aceitar ou não as permissões que serão pedidas.

Veja o exemplo de um controller:

class HomeController < ApplicationController
 
  def index
    session[:facebook_scopes] = "email, publish_stream"
  end
 
end

A escolha foi difícil pois implicaria em muitas mudanças. Entre as mais difíceis eram: deixar grandes amigos, deixar a empresa que ajudei a fundar e ainda “enfrentar” um mundo desconhecido até então. O mundo das Consultorias.

2011 – Fase 1

Tive a sorte de conhecer grandes pessoas, e mesmo correndo o risco de não lembrar de algumas, não posso deixar de citar alguns nomes. O primeiro, Diego Carrion(@dcrec1) que no início de Janeiro de 2011 abriu uma grande porta em minha carreira me convidando para trabalhar no time de Rails da Gonow Tecnologia.

A minha meta para 2011 era muito simples: Aprender o máximo que eu puder. E a melhor maneira de conseguir isso, seria trabalhando com pessoas tecnicamente melhores do que eu. Felizmente eu tive esta oportunidade.

Atuando como consultor tive a oportunidade de passar por vários projetos em empresas grandes de pequenas. Participei de vários projetos. “Coloquei a mão” em muitos códigos diferentes. Escrevi código ruim e tive a felicidade de receber críticas construtivas nos comentários do Github. Desenvolvi uma certa habilidade de “pegar o projeto andando” e ter que me virar. Enfim, aprendi muito mais do que achava que poderia aprender.

Para fechar a fase 1, uma outra pessoa que gostaria de citar é o Ricardo Almeida(@almeidaricardo) que me deu uma grande força no primeiro projeto que participei.

2011 – Fase 2

Dizem por ai que a única constante é a mudança. Concordo com isso, e por este motivo chego na fase 2. Mantendo o foco na minha principal meta para 2011 decidi que seria mais interessante para minha carreira me dedicar ainda mais em Ruby e trabalhar em alguns projetos diferentes. Desta forma aceitei o convite para trabalhar na Codeminer42 e aproveito para agradecer ao Fábio Akita(@akitaonrails) pela confiança.
Continuo tendo a sorte de trabalhar com excelentes pessoas e excelentes projetos. Se continuarmos com o mesmo foco que tivemos nos últimos 3 meses, 2012 será ainda melhor!

Com isso fecho o ano com a certeza de que aprendi muito e ainda não sei nada, e isso é o que mais me motiva para tentar fazer o próximo ano ainda melhor.

Trabalhando em consultorias, tenho a oportunidade de “colocar a mão” em muitos projetos. Em grande parte deles, o código escrito parecia ter sido obrigado a se “encaixar” em um dos 3 diretórios citados acima.

A questão é: nem tudo na sua aplicação é um model, um controller ou uma view. Logo não faz sentido inserir seu código lá.

Na aplicação que trabalho atualmente tenho a seguinte estrutura dentro do diretório app:

• adapters
• assets
• controllers
• helpers
• mailers
• models
• observers
• presenters
• uploaders
• validators
• views
• workers

Não tenha receio de acrescentar outros diretórios em sua aplicacão achando que você está saindo do padrão. A nova onda na comunidade é falar sobre SOLID e seguindo alguns destes princípios ajudará na organização.

Uma outra prática que costumo seguir em aplicações quem possuem um grande número de models por exemplo, é separá-los em subdiretórios dentro de app/models. Não preciso criar namespaces para isso. Basta acrescentar o novo diretório no load path da aplicação.

Se a sua aplicação possui vários domínios, faz sentido organizar desta forma.

Guru-SP – Criando um Framework com Rack em 10 minutos from agaelebe on Vimeo.

Porém a partir deste commit, a gem Capybara ganhou uma nova DSL que irá permitir a realização de testes de aceitação com Rspec sem depender do Steak.
Particularmente achei isso muito interessante. Será uma dependência a menos e as coisas estão ficando cada vez mais facilitadas.

Abaixo, vou listar alguns passos para utilizarmos esta nova funcionalidade do Capybara.

1) Crie uma nova aplicação Rails e configure seu Gemfile como o seguinte:

gem 'sqlite3'
gem 'rspec-rails'
gem 'capybara', '1.0.0.beta1'
gem 'database_cleaner'

Obs: as versões anteriores a 1.0.0.beta1 do Capybara não possuem suporte a esta nova DSL

2) Rode o comando bundle install para instalar todas as dependências

3) Rode o comando rails g rspec:install para setar as configurações base do Rspec

4) Abra o arquivo spec/spec_helper.rb e sete o parâmetro use_transactional_fixtures para false, da seguinte forma:

config.use_transactional_fixtures = false

Esta configuração será necessária quando desejarmos rodar nossos testes com o driver de javascript

5) Crie o diretório spec/support e adicione o arquivo capybara.rb com o seguinte conteúdo:

require 'capybara/rails'
require 'capybara/dsl'
 
RSpec.configure do |c|
  c.include Capybara::DSL, :example_group => { :file_path => /\bspec\/acceptance\// }
end

É com esta configuração que fazemos esta integração da nova DSL do Capybara com o Rspec. Ainda, estamos configurando que os nossos arquivos de testes de aceitação irão ficar em spec/acceptance.

6) Crie o arquivo spec/support/database_cleaner.rb com o seguinte arquivo:

require 'database_cleaner' 
 
RSpec.configure do |config| 
 
  DatabaseCleaner.strategy = :truncation 
 
  config.before :each do 
    Capybara.reset_sessions! 
    DatabaseCleaner.clean 
  end 
 
end

Basicamente estamos usando a gem DatabaseCleaner para limpar a nossa base de dados a cada execução dos testes. Também estamos resetando as sessões do Capybara.

Neste ponto terminamos a fase de configuração. Agora já poderemos escrever nossos testes.
Vamos usar o nosso bom e velho exemplo de Blog, e criar o seguinte teste em: spec/acceptance/post_spec.rb

require 'spec_helper'
 
feature "Post Blogs", %q{
  In order to have an awesome blog
  As an author
  I want to create a post
} do
 
  background do
    Post.create(:title => "My Post Title", :body => "My Body")
  end
 
  scenario "Post index", :js => true do
    visit posts_path
    page.should have_content('My Post Title')
    page.should have_content('My Body')
  end
 
end

Basicamente estamos definindo nossa feature, e no bloco background estamos criando um Post antes da execução de cada teste.

No cenário Post index, estamos escrevendo algumas ações e poderíamos utilizar todos os métodos do Capybara para interagir com a página, como por exemplo fill_in, click_link etc.

Também estamos usando o “ :js => true” para que o nosso teste seja executado com o browser aberto. Isso será necessário quando precisarmos interagir com alguma funcionalidade que envolva javascript, ajax etc. Se seu teste não depende de javascript, recomendo não usar o :js => true, pois fará apenas que ele fique mais lento.

Por fim, estamos verificando se o post está presente na página.
É importante observar que a ideia, é apenas mostrar o que é possível de se fazer. Não estamos discutindo sobre a melhor maneira de testar esta tipo de funcionalidade(cadastro de post).

Obviamente, se rodarmos o teste agora ele irá falhar.
Agora, vamos implementar nosso código para que o teste passe, e um simples Scaffold resolverá a questão.

rails g scaffold Post title:string body:text
rake db:migrate RAILS_ENV=test

Ao rodarmos o teste com o comando:

rspec spec/acceptance/posts_spec.rb

O teste deverá passar.

Conclusão

Pensando no cenário em que a equipe não tem o cliente ajudando ou escrevendo histórias com Cucumber, acho muito válido escrever testes de aceitação com estas ferramentas. Ainda mas agora, que poderemos utilizar apenas Rspec e Capybara.

Um exemplo prático é a criação de APIs. Podemos por exemplo, ter uma determinada action em nossa aplicação, que é responsável por apenas devolver um JSON. Neste caso o uso do Rails Metal é extremamente indicado, pois evitamos carregar funcionalidades nas quais não precisaremos..

De forma resumida, o Rails Metal praticamente provê um código suficiente para uma aplicação Rack.

No Rails 3 temos o ActionController::Base que herda de ActionController::Metal, que por sua vez herda de AbstractController::Base.

Esta nova arquitetura nos dá muita flexibilidade para utilizar somente o que necessitamos.
Veja um exemplo prático abaixo:

Download de arquivos

Vamos imaginar que nossa aplicação possui uma funcionalidade de upload de arquivos, e que posteriormente desejamos disponibilizá-los para download. Porém existe uma restrição: Apenas usuários autenticados poderão fazer o download dos arquivos.

Neste caso, não podemos simplesmente fazer o upload dos arquivos dentro do diretório public. Caso contrário os arquivos estariam disponíveis sem autenticação.

Uma possível solução seria realizar o upload em um diretório fora de public, e em seguida criar um controller que direciona o usuário para o download do arquivo em questão.
Esta é uma situação ideal para usar o Rails Metal, afinal precisamos apenas verificar a autenticação do usuário e em seguida enviar o arquivo.

Abaixo uma possível implementação de exemplo:

Em nosso arquivo routes.rb teríamos algo do tipo:

 match '/download/:file' => DownloadController.action(:file)

E nosso controller seria:

class DownloadController < ActionController::Metal
 
  before_filter :authenticate_user!
 
  def file
    #implementação da lógica para recuperar qual arquivo o usuário deseja
    send_file("/path/to/your/file.csv")
  end
 
end

Simples e prático! Porém esta implementação não irá funcionar, pois precisamos incluir alguns módulos em nosso controller.

• Para utilizarmos o send_file precisamos incluir o módulo ActionController::Streaming
• Para utilizar o before_filter precisamos incluir o módulo AbstractController::Callbacks
• Para verificarmos a autenticação do usuário com o Devise precisamos incluir o módulo Devise::Controllers::Helpers
• E para finalizar precisaremos também do módulo ActionController::Helpers pois o Devise utiliza o método helper_method para criação dinâmica do método :authenticate_user!

Agora nossa implementação seria:

class DownloadController < ActionController::Metal
 
 include ActionController::Streaming
 include AbstractController::Callbacks
 include ActionController::Helpers
 include Devise::Controllers::Helpers
 
 before_filter :authenticate_user!
 
  def file
    #implementação da lógica para recuperar qual arquivo o usuário deseja
    send_file("/path/to/your/file.csv")
  end
 
end

Com isso temos um controller mais leve e ainda podemos utilizar diversas funcionalidades que as demais gems, módulos etc nos fornecem.

“O método try permite-nos invocar qualquer método, sem nos preocupar com o fato do objeto receiver ser nil. Caso o objeto seja nil, a exceção NoMethodError seria lançada, mas utilizando o try isso não aconteceria. Ao invés disso, nil seria retornado.”

Situação 1)

Ao invés disso:

person = Person.find_by_name(“Rinaldi”)
 
unless person.nil?
 person.age
end

Poderíamos fazer isso:

person = Person.find_by_name(“Rinaldi”)
person.try(:age)

Situação 2)

["a","b","c"].select{|letter| ["g","m","k"].include? letter}.last.try(:upcase)

No exemplo acima, estamos invocando o método upcase em um objeto que talvez não exista. Logo, é recomendável utilizar o try.

Se por algum motivo precisássemos utilizar o método try diretamente no Ruby poderíamos fazer a seguinte implementação:

class Object
 def try(method)
   send method if respond_to? method
 end
end