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

Um segundo problema que o processo formal de revisão ataca, é o de identificar e corrigir falhas em estágio inicial de desenvolvimento, para evitar que o mesmo se propague e torne custoso a correção. O objetivo aqui é em reduzir o tempo total de desenvolvimento e reduzir custos.

Falando sobre o primeiro problema:

A teoria da computação nos garante que é computacionalmente impossível , gerar uma ferramenta que nos garanta que para qualquer aplicação informada, seja possível fazer uma análise para saber se a mesma é 100% livre de falhas. Isto é conhecido como Halting problem.

Sabendo que não é possível construir tal ferramenta, podemos tentar resolver por aproximação, criando uma ferramenta que ataque um nicho específico de aplicações, ou tentar outras abordagens que tenham um melhor custo benefício em casos genéricos.

As abordagens genéricas, sabendo-se que não é possível automatizar essa solução, atacam o problema através de mudanças no processo. Essas mudanças podem ser feitas de N maneiras distintas. As mais tradicionais vão pela linha do modelo de maturidade (entende-se aqui a adoção de CMMI, MPSBR, etc. e suas práticas).

Modelos de maturidade estão em baixa atualmente, devido em parte do sucesso do movimento ágil, e em partes devido a ascensão de linguagens mais dinâmicas e que utilizam paradigmas mais distintos.

Uso de métricas para auxiliar um processo de desenvolvimento ágil:

Uma das alternativas que se pensa no mundo ágil para tentar alcançcar o mesmo objetivo (produzir um software de qualidade, livre de falhas), é a utilização de métricas para “julgar” a qualidade, substituindo a revisão formal.

O problema das métricas é que elas indicam o “estado em que está”, mas não um “caminho para onde se quer chegar”. Tem um artigo muito bom de um dos criadores do Code Climate, que fala sobre as métricas utilizadas no Ruby, o significado delas e a motivação deles ao construir a ferramenta:

“…There’s a lot our code can tell us about the software development work we are doing. There will always be the need for our own judgement as to how our systems should be constructed, and where risky areas reside, but I hope I’ve shown you how metrics can be a great start to the conversation.”

A armadilha está na geração de um score. Se você parar para pensar, o score nada mais é do que uma formula, definida unilateralmente (chame aqui de “opinião” ou “convenção”), que uma empresa ou um grupo de pessoas dentro da mesma definiu.

Esse score leva em consideração regras que eles acreditam que refletem o que seria um código “bom”, do ponto de vista deles. Note que estamos falando sobre ponto de vista (pode-se considerar nesse contexto como um sinônimo pra opinião).

Algumas das métricas que compõem o score, possibilitam uma análise precisa sobre “bom” e “ruim” enquanto outras sugerem que seja definido um threshold, para que conclusões seja feitas. A idéia de se precisar definir um threshold, indica claramente que determinada solução não pode ser aplicada universalmente, e portanto ao usar dessa forma, estamos cometendo um grave equívoco.

Esse equívoco vai mais além. Ao marcar um código como “ruim” (aplicar uma nota B, C, D…), baseado em uma análise falha, tenta-se sugerir maneiras de refatorar o código para que a nota seja melhorada, e então considerar que aquele código é “bom”.

Se voltarmos a nossa análise inicial sobre o Halting problem, o erro básico aqui fica mais grigante.

O que fazer então?

Primeiramente, faça o que o próprio criador sugere, use o seu próprio julgamento e entenda quando alguma coisa deve ser mexida ou não, mas não faça apenas para subir a nota.

Existe um outro artigo que havia lido recentemente: “Automated code metrics: Why you shouldn’t care about thresholds”, que fala exatamente sobre essa questão, e sugere que você não deve escolher um score mínimo e transformar isso numa cruzada ignorante para manter o código dentro desses parâmetros a qualquer custo.

Uma forma de melhorar um pouco essa situação, seria que cada projeto pudesse customizar a forma como o score é gerado, podendo assim configurar os parâmetros que você considera coerentes para aquele projeto, tendo sempre a opção de “ignorar” (e registrar isso, de forma a corrigir o score) qualquer conclusão que a ferramenta realizar automaticamente para você.

Se você não está convencido de que este é o caminho correto, sugiro a leitura deste outro artigo do James Turner: “Process Kills Developers Passion”. No artigo ele ataca esse e outros “pecados” que são cometidos pela nossa indústria que nos desvia do caminho ideale nos distrai do nosso foco que é de fato produzir software livre de falhas e de qualidade.

(Eu pretendo escrever em um post futuro uma análise com a mesma óptica, sobre a utilização desenfreada de Design Patterns)

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.

A maior diferença estrutural que Linkedin e Facebook tem em relação ao Google Plus, é o que torna o Twitter uma ferramenta excelente de comunicação para diversas comunidades, a questão do assincronismo dos relacionamentos.

Diferentemente da relação orgânica no facebook de amizade, que depende da aceitação mútua, no Google Plus você pode seguir qualquer pessoa e começar a ter acesso as postagens direcionadas ao público, e isso gera uma ótima ferramenta de interação social, muito mais poderosa que nas outras redes, sem a necessidade de apelar para a criação de “Páginas”.

O recurso de “seguir” alguém está disponível no Facebook também, mas não é muito bem utilizado pelas pessoas, simplesmente por que não é o workflow padrão. Da mesma forma, a geração de conteúdo público e direcionado para certos grupos é muito menos intuitiva e natural no Facebook, e isso não parece ser alguma coisa que vá mudar tão cedo, pois envolveria uma mudança drástica no status-quo, que dificilmente seria realizado nessa altura do campeonato.

Se não bastasse essa diferença em como as comunicações acontecem, ultimamente, de maneira muito pouco científica, eu tenho observado uma degradação considerável na percepção de “performance aparente” do Facebook, e semanalmente pelo menos algumas vezes existem problemas parciais em funcionalidade principais, que interrompem o fluxo de comunicação, e abrem espaço para o usuário explorar outras redes sociais. E pelo que estamos notando, parece que eles também estão chegando a conclusões parecidas com a minha.

TL;DR

Em poucas palavras, eu acredito que o Facebook continuará sendo a rede social de “coisas sociais” por muito tempo, mas as pessoas que estão tentando fazer um uso profissional, vão encontrar melhores mecanismos no Google Plus, por exemplo. Em algum momento eu acredito que o twitter começará a perder espaço, já que temos o mesmo poder de assincronismo no Google Plus, sem a limitação de 140 caracteres.

O que vocês acham?

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

Várias idéias vieram em mente, e cheguei a uma conclusão interessante: não existe um CMS focado no desenvolvedor.

Parece tão óbvio se você analisar toda a frustração que existe na nossa comunidade por não existir uma solução silver bullet, que cada um acaba seguindo o caminho de criar seu próprio CMS.

De reinvenção da roda em reinvenção da roda, nós perdemos muito com a fragmentação dos esforços. Se tivéssemos alguma solução forte que fosse meio que padrão para todo mundo, poderíamos estar todos fortalencendo essa solução e nos beneficiando daquilo que o Open Source trás de melhor.

ALGUNS PROJETOS INTERESSANTES:

Eu já havia explorado algumas vezes a listagem de CMS do Ruby Toolbox, mas dessa vez estava vendo as soluções com outros olhares.

O que parece mais promissor pra mim são três projetos, e o motivo disso é que nenhum deles está pensando em concorrer com o WordPress no mesmo nível (eles não querem fazer um WordPress clone, como o pessoal do Typo).

Locomotive CMS

Este aqui é de longe o mais bonito e foi também o que mais me chamou a atenção.
Ele resolve o problema que a maioria dos CMS estão tentando resolver sem muito sucesso: Criar outros tipos de itens que não só “artigos” e “páginas”. O clássico, portifólio e produtos, que ninguém fez direito, sem as “gambiarras” dos temas.

Ele consegue organizar isso muito bem, graças ao uso do MongoDB, que em partes facilitou muito a implementação do “crud dinâmico”, mas que também gera uma dependência alienígena para um CMS, que pra mim é ponto negativo dele.

Confortable Mexican Sofa

O nome é proposital, para também formar a sigla CMS, e foi implementado na linha que eu acredito que tem futuro: Rails Engine.

Isso significa basicamente uma coisa: Você consegue “plugar” ele na sua aplicação existente.Isto resolve o problema de integração do CMS com a sua aplicação, já que ele agora faz parte dela.

Outro ponto positivo dessa solução é que ele disponibiliza via DSL própria, meios de você utilizar a mesma interface de administração que ele está utilizando para outras coisas da sua aplicação, ou seja, você consegue estender facilmente, sem muito malabarismo.

Railsyard

Desenvolvido por uma empresa de publicidade italiana, possui o visual menos atraente dos três, mas aborda o problema com uma proposta bastante diferente, ao invés de CMS, CMF: Content Management Framework.

Lembra quando comentei sobre colocar o foco no desenvolvedor?

Standard
Ruby On Rails, Ubuntu

Instalação do Nginx + Passenger no Ubuntu 12.04 via apt-get

Este artigo é uma continuação do artigo anterior, Instalação do Ruby 1.9.3 sem RVM ou Rbenv no Ubuntu 12.04.

Se você ainda não seguiu os passos de instalação sugeridos no artigo anterior, faça-os, já que eles são necessários para que os passos seguintes funcionem conforme esperado.

Como explicado no artigo anterior, estamos usando o ppa da Brightbox, que além de nos fornecer uma versão atualizada e otimizada do Ruby, também fornece uma compilação do nginx com passenger, integrados com ruby 1.8.7 ou 1.9.3.

A instalação é feita via apt-get:

Feito isto, é necessário verificar apenas o arquivo de configurações do nginx e descomentar as duas linhas mencionadas no trecho de configuração do passenger:

Com isso você tem uma instalação funcional do nginx com passenger embutido, e precisa agora apenas gerar uma configuração de virtual host.

Este ultimo passo é o que de fato vai apontar uma “pasta” do seu servidor, para ser disponibilizada pelo nginx quando alguém acessar um determinado domínio.

Vamos colocar o arquivo em /etc/nginx/sites-enabled e reiniciar o servidor (sudo service nginx restart):

Está pronto. Nginx + Passenger atendendo requisições em um virtualhost, sem precisar do RVM, do rbenv ou de compilar na mão passenger ou alguma versão do ruby.

Standard