Bruno Pereira

Depois de mais de 2 anos e meio, hoje é o meu último dia alocado na Globo.com. A partir de segunda-feira (01/12) já estarei alocado em um novo projeto, também nas Organizações Globo, mas desta vez na Globosat.

Eu levarei várias boas lembranças, de um período que foi muito positivo para mim. Comparando a minha experiência e maturidade agora com o momento em que entrei na Globo, a diferença é enorme. Tive a oportunidade de trabalhar com profissionais de altíssimo nível e em projetos de enorme importância técnica e de negócio. Tive também a sorte de atuar em áreas com as quais tenho muita afinidade e interesse, o que ajuda bastante no envolvimento de qualquer profissional.

Quando cheguei à Globo pude vivenciar uma situação nova para mim. Passei a ter a satisfação de ir trabalhar feliz todos os dias. Atuando em um ótimo ambiente de trabalho no qual o software fica em primeiro plano. Com o benefício extra de saber que meu trabalho teria a visibilidade do maior portal de internet da América Latina.

Além disso, posso dizer que vivi muitos progressos dentro da empresa. Acompanhei o surgimento de produtos como o G1, o 8P, o Futpedia e o Musas, além de um progresso fantástico na plataforma de Vídeos. Acompanhei de perto a produção interna para eventos como a Copa de 2006 e as Olimpíadas de Pequim. Poder vivenciar esse crescimento da empresa foi muito interessante.

Também me deixou muito feliz a abordagem da Globo.com em relação a Open Source. Quando cheguei na empresa, todo mundo usava Windows, o servidor de aplicações mais usado era o Weblogic e embora já existisse o uso de muitos softwares open source, isso não fazia parte da cultura da empresa.

Hoje em dia a relação da Globo com Open Source é excelente. Todos apostam no uso de Open Source, os desenvolvedores todos usam Linux, nossos servidores de aplicação são quase todos Open Source, já há vários projetos com banco de dados open source, e a maturidade dos profissionais em relação a Open Source aumentou muito. Pra mim isso foi muito gratificante. Durante mais de 1 ano e meio eu tive a satisfação de trabalhar full time com Linux, e acredito que consegui contribuir um pouco também para que outros utilizassem de forma produtiva.

Ainda mais importante do que a relação com open source foi a adoção de metodologias ágeis. Quando cheguei na Globo.com a maioria dos projetos era no estilo Waterfall. Não é necessário explicar com detalhes aqui, mas era muito perceptível que os projetos não andavam na velocidade que poderiam.

Aos poucos o Scrum começou a ser utilizado, e alguns meses depois isso desencadeou uma série de mudanças positivas na empresa. Este ano inteiro eu trabalhei em um time Scrum, e foi uma experiência excelente. Passamos a ter uma equipe multi-disciplinar, tendo contato diário com um designer, com um arquiteto de informação e um desenvolvedor client-side. Isso foi muito benéfico para mim. Acompanhar de perto o trabalho de profissionais de outra especialidade me ensinou muito sobre a atuação deles, e claro, aprendi muito sobre client-side e passei a gostar disso, o que é fundamental para qualquer desenvolvedor web.

Ao longo do ano nós amadurecemos muito a nossa forma de trabalho, e a utilização de práticas ágeis foi fundamental nisso. Claro que ainda existem arestas a serem aparadas e pontos que precisamos melhorar, mas sem dúvida nosso time evoluiu muito esse ano.

Tecnicamente o ano foi muito bom para mim também. Participei de projetos muito interessantes como a migração para o e-mail no Google, onde atuei diretamente na integração entre as empresas. Outros projetos muito bacanas foram o novo cadastro e a nova Central do Usuário.

O projeto de integração com o Google foi o primeiro projeto crítico no qual utilizamos REST, e como tivemos muito sucesso, todas as nossas aplicações já estão usando REST, e falta mais um pouquinho só para que nossa arquitetura seja 100% migrada de comunicações via EJB para REST. Aprendi muuuuuuuito nesse processo, foi uma experiência excelente.

Os projetos do Cadastro e da Central foram muito interessantes do ponto de vista de produto e do ponto de vista de desenvolvimento. As 2 aplicações foram desenhadas para terem módulos dinâmicos de cadastro. Isso permite que cada produto tenha o seu próprio template de cadastro, e as informações requisitadas dos usuários são configuradas por uma ferramenta de administração.

O desenvolvimento destas aplicações exigiu um trabalho muito interessante de modelagem e desenvolvimento, com muitas refatorações até que chegássemos no modelo final. Aprendi muito também com esses dois projetos.

Mas nem só de software vive uma pessoa :)  Nesse meu período na Globo.com eu conheci muitas pessoas fantásticas e fiz muitos amigos. O ambiente de trabalho e as pessoas da Globo.com são um dos maiores motivos para que tenha sido tão legal trabalhar na empresa, e com certeza vou sempre me lembrar disso.

Meu time de desenvolvimento esse ano é muito bem entrosado e positivo. Tacaram na mesma mistura 2 cariocas, 1 capixaba, 1 prudentino e 1 paraense, e deu muito certo Gostei muito da experiência, e vou com certeza sentir falta desses picaretas

Estou indo agora para um novo projeto na Concrete, atuando na Globosat. O pouco que sei do projeto até agora me pareceu muito interessante, e essa mudança de cliente é fundamental para as minhas perspectivas dentro da empresa. Torço muito para essa minha nova empreitada seja tão interessante e produtiva como meu período dentro da Globo.com, e claro, espero contribuir bastante para o sucesso da Concrete em um novo cliente e novo projeto.

No final das contas, sinceramente espero que eu tenha contribuído tanto com a Globo.com quanto ela contribuiu para a minha carreira e o meu amadurecimento. Foram 2 anos e meio sensacionais e tenho certeza de que a empresa continuará no seu caminho de enorme sucesso, que pude acompanhar neste período.

Chegou então o momento de dizer Adeus Globo.com, foi um grande prazer para mim!

Li hoje um post do Dare Obasanjo que me chamou a atenção por mostrar como a web é mesmo um quintal aberto, onde nossas informações pessoais ficam cada vez mais expostas a qualquer um que queira mesmo procurar.

Recentemente a senha do e-mail pessoal de Sarah Palin no Yahoo foi roubada, e o suposto responsável mandou e-mails para algumas listas, dizendo como conseguiu fazer isso com facilidade. Sarah Palin é a atual governadora do Alaska, e candidata a vice-presidente dos Estados Unidos, na chapa de John McCain.

Segundo o hacker, no processo de recuperação de senha do Yahoo foram feitas algumas perguntas pessoais da governadora, mas o hacker foi capaz de obter TODAS as informações solicitadas com alguma facilidade na internet, em diferentes locais.

Isso mostrou que a funcionalidade de recuperação de senha da maioria dos sites é inadequada, por ser insuficientemente segura. Dare Obasanjo sugeriu uma alternativa simples - que provavelmente muitos de nós já havia pensado - que é permitir ao usuário que cadastre sua própria pergunta secreta, em vez de utilizar uma das poucas perguntas oferecidas pelos sites.

Bom, felizmente meu time é responsável pelo cadastro de usuários na Globo.com e muito em breve faremos uma nova Central de Relacionamento. Dentro das modificações a serem feitas está um novo processo de recuperação de senha, no qual certamente faremos algo melhor do que há hoje.  Atualmente também utilizamos um conjunto limitado de perguntas pré-cadastradas, mas vou fazer todo o possível para convencer nosso PO de que precisamos de algo melhor que isso

Em Setembro acontece o aniversário do CEJUG e eu fui honrado com um convite do Rafael para me apresentar no evento comemorativo da data.

Fiquei muito contente com esta oportunidade e aproveito para agradecer ao Rafael, às empresas patrocinadoras do evento e à Concrete pelo apoio que estão me dando neste evento.

Eu me juntei ao CEJUG alguns meses atrás, depois de perceber o excelente nível do grupo e a vibrante comunidade de Java que existe no Ceará. Inúmeras vezes já elogiei o nível de envolvimento dos membros do grupo e o valor das discussões sobre software que rolam por lá. Me sinto bastante satisfeito por participar do grupo e trocar idéias e experiências com o pessoal.

Finalmente surgiu a oportunidade de conhecer a rapaziada da terra da tapioca e também a sua bela cidade. Estou certo de que a minha estadia por aí será muito agradável e aguardo ansiosamente por esta ocasião.

Neste evento eu farei uma apresentação sobre web services REST, mas um pouco modificada em relação às outras que já fiz sobre o assunto. Nesta apresentação falarei um pouco mais sobre como estamos utilizando REST no meu time para servir a requisições Ajax com JSON.

Meu time é responsável pelos sistemas de cadastro, autenticação e autorização de usuários da Globo.com e nós usamos REST para integrações Server x Server e também para comunicações Ajax com os clientes consumindo conteúdo JSON.

Além do meu time, a Globo.com já usa REST no Globo Vídeos e na nova plataforma de publicação de conteúdo do Portal.

Espero que o pessoal goste da apresentação e que minha ida ao evento seja tão proveitosa para vocês como para mim. Ah, e haja tapioca!

Minha primeira semana após as férias foi do jeito ideal para recuperar o ritmo de trabalho: cheia de emoções

Com subidas para produção durante o dia e longas noites de preparação para o fim de semana, consegui rapidamente trocar na minha cabeça o contexto das férias para a rotina de trabalho. No sábado às 23:30 cheguei à empresa para começar a janela de subida do novo e-mail da Globo.com. Fui sair de lá só no domingo ao meio-dia, mas foi uma janela bem sucedida e sem sustos, embora bem trabalhosa.

Este projeto se alongou bastante muito mais por questões comerciais do que questões técnicas, e foi ótimo finalmente colocá-lo no ar.

O projeto de migração de e-mail foi provavelmente o mais crítico que já trabalhei, pois estávamos lidando com uma grande massa de usuários e uma gigantesca massa de e-mails, o que trouxe alguns desafios interessantes. A parte do projeto que era a minha principal responsabilidade era a integração das nossas aplicações com os serviços do novo provedor de e-mails.

Nesta integração, usamos REST na comunicação entre aplicações desenvolvidas por nós e também para comunicação entre a Globo.com e o novo provedor de e-mail. Todos gostamos bastante dos resultados dessa forma de comunicação e cada vez mais nossas aplicações estão seguindo por esse caminho. Por questões de priorização do Product Owner, é claro que as melhorias técnicas muitas vezes têm que ser adiadas, mas estamos progressivamente refinando nossa arquitetura e usando cada vez menos as comunicações EJB legadas e cada vez mais os serviços REST.

Bom, entre as lições aprendidas neste projeto, está a de desconfiar de todos os componentes, e tratar minuciosamente de possíveis situações de contingência, até as que pareciam improváveis. Vou confessar que fomos um pouco ingênuos em alguns aspectos. Devido ao enorme gabarito da empresa com a qual estávamos nos integrando, tínhamos aquela idéia de que os servidores deles seriam “quase invulneráveis” e que a API deles seria infalível.

Bom, continuo tendo um enorme respeito pela empresa, mas vi que eles também falham, e não é tão pouco como pensávamos. Alguns tratamentos de contingência que fizemos tiveram que ser revistos e acabamos aprendendo bastante com esse processo.

Foi interessante que no domingo depois termos colocado a aplicação no ar eu li um post do Dan Pritchett sobre disponibilidade de 99,999%. Talvez se eu tivesse lido esse post uns 6 meses atrás eu acabaria só lendo rapidamente sem tanta atenção. Mas como vivenciei bem algumas questões que ele levantou, isso acabou realimentando um pouco as minhas idéias sobre o assunto.

Bom, para quem já está usando o novo e-mail da Globo, espero que a experiência esteja sendo a melhor possível. Para mim esta virada foi uma experiência muito proveitosa e torço para que venham mais e mais projetos desafiadores como esse.

O Bill de hÓra publicou um post sobre um assunto que me interessa enormemente. Ele comentou sobre a dificuldade de se projetar boas APIs e protocolos.

Para quem não o conhece, o Bill de hÓra foi o co-editor da RFC do AtomPub, o protocolo de publicação do formato Atom. No post ele comentou sobre a dificuldade de elaborar um bom protocolo de comunicação (no caso o AtomPub). O trabalho demorou mais de 2 anos para ser concluído, e neste 2 anos não contam o tempo no qual o Joe Gregorio (o outro editor da RFC) já estava trabalhando no protocolo antes.

Uma observação que ele faz é que é difícil encontrar indivíduos capazes de projetar boas APIs, e bem mais difícil é encontrar indivíduos capazes de projetar bons protocolos de comunicação. Algumas pessoas dizem que essas habilidades (projetar APIs e projetar protocolos) são de certa forma opostas, o que implica que seria especialmente difícil encontrar pessoas com habilidade nas 2 coisas.

Ler esse post foi motivante e inspirador para mim.  Neste exato momento eu estou fazendo as duas coisas simultaneamente. Meu time é responsável pelo sistema de cadastro de usuários e autenticação da Globo.com, entre outras coisas. Esse sistema é provavelmente o que possui mais clientes internos na empresa. A implementação original utilizava EJBs para comunicação remota entre clientes e o servidor, e permitia apenas clientes Java.

Estamos progressivamente saindo dessa estrutura. Estamos implementando novas interfaces e clientes que usam serviços REST na comunicação, em vez dos EJBs. Isto está sendo feito de forma progressiva porque nenhum Product Owner daria alto valor de negócio para uma migração dessas, exceto em situações extremas (que não são nosso caso).

Pois bem, nesta migração eu estou atuando nas 2 frentes que o Bill de hÓra classificou como desafiadoras. Estamos modelando os serviços REST e o novo protocolo de comunicação. E estamos também implementando uma API Java para realizar as operações através deste novo protocolo.

Sem dúvida esta migração é desafiadora. De fato não é fácil elaborar um bom protocolo e uma boa API. Porém, isto também motiva demais. Quem acompanha o meu blog já sabe do meu apreço por serviços REST. Assim, este trabalho atual tem sido ótimo para conseguir explorar inúmeras situações envolvidas neste tipo de comunicação.

Para minha sorte, pude contar com alguns pontos facilitadores. Na elaboração do protocolo, o conhecimento do AtomPub ajuda muito. Eu já conheço bem esse protocolo e tinha desenvolvido serviços REST em alguns projetos, então essa parte da empreitada ficou muito facilitada.

Além disso, o conhecimento da API Java anterior do projeto traz várias idéias que podemos explorar. Algumas decisões na API anterior foram muito boas, e outras trouxeram alguns problemas. Eu não participei da implementação original do projeto (isso foi em 2004), mas após trabalhar no projeto por bastante tempo, consegui vivenciar bem os problemas dela. O principal era o alto acoplamento entre o servidor e os clientes, então isso é o principal ganho que pretendemos ter com essa nova implementação baseada em REST.

O outro ponto facilitador é estar no mesmo time que o Silvano, certamente um dos melhores caras que já conheci tecnicamente. Nós temos visões complementares sobre a arquitetura e a implementação. As idéias que colocamos na prática após as freqüentes discussões são muito superiores às que eu ou ele seríamos capazes de desenvolver individualmente. Com a liberdade de decisões técnicas que temos na Globo (principalmente após a adoção do Scrum), conseguimos evoluir nossas aplicações progressivamente, sempre avaliando pontos positivos e negativos das decisões anteriores.

Após ler esse post do Bill, tive uma dimensão melhor da grandeza do desafio que estamos tendo agora. Isto traz ainda mais motivação, e não abala a confiança. Tenho a mesma sensação que Isaac Newton teve ao dizer que “se ele pôde enxergar mais longe foi porque se apoiou nos ombros de gigantes”.

Quando estamos trabalhando freqüentemente com padrões e tecnologias abertas, temos sempre essa vantagem. Viver no mundo open source é se apoiar sempre nos ombros de gigantes, e então qualquer desafio fica muito mais suave e a nossa confiança aumenta. É por isso que eu amo o que faço

Caros amigos, na terça-feira dia 27/05 farei uma apresentação sobre web services REST no RioJUG.

Esta apresentação será semelhante à que fiz recentemente na Globo.com, mas acho que ficará um pouco melhor. Maiores informações sobre a apresentação podem ser vistas na página do grupo. Após a apresentação atualizarei este post colocando os slides.

Quem quiser/puder comparecer será muito bem-vindo

Ontem fui no Tech Talk de MySql aqui na Globo.com, que me trouxe algumas idéias interessantes e também fomentou algumas discussões. Não vou falar muito sobre o tech talk especificamente, mas sobre uma discussão paralela.

Algumas pessoas sabem da minha preferência pelo Postgres sobre o MySql. Durante a apresentação ontem o Rafael me perguntou porque tanta gente utiliza o MySql e nem tanta gente usa o Postgres. Ele me perguntou isso porque usa o Postgres em alguns projetos e não viu vantagens em utilizar o MySql em vez do Postgres.

Bom, a resposta pra isso na minha opinião vem da diferença de estratégia. Banco por banco, sou mais o Postgres, embora eu considere que em boa parte dos casos, qualquer banco atende aos requisitos. Mas porque então o MySql ganhou bem mais adoção do que o Postgres?

Na minha opinião, o fator principal que levou a isso é que o MySql já há muito tempo oferece instalador nativo para o Windows. O MySql foi lançado em 1996 e começou com suporte apenas a Linux, mas desde 1998 permite instalação nativa no Windows. O Postgres começou como um projeto acadêmico em 1986, mas em 1996 se tornou um projeto open source com participação da comunidade de software livre. Podemos ver que nesta vertente atual de desenvolvimento, ambos estão disponíveis desde 1996. Enquanto o MySql suporta nativamente o Windows desde 1998, no Postgres isso só foi ocorrer em Janeiro de 2005, com o lançamento da versão 8.0. Anteriormente o Postgres só podia ser instalado no Windows com uso do Cygwin, que está longe de ser algo prático.

Considerando os recursos que ambos os bancos ofereceram ao longo de sua história, não restam dúvidas de que o Postgres é historicamente superior tecnicamente, e na minha opinião continua sendo. Entretanto, com a enorme quantidade de desenvolvedores que só utilizavam Windows (what a shame!), o fato de poder rodar o banco de dados na mesma máquina de desenvolvimento tornou o MySql muito mais conveniente para quem precisava de um banco de dados gratuito para suas aplicações.

Quando o Postgres lançou a versão 8.0 em Janeiro de 2005, muitos desenvolvedores já utilizavam o MySql há anos, e com isso sua adoção já estava bem grande. Neste ponto podemos ver claramente a diferença que fez uma estratégia correta. O fato de ser limitado tecnicamente em comparação com o Postgres não impactou o sucesso do MySql, porque durante muitos anos ele foi simplesmente muito mais conveniente para o desenvolvedor.

Atualmente, só vejo chances do Postgres aumentar seu sucesso se for comprado por alguma grande empresa e colocado em uma pilha de produtos interessante. Eu gosto muito do banco, e nos meus projetos pessoais ele é minha opção default. Entretanto, temo que ele nunca saia da sua abrangência atual, pelos erros na estratégia. É uma pena, devido à qualidade do projeto. Mas é muito difícil qualquer mérito técnico sobreviver a uma estratégia perdedora.