Longos prazos no desenvolvimento humano

February 25th, 2009 § 2 comments § permalink

Meu primeiro contato com a fundação The Long Now foi através de um sub-projeto da mesma: o Long Bets, que procura gerar discussões públicas e responsáveis sobre tendências e previsões relacionadas à sociedade humana como um todo.

No começo de 2002, Dave Winer, um dos pioneiros da então incipiente “blogosfera”–e cujo blog eu lia na época–fez uma das primeiras apostas registradas no site. A aposta foi entre ele e o CEO do New York Times e essencialmente era sobre a relevância dos blogs em resultados de busca para cinco anos no futuro. Winer acreditava que em 2007, para as principais histórias do ano, blogs seria responsáveis pelos resultados mais importantes. Winer ganhou a aposta, a propósito.

Acabei ficando curioso com a idéia que teria motivas as longas apostas e descobri que eram somente parte de um projeto maior de consciência a longo prazo sobre assuntos humanos por uma fundação criada especificamente para esse propósito.

Os criadores da Fundação The Long Now sentem que o passo da civilização humana está chegando em um ponto intolerável onde o tempo de atenção médio da espécie é patologicamente prejudicial à sobrevivência da mesma e estão criando projetos que vão tentar incentivar o pensamento em prazos que compreendem não somente anos, mas em alguns casos olham milênios à frente.

Um desses projetos, por exemplo, é o 10,000 Year Clock. Esse projeto visa construir um relógio capaz de durar 10 mil anos, que é justamente o tempo em que a humanidade existe com uma espécie tecnologicamente estável. Para apoiar nesse processo, uma das idéias interessantes é usar uma base milenar na nomenclatura dos anos. Como pode ser visto nos sites da Fundação, os anos são registrados com um zero a mais, 2009 sendo 02009 no caso. O relógio a ser construído duraria até o ano 12000, marcando os 10 mil anos do protótipo inicial.

Outros projetos compreendendo o mesmo timeframe estão sendo elaborados, com o propósito de preservar a herança lingüística e o conhecimento que está sendo acumulado atualmente e que corre o risco de ser perder por existir em formatos proprietários e pouco duráveis.

Estou começando agora a ler Anathem, do Neal Stephenson, que também é inspirado pelas idéias da Fundação e está sendo bem interessante ver como Stephenson conduz essa idéia de pensamento a longo prazo dentro da obra–algo que ele já faz por extensão em outros de seus trabalhos mas que fica mais evidente em Anathem.

Trabalhando em uma profissão em que as coisas são medidas em um ritmo dezenas de vezes maior do que da maioria das outras áreas, não fica difícil perceber a atração que isso possui para a discussão tecnológica–não por que há uma necessidade de reduzir o ritmo, mas sim pela idéia de remover o imediatismo e pensar em como o acúmulo de decisões corretas é necessárias para um uso são dos recursos planetários que temos e uma eventual saída do planeta.

Se vamos evitar os cenários apocalípticos e destrutivos que permeiam nossos sonhos ficcionais, precisamos de uma visão que olhe para um momento em que não seremos os mesmos em nossa relação com o universo mas que nos permita permanecer essenciais ao que somos. Essa é uma das promessas dos projetos Long Now e algo que acredito valer o esforço.

Frustração

February 18th, 2009 § 0 comments § permalink

Incômodo, um balanço arriado,
uma lasca na mão, um caco de vidro no pé.
Subindo pela garganta,
o sangue quente, a alma talhada.

Um grito contido,
a voz que reluta em sair.
Não me enxerga?
Não me vê?

Vou berrar pelos cantos da terra,
aquilo que só eu posso perceber.
Se ninguém mais entender,
a culpa é de quem?

Rails é, definitivamente, o novo ASP

February 13th, 2009 § 14 comments § permalink

Você sabe que uma tecnologia atingiu o ponto de saturação quando alguém tem a capacidade de propor algo CMM-like para ela.

Rails é, definitivamente, o novo ASP–ou Cobol, ou PHP, ou escolha o que você achar melhor. :)

Balanço cultural de janeiro

February 6th, 2009 § 2 comments § permalink

Em janeiro retomei meu ritmo usual de leitura e filmes com o seguinte resultado:

  • 8 livros
  • 4 filmes
  • 10 episódios de série

Os três primeiros livros do mês foram The Fall of Hyperion, Endymion e The Rise of Endymion, todos por Dan Simmons e que juntos com Hyperion, lido do mês anterior, compõem a tetralogia Hyperion Cantos.

Enquanto o primeiro desses três livros termina a estória começado em Hyperion, os dois seguintes pulam quase que 300 anos para o futuro para explicar o panorama mais abrangente que permeia o Cantos. Os livros mostram um clara progressão no domínio do tema por Simmons, mas confesso que não achei a segunda parte do Cantos tão interessante quanto a primeira. Simmons explora bem a mitologia por trás do que está contando mas algumas coisas–com a longa peregrinação feita pelos personagens principais–se arrastam sem oferecer uma conclusão satisfatória sobre a necessidade de algumas passagens. O final é bem resolvido e amarra a maioria das pontas soltas mas carece do impacto da conclusão da primeira parte.

Seguindo o mês, li The Productive Programmer, por Neal Ford. O livro é uma compilação de dicas e técnicas para aumentar a produtividade que vão desde conceitos mais gerais como TDD, passando por itens de interesse a longo prazo como escolher o editor correto até dicas do dia-a-dia sobre como gerenciar atalhos e comandos no shell. Algumas das dicas são genéricas, outras se aplicam a somente um sistema operacional, mas todas podem acrescentar algum valor à vida do programador. Não é um livro para ler uma vez só mas para rever periodicamente implementando gradualmente as técnicas demonstradas.

Continuando, foi a vez de reler Peopleware, o clássico de Tom DeMarco e Timothy Lister. A primeira vez que li o livro foi na perspectiva de um programador, aproveitando determinados aspectos do livro. Lendo agora no papel de um Agile Manager, a perspectiva diferente é bem interessante. Esse é um livro que eu vivo citando e a segunda leitura não foi menos interessante do que a primeira, embora agora a capacidade específica de atuar tenha uma atração adicional.

Os dois livros seguintes também foram uma releitura. Embora eu realmente não bata com o estilo pregacional que Terry Goodkind adota em seus livros–ele força a barra várias vezes para mostrar seu ponto de vista–continuo achanado que ele é um excelente contador de estórias. Acabei relendo Wizard’s First Rule e Stone of Tears, os dois primeiros livros da série The Sword of Truth. A releitura foi inspirada pelos primeiros episódios da adaptação da mesma para TV, na recente série The Legend of the Seeker e foi interessante ver as diferenças do livro para a representação na tela.

Fechei o mês lendo The Diamond Age, outro clássico de Neal Stephenson que eu ainda não tinha lido. Dessa vez Stephenson mistura nanotecnologia com um mundo onde o modo de vida vitoriano ganhou ascendência e filos similares aos grupos mostrados em Snow Crash competem entre si. No meio disso, um projeto implementando por um cientista cai em mãos erradas e começa a transformar o mundo conhecido envolvendo várias facções em uma disputa por tecnologia e mentes. Como sempre, a visão de Stephenson é gigantesca e ele consegue criar um mundo completamente diferente do nosso e ainda assim realista e consistente. Mais um que não desaponta.

Nos filmes, comecei o mês vendo o remake de The Day the Earth Stood Still. Estória simplória, atores que não dão nem um esforço mínimo para convencer e propaganda descarada são contínuos dentro do filme. Esse dá para esquecer antes mesmo que você termine de sair do cinema.

Tropic Thunder é divertido no modo usual de Ben Stiller e Jack Black e conta com a participação hilária de Robert Downey Jr., mas também não convence. Dá para rir bastante com algumas partes mas a estória já cansou.

Righteous Kill, com os pesos pesado Al Pacino e Robert De Niro é uma tentativa de refazer o sucesso que Heat (Fogo contra Fogo) teve. Os dois dão um show como seria de esperar, mas o filme possui um enredo um tanto ou quanto pobre e previsível que nem a atuação e química entre eles consegue tornar algo grandioso. Algumas falas e cortes são tão inspirados que seria de esperar que o filme todo produzisse algo melhor, mas mesmo aproveitando a precisão e combinação de Pacino e De Niro, o filme não tem peso para ser um clássico.

Finalmente, fechei o mês em filmes com Layer Cake, uma divertida comédia com Daniel Craig no papel de um traficante que quer deixar a vida de crime e descobre que as coisas não são tão fáceis como parece.

Nas séries, o retorno de Lost foi forte, mostrando que a quarta temporada não foi uma coincidência e que os fãs podem esperar uma boa conclusão. Battlestar Galactica, ao contrário, parece perdida e dá a impressão de que uma quinta temporada pode ser empurrada goela abaixo dos fãs. Ou isso, ou um final cataclísmico vem por aí.

Testes, primeira temporada, episódio um

February 4th, 2009 § 2 comments § permalink

No último artigo, falei um pouco sobre a preocupação arquitetural que deve permear os testes e fiquei devendo um exemplo.

Para não entrar em detalhes específicos do Rails e viciar a discussão, me lembrei de um exemplo que li há vários anos, quando estava começando a estudar XP, de um sessão entre dois programadores experientes fazendo pair-programming para chegar em um corpo de testes expressivo com base em um problema bem específico.

O exemplo é real e foi protagonizado por Robert C. Martin, um dos assinantes originais do Agile Manifesto e Robert S. Koss. Para ler o exemplo, siga para a página do mesmo.

Como é possível ver claramente pelo exemplo, a implementação secundária–representada pela classe Scorer–não possui um teste em particular. Entretanto, está fielmente testada através do seu relacionamento com o objeto mais importante. A preocupação arquitetural está no que as duas classes fazem em conjunto e não com o que cada uma delas possui como função. Note, inclusive, que classes secundárias são consideradas e descartadas sem que as mesmas sejam objeto de testes mais do que de passagem.

Obviamente, em uma arquitetura saudável, classes dominantes aparecerão e terão um foco maior em testes. O importante, então, é manter a visibilidade do domínio que está sendo testado.

No caso específico do Rails, o grande problema está em como aplicações são geralmente desenvolvidas. Por causa da separação convencionada do domínio MVC da aplicação, muitos desenvolvedores acreditam que essa é a única forma que se pode desenvolver aplicações usando o framework. O alvo, quando usando o Rails, não deve ser aplicar essa estrutura cegamente mas conseguir segregar papéis e funções de modo que o todo seja coerente.

Essa é uma visão bem geral do assunto e poderíamos nos estender em vários aspectos. Perguntas e comentários são bem-vindos.

O último D em TDD é para Arquitetura

February 3rd, 2009 § 6 comments § permalink

No meu último artigo, comentei bastante sobre a minha opinião de que testes devem ser sobre o relacionamento entre partes específicas do seu código e não sobre interfaces ou contratos. Na minha experiência, os testes mais duradouros e de maior valor são aqueles que exercem as interfaces e contratos indiretamente, através do arquitetura particular oferecida pelos mesmos.

O ressurgimento de testes como uma ferramenta ágil é uma coisa recente e, obviamente, uma excelente oportunidade para conversar sobre técnicas, filosofia e metodologia de desenvolvimento. Em especial, a comunidade Rails tem feito um trabalho excepcional de evangelização sobre o assunto, tornando testes um participante de primeira classe no discurso de desenvolvimento de software.

Entretanto, como é fácil acontecer, o próprio sucesso do assunto está se convertendo em uma fonte de perigos para desenvolvedores iniciantes ou que não tenham tanto familiaridade com TDD e BDD. A própria multiplicação dos pães, digo, dos frameworks de teste está contribuindo para isso no sentido de que, em um afã de criar mais features do que o concorrente, alguns framework estão simplesmente promovendo técnicas péssimas de testes em troca de um falso senso de segurança.

Isso volta um pouco na discussão sobre a diferença entre TDD e BDD, mas acho que o ponto merece uma ênfase. Em resumo, é imprescindível evitar substituir arquitetura, mesmo quando se está fazendo TDD, por meros testes.

Isso fica mais fácil de ser percebido com algumas ilustrações. Tomando o Shoulda como exemplo, é muito comum ver código como o seguinte:

class UserTest < ActiveRecord::TestCase
  should_belong_to :account
  should_have_many :posts
  should_have_named_scope('recent(5)').finding(:limit => 5)  
  should_have_index :age
end

Esse tipo de código não prova absolutamente nada sobre o desenho próprio de sua classe. O código acima:

  1. É redundante, porque as três primeiras cláusulas já serão testadas automaticamente em outras partes do código, especificamente em controller;

  2. É quebradiço, porque é diretamente relacionado à implementação e não ao comportamento da classe em si;

  3. É pouco mais do que um teste de sanidade para descobrir se o desenvolvedor colocou algumas poucas linhas de código em seu modelo;

  4. Expõe detalhes de implementação, como no caso do matcher para índice.

Em outras palavras, todos os testes acima são absolutamente inúteis. O teste de escopo é o único com algum valor para o teste do modelo em si, mas continua sendo redundante.

Pior ainda, existem exemplos como shouldhavebeforesavecallback, proveniente do Remarkable. Esse é o tipo de asserção que chega a ser contraproducente. É um teste que expõe a funcionalidade subjacente de um modelo, que por regras de encapsulamento deveria ser completamente isolada e invisível para as demais partes da aplicação, é um desvio completo do que TDD representa.

Testes, mais uma vez, são sobre interoperabilidade entre facetas do código. São parte de uma conversa arquitetural que procura se focar o mínimo em detalhes internos de implementação. O objetivo é escrever o menor corpo possível de testes–axiomas–que possa dar uma indicação da validade de um dado corpo de código. E como eu repito freqüentemente aqui, simplicidade é um alvo explícito de boas arquiteturas.

Where am I?

You are currently viewing the archives for February, 2009 at Superfície Reflexiva.