Posts by Hugo Baraúna

Então você já fez a feliz escolha de tratar seu processamento em background com Delayed Job, ótimo! Mas como ter certeza que esse processamento vai continuar acontecendo enquanto você estiver dormindo? E se o o processo do Delayed Job cair, você vai acordar de madrugada e levantá-lo na mão? Eu não faria isso, gosto do meu sono. Qual a solução então?

Não é nenhuma novidade para nós, rubyistas e railers, que existem soluções como o God para fazerem o trabalho de monitoramento de processos. No entanto, existem outras soluções, como o Bluepill. O Bluepill é uma ferramenta de monitoramento de processos assim como o God, mas diferente dele, não tem memory leak, segundo seus autores.

Bem, como não quero acordar de madrugada para levantar meu processo do Delayed Job na mão, e também não quero ficar restartando um processo do God por causa de memory leak, resolvi usar o Bluepill. Mas como uso o Bluepill para monitorar o Delayed Job?

Para configurar o Bluepill para monitorar o Delayed Job, e usar o Capistrano para automatizar algumas tarefas, temos basicamente 4 passos:

  1. Instalar e configurar o Delayed job
  2. Instalar e configurar o Bluepill
  3. Escrever a receita de capistrano para o Bluepill
  4. Setar algumas coisas do arquivo /etc/sudoers

Vamos dar uma olhada em detalhes em cada passo.

Instalação e configuração do Delayed Job

Instalar e configurar o Delayed Job é super simples, basta ler o README do projeto, que está bem claro. Recomendo também assistir ao RailsCast sobre o Delayed Job. Foi de lá que tirei a informação de usar o fork do Delayed Job da Collective Idea ao invés da versão do repositório original.

Instalação e configuração do Bluepill

Instalar o Bluepill também não tem muito segredo, basta você ler o README do projeto e seguir os passos que estão descritos lá.

Na parte da configuração, você pode ver as opções também no README do projeto. No meu caso, esse arquivo está em RAILS_ROOT/config/production.pill.

Bluepill.application("my_app") do |app|
  app.process("delayed_job") do |process|
    process.working_dir = "/home/deploy/my_app/current"
 
    process.start_grace_time    = 10.seconds
    process.stop_grace_time     = 10.seconds
    process.restart_grace_time  = 10.seconds
 
    process.start_command = "ruby script/delayed_job -e production start"
    process.stop_command  = "ruby script/delayed_job -e production stop"
 
    process.pid_file = "/home/deploy/my_app/shared/pids/delayed_job.pid"
    process.uid = "deploy"
    process.gid = "deploy"
  end
end

No entanto, eu tive um pequeno problema com a interação do Bluepill e o Delayed Job. Ao passar a flag -e production para o Delayed Job, ele não a estava interpretando direito. Você pode ver mais detalhes sobre isso numa issue que abri no repo do Delayed Job.

A primeira solução que pensei, foi usar RAILS_ENV=production ruby script/delayed_job start, no entanto por algum motivo que ainda desconheço, isso não funcionou.

A solução que cheguei então para resolver esse problema, foi modificar o arquivo que está em RAILS_ROOT/script/delayed_job para o seguinte:

1
2
3
4
5
6
7
8
9
#!/usr/bin/env ruby
 
# TODO improve the line of code below
# The line below is just a hack while we wait the delayed job guys answer the following issue
# http://github.com/collectiveidea/delayed_job/issues#issue/38
ENV['RAILS_ENV'] ||= "production"
require File.expand_path(File.join(File.dirname(__FILE__), '..', 'config', 'environment'))
require 'delayed/command'
Delayed::Command.new(ARGV).daemonize

Como a flag -e production não estava sendo interpretada direito no Delayed Job, estou setando na mão o RAILS_ENV para production (linha 6), portanto estou supondo que você só está usando o Bluepill para monitorar processos do Delayed Job em environment igual a production.

Receita do Capistrano para o Bluepill

Para automatizar as tarefas de ligar e desligar o Bluepill, escrevi a seguinte receita de capistrano:

# deploy credentials
set :user, "deploy"
set :deploy_to, "/home/deploy/#{application}"
set :use_sudo, false
set :rails_env, "production"
 
# Bluepill related tasks
after "deploy:update", "bluepill:quit", "bluepill:start"
namespace :bluepill do
  desc "Stop processes that bluepill is monitoring and quit bluepill"
  task :quit, :roles => [:app] do
    sudo "bluepill stop"
    sudo "bluepill quit"
  end
 
  desc "Load bluepill configuration and start it"
  task :start, :roles =>[:app] do
    sudo "bluepill load /home/deploy/my_app/current/config/production.pill"
  end
 
  desc "Prints bluepills monitored processes statuses"
  task :status, :roles => [:app] do
    sudo "bluepill status"
  end
end

Note que ao invés de usar o método run do capistrano, estou usando o método sudo. Isso porque o comando bluepill deve ser rodado como root. Isso nos leva para o próximo tópico.

/etc/sudoers

Já que eu preciso rodar o comando bluepill como root, vou ter que mudar o meu set :user, "deploy" para set :user, "root"? Acho melhor não, não gostamos de dar acesso root para qualquer coisa, mesmo para deployment. Então, como fazer? Simples, basta editar seu arquivo de sudoers.

Para isso, você precisa usar o comando visudo para abrir e editar o arquivo /etc/sudoers. Uma vez com o arquivo aberto, adicione a seguinte linha no final do arquivo:

deploy ALL=(ALL) NOPASSWD: /usr/local/bin/bluepill

Pronto, agora o usuário deploy já pode fazer sudo bluepill sem precisar de senha. Problema resolvido sem colocar a segurança da sua máquina em risco. ;)

Depois de ter feito esses 4 passos, você está pronto para dormir a noite sem se preocupar com seu processo do Delayed Job. E quando quando quiser saber como está o status dos seus processos monitorados, basta usar a seguinte task do capistrano na sua máquina local:

cap bluepill:status

E você? Quais soluções você usa para dormir em paz?

Update: Se você está tendo problemas em restartar o Bluepill com o capistrano, dê uma olhada aqui.

Rails for Kids 2009

O Rails for Kids foi uma maratona beneficente de palestras on-line realizada no dia 12/09/2009  que contou com grandes nomes da comunidade Ruby on Rails do Brasil e de fora. Nós da Plataforma Tecnologia fomos representados por mim (Hugo Baraúna) e pelo George Guimarães.

A qualidade do evento foi surpreendente, ainda mais quando levamos em consideração que ele foi realizado totalmente on-line. Na minha opinião, a organização do Rails for Kids foi excelente pois juntou um respeitado time de palestrantes, utilizou uma ferramenta para apresentações online/e-learning  muito boa e teve presença em peso da comunidade. Parabéns ao Carlos Eduardo pela organização!  Eventos assim são sempre bem-vindos! =)

Mas para aqueles que não puderam participar do evento, não se preocupem. Ainda há uma chance: as palestras foram gravadas! Basta entrar no site do Rails for Kids e fazer uma simbólica doação.  Você ajuda quem precisa e assiste a palestras de primeira qualidade. É um benefício em dose dupla! =D

Se não puder ajudar com doações, divulgue. Vale lembrar que o objetivo maior é ajudar crianças carentes.

Valeu pessoal!

obs.: para ler um bom resumo das palestras do evento, dê uma olhada nesse post do Carlos Antônio, da para ter uma ótima idéia!

Everyone already heard about scalability at least once. Everyone already heard about memcached as well. What not everyone might heard is the dog-pile effect and how to avoid it. But before we start, let’s take a look on how to use Rails with memcached.

Rails + Memcached = <3

First, if you never used memcached with rails or never read/heard a lot about scalability, I recommend checking out Scaling Rails episodes done by Gregg Pollack, in special the episode about memcached.

Assuming that you have your memcached installed and want to use it on your application, you just need to add the following to your configuration files (for example production.rb):

1
config.cache_store = :mem_cache_store

By default, Rails will search for a memcached process running on localhost:11211.

But wait, why would I want to use memcached? Well, imagine that your application has a page where a slow query is executed against the database to generate a ranking of blog posts based on the author’s influence and this query takes on average 5 seconds. In this case, everytime an user access this page, the query will be executed and your application will end up having a very high response time.

Since you don’t want the user to wait 5 seconds everytime he wants to see the ranking, what do you do? You store the query results inside memcached. Once your query result is cached, your app users do not have to wait for those damn 5 seconds anymore!

What is the dog-pile effect?

Nice, we start to cache our query results, our application is responsive and we can finally sleep at night, right?

That depends. Let’s suppose we are expiring the cache based on a time interval, for example 5 minutes. Let’s see how it will work in two scenarios:

1 user accessing the page after the cache was expired:

In this first case, when the user access the page after the cache was expired, the query will be executed again. After 5 seconds the user will be able to see the ranking, your server worked a little and your application is still working.

N users accessing the page after the cache was expired:

Imagine that in a certain hour, this page on your application receives 4 requests per second on average. In this case, between the first request and the query results being returned, 5 seconds will pass and something around 20 requests will hit your server. The problem is, all those 20 requests will miss the cache and your application will try to execute the query in all of them, consuming a lot of CPU and memory resources. This is the dog-pile effect.

Depending on how many requests hit your server and the amount of resources needed to process the query, the dog-pile effect can bring your application down. Holy cow!

Luckily, there are a few solutions to handle this effect. Let’s take a look at one of them.

Dog pile effect working on your application!

Dog pile effect working on your application!

How to avoid the dog-pile effect?

The dog-pile effect is triggered because we allowed more than one request to execute the expensive query. So, what if we isolate this operation to just the first request and let the next requests use the old cache until the new one is available? Looks like a good idea, so let’s code it!

Since Rails 2.1, we have an API to access the cache, which is defined by an abstract class called ActiveSupport::Cache::Store. You can read more about it in this post or in this excellent railscast episode.

The code below simply implements a new and smarter memcached store on top of the already existing MemCacheStore:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
module ActiveSupport
  module Cache
    class SmartMemCacheStore < MemCacheStore
 
      alias_method :orig_read, :read
      alias_method :orig_write, :write
 
      def read(key, options = nil)
        lock_expires_in = options.delete(:lock_expires_in) if !options.nil?
        lock_expires_in ||= 10
 
        response = orig_read(key, options)
        return nil if response.nil?
 
        data, expires_at = response
        if Time.now > expires_at && !exist?("lock_#{key}")
          orig_write("lock_#{key}", true, :expires_in => lock_expires_in)
          return nil
        else
          data
        end
      end
 
      def write(key, value, options = nil)
        expires_delta = options.delete[:expires_delta] if !options.nil?
        expires_delta ||= 300
 
        expires_at = Time.now + expires_delta
        package = [value, expires_at]
        orig_write(key, package, options)
        delete("lock_#{key}")
      end
    end
  end
end

The code above is mainly doing:

  1. Suppose that your query is already cached;
  2. In the first five minutes, all requests will hit the cache;
  3. In the next minutes, the first request will notice that the cache is stale (line 17) and will create a lock so only it will calculate the new cache;
  4. In the next 5 seconds, the new query is calculated and all requests, instead of missing the cache, will access the old cache and return it to the client (lines 17 and 21)k;
  5. When the query result is returned, it will overwrite the old cache with the new value and remove the lock (lines 31 and 32);
  6. From now on, all new requests in the next five minutes will access the fresh cache and return it (lines 17 and 21).

Fallbacks and a few things to keep in mind

First, is not recommend to set the :expires_in value in your cache:

1
Rails.cache.write('my_key', 'my_value', :expires_in => 300)

With the solution proposed above, you just need to set :expires_delta. This is due to the fact that our application will now be responsible to expire the cache and not memcached.

1
Rails.cache.write('my_key', 'my_value', :expires_delta => 300)

However, there are a few cases where memcached can eventually expire the cache. When you initialize memcached, it allocates by default 64MB in memory. If eventually those 64MB are filled, what will memcached do when you try to save a new object? It uses the LRU algorithm and deletes the less accessed object in memory.

In such cases, where memcached removes a cache on its own, the dog pile effect can appear again. Suppose that the ranking is not accessed for quite some time and the cached ranking is discarded due to LRU. If suddenly a lot of people access the page in the five initial seconds where the query is being calculated, requests will accumulate and once again the dog-pile effect can bring your application down.

It’s important to have this scenario in mind when you are sizing your memcached, mainly on how many memory will be allocated.

Now I can handle the dog-pile effect and sleep again!

Summarizing, when your are using a cache strategy, you will probably need to expire your cache. In this process, the dog-pile effect can appear and haunt you down. Now you have one (more) tool to solve it.

You just need to add the SmartMemCacheStore code above to your application (for example in lib/), set your production.rb (or any appropriated environment) to use the :smart_mem_cache_store. If you use Rails default API to access the cache (Rails.cache.read, Rails.cache.write) and designed well your memcached structure, you will be protected from the dog-pile effect.

A real dog-pile! =p

A real dog-pile! =p

Rails for Kids 2009

A comunidade de Rails do Brasil está sempre ativa, sinal disso é que dia 12 de setembro vai acontecer o Rails for Kids 2009.
O Rails for Kids 2009 é um evento composto por uma maratona de palestras on-line ao vivo relacionados a Ruby on Rails. Teremos alguns dos melhores Railers do Brasil contando um pouco de suas experiências próprias sobre assuntos muito legais, como: deployment de aplicativos Rails, Agile, Git, Integração contínua, Cucumber, CouchDB e muito mais.
Eu (Hugo Baraúna) e o George Guimarães estamos entre os palestrantes =D. Falarei sobre metodologias ágeis e a motivação por trás delas, enquanto o George falará sobre deployment automatizado de aplicações em Rails com Capistrano e Passenger.
Agora, mais importante do que as palestras em si, é o fato que toda renda gerada pelo evento será doada à instituição Cotolengo, no Mato Grosso do Sul. Ou seja, você fará um grande gesto humano e ainda por cima poderá assistir à ótimas palestras!
Parabéns ao Carlos Eduardo da e-Genial, que é o responsável por este importante evento.
O Rails for Kids já está chegando, agora basta você ir ao site e se inscrever.
Nos vemos por lá!

A comunidade de Rails do Brasil está sempre ativa, sinal disso é que dia 12 de setembro vai acontecer o Rails for Kids 2009.

O Rails for Kids 2009 é um evento composto por uma maratona de palestras on-line ao vivo relacionados a Ruby on Rails. Teremos alguns dos melhores Railers do Brasil contando um pouco de suas experiências próprias sobre assuntos muito legais, como: deployment de aplicativos Rails, Agile, Git, Integração contínua, Cucumber, CouchDB e muito mais.

Eu (Hugo Baraúna) e o George Guimarães estamos entre os palestrantes =D. Falarei sobre metodologias ágeis e a motivação por trás delas, enquanto o George falará sobre deployment automatizado de aplicações em Rails com Capistrano e Passenger.

Agora, mais importante do que as palestras em si, é o fato que toda renda gerada pelo evento será doada à instituição Cotolengo, no Mato Grosso do Sul. Ou seja, você fará um grande gesto humano e ainda por cima poderá assistir à ótimas palestras!

Parabéns ao Carlos Eduardo da e-Genial, que é o responsável por este importante evento.

O Rails for Kids já está chegando, agora basta você ir ao site e se inscrever.

Nos vemos por lá!

Todo mundo já ouviu falar de escalabilidade. Todo mundo também já ouviu falar de Memcached. O que nem todos ouviram falar ainda é do dog-pile effect e de como evitar esse problema. Mas antes de discutirmos sobre o que é o dog-pile effect, vamos primeiro dar uma olhada em como é simples usar o Memcached com o Rails.

Rails com Memcached

Se você nunca usou o Memcached com Raills ou ainda não conhece muito sobre escalabilidade com Rails, os episódios do Scaling Rails feitos pelo Gregg Pollack são extremamente recomendados, especialmente o episódio sobre Memcached.

Dado que você tem o Memcached instalado e quer usá-lo dentro do seu aplicativo Rails, basta você ir em um dos arquivos de configuração, por exemplo o production.rb e colocar:

1
config.cache_store = :mem_cache_store

Por padrão, o Rails vai procurar por um processo do Memcached rodando no localhost na porta 11211.

Mas pra quê eu vou querer usar o Memcached? Bem, digamos que o seu aplicativo possui alguma página que precise rodar uma query lenta no banco de dados, tal como uma query para gerar um ranking de blog posts baseados na influencia dos autores, que demora em média 5 segundos. Nesse caso, toda vez que um usuário entrar nessa página do seu aplicativo, essa query será executada e o aplicativo terá um tempo de resposta muito alto.

Como você não vai querer que todo usuário sofra esperando 5 segundos para ver o ranking, o que você faz? Armazena o resultado dessa query no Memcached. Assim, uma vez que o resultado da query estiver cacheado, seus usuários não terão que esperar pelos malditos 5 segundos!

O que é o dog-pile effect?

Legal, você está cacheando o resultado da query do ranking e você finalmente vai poder dormir a noite. Será mesmo?

Vamos supor que você está expirando o cache baseado no tempo, ou seja, digamos que a query cacheada deva expirar após 5 minutos. Vejamos como esse processo funciona diante de dois cenários:

Um único usuário acessando depois do cache ficar obsoleto (stale):

Nesse primeiro cenário, quando um usuário acessar a página do ranking, a query deve ser executada novamente, fazendo com que a CPU do seu sistema tenha um pico de consumo para conseguir processá-la. Depois dos 5 segundos, seu usuário, poderá visualizar o ranking. Até aqui, ok, demorou, mas o usuário conseguiu ver o ranking e seu sistema (ainda) está de pé.

N usuários acessando depois do cache ficar obsoleto (stale):

Digamos que, em um dado horário, essa página do seu aplicativo tenha em média 4 requests/segundo. Nesse cenário, entre a chegada do primeiro request e o banco de dados retornar o resultado da query, passarão 5 segundos e ocorrerá algo em torno de 20 requests. O problema é, todos esses 20 requests irão dar cache miss e seu aplicativo executará a query em todos os casos, consumindo muitos recursos de CPU e memória. Esse é o dog-pile effect.

Dependendo de quantas requests resultarem em cache miss, do quão pesado for o processamento de sua query e dos recursos de infra disponíveis, o dog-pile effect pode acabar derrubando sua aplicação!

Caramba!!! Quer dizer que o dog-pile effect é tão sério assim e pode chegar a derrubar minha aplicação!? Sim, isso pode acontecer. Mas existem algumas soluções para evitarmos esse tipo de problema. Vamos dar uma olhada em uma delas.

O dog-pile effect pode fazer isso com seu aplicativo!

O dog-pile effect pode fazer isso com seu aplicativo!

Como resolver o problema do dog-pile?

Bem, o problema do dog-pile effect é que deixamos mais de um request executar o custoso cálculo da query. Hum… e se isolarmos esse cálculo para apenas o primeiro request e servir o antigo cache para os próximos requests até que o resultado cacheado da nova query esteja disponível? Parece uma boa idéia… Então vamos implementá-la!

Desde o Rails 2.1, temos uma API padrão para acessar o cache dentro do Rails definida por uma classe abstrata chamada ActiveSupport::Cache::Store. Você pode ver mais dessa API nesse post ou nesse ótimo episódio do railscast.

O código abaixo simplesmente cria um novo cache store baseado no já existente MemCacheStore:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
module ActiveSupport
  module Cache
    class SmartMemCacheStore < MemCacheStore
 
      alias_method :orig_read, :read
      alias_method :orig_write, :write
 
      def read(key, options = nil)
        lock_expires_in = options.delete(:lock_expires_in) if !options.nil?
        lock_expires_in ||= 10
 
        response = orig_read(key, options)
        return nil if response.nil?
 
        data, expires_at = response
        if Time.now > expires_at && !exist?("lock_#{key}")
          orig_write("lock_#{key}", true, :expires_in => lock_expires_in)
          return nil
        else
          data
        end
      end
 
      def write(key, value, options = nil)
        expires_delta = options.delete(:expires_delta) if !options.nil?
        expires_delta ||= 300
 
        expires_at = Time.now + expires_delta
        package = [value, expires_at]
        orig_write(key, package, options)
        delete("lock_#{key}")
      end
    end
  end
end

A idéia do código acima é a seguinte:

  1. Digamos que o resultado da sua query já está cacheada;
  2. Durante os 5 minutos seguintes, todas as requests resultarão em cache hit;
  3. Depois dos 5 minutos, o primeiro request que chegar vai ver que o resultado cacheado já está stale, ou seja, obsoleto (linha 17). Esse request vai criar um lock para apenas ele ter direto de calcular o novo valor a ser cacheado;
  4. Durante os próximos 5 segundos, estará sendo feito o cálculo da query, e todos os requests que chegarem, ao invés de resultarem em cache miss, vão resultar em cache hit (devido ao lock), devolvendo o último valor cacheado (linhas 17 e 21);
  5. Após o primeiro request acabar de fazer o cálculo da query, ele vai cachear o novo valor e apagar o lock que tinha criado (linhas 31 e 32);
  6. Todas os novos requests que chegarem nos próximos 5 minutos verão que o valor cacheado não está “stale”, resultarão em cache hit e retornarão o novo valor cacheado (linhas 17 e 21).

Armadilhas e algumas coisas para se lembrar

Primeiramente, não é recomendado setar o valor :expires_in do seu objeto cacheado:

1
Rails.cache.write('my_key', 'my_value', :expires_in => 300)

Com a nossa solução, basta que você sete o valor do :expires_delta. Isso porque a aplicação será responsável por expirar o cache, e não mais o Memcached.

1
Rails.cache.write('my_key', 'my_value', :expires_delta => 300)

Entretanto, existem alguns casos em que o Memcached ainda pode expirar o cache. Quando você inicializa o Memcached, ele aloca por default 64 MB de memória. Digamos que os 64 MB estão cheios, o que ele faz quando você tenta salvar o próximo objeto em memória? Ele usa o algorítmo de LRU e deleta o objeto cacheado menos acessado.

Nos casos em que o Memcached expira o cache por conta própria, há uma possibilidade de termos o dog pile effect novamente. Digamos que o ranking não é acessado por muito tempo e o objeto cacheado é descartado devido ao LRU. Se, de repente, muitas pessoas voltam a acessar a página e ocorrem muitos acessos durante os cincos segundos iniciais em que o ranking é gerado, o efeito pode ocorrer novamente.

Vale a pena ter essa situação em mente na hora que você for dimensionar por exemplo o quanto de memória vai ficar alocado para o seu Memcached.

Já consigo lidar com o dog-pile, posso voltar a dormir!

Resumindo, quando você estiver usando uma estratégia de caching, você provavelmente irá precisar expirar o seu cache. Com o processo de expiração, pode surgir o problema de dog-pile effect. Agora você já tem (mais) uma ferramenta na sua toolbox para resolver esse problema.

Basta colocar o código acima do SmartMemCacheStore na sua aplicação Rails (no diretório lib/ por exemplo), setar no seu production.rb (ou em outro environment.rb que você queira) e configurar a cache store para :smart_mem_cache_store (config.cache_store = :smart_mem_cache_store). Se você usa a interface padrão do Rails para acessar o cache (Rail.cache.read, Rails.cache.write) e arquitetou bem sua estrutura com o memcached, você estará protegido do dog-pile effect.

Curiosidade: de onde vem o termo dog-pile effect? Dog-pile é um termo comum em inglês para se referir a um monte de coisas empilhadas. A idéia da metáfora então seria comparar uma pilha de requests uma em cima da outra, esperando pelo processamento da query custosa.

Um dog-pile de verdade  =p

Um dog-pile de verdade =p

One of the first things we learn in Rails which are greatly useful are ActiveRecord validations. However, since they are easy to add, it happens frequently that we are burdening our users with validations instead of making forms easier and clearer.

For instance, let’s suppose we are validating the Social Security Number (SSN) of an user on signup. A sample code would be:

1
2
3
4
5
6
7
class User < ActiveRecord::Base
  validates_presence_of :ssn
  validates_length_of :ssn, :is => 9
  validates_numericality_of :ssn
  validates_uniqueness_of :ssn
  validates_as_ssn :ssn # Checks if a reserved or special SSN was sent
end

With the configuration above, if the user forgets to fill in the SSN, leaving it blank, four error messages related to the SSN field will be shown:

  • SSN can’t be blank
  • SSN is the wrong length (should be 9 characters)
  • SSN is not a number
  • SSN is invalid

The question is: if the user just left the field blank, why we should show all those errors to him? Are they all relevant?

OMG! What have I done wrong to appear so many errors?

OMG! What have I done wrong to appear so many errors?

Luckily, the solution is quite simple: we can make use of the :allow_blank option, so other validations won’t be triggered if the field is blank:

1
2
3
4
5
6
7
class User < ActiveRecord::Base
  validates_presence_of :ssn
  validates_length_of :ssn, :is => 11, :allow_blank => true
  validates_numericality_of :ssn, :allow_blank => true
  validates_uniqueness_of :ssn, :allow_blank => true
  validates_as_ssn :ssn, :allow_blank => true
end

This is also a nice use case for the Object#with_options method added by Rails:

1
2
3
4
5
6
7
8
9
10
class User < ActiveRecord::Base
  validates_presence_of :ssn
 
  with_options :allow_blank => true do |v|
    v.validates_length_of :ssn, :is => 11
    v.validates_numericality_of :ssn
    v.validates_uniqueness_of :ssn
    v.validates_as_ssn :ssn
  end
end

SSN is just an example, but we are frequently burdening our users in username, e-mail, password and many other fields.

Do not validate presence of confirmation fields

Another interesting subject about validations are the confirmation fields. We have the following note in the documentation of validates_confirmation_of:

1
2
validates_confirmation_of :password
# NOTE: This check is performed only if password_confirmation is not nil

And this is a feature. This means that you don’t need to give the :password_confirmation key when creating objects in console or when writing tests:

1
2
3
it "should be valid with valid attributes" do
  User.new(:password => "123456").should be_valid
end

If the test fails, you are validating the presence of :password_confirmation, which is unnecessary. Since the :password_confirmation field will be available in the views, it will always be sent. So if the user leave it blank, it’s sent as blank value to the model and therefore will be checked. Just in the place it needs to be.