Category Archives: Rails

Hackathon como forma de contratação

Sempre tive a idéia de utilizar um Hackathon como modelo de avaliação de candidatos que desejávamos contratar, apresentei o modelo para a Fortes e realizamos um evento com bastante sucesso em 2012.  Outras equipes da empresa passaram a utilizar a experiência e se tornou um modelo a ser seguido internamente e já com várias edições.

Esse ano fizemos o segundo do meu time para avaliar um candidato em Rails justamente para me substituir (foi meu último compromisso na empresa, apesar de já ter saído).

 

Vantagens

Contratar alguém é sempre uma loteria, por mais justo que seja o processo. Envolve, além dos aspectos técnicos, saber se o sujeito conseguirá se integrar na equipe aonde vai trabalhar, se não fere princípios e cultura da empresa e aceitação perante a todos os participantes. Não basta ter feeling no candidato, você precisa sempre comprovar que ele realmente merece, ou seja, o próprio avaliador também tem que saber vender a escolha que fez.

IMG_20140830_102439134

No primeiro Hackathon o candidato escolhido era primo de um funcionário da empresa e membro do time aonde iria trabalhar, meu amigo pessoal e já tinha trabalhado na própria empresa como terceirizado por uma consultoria. Ele venceu a competição com os critérios estabelecidos acompanhado pelo departamento de RH (que participaram no dia do evento como olheiros), foi o suficiente para não pairar nenhuma dúvida em sua escolha, apesar do RH ter escolhido outro candidato por questões que não estavam definidos nos nossos critérios de avaliação e premiação (o Hackathon ainda teve um premio em dinheiro para o vencedor).

Formato

A avaliação dos aspectos técnicos é dentro de uma simulação do ambiente de trabalho, já que você provavelmente organizará o evento dentro de sua cultura. A pressão que se espera, o relacionamento que se espera que ele desempenhe e toda a expertise técnica é esmiuçada com mais detalhes do que uma simples prova ou avaliação de currículo.

No primeiro evento fizemos um detalhamento muito rígido de como os candidatos seriam avaliados, inclusive incluímos testes como item obrigatório.

IMG_20140830_125726664

Dessa vez o formato foi mais simples, apenas dois times codificando o mesmo sistema (as mesmas features), com apenas duas rodadas de avaliação, uma primeira aonde declarávamos e apontávamos todos os pontos negativos e de correção e a segunda que seria apenas uma forma de avaliar o evento, trocar feedback e curtir a tarde de diversão.

IMG_20140830_125705090

O formato de inscrição no evento era acompanhado do currículo, link do github e quaisquer informações necessárias que os candidatos pudessem informar para ajudar na escolha dos participantes.

Os desenvolvedores estavam livres para codificarem como quiserem, avaliamos inclusive como eles se comportariam tendo que assumir posições com pessoas que nunca viram antes ou mesmo que conhecessem, nunca trabalharam juntas.

IMG_20140830_143802812

Feedback

O que todos perceberam é que uma simulação de codificação de uma Release real, mas acompanhado por uma equipe experiente que vai corrigindo o processo e os erros, é praticamente uma aula, um curso.

Tivemos o cuidado de apontar sempre quando o time se desviava do objetivo do desafio, praticamente doutrinar sobre o conceito de MVP dentro da realidade da empresa e do mercado. Pudemos perceber que os desenvolvedores se perdem fácil em detalhes que não são importantes em um produto e deixam seu ego passar sobre o valor do negócio.

IMG_20140830_164309781

O que percebemos também é que candidatos com o currículo muito forte ou experiente em relação aos demais  não conseguiu se vender tanto quanto outros candidatos que provavelmente seriam descartados logo de início em um processo convencional de apenas avaliação de currículo ou entrevista.

Daqui pra frente eu espero que o formato seja adotado em larga escala – e vou trabalhar para isso – como uma forma de contratação, inclusive na empresa que trabalho, a Sagarana.

Rails Rumble 2012, nós participamos

Mais uma vez participamos (@cmilfont, @rudrige, @alcidesqueiroz e @yuriadams) desse fantástico Hackathon da comunidade Rails que te desafia a escrever uma aplicação em apenas 48h. Havíamos participado da última edição do Rumble em 2010 com uma aplicação para organização/indexação de livros pessoais – uma pena não ter ocorrido em 2011.
Rails Rumble

Dessa vez resolvemos construir uma rede social para conhecermos os times e equipes de Brazilian JiuJitsu desde sua origem até os dias atuais, chamamos de Jiujitsu Team. Evidente que devido ao tempo e nossa disponibilidade não conseguimos fazer tudo que gostaríamos, mas fechamos um pequeno escopo e entregamos todo funcional, ao contrário de 2010.

Registramos o domínio uns dias antes e esboçamos um escopo do que gostaríamos de fazer – imagem a baixo.

Esboço do Projeto

No dia da competição eu ainda tentei fazer com TDD, mas ficou comprovado pra mim que eu não consigo “I TDD my spikes solutions“. Eu preciso de um tempo para maturar um projeto inicial, pelo menos a primeira versão “prototipal” nasce de experimentações num mexe-daqui-mexe-de-lá, mas depois voce consegue TDDar 🙂

# -*- encoding : utf-8 -*-
require 'spec_helper'
describe GraduationsController do
describe "GET belts" do
before do
@belts = []
7.times {|n| @belts << FactoryGirl.create(:belt, :name => "#{n} belt" )}
Belt.stub(:all).and_return @belts
end
it "should list all belts" do
get :belts, :format => :json
assigns[:belts].should == @belts
assigns[:belts].should have(7).belts
end
end
describe "POST create" do
before do
@graduation = Graduation.new :id => 1
@belt = Belt.new :id => 1
@graduation.stub(:belt_to).and_return @belt
controller.stub_chain(:current_user, :profile, :graduate_your_student).and_return(@graduation)
end
# @graduation = current_user.profile.graduate_your_student params[:student_id], params[:belt_id]
# respond_with @graduation, :include => :belt_to
it "graduate your student" do
post :create, :format => :json, :student_id => 1, :belt_id => 1
assigns[:graduation].should == @graduation
assigns[:graduation].belt_to.should == @belt
end
end
end

Participar de uma competição desse tipo é muito importante para nos testarmos sob pressão de tempo, validamos nossas crenças e ajustamos o que funciona ou não do “By The Book” com o suficiente necessário para um produto.

Profile no Jiujitsu Team

Dê uma navegada nos outros projetos para ver o que a comunidade de 500 times fez esse ano, se gostou do nosso projeto e quiser votar na gente, o link é esse.

Nodejs vs Rails, ou a ironia de quando apertam no meu calo.

Por volta de 2007/2008 quando o Rails se popularizou no mundo inteiro, um tema comum em todas as listas de discussões era como o Rails ia matar o Java. Ficavam furiosos os mais exaltados, porém míopes, javeiros.

Claro que era uma brincadeira com um fundo de verdade, um alerta para sermos poliglotas e usarmos o melhor ambiente/plataforma/ferramenta/etc para resoluções de problemas.

Claro que a comparação era esdrúxula porque comparavam um Framework com uma linguagem, aliás, não só linguagem, mas uma plataforma. Não importa se o Rails poderia ser executado na plataforma Java, a mensagem era o alerta de que não adianta fazer tudo com apenas uma ferramenta. Naquele momento se voce era programador DotNet, voce tentaria fazer tudo com DotNet, se voce fosse programador Java, o mesmo com sua linguagem/plataforma.

Na época Java era Mainstream, Rails um Framework que trazia consigo uma linguagem “Underground” com uma comunidade ainda muito pequena, porém vibrante.

A História se repete

Hoje em dia Rails é um Framework muito popular que criou um ecossistema em sua volta, graças a ele que a linguagem Ruby tem uma certa penetração até em grandes corporações. Ouso dizer que Rails é uma “plataforma” e que tudo gira em torno dele, retire esse Framework e a linguagem Ruby dificilmente se mantém no Mainstream.

Em 2009 surgiu uma ferramenta chamada Nodejs. Um “Evented I/O for V8 JavaScript“, ou seja, uma ferramenta para fazer IO não-bloqueante usando a VM do Chrome. Em pouco tempo a comunidade em volta do Nodejs repetiu o mesmo processo que o Rails levou de 2004 a 2010 só que em menos tempo. Esse ano (2011), as duas comunidades chamam a mesma atenção do mercado, principalmente as Startups do Vale do Silício.

Nodejs criou uma comunidade em sua volta, apesar de ter um propósito bem definido. Não existe um Framework no ecossistema Nodejs que sequer chegue aos pés do Rails, o máximo é algo similar o Sinatra chamado de Express. Mas somente a possibilidade de uma comunidade/ecossistema desviar a atenção e rivalizar no efeito “Sou foda, estou na crista da onda” já deixa incomodado muitos Railers.

Pois bem, eu dizia há alguns dias para amigos e clientes que a comunidade Rails iria subir nas tamancas quando o Nodejs crescesse mais do que já cresceu. O motivo que alerto é que a comunidade se tornou tão pedante quão a comunidade Java de 2007/2008. Hoje em dia temos “Railstards” que pregam o desenvolvimento somente com Ruby ao ponto de escreverem Javascript em Ruby por conveniência de não sair da sua zona de conforto.

Há alguns dias a Nodejitsu publicou uma página para acompanhar o momento onde o número de Watchers (observadores) do projeto nodejs no github ultrapassou o mesmo número no projeto Rails.

A Notícia por si só não deveria ter nenhum significado. Comparar um Framework popular com uma Ferramenta de Evented IO?

Ops, há alguns anos comparamos uma linguagem/plataforma com um Framework, ninguém disse na época que era descabido a comparação, porque seria hoje comparar Nodejs vs Rails?

Não rir dessa piada irônica só demonstra que você deveria subir um alerta, a grande maioria dos Javeiros já calçou a sandália da humildade, acho que ta na hora de nós Railers também 😉

Como disse o @leonardoeloy: Se Java é o novo Cobol, Rails o novo Java, Nodejs o novo Rails, quem é o novo Nodejs?