Archive for January, 2008

Novo release do Globo Vídeos (agora em tela cheia)

Wednesday, January 30th, 2008

São 05:55 da manhã por aqui e acabamos de subir o primeiro release do Globo Vídeos de 2008. Essa versão é a primeira depois da mudança para Flash vídeo e nós corrigimos diversos detalhes de infraestrutura que ficaram pendentes em 2007. Fizemos bastante coisa, mas não vai dar para ver muita novidade.

Mesmo que esse release tenha sido praticamente só de coisas “internas”, não tivemos como deixar de fora uma das funcionalidades mais requisitadas: os vídeos em tela cheia! Muitos usuários sentiram falta dessa funcionalidade e cheguei até a receber aqui no blog comentários como: “a decisão de tirar a tela cheia merece o prêmio abacaxi da década”.

Acho que isso tudo merece uma explicação.

Tivemos que fazer isso porque estávamos correndo contra o tempo para colocar a infraestrutura de Flash vídeo antes do Big Brother. O BBB é um grande evento para os nossos servidores, eles trabalham um bocado nessa época. O consumo de vídeos aumenta muito e por isso é muito arriscado fazer qualquer mudança grande na infraestrutura neste período, porque se alguma coisa der errado, nossos usuários podem ficar sem ver vídeos (e nós definitivamente não queremos isso).

Como a mudança de Windows Media para Flash envolvia uma quantidade enorme de mudanças, só tínhamos duas opções: ou fazíamos a migração para Flash antes do BBB, ou esperávamos para fazer em abril de 2008, depois que o programa acabasse.

Só o trabalho de infra foi monstruosamente grande… Desde a captura de vídeos com mais qualidade, até a produção em um novo formato (flv) e distribuição dos vídeos usando dezenas servidores totalmente novos com softwares completamente diferentes dos anteriores. Como se isso tudo já não fosse suficiente, precisavamos mudar o player do Globo Vídeos e o player embedded que é usado por inúmeros sites da Globo.com, mantendo compatibilidade com alguns programas que ainda funcionam em Windows Media como os jogos da NBA, por exemplo.

Com tantas coisas pra fazer pela frente, nós tivemos que priorizar a implementação de tudo que era absolutamente necessário para o funcionamento dos novos vídeos em Flash. A tela cheia é uma funcionalidade importante? Sim, ela é muito importante. Só que mais importante que isso é tocar o vídeo. Para viabilizar o projeto, tivemos que tirar absolutamente todas as funcionalidades que não fossem impeditivas para o funcionamento dos novos vídeos. A princípio isso pode parecer ruim, mas nossas práticas com Scrum nos mostraram claramente que essa era a única forma de fazermos o player Flash acontecer.

Posso dizer que essa decisão não foi nem um pouco fácil, porque acabamos tirando uma funcionalidade dos usuários. Mas pode ter certeza que foi uma das coisas que viabilizou a migração dos vídeos para Flash ainda em 2007.

Ficamos sem a tela cheia por pouco mais do que 40 dias. Não foi muito tempo, mas sei que muita gente ficou chateada. Peço desculpas em nome da Globo.com, mas como vocês estão vendo, foi por uma boa causa. :)

Você tem que ler os livros!

Tuesday, January 22nd, 2008

Nos últimos meses já ouví algumas pessoas dizerem que não têm costume de ler livros, ou questionarem a necessidade de lê-los, já que há uma abundância de fontes de leitura por aí na Internet.

Hoje em dia realmente temos milhares de formas de nos informarmos. Me lembro de ter lido em algum lugar que a Internet possui mais de 250 milhões de sites. Se somarmos isso tudo, realmente tem muita informação. Justamente por isso, faz parte da minha rotina diária dar uma navegada no Google Reader, onde tenho cadastrados os feeds de mais de 300 sites e blogs de diversos assuntos que acho interessantes. Essa é basicamente a minha principal fonte de informação diária e é a melhor maneira de me manter atualizado com tantas novidades surgindo por aí todo dia.

Porém, em alguns casos, para aprender e entender certos assuntos, você precisa ler os livros. Não tem jeito! Por exemplo, como é que um desenvolvedor de software pode dizer que entende Domain-Driven Design sem ter lido o livro do Eric Evans ou pelo menos o DDD Quickly? Ou então dizer que sabe sobre metodologias ágeis sem ter lido pelo menos um livro do Ken Schwaber, Kent Beck ou Uncle Bob? Como é que alguém pode se dizer Arquiteto de Software Sênior++ Certified ™ sem ter visto o Patterns of Enterprise Application Architecture e o GoF? Eu respondo: não tem como. Simplesmente não tem jeito, você precisa ler os livros.

Hoje mesmo o Patrick Kua, que trabalha na ThoughtWorks, escreveu um post sobre os livros que ele considera essenciais para saber sobre metodologias ágeis. Ele acredita que você precisa ler 11 livros, O.N.Z.E. livros, para entender sobre o assunto, e ainda completa: “Of course, simply reading the books won’t mean that you’re an expert [...] though it’ll definitely help in providing context, advice or skills that you need to practice.”. Ou seja, mesmo lendo todos esses livros, ainda há muita coisa para aprender… E estamos falando sobre um assunto apenas.

Assim como os blogs e os sites, os livros são uma fonte de informação importantíssima e necessária. Se você quer trabalhar com tecnologia e desenvolvimento de software não tem jeito: tem que ler e ler muito!

Sobre Entrevistas (parte 2)

Monday, January 21st, 2008

O Phillip Calçado blogou há alguns meses sobre entrevistas e eu resolví agora fazer uma espécie de continuação. Depois daquele post já aconteceram dois processos seletivos aqui na equipe e tenho algumas coisas a acrescentar.

Com o passar do tempo e das entrevistas, acabamos aprendendo algumas coisas e já tínhamos algumas idéias para serem aplicadas, como o Phillip bem disse. Tiramos algumas idéias interessantes do Joel Spolsky, mas ainda não era o suficiente. Ainda estava faltando um formato definido para as entrevistas, um roteiro. É claro que as entrevistas têm que ser flexibilizadas de acordo com o seu andamento ou o candidato, mas eu particularmente ainda sentia falta de não termos um planejamento definido para as conversas. Muitas vezes o candidato ia embora e eu sentia que eu tinha ido muito mal na entrevista, o que era péssimo.

Depois de misturar algumas idéias de Scrum com coisas que eu lí no Peopleware e mais todas as experiências anteriores, fiz um roteiro para o nosso último processo seletivo que acabou funcionando bem melhor do que eu imaginava.

Vou tentar explicar um pouco melhor como funciona:

Etapa 1: Captando currículos.

Para captar currículos legais, tentamos escrever uma mensagem o mais clara possível do que estávamos procurando e com a cara da nossa equipe. O Phillip escreveu a primeira versão dessa mensagem e depois ao longo do tempo ela foi sendo ajustada. No final ficou mais ou menos assim.

É um pouco diferente do que se vê por aí mas explica com bastante detalhes o dia a dia do trabalho e mostra nosso clima descontraído e irreverente. Acho que o fato de passarmos emoções na mensagem faz com que algumas pessoas se identifiquem com a oportunidade mais facilmente (ou que a descartem logo de cara). O principal objetivo da mensagem era passar a seguinte idéia: venha trabalhar aqui porque é muito legal!

Etapa 2: Selecionando os currículos.

Fazer uma seleção curricular cuidadosa foi importante para conseguir selecionar os candidatos mais adequados e não perder muito tempo entrevistando pessoas que não se encaixavam no perfil requerido para a vaga.

Alguns currículos foram muito fáceis de descartar, porque os candidatos simplesmente não conseguiram atender a um único e simples pedido: não enviaram a relação dos 3 últimos livros que leram. Das duas uma: ou o candidato não leu nada (e nós não queremos gente que não lê), ou não leu a mensagem até o final (e pode ser um daqueles que envia currículo para todas as oportunidades do planeta, que nós também não queremos).

A lista dos 3 últimos livros lidos é muito interessante porque diz muito sobre os interesses e o nível técnico da pessoa. É tiro certo: os candidatos que leram os livros mais interessantes geralmente têm os currículos mais interessantes.

Etapa 3: Entrevista pessoal.

Na entrevista pessoal a estratégia era falar a menor quantidade de tempo possível. A justificativa é simples: você tem apenas alguns minutos para descobrir o máximo possível sobre a pessoa. Fazendo uma matemática simples, podemos concluir que quanto menos se fala mais o candidato tem oportunidade para falar.

Quando a entrevista já estava mais para a última metade eu começava com as perguntas mais técnicas e difíceis. Na medida do possível tentei perguntar detalhadamente sobre a maioria das coisas que foram colocadas no currículo, especialmente quando o currículo era recheado de siglas. Fiz questão de me assegurar de que aquilo não estava ali só para fazer volume. Acabei descobrindo que muita gente não sabe para que servem os Design Patterns que estão em seus currículos, que não sabem resolver problemas simples de arquitetura ou que não conhecem o básico sobre concorrência, sistemas operacionais, redes, protocolos, algorítmos, etc.

Nos minutos finais eu explicava detalhadamente como funciona a empresa, com o que a empresa trabalha e com que tipo de coisas o candidato iria se deparar. Uma vez tentei fazer isso no começo da entrevista mas percebí que isso fazia com que o candidato ficasse o tempo todo tentando falar coisas que ele achava que eu queria ouvir, então achei melhor continuar fazendo no final mesmo.

Etapa 4: Entrevista com a equipe.

Quem passou na entrevista pessoal chegou na etapa mais interessante do processo: a entrevista com a equipe de desenvolvimento. Por isso é tão importante fazer um bom filtro na fase anterior, porque a equipe tem mais o que fazer e eles não podem perder muito tempo. Todas as pessoas que foram para essa fase tinham plenas condições de trabalhar aqui, só precisavamos escolher as melhores. Basicamente a idéia dessa fase é que não há ninguém melhor do que as pessoas que fazem o trabalho para avaliar se alguém também está apto para fazê-lo.

Nesta etapa estabeleciamos um timebox (de 30 a 40 minutos) para que aqueles candidatos que gostam de falar demais saibam que eles tem tempo curto e que devem ser breves e objetivos. As perguntas não eram planejadas e a equipe perguntava sobre o que vinha na cabeça.

Nos primeiros 15 minutos fazíamos perguntas mais abstratas como “o que você sabe sobre x” ou “conte sobre sua experiência com y” e por aí vai. A partir daí a equipe ia pegando “ganchos” no que o candidato ia falando e as perguntas iam fluindo. Como tinham muitas pessoas na sala e todos queriam perguntar, tivemos que usar uma bola para organizar quem ia falar. Quem estava com a bola estava no comando e quem não estava ficava calado e escutava.

Nos últimos 15 minutos fazíamos as perguntas cascudas. Normalmente pegávamos situações do nosso dia a dia e criávamos problemas para as pessoas resolverem. Perguntamos sobre problemas de concorrência, arquitetura da JVM, arquitetura de sistemas de cache, algorítmos e por aí vai. As perguntas eram bem pesadas e o clima geralmente ficava bem tenso, mas o intuito era esse mesmo. Muitas pessoas que tinham ido muito bem na etapa individual travaram completamente quando ficaram sob pressão.

No final, para descontrair, falávamos várias bobagens e fazíamos perguntas sociais: tipos de música preferidos, hobbies, time que torce, se é casado, tem filhos, piadas nerds diversas e coisas do tipo.

Etapa 5: Escolhendo o candidato.

Depois da equipe entrevistar todos os candidatos fizemos um debate para escolher quem seria selecionado. Todas as pessoas opinaram e escolhemos juntos quem entrou. Essa idéia veio do Scrum, onde o time toma as decisões em conjunto de tudo que é feito. Isso é bom por dois motivos. O primeiro é que várias cabeças pensam melhor que uma. Se todas as pessoas gostam de alguém e só eu que não gosto, o problema possivelmente está comigo. No fim das contas eu acabo me previnindo de fazer alguma besteira e escolher a pessoa errada. O segundo motivo é que como todos concordaram em escolher um determimnado candidato, ninguém pode ser culpado posteriormente por ter feito a escolha errada. Se errarmos, erramos todos juntos (o que é bem mais difícil de acontecer).

Esses debates foram muito engraçados porque o pessoal acabava comprando a briga de um ou outro candidato e virava um mega flame war. Nos casos em que todo mundo concordava, era maravilhoso, porque era a certeza absoluta que o candidato era o certo. Em compensação, quando ninguém entrava em acordo, era 458 mil vezes mais difícil de resolver. Quando isso acontecia, todo mundo dava sua opinião (eu inclusive) e tentávamos fazer com que alguém mudasse de idéia. Por sorte temos um número ímpar de pessoas na equipe e dava pra desempatar. Quando ninguém entrava em acordo e ficávamos empatados e totalmente travados, eu acabava dando o voto de desempate.

Etapa 6: Entrevista final com o gerente.

Depois dos candidatos serem escolhidos pelo “comitê” eles foram para uma última entrevista comigo e o gerente da área. Essa etapa foi a mais tranquila de todas porque as pessoas que chegaram até ela já tinham recebido a certificação de capacidade técnica pela equipe, então as perguntas foram muito mais sobre questões sociais, objetivos de vida, profissionais e por aí vai. Basicamente é a entrevista para o candidato ser abençoado e o martelo ser batido.

Não sou nenhum especialista em recursos humanos e nem em recrutamento, mas esse processo me parece que funciona bem. Estou satisfeito com as pessoas que contratamos e contente por termos achado uma forma mais divertida e eficaz de selecionar pessoas.

Um beijinho no Big Brother vira um furacão!

Thursday, January 10th, 2008

Hoje de manhã tivemos uma quantidade absurda de acessos aqui na Globo.com por conta de um simples beijinho que rolou no Big Brother Brasil 8. No segundo dia de BBB, já batemos o recorde do programa do ano passado inteiro, que foi de 8 Gigabits de consumo de banda simultâneo!

O melhor de tudo foi que o Globo Vídeos aguentou firme e forte! Foi muita coincidência ter acontecido isso porque há menos de dois dias eu escreví um post sobre a necessidade constante de nos preocuparmos com otimizações o tempo todo, antes mesmo de começar a desenvolver. Felizmente estávamos preparados para essa pancada, afinal de contas todo ano damos um duro danado para ajudar a fazer com que o BBB aconteça sem problemas.

Esse ano promete… Com certeza vamos bater todos os recordes de consumo de banda da história da Globo.com e do Brasil!

E que venham as provas de resistência! :)

A falácia da otimização prematura

Tuesday, January 8th, 2008

“A otimização prematura é a raiz de todo o mal”. Quantas vezes você já ouviu essa frase? Eu mesmo já disse isso aqui nesse mesmo blog e já falei essa frase para várias outras pessoas. O problema, como já apontavam os sábios budistas, é que as pessoas acabam levando as coisas ao extremo… Para alguns desenvolvedores, como a otimização é a raiz de todo o mal ela deve ser evitada a qualquer custo e ao longo dos anos o sentido da frase acabou virando simplesmente “nunca otimize seu código”.

O criador dessa frase famosa foi Tony Hoare e Donald Knuth foi o responsável por torná-la popular. O que as pessoas não param para pensar é que quando essa frase foi dita, em 1975, o contexto era completamente diferente. O que Hoare e Knuth estavam realmente falando é que os engenheiros de software da época deveriam se preocupar com outras coisas mais importantes (como um bom design de algorítmos e boas implementações desses algorítmos) antes de se preocupar com micro-otimizações como a quantidade de ciclos de CPU que um determinado comando consome. A história toda é bem interessante e recomendo a leitura completa.

Hoje em dia os tipos de software que desenvolvemos são completamente diferentes. A capacidade computacional das máquinas é diferente, as arquiteturas dos sistemas, a quantidade de usuários… Temos bancos inteiros totalmente computadorizados com milhões de transações simultâneas acontecendo e essas trasações não podem falhar ou alguém perde dinheiro em algum lugar. Temos sistemas na internet que suportam milhões de usuários trocando mensagens o tempo todo. Enfim, precisamos considerar aspectos bem diferentes.

Eoin Woods, membro da IASA, publicou um artigo sobre o que ele acredita que sejam os 10 maiores erros de arquitetura cometidos em projetos. O item número 7 é “Assumir requisitos de performance e escalabilidade”. Ele acredita que você deve começar a considerar aspectos de performance e escalabilidade desde cedo porque isso ajudará a aumentar a sua confiança de que não há nenhum bicho de sete cabeças que na última hora vai arruinar qualquer possibilidade da sua aplicação ir para produção. Os requisitos de performance de uma aplicação devem ser conhecidos, estudados e levados em consideração desde o início do desenvolvimento.

Robert Annet do Coding The Architecture cita um outro exemplo do que pode acontecer quando você assume certas informações erradas no desenvolvimento. Ele também conclui que todos os desenvolvedores devem sempre estar cientes da arquitetura de um sistema e como isso afeta o que está sendo desenvolvido. Faz muita diferença, por exempo, se uma aplicação rodará em cluster ou não.

Resumindo, eu discordo de quem diga que um software não deve ser otimizado antes mesmo de ser desenvolvido. Há casos e casos. Veja a minha situação: quando eu desenvolvo sistemas na Globo.com, como é que eu posso ignorar o fato de que o sistema será acessado por milhões de usuários? No nosso último projeto, por exemplo, uma das premissas era que o player de vídeos fosse ultra-compacto (menor quantidade de bytes possível) já que ele seria baixado por qualquer usuário que fosse ver o vídeo e não poderia afetar o carregamento da página. Se não fosse isso poderíamos acabar tendo um daqueles arquivos Flash de 2 MB que quando você acessa a página tem que esperar 2 minutos para carregar – a experiência do usuário fica um lixo.

Porém também acho que temos que tomar cuidado para não exagerar na dose. Otimizações são boas quando elas são realmente necessárias.

Já cansei de ver desenvolvedores sacrificarem o design de uma aplicação por causa de performance ou otimizações que eram completamente desnecessárias. Quando você tem requisitos de performance claros como os que eu citei acima é óbvio que você tem que levá-los em consideração. Mas a grande maioria das aplicações certamente não atende milhões de usuários nem se você somar 10 anos de acesso! Então o que acaba acontecendo é que ao invés de se preocupar com desenvolver software de qualidade, bem testado, modular e com design decente muita gente acaba desenvolvendo software desnecessariamente otimizado e difícil de entender e modificar. A não ser que você tenha requisitos não-funcionais bem claros e definidos a prioridade sempre deve ser por um bom design, código legível, extensível e esse tipo de coisa.

Otimizar cedo ou não, sempre vai ser um assunto controverso. Normalmente esse tipo de coisa envolve julgar uma série de fatores técnicos e de negócio. Concluindo, é essencial que a equipe de desenvolvimento tenha bom senso ao tomar essas decisões. Nunca otimizar ou sempre otimizar são abordagens completamente equivocadas. Como dizem os budistas, “prefira sempre o caminho do meio”.