Geral, Ruby On Rails

Acelerar o Rails Assets Precompile

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%).

 

Standard
Ruby On Rails

Atualizando testes do RSpec 3.x automaticamente para nova sintaxe

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:

 

Standard
Programação, Ruby On Rails

Por que você não deve seguir cegamente o score do Code Climate

Recentemente, houve uma discussão na lista do GURU-SC em relação a uso de patterns para satisfazer um nivel de score específico no Code Climate.

Para quem não conhece, o Code Climate é uma ferramenta para geração automática de métricas de “qualidade”. Apesar deles se intitularem uma ferramenta de Revisão de Código, não é isso que a ferramenta faz:

Code review is systematic examination (often known as peer review) of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills. Reviews are done in various forms such as pair programming, informal walkthroughs, and formal inspections.” – Wikipedia

Sendo pragmático, pode-se considerar o objetivo de “melhorar as habilidades dos desenvolvedores” como um objetivo complementar de “melhorar a qualidade geral do software”. Qualidade tem um significado subjetivo que pode ser visto pela ótica da robustez (um software de qualidade é aquele que nunca falha), ou pela facilidade de dar manutenção (desacoplamento, Separation of Concerns, cobertura de código, uso correto dos recursos de orientação a objetos, etc). Continue reading

Standard
Programação

Como definir o filetype de um arquivo no vim

Trabalhando recentemente com o Redmine, me trouxe uma situação meio incomum: precisar definir o filetype de um arquivo que não utilize a extensão .rb padrão de arquivos ruby.

Uma das muitas engenhosidades (gambiarras) que podem ser feitas quando você quer permitir que o usuário atualize o Gemfile sem necessariamente editar o Gemfile, é forçar que o mesmo inclua o conteúdo de um segundo. Como o Gemfile nada mais é do que um arquivo ruby, qualquer código ruby dentro dele é executado como tal:

Este código acima é o trecho encontrado no Gemfile do Redmine, o que ele faz é carregar o conteúdo do Gemfile.local como se fosse uma continuação do mesmo Gemfile. Com isso o usuário pode incluir todas as customizações que quiser sem se preocupar em ter que fazer merge do Gemfile a cada atualização. Continue reading

Standard
Geral

Documentação Offline para Gems

Este é um daqueles posts essenciais para quem quer trabalhar de qualquer lugar, sem ter que se preocupar se vai ter acesso a consciência coletiva (Google/Stack Overflow), afinal sabemos que 3G e Wifi só funcionam bem na loja da operadora e em casa, respectivamente.

O primeiro passo é garantir que todas as nossas gems instaladas passaram pelo processo de geração da documentação. Isso é muito importante, por que, por padrão, o Bundler não executa a geração do RDoc, para garantir uma melhor performance:

O processo vai demorar consideravelmente de acordo com a quantidade de Gems que você possui.

Aqui entra duas opções, você pode suar somente os comandos que já possui (isto, é usar o “gem” para hospedar as próprias documentações), ou usar algo melhor como o YARD.

O YARD é a mesma ferramenta que é responsável pela geração das documentações no RubyDoc.info.

A instalação é via Rubygems:

Para acessar a documentação, basta rodar o servidor embutido:

Resultado final acessando http://0.0.0.0:8808:

Yardoc server

Standard
Geral

Ruby 2.0.0-p247 no Ubuntu 12.04 LTS via apt-get

Este post poderia se chamar também “Como criar pacotes Debian do Ruby 2.0.0 ou de qualquer outra versão“, já que é exatamente isso que vou ensinar.

Não se preocupe, por que não existe nenhum trabalho manual ou muito complicado, pra falar a verdade é muito mais simples do que você imagina, e com isso, você ganha uma instalação muito mais rápida no servidor de produção, seja pra uma máquina ou pra 10mil.

Se você está lendo este artigo, espero que já esteja convencido sobre por que utilizar RVM ou Rbenv em produção é uma má idéia, mas se você ainda tem dúvida, alguns argumentos para auxiliar na sua decisão:

  1. Se você não utiliza o sistema de pacotes do seu sistema operacional, você perde toda a gerência de dependências que vem com ele, e com isso, corre o risco de alguém inadvertidamente quebrar a sua instalação customizada e compilada, instalando um pacote mais antigo do que o instalado manualmente.
  2. Utilizando pacotes você consegue gerenciar facilmente atualizações, bem como garantir que todas as dependências também estão atualizadas.
  3. Compilar Ruby em produção vai degradar a performance da máquina, durante todo o processo de compilação, sem contar que será necessário instalar uma quantidade grande de dependências que não seriam normalmente utilizadas se você já tivesse o pacote compilado.
  4. Difícil automatizar, já que você não tem muito controle sobre o que pode acontecer durante um processo de compilação. Uma compilação pode falhar em uma das máquinas e você dificilmente vai ficar sabendo disso, se esse procedimento for ser executado em muitas máquinas ao mesmo tempo e de forma regular.
  5. Desperdício de recurso ter compilar a mesma coisa em várias máquinas.

Se você ainda achar que os argumentos acima não são suficientes, talvez a facilidade de se gerar o pacote possa te convencer o contrário.

Continue reading

Standard
Geral, Redes Sociais

Google Plus está indo bem, mas não como você imagina

Minhas observações recentes sobre como o Google Plus está evoluindo rápido e abocanhando uma boa quantidade de usuários:

O maior concorrente atualmente do Google Plus, na minha opnião não é o Facebook, e sim o Linkedin, e em algum outro nível o twitter.

É incrível como a quantidade de recursos disponíveis no Linkedin focando em criar uma comunidade de usuários profissionais não conseguiu atrair até hoje uma densidade relevante de conteúdo gerado por usuários. Você encontra sim, uma gama muito bem estruturada de currículos e realizações, mas não é ali que as melhores conversas estão acontecendo. Continue reading

Standard
Ruby On Rails, Tutoriais, Ubuntu

Instalação do Ruby 2.0.0-p195 no Ubuntu 12.04+ sem RVM e Rbenv

Se você estava aguardando uma patch release do Ruby 2.0 para começar a utilizar ele em produção, a hora é esta. Com o lançamento a poucos dias do 2.0.0-p195 e do lançamento dos pacotes pela Brightbox, ficou mais fácil impossível de instalar em produção, sem precisar das soluções alternativas do RVM e do Rbenv.

Este artigo é uma atualização do artigo anterior: Instalação do Ruby 1.9.3 sem RVM ou Rbenv no Ubuntu 12.04, para mais detalhes consulte-o.

Note que vamos utilizar para essa instalação o repositório experimental, o que significa em outras palavras: “não utilize para sistemas que possuam necessidade crítica de estabilidade”.

Continue reading

Standard
Geral

RMagick no Ubuntu

Uma das maiores vantagens do Ruby é o quão facil ele consegue conversar com bibliotecas escritas em C. Esta característica supre uma série de necessidades que seriam impossíveis ou pouco interessantes, se fossem escritas diretamente na linguagem. Seja por questões de performance, ou pela falta de motivação em reescrever alguma coisa que já funciona bem.

Nessa linha, temos algumas bibliotecas que conversam com o ImageMagick, sendo a mais conhecida e utilizada o RMagick (mas não necessariamente é a melhor).

Uma das coisas que sempre me incomodou em relação a ela, são as dependências que não estão “muito bem documentadas”. Em outras palavras, um “gem install rmagick” não vai ter o resultado esperado, a menos que alguns pacotes do sistema operacional estejam instalados.

TL;DR

Para instalar os pacotes necessários para conseguir instalar e compilar o rmagick, digite o comando abaixo:

Standard