Keep Learning Conhecimento nunca é o bastante

Sentinel: observers transparentes para seu código Ruby

Para uma determinada funcionalidade no Busk, precisava “trackear” todas as buscas feitas no site pelos usuários. Existem várias maneiras de conseguir esse resultado. Decidi por, de alguma forma, interceptar as chamadas ao método responsável pelas buscas (que faz o tratamento da query de busca enviada pelo usuário e chama o Sphinx). Uma das formas de se fazer isso é através do padrão conhecido como Observer.

Existem algumas bibliotecas open source que implementam Observers em Ruby e até mesmo uma na própria linguagem. Porém, queria que a implementação fosse transparente, sem alterar nada no método observado, nem mesmo adicionando uma chamada para notificar os observers, como é feito na implementação mais comum. Daí nasceu a ideia de criar uma pequena biblioteca provendo essa funcionalidade através do recurso de aliasing do Ruby e o resultado foi batizado de Sentinel, disponibilizado como uma gem.

Com essa gem, é possível interceptar chamadas a métodos de instância ou de classe através de um simples mixin (veja o Readme da gem para mais informações). De forma declarativa, definimos qual o método a ser observado e qual será o Observer notificado (qualquer objeto que responda ao método notify).

Sinta-se à vontade para sugerir modificações e notificar erros.

Desenvolvedor, arquiteto, programador, engenheiro…

É realmente necessário ter equipes de arquitetura separadas de equipes de desenvolvimento? Essa pergunta é muito antiga e cada um tem uma resposta. Pra mim, não. Mas vamos pensar mais sobre isso.

Em primeiro lugar, o que é um arquiteto de software? É um desenvolvedor com muito conhecimento e experiência (minha resposta)? É um profissional diferente, especificamente treinado para a arquitetura de sistemas? É alguém que possui algum “dom” especial?

O cargo de “Arquiteto de Software” como empregado hoje na indústria do software é mais uma herança ruim da comparação entre desenvolvimento de software e construção civil. Nesta última, o arquiteto faz o projeto mas, em geral, não suja as mãos no cimento. O ponto é: arquitetar um sistema de software é ou não é fundamentalmente diferente de construir software, isto é, programá-lo, testá-lo e mantê-lo? Não. Existem algumas diferenças e algumas preocupações diferentes mas é impossível dissociar as atividades no nível em que é feito em outras áreas.

Um fato interessante é que apenas empresas grandes, com orçamentos folgados (que, em geral, desperdiçam tempo e dinheiro com futilidades e becos sem saída) costumam oferecer o cargo de arquiteto de software. Eles geralmente ficam em equipes de arquitetura, longe das equipes que “sujam” as mãos no código no dia-a-dia. Ora, isso, por si só, cria as Torres de Marfim e uma certa animosidade latente entre as diferentes equipes – que deveriam trabalhar em conjunto todos os dias.

Não faz sentido (e não é eficiente) ter equipes de arquitetura separadas, sem contato direto e constante com as equipes de desenvolvimento. Também não faz sentido empregar arquitetos de software que só planejam e não participam da execução diariamente.

Usando a já batida metáfora do desenvolvimento de software como jardinagem é fácil perceber que estamos longe do processo utilizado, por exemplo, na construção civil ou na indústria automobilística. Não é possível projetar todo o software com antecedência, como um prédio ou um carro, comprar a matéria-prima, contratar os operários e implementá-lo praticamente sem desvios. O projeto é o software e o software é o projeto.

Podemos, sim, ter um plano geral, um conjunto de guias e processos a serem seguidos, interfaces definidas, padrões e tudo mais, mas é preciso adaptação rápida à mudança. Na criação (e não construção, isso é importante) de um jardim, uma planta pode não se desenvolver por um entre vários fatores. Na criação de software, uma especificação da equipe de arquitetura pode não se encaixar nas necessidades do projeto.

Se houver uma “equipe de arquitetura” como uma entidade especial, separada, perde-se muito tempo para reagir às mudanças. Se os arquitetos são do tipo que se acha bom demais pra se sujar na programação as conseqüências são ainda piores – em primeiro lugar porque eles não tem noção da realidade do projeto enquanto fazem os planos e, em segundo, porque tendem a resistir à mudanças no que consideram um plano perfeito.

Se insistíssemos em utilizar a metáfora da construção civil, podemos comparar todo o ciclo de desenvolvimento de software com o ciclo de arquitetura e projeto de um edifício, excluindo sua construção. O desenvolvimento de software é uma atividade criativa, não “mecânica”.

Um desenvolvedor de software que não se atenta à arquitetura, que não tenta melhorar nos fundamentos básicos necessários ao entendimento do software como um todo, não passa de um programador – um mero codificador, facilmente substituível.

Um arquiteto de software que não programa, não se envolve com o dia-a-dia da produção de software e não se interessa pelos outros aspectos da disciplina, não passa de um “masturbador mental de software“. Daí para o que os americanos chamam de “Death by PowerPoint” leva um piscar de olhos.

Sim, é necessário que tenhamos a figura do “líder técnico”, aquele desenvolvedor com bastante experiência e jogo de cintura, que já viu e já fez de tudo na área. Ele, inclusive, pode ter o cargo formal de arquiteto de software. O que não pode acontecer é que ele seja um profissional isolado em uma esfera de cristal, um “deus” criando o que ele pensa ser adequado, dando ordens e ignorando eventuais questionamentos de sua intocável arquitetura. Isso é tudo o que um time de verdade não precisa.

Em resumo, um bom desenvolvedor é também um bom arquiteto. E um bom programador. E um bom qualquer coisa que seja necessária para criar software consistentemente.

O ActiveSupport mexeu no seu logger? Recupere a formatação original!

Recentemente estava escrevendo um script de manutenção utilizando o logger padrão do Ruby e tudo estava indo muito bem. A formatação padrão do logger oferece uma boa quantidade de informação, com timestamp, id do processo, nível da mensagem (erro, informação etc), como na imagem abaixo:

Formatação padrão do logger

Pouco depois, resolvi utilizar o ActiveRecord (que carrega junto o ActiveSupport) no script. Feito isso, o output do logger mudou para:

Formatação com ActiveSupport

Isso não é bom. Pesquisei um pouco e descobri que o ActiveSupport modifica a formatação padrão utilizando uma classe chamada SimpleFormatter ao invés da classe Formatter padrão do logger.

Desta forma, recuperar a formatação original é simples, basta modificar o formater utilizado pela sua instância do logger:

log = Logger.new(STDOUT)
log.datetime_format = "%d-%m-%Y %H:%M:%S"
 
# Recuperando a formatação original
log.formatter = Logger::Formatter.new

Também é possível alterar o formatter padrão na classe Logger. Dessa forma todas as instâncias utilizarão o formato padrão:

# Fazer isso após carregar o ActiveSupport para reverter a alteração do formatter
class Logger
  def formatter
    @formatter = Formatter.new
  end
end

Utilizando rack-debug para debugging com Passenger

Desenvolver aplicações Rails utilizando o Phusion Passenger (principalmente no Mac OS X com o Passenger preference pane) é muito prático. Porém, uma coisa que logo senti falta foi a possibilidade de utilizar a gem ruby-debug quando precisava de breakpoints para debuggar o código.

Uma maneira de conseguir isso é através da gem/plugin rack-debug. Para utilizá-la, segui os passos abaixo.

1. Instalação

 $ script/plugin install git://github.com/ddollar/rack-debug.git
 
 # config/environments/development.rb
 config.middleware.use "Rack::Debug"

2. Chamar o debugger onde necessário:

  def create
    @status = current_user.statuses.create(params[:status])
    debugger
    if @status.valid?
...

3. Conectar-se ao debugger

 # No diretório da aplicação, chamar a task rake
 $ rake debug
 Connected.

4. Ao executar a linha onde o debugger foi chamado, a aplicação para e você tem acesso ao console do debugger

 (rdb:1) p @status
 #<status id: 231, text: "Testing rack-debug", user_id: 4, ...>

Pronto. Happy debugging!

Update: ao chamar a task rake, pode ocorrer um erro com a mensagem “Server is not running or Passenger has spooled down”. Neste caso, reinicie o Apache e tudo deve funcionar normalmente.

Seu chefe é incompetente? A ciência explica!

Pesquisas feitas na Universidade de Catania, na Itália, mostram que, quanto mais promoções, mais incompetente é o profissional. A pesquisa foi feita a partir do chamado Princípio de Peter, formulado pelo psicólogo canadense Laurence J. Peter, com a seguinte frase (original, em inglês): “Every new member in a hierarchical organization climbs the hierarchy until he/she reaches his/her level of maximum incompetence”.

A explicação é simples: no sistema de promoção por mérito, pessoas muito boas em dada especialidade são promovidas para outras áreas, para as quais podem ser menos aptas (claro, isso só ocorre quando a promoção leva o profissional a uma área em que suas habilidades atuais não são fundamentais). Dessa forma, cair nas garras do Princípio de Peter torna-se inevitável, levando a empresa a uma perda geral de eficiência ao longo do tempo.

A solução, segundo os cientistas, é reservar 50% das promoções para os piores profissionais da empresa – a chance de que eles “se encontrem” nos cargos aos quais são promovidos é muito maior.

Que desenvolvedor de software nunca topou com esse tipo de problema? Aquele cara, ótimo desenvolvedor, acaba sendo promovido à gerente (e aceita, seja pela grana, pelo status ou por falta de opção) e é simplesmente um zero à esquerda na função. É claro que isso acontece em qualquer área, mas é nesta em que eu tenho experiência.

Podemos tirar duas lições disso:

• Se, por ser um ótimo desenvolvedor, você for agraciado com uma promoção para outra área, pense duas vezes antes de aceitar – isso pode significar o fim da sua carreira como profissional competente. Se a empresa não lhe der opção (é bem comum que só se consiga um aumento aceitando uma promoção-bomba dessas), procure outro lugar – quando você realmente é competente, escolhas não faltam.
• Se você se tornar um empreendedor, primeiro busque ajuda especializada caso não se sinta à vontade com as tarefas necessárias nesse seu “novo cargo”. Você pode ser um ótimo designer com uma ótima ideia, mas isso não quer dizer que será um bom empresário. Além disso, pense bem na política de promoção que vai utilizar se a empresa for bem sucedida. Um exemplo: pode ser muito mais satisfatório recompensar os bons funcionários com melhorias salariais do que promovê-los a cargos para os quais eles não possuem aptidão.