Mais 10 livros recomendados para desenvolvedores

March 3rd, 2014

Lá atrás em 2008 escrevi um post sobre 10 livros recomendados para desenvolvedores. Na época o post foi bastante popular e eu sempre pensei em escrever uma continuação, que acabei nunca fazendo.

Enfim, a hora chegou e aqui vai mais uma lista de outros 10 livros recomendados para desenvolvedores! Mas antes disso, alguns detalhes sobre como cheguei nessa lista:

Por que apenas 10 livros e não 20 ou 30? Não sei dizer – o primeiro post foi assim então vou continuar. :) O bom é que isso me deixa uma quantidade de livros mais do que suficiente para no futuro escrever vários posts!

Por que essa lista tem livros sobre “processos” como Kanban ou Lean? Não era para ser livros para desenvolvedores? Não tenho pretensão de escrever aqui uma lista definitiva e restrita a apenas um tópico, mas sim listar alguns livros que pessoalmente acho importantes para desenvolvedores de software e que me marcaram de alguma forma. Nosso trabalho não é só programar direito mas também saber se organizar (ou organizar um time) para que se entregue mais software, com mais qualidade e em tempo recorde, portanto acho esses tópicos super importantes.

Por que um livro sobre JavaScript e nenhum sobre Ruby, Python, Java ou qualquer outra? Tem alguma preferência de linguagens rolando aí? Não tem preferência não. O “Good Parts” é sensacional porquê me fez entender e respeitar JavaScript de um jeito completamente diferente. Não acredita? Leia o livro então! Acha que é perda de tempo? Eu acho que não, JavaScript hoje em dia é uma das linguagens mais populares e é indispensável conhecê-la bem para fazer desde um simples website como este blog até gigantes como Yahoo e Facebook.

Por que todos os livros são em inglês? 99% de toda a literatura relevante de tecnologia é em inglês e em muitos casos não há tradução disponível, portanto se você ainda não está craque, pule esta lista e vá urgentemente aprender inglês antes de mais nada! De todas as linguagens (de programação ou não) que você pode pensar em aprender, essa é provavelmente a mais importante.

Clean Code: A Handbook of Agile Software Craftsmanship Clean Code: A Handbook of Agile Software Craftsmanship
Robert C. Martin
Test Driven Development: By Example Test Driven Development: By Example
Kent Beck
Growing Object-Oriented Software, Guided by Tests Growing Object-Oriented Software, Guided by Tests
Steve Freeman e Nat Pryce
Code Complete: A Practical Handbook of Software Construction Code Complete: A Practical Handbook of Software Construction
Steve McConnell
Working Effectively with Legacy Code Working Effectively with Legacy Code
Michael Feathers
JavaScript: The Good Parts JavaScript: The Good Parts
Douglas Crockford
Kanban: Successful Evolutionary Change for Your Technology Business Kanban: Successful Evolutionary Change for Your Technology Business
David J. Anderson
Lean Software Development: An Agile Toolkit Lean Software Development: An Agile Toolkit
Mary Poppendieck e Tom Poppendieck
The Lean Startup: How Today The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
Eric Ries
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
Jez Humble e David Farley

A volta dos que não foram

June 7th, 2012

Um ano sem postar aqui. Um ano! Já passou da hora de sacudir a poeira.

Muita, muita coisa mudou desde o último post. Mudei para os Estados Unidos, trabalhei em vários projetos diferentes, viajei bastante, perdi uns 40 quilos (mas aqui nos EUA eu falo que perdi 80 pounds para parecer mais grandioso!), tive mais uma filha, fiz um “double-double” na liga de basquete do Yahoo! hoje… Tanta coisa aconteceu que fica até difícil de decidir por onde começar.

Fazendo uma retrospectiva rápida, o resumo desse últimos 12 meses é que aprendi mais do que em qualquer outro ano da minha vida. Consegui construir um dos times mais competentes que já participei, fizemos um projeto do zero que é o ponto central de todo o Yahoo!, sem contar os outros que continuamos, até chegar nesse ponto onde estamos hoje, trabalhando num produto que tem mais usuários do que habitantes no Brasil! Dá para passar dias escrevendo sobre isso tudo.

Para poder focar nesses projetos e na minha vinda para os EUA (e na saúde, e na família), tive que sumir um pouco e não fui em nenhum evento depois do BrazilJS em Maio/2011. Fiquei triste também de ter que cancelar algumas palestras que já estavam marcadas em conferências como a QCon e a Codestrong, mas olhando para trás acho que isso foi essencial para permitir colocar 100% do cérebro trabalhando nas coisas mais importantes. Quem sabe em 2013 (se o mundo não acabar antes)…

A boa notícia é que agora as coisas estão mais estabilizadas e estou ansioso para voltar a discutir sobre as coisas que acontecem por aí. Para mim sempre foi muito bom escrever porque me fez aprender ainda mais, não só sobre tecnologia e trabalho como também sobre português (principalmente graças a alguns caras como o Denilson e o Pedro que sempre me mandam correções por e-mail quando escrevo errado). :)

Está na hora de organizar as ideias novamente e começar a postar. Estou de volta!

Update: Para tirar a poeira do meu outro blog (em inglês), acabei escrevendo o primeiro post por lá.

[BrazilJS 2011] Aplicações para iOS com JavaScript e Titanium Mobile

May 13th, 2011

Hoje fiz minha apresentação no BrazilJS 2011, o primeiro evento exclusivamente sobre JavaScript da América Latina. Na verdade fiquei sabendo que os aproximadamente 550 participantes tornaram o BrazilJS 2011 o maior evento de JavaScript da história e do mundo! Incrível! Fico muito feliz de ter feito parte disso e mais ainda pela calorosa recepção dos amigos de Fortaleza. :)

Quer ter ideia de quanta gente estava lá? Então veja a minha vista lá do palco (infelizmente várias pessoas já tinham saído por causa do horário do almoço, que era logo depois da minha apresentação):

Stage view @ Brazil JS 2011

Mas vamos ao que interessa. Minha apresentação foi sobre como desenvolver aplicativos usando Titanium Mobile, JavaScript e APIs abertas do Yahoo! através do YQL.

O Titanium é uma plataforma Open Source que te permite desenvolver aplicações nativas para iOS e Android (e até Desktop) usando suas habilidades de desenvolvimento para web e JavaScript. Diferente de outras plataformas, o Titanium não usa “WebViews”, ele cria aplicações nativas que se parecem e se comportam como aplicativos em Objective-C (iOS) ou Java (Android).

Os slides estão logo abaixo, mas você também pode baixá-los no Slideshare.

Se você quiser se aprofundar nos assuntos que falei durante a apresentação, aqui vão alguns links úteis:

E por último mas não menos importante, muito obrigado pelo feedback no Twitter! Até a próxima!

Feedback about BrazilJS 2011 talk on Twitter (1) Feedback about BrazilJS 2011 talk on Twitter (2)

* Se você quiser começar a brincar com o YQL, aqui está a query que pega os dados das imagens acima: http://y.ahoo.it/TDKTqZRs

Sobre entrevistas (parte 3)

March 28th, 2011

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?

Meu ambiente de trabalho em 7 itens

January 17th, 2011

O Anderson Casimiro (@duodraco) começou um meme muito legal: “Seu ambiente de trabalho em 7 itens”. Nele você escreve sobre quaisquer 7 coisas do seu ambiente de trabalho que achar mais interessantes e em seguida indica de 3 a 5 pesoas para fazerem o mesmo. O Anderson passou o meme para o Ivo Nascimento (@ivonascimento), que depois mandou para o Bruno Roberto Gomes (@brgomes) e por fim para o Hélio Costa (@hlegius) que me colocou nesta roda.

Então vamos lá, as 7 coisas que mais gosto e acho importantes no meu ambiente de trabalho são:

1) Git + Github

O Git é uma fantástica ferramenta de controle de versão. Sua característica principal é ser um sistema de controle de versão distrubuído, o que significa que você pode criar repositórios locais independentes de um servidor central, por exemplo. Com isso você pode criar facilmente novos branchs e repositórios praticamente sem custo (ou seja, muito rápido). Outra coisa sensacional é que o Git praticamente resolve sua vida com relação a merges. Na maioria das vezes ele consegue “se achar” sozinho e resolver conflitos para você, o que poupa um bocado de tempo quando você está trabalhando em equipe com várias pessoas alterando a mesma base de código.

O Github faz o Git – que ja é fantástico – ficar ainda melhor. O Github mudou para melhor a forma de colaboração entre desenvolvedores em projetos open source. Basta você criar um clone remoto do projeto que deseja contribuir, fazer suas alterações e fazer um “pull request”. Você pode adicionar colaboradores nos seus repositórios ou até mesmo criar um time de colaboradores. Isso é mais ou menos o que as pessoas já faziam antes, o Github apenas entendeu esse processo e criou uma ferramenta excelente para suportá-lo com algumas melhorias. E isso tudo não serve apenas para projetos abertos não, você pode fazer como eu (e muita gente) e por alguns míseros dólares você terá seus repositórios privados para trabalhar nos seus projetos particulares. Hoje basicamente não tenho nada importante que não esteja no Github.

2) Google App Engine

O Google App Engine também é um absurdo. Com ele você pode desenvolver aplicações Python ou Java num estalar de dedos e colocá-las para funcionar numa infraestrutura bastante confiável e rápida. O App Engine oferece banco de dados, cache, storage e várias coisas úteis que te ajudam a focar na sua aplicação e esquecer a infraestrutura. Para os Railers que lêem este blog, o Heroku é um bom quebra galho (mesmo sendo bem mais simples que o App Engine).

3) VMWare Fusion

O VMWare Fusion me possibilita ter vários sistemas operacionais com diferentes browsers para testar minhas aplicações web em uma máquina só. Além disso, como trabalho muitas vezes desenvolvendo coisas que serão servidas com Red Hat Enterprise Linux ou CentOS, posso facilmente criar ambientes de desenvolvimento locais com esses sistemas operacionais e continuar trabalhando no conforto do meu Mac sem ficar com medo das coisas não funcionarem em produção.

4) TextMate

Todo mundo tem seu editor preferido, e o meu é o TextMate. Gosto dele porque é leve, fácil de escrever plugins e snippets e possui umas centenas de plugins disponíveis por aí para trabalhar com qualquer linguagem que já precisei até hoje, suportar sistemas de controle de versão, e por aí vai. Infelizmente não consigo usá-lo para todas as linguagens que trabalho. Por exemplo, quando programo em Java ainda prefiro usar o Eclipse, ou o XCode para brincar com iOS, mas para todo o resto uso o TextMate (ou, quando em servidores remotos, o Vim).

5) Shell

Não tem como sobreviver sem um shell. Eu costumo usar o Terminal do Mac OS X com algumas customizações, e como shell uso o Bash. Além de me possibilitar diagnosticar problemas em servidores remotos, ver logs e etc., também uso o shell para algumas tarefas de desenvolvimento como usar o Git (incluindo resolver conflitos, prefiro fazer manualmente), buscar arquivos, inspecionar minha máquina e por aí vai. Também costumo escrever shell scripts para fazer algumas tarefas pessoais como codificar vídeos com ffmpeg e fazer backups remotos.

6) MacBook + Mac OS X

Os Macs são computadores que simplesmente funcionam. É isso. Meu MacBook Pro é potente e tem um hardware excelente que não me deixa na mão. E quanto ao Mac OS X, ao invés de ficar no meu caminho me pedindo drivers para fazer qualquer coisa ele simplemente funciona e deixa o caminho livre para que eu possa trabalhar. Já se foi a época em que eu tinha tempo para comprar peça por peça e montar meu próprio computador, ou então ficar re-configurando meu xorg.conf a cada update de sistema operacional. :) Hoje não dá mais, preciso focar em coisas mais importantes.

7) Monitor adicional de 24″, teclado e mouse

Nós que trabalhamos intensivamente com computadores não podemos nos dar ao luxo de não ter um teclado, mouse ou monitor confortáveis. O monitor de 24″ é o mais importante do meu setup de trabalho. Usar dois ou mais monitores me deixa muito mais produtivo, além de ser muito mais confortável do que o display do MacBook (porque é gigante). Se você nunca tentou usar dois monitores, não perca mais tempo e tente agora, você vai ver a diferença. Quanto ao mouse e teclado, durante muito tempo usei hardware Microsoft (aliás, isso eles fazem bem) mas recentemente tenho usado o Magic Mouse e um mini teclado sem fio, ambos da Apple.

E para continuar a brincadeira…

Indico mais 5 pessoas para participar:

Estamos contratando no Yahoo! Brasil

November 18th, 2010

Estamos contratando desenvolvedores para o Yahoo! Brasil!

Nosso time é responsável pelo desenvolvimento e manutenção do Yahoo! Meme. Para trabalhar conosco é imprescindível ser faixa preta em Python, PHP ou JavaScript e conhecer 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 (especialmente XP), conhecer ferramentas de testes unitários, 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 trabalhamos com web, também é necessário ter conhecimento em HTML, CSS e desenvolvimento de aplicações cross-browser.

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 em C, C++, arquitetura de serviços, desenvolvimento de mashups, experiência com uso e desenvolvimento de APIs (REST, YQL, etc.) e experiência em desenvolvimento para iPhone/iPad são bons diferenciais, porém não são requeridos.

Para estas posições é necessário saber inglês bem, 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 vale refeição. Estamos localizados na Vila Olímpia em São Paulo. Geralmente contratamos pessoas de outros estados, mas desta vez infelizmente só estamos contratando pessoas de São Paulo/Capital. Update: Voltamos a contratar pessoas pessoas de outros estados e oferecemos auxílio para mudança (passagem, hospedagem, etc.).

Se você se encaixa neste perfil, envie 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. :)

Update: mais detalhes sobre a vaga (em inglês) na página de desenvolvedores do Meme.

Porquê eu não gosto de desenvolver sites usando Flash

November 17th, 2010

Uma vez estava no carro com minha esposa procurando um lugar para jantar (porque o primeiro lugar que fomos estava lotado). Um amigo me recomendou uma pizzaria que é bem popular aqui em São Paulo e decidimos ir para lá, mas primeiro queria ver se eles não estavam com fila de espera também. Quando entrei no site do restaurante para pegar o telefone e ligar… não funcionou porque o site é feito em Flash – que não funciona no iPhone.

Quem me acompanha no Twitter já deve ter percebido há tempos que eu não sou muito fã de Flash, mas quando eu faço os meus “rants” fica parecendo que eu não gosto pura e simplesmente porque sou fã de carteirinha do iPhone.

Se fôssemos discutir esse episódio do ponto de vista do usuário, a primeira coisa que alguém falaria seria “ah, você deveria ter um Android porque ele roda Flash”. Mas eu não quero entrar nesse mérito. Na verdade quero discutir esse problema de outro ponto de vista, o do dono do negócio (o cara que paga para alguém fazer o seu site).

Se você tem um negócio – seja uma pizzaria, um mercado, uma empresa de desenvolvimento de software e por aí vai – você possivelmente vai querer estar na Internet, afinal, alguns dos 67,5 milhões* de Brasileiros que são usuários de Internet podem acabar “esbarrando” no seu site e comprando algum produto ou ao menos conhecendo sua empresa (*dados do Ibope/Nielsen de dezembro de 2009).

Uma pessoa da minha família passou por essa experiência recentemente. Ele contratou uma empresa para desenvolver um site para a sua empresa justamente porque queria ser encontrado na Internet e queria vender seus produtos para mais pessoas. Acontece que a empresa que ele contratou desenvolveu o site em Flash, que obviamente não funciona no iPhone. Mas mais do que isso, o site bloqueia alguns comportamentos padrão do navegador (barra de rolagem e o botão de voltar/avançar), além de não ser indexado nos mecanismos de busca. Obviamente ele não percebeu nada disso por ser leigo no assunto, mas eu fiz uma brincadeira bem rápida procurando por alguns dos produtos da empresa dele em ferramentas de busca e vários sites de concorrentes apareçeram nos resultados, mas o dele não. Não preciso nem dizer que ele ficou decepcionado (e com razão).

Pensando como o dono do negócio, eu diria: “Ora bolas, se eu invisto dinheiro para ter um site, eu quero que ele seja acessível para o maior número de pessoas possível!” E como profissional de Internet, não gosto de desenvolver usando Flash pelos mesmos motivos a não ser que eu não tenha escolha (mas geralmente há uma saída). Para ser um pouco mais claro, meus motivos são os seguintes:

1) Sites em Flash não são indexados direito em mecanismos de busca

A maioria das informações dos sites em Flash ficam dentro de um arquivo compilado que não é lido pelos “crawlers“. Se o conteúdo não pode ser indexado ele dificilmente será encontrado por possíveis usuários/compradores/etc. em ferramentas de busca. Até existem formas de contornar esse problema, mas uma rápida análise em alguns sites em Flash conhecidos me mostraram que em mais de 90% dos casos os desenvolvedores não se preocupam em fazer com que o site seja buscável. Ferramentas de busca hoje em dia são fundamentais para ajudarem os usuários a acharem o que precisam na Internet. O site que não aparece bem em buscas certamente está deixando de ter uma boa quantidade de usuários a mais.

2) Sites em Flash não são acessíveis para pessoas com deficiência

Pessoas com deficiência visual utilizam “screen readers” para navegarem na Internet. A navegação nesses leitores de tela é feita com base nas tags HTML da página. Por exemplo, as tags <h*> ajudam o cego a navegar pelos tópicos principais que a página cita. O alt (da tag <img>) ajuda-o a saber qual o conteúdo das imagens, e por aí vai. Se o site é feito em Flash, nada disso vai funcionar. É possível contornar esses casos (assim como no tópico anterior), mas é trabalhoso e ninguém faz. Dos 20 sites populares que analisei antes de escrever esse post nenhum se preocupou com isso. Se você faz o seu site em HTML, isso tudo já funciona praticamente “de graça”.

É claro que pessoas cegas são uma minoria da população, mas nós temos sorte de não fazer parte dela. Justamente por serem minoria eles acabam muitas vezes sendo excluídos, e como se a cegueira já não fosse sofrimento suficiente eles sofrem ainda mais. É uma questão humana que, pelo menos para mim, conta bastante.

3) Flash atrapalha algumas funções nativas dos navegadores

Sites em Flash muitas vezes atrapalham o funcionamento padrão dos navegadores. Um exemplo clássico é que eles fazem com que o botão de Avançar/Voltar parem de funcionar ou funcionem errado. Esse mesmo problema impede que um usuário consiga gravar nos seus “Favoritos” uma página específica (porque o endereço é o mesmo para o site inteiro, e quando ele acessar vai cair na página principal do site ao invés da página que ele queria). Muitos sites já corrigem isso atualizando as URLs ao longo da navegação, mas vários não funcionam direito. Um outro exemplo pior ainda é quando sites em Flash substituem a barra de rolagem nativa do navegador por uma específica do Flash. Esse sim é um problema terrível, porque até o scroll do mouse para de funcionar. Quer ver como é perturbador? Então veja este site. Por favor, será que dá para me deixar usar o navegador direito?

4) Flash é pesado, especialmente se você está em redes 3G/Edge ou conexões lentas

Tudo bem, os sites em Flash funcionam em Android. Mas o que você acha de ter que esperar um Flash de 2MB carregar para você poder começar a usar o site? E olha que nem estou contando as famosas introduções animadas, das quais vou falar daqui a pouco. As aplicações em Flash ficam gigantescas e lentas, especialmente para quem está acessando de dispositivos móveis ou de conexões mais lentas.

5) Muitos designers de sites em Flash esquecem da usabilidade

Veja este site. Eu que não sou nenhum especialista em UX sei há anos que rolagem horizontal é abominável. Neste exemplo eles anda fizeram com que o trackpad do meu notebook não funcione corretamente, proporcionando assim a maneira mais lenta e tediosa possível de rolar para achar a informação que eu preciso. Agora veja este outro site. Fiz um teste rápido em casa e minha mãe não foi capaz de usá-lo, tem animações demais e objetividade “de menos”. Aposto que muitas outras pessoas também não conseguiriam. Você não constrói sites somente para pessoas que entendem de Internet ou são capazes de “fuçar” e descobrir como funcionam as coisas. A Internet é aberta e todo tipo de gente usará o seu site, por isso é preciso que ele seja tão fácil e direto quanto possível. Não adianta se preocupar somente em fazer sites bonitinhos, eles precisam ser funcionais também.

6) Flash não funciona em todos os dispositivos móveis

Sites em Flash não funcionam em iPhones e iPads, por exemplo. O iPhone – especialmente o 4 – é um fenômeno de vendas. No primeiro dia de venda foram vendidas 300.000 unidades do iPhone 4. No Brasil, várias pessoas foram para a porta da loja à meia noite para poderem ser os primeiros a comprarem o aparelho. Até hoje as lojas das maiores operadoras ainda estão com o aparelho em falta (porque todas as unidades que chegam são vendidas num piscar de olhos). Isso sem contar o iPad, que estima-se que serão vendidas 10 milhões de unidades até o fim de 2010. Ou seja, estamos falando de uma quantidade expressiva de aparelhos. Assim como você se preocupa em desenvolver sites compatíveis com vários navegadores, você precisa se preocupar com dispositivos móveis. Seria muito mais fácil desenvolver para Firefox somente, mas infelizmente há um grande número de usuários que usam Internet Explorer (incluindo IE6, infelizmente) e você não pode deixar de levar isso em consideração, senão eles não conseguirão usar seu produto. O mesmo vale para iPhone – seria muito mais fácil se você não precisasse se preocupar com ele, mas um grande número de pessoas estão usando e você não vai querer deixar essas pessoas de fora do seu site. Se você realmente precisar usar Flash, preocupe-se em ao menos desenvolver uma versão compatível com outros dispositivos (como fizemos na época que eu trabalhava na Globo.com, por exemplo).

7) Introduções em Flash são pouco úteis

Qual é o objetivo funcional de uma introdução em Flash em um site? Pense. Não há nenhum! Sites em Flash muitas vezes tem aquelas introduções gigantes e tediosas que são uma maneira super eficiente de impedir os usuários de fazerem o que eles precisam. Pode ser que isso tenha sido legal há alguns anos quando era novidade, mas isso já passou há muito tempo.

Concluindo…

Como falei no início, minha análise é do ponto de vista dos nossos clientes, ou seja, das pessoas que nos pagam para fazermos bons projetos de websites. Tenho certeza que você que é profissional de Internet como eu não quer fazer projetos ruins (ou não tão bons quanto poderiam ser).

Existem um monte de ferramentas que te permitem criar sites funcionais, rápidos, acessíveis e eficientes. Mais recentemente com o HTML5, muitas das coisas que antes só eram possíveis com Flash (ou Silverlight) agora são nativas dos navegadores.

Da próxima vez que você for usar Flash, pense duas vezes. E se não tiver jeito e você for usar mesmo, por favor faça direito. :)

Como anda o seu inglês?

October 5th, 2010

Há não muito tempo uma pessoa me procurou no IM para conversar sobre sua carreira. Ela me disse que no momento estava fazendo um curso de Java e me perguntou o que exatamente ela precisava para trabalhar numa empresa como o Yahoo!. Conversamos sobre algumas coisas até que perguntei sobre seu inglês. Para minha surpresa, ela disse que o curso de inglês iria ter que esperar um pouco porque naquele momento ela estava priorizando o curso de Java…

Se você está numa situação parecida, faça o seguinte: pare tudo que você está fazendo e vá aprender inglês. Sério, no nosso mercado é muito, mas muito mais importante do que você pode imaginar.

Em primeiro lugar, alguns dos melhores livros existentes só estão disponíveis em inglês. Poucos títulos são traduzidos e quando são levam alguns meses (ou anos) para tal, isso sem contar que as traduções muitas vezes são ruins. Por exemplo, o Domain-Driven Design do Eric Evans levou aproximadamente 5 anos para ser traduzido, o Patterns of Enterprise Application Architecture do Martin Fowler levou 4 anos, e por aí vai. Hoje em dia o tempo é menor que isso, mas mesmo assim é muito tempo. Ou seja, você não só vai ficar alguns meses (ou anos) para trás como também corre o risco de não ter acesso a uma boa parte do conteúdo mais relevante disponível.

Em segundo lugar, os grandes players de TI publicam seus blogs em inglês – assim como vários dos desenvolvedores mais influentes no mercado. De forma alguma estou desmerecendo os blogs em português (como esse aqui), mas grandes nomes como Robert Martin, Alistair Cockburn, Kent Beck – e mais algumas dezenas que eu poderia citar – escrevem em inglês. Isso sem contar as dúzias de blogs como o TechCrunch, Mashable, High Scalability ou até mesmo o xkcd. Se você não entende inglês você não poderá aproveitar todo esse conteúdo.

Em terceiro lugar, a maioria dos projetos Open Source relevantes são em inglês. Por exemplo, você está acompanhando o desenvolvimento do Node.js? Você já estudou Clojure? E o Rails 3? Linux? Python? Projetos da Apache Foundation? Se você já brincou com alguma dessas coisas (ou todas) certamente foi porque você sabe inglês. E você pode não somente usar essas coisas para desenvolver como também estudar os códigos para entender como funcionam ou contribuir com os projetos. Enfim, um mundo gigantesco de oportunidades.

Eu poderia dar mais um monte de motivos – como dizer que a maioria dos lugares mais relevantes que todo mundo gostaria de trabalhar vão exigir que você saiba inglês – mas acho que só isso já é mais do que suficiente. Inglês é uma das coisas mais essenciais para profissionais de desenvolvimento de software e você não pode ignorar isso. Corra atrás e aprenda inglês “pra ontem”, essa é sua prioridade número um!

Alguns pensamentos sobre “documentação ágil”

September 20th, 2010

Existe um mito de que não se documenta em projetos que usam metodologias de desenvolvimento ágil. Não é bem assim, aliás, não chega nem perto de ser verdade.

A grande diferença entre projetos “tradicionais” e de desenvolvimento ágil é que os processos tradicionais geralmente são bastante prescritivos e você tem que documentar tudo que estiver definido no processo (que geralmente é muita coisa). Você não pensa no que está fazendo, simplesmente segue o que foi definido e escreve documentos. Em métodos ágeis não há prescrição de documentação (e o manifesto ágil fala também sobre “software funcionando mais do que documentação”), mas isso não significa que você não pode documentar nada. Muita gente confunde isso e diz que nunca se deve documentar em projetos “ágeis”, o que é um grande engano. Em projetos ágeis você pode documentar sem problemas desde que seja necessário de fato. A idéia é que você não deve perder tempo com nada que não seja requerido de verdade para o projeto.

Já participei de projetos onde documentar foi extremamente necessário. Por exemplo, uma vez trabalhei num projeto com vários times onde nem sempre os desenvolvedores estavam no mesmo espaço físico, portanto era preciso documentar alguns pontos chave da arquitetura e ambiente para que todos pudessem trabalhar sem problemas. Também já participei de situações onde meu time desenvolvia componentes que precisavam ser usados por outros times, e esses componentes precisavam estar bem documentados para que os outros times pudessem trabalhar adequadamente. Note que isso é totalmente diferente de documentar o projeto inteiro ou escrever dezenas de casos de uso. Documentamos apenas o que fazia sentido ser documentado.

Enfim, há diversas situações onde você pode precisar documentar por diversos motivos. Para te ajudar a decidir quando documentar e como documentar, veja a seguir alguns princípios do que chamei de “documentação ágil”. Essas são apenas algumas práticas úteis e princípios importantes que observei ao longo do tempo em diversos projetos de que participei. Certamente existe muito mais do que isso, mas vamos lá:

Documentação não substitui comunicação

Em projetos tradicionais, muitos documentos são usados para comunicar idéias entre o Analista e o Programador, com QA e por ai vai. Em desenvolvimento ágil o objetivo da documentação é registrar as informações por outros motivos (como os motivos acima). Se você estiver se comunicando por documentos, você já deixou de ser ágil há muito tempo. Documentação não deve ser usada para substituir a comunicação intensa e constante entre os membros do time.

Documentação não pode ser perecível

Documentação tem que ser leve e não pode ser perecível, ela deve ser durável. Se você documenta algo que precisa ser modificado todo dia, existem grandes chances de você esquecer de atualizar a documentação e ela passa a ficar desatualizada. É melhor não ter documentação do que ter documentação errada. Além disso, se você precisa mudar a documentação toda hora significa que você está se aprofundando demais nos detalhes, e então a documentação vai “quebrar” a cada linha de código que você escrever. Quando estiver documentando, pergunte-se: “daqui a algum tempo essa documentação ainda será válida?”. Faça documentação durável. Não entre num nível de detalhe que te faça mudar a documentação o tempo todo (a não ser que você realmente precise disso – e mesmo assim pense se não dá pra fazer de outro jeito, por exemplo, automaticamente).

Documente o necessário, e não mais do que isso

Assim como você deve implementar apenas o necessário para entregar uma funcionalidade e não mais do que isso, você deve documentar apenas o que for necessário e nada mais do que isso. Não perca tempo escrevendo documentação que nunca será usada por ninguém. Se ninguém precisa usar a documentação, então ninguém deve documentar. Documento tem que ter um motivo, documentar sem uma necessidade real não faz sentido

Documentar tem que ser fácil

Documentar tem que ser rápido, não pode dar trabalho. Use ferramentas como wikis, geradores de documentação (como o Sphinx) e por aí vai. Se for fácil documentar, as chances de você fazê-lo serão maiores. No caso de não usar wiki (ou alguma coisa online/web), use ferramentas para publicar a documentação automaticamente. Se a documentação for fácil de ser acessada (e tiver busca) ela fica mais útil. Além disso, prefira usar uma tecnologia fácil e conhecida para que todos os membros do time possam documentar. Por exemplo, se você escolher usar LaTeX, você está reduzindo as chances de designers documentarem, pessoas de negócio e outros membros não-programadores de um time.

Documentação faz parte do “Definition of Done”

Se o seu projeto precisa de documentação por qualquer motivo, a documentação deve fazer parte da “Definition of Done”. É melhor documentar no momento que as histórias estao sendo desenvolvidas – quando o conhecimento está fresco na cabeça – do que acumular um monte de débito e ter que pagar de uma vez só – quando você vai precisar conferir um monte de coisas que já estão prontas para documentar com precisão, o que vai te dar mais trabalho e consumir mais tempo.

Documentação no código pode ser um “code smell”

“Code smell” é um sintoma no seu código que pode indicar um problema maior. Muitas vezes códigos precisam ser documentados porque eles são desnecessariamente complexos. Sempre que possível prefira refatorar o código para ele ficar mais fácil de entender ao invés de escrever comentários (até porque muitas vezes o código muda e o comentário fica lá desatualizado, e isso acaba mais atrapalhando do que ajudando). Tenha uma boa suite de testes (uma suite bem escrita e organizada é uma especificação executável), use Domain-Driven Design para expressar melhor o domínio do software, metáforas, tenha um design simples, use design patterns, enfim, é melhor fazer com que o software seja mais bem escrito e não mais bem documentado.

Dev in Rio 2010

August 18th, 2010

Você se lembra do Dev in Rio? O Dev in Rio 2009 foi um evento sensacional no Rio de Janeiro, criado e organizado por mim e o Henrique Bastos.

Organizar esse evento foi uma experiência excepcional. Para começar, tivemos a sorte de todos os planetas se alinharem e termos vários amigos internacionais presentes no Rio de Janeiro na mesma semana. Quando decidimos tornar isso um evento, a galera aqui do Brasil também se empolgou e todos toparam nos ajudar não só como palestrantes mas também patrocinando o evento. Só tinha um pequeno problema: tinhamos mais ou menos um mês para organizar tudo. Tudo foi feito em 20 e poucos dias, desde fazer um site, até criar uma marca, receber as inscrições e organizar todo o evento. Organizar uma conferência de alta qualidade com palestrantes renomados foi uma experiência única, tanto para aprender o quão complicado é quanto para poder curtir um gigantesco #horaextra com a gratificante sensação de dever cumprido.

No fim do Dev in Rio ficou aquela sensação de que aquilo não poderia acontecer uma vez só. Foi tão legal que desde o dia que acabou ficamos pensando sobre como seria em 2010. A única coisa que sempre tivemos em mente foi que o Dev in Rio deveria continuar sendo um evento sensacional, e nada menos do que isso. Sempre tivemos em mente que seria melhor não fazer nada do que fazer um negócio “mais ou menos”. No fim das contas tivemos mais dificuldade para conseguir patrocínio e palestrantes do que no ano passado, e somando isso com as dificuldades de comunicação geradas pela minha mudança para São Paulo, acabamos decidindo por não fazer o evento em 2010.

Mas num dos encontros mais recentes do #horaextra, a galera decidiu se organizar para montar um outro evento. Liderados pelo André Fonseca, Ramon Page, Rodrigo Pinto e Sylvestre Mergulhão, todos se dispuseram a colaborar com alguma pequena ação: uns cuidando do site, outros com divulgação ou correndo atrás de patrocínio, todo mundo trabalhando pelo mesmo objetivo – fazer um evento sensacional em 2010 no Rio de Janeiro. E por isso vamos mudar de idéia.

É com muita felicidade que eu escrevo este post para dar a boa notícia: vem aí o Dev in Rio 2010 com força total! O Dev in Rio cresceu e ganhou vida própria. Agora não é mais organizado por apenas duas pessoas, mas sim por toda a comunidade de desenvolvimento de software do Rio de Janeiro! :)

Dessa vez eu e o Henrique ficaremos bem menos envolvidos. No entanto, vamos ajudar a galera nova a manter em 2010 as coisas que fizeram do Dev in Rio 2009 um evento de sucesso:

  • Um evento da comunidade para a comunidade;
  • Um evento de qualidade com um custo acessível, apenas para se pagar e não com o objetivo de gerar lucros;
  • Um evento independente de linguagens ou tecnologias, com o único propósito de juntar o que todas elas tem de melhor e suas comunidades;
  • Um evento onde o #horaextra faz parte da programação (com direito a hino e tudo mais). :)

Aguardem o Dev in Rio 2010!