Categories
Gerenciamento

Sobre entrevistas (parte 3)

Em determinada etapa da sua carreira quando você se torna um desenvolvedor mais experiente ou líder de uma equipe, fazer entrevistas passa a fazer parte do seu dia-a-dia. Entrevistar pessoas é bastante cansativo, demorado e difícil, porém é um trabalho que precisa ser muito bem feito para que você consiga contratar os profissionais que melhor se encaixam na sua equipe e empresa.

A última vez que escrevi sobre entrevistas aqui no meu blog foi há três anos. De lá para cá liderei ou participei de algumas dezenas – talvez centenas – de entrevistas e umas dúzias de contratações, sempre tentando resolver o mesmo problema: Quais são as melhores abordagens para conseguir analisar uma pessoa e entender sua experiência tão bem quanto possível em apenas algumas horas?

Durante esses três anos tentei um monte de coisas diferentes, desde fazer filtro de profissionais com uma consultoria de RH até chamar pessoas para trabalharem na minha equipe por alguns dias e ver como elas funcionam. Todas as abordagens tem seus prós e contras e não há uma fórmula secreta para resolver esse problema, mas ficam aqui algumas dicas novas de coisas que deram certo nesses últimos anos:

Entrevista por telefone

Houve uma época em que eu chamava qualquer pessoa para uma entrevista presencial. Basicamente só entrevistava por telefone pessoas de outros estados, mas sempre que possível preferia entrevistar ao vivo porque sempre achei que uma conversa “olho no olho” é muito melhor para conhecer as pessoas. De fato isso é verdade, porém o que acontece é que em geral você recebe uma dezena de currículos e fica muito difícil entrevistar todo mundo. Pior ainda é que muitas vezes o candidato tem um currículo excelente mas na hora da entrevista você percebe que ele na verdade tem um currículo muito bem escrito e não passa disso, ou seja, você perdeu o seu tempo (e o candidato também).

Para resolver esses problemas hoje em dia eu entrevisto praticamente todas as pessoas por telefone. Depois de escolher as pessoas que quero conhecer, marco uma conversa de 30 minutos onde tento explorar conhecimento sobre tecnologias que usamos, valores, interesses pessoais e o mais importante: saber se essa pessoa é mesmo boa ou tem apenas um currículo bonito. Se você não tem idéia de como entrevistar pessoas por telefone, este artigo do Joel Spolsky é um bom começo para aprender.

Com essa abordagem consigo entrevistar um número significativamente maior de pessoas, primeiro porque é uma entrevista mais curta – portanto me sobra mais tempo -, segundo porque sendo por telefone dá para falar em horários mais alternativos – o que facilita a vida de todo mundo e aumenta o número de pessoas que podem participar imediatamente -, e terceiro porque isso diminui drasticamente o número de pessoas que são entrevistadas presencialmente. Deixe para entrevistar presencialmente somente as pessoas que você acha que realmente têm chance de participar do seu time.

Programe e discuta código com o candidato

Dá até vergonha de dizer, mas acredite, no passado (não muito distante) eu já contratei desenvolvedores sem ver uma linha do seu código. Mais vergonhoso ainda é saber que isso é uma prática extremamente comum no mercado. Já vi isso acontecer em inúmeras empresas de todos os tamanhos. O problema disso é que, uma vez que você contrata um desenvolvedor ruim, a trapalhada já está feita, não tem mais como voltar atrás. Você até pode demitir o cara e contratar outro, mas você vai ficar demitindo e contratando até achar alguém que te agrade? Além de ser uma abordagem bem ineficiente, acho que não é ético. Imagine que o profissional estava bem em uma determinada empresa e você o tirou de lá para trabalhar na sua equipe. Por culpa sua ele não só perdeu o emprego antigo como também perderá o novo (porque você não foi eficiente avaliando-o na entrevista).

Evite isso e dedique uma boa parte da sua entrevista a ver e discutir código com o seu candidato. Nesse último ano passei inclusive a pedir para que os cadidatos resolvessem problemas bem simples de programação como um caça-palavras ou um problema simples de criptografia. O objetivo é entender como o candidato organiza seu código, ver se ele escreve testes, saber se ele faz BDUF sem necessidade, se usa design patterns quando faz sentido e por aí vai. Quando o candidato passa por toda essa parte “remota” do processo de seleção, discutimos o código presencialmente e adicionamos algumas novas funcionalidades juntos para ver como ele funciona programando em par/time.

Muitos candidatos acabam desistindo de participar quando vêem que precisam mostrar código. Outros candidatos mandam código mas acabam não indo bem na entrevista presencial porque ficam nervosos de programar “em público”. Infelizmente nesse tipo de abordagem provavelmente teremos falsos negativos, por outro lado dificilmente teremos falsos positivos.

Analise sob vários pontos de vista

Já faz algum tempo que percebi que é muito útil fazer com que os candidatos sejam entrevistados por vários desenvolvedores do time. Nesses últimos três anos, poucas foram as vezes em que os cadidatos não foram entrevistados por pelo menos duas ou três pessoas. É muito útil poder discutir com outras pessoas do seu time sobre as entrevistas. Às vezes você achou o candidato bom, porém outras pessoas perceberam problemas que você não percebeu (e vice e versa). Ou então você ia esquecer de perguntar alguma coisa importante, mas o time que sempre participa junto das entrevistas acaba lembrando de perguntar. A melhor parte disso tudo é que é muito mais fácil errar tomando uma decisão desse tipo sozinho, então quando você está entrevistando em grupo e o time inteiro sai satisfeito de uma entrevista, a sensação de que você está tomando uma decisão certa sobre contratar alguém é muito maior.

Além disso é interessante que o candidato converse com pessoas de diferentes especialidades. Nesse último ano vários dos nossos candidatos conversaram não apenas com desenvolvedores mas também com pessoas de produto, especialistas de processo e por aí vai. Como são pessoas de especialidades bem diferentes, as perguntas que eles fazem são bem diferentes, o que te ajuda a analisar o candidato por vários ângulos.

Vasculhe seu candidato na Internet

Olhar o Github do candidato, Bitbucket e afins é o mínimo que você deve fazer. Eu pessoalmente gosto de olhar o LinkedIn, Facebook e Twitter também, para ter uma idéia do que a pessoa gosta, quem ela segue, o que ela fala e como se comporta. Por exemplo, há não muito tempo um candidato que me mandou currículo tinha escrito no Twitter uma frase bem chata reclamando do seu chefe, do tipo “meu chefe é um idiota”. O que eu espero de um profissional sério é que ele vá conversar com o seu chefe e resolva seus problemas. E se ele não conseguir e o chefe for realmente um idiota, peça demissão e trabalhe em outro lugar. É bem melhor do que ter uma atitude idiota em um lugar público onde todo mundo pode ver – incluindo o seu (ex) futuro chefe.

E por falar em atitudes idiotas…

“No asshole rule”

Existe até um livro sobre isso. Se você quer ser feliz, evite ao extremo contratar “assholes”. Comportamentos do tipo “eu sou mais inteligente que todo mundo e não preciso de ninguém para fazer meu trabalho além de mim mesmo, porque eu sou um rockstar e ninguém tem nada a me acrescentar” podem levar seu time para o buraco (o quase-trocadilho com “asshole” não foi intencional).

Sabe aquele tipo de ambiente onde a fofoca rola solta, com conversinhas venenosas de corredor, onde todo mundo tenta queimar todo mundo? Ou aqueles times onde, se você der sua opinião, alguém vai contrariar só por contrariar para tentar aparecer? Ou então aquelas pessoas que arrumam confusão gratuitamente? Se você não quer ter esse tipo de problema na sua empresa (e eu acho que ninguém quer), o primeiro e melhor passo que você pode dar é tentar ao máximo possível não contratar “assholes”. Mesmo que o cara seja muito bom tecnicamente, na minha experiência é melhor ter um cara “menos bom” mas que trabalhe em equipe, seja construtivo, empolgado e confiável.

Se não for o candidato certo, não contrate

Se o candidato não é a pessoa 100% certa para o seu time, então não contrate. Em alguns casos você vai encontrar candidatos que são quase ideais e pode ser difícil resistir à tentação – porque em muitos casos são problemas que você acha que pode consertar. O problema é que às vezes (como já aconteceu comigo) as pessoas não estão dispostas a mudar e sua vida pode se tornar bem difícil. Hoje em dia prefiro entrevistar mais uma dezena de pessoas e demorar mais um mês para contratar (ou até não contratar) do que correr o risco de errar.

Uma pergunta interessante que você pode se fazer é: Se você estivesse contratando alguém para a SUA startup, você contrataria essa pessoa? Aliás, recomendo a leitura desse artigo do Steve Yegge na íntegra.

E você, o que aprendeu nos seus processos seletivos?

Categories
Etc.

Que ferramentas você vai usar na hora de programar?

Há uns dois meses estava eu numa madrugada típica brincado de escrever códigos aleatórios, dessa vez usando o Google App Engine. Num determinado momento (acho que eu estava testando o versionamento de deploys – que é lindo demais) fiquei tão empolgado que soltei um daqueles posts meio aleatórios no Twitter dizendo: Google App Engine kicks serious ass!. Muita gente estranhou, incluindo o meu amigo Rodrigo Kumpera que prontamente respondeu: @gchapiewski I thought you used to work for yahoo!.

O mesmo “fenômeno” aconteceu no Yahoo! Open Hack Day que fizemos em São Paulo em março. Muitas pessoas acharam estranho e ficaram abismadas pelo fato do Yahoo! e seus funcionários mostrarem hacks que faziam uso de Google Maps, Twitter, Facebook e outros produtos que não são do Yahoo!.

Vamos lá, qual o problema? Sério mesmo, qual o problema? 🙂 Agora que eu trabalho no Yahoo! tenho que usar Y! Mail ao invés de Gmail? Ou então tenho que programar usando apenas YUI ao invés de jQuery? A política do Yahoo! é muito simples e na minha opinião bem coerente: a Internet está cheia de serviços excelentes e nós também temos alguns ótimos serviços. Porque não combinar o que há de melhor e fazer uma coisa melhor ainda?

Sempre falo isso e já até me falaram que parece meio “piegas”, mas é a pura verdade (e nunca é demais repetir): use a melhor ferramenta para resolver cada problema!

Esse modo de pensar é bem difícil nesse mercado. Muita gente acha que linguagens e tecnologias são como religiões, mas não é o que eu acredito. Não me importo de usar Java se for a melhor opção para resolver meus problemas – apesar de adorar programar em Ruby. Ou de aprender uma nova linguagem/ferramenta se ela se mostrar melhor para resolver alguma coisa (como quando eu precisei aprender ActionScript para fazer coisas legais para o Globo Vídeos – apesar de eu nunca ter tido simpatia por Flash).

Para pessoas da nossa área, acredito em um posicionamento profissional baseado em fatos e dados, não em preferências, traumas ou qualquer outro argumento sem lógica. No caso que comecei a contar no início desse post, eu estava programando um webservice REST em Python e o Google App Engine é o melhor lugar para ele estar hospedado. Aliás, eu usei Python já pensando em fazer o deploy lá, porque é super simples de usar, funciona muito bem e vai me liberar mais rápido para fazer outras coisas interessantes. É óbvio que todos temos nossas preferências de linguagens e tecnologias, mas o papel de um profissional é ser pragmático é fazer o que for mais adequado para cada situação.

Sempre que você está programando você precisa atingir um objetivo. Como eu ouvi falar esses dias, você “não senta e começa a programar igual a um cavalo”, você está desenvolvendo um produto ou alguma coisa maior e precisa ter isso em mente o tempo inteiro. Seu objetivo é entregar um software de qualidade, performático, bem testado, manutenível e que atenda ao seu cliente/objetivo. O seu objetivo não é usar as ferramentas da sua empresa ou as tecnologias que você gosta. Pense nisso.

Categories
Eventos

O Open Hack Day BR 2010 foi sensacional!!!

O Yahoo! Open Hack Day Brasil 2010 foi sensacional! Não tenho palavras para descrever o quanto fiquei feliz ao ver a quantidade enorme de feedbacks positivos que tivemos sobre o evento. Foram três meses de muito trabalho para organizar todos os detalhes e estou imensamente feliz que deu tudo certo!

Yahoo! Open Hack Day Brasil 2010
Foto: Hackers no Senac para o Open Hack Day 2010

O evento começou uma semana antes com a comunidade brasileira de desenvolvedores mostrando sua força! Os Yahoos gringos ficaram assustados com o tamanho da movimentação dos hackers no nosso wiki interagindo e formando times. Mais um exemplo disso foi quando o Eduardo Otubo (@otubo, que inclusive foi o ganhador de uma das categorias) teve a excelente idéia de criar um canal no IRC (#brhackday no Freenode) onde o pessoal começou a trocar idéias antes mesmo do fim de semana.

Quando o evento começou tivemos alguns pequenos problemas de conexão com a Internet mas graças ao feedback dos hackers e ação instantânea do nosso time conseguimos resolver tudo bem rápido. Aliás, passei 36 horas lendo o Meme, Twitter, IRC, circulando e lendo nosso quadro de feedback para garantir que todos estavam tendo seus problemas resolvidos e que tinham as melhores condições possíveis para programar. Eu diria que o destaque foi quando começamos a ser bloqueados pela API do Twitter (porque todos estavam saindo pelo mesmo IP e chegamos rápido ao limite de 150 requests/hora) e o Cody Simms (@cody) rapidamente ligou para nossos amigos do Twitter, que aumentaram generosamente o limite permitido para o nosso IP!

O resultado foi que tivemos hacks incríveis e de altíssima qualidade. O Christian Heilmann (@codepo8) – que assim como o Cody (e o Anil) veio ao Brasil especialmente para participar do Open Hack Day – acabou de escrever um post no blog do Yahoo! Developer Network (YDN) sobre as categorias de prêmios e seus ganhadores:

  • Hack “Keep it local”: “PlaceHacker” por Maurício Maia – uma cópia do Yahoo! Placemaker que funciona com maior precisão no Brasil e com registros em português.
  • Melhor Hack com o Meme: “SlideMeme” por Carlos Duarte do Nascimento e Vanessa Sabino – um hack para postar apresentações do Slideshare no Yahoo! Meme, convertendo as apresentações para GIFs animadas.
  • Melhor hack com YQL: “Gas Finder” por Eduardo Otubo e Luciano Camilo – uma colaboração (na verdade apresentada em dois hacks separados) que criou uma tabela YQL com os preços de gasolina em São Paulo e uma aplicação em Android que te leva para o posto de gasolina mais barato próximo de você.
  • Hack de melhor utilidade pública:: “Infraero BR parser” por Danilo Bento – um conversor e API que permite encontrar rapidamente várias informações de vôos e aeroportos do Brasil.
  • Melhor hack com YAP: “filmes.cc” por David Ruiz e Ricardo Felipe Noronha Martins – uma aplicação com YAP que mostra os horários de cinemas no Brasil e permite convidar amigos para ir com você
  • Melhor hack escolhido pelos hackers e vencedor geral (sim, os hackers e os juízes concordaram): “F1 Results” por Daniel Rodrigues da Costa Filho, Fabio Dan Dias Cardoso e Iraê de Carvalho Brasil – uma visualização incrível dos resultados históricos da Fórmula 1 baseados na Ergast API e usando Canvas, CSS3 e HTML5 para fazer uma ótima interface rica.

Todos os hackers campeões ganharam uma mochila de notebook personalizada do Yahoo! Open Hack, um iPod Touch e o nosso respeito!

Ganhadores do Yahoo! Open Hack Day Brasil 2010
Foto: ganhadores do Yahoo! Open Hack Day Brasil 2010

Veja as fotos no nosso grupo do Flickr e mais posts sobre o evento na página de notícias do nosso wiki. Veja também a lista dos 48 hacks submetidos no Hack.Trackr e o nosso Delicious para alguns links interessantes.

Mais uma vez um obrigado especial para os meus queridos Anil Patel (@anilpatel) e Mayra Attuy (@mayra_attuy) que passaram os últimos três meses comigo ajustando cada detalhe desse evento. Obrigado também a toda equipe do Yahoo! Brasil – em especial Pedro Valente (@pedrovalente) e Antonio Carlos Silveira (@acarlos1000) que ajudaram MUITO – e a todos vocês hackers por terem vindo e hackeado por 24 horas sem parar criando projetos inspiradores, fazendo deste evento um grande sucesso!

Nos vemos no próximo Open Hack Day, aguardem notícias! 🙂

Categories
Eventos

Vem aí o Yahoo! Brasil Open Hack Day 2010!

Dando início às atividades de 2010 (Já estava na hora), estamos organizando o Yahoo! Brasil Open Hack Day que acontecerá nos dias 20 e 21 de março de 2010 no Centro Universitário Senac (Campus Santo Amaro).

Vencedores da Categoria "What the hack was that"

Esta será a segunda edição do evento no Brasil, que também já acontenceu em Sunnyvale, Londres, Bangalore e Taiwan. A última edição no Brasil foi em novembro de 2008 e foi um sucesso enorme; com aproximadamente 200 participantes e uma porção de hacks interessantes!

Serão 24 horas sem parar de hacking, aprendizado, diversão e a oportunidade de conhecer outros hackers! O Yahoo! vai patrocinar comida, bebida e tudo mais que os hackers precisarão para ficarem confortáveis, felizes e liberarem sua criatividade! Haverá também um espaço pra dormir caso alguém queira tirar uma soneca.

No último Hack Day (que eu infelizmente não estava presente) houve hacks muito legais, de aplicações móveis a hacks de hardware. Por exemplo, os ganhadores da categoria “What the Hack” usaram Python, Flickr, Twitter e alguns pedaços de hardware para construir uma placa com LEDs que piscavam mais ou menos dependendo do número de fotos no Flickr e posts no Twitter com a tag oficial do Hack Day.

Também houve um hack super criativo sem código (como assim?!?!), que inclusive acabou obrigando que uma nova categoria fosse criada – “Using the environment Hack”:


Vamos juntos criar novos aplicativos usando as plataformas abertas do Yahoo! como YQL, YAP, Meme, YUI3, Pipes, Flickr e, é claro, quaisquer outras ferramentas de desenvolvimento abertas que você quiser usar. Os melhores hackers ganharão um prêmio e o direito de serem vangloriados até o fim dos tempos ou o próximo Hack Day, o que quer que aconteça primeiro. 🙂

As inscrições são limitadas, portanto corra e faça logo a sua em http://hackday.com.br! Caso tenha alguma dúvida entre em contato pelo e-mail openhackbrazil@yahoo-inc.com.

Está aberta a temporada de hacking no Brasil!

Categories
Carreira Notícias

Yahoo! procura Ninjas

Estamos procurando Desenvolvedores e Scrum Masters Ninjas para integrarem nossa equipe no Yahoo!

Nosso time é o que chamamos de “Innovation Cell”, que é algo como uma incubadora de projetos, responsável por pesquisar e criar novos produtos. Atualmente nosso carro-chefe é o Yahoo! Meme, que foi inteiramente desenvolvido no Brasil no último ano e já está em vários outros países como Indonésia, Filipinas, México, Argentina e Taiwan.

Desenvolvedor Ninja

Os Desenvolvedores Ninja serão responsáveis pelo desenvolvimento e manutenção de aplicações web, em especial o Yahoo! Meme e outros aplicativos de integração com redes sociais. É imprescindível ser faixa preta em Python, PHP ou JavaScript e conhecer bem pelo menos uma segunda outra dessas três. Mesmo sendo essas as principais linguagens que usamos por aqui, precisamos de desenvolvedores multidisciplinares que saibam usar diferentes tipos de ferramentas – porque nunca sabemos quais produtos virão no futuro e que tipos de vantagens poderemos ter usando ferramentas diferentes.

Tão ou mais importante do que isso é ter ótimos conhecimentos sobre desenvolvimento ágil e ser capaz de trabalhar com TDD, entender sobre CI e a sua importância, automatização de rotinas/build/etc., melhores práticas de desenvolvimento de software, Orientação à Objetos, Domain-Driven Design e tudo mais que puder ser relevante para ajudar a construir software confiável e manutenível de forma rápida e com ritmo/qualidade sustentável. Experiência com automatização de testes com Selenium ou Webdriver também é essencial.

Como desenvolvemos produtos de escala mundial, é necessário ter experiência com aplicações de alta performance e disponibilidade, identificação e otimização de gargalos de performance, escalabilidade, caching e sharding. É importante também ter bons conhecimentos de pelo menos um tipo de Unix e seus derivados.

Conhecimentos de OpenSocial, desenvolvimento de mashups, arquitetura de serviços e experiência com uso e desenvolvimento de APIs (REST, YQL, etc.) são diferenciais.

Scrum Master Ninja

O Scrum Master Ninja deverá ajudar o time de desenvolvimento a produzir no máximo da sua capacidade. Sua missão será organizar e facilitar os Sprint Plannings e Reviews, bem como Retrospectivas e o que mais for necessário para suportar os times de desenvolvimento e produto. Ele deverá identificar e remover impedimentos, ajudar o time a manter o foco mas dando todo o espaço e autonomia que ele precisa para se auto-organizar e gerenciar. É necessário já ter tido alguma experiência anterior relevante nesta posição.

Como o Yahoo! é uma empresa que em sua maioria ainda trabalha com métodos tradicionais de desenvolvimento, esta pessoa também será responsável por fazer com que o time esteja dentro das normas da empresa, gerando relatórios para as células de gerenciamento de projetos e fazendo algum trabalho burocrático de registro e comunicação de métricas.

Queremos um Scrum Master influente, que seja capaz de entender questões técnicas mesmo que em alto nível, que seja apaixonado por procurar maneiras de melhorar o processo de desenvolvimento, construtivo na hora de resolver problemas e solucionar conflitos e com muita vontade de descobrir novas maneiras de trabalhar com métodos ágeis. O Yahoo! é uma empresa que ainda está engatinhando em métodos ágeis e por isso precisamos de alguém com muita disposição e vontade de mudar a empresa!

Por último, experiência com XP, Lean Software Development, Kanban e diversos métodos ágeis são diferenciais.

Continuando…

Para ambas as posições é necessário inglês avançado, o que quer dizer que você deve ser capaz de conversar e ler/escrever em inglês sem problemas (e eventualmente ser entrevistado em inglês caso necessário).

Estamos procurando por pessoas criativas, que gostem de inovação, de pesquisar e identificar novas tendências e de encarar desafios complexos com agilidade e velocidade. Nosso time é pequeno, jovem e nosso ambiente está em constante mudança e evolução. Queremos pessoas irreverentes, que gostem de desafios, com idéias novas e com vontade de criar produtos incríveis!

A empresa oferece contratação apenas por CLT e benefícios como plano de saúde e ticket refeição. Estamos localizados na Vila Olímpia em São Paulo. Vamos dar preferência para pessoas de São Paulo mas também vamos olhar com carinho currículos de pessoas de fora e daremos auxílio para mudança caso necessário.

Se você se encaixa em algum destes perfis, mande seu curriculo em inglês para mim (gc AT yahoo-inc.com) com uma lista dos últimos 3 livros técnicos que leu. Não esqueça de colocar links para o seu Twitter, LinkedIn, GitHub e o que mais você achar relevante e que pode nos ajudar a te conhecer melhor. 🙂

Categories
Etc.

Top 200 blogs para desenvolvedores

Um post bem rapidinho. Essa notícia está um pouco atrasada mas continua boa. 🙂

Se você (assim como eu) gosta muito de ler blogs de desenvolvedores, provavelmente vai adorar isso: uma lista com os top 200 blogs para desenvolvedores selecionados por Jurgen Appelo.

A lista contém ótimos blogs de gente conhecida no mercado como Martin Fowler, James Shore, Jeff Sutherland, Joel Spolsky e por aí vai, além de blogs que eu ainda não conhecia e que são bem legais também. Para completar ainda tem o Twitter de uma boa parte dessas pessoas.

Mesmo que você não concorde com a lista e ache que tem coisa faltando ou sobrando, com certeza irá encontrar um monte de blogs interessantes para incrementar o seu leitor de RSS. Boa leitura!

Categories
Agile Eventos Python

[EDTED Florianópolis] Eu fui!

Nesse último sábado estive em Florianópolis participando do 14o. Encontro de Design e Tecnologia Digital (ou simplesmente #edted para os “Twitteiros”). O evento já passou pelo Rio de Janeiro e São Paulo e ainda vai passar por mais 6 cidades até o fim do ano (veja a programação).

Nas outras duas cidades percebí que minha apresentação ficou confusa porque fiz uma mistura de tecnologia com processo de desenvolvimento que eu senti que não deu muito certo. Então em Floripa decidi jogar todo o plano fora e fazer um totalmente novo, separando em duas apresentações.

Introdução a metodologias ágeis

Nessa apresentação tentei explicar metodologias de desenvolvimento ágil de software da forma mais simples e mais abrangente possível. Meu objetivo era fazer algo que pudesse servir tanto para quem nunca teve nenhum contato saber do que se trata como para quem já conhece aprender alguma coisa nova. Para isso eu fiz um paralelo com algumas historinhas e acabou virando uma apresentação bem humorada, despojada e (acredito eu) fácil de entender. Pelos comentários que li no Twitter parece que dessa vez “acertei a mão”. 🙂

No final falei de alguns livros para se aprofundar no assunto que foram:

Python Coding Dojo: O primeiro passo para se tornar um programador Python Samurai

Nos últimos meses tenho trabalhado bastante com Python e tenho gostado muito. Graças a isso e a confiança do pessoal da Arteccom no meu trabalho, resolvi fazer uma coisa bem diferente e um pouco ousada: tentar ensinar Python em apenas duas horas usando um formato de Coding Dojo! Essa apresentação foi uma cópia da minha apresentação no PythOnCampus, porém dei uma reduzida no conteúdo, adicionei uma breve introdução sobre Coding Dojo e troquei o formato para ter uma seção prática de programação.

Apesar de ter conseguido fazer uma boa introdução e passado bastante informações sobre a linguagem, é claro que o objetivo não era fazer com que as pessoas saissem de lá sabendo fazer tudo em Python. Elas apenas tiveram um primeiro contato com a linguagem, viram que não é nenhum bicho de 7 cabeças (muito pelo contrário) e ainda se divertiram programando em par no palco, fazendo TDD e resolvendo desafios de programação. Me surpreendi pela procura/interesse do pessoal e pelo feedback me parece que também deu certo.

De quebra também mostrei para o pessoal como funciona um Dojo, quais os objetivos e benefícios. É uma prática muito legal e muito fácil de fazer, qualquer um pode (e deveria) organizar um Dojo na sua empresa ou com seus amigos.

Para quem quiser saber mais sobre o que vimos:

Não vou disponibilizar os slides porque eles em sua maioria só tem um monte de fotos e palavras desconexas que não servem pra nada sem mim, são apenas um suporte para a apresentação. Além do mais, não quero fazer spoiler para o pessoal das outras cidades.

É isso aí pessoal, obrigado pela recepção calorosa e pelo bate papo! Nos vemos na próxima! 😉

Categories
Fun REST Ruby

Cadê meu Sedex?

Quem usa o serviço de Sedex e encomendas dos Correios sabe como é um saco entrar no site dos Correios para saber onde está sua encomenda. Como eu vendo e compro bastante coisa no Mercado Livre, há alguns anos desenvolvi um widget para Mac OS X que facilita buscar essas informações, mas acabei não usando muito porque não era prático o suficiente.

Na sexta-feira passada conversando com uns amigos tive a idéia de fazer um brincadeira no Twitter que poderia ser uma solução suficientemente prática: você digita no Twitter @cade_meu_sedex SO376590583BR” (usando o número da sua encomenda ao invés do meu, obviamente) e o macaco dos Correios diz pra você qual é o status mais recente disponível no site dos Correios. 🙂

cade_meu_sedex

Fazendo essa brincadeira acabei desenvolvendo uma API Ruby e de webservices REST para consulta ao site dos correios, que foi batizada com o misterioso nome de “correios-api”. Essa API já está disponível como uma RubyGem e no site do projeto tem instruções para instalação e uso.

Tanto o robô quanto a API foram desenvolvidos em Ruby e os códigos estão no meu Github para quem quiser dar uma olhada. No caso dos webservices foi especialmente ridículos fazê-los usando o Sinatra, que é um framework sensacional e absurdamente simples.

A próxima feature desse projeto será criar métodos para fazer orçamento de encomendas, que foi uma idéia dada pelo pessoal da lista Rails-BR. Se alguém tiver outras idéias ou quiser colaborar seja bem-vindo!

Categories
Engenharia de software Webservices

Arquitetura “pull” ou “push”: qual escala mais?

Apesar do que possa parecer, esse post não é sobre git. 🙂

Conversando com o Peleteiro esses dias ele me deu uma idéia interessante. Ia ser o máximo se houvesse um post automático no meu Twitter toda vez que eu ganhasse um achievement no Xbox! Os achievements são como se fossem medalhas: na medida que você vai jogando os jogos e passando de fase ou conquistando coisas, você vai ganhando mais pontos e mais medalhas. Resumindo, é totalmente inútil mas bem legal.

Como nos últimos tempos andei fazendo uma porção de robôs de Twitter para fazer uma porção de coisas, na mesma hora pensei em fazer mais um deles, que ficaria dando requests na API do Xbox Live até que aparecesse um novo achievement e então ele faria o post.

Na mesma hora me bateu a mesma sensação de ineficiência que tive quando fiz os outros robôs. Pra fazer essas coisas eu tenho que ficar fazendo polling no serviço de “n” em “n” minutos para saber das atualizações… Apesar de ser eficiente nao é lá muito eficaz.

Vou fazer uma brincadeira para mostrar o tamanho do problema. Somando só os robôs que fiz para a Globo.com, eu faço diariamente cerca de 72.000 requests para o Twitter (cerca de 25 robôs x 2 requests por minuto x 60 minutos x 24 horas). Ok, nem todo mundo faz robôs de Twitter, eu sei, mas vamos supor que uma pessoa em cada 100.000 faz robôs que nem eu. Isso significaria que só eu e mais uma pessoa fazemos isso no Brasil inteiro (o que não deve ser verdade, mas vamos continuar assim fazendo a conta por baixo). Então considerando que a população mundial é de quase 7 bilhões de pessoas, temos cerca de 70.000 pessoas fazendo o mesmo em todo o mundo. Sendo assim, pela minha conta de padaria o Twitter recebe algo em torno de 5,04 bilhões de requisições por dia, 210 milhões de requisições por hora, quase 60.000 requisições por segundo (só de robôs)!!!

Ok, o número deve ser bem diferente disso. O fato é que com certeza é muito alto.

Eu faço polling no Twitter para buscar por usuários que falaram uma determinada palavra (usando o RSS da busca do Twitter) e então adicioná-los. Funciona assim: quando uma pessoa escreve alguma coisa que eu estou procurando, eu adiciono ela como amigo(a). Apesar dessa quantidade imensa de buscas e requests, um robô adiciona apenas na faixa de 25 usuários por dia. Se houvesse alguma forma de saber que algum usuário escreveu alguma palavra que eu busco, nesse meu cenário só seria necessário fazer algo em torno de 625 requests por dia (menos de 1% da quantidade que eu faço).

O que eu estou propondo aqui não é nada novo. Além dos mecanismos tradicionais de polling (fazer “pull” de arquivos de tempos em tempos), estes tipos de serviços deveriam disponibilizar um mecanismo para o servidor avisar o cliente que alguma informação que ele deseja está disponível (“push”).

Depois da apresentação “Beyond REST? Building data services with XMPP” que rolou na OSCON 2008, o XMPP entrou na moda como uma possível solução para esse problema. Nessa arquitetura, os clientes se “inscrevem” em um serviço de mensagens instantâneas e mantém uma conexão aberta com o servidor para que, quando determinada informação estiver disponível, ela seja enviada ao cliente ao invés dele ter que ficar fazendo “polling”. Isso reduz consideravelmente a carga de requests recebida pela aplicação, mas é mais difícil de escalar para uma quantidade muito grande de usuários.

Uma solução que surgiu na nossa conversa foi um “pingback ao contrário”. Seria algo como o webhook do Github. Quando o usuário fizer um GET em um recurso, ele poderia mandar um header com uma URL, e quando houvesse alguma atualização do recurso o servidor poderia fazer um GET para esta URL com o objetivo de informar ao cliente que há informações novas disponíveis. Essa solução escala mais do que a primeira, mas tem um lado negativo: não funciona se o cliente não tiver um IP real disponível. No meu caso, por exemplo, que tenho robôs rodando no meu desktop da Globo.com (que não tem IP real), não seria possível usar esse tipo de serviço.

Também dá pra fazer algumas soluções mais criativas usando coisas que a princípio parecem esquisitas mas podem fazer sentido. Por exemplo, um servidor de e-mail como o Postfix poderia fazer esse trabalho com o pé nas costas. Quando o cliente acessasse um recurso, ele poderia informar em um header um e-mail para ser notificado quando houvesse atualização. É uma solução bem fácil de escalar e de fácil implementação – tanto pelo lado do cliente quanto do servidor – apesar de não ser muito comum.

Pelo que eu andei lendo o pessoal do Twitter já pensou nesse problema e para resolvê-lo criaram o Firehose, que é uma solução baseada em XMPP. Como eu falei, o problema não termina por aí – eles terão vários problemas novos para escalar XMPP para uma grande quantidade de usuários.

Enfim, esse problema é bem interessante… Na próxima oportunidade que tiver vou tentar fazer uma prova de conceito de todas essas opções para ver no que dá.

E para aqueles que ainda não entenderam, talvez fique um pouco mais claro agora: escalabilidade é muito mais uma questão de arquitetura de software e infra-estrutura do que de linguagens e frameworks.