Mas o post foi superficial, sobre diversos pontos. Um deles é que é sobre arquétipos, não pessoas. De fato, a mesma pessoa pode se pegar assumindo um ou outro papel. E as motivações que levam as pessoas a agirem de uma forma ou de outra mal foram tocadas.

Por último, existem outros arquétipos envolvidos nesta história que não foram citados e podem ser mal interpretados, com o do crítico.

O termo “crítico” tem um apelo extremamente negativo para a maioria das pessoas. Ele é um chato e inútil. Ou incorpora a ácida piadinha do “Crítico é que nem eunuco, sabe como faz, vê fazerem todo dia, mas nunca fez nada”. E volta e meia é um insuportável Capitão Óbvio:


Por outro lado, existem coisas que tornam o crítico tolerável, como a idéia de que só a “crítica construtiva” deve ser feita. Ou se tornar um guia rápido e preguiçoso do que eu devo fazer: leio este livro, vejo este filme…

Não! Relembre um dos mais marcantes discursos do cinema, a crítica do Anton Ego em Ratatouille e veja se o grande crítico não tem o seu valor.

In many ways, the work of a critic is easy. We risk very little, yet enjoy a position over those who offer up their work and their selves to our judgment. We thrive on negative criticism, which is fun to write and to read. But the bitter truth we critics must face, is that in the grand scheme of things, the average piece of junk is probably more meaningful than our criticism designating it so. But there are times when a critic truly risks something, and that is in the discovery and defense of the new. The world is often unkind to new talents, new creations. The new needs friends. Last night, I experienced something new; an extraordinary meal from a singularly unexpected source. To say that both the meal and its maker have challenged my preconceptions about fine cooking, is a gross understatement. They have rocked me to my core. In the past, I have made no secret of my disdain for Chef Gusteau’s famous motto, “Anyone can cook”. But I realize — only now do I truly understand what he meant. Not everyone can become a great artist, but a great artist can come from anywhere. It is difficult to imagine more humble origins than those of the genius now cooking at Gusteau’s, who is, in this critic’s opinion, nothing less than the finest chef in France. I will be returning to Gusteau’s soon, hungry for more.

Para o verdadeiro fã de cinema, críticas de pessoas como o Roger Ebert são um deleite. Boas críticas iluminam.

Mas é meio covarde comparar um crítico de cinema a um cineasta, pois os skills não diferentes. O crítico não precisa saber lidar com os trocentos atores envolvidos. O cineasta não precisa ser eloquente com as palavras de sua obra. E por aí vai. Mas todo crítico tem um pouco de cineasta e vice-versa.

O cineasta pode ser mais “completo”, mas isso em nada diminui o trabalho do bom crítico. Cada um cumpre seu papel.

O grande crítico também é apaixonado pelo assunto. Não há como negar. Talvez por isso ele detone tanto algo que, a seu ver, macule a sua paixão.

I don’t like food – I love it! And if I don’t love it, I don’t swallow.

Do lado do software, já conheci gente que eu colocaria para ensinar a aplicar determinadas práticas, mas não para desenvolver um projeto sem a coordenação adequada. Não sei o que que acontece. O cara se perde, inverte as prioridades, sei lá! Mas na hora de deixar o código claro, o cara é bom.

Têm potencial, mas precisam desenvolver seus outros skills. Senão, tornam-se vítimas de sua própria paixão. Foi por isso que destaquei a coordenação como fundamental. Senão ele se perde e, de alguém que tem uma visão técnica muito afiada, passa a um elemento que abala o time.

Linus, um grande artista e crítico

Agora, se o cara é só um crica chato que não tem nada de relevante para dizer, que vá catar coquinho.

Ou melhor: um tolo pomposo não está seriamente buscando se desenvolver. Afinal, é um tolo. Quer falar, se achar, (se) enganar.

Neste caso, o cara chega, chama meio mundo de besta, diz que é o foda e, quando recebe a oportunidade do “então faz”, o resultado é decepcionante. E freqüentemente ele foge, deixa tudo uma zona e põe a culpa nos outros.

Quem nunca ouviu (ou viu) uma história assim?

E com isso, meu amigo, além do dano direto que causou com a zona que deixou para trás, gera um efeito colateral de reforçar o tal ditado. Daí, a resistência gerada a mudanças ou a alguma técnica queimada pelo pavão é terrível para o curió que busca o saber para fazer melhor.

Além de se matar na tal “busca” do “saber”, este pode ser simplesmente errado ou inadequado ao contexto. Também pode ser irrelevante frente a outros fatores que passaram batidos. Pode ser incompleto, exigir uma prática que ainda não tenha, etc. Horrível, e existem boas chances de você estar errado.

Mas a diferença principal entre os dois pássaros (pavão e curió) é que o segundo tende a perceber o erro e corrigir antes e sempre. Até acertar. E aí dá um passo à frente de quem continuou na mesma, achando que quem faz não precisa saber mais nada. E do pavão que só camufla.

Outro que pode sofrer as consequencias é quem ouviu os “ensinamentos” do pavão. Como ele (o pavão) não está comprometido em pôr seus conhecimentos à prova, é comum que se forme apenas um amontoado de coisas que não trazem nenhum diferencial real, mas seduz pelas aparências. Ou, mesmo que as idéias sejam bacanas, se reforça o mundo da fantasia. Ou seja, pavão que efetivamente não soube fazer não ensina, deseduca.

PS: uma perspectiva interessante relacionada a isso, mas aplicada a gurus ágeis está em Agile Ruined My Life.

Meu primeiro contato foi, obviamente, com o JUnit, ainda em 2001. O que mais me encantou foi a possibilidade de aniquilar um fantasma que assusta muita gente: o “eu juro que já tinha testado!”.

Quantas vezes não fiquei com carão ao ver um bug que, sim, eu já tinha corrigido, mas ele teimava em voltar. Ou ainda mais simples: um bug desconhecido (e óbvio) sobre uma funcionalidade que já tinha sido bem testada, mas que quebrou por um efeito colateral qualquer.

Assim, a primeira coisa que me pegou foi a possibilidade de ter testes de regressão. Mas, obviamente, não foi a única. Junto com isso veio outras coisas, como o TDD, suporte a refactoring de gente grande, segurança, explorações, etc.

assertNotFrustrated(expected, actual)

Mas aí vieram duas coisas chatas: o container chato e o teste fraco.

No início, meus primeiros testes eram executados em segundos, como um “Run” de dentro do IDE. Mas os containers com seu processo lento e mais ou menos manual de “deploy” os enfraqueceu e complicou. E aí fiquei de novo com cara de taxo. Mesmo tendo um monte de casos cobertos em testes unitários, eu era surpreendido com erros na aplicação “deployada”, que vinham de todos os lados:

• Erro no template, como um null pointer em um ${user.name}, quando user não havia sido definido.
• Erro também no template, mas proveniente do HTML/CSS usado.
• Mais erro no view, desta vez de javascript.
• Erro de configuração no ambiente interno.
• Erro de configuração do ambiente externo (integração/pre/produção).
• E por último, mas não menos, casos de teste que eu só imaginava à medida em que interagia com a aplicação. Este é o que mais dói, pois você pode descobrir um mundo de situações se você se fechar naquele esquema eu-sou-foda-porque-faço-100%-de-cobertura. É aí que a tartaruga passa o coelho presunçoso. É aí que você ouve o uncle Ben.

No Chile

Mesmo assim, sou ferrenho adepto desta técnica que, obviamente imperfeita, pode ajudar muito se bem utilizada. Foi por isso que quero levar isso para a turma que foi contratada pela Gonow, no Chile. Mas, para fazer um negócio mais bonitinho, resolvi preparar um roteiro para passar para o pessoal.

E eis que começo a fazer uns testes muito sem graça. Tipo, que graça tem um teste de um container/controller do VRaptor, quando a lógica de negócio é muito chinfrim? Ou quando o que pega é a configuração do ambiente?

Então eu resolvo fazer um teste que sai da configuração e vai ao view. Mas sem ter que ficar subindo e baixando tomcat, que é muito chato. Ou melhor: sem precisar instalar o dito-cujo, como um mvn jetty:run da vida. Ou ainda mais prático: com um clique no botão de executar os testes. Para isso, eu só preciso subir o jetty-embedded, já devidamente configurado, antes dos testes (à la um @Before). E depois é matar o dito-cujo.

Aumentar a segurança dos testes, ao mesmo tempo em que simplifica e acelera o processo?

Japybara – na falta de um nome melhor

Pensei bem e resolvi colocar tudo numa biblioteca. Fechei o projeto-roteiro-para-tdd e criei o japybara. O nome veio do Capybara, que é algo que já penso em passar para o pessoal faz tempo. Só que para java.

A coisa toda é muito simples.

1. Baixe o japybara do github: git://github.com/gandralf/japybara.git
2. Instale-o em seu repositório: mvn install. Cuidado: por enquanto os testes usam a porta 8080.
3. Adicione isso ao pom do seu projeto:

   <dependency>
       <groupId>org.japybara</groupId>
       <artifactId>japybara</artifactId>
       <version>0.1</version>
       <scope>test</scope>
   </dependency>
   

4. Crie sua classe de testes:

   import org.junit.Test;
   import static org.junit.Assert.*;
   
   import org.japybara.WebTest;
   
   public class SomeWebTest extends WebTest {
       @Test
       public void shouldHit() throws IOException {
           visit("/hello?name=John");
           assertHasContent("Hello, John!");
       }
   }
   

5. 

Observação: usei o termo “testes de integração” aqui como um genérico para algo maior que os testes unitários. Dependendo do contexto, você pode usar o Japybara para os testes funcionais e de aceitação.

Inspirado por inúmeros casos de pessoas reclamando de sites horrorosos que só funcionam no IE (como o do Christiano e da MacMagazine), resolvi descrever minha interação (obviamente frustrante) com um destes sites: a Vivo (no caso, a Loja Virtual, aonde estava procurando o iPhone4 para comprar).

Depois de quebrar a cabeça e chegar à conclusão que o negócio não funcionava no Safari/Chrome/Firefox, resolvi enviar uma mensagem para o “fale conosco” deles. Na hora, já sabia que era inútil, mas algum impulso sado(porque fui mega-pentelho)-masoquista me levou a escrever o seguinte:

Quase metade das pessoas que visitam a loja virtual da Vivo ficam frustradas porque o site simplesmente não funciona em seu navegador. Isto é, ele só funciona no Internet Explorer, que hoje deve estar com cerca de 50% do mercado. http://en.wikipedia.org/wiki/Usage_share_of_web_browsers

O pior é que fazer sua loja funcionar em todos os navegadores é fácil e rápido. Mas vocês têm que se mexer.

O triste é que eu sei que o responsável já sabe disso, mas não faz nada para corrigir. E sei que provavelmente esta mensagem vai ser ignorada com algo como “Ah, já sei disso, mas não vou fazer nada. Que chato, heim?” ou “Não posso fazer nada” ou algo dilbertesco como http://dilbert.com/strips/comic/2010-09-05/

E eis que recebo uma resposta! Obviamente, eles não se deram ao trabalho de pensar no problema por mais de dois minutos. Ao invés disso, me mandam aquela resposta-políticamente-vaga-que-não-diz-bulhufas (o negrito é por minha conta):

Ola Alexandre,
Sou Mxxxx, analista da Vivo e estou retornando o seu e-mail de 29/03/2011 referente a informação sobre o site do meu Vivo de sua linha (11)xxxx-xxxxx.

Informo que realizei a analise sobre a dificuldade mencionada junto ao nosso setor especifico e informo que não constam irregularidades para o acesso ao site da Vivo, uma vez que os desenvolvedores de sites não os criam para uso exclusivo de uma plataforma e/ou browser de navegação.

Esclareço que é de responsabilidade das empresas desenvolvedoras de sistemas operacionais e browsers de navegação disponibilizarem as atualizações necessárias para que todos os seus clientes possam acessar qualquer web site sem dificuldades.

Ressalto que, na conjuntura atual, o mundo está presenciando uma revolução tecnológica cada vez mais acelerada e, muitas vezes, a disponibilização e compatibilização de programas, softwares, plugins e complementos de navegadores não são disponibilizados em tempo hábil, causando insatisfação nos usuários.

Vale lembrar que um sistema operacional possui várias versões e pode usar vários tipos de browsers de navegação, e cada browser, por sua vez, pode possuir certo número de versões, onde deverá ser baixado o plugin/complemento/atualização adequada a este para que ele funcione em sua plenitude.

Esclareço que é notória a dificuldade dos usuários de micro-computadores identificarem e encontrarem qual versão correta de plugin, complemento ou atualização que sanará a dificuldade encontrada na utilização de determinados programas. Porém, mesmo com a interação da Vivo juntos a empresas da área, não há como abranger todas as opções e dificuldades apresentadas, sendo que a responsabilidade de disponibilizar atualizações de plataformas operacionais e browsers de navegação e de seus criadores e não das empresas de telefonia móvel.

Peço gentilmente que verifique as atualizações necessárias de seus sistemas, Adobe Flash Player e Java Script, entre outros, ou a possibilidade de realizar o acesso do nosso site por outros meios.

Espero ter sido de grande utilidade e se houver qualquer duvida e/ou serviços, por favor, nos encaminhar um novo e-mail, pois estou à disposição para ajudar sempre.

Informo que o Fale Conosco, está à disposição para eventuais esclarecimentos ou se preferir entre em contato com a nossa Central de Relacionamento, através do *8486 de qualquer celular Vivo ou ainda do 1058 de qualquer telefone fixo.

Agradeço o seu contato e lembrando, o numero deste atendimento é 2011704747939.

Estou à disposição se precisar de esclarecimentos.

Atenciosamente,

Mxxxx Sxxxx Xxxxxx

Deixei a resposta na íntegra. Daria para perder um tempão para comentar toda a insanidade dita, mas ela é tão óbvia que nem precisa.

Mas, enfim, numa reação que mistura Buddha com estou-curioso-para-ver-que-merda-que-isso-dá, respondi o email:

Então, não faço a menor idéia porque estou fazendo isso pois, a priori, não ganho nada com isso. Mas, enfim… seguem textos que o atendente (Mxxxx) escreveu (depois de “>”) e que eu comento:

> “Informo que realizei a analise sobre a dificuldade mencionada junto ao nosso setor especifico”

Eu: Legal! Como vocês o fizeram? Abriram a loja virtual (https://lojavirtual.vivo.com.br/) no Firefox ou no Google Chrome?

> “e informo que não constam irregularidades para o acesso ao site da Vivo”

Ué… acabei de testar o site nas seguintes combinações:

- Internet Explorer 7 e Windows: funcionou. Provavelmente funciona no IE 6, 8 e 9.
- Google Chrome e Windows: não funcionou
- Google Chrome e MacOS: não funcionou
- Safari e MacOS: não funcionou
- Firefox 3.6 e MacOS: não funcionou
- Firefox 4 e MacOS: não funcionou.

Todos os navegadores usados estavam na última versão, exceto o IE 7 e Firefox 3.6 (que depois atualizei para 4.0, que é a última, e mesmo assim continuou não funcionando).

> “uma vez que os desenvolvedores de sites não os criam para uso exclusivo de uma plataforma e/ou browser de navegação.”

Eu diria que é justamente o contrário: os desenvolvedores criaram o site que só funciona na plataforma Windows e browser Internet Explorer.

> “Esclareço que é de responsabilidade das empresas desenvolvedoras de sistemas operacionais e browsers de navegação disponibilizarem as atualizações necessárias para que todos os seus clientes possam acessar qualquer web site sem dificuldades”

E que é de responsabilidade dos desenvolvedores criar sites que sigam os PADRÕES web e que pelo menos verifiquem (testem) seus produtos. Este não foi o caso da equipe que fez a lojavirtual da vivo, pois posso listar VÁRIAS de violações destes padrões.

> “Ressalto que, na conjuntura atual, o mundo está presenciando uma revolução tecnológica cada vez mais acelerada e, muitas vezes, a disponibilização e compatibilização de programas, softwares, plugins e complementos de navegadores não são disponibilizados em tempo hábil, causando insatisfação nos usuários”

Eu sei disso Mas fazer algo que funcione em um só navegador, a esta altura do campeonato também é demais.

É simples: depois de desenvolver o site, experimente dar uns cliques nele no Firefox e, de preferência, também no Google Chrome. Se fizessem isso, vcs veriam, em alguns SEGUNDOS que o site não funciona nestes navegadores.

E, para fechar com chave de ouro, eles ainda me trolam com um e-mail nada há ver contendo aquilo que mais odeio no mundo: um número de protocolo!

Olá, Alexandre.

Sou Lxxxxxx Xxxxxx, analista da Vivo e estou retornando o seu e-mail de 29/03/2011, referente á linha (11) xxxxxxxx

Devido a uma falha sistêmica, houve um atraso na resposta referente à sua solicitação, porém a mesma já foi solucionada. Peço desculpa pelo transtorno e esclareço que o Grupo Fale Conosco está a sua disposição para futuras solicitações sobre produtos e serviços da Vivo.

O protocolo deste atendimento é 201175361xxxx e você receberá via SMS em até 24h.

Estou à disposição se precisar de esclarecimentos.

Atenciosamente,

Lxxxxxx Xxxxxx

Turma de site incompatível, uma dica: ao invés de redigir respostas vagas e imensas e atender reclamações de usuários ensandecidos (como eu), que tal dar um “tapa” no seu site? Mas não é qualquer coió que sabe fazer isso direito, não. Você vai ter que contratar um bom time de front-end! E quem sabe role até uma graça com HTML5…

Lembre-se: o seu site é a porta de entrada (virtual, e cada vez mais importante) da sua empresa. Deixe-a, pelo menos, limpa.

1. Entender o porque e evitar esta instabilidade. Daria para perguntar coisas como:
   • Putz, não dá para esperar um sprintzinho, não?
   • Tem que fazer isso agora mesmo e arriscar o planejamento/meta do sprint (iteração) atual?
   • A principal causa destas mudanças é X, portanto temos que fazer Y de forma a trazer um mínimo de estabilidade para o sprint corrente. Por exemplo: acúmulo de dívidas técnicas => reverter o quadro, ou priorização equivocada => trabalhar melhor o backlog antes do sprint
2. Chutar o balde e, ao invés de lutar contra estas mudanças, abraça-las de modo a trabalhar com elas da melhor maneira possível. Neste caso, aceita-se a impossibilidade (ou pouca praticidade) de se planejar um sprint com as tarefas x, y e z, sem surpresas significativas. E daí não dá para planejar o timebox bonitinho. Dá para, talvez, estabelecer um plano de entrega, baseado em metas.

Nos casos em que a segunda opção é a melhor escolha, a técnica de Kanban pode ajudar. Sem querer me alongar, segue um vídeo bacana, em que o Rodrigo Yoshima fala um pouco sobre o assunto:

Um ponto importante é o termo “melhor maneira possível“. No caso do kanban, o ponto é favorecer o fluxo contínuo de valor e tentando expor os gargalos deste fluxo e reduzindo (explicitando e gerenciando) o trabalho em progresso (aquela coisa que você começa e nunca termina porque tem outra-coisa-mega-urgente-para-fazer, e depois outra, e outra…).

E tem também seus slides:

Quer saber mais? Veja este um post sobre kanban & cia no blog da Aspercon. E este na Scrum/Kanban na QCon.

• TV LCD Samsung 40″ series 6 (LN40A, full hd): 1800,00
• TV LED Samsung 32″ UN32B6000: 1200,00
• Home Theater Onkio 7.1 HT-SR800 2000,00 Acompanha os pedestais
• PS3 slim + dois controles + jogos (God of War 1, 2 e 3, Rockband 2 e Beatles Rockband, Street fighter IV e Mirror’s Edge) + kit rockband completaço (duas guitarras, uma bateria e dois microfones)1200,00 (acho que a saída de audio pelo HDMI está ruim e não achei o adaptador para composite)
• WDTV Live (para ver filmes na TV a partir de streaming do computador ou de pendrive/HD externo): 300,00
• DVD Samsung H1080R: 200,00 (lindão!)
• Impressora Laser ML-1630 Samsung: 350,00. Lindona. Acompanha carga de tinta.
• Telefone sem fio siemens: 80,00
• Rack Airon para TV/Home Theather: 750,00
• iMac 24″ (Core 2 duo 2.4G, 4Gb, 320G HD): 3500,00

Acontece que eu tenho um monte de vinhos em casa, a maioria comprada durante minhas viagens ao Chile e Argentina. E, como não dá para levar tudo quando me mudar, resolvi passar alguns para frente.

Aproveite que é só barganha!!! Além de serem vinhos excepcionais, o preço deve estar entre 40%-70% do que se encontra nas melhores importadoras de São Paulo (aka Mistral). E outros que nem se encontra aqui, já que ficaram um pouco em guarda (2 anos+). Além do mais, eu usava estas viagens não para gastar menos, mas para comprar vinhos lá que eu não teria coragem de comprar no Brasil, já que estariam caros demais para meu gosto.

Nota: não vou caprichar na descrição nem usar vinhês e metáforas sem noção para descrever estes vinhos. O google e o próprio site da Mistral são seus amigos! Além do mais, tenho um pavor pessoal às descrições de vinho que não sejam diretas, claras e que se atenham a fatos já que, para mim, 80% deste lero-lero é tão útil e preciso quanto o horóscopo do dia. Ou seja, “O bouquet é exuberante e exótico, enquanto no palato mostra-se macio e intenso, com personalidade bastante peculiar” não é muito melhor que “Vênus e Júpiter formam um par e tanto a seu favor nestes dias! Beleza, encantamento e sociabilidade – sucesso também, além de provas de afeto e bem querer. Se você vai desfilar neste carnaval, será um sucesso. Senão, também será bem notado.”

Velho Mundo

• Alma Negra
  Excelente vinho argentino, de composição “misteriosa”. Ou seja, não fala qual ou quais as uvas de sua composição. Duvida que é bom? Pergunte ao @qmx!
  R$ 40,00
• Altair Sideral 2003
  Vinho tinto chileno, “Premium”.
  R$ 80,00 Deve estar pelo menos uns R$ 150,00 aqui.
• Amayna Chardonnay
  De longe, meu Chadornnay preferido. Segundo o enólogo Carlos Gustavo, “viva o abacaxi!” e tem um final de…
  Chegou a 93(!!!) pontos no Robert Parker (06) e foi considerado o “Melhor Branco do Novo Mundo” pela Decanter.
  R$ 40,00 De graça!
• Amayna Pinot Noir
  Um dos meus vinhos chilenos favoritos. Elogiadíssimo (veja o vídeo do Garry), foi indicado como “Melhor Vinho do Novo Mundo” por Steven Spurrier, da Decanter, e sempre fica acima dos 90 pontos nos Robert Parkers da vida.
  R$ 50,00
• Angelica Zapata Chardonnay
  Melhor Chardonnay da Catena Zapata, e provavelmente o melhor branco da Argentina.
  R$ 45,00
• Cuvée Alexandre Cabernet Sauvignon 2001
  Eu disse 2001!!!! Uma barganha! Este vinho é um dos mais emblemáticos do Chile (fora da categoria Premium). Por ser 2001, este vinho deve estar em seu auge. Por fim, a safra de 2001 foi excelente para o Chile (veja o guia da Mistral).
  R$ 50,00
• Dos Cielos
  Blend criado como uma edição especial, que uniu dois produtores distintos da Argentina, um da Patagônia e outro de Mendoza. Lindão. Acho que tenho até a caixinha de madeira que veio com ele.
  R$ 100,00
• D.V. Catena Nicasia – Malbec
  Caro, é verdade, mas mesmo assim uma barganha! A linha D.V. é grande e, de certa forma, confusa, já que um DV Malbec pode ser 4x mais caro que o outro. Este é dos mais caros =P.
  R$ 130,00
• Leyeda Chardonnay
  Ótimo Chardonnay chileno. Ainda prefiro o Amayna, mas é bom variar de vez em quando.
  R$ 40,00
• Montes Alpha Cabernet Sauvignon 2006
  Um mega-clássico do Chile. Observe que este é um 2006. Então já envelheceu um pouquinho na garrafa, o que comtribui para deixá-lo mais redondo (ok, aqui é metáfora de cerveja). Vai comprar um novo? A safra deve ser de 2008/2009. Acho que dá para evoluir bonito até 2016.
  R$ 40,00
• Montes Alpha Syrah 2008
  De longe, o Syrah chileno que mais gosto. Dica: deixe evoluir por algum tempo na garrafa. Provei um 2006 recentemente e… PQP! Muito f#da!!!
  R$ 40,00
• Terrunio Carmenere
  O melhor Carmenere (Chile, claro!) que conheci. Precisa dizer mais?
  R$ 60,00 Barganha absoluta, já que aqui não sai por menos de R$ 200.

Velho Mundo

Para quem quiser variar, ainda tenho algumas ótimas alternativas do velho mundo.

• Cava Elyssia Pinot Noir
  Este delicioso espumante espanhol é, além de um dos melhores que já provei, uma pechincha. E, para dar uma corzinha, é feito com Pinot Noir.
  R$ 45,00
• Chablis Premier Cru (Vaillons, de William Fevre)
  Como disse um amigo meu: “com um Chablis Premier Cru, não tem erro”. Talvez a Chablis seja a mais emblemática região de produção de vinhos brancos do mundo. E ser um Premier Cru leva o negócio a um ótimo nível de qualidade.
  R$ 80,00
• Bourgogne Premier Cru (Beaune du Château, branco e tinto)
  Dois outros Premier Crus, um branco e outro tinto, ambos da Bourgogne. Já experimentou um bom bourgogne?
  R$ 80,00 cada.

Entrevista com o Ricardo Semler:


Nesta aqui, ele é mais direto, sobre educação:

Aí vem uma apresentação que jurava que já havia deixado aqui: The Real World.

Outra bem bacana, que possui um núcleo comum forte com a primeira, desta vez com o Ricardo Semler, “Leading by Omission”, dada no MIT.

Why work doesn’t happen at work

Falando em TED: the surprising science of motivation

Outra do DHH: “Unlearn your MBA”. Título marqueteiro, mas com conteúdo bacana, com muitos pontos em comum com o rework:

A Ffffuuuu Conf foi mais ou menos assim. Fui lá não porque queria ver uma opinião divergente, mas porque algumas das pessoas mais bacanas com quem já trabalhei fariam apresentações. E eu sabia que eles tinham algo a dizer.

Além disso, o espírito subversivo da conferência era instigante. Seria o oposto do que se vê na maioria das conferências, infestadas por drug-dealer-wannabes, com um “use isso que é legal”. Não! O espírito é o oposto: “use isso e se f*oda”!

E que venham as trollagens!

A keynote “Patterns of fail” foi épica. Ela apresentou aguns padrões que (infelizmente) presenciei. Também tinha o maior índice de trollagens por slide quadrado da conferência.
Gostei, em especial de:

• “The most interesting and character defining trait of these people is how they recovered” (de um #fail)
• Bikeshedding: quando todo mundo vai discutir picuinha. Já tinha visto isso, mas nunca imaginei que teria uma página na wikipedia. Pensei que, no máximo, numa tirinha do Dilbert.
• Behavioral Patterns, que foi o coração da apresentação. De chorar de rir… e de tristeza.

Só não posso concordar com alguns comentários sobre a 37signals & cia. Agora não me lembro de nenhum argumento em específico, mas só uma sensação de desdém sobre o trabalho deles. E sobre os fanboys que se acham depois de lerem o livro. Mas o problema não é do livro, pois eles também se achariam depois de verem meia dúzia de posts no highscalability.com.

Sinto muito, mas os caras são muito bons. Quanto ao livro, é meio um monte de causos, bem parecidos com o que já tinham escrito no blog. E alguns causos merecem ser contados, não por definirem uma verdade absoluta ou uma receita de sucesso, mas por trazerem uma perspectiva interessante. O errado é interpretar a experiência alheia, mesmo que contundente, como uma verdade científica. Vai ter gente achando que o livro é óbvio (eu, por exemplo, que já conhecia a maior parte dos pontos de vista apresentados), e vai ter gente que vai achar o livro revelador. Mas vamos voltar à ffffuuuu conf, que aqui não é sobre a 37…

Não sei como não rolou um banho de sangue depois desta apresentação.

Depois veio a excelente “Agile or Fragile”, do Rodrigo Campos.

Além do conteúdo bacana, ela fechava cada sessão com “possíveis soluções” para cada #fail.

Gostei principalmente de:

• Continuous development is not an excuse for short sighted definitions
• “new story: now we need to get back to earth safe and sound.” #hehe
• “You need to control the Drama Queens” #epic
• “The risk homeostasis syndrome” Não conhecia esse negócio. Chamei algo parecido com isso de “síndrome do coelho presunçoso”, no qual pessoas ficam cada vez mais displicentes à medida em que se apoiam em ferramentas melhores.

E aí vão alguns comentários:

• Pair programming: tal como as duplas de comédia, não é para qualquer um(s) nem para qualquer hora. Mas pode ser uma técnica válida, dependendo das pessoas envolvidas, do motivo e do momento. #captainobvious
• QA: um negócio que fiz uma vez foi deixar a turma de QA testando o produto do sprint anterior. Assim: os testes começavam durante o sprint e se intensificavam no final dele, mas seguiam um pouco além. Basicamente, QA seguia um ciclo diferente do desenvolvimento.

A Itil for failers foi ótima, e serviu para tirar um peso de não ter dado bola p/ Itil ou tentado implantar isso bonitinho.

Era algo que eu desconfiava, mas ficou mais claro agora.

Depois veio a mega-rápida-palestra do Fábio Akita. Prá variar, foi ótima.

Mas em algum momento ele dizia algo como “metodologias são supertições”. Discordo, pois percebo que metodologias têm supertições, o que é algo bem diferente. Se são, nem compensa pensar em olhar. Se têm, pode ser interessante tentar separar o que é útil do que é coincidência. Eventualmente tem algo lá que te sirva, nem que seja para falar mal (ffffuuuu).

Também citava que geralmente, quando alguma coisa não dava certo, tendíamos a nos culpar, dizendo que não usávamos a metodologia direito. Beleza, concordo até certo ponto. Algumas pessoas têm este perfil (mea culpa!), outras não. De vez em quando o problema está com a metodologia (tá errada!), ou com as pessoas (não se aplica neste contexto, não entendeu, …).

Minha experiêcia diz que, em geral, somos péssimos para entender e, por extensão, aplicar novos conceitos.

• Geralmente temos preguiça na hora de ler/buscar a informação, o que já f*ode tudo.
• Não temos a humildade para pensar que, talvez, tal coisa mereça uma análise mais profunda ao invés do “já entendi” depois de ler as primeiras duas páginas.
• Adoramos martelar a idéia à realidade. Não moldar ou enxergar, mas martelar. Usar o GIT como o SVN não dá certo. Nem achar que na Inception se levanta os requisitos ou que Scrum Master distribui tarefas. Mindset x abertura para novos conceitos.
• E muitas coisas exigem disciplina e preparação.

Quando é que o auto-engano está ligado e não percebemos que somos índios teimosos que tentam a dança da chuva mais uma vez ou que não estamos prontos? Não tenho a mínima idéia!

No final, me lembrei de algo que li faz tempo e que acho cada vez melhor: Enough of Processes: Let’s Do Practices, do Jacobson.

A apresentação do Ivan (You shall not get excited) foi, prá variar, ótima… e hilária. Me lembrou suas apresentações de OpenGL na UFMG.

E a citação “Ignorance more frequently begets confidence than does knowledge” também me fez lembrar de:

• “It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.” — Mark Twain
• “The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts.” — Bertrand Russell

Só que foi pro lado do sucesso com o Erlang meio cedo: estava esperando mais histórias de fracasso. Era a ffffuuuu conf, afinal.

A do Trentas, How Not To Use The Right Tool For The Wrong Reason também foi bacana, mas ficou no contexto de infra/sysadmin. O que não foi bem o que eu esperava, até por que vi casos exatamente como o título.

Por fim, a apresentação do Renato Lucindo, Software Instability. Realmente são poucos os desenvolvedores que pensam que o negócio pode (vai!) dar m*rda algum dia e que uma voadora na cabeça para acordar é sempre bem vinda. Só de lembrar quando eu pedia pro povo para usar a p*rra do log direito… aaaargh!

Um ponto que pode ter sido polêmico foi sua observação sobre “No mocks”, na parte “Tests that matter”. Isso é um ponto muito #ffffuuuu para mim.

Nos últimos tempos, vejo o uso de testes unitários com um misto de satisfação e preocupação. Comecei a usar essa tranqueira em 2001 (com o JUnit e eventual TDD) e sempre buzinei no ouvido de muita gente que isto era um negócio legal, mas fiquei ANOS sem ter um feedback positivo (será que ninguém usa isso? #foreveralone). Nos últimos 2-3 anos foi que vi o pessoal comprar a idéia. Legal, né? Não!

O que vi foi, na verdade, o milagre da multiplicação dos mocks, de gente pedindo mais tempo para fazer os testes unitários, sistemas buguentos cheios de testes frágeis, que TDD é um axioma e que nada que presta foi feito sem isso, hudson-verde-tchau, dogmas e mais dogmas. Aaaarrrgggghhhh!!!! Sensação total de #ffffuuuu + #foreveralone. Vai tentar falar em testes automatizados depois disso!

E foi só. Tive que sair mais cedo e não pude voltar. Daí perdi as lightning talks, como a elogiada How to CrAP. :(

O mantra que mais se repetiu: contrate pessoal bom, demita os idiotas. O pessoal bom também vai falhar, mas consegue se virar.

E métodos prontinhos e bestas que qualquer curió pode seguir? Não! No final, só quem merece deve ser condenado à liberdade.