Depuração: Patologia forense versus medicina, uma analogia

December 3rd, 2007 § 5 comments § permalink

Há alguns meses atrás, um programador Ruby chamado Giles Bowkett publicou um texto um tanto ou quanto provocador com o título: Debugger Support Considered Harmful.

O grosso do argumento era que Ruby não precisa de um depurador porque possui testes automatizados. Desnecessário dizer, o texto provocou repostas inflamadas de vários outros programadores dizendo que Bowkett não sabia nem o que estava falando quanto mais o que um depurador era.

Controvérsias à parte, Giles Bowkett reconheceu depois que a terminologia era inadequada, embora não tenha reconhecido a principal falha no seu argumento. Por mais que se diga que testes são preventivos–e realmente o são–o pouco uso que se fazer de um depurador em Ruby se deve, com certeza, ao fato de que até pouco tempo atrás, o suporte ao mesmo era péssimo. Eu já conversei com dezenas de programadores Rails, por exemplo, e para tarefas em que o depurador é necessário, abunda a típica técnica de depuração que o pessoal do ASP costuma chamar de Response.Write debugging.

O fato é que um testes são, em última instância, verificadores de especificação. Não tem e nunca tiveram o propósito de ajudar um programador a identificar erros esdrúxulos escondidos no meio do código.

Um programador experiente introduz cerca de um bug a cada dez linhas de código, seja qual a linguagem ou ambiente que estiver usando de acordo com o que é possível observar na maioria dos projetos. Um teste pode e geralmente revela esses bugs e um programador experiente, na maioria das vezes, consegue identificar o problema com uma única olhada no código. Quando maior a experiência, maior a chance de que uma mera verificação do código em questão revele o problema.

Entretanto, há momentos em que o problema está escondido e é necessário passar o código linha por linha e acompanhar dezenas de variáveis em busca do defeito. Nesses casos, um teste é absolutamente inútil. Mesmo que o teste seja ajustado para lidar com pedaços ainda menores do código, certas condições não aparecerão a menos que o código seja testado item por item.

A falta de um depurador nesse momento vai simplesmente fazer com que o programador introduza artefatos como impressão de variáveis, comentários de partes do código e em geral use estratégias inferiores que poderiam ser resolvidas com um suporte um pouco melhor do ambiente de desenvolvimento. Infelizmente, linguagens de scripting sofrem um pouco mais com isso e, quanto mais seu uso se intensifica, mais o problema se torna claro.

Na seqüência de comentários resultantes do texto do Bowkett, uma das respostas mais interessantes foi de James Robertson, evangelista do Cincom Smalltalk.

Em sua resposta, Robertson compara o depurador existente na maioria das linguagens a um patologista forense. O depurador faz o papel de um CSI investigando a cena do crimeapós o fato tentando descobrir o que matou a vítima. Por outro lado, o depurador sofisticado de uma linguagem como Smalltalk é mais parecido com um médico, tratando um paciente anestesiado e resolvendo seu problema enquanto o mesmo ainda está vivo.

Qualquer um que tenha trabalhado com o depurador do Smalltalk sabe que a analogia é muito própria. Durante o desenvolvimento de uma aplicação Seaside, por exemplo, o processo mais comum de depuração é o seguinte:

  1. Um teste é desenvolvido para a funcionalidade
  2. O teste é rodado
  3. O teste falha e mostra onde o problema ocorreu
  4. O código em questão (que pode até não existir ainda) é mostrado no depurador
  5. O código é corrigido (ou criado, incluindo declaração de classes, variáveis, etc)
  6. A execução é reiniciada
  7. O teste passa

Se há um problema durante a execução da página, o processo é similar:

  1. A página mostra o erro e oferece um link para o depurador
  2. O link é clicado e o depurador se abre na imagem em execução
  3. O código é corrigido
  4. A página é continuada
  5. A página termina de executar, já com o novo código, como se nada houvesse acontecido

O depurador, então, é parte integral do processo de desenvolvimento e, na verdade, não deveria ser chamado de depurador. É mais um explorador do estado do código atual, visto dinamicamente.

Qualquer mudança feita durante a depuração se propaga pelo ambiente todo instantaneamente. Da mesma forma, se um erro acontece durante a depuração, um novo depurador é aberto com as mesmas propriedades. Corrigido o novo problema, a execução retorna ao depurador inicial e o processo continua daí. Não existem coisas como loops infinitos ou necessidade de reiniciar uma página ou código para testar a correção de um problema. Como Robertson coloca no final de seu texto, é uma questão de pedir ao sistema para se explicar sobre o que está acontecendo.

Nesse sentido, não há comparação entre os depuradores comuns, seja do Ruby ou do C# ou o que você quiser. A diferença é grande demais para ser considerada. E dizer que testes resolvem esse problema é a mesma coisa que dizer que você pode resolver problemas de código escrevendo documentação. A arrogância e a incompreensão simplesmente se tornam auto-evidentes.

Pão de Cast #6

December 3rd, 2007 § 4 comments § permalink

Está no ar, com um pouco de atraso, o Pão de Cast #6 – Edição “Nós gostamos de dinheiro também”. Se você gostou dos primeiros, há um boa chance de gostar desse também. Exceto, talvez, pela parte em que criticamos monetização. Tudo bem, metemos o ferro talvez seja a expressão mais adequada.

Outros assuntos incluem:

  • Uma semana de Kindle
  • O abertura da rede da Verizon

E outros assuntos. Dê uma conferida.

Balanço cultural de novembro

December 2nd, 2007 § 1 comment § permalink

Novembro foi um mês de pós-recuperação e não rendeu quase nenhum oportunidade de ler. Entre a organização de um evento e o fato de ter que colocar meia dúzia de projetos em dia, acabei lendo pouco e assistindo mais seriados.

O resultado de novembro foi o seguinte:

  • 3 livros
  • 4 filmes
  • 8 episódios de séries

Nos livros, comecei por Simulacron-3, da Daniel Galouye. O livro foi a inspiração para o esquecido 13º Andar que saiu no mesmo ano que The Matrix. Particularmente, embora já tenha assistido este último pelo menos umas quinze vezes, já assisti o anterior incontáveis vezes e não consigo resistir rever um pedacinho sempre que o vejo passando em algum canal, o que dá uma idéia de quais são as minhas preferências. O livro é antigo, de 1967, e bem datado em relação à parte tecnológica. A idéia, porém, é muito bem executada e, claro, mais elaborada que o filme. Vale a pena uma leitura se você puder encontrá-lo.

O segundo livro foi Budapeste, de Chico Buarque. Na capa do livro, um dos blurbs é de José Miguel Wisnik que diz: “Budapeste, no exato momento em que termina, transforma-se em poesia”. Concordo plenamente. Eu não tinha lido nenhum outro dos livros de Buarque, mas Budapeste me encantou pelo estilo e fluidez da estória. A trajetória de um ghost writer que se perde e se reencontra em Budapeste é mais poesia do que prosa e a forma como Buarque tece a estória já torna o livro digno de uma releitura.

Terminei o mês lendo Confessor, o livro final na série The Sword of Truth, de Terry Goodkind. Eu já tinha reclamado do estilo de pregação do autor há um bom tempo atrás–que tenta emular, sem sucesso, seu ícone do Objetivismo, Ayn Rand–e este livro não fica muito atrás em termos de exposições exaustivos de filosofia mal explicada o que me leva a manter a conclusão: Goodkind é um excelente contador de estórias, mas um péssimo expositor. Mais foi bom terminar a série, que já dura quinze anos e que acompanho há pelo menos cinco, esperando os livros finais. Ainda bem que o autor não morreu antes de terminar. O final foi meio corrido mas deu para satisfazer o leitor. Imagino que os fãs tenham entrando em êxtase com tantos personagens originais que apareceram por algumas linhas.

Nos filmes, 28 Weeks Later (Extermínio 2) que, se não manteve a qualidade do anterior, foi bom o suficiente para manter a minha atenção até o final. O estilo operático de algumas cenas é o que há de melhor no filme, combinando a loucura da situação com uma fluidez de movimentos que até hoje não vi paralelizada em qualquer outro filme de ação.

Ratatouille foi encantador, o melhor filme de animação do ano e uma recuperação há longo devida do estilo de estória infantil que os filmes como Shrek–por melhor que sejam–estavam perdendo.

Pirates of Silicon Valley teve sua resenha própria e o último filme que vi, Sunshine, foi um repeteco. Gostei ainda mais do mesmo na segunda vez, e até mesmo os tons anti-religiosos no filme fizeram mais sentido.

No próximo mês provavelmente não vou conseguir ler ou ver qualquer coisa, mas vou fazer um esforço

Minas on Rails, o depois

December 2nd, 2007 § 7 comments § permalink

Ontem foi o Minas on Rails, edição 2007 e finalmente estou acordado depois da maratona. Se eu estou assim, nem imagino o resto dos organizadores, que, confesso, ralaram bem mais do que eu para que o mesmo acontecesse. Depois de 15 horas de sono quase que ininterrupto, ainda estou me sentindo um trapo.

Mas, cansaço a parte, acho que o evento foi muito bom. Como todo marinheiro de primeira viagem, cometemos muitos erros mas o feedback posterior foi muito bom e acho que conseguimos nosso objetivo de informar um pouco mais sobre o Ruby e o Rails a quem não conhecia.

Infelizmente, nossos planos tanto para gravar como transmitir o evento ao vivo foram por água abaixo–graças a uma combinação de problemas técnicos no momento que tiveram a ver, em maior parte, com a mudança abrupta de local acontecida na última semana. O material das palestras, entretanto, será disponibilizado depois.

Revi e conheci mais um porção de gente interessante e isso já mais do que compensou o esforço. Muita gente que eu só conhecia virtualmente apareceu, incluindo o Leonardo Faria, o Vinícius Teles–que me deixou encabulado com os elogios–o Edgar, que eu conhecia do curso da e-Genial e que fez uma heróica viagem de trem de 12 horas para chegar ao evento, e o Lincoln de Sousa–que estava no pós-encontro e me levou em casa depois em uma viagem insana de carro com o Rafael Apocalypse e o Lucas Petes (aliás, com tanto louco no carro, não sei como chegamos vivos; e eu nem bebo).

No geral, a experiência foi ótimo. Ano que vem, espero que possamos fazer ainda melhor com o aprendizado desse. Muito obrigado aos mais de 120 participantes que fizeram do evento um sucesso.

Minas on Rails: o trem está rolando!

December 1st, 2007 § 9 comments § permalink

Com uma hora de atraso, estamos felizes em começar o Minas on Rails ’07. Como sempre, aventuras na hora de organizar que render histórias engraçadas depois. A primeira palestra está rolando, com o André Fonseca, falando um pouco sobre o Baú de Arquivos e como o Rails facilitou o processo de desenvolvimento do mesmo.

Atualização: Primeira palestra apresentou bem o Rails e agora estamos na segunda palestra com o TaQ, falando sobre o Ruby (passado, presente e futuro). Boa seqüência à anterior para familiarizar o pessoal com o que o Ruby oferece para depois falar de coisas mais complexas.

Atualização: TaQ: Tio, faz assim. Coisa de paulista. :-)

Atualização: Terceira palestra do dia com o Eduardo Rocha, do O Curioso, um site relacionado ao Orkut (salva os scraps permanentemente) usando Rails pesadamente com crawler, dezenas de processos, etc. O caminho de upgrade foi interessante e mostra que o Rails consegue evoluir tranqüilamente. Interessante as configurações: 20 mil usuários com 1×4 Xeon + 2GB, o que é modesto. Hoje são 400 mil usuários com máquinas não tão enormemente maiores.

Atualização: Quarta palestra começando sobre JRuby. Diógenes Araújo dando uma revista no assunto falando sobre o que está acontecendo, o que vai acontecer e como desenvolvedores Java e MRI podem se aproveitar do JRuby. O JRuby está se movendo em um passo muito rápido o que é muito bom.

Atualização: Quarta palestra começando com o Rafael Apocalypse falando sobre design Web com o padrão MVC e como lidar com programadores e designers ao mesmo tempo sem comprometer a qualidade final do produto. A próxima é a minha. Medo.

Atualização: Acabei minha palestra e depois fui levar o TaQ em Confins. Pela resposta da aduiência dá para melhorar bastante coisa antes da próxima apresentação. Esperado, é claro. Perdi a palestra seguinte, de TDD, e agora está rolando a palestra do Vinícius sobre o projeto Lucidus.

Atualização: O projeto Lucidus é um exemplo muito interessante de XP + Rails em grande escala. Ainda não havia visto a apresentação do mesmo e ver o processo aplicado em detalhes em uma empresa grande versus equipe grande é bem positivo.

Atualização: Palestra do Vinícius terminando, com bastante questões. Muito positivo. Agora falta somente o último passo nessa longa caminhada. :-)

Atualização: Palestra do Carlos Júnior começando falando sobre REST e Rails.

Atualização: Com o evento terminando, já dá para notar bastante coisa que fizemos certo e bastante coisa que fizemos errado. Marinheiros de primeira viagem, acho que até conseguimos executar bem. Resta saber a reação do pessoal depois. :-)

Atualização: Última palestra concluída. Evento basicamente terminado só com um tempo aberto para perguntas e respostas com os palestrantes.

Where am I?

You are currently viewing the archives for December, 2007 at Superfície Reflexiva.