Meu ambiente de trabalho em 7 itens

Para terminar o ano, fui convidado pelo instrutor Anderson Leite para escrever meu ambiente de trabalho em 7 itens:

Máquina / Sistema Operacional

Desde 2008 passei por dois Airs, um Pro e um iPad. Nesse instante estou com o Air de 11″. Costumo usar o mesmo notebook para programar no trabalho, em casa e no carro. Programação extrema.

Em casa uma TV de 32″ como segundo monitor, no trabalho qualquer coisa disponível.

Uso o OS X em coreano e Parallells para o C# no Windows. Sempre uso o sistema operacional em uma língua estrangeira que não domino.

Editor e IDE

Qualquer um que tenha opção de abrir e salvar arquivo. Quando estou em máquinas que desconheço atalhos faço tudo na unha, sem medo. Editor x IDE, Teclado x Mouse é um meio, não um fim. Se o desafio de um bom programador fosse digitar menos e digitar rápido, contrataríamos somente campeões do Typeracer.

No dia a dia uso Eclipse, Textmate e vi. Já usei emacs, gedit, visual studio. Na máquina dos outros qualquer um que tenha opção de abrir e salvar arquivos. Aprendo os atalhos, mas meu foco está no tempo parado olhando a tela, não na destreza dos quatro alts que o mac oferece.

Terminal e Editor

Bash com alguns .shs extras. Toda vez que troco de máquina ele é limpo e não reaproveito nada do anterior. A idéia é não viciar.

Abro diversas abas e não consigo ficar em um só projeto ao mesmo tempo. Enquanto rodo os testes de um, escrevo a funcionalidade de outro, mesmo que por 30 segundos. Quando possível, revezo entre três.

Browser

Chrome com gleebox, Firefox com gleebox e Safari, todos ao mesmo tempo. Internet Explorer para os sites que não funcionam e sites coreanos em geral.

Software

Vital: file explorer (finder no os x), terminal, um editor qualquer. O resto é opcional.

Opcional: SizeUp, spotlight, dropbox, google apps.

Aberto esporadicamente: skype, adium, tweet decks.

Source-code

Git. Svn em alguns projetos de terceiros. Aliás, svn que não funciona com OS coreano.

Música

Sem. 99% do tempo prestando atenção nas conversas dos outros. Fones de ouvido quando não desejo ouvir barulho.
Como não escuto música, prefiro citar outro item do meu ambiente, o pote de chá que em suas variações chinesas, japonesas e coreanas sempre está do meu lado.

Convido todos os leitores para espiarem e compartilharem o seu ambiente de trabalho.

Efeitos colaterais, programação funcional e ruby

Durante a última turma de formação Rails, surgiu uma dúvida relativa a algumas idéias do mundo funcional que Ruby utiliza. É comum o uso do método returning em Rails para dar uma mão e permitir acessar um objeto, além de retorná-lo:

É uma idéia comum no mundo funcional, podendo ser pensada da seguinte maneira: precisamos executar diversos processos com efeito colateral mas estamos interessados em um único retorno.

Uma implementação comum nesse mundo seria:

Implementação de k_comb em uma linguagem funcional qualquer

Ao invocarmos k_comb com uma série de funções, somente a primeira possuirá seu valor retornado: todas as outras são executadas e seu retorno é ignorado. Por isso uma consequência direta é que ao usar tal padrão, estamos fazendo uso de efeitos colaterais.

O Ruby 1.9 já fazia:

Implementação usando o exemplo tap do Ruby 1.9

Com o tappie o ruído da variável extra pode ser removido, indo além da implementação do Ruby e do Rails, de uma maneira bem simples:

Implementação usando Tappie

Usar tais recursos de linguagens funcionais no mundo orientado a objetos de Ruby ajuda a diminuir o ruído semântico da linguagem, mas ao mesmo tempo é possível ir ainda além do que a linguagem Ruby nos fornece. Esse exemplo de implementação de k_combinator é uma possível extensão para o próprio Ruby.

Outras bibliotecas fornecem exemplos de funções como operadores.

Por uma web melhor: evite manter estado

Todo dia centenas de aplicações são lançadas ou atualizadas na internet e fazem uso do protocolo http, que influencia diretamente o retorno do nossos produtos. Por exemplo, adotar web services via ftphoje em dia não parece tão viável quanto era anos atrás.

Mas mesmo com um protocolo ubíquo como o http, muitas vezes deixamos de lado conhece-lo a fundo e perdemos um grande número de potenciais clientes.

Um caso comum que pode ser melhorado é a utilização indiscriminada de estado de cliente para responder uma requisição.

Nesse cenário, já na primeira requisição o servidor marca o cliente com um cookie de tempo determinado de expiração, por exemplo 15 minutos, e esse cookie é essencial para todas as requisições futuras. Assim que o cookie expira, o usuário é obrigado a voltar para a pagina inicial.

Por exemplo, no site da Tam, inicie uma busca e aguarde sua sessão expirar. Tente executar um refresh: o site o redireciona para a página inicial de escolha de língua, uma página que você não passou anteriormente.

Site com escolha de país. Opção para lembrar, mas será esquecida junto com o cookie.

Ao escolher um país note que devido a utilizar cookies (ou url-rewriting), o sistema não consegue realmente lembrar após o tempo passar, apesar de marcarmos o checkbox.

Além do usuário se assustar com uma tela que não existia antes, ele não retorna para onde estava, mas sim para a página inicial, perdendo o trabalho executado até então.

Se o usuário encontrou uma viagem interessante e tenta compartilhar o mesmo para Se enviar o link para um colega para que veja o preco da passagem, ele nao sera capaz de acessa-lo. Como o http pode nos ajudar? Trabalhando com a busca como um recurso (de REST), URIs amigáveis, verbo GET e sem manter o estado teríamos uma URI que resolveria quase todos os problemas acima mencionados:

http://site.com.br/viagem/cgu/seo/20110101/201101012

Podemos medir o número de clientes potenciais que podemos perder diariamente por mantermos sessão em momentos desnessários colocando um contador na página de perda de sessão.

Analise em seu site quantas pessoas entram nessa página diariamente e tem seu fluxo de pensamento quebrado devido a essa abordagem.

Na abordagem da URI baseada em recursos existe somente um ponto que não foi abordado: como saber o país do cliente? Existe uma solução padrão do http para isso: utilize o header Accept-language.

Seria possível reescrever as URIs com a língua o que apresenta desvantagem somente para o caso de compartilhar a URI com amigos que não entendem a lingua atual.

Timeout

Quando uma sessão se faz necessária e o tempo é curto, mantenha um contador indicando o mesmo para seu usuário, como no site do Banco do Brasil. Perder o fluxo de trabalho atual é sempre uma experiência negativa portanto dê a chance de seu usuário executar um refresh para continuar trabalhando.

Solução do BB: mostrar o tempo até expiração.

Caso o usuário esteja preenchendo um formulário e não queira executar um refresh, mostre um alert do javascript confirmando se o usuário deseja se manter logado, executando uma requisição ajax para prolongar o tempo, como alguns sistemas de submissão de palestra online costumam fazer.

Recentement Subbu Allamaraju comentou sobre a questão de sessão não fazer parte de HTTP e quão vital isso é para a web escalar.

Entender o cookie e o valor da sessão significa algo além do que está na URI: conhecimento fora do padrão HTTP, chamado out-of-band knowledge. Sites que se baseiam nesse tipo de trabalho, implicam em pior SEO, além de dificuldades de acesso no dia a dia por seus usuários. Por uma web melhor, não dependa de estado do seu cliente.

Prática ágil: busque e compartilhe o conhecimento

Sintoma: os desenvolvedores de um projeto jamais enfrentaram um tipo de problema e decide resolvê-lo. Uma história começa a ser desenvolvida, mas o mesmo fica parado diversas vezes em pequenos detalhes que impedem completá-la pois ninguém na equipe possui tanta experiência com a ferramenta: existem mais dúvidas do que respostas na equipe.

Ação: participe ativamente em listas e fóruns de discussão de plataformas ou linguagens, como o Tectura, o GUJ ou o guru-sp.

As chances de outras empresas e desenvolvedores terem passado pelos mesmos problemas que nós em algum momento no passado é muito grande. Em toda singularidade de nossos projetos, a similaridade é muito grande.

Em casos pequenos como uma mensagem de erro jamais vista, buscadores são seus amigos, como quando procuramos no google entre as páginas do brasil a mensagem exata de erro “java.lang.IllegalStateException: Response already committed”:

Buscando por uma exception no google entre as páginas do Brasil: ajude a comunidade local a se desenvolver.

Em casos em que não encontrar publicada a resposta para sua pergunta, não deixe de aproveitar para colaborar: compartilhe suas dúvidas e soluções.

Como professores, sabemos que escrever a dúvida ajuda no processo do desenvolvedor entender o seu próprio problema. Ajuda a expressar aos outros um conceito e problema abstrato: algo que requer exercício para dominar.

Quando tentamos explicar o que está ocorrendo conosco para terceiros somos obrigados a pensar nele com mais calma do que o momento de estresse no qual estamos tentando as soluções.

Ao mesmo tempo ajudar outros a resolverem problemas facilita o processo de assentamento do aprendizado uma vez que o processo de explicação exige uma estruturação maior do que foi aprendido. Criar um blog público sobre tópicos do desenvolvimento dentro da empresa e, principalmente no início, incentive a criação de um posts regulares até o momento em que compartilhar as experiências se torne algo natural.

Utilizar os fóruns para compartilhar as idéias, começando novas threads como no caso do Tectura, é um exercício ainda melhor onde não só doamos parte de nosso conhecimento para um mercado de maior qualidade mas também aumentamos nossa capacidade de expressar nossas idéias.

Se o assunto for grande o suficiente, considere escrever para as revistas da área, sites de notícias ou apresentar em grupos de usuários e eventos.

Prática: abra mão de começar pela solução mais elegante

Sintoma: um desenvolvedor começa a implementar uma funcionalidade e já no início, em algo simples e que resolveria o problema de maneira elegante, está com problemas em algo pequeno e aparentemente ilógico, que deveria funcionar. Por esse motivo a equipe não conseguem continuar com a funcionalidade, com a qual se debatem durante algumas horas.

Ação: deixe de lado a solução mais elegante temporariamente. Se possível siga a prática de baby steps. Procure ajuda em um fórum ou lista de discussão, e implemente uma solução mais simples e básica enquanto isso.

Se o desenvolvedor julga a solução daquele trecho de código algo simples e perde muito tempo para implementar, temos um indicador de um de dois possíveis motivos:

a) se a solução era tão simples quanto imaginado, ela não deveria ter demorado tanto tempo, portanto a solução não é tão simples assim: abra mão dela e implemente uma mais simples

b) com o cansaço mental em cima do problema, fica difícil ver um erro pequeno e geralmente bobo que impede o correto funcionamento.

Independente de qual dos dois for o problema, compartilhe ele de maneira assíncrona – lista ou fórum – com outros que estão com a cabeça fresca e não viciada no problema.

Listas e fóruns são úteis para buscar e discutir abordagens.

As metodologias ágeis deixam claro que tentar lançar o produto perfeito já na sua primeira versão é algo extremamente difícil e penoso. O mesmo é aceito amplamente para o design da aplicação, mas ainda temos dificuldade de aceitá-lo para qualquer pedaço de código, o baby step.

Duke Nuke Forever: em busca da qualidade técnica máxima

Praticar dojos também ajuda a não ficar impedido nesses instantes e evitar o desperdício uma vez que a prática de baby steps é reforçada o tempo todo.

Podemos buscar a perfeição técnica e de produto, mas não devemos começar com ela: alcança-la é um processo.

Prática: faça revisões arquiteturais regularmente

Sintoma: durante o desenvolvimento de um sistema, a equipe percebe a necessidade de mudar algum aspecto arquitetural. Como a arquitetura é a parte mais difícil de se mudar no software, o custo atrelado também é alto. Após o término do projeto, descobre-se que outras equipes já haviam passado por problemas semelhantes e sabiam que a primeira alternativa era ruim para o sistema.

Ação: sempre que um projeto é concluído, aproveite o espaço de almoço de um dia da semana seguinte para apresentar a evolução do sistema e da arquitetura para todos os interessados.

Momento de descontração.

A revisão não é um momento de busca de aprovação, mas de compartilhar os problemas de alto nível passados pela equipe, por exemplo:

a) entre as 3 ferramentas que suportam serialização em Ruby que utilizamos durante os últimos 6 meses, quais os problemas que cada uma apresentou

b) não era esperado mas a adoção de um estilo arquitetural determinado implicou na perda de escalabilidade

c) a atualização de uma biblioteca após o primeiro release foi compensada na produtividade da equipe após 3 meses, ou simplesmente não compensou e voltamos a utilizar a antiga

d) a adoção da prática de deploy contínuo permitiu disponibilizar 30 novas features por mês para os clientes

Pipeline de deploy contínuo existente desde 2008

A revisão arquitetural permite que o conhecimento adquirido em projetos anteriores possa ser reutilizado em projetos posteriores, uma propriedade coletiva – a arquitetura ou até mesmo o processo – assim como a prática de programação pareada faz o mesmo com menor granularidade: o código.

Em projetos de longa duração é natural que as evoluções continuem acontecendo, portanto faça apresentações regularmente das mudanças arquiteturais.

Prática: Evite adivinhar, faça o que é esperado

Sintoma: frente a uma duas possibilidades que o cliente não deixou claro, é escolhido um caminho e frequentemente descobre-se ser o errado.

Após a entrega de uma funcionalidade, é o cliente quem testará, aprovará e utilizará a mesma no dia a dia. Uma vez que é difícil nos colocarmos em seus pés e pensarmos como eles, assumir a resposta de uma dúvida como a provável escolha do cliente é um risco muito alto que corremos. Por exemplo:

Para integrar com o sistema de billing, é necessário aceitarmos cartões de crédito, débito ou vale?
Em um caso, a resposta é assíncrona, no outro, síncrona.

O time deve evitar assumir respostas: procure o cliente pessoalmente e faça a pergunta, somente então continue a criação da funcionalidade pelo caminho que o cliente pretende utilizar.

Caso ele esteja indisponível, envie um email para uma lista interna. Durante a espera pela resposta sobre qual caminho seguir em determinada história, evite cruzar a linha da certeza e iniciar a parte da história que envolve um “chute”, principalmente quando mudar entre o escolhido pelo time e as outras opções é custoso para o projeto.

Ao invés da adivinhação, prefira começar uma história nova. Quando terminar essa segunda, analise então se a história parada já possui resposta, se o impedimento foi removido ou se deve continuar com uma terceira história.

Caso costume do cliente demorar pouco tempo para responder, por exemplo vinte minutos, ao invés de começar uma nova história, utilize o tempo para melhorar a qualidade do código, refatorando o mesmo.

A resposta poderá vir na forma de um feedback inicial, somente para permitir o andamento da história, até o momento que o responsável estiver livre para a conversa frente a frente, por exemplo:

Tenho certeza que aceitaremos cartões de débito mas não sei sobre crédito ainda.

Uma resposta final e direta também permite a continuação da história.

Outra possível resposta é o cancelamento temporário da história por diversos motivos, como quando o cliente não possuir a informação necessária e prefere postergá-la, outro sistema não está ainda pronto ou o cliente decidir que a mesma deixou de fazer sentido, por exemplo:

A equipe financeira ainda não fechou o contrato com as representantes dos cartões.
Precisamos esperar a resposta para continuar esse trabalho.

Em qualquer uma das finalizações, evitamos adivinhar e durante todo o tempo a equipe entregou valor ao projeto: nem ficou parada nem foi para o caminho errado.

Kanban Yoshima

Nessa apresentação o Rodrigo Yoshima apresentou o Kanban como ele se encaixa no quadro geral das metodologias ágeis que utilizamos hoje em dia.

O vídeo foi gravado durante o evento da Noite Ágil na Caelum em São Paulo.

Deploy Contínuo – Entrega contínua de valor

Desde 2005 ajudo com o desenvolvimento de um produto interno que teve sua segunda versão criada em 2008. Até então utilizávamos práticas de extreme programming, como programação pareada, testes, integração contínua e build automatizado.

Entre 2008 e 2009, tomamos o processo de deploy parcialmente automatizado e levamos a seus extremos. Construimos passo a passo um ambiente de produção que pode ser atualizado a qualquer instante para uma versão nova, além do processo de rollback também ser efetuado de maneira simples.

Evolução do banco de dados, testes de integração, testes rodando em paralelo e testes de end-to-end rodados na Cloud são algumas das práticas que adotamos e que apresentarei nos próximos posts, passo a passo.

Tudo isso não aconteceu do dia para a noite em um projeto que já existia e possuia código legado, mas com o passar do tempo implementamos todos esses passos, com uma equipe que vivia em alteração. Agora já vemos os frutos dentro da empresa: uma nova equipe colocou no ar processo semelhante em menos de 1 mês em um projeto novo, e a repetição desse processo nos mostra que não só sites simples são capazes de efetuar deploy contínuo.

O vídeo a seguir é uma visão geral do que é o deploy contínuo e onde chegaremos com os posts que virão:

Noite Ágil – André Pantalião

Mais um vídeo da Noite Ágil já está disponível. Dessa vez André Pantalião apresenta os problemas enfrentados, resolvidos e em aberto que encontraram ao implantar agile em sua equipe: