DevOps, Ubuntu

Selecionando o repositório mais próximo do Ubuntu via linha de comando

Existem vários casos de uso em que você desejaria trocar a lista de repositórios para um repositório local mais próximo de você.

Em uma instalação padrão, o Ubuntu vai utilizar o país selecionado para pré-fixar um “country code” a url no /etc/apt/sources.list, no entanto esse comportamento não é ideal. Ao utilizar máquinas virtuais localmente com imagens já prontas, por exemplo usando o Vagrant, o problema se torna ainda pior, pois nesses casos, você provavelmente vai estar usando um repositório fora do país.

Estava tentando automatizar a alteração dos repositórios, e pelo fato de ser um projeto distribuído onde usuários de outros países iriam se beneficiar daquela configuração do Vagrant, não podia simplesmente fixar um país específico ou um repositório local.

Continuar lendo
Padrão
DevOps, Programação

Palestra do TDC 2015: ChatOps em Ruby

https://speakerdeck.com/brodock/chatops-em-ruby

Padrão
DevOps, Programação

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

Padrão
DevOps, Ubuntu

Cozinhando com o Chef: Orquestramento de servidores e Dev machines (TDC Floripa 2014)

Pra quem não pode participar do TDC 2014 em Florianópolis, a InfoQ está disponibilizando todas as palestras que foram gravadas, e você pode acompanhar a minha acesando o link da palestra: “InfoQ: Cozinhando com o Chef: Orquestramento de servidores e Dev machines”

Os slides também estão disponíveis abaixo:

 

 

Padrão
Redes Sociais

Construindo uma comunidade: Ruby on Rails Brasil

Estava esperando o momento certo para escrever este artigo, para que ele pudesse ser absorvido da melhor maneira possível pelas pessoas que se interessam pelo assunto.

Antes de chegar no catupiry da coxinha (o abrasileiramento da expressão “cereja do bolo”), queria compartilhar um pouco de como e por quê eu me envolvi com a comunidade Ruby on Rails Brasil, no Facebook, em junho de 2012.

A Origem

Naquela época, eu havia recentemente trocado de trabalho e tinha o desafio de iniciar uma nova equipe de desenvolvimento, usando uma tecnologia que não era o carro chefe (Ruby on Rails) daquele grupo de desenvolvedores. Tendo a responsabilidade de recrutar, treinar e auxiliar o progresso daqueles que viessem a trabalhar no projeto, me deixou com um sentimento de isolamento muito grande, não tendo muito com quem conversar sobre assuntos que viriam a ser de extrema importância também pro meu aperfeiçoamento.

Foi um pouco nessa vibe, que eu comecei a pesquisar, listas de e-mail, grupos de discussão pela internet, sem encontrar durante algum tempo, um que parecesse suprir esse requisito.

Meu ponto de partida foi com as comunidades gringas. Eu acreditava que encontraria uma discussão mais avançada lá, tendo como base o lag que diversas tecnologias sempre tiveram dentro do Brasil… (Java estou falando de você). Continuar lendo

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