2) O ingênuo: Ele sabe como escrever testes mas não enxerga muito valor. Normalmente escreve testes por obrigação ou para não passar vergonha diante da equipe. Ele é do tipo que se o build está quebrado e alguém pede para ele consertar, ele comenta o teste e faz git push. Também reclama muito que escrever testes demora muito e ele seria muito mais produtivo se não tivesse que testar.

3) O extremista: Ele valoriza o teste de forma extrema. Para ele, todo código deve ser testado. 100% de cobertura é o objetivo é a maior garantia. Até utiliza técnicas como TDD, BDD e outras, mas o que importa mesmo é ter teste para tudo, inclusive para código que ele não escreveu. Quanto mais teste por linha de código melhor.

4) O experiente: Ele entende os principais motivos para testar: melhorar o design do código, fornecer garantias etc. Compreende que nem tudo precisa ser testado e nem tudo é viável de testar. Por experiência e prática, ele testa aquilo que pode quebrar e não gasta tempo com testes inúteis que levam tempo demais para serem escritos. Pratica TDD quando faz sentido e não fica preso a “regrinhas”.

class User < Struct.new(:name, :email)
  def info
     "#{name} - #{email}"
  end
end
User.new("Rinaldi", "mail@gmail.com").info

Esta não é uma boa ideia porque se a esta classe User for carregada duas vezes, será lançado o seguinte erro: “TypeError: superclass mismatch for class User”

Isso ocorre pelo seguinte: A cada vez que a classe for definida, uma nova instância do Struct será criada.
Se a classe for carregada pela segunda vez, User já vai ter uma referência.
Em projetos Rails este erro poderia seria comum.

Se você realmente deseja fazer uma abordagem neste estilo, melhor seria utilizar um bloco da seguinte forma:

User = Struct.new(:name, :email) do
  def info
    "#{name} - #{email}"
  end
end
User.new("Rinaldi", "mail@gmail.com").info

A mudança foi praticamente mínima e o possível erro será evitado.

Um exemplo desta falácia pode ser vista no seguinte post: Dependency injection is not a virtue

Como o título do post sugere, o autor apresenta alguns argumentos falaciosos que poderão levar o leitor a acreditar que usar injeção de dependência não é uma boa ideia.

Basicamente, o autor apresenta o seguinte código:

def publish!
  self.update_attributes(created_at: Time.now)
end

E comenta que em linguagens como Ruby, podemos simplesmente usar stubs para testar o comportamento, mas em por influência de linguagens não tão flexíveis, acabamos achando necessário acrescentar um parâmetro no método publish! para poder fazer a injeção da dependência e com isso ficar mais fácil escrever o teste.

O código ficaria assim:

def publish!(time=Time.now)
  self.update_attributes(created_at: time)
end

Resumindo, ele critica a técnica de injeção de depedência argumentando que sua utilização é necessária apenas para facilitar o teste. Resumindo, seria assim: “Muitas pessoas usam injeção de dependência para facilitar o teste, logo não existe virtude em utilizar”.
Perceberam como o argumento é falacioso?

Não precisa ser expert no assunto para ver que isso não é verdade. Com pouco tempo de estudo e prática, percebe-se que a utilização desta técnica traz muitas vantagens.
Em um post anterior, eu mesmo falei sobre o assunto.

No geral eu concordo que modelar seu código para que o mesmo fique mais fácil de testar não é o ideal. Porém, este argumento não é válido o suficiente para afirmar que não existe virtude em utilizar injeção de dependência.

O correto deveria ser o oposto. Fazer um bom design para que a facilidade de testar seja uma consequência.

Grande parte das aplicações Web necessitam de algum sistema de filas para realizarem determinados trabalhos em background. Dois dos mais conhecidos no mundo Ruby são: Resque e Sidekiq.

Desta forma, quando precisamos enfileirar algum Job para ser executado em background, fazemos algo como:

class MyService
   def do_something(params)
      Resque.enqueue(MyWorker, params)
   end
end

Existe algum problema com isso?

Sim. É praticamente certo que a chamada Resque.enqueue será espalhada por toda a aplicação. O problema ficará evidente quando precisarmos mudar o sistema de filas. Se atualmente usamos o Resque e decidimos migrar para Sideqik, teremos que alterar várias partes da aplicação. É importante notar que uma mudança deste tipo não é totalmente incomum. Já vi muitos projetos(grandes inclusive) mudarem.

Logo, quanto mais flexível estiver nosso código, menos trabalho teremos. Sempre devemos escrever código pensando que ele poderá mudar.

Como resolver?

Segue abaixo um exemplo de modelagem que costumo utilizar:

class ResqueAdapter
  def self.push(MyJob, params) 
    Resque.enqueue(MyJob, params)
  end
end
 
class SideKiqAdapter
  def self.push(MyJob, params)
    Sidekiq::Client.enqueue(MyJob, params)
  end
end
 
class MyService
  attr_accessor :queue_adapter
 
  def initialize(adapter = ResqueAdapter)
    @queue_adapter = adapter
  end
 
  def do_something(params)
    @queue_adapter.push(MyJob, params) 
  end
end

Comentários:

1) A ideia é implementar o Adapter Pattern. No caso, temos uma classe chamada MyService que possui um método que irá enfileirar um Job. Nosso objetivo é que qualquer cliente que precise enfileirar um Job conheça uma interface única e bem definida. No exemplo, esta interface é o método push. Logo, toda a aplicação irá “saber” que para enfileirar um Job, precisará do método push com seus devidos parâmetros.
Com isso iremos evitar o Resque.enqueue por toda a aplicação.

2) No exemplo, o adapter padrão é o ResqueAdapter. Se em determinado momento decidirmos mudar para o SideKiq basta utilizar o SideKiq realizando a mudança em apenas um ponto, pois temos flexibilidade.

3) Estamos aplicando o Open/closed principle mantendo a interface fechada e modificando a implementação através da injeção de dependência e duck typing

Finalizando

A ideia aqui é mostrar que pequenas decisões no Design podem trazer grandes ganhos.
No Rails 4 teremos uma API bem definida para enfileirar Jobs e teremos ganhos semelhantes aos que citei acima.

Desta forma, estou fazendo a consulta ao web service a partir da aplicação Rails.
Como esta consulta deve ser rápida e não precisava de todo o stack do Rails, utilizei um controller Metal ao invés de um comum.

Eu já sabia que utilizando Rails Metal conseguiria processar muito mais requests mas como tínhamos que retornar um JSON, precisamos adicionar 4 módulos ( ActionController::Rendering, ActionController::Renderers::All, ActionController::MimeResponds, ActionController::ImplicitRender ) e neste ponto já não sabia se após incluir estes 4 módulos a performance continuaria a mesma.

Fiz um teste rápido com Httperf e verifiquei que ainda assim foi possível processar mais que o dobro de requests.

Se tiverem alguma situação semelhante, acredito que valha a pena a utilização.
Poderíamos montar uma simples Rack App para poder fazer esta consulta e retornar o JSON, mas considerei o resultado obtido como suficiente.

Abaixo uma versão resumida do código:

class MyController < ActionController::Metal
  include ActionController::Rendering
  include ActionController::Renderers::All  
  include ActionController::MimeResponds
  include ActionController::ImplicitRender 
 
  def index
   #uma consulta qualquer 
   render :json => {:resultado => :teste}
  end
end

Antes de mais nada, é importante destacarmos o problema que os Presenters se propõem a resolver. No MVC(model view controller) temos a View como responsável por apresentar os dados. Com isso existe uma forte tendência de sobrecarregarmos esta camada inserindo lógica, tratamento de dados etc.

Desta forma, a ideia de utilizar Presenters é tirar todas estas responsabilidades da View com a utilização de objetos especializados. Este termo foi inicialmente trazido para a comunidade Rails por Jay Fields neste post de 2007. Atualmente alguns desenvolvedores preferem usar outros nomes e variações. Particularmente gosto(ou será costume?) do nome “Presenter” e nest post estou focando na ideia de sua utilização. Neste contexto não estou me importando com o nome que iremos chamar este “tipo” de objeto. Quero focar na ideia.

Se tratando de implementação, Presenter é uma espécie de Decorator. Decorator é um pattern cuja responsabilidade é adicionar funcionalidades a uma classe.
No caso dos Presenters, sua responsabilidade é adicionar responsabilidade de apresentação a uma classe.

Se tratando de implementar Design Patterns, sempre seguiremos “regras”. Se o pattern X diz que devemos implementar de determinada maneira, “deveremos” seguir. Porém, não sou 100% purista a ponto de não me permitir modificar o que considero necessário. Desta forma vou listar abaixo algumas características que particularmente considero importante nos Presenters que uso.

1) Ser um Decorator real: Como disse acima, um Presenter é um Decorator. Ser um decorator real significa implementar o Presenter de forma a ter sua interface transparente em relação ao objeto que ele decora. Desta forma os métodos invocados no Presenter serão delegados para o objeto decorado(caso o Presenter não os implemente).

2) Composição/Modificação com foco na apresentação: Esta é a característica principal. O Presenter irá decorar o objeto podendo inclusive adicionar novos métodos responsáveis em realizar alguma formatação. Ex: Podemos ter um método responsável em formatar uma Data ou exibir um nome de determinada maneira.

3) Possibilidade de acesso ao contexto corrente: Se tratando de aplicações Rails por exemplo, podemos considerar 2 tipos de contextos: Controllers e Views. A ideia é que de dentro dos Presenters consigamos ter acesso a métodos ou variáveis de instâncias do contexto. Com isso podemos ter métodos que levem em consideração o estado de elementos que estão presentes no contexto. Ex: Podemos ter um método em nosso Presenter que exiba determinada informação apenas se o usuário estiver logado. Para sabermos se o usuário está logado podemos acessar o contexto e verificar esta condição.
Este é um caso que poderíamos por exemplo, remover alguns IFS das views.

Com o objetivo de implementar estas 3 características, criei uma gem chamada ClassicPresenter. O código é absolutamente simples e foi inspirado em algumas outras implementações de “Presenters” de outros desenvolvedores. Decidi criar a gem após ter percebido que eu repeti o mesmo código nos últimos 3 projetos que trabalhei.

Exemplo de utilização:

Para simplificar o exemplo vou considerar que temos uma aplicação Rails com os seguintes items:

1) Um CRUD básico de Produtos(ex: rails generate scaffold Product name description)
2) Sistema de autenticação com a gem Devise

Dados que estamos neste ponto, podemos seguir os seguintes passos:

1) Instale a gem ClassicPresenter adicionando a seguinte linha em seu Gemfile e em seguinda rode o comando bundle install

gem 'classic_presenter'

2) Crie um Presenter para a classe Product(que você criou com seu CRUD) com o seguinte comando:

rails generate  presenter Product

Este generator irá criar um arquivo chamado product_presenter.rb dentro do diretório app/presenters

3) Adicione o seguinte código:

class ProductPresenter < ClassicPresenter::Base
  def display_name
      if context.user_signed_in?
        context.link_to name, context.product_path
      else
        name
      end
  end
 
  def display_description
    #crie uma partial chamada description para poder usar este método
    context.render "products/description", :product => self
  end
end

Basicamente, nosso Presenter implementa as 3 características que citei acima. Como ele decora uma instância da classe Product qualquer método que invocarmos no Presenter será delegado para a instância de um Product a menos que o Presenter implemente.

Agora vou listar abaixo alguns detalhes referente ao código acima:

a) Dentro de qualquer método do Presenter teremos acesso ao context. Se o Presenter foi instanciado na View, ela será o context. Logo teremos acesso a todos os métodos da View como por exemplo link_to, number_to_currency, ou até o current_user que é um método de nossa View provido pela gem Devise

b) Perceba que quando invocamos o método name, este será delegado para o objeto decorado.

4) Utilizando o Presenter na View:

Nossa View do arquivo show.html.erb poderia ser implementada da seguinte forma sem o Presenter:

<% if user_signed_in? %>
<%= link_to @product.name, product_path %>
<% else %>
<%= @product.name %>
<% end %>
 
<% render "products/description", :product => @product %>

Utilizando nosso Presenter podemos refatorar esta View para a seguinte forma:

<% present ProductPresenter, @product do |presenter| %>
<%= presenter.display_name %>
<%= presenter.display_description %>
<% end %>

A seguir as vantagens que eu vejo que com esta mudança:

• Retiramos toda a lógica da View e encapsulamos em um objeto
• Aplicamos o princípio tell don’t ask e simplesmente dizemos para nosso presenter “apresenter” os dados
• Tendo acesso ao contexto de dentro do Presenter podemos realizar praticamente toda tarefa que necessitarmos se estivéssemos diretamente na View

Voce pode visualizar os slides neste link e acompanhar o vídeo abaixo:

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.