Keep Learning Conhecimento nunca é o bastante

Duas dicas rápidas sobre RSpec

1. Não utilize a sintaxe abaixo:

something.should != value

A razão para isso é que != é uma expressão, enquanto ==, >=, <= e outros são métodos (podermos utilizá-los sem o "." é açúcar sintático da linguagem). Dessa forma, por mais que na maioria dos casos isso não incorra em efeitos indesejados (a expressão retorna um booleano, o que, em geral, basta) mas a equipe que desenvolve o RSpec recomenda evitar o uso, preferindo a sintaxe abaixo:

something.should_not == value

E para verificar essa diferença, veja abaixo:

ree-1.8.7-2010.02 > 1.== 1
 => true 
ree-1.8.7-2010.02 > 2.>= 1
 => true 
ree-1.8.7-2010.02 > 2.!= 1
SyntaxError: compile error
(irb):3: syntax error, unexpected tNEQ
2.!= 1
    ^
	from (irb):3

2. Essa é até bem conhecida, mas vejo um número considerável de pessoas fazendo outra coisa tentando fazer isso: ao configurar callbacks para executar código de setup/teardown antes ou depois de toda a suíte, no bloco de configuração, podemos controlar a ordem com os métodos prepend_before e append_after:

Spec::Runner.configure do |config|
  # antes da suite
  config.before(:suite) do #alias para append_before (ou seja, depois de outros blocos "before")
    # fazer alguma coisa, provavelmente setup
  end
 
 # depois da suite
  config.after(:suite) do #alias para prepend_after (ou seja, antes de outros blocos "after")
    # fazer alguma coisa, provavelmente cleanup
  end
 
  # Podemos ter um controle mais fino da ordem de execução dos callbacks
 
  # antes de tudo, inclusive do bloco "config.before" um pouco acima
  config.prepend_before(:suite)
    # setup do setup ;)
  end
 
  # após tudo, inclusive do bloco "config.after" um pouco acima
  config.append_after(:suite)
    # teardown do teardown ;)
  end
end

O que você está construindo?

O ser humano é um construtor. Nós, desenvolvedores de software, independente de formação ou posição, temos fome de construir. O que queremos é construir coisas a partir de nossas ideias, botar à prova nosso conhecimento e, dessa forma, adquirir maturidade, experiência e mais conhecimento.

Vejo dois comportamentos profissionais comuns que podem prejudicar muito isso:

• Quero ser promovido: aquela pessoa que acredita que deve se dedicar 100% à agradar aos seus superiores. Dessa forma ela conseguirá “evoluir” profissionalmente até chegar à tão sonhada liberdade profissional/financeira.
• Eu não ligo: para esta pessoa, “é apenas um trabalho”. Ela não vai se aprimorar, simplesmente porque não vê necessidade. Em geral, não constrói nada, pois não acredita estar fazendo algo em benefício próprio.

No primeiro caso, a dita “liberdade” nunca será alcançada pois, na verdade, ela não existe. Pouquíssimas pessoas (se existir alguma) possuem a “verdadeira” liberdade: estar completamente livre de qualquer restrição de tempo, espaço e recursos. Isto é: dinheiro infinito e possibilidade de tempo e localização para estar onde quiser no momento que quiser, independente de qualquer fator externo. Isto é utópico.

A liberdade está em cada um – basta se sentir livre para ser livre – e é bem possível atingir isso nessa sociedade louca movida à sacrifícios em nome da tal “vida profissional”: basta não participar da loucura.

No segundo comportamento, vai ficar sempre um vazio pois, independente de ser por trabalho ou por diversão, temos essa necessidade intrínseca de construir: daí o fato de pessoa nenhuma, mesmo com riqueza “infinita”, conseguir ficar absolutamente sem fazer nada por muito tempo. A maioria de nós precisa trabalhar pra se sustentar, então temos de encontrar meios para conciliar isso com a satisfação por criar.

No final das contas, é sim “apenas” um trabalho: o seu trabalho, a sua criação (seja em troca de dinheiro ou não). Evite errar pelo excesso ou pela falta. Deve ser algo a se construir e se orgulhar, não um empecilho para seu bem estar. Se esse for o caso, hora de se movimentar para mudar: o que você está construindo?

Comprometa-se consigo mesmo.

Uma frase que ouço com frequência é: “não se comprometa com trabalho feito para outros, apenas com um negócio próprio”. Bom, tenho que dizer que isso é um perfeito discurso de perdedor. Primeiro porque, em geral, as pessoas que falam isso estão trabalhando para outras. Segundo porque elas não tem coragem para assumir riscos e começar um negócio próprio.

Isso costuma ser trazido muito à tona em conversas com amigos e conhecidos pois prefiro trabalhar em startups em oposição à empresas grandes e tradicionais. De alguma forma, startups estão ligadas a profissionais mais comprometidos, o que nem sempre é verdade, e muitas usam esse “status” para exigir longas e estafantes jornadas de trabalho. Ninguém deve se comprometer com esse tipo de vida, seja a empresa uma startup ou não.

Não consigo me imaginar passando oito horas por dia fazendo algo com que eu não tenha comprometimento e não acredite que vai dar certo. E isso não é exclusivo à startups: esse tipo de atitude é necessária esteja você trabalhando em uma startup com mais três pessoas, em uma corporação gigantesca ou no seu próprio negócio.

Você iniciaria uma empresa para fazer algo em que não acredita? Penso que não. Então por que em um emprego “normal” isso seria diferente? Fazendo uma conta bem básica, são cento e sessenta horas por mês, durante trezentos e sessenta meses (equivalente a trinta anos), o que dá seis anos e meio continuamente fazendo algo que você não dá a mínima.

Enquanto você não inicia seu próprio empreendimento (talvez nunca), a solução é encarar o “trabalho para os outros” como seu empreendimento. Afinal, é isso mesmo o que ele é. O lucro (ou prejuízo) final pode não ficar na sua mão, mas o trabalho que você realizou e a sua satisfação com ele não dependem disso.

Se você não consegue enxergar isso como possível, é um ótimo sinal de que você deve parar de se lamentar e iniciar seu empreendimento. Comprometa-se consigo mesmo, independente do fato de, no momento, você ter um chefe ou ser o chefe.

Sentinel: agora, mais transparente do que nunca

Em Janeiro criei a gem Sentinel, que provê a funcionalidade do padrão Observer de forma transparente para código Ruby. Bom, olhando os exemplos de uso da primeira versão, é possível perceber que a biblioteca não é tão transparente assim: apesar de não alterar os métodos observados, a classe subject tem conhecimento do observer, o que não é bom (nos comentários do post linkado acima falo sobre um “hack” para contornar isso, mas não é uma solução elegante).

Com o amadurecimento da ideia e algumas alterações no código, foi possível tornar a biblioteca totalmente transparente do ponto de vista do subject a partir da versão 0.2.0. Segue um exemplo (ignore a “inocência” do código):

class User
  def save
    ...
  end
end
 
class UserObserver
  include Sentinel
 
  observe User, :save
 
  def self.notify(*args)
    #método chamado antes de user.save
  end
end

Uma atual limitação é que a interceptação é sempre feita pelo método de classe notify do Observer. O plano é que isso seja flexibilizado em breve.

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.