DevOps, Programação

Palestra do TDC2015: Melhorando o Onboarding de Desenvolvedores com Boxen, Vagrant e Kitchenplan

Padrão
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%).

# 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

 

Padrão
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:

transpec -k oneliner -t

 

Padrão
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). Continuar lendo

Padrão
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:

local_gemfile = File.join(File.dirname(__FILE__), "Gemfile.local")
if File.exists?(local_gemfile)
  puts "Loading Gemfile.local ..." if $DEBUG # `ruby -d` or `bundle -v`
  instance_eval File.read(local_gemfile)
end

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. Continuar lendo

Padrão
DevOps, Ruby On Rails

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.

Continuar lendo

Padrão
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”.

Continuar lendo

Padrão
Ruby On Rails

Sobre CMS e Ruby on Rails

Alguém havia perguntado na comunidade Ruby on Rails Brasil a algum tempo atrás sugestões sobre CMS ou código de “Blogs” escrito em Rails. Em uma das minhas divagações filosóficas deste final de semana, estava chegando a uma conclusão sobre o por que nenhum CMS feito em Rails realmente decolou (a ponto de ser um concorrente a altura do WordPress).

Posso citar algumas coisas aqui que valem ser ditas:

  1. Nenhuma empresa patrocinando (este é o principal motivo na minha opnião… projetos ambiciosos sem uma empresa por trás pagando horas de desenvolvimento, tendem a falhar)
  2. Já existe o WordPress (ou seja, qualquer coisa que seja menos atraente que ele, não vai conseguir gerar massa crítica e convencer pessoas a desenvolver temas, plugins etc).
  3. Difícil customização (este aqui é o ponto que mais pesa, se eu já não estou usando o WordPress, é por que provavelmente eu preciso customizar o projeto e não quero “sujar as mãos” com código pouco estruturado em PHP).

Nessa linha, fiquei imaginando um pouco sobre quais características um projeto de CMS poderia ter que conseguisse superar as soluções existentes e ganhar tração suficiente para conseguir seu espaço ao sol. Continuar lendo

Padrão