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

Inicialmente é importante compreender o que realmente acontece quando usamos o extend self.

Considere o seguinte código:

module MyModule
 def hello
   "hello"
 end
end
 
class MyClass
 extend MyModule
end
 
puts MyClass.hello

Basicamente estamos realizando o mixin de class methods. Ou seja, com o extend, os métodos definidos no módulo estarão disponíveis na classe MyClass(que por sua vez é um objeto). Por este motivo é que acessamos MyClass.hello ao invés de primeiramente criarmos um objeto da classe MyClass.
Isso seria necessário se utilizássemos o include, ao invés do extend.

Agora o que aconteceria se utilizássemos o extend self dentro de nosso módulo conforme o código abaixo?

module MyModule
extend self 
def hello
   "hello"
 end
end

Quem é self? Neste caso self é o próprio MyModule. Logo seria o mesmo que escrevêssemos: extend MyModule.

Com isso, o método hello também estará disponível no objeto MyModule(que é uma instância da classe Module).

Isso nos permite escrever:

MyModule.hello

O que podemos fazer com isso?

1) Esta abordagem facilita nosso trabalho no momento de testarmos, pois podemos isolar nosso módulo/classe e testar seu comportamento de forma separada. Não precisaríamos por exemplo, realizar um include/extend em alguma outra classe/objeto somente para este fim.

2) Uma alternativa para implementar o Singleton Pattern.

Considere o seguinte código:

require "singleton"
 
class MyLib
 include Singleton
 
 def initialize
   @var = "hello"
 end
 
 def hello
   puts @var
 end
end
 
MyLib.instance.hello  #=>hello

Estamos apenas implementando o Singleton Pattern em uma classe.

Utilizando o extend self podemos ter basicamente o mesmo comportamento:

module MyLib
 extend self
 
 def var
   @var ||= "hello"
 end
 
 def hello
   puts var
 end
end
 
MyLib.hello #=> hello

Obs: a intenção não é substituir uma implementação pela outra, mas sim mostrar alguns recursos da linguagem que nos permitem resolver determinados problemas de maneiras diferentes. Inclusive esta é uma das filosofias do Ruby.

MyLib.configure do |config|  
  config.my_property = 25  
end

Ou seja, estamos setando uma propriedade com o valor 25.

A Gem Capybara utiliza esta mesma abordagem. Veja abaixo:

Capybara.configure do |config|             	
  config.default_wait_time = 2  
end

Vamos ver abaixo, como funciona esta implementação. Considere o seguinte código abaixo:

module MyLib
  class << self
    attr_accessor :my_property
    def configure
      yield self
    end
  end
end
 
MyLib.configure do |config|
  config.my_property = 2011
end
 
puts MyLib.my_property

Basicamente estamos definindo um módulo chamado MyLib. Dentro dele, estamos definindo um accessor chamado my_property e também um método chamado configure.
Porém o accessor e o método, são definidos na singleton class do objeto MyLib.

Se você não entendeu muito bem esta questão de singleton classes, eu expliquei com mais detalhes no post “Ruby: relações e interações entre classes e objetos”.

A grande “sacada” está no método configure. Ele executa o método yield passando o self como parâmetro. Mas neste caso, quem será self? Self será o próprio módulo MyLib. Esta é a “chave” da questão.

É importante lembrar que o yield é o responsável por executar o bloco passado como parâmetro. E no exemplo acima, nosso bloco é:

do |config| config.my_property = 2011 end

Seguindo a ideia de como os blocos funcionam em Ruby, o módulo MyLib(que foi passado como self para o bloco) será mapeado para o config do bloco. Logo, quando fazemos config.my_property = 2011 de dentro do bloco, é como se estivéssemos fazendo MyLib.my_property = 2011.

Isso só foi possível pelo fato de termos definido um accessor para a nossa propriedade.

Uma outra abordagem que poderíamos utilizar para deixar a configuração um pouco mais modular seria com o seguinte código abaixo:

class Configuration
    attr_accessor :my_property
 
    def initialize
      @my_property = 'default value'
    end
end
 
module MyLib
  class << self
    attr_accessor :configuration
  end
 
  def self.configure
    self.configuration ||= Configuration.new
    yield(configuration)
  end
end
 
MyLib.configure do |config|
  config.my_property = "new value"
end
 
puts MyLib.configuration.my_property

Basicamente estamos armazenando um objeto de configuração dentro do nosso módulo.