Existem algumas poucas certezas na vida de um programador, uma delas é que o tempo de compilação tende sempre a ficar maior, conforme o projeto evolui, e para lidar com isso, precisamos de novas ferramentas ou novas formas de tratar o problema. Apesar de Ruby ser uma linguagem interpretada, todo programador Rails sofre, quando vai colocar o seu código no ar, com o tempo de compilação dos assets.

Nesse caso, o processo chamado mais precisamente de “precompile”, roda por padrão uma série de otimizações em códigos CSS e JavaScript, além da conversão de linguagens como SASS, LESS e CoffeScript, para as equivalente que seu browser é capas de entender.

Uma das coisas que mais me irritava nesse processo é que existia apenas uma única alternativa disponível no framework pra lidar com esse problema, trocar o “Componente” que realiza essa pré-compilação, por um possivelmente mais eficiente.

No entanto, nenhum existente foi pensado para ser executado em um conjunto grande de arquivos, e muito menos usando conceitos de paralelismo. E nesse ponto eu sempre achei que poderia ser algo que daria um ganho gigantesco no tempo de pré-compilação (considerando uma máquina com múltiplos cores).

Encontrei uma Gem que promete fazer algo a respeito nesse sentido. Ela faz um monkeypatch no Sprockets para que o mesmo utilize fork durante o processo e portanto, consiga utilizar todos os processadores da máquina, sem partir pra uma abordagem com threads.

Instalação:

As instruções de instalação, podem ser encontradas no projeto do Github: steel/sprockets-derailleur com a vantagem de também ter suporte para Rails 3.2

Bônus:

Existe uma discussão para melhorar o Sprockets sem a necessidade de se fazer um monkeypatch, se você também considera isso importante, contribua no ticket #308.

Bônus 2:

Eu presenciei uma melhora gigantesca no tempo de pré-compilação, quando atualizei uma aplicação legada que utilizava Rails 3.2 para 4.0 (caiu de 4 minutos para meros segundos). De início achei que pudesse ser um caso isolado e então conversei com algumas outras pessoas, que me relataram o mesmo resultado.

Então, se você está tendo problemas com isso e ainda está no Rails 3.2, mais um motivo para migrar logo.

Resultados:

Apenas para prova de conceito, escolhi uma aplicação OpenSource, para validar os ganhos. Estou utilizando o gitlabhq/gitlabhq, com a tag v7.1.0. Abaixo estão o antes e o depois (apesar de ser pouco o tempo de pré-compilação dessa aplicação, baixamos ~40%).

# Antes
bin/rake assets:precompile  0,10s user 0,02s system 1% cpu 9,124 total

# Depois
W, [2014-08-20T14:29:40.588648 #8941]  WARN -- : Initializing 8 workers
W, [2014-08-20T14:29:45.413547 #8941]  WARN -- : Completed compiling assets (5.29s)
bin/rake assets:precompile  0,10s user 0,02s system 2% cpu 5,829 total

Sempre que temos que dar manutenção em um código legado, uma coisa interessante de se fazer é atualizar as bibliotecas das quais ele depende, para aproveitar correções de segurança e melhorias, no entanto, esse processo nem sempre é simples e transparente. Eventualmente APIs se tornam deprecated e maneiras melhores de se fazer uma determinada coisa são inventadas.

O processo de refactoring pode ser duro se sua base de testes não tiver uma boa cobertura, mas quando o que precisa ser melhorado é justamente o responsável pelos testes, caímos no famoso problema: “Who watches the watchman?”

No caso estamos falando da migração do RSpec 2.x para 3.x, e aqui vai a melhor receita de bolo:

1. Atualize primeiramente o RSpec para 2.99, esta versão vai te informar (através de Warnings) sobre todos os problemas de compatibilidade que você terá ao migrar para a 3.0 em diante, e vai te permitir consertar pró-ativamente os mais críticos.
2. Atualize para o 3.x
3. Instale e execute a gem Transpec para migrar as sintaxes deprecated para o novo modelo

Utilizei em um projeto que estava migrando do Rails 3.2 para 4.0 e correu sem maiores dificuldades, e o projeto ainda me gerou um template para a commit message, descrevendo tudo que foi feito! Sobra mais tempo pro café :)

Bônus: Eu optei por manter a sintaxe dos shoulda-matchers intacta, sem convertê-los de it { should ... } para it { is_expected.to ... }. Essa e outras opções podem ser feitas através de flags passadas pro transpec durante a execução. Desabilitei também o “explicit spec type”, pois uso ele dinamicamente. No meu caso o comando utilizado foi:

transpec -k oneliner -t