Algumas dicas para testes melhores

October 27th, 2008 § 3 comments § permalink

O Lucas Húngaro escreveu recentemente sobre a necessidade de abandonar testes quebradiços com uma forma de manter seus testes saudáveis, citando vários exemplos de como isso pode ser feito. Desnecessário dizer, concordo com o que ele disse.

Um conselho dele em particular me parece a melhor consideração sobre o assunto. Falando sobre mocks e stubs, ele diz:

Algumas soluções pra isso são: não utilizar mocks e stubs (o que é um tanto extremista), aumentar o encapsulamento das classes ou aceitar isso e continuar.

Chamo a atenção para a parte final: algumas vezes, você tem simplesmente que aceitar que alguns testes devem ser de certa forma para garantir uma cobertura mais compreensiva.

Dito isso, seguem algumas dicas para testes melhores:

Mocks e Stubs

Uma regra simples que pode ajudar a entender quando usar essas duas técnicas é a seguinte: Se o comportamento esperado deve ser conhecido, use mocks e stubs. Caso contrário, não.

Isso torna fácil perceber que testes de modelos–no caso do Rails, por exemplo–raramente (ou nunca) deve usar essas técnicas. Quando se trata do domínio da aplicação, encapsulamento é uma propriedade básica de sistemas orientados a objetos que não deve ser violada se possível. Obviamente, abstrações vazam; mas isso não deve ser uma desculpa para quebrá-las em testes.

Não teste a abstração imediatamente inferior

Se você está usando Rails, por exemplo, não faz o menor sentido testar a abstração inferior. É muito comum ver testes como:

it "should return all current books" do
  Book.current.proxy_options.should == { :conditions => { :current => true } }
end

Esse tipo de teste verifica se o Rails está funcionando da maneira como deve funcionar e não se o seu código está correto. O resultado é que pequenas mudanças e principalmente a introdução de algum comportamento ortogonal pode quebrar completamente a aplicação enquanto o teste continua a funcionar.

Digamos, por exemplo, que você agora tenha que usar alguma esquema de caching em sua aplicação. No interesse de que a abstração não vaze, você envolve o método acima em alguma abstração que faça isso. O teste acima provavelmente quebrará de imediato, porque está testando a abstração inferior e não o comportamento da aplicação.

O teste correto, nesse caso, seria verificar se a lista retorna é realmente correta, mesmo que isso envolva alguma manipulação de dados que reduza a velocidade do teste.

Use testes de sanidade

Conversamente, é importante também ter alguns testes de sanidade. Às vezes é necessário saber se alguma coisa está declarada, mesmo que a forma final daquela declaração não seja importante.

Um exemplo disso são testes em views. Geralmente, testar se algum conteúdo está aparecendo em uma view é inteiramente desnecessário e pode gerar testes que devem ser refeitos a cada pequena mudança para se adaptar a novas condições.

Mesmo assim, em alguns casos é importante a existência de testes que correm esse risco como forma de testar a sanidade da aplicação; em outras palavras, testar se condições básicas estão sendo supridas.

Não teste nada que não seja público

Uma pergunta muito comum em listas de discussão é como testar métodos privados ou protegidos de uma classe. A reposta geralmente envolve o uso de reflexão e violação de abstrações.

Um exemplo comum seria o código abaixo:

it "should prepare the environment" do
  Manager.send(:prepare_environment)
  Manager.environment.name.should == "development"
end

A resposta correta deveria ser: nunca faça isso. Se seus testes contém alguma necessidade desse tipo, você está violando o encapsulamento e isso indica alguma problema arquitetural mais básico da aplicação. Provavelmente alguma necessidade de separação de dependências que você ainda não identificou.

Nesse casos, funcionalidade básica que envolva código encapsulado pode ser melhor testada pelo seu efeito em outras partes da aplicação.

Cuidado com a ordem dos seus testes

Uma coisa interessante é tentar rodar os seus testes em ordem arbitrária. Existe opções para isso em alguns dos frameworks existentes que podem ajudar a identificar dependências escondidas em seus testes.

Finalizando

Para terminar, esse são apenas alguns dos muitos conselhos possíveis nessa área. Fiquem à vontade para usar a área de comentários do texto para expandir sobre o assunto.

Um conselho final: use seus testes como oportunidades para pensar sobre a sua aplicação. Se você se vê em uma situação em que testar está se convertendo em algo progressivamente mais complicado, alguma coisa está errada na forma como você desenhou seu código. Pare, pense sobre o assunto, e refatore. Seu código e seu tempo agradecem.

Algumas considerações sobre TDD e BDD

October 27th, 2008 § 13 comments § permalink

Parece haver muita confusão sobre a diferença entre TDD e BDD na comunidade Rails. A criação de vários frameworks competidores (RSpec, Shoulda, Expectations, etc) parece não ter ajudado muito já que cada proponente torce um pouco a visão dada por cada um deles.

A grande divisão

O problema é que a maioria das pessoas que pratica uma variante ou outra nunca leu a literatura sobre o assunto e por causa disso há uma falta de formalização sobre o assunto. Muito do que se vê escrito hoje tanto sobre TDD ou BDD é escrito da forma que aquela pessoa em particular pratica o assunto e não como o conceito foi sendo desenvolvido ao longo das anos.

Tome, por exemplo, TDD como popuralizado originalmente por Kent Beck no contexto de Extreme Programming. Existe uma granularidade envolvida no crescimento do código que pode ser descrita como orgânica.

Design ou Development?

Uma das coisas que sempre me ajudou a enxergar o modo apropriado de construir uma aplicação a partir de testes foi pensar no D final de TDD ou BDD não como desenvolvimento, mas como design.

Voltando ao tema de granularidade, se você fizer uma experimento e acompanhar dezenas de pessoas que “praticam” TDD ou BDD, o mais provável é que você perceba que os testes estão sendo escritos como uma forma de cobrir o código e não como uma forma de pensar no código em si. Um teste é escrito que demonstra um certo caso de uso da classe ou método em questão e o código para aquele trecho é então escrito.

É muito comum, dentro da prática descrita acima, que vários testes seja escritos em seqüência e o código da classe ou método inteiro seja depois implementado. Voltando ao modo como Kent Beck explicou o processo originalmente, nada por estar mais longe da realidade.

De fato, nos seus exemplos concretos sobre o assunto, Kent Beck compara o uso de TDD ao uso de uma lista de tarefas para a construção de código, o que força o desenvolvedor a pensar em detalhes sobre a arquitetura que está criando. Volta aqui o sentido de design e não de desenvolvimento puro.

Chega-se então ao ponto de que cada teste é pensado como uma forma de evoluir a arquitetura do código e pensar em como aquela classe ou método existe dentro do contexto mais generalizado da aplicação. Não é surpreendente que quando isso é feito, coberturas de 100% são factíveis, métodos ou funções não possuem mais do que algumas poucas linhas fazendo exatamente e o que deve fazer e não mais e uma delegação efetiva de responsabilidades acontece.

TDD versus BDD

Chega-se então ao ponto central da conversa? Qual é a diferença principal entre TDD e BDD? No ponto mais básico da cadeia, a resposta é: nenhuma.

Tanto TDD quando BDD são formas de se pensar em testes partindo de premissas ligeiramente diferentes mas chegando ao mesmo resultado prático. Sendo feitas de maneira apropriada, o resultado final dentro das necessidades acima (cobertura, delegação, arquitetura) é o mesmo e a conversação que deve acontecer no desenvolvimento ocorre naturalmente.

Apesar disso, há uma diferença histórica que está evoluindo com o tempo e que, em última instância, está se convertendo no foco de debate entre os dois campos. Essa diferença foi inicialmente expressa por Dan North (responsável pelo desenvolvimento do RBehave, que mais tarde se tornaria a base do Story Runner do RSpec) e depois elaborada por David Chelimsky.

Esse posicionamento coloca BDD não como uma oposição direta a TDD em termos práticas, mas como uma corrente filosófica que engloba TDD e expande o discurso para incluir elementos que vão além do metodológico e já começam a cair no processual.

Um exemplo claro disso é a ascensão de frameworks orientados a estórias (testes de aceitação de usuários) como o Cucumber. Esses esforços representam a graduação de BDD não somente com uma forma de fazer testes mas como um processo de pensar e executar testes ao longo de toda a gama de necessidades de uma aplicação (de unitários e visuais).

Essa conversa é a parte mais importante do BDD e, no caso do Rails e Ruby, o RSpec representa apenas uma faceta de tudo o que vem sendo pensado pela comunidade. Eventualmente, como Chelimsky coloca, TDD será um parte de algo maior que será chamado de BDD.

Finalizando

A confusão experimentada atualmente é mais resultado da conversação acima do que da diferença real entre os frameworks. Ainda citando Chelimsky, quando BDD era somente sobre testes unitários, não havia diferença nenhum entre TDD e BDD. Ambos eram e são sobre a melhor forma de testar uma aplicação e nada mais do que isso.

Para dar um exemplo, atualmente eu tenho preferido a combinação Test/Unit + Shoulda + RR ao invés do meu usual RSpec. Gosto da leveza dos anteriores em relação ao último quando os testes se tornam mais envolvidos. Mas isso representa apenas dores de crescimento do RSpec. É bem possível que quando este último estiver mais estabilizado, lidando mais com a magia negra que ele precisa para sua sintaxe, eu mude novamente de prática.

De uma forma geral, então, escolha o frameworks que melhor lhe convier. Desde que a forma como você faz testes esteja correta, o resultado final estará correto também.

Quem imaginaria?

October 25th, 2008 § 5 comments § permalink

Lendo essa entrada no blog do Jon Taplin (muito recomendado, por sinal) é interessante ver que o Brasil figura entre as economias emergentes de menor vulnerabilidade durante a crise econômica atual. De fato, entre os países listados abaixo, ele é o menor vulnerável.

Isso não quer dizer, é claro, que ele não seja muito vulnerável. Como Taplin mesmo aponta, o governo está tendo que queimar milhões de reais para manter a moeda em um nível de valorização razoável. Da mesma forma, a queda da bolsa brasileira é uma das mais acentuadas.

Mesmo assim, é interessante ver que, na situação atual, o Brasil está em uma posição bem diferente da imaginada há alguns anos atrás. Ninguém apostaria suas fichas nem de longe em um Brasil com um economia estável e um poder de influência razoável no mercado global. Se nem tudo são flores, pelo menos não há um pânica generalizado em um momento que outros já estão em plena fuga.

Agora, se ao menos houvesse um jeito de exilar todos especuladores…

Aprendendo Rails

October 23rd, 2008 § 9 comments § permalink

O dia nove de outubro passado marcou os dois anos da liberação do meu tutorial Rails para sua Diversão e Lucro. Oito meses depois do lançamento, o mesmo já havia ultrapassado 15 mil downloads somente no meu servidor. Considerando que a licença é GFDL e que o mesmo foi reproduzido em dezenas de sites, o número atual deve ter sido bem maior mesmo na época.

No geral, foi uma experiência bem positiva. Para um tutorial que começou como material para um curso, a quantidade de pessoas interessadas foi surpreendente. Mesmo na época, havia uma carência enorme de informações sobre o assunto. Coincidentemente, o primeiro livro de Rails no Brasil também foi lançado na mesma época. Acho muito legal, inclusive, que pessoas que hoje são extremamente ativas na comunidade tenham tido contato inicial com Rails através do tutorial.

Bem, esse monte de reminiscências é para anunciar aos leitores regulares que possam eventualmente desejar aprender Rails e aos visitantes que volta e meia chegam aqui perguntando sobre o assunto e topando com um tutorial desatualizado que uma nova versão está disponível.

No melhor espírito da GFDL, Cássio Souza atualizou o tutorial para Rails 2.1, modificando o material antigo, removendo as partes ultrapassadas e acrescentando muito material novo em um novo tutorial que reflete mais precisamente a versão atual do Rails (de 1.2 para 2.1). O material também é acompanhando de screencast que explica mais detalhes práticos sobre o assunto.

Fica aí a dica para quem quer aprender sobre Rails de maneira prática. E que venha os downloads. :)

A falsa dicotomia: generalista versus especialista

October 22nd, 2008 § 8 comments § permalink

Um papo semi-presente na área de TI é a velha dúvida: generalista ou especialista? Como em essencialmente qualquer carreira em que a dicotomia é possível, há sempre uma grande questão em torno do que decidir quando se pensa em um plano para o futuro.

De um lado, especialistas justificam sua escolha em termos de melhores salários, pouco rotatividade, maior reconhecimento. Do outro lado, os generalistas justificam com maior estabilidade, menos rotina, maior amplitude de oportunidade. Sempre há uma certa tensão entre as duas versões do profissional de TI e como qualquer dicotomia, geralmente a verdade é uma coisa inteiramente diferente.

No tempo que eu tenho de carreira, o que eu observo é que a dicotomia é inteiramente falsa. Se existe o bom profissional, não há como o mesmo ser especialista ou generalista. Em um área como a nossa, onde a velocidade de transformação é enorme, medida em meses e semanas ao invés de décadas e anos, qualquer coisa que não seja a fusão dos dois conceitos é simplesmente impensável.

Ironicamente, algumas das raízes dessa separação refletem, ou talvez até tenham sua origem, na antiga disputa entre consultores e empreendedores–centrada, por sua vez, na igualmente inválida dicotomia entre engenheiros e artesãos. Como a maioria das comparações feitas para explicar o desenvolvimento de software, as analogias passam longe de explicar a realidade.

Recentemente, a popularização de frameworks e linguagens fora do mainstream como Rails/Ruby e Django/Python permitiu uma rara observação de como qualquer separação explícita geralmente é de aplicação limitada.

Um caso usual é tomar um profissional que trabalha com uma dessas tecnologias, que está tentando sair do comum em seu trabalho, seja como forma de criar uma nova carreira ou mudar sua empresa para obter uma carreira mais interessante, e por via dessa necessidade forja uma aliança entre áreas díspares como gerência, design, usabilidade, programação e outras (às vezes acumulando todas essas funções sobre si mesmo) e usar isso como exemplo de que o generalizado é melhor do que o especializado.

O mesmo erro é tomar uma disciplina como medicina e usar para ilustrar a outra proposição. Enquanto o exemplo do parágrafo anterior é um erro ao assumir que o mesmo é um exemplo de arte, o segundo é um erro em assumir que “engenharia” é uma metáfora inteiramente válida para o desenvolvimento de software.

A realidade é que, como em qualquer área, o nosso grau de proficiência é inteiramente dependente do âmbito do que estamos fazendo no momento e das circunstâncias transitórias em que esse trabalho se exprime. A especialização, nesse sentido, vem mais como força da acumulação de experiência do que de uma escolha explícita.

Um desenvolvedor é um engenheiro? Sim. É um artista? Também. Por extensão, a mesma pergunta pode ser feita para a dicotomia inicial. É um generalista? Sim. É um especialista? Também.

Isso é o que Dave Thomas fala quando explica sobre o Dreyfus model. Você vai de um lado do espectro ao outro e às vezes está em vários pontos em várias áreas. Quando isso é considerado, a dicotomia cai imediatamente por terra.

Em última instância, como a maioria das preocupações similares, o único resultado da eterna discussão é o gasto de tempo e calorias que poderiam ser postos para melhor uso em projetos mais interessantes. Na próxima vez que alguém quiser discutir isso com você, dê de ombros e ignore. Você não estará perdendo nada de valor para sua carreira futura.

Atualização: A propósito, acabaram de chamar a minha atenção que o Carlos Brando e o Fábio Akita fazem essencialmente o mesmo ponto no Rails Podcast Brasil #34. Desnecessário dizer, concordo.

Como blogar efetivamente, ficar famoso e ganhar leitores sem parecer um plagiador

October 20th, 2008 § 12 comments § permalink

O Google registra nada menos que 77 milhões de referências a “como blogar”. Milhares de conselhos dispensados por famosos e não famosos que tentar ensinar a outros (e convencer a si próprios) como chegar à ponta da vasta cauda longa que compreende as múltiplas e dissonantes blogosferas espalhadas por aquilo que se convencionou chamar a Web.

O que nenhum desse milhões de textos diz é que a verdade é bem mais simples do que parece. Neste pequeno texto, chame de cartilha se quiser, apresento o método mais efetivo, mais seguro e mais recompensador de se erguer aos pináculos da sua blogosfera de escolha. E isso tudo sem o inconveniente de parecer um plagiador.

O método descrito abaixo compreende a criação de um formato específico de artigo, necessariamente longo–o que significa que a técnica só vai funcionar para aqueles com paciência de escrever algo além das médias três linhas que compõem o usual texto de um blog–dispensado aos leitores em doses ocasionais, duas a três vezes por semana. Esse texto possui seções específicas que agora descrevo:

Parte I – Do assunto

O primeiro passo é escolher um tema que esteja em voga. Atualmente, por exemplo, pode ser algo relacionado à crise econômica, Obama versus McCain, o sempre presente fluxo de start ups Web, os lançamentos de produtos de firmas Web famosas e assim por diante. Se você não consegue ter idéias, basta visitar um site de notícias Web qualquer e usar a inspiração.

Como é possível ver, escolher o assunto é muito simples. Basta reusar algo que está sendo falado ou que está no “inconsciente coletivo” da Web no momento. Você vai perceber depois de alguns artigos que não é necessário nenhum tipo de originalidade. Afinal de contas, ninguém é original.

Parte II – Do título

O título, novamente, é tão simples quando escolher o assunto. Na verdade, existem somente três tipos de títulos que levam ao estrelato. A menos que você queira variar ocasionalmente, para surpreender um ou outro leitor, você deve ser conformar a estes três padrões, que são:

  • Como [alguma coisa]. Por exemplo, Como blogar efetivamente, ficar famoso e ganhar leitores sem parecer um plagiador; ou Como entender as eleições americanas, ou Como ser um marketeiro eficaz.
  • [N] passos para [alguma coisa]. Por exemplo, 5 passos para blogar efetivamente, ficar famoso e ganhar leitores sem parecer um plagiador; ou 3 frases para entender as eleições americanas, ou 9 atitudes para ser um marketeiro eficaz.
  • D[a/as/o/os] um [assunto qualquer]. Por exemplo, Dos passos para blogar efetivamente, ficar famoso e ganhar leitores sem parecer um plagiador; ou Das necessidades de entender as eleições americanas, ou Das vantagens de ser um marketeiro eficaz.

Como é possível perceber, não existe esforço nenhum em criar um título eficiente. Basta adaptar alguma frase pequena nos moldes acima e você terá um pagerank vencedor à sua espera.

Parte III – Da introdução

Depois de falar na parte fácil, é hora de falar da parte mais difícil. Como o seu professor de literatura da quinta série costumava dizer, a introdução e a conclusão são duas das partes mais importantes de um texto. Já que só sobra o desenvolvimento, acho que esses professores estavam pensando em seus alunos como blogueiros futuros.

Mas, infelizmente, tais professores estavam certos. A parte mais difícil de um texto vencedor é a introdução. E isso porque, de todo o resto, é a única que vai exigir um módico de originalidade. Se você começar a copiar na introdução, vai ser sacado rapidamente. Mas não se preocupe, como uma boa introdução não passa de dois ou três parágrafos–que podem ser curtos–o risco de errar é mínimo.

Para uma boa introdução, basta criar esses dois os três parágrafos–que podem ser duas ou três linhas na verdades, mas não se esqueça das quebras para torná-los mais convincentes–com alguma citação famoso seguida de uma declaração sobre como você vai iluminar o assunto. Varie isso a cada artigo e os leitores vão achar que você é, além de tudo, um erudito.

Parte IV – Do conteúdo, ou, da verborréia necessária

Se a introdução é complicada, o conteúdo em si é absurdamente simples. Tudo o que é necessário é uma quantidade razoável de verborréia parafraseadas, citada e puramente copiada e você está pronto para a glória.

Para acertar a mão, basta seguir os passos abaixo:

  1. Primeiro, encontre um autor que tenha escrito algo que seja pertinente ao seu assunto (mesmo que apenas de leve) e que esteja em voga. Atualmente, livros como A Lógica do Cisne Negro, Blink, The Tipping Point, Freakonomics, The Long Tail, The Big Switch, Linked ou qualquer outra nessa linha de assuntos modernosos que se propõem a explicar tudo sobre tudo.

  2. Livro escolhido, você precisa agora seguir um padrão bem simples: três parágrafos de paráfrase, ou seja, falando exatamente o que o autor falou em algum ponto do livro com suas palávras, e um parágrafo citando o autor do livro. Para cada conjunto desse, coloque um título parafraseado do próprio lido ou inventado na hora mesmo.

  3. Para não ficar ainda mais interessante, a cada dez ou doze parágrafos, introduza alguma citação ou paráfrase de outro autor. Se leitores vão achar você ainda mais erudito pela profundidade das correlações.

E é só. Desde que o artigo seja grande, o esforço será notado. Caso você não queira se dar ao trabalho de ler um livro ou mesmo escaneá-lo em busca de citações interessantes, um artigo em uma publicação da sua área também serve. Seja a InfoQ, Wired ou The New York Times, o importante é contar a estória direito.

Parte V – Da conclusão

Finalizar, ao contrário do que o seu professor dizia, não é tão complicado. Basta criar alguma expectativa no leitor de como ter lido aquele artigo mudou a vida dele ou explicar como, de posse das informações que você passou, que você tão cuidadosamente colou em um artigo de proporções avassaladoras, vai transformar a sua compreensão de tudo o mais e torná-lo mais erudito, famoso ou eficiente. Qualquer dessas palavras ou similares em uma frase já é vencedora.

Conclusão

Como você pode ver, o processo todo é simples (embora um pouquinho trabalhoso). Mas, como já diziam os antigos, no pain, no gain. Basta seguir as instruções, gastar uns 20 ou 30 minutos coletando citações de suas obras favoritas e você terá algo original, digno de uma mestrado ou doutorado.

Para terminar, depois de postar o texto, sente-se e aguarde as dezenas de comentários congratulando você por sua elegância, erudição e compreensão do mercado. Depois de tanto trabalho, você mereceu.


P.S.: Disclaimer Eu presumo que os leitores regulares vão perceber imediatamente que o texto acima é irônico. Mas, como várias pára-quedistas podem pensar o contrário, fica aqui o disclaimer. Não vai adiantar muito, provavelmente, mas o seguro morreu de velho.

Reduzindo o excesso de informações

October 19th, 2008 § 7 comments § permalink

Durante o Rails Summit ’08, vários dos palestrantes tocaram em um ponto que me chamou bastante a atenção: o tempo perdido com as várias ferramentas online que usamos como RSS, Twitter, IM e outros.

Com a movimentação pesada aqui na WebCo, nos últimos meses, o Twitter era algo que eu tinha praticamente abandonado, carregando apenas ocasionalmente para ver uma coisa ou outra referenciada pelo pessoal durante o dia. IM é algo que, felizmente, nunca usei tanto e passo a maior parte do dia sem mais do que uma conversa ocasional.

Já o RSS, nem de longe. Olhando a parte de Trends no Google Reader, fiquei meio que abismado com os números: mais de 230 subscrições, 250 textos lidos por dia, em alguns dias superando até isso. Obviamente, para “ler” isso tudo eu apenas corro o olho sobre a maioria dos títulos.

Mesmo assim, como os palestrantes acima comentaram, isso acaba sendo uma enorme perda de tempo que poderia estar sendo dedicada a coisas mais interessantes. A mesma seção de Trends apontou que a maior parte da minha leitura é feita antes do começo do dia de trabalho propriamente dita e no período de dez da noite à uma da manhã. No mínimo, sono perdido que não dá para recuperar.

Depois de ficar meio encafifado com a coisa toda, resolvi fazer uma limpeza geral do Google. A primeira coisa foi limar mais de 130 feeds que não leio mais por um motivo ou outro. O segundo passo foi modificar a forma de categorização dos feeds: removi toda a categorização antiga e dividi o que sobrou em quatro novas categorias de prioridade: blogs para leitura diária, blogs para ler nos momentos vagos ao longo do dia se houverem, blogs para leitura semana, e o restante deixei em uma lista de leituras ocasionais.

Obviamente, isso tudo só vai funcionar se eu seguir a priorização. Caso não dê certo, há sempre a possibilidade de simplesmente deixar a leitura completa somente para os fins de semana. Mas considerado que apenas uns poucos blogs estão na leitura diária (e não são pessoas que postam diariamente) e que menos do que uma dúzia estão na próxima categoria, acho que dá para gerenciar.

Eventualmente, conto se deu resultado ou não.

Rails Summit ’08

October 17th, 2008 § 0 comments § permalink

Como mais de quinhentos outros Railers do Brasil, participei ontem e ante-ontem do Rails Summit ’08. Foram dois dias intensos de bastante palestras e conversas no corredores e salões do Anhembi, e, como a maioria dos participantes, fiquei bem satisfeito com a experiência.

Esse foi o primeiro evento brasileiro de Rails de larga escala, contando com a participação de palestrantes da comunidade Rails internacional e para uma primeira edição ficou bem além das expectativas que qualquer um poderia ter tido. A organização foi impecável, tanto no que prometeu fazer quanto no que teve que resolver quando algumas coisas não saíram como previsto e o resultado final foi um evento de qualidade que nada ficou a dever a conferência do mesmo porte que já são realizadas para outras comunidades.

Outros blogueiros já falaram bastante sobre as palestras e acontecimentos e não vou me estender mais sobre o assunto. Para um outro apanhado geral, o livestreaming do evento que preparamos aqui na WebCo também mostra tudo que o pessoal andou falando e ainda está falando sobre o Rails Summit.

Finalizando, um mega-parabéns ao Akita pelo esforço demonstrado antes e durante o evento na promoção da comunidade aqui no Brasil.

Balanço cultural de setembro

October 17th, 2008 § 0 comments § permalink

Como o mês foi bem movimentado, acabou que não deu tempo de escrever sobre o que andei lendo e assistindo nos últimos tempos. O resultado de setembro foi:

  • 8 livros
  • 12 filmes
  • 12 episódios de séries

Nos livros, comecei o mês com Linked, do Albert-László Barabási. O livro é essencialmente uma narrativa da história em torno da pesquisa sobre redes e o que essa pesquisa significa para as várias áreas de conhecimento humano. Barabási é famoso pela sua participação em vários dos trabalhos seminais sobre o assunto e oferece uma visão simples e ao mesmo tempo ampla sobre o assunto em um livro que leigos podem aproveitar inteiramente. Aliás, é um excelente livro para ilustrar alguns aspectos da recente crise econômica para quem deseja entender um pouco mais sobre a fragilidade de redes.

Seguindo, foi a vez de The Last Colony, o terceiro volume na trilogia Old Man’s War de John Scalzi. Esse é o volume mais fraco da série, sem tanta caracterização e com uma linha narrativa um pouco convoluta mas ainda é divertido o suficiente para valer a pena completar a trilogia. Nesse livro, John Perry e sua agora esposa Jane Sagan voltam para liderar uma colônia nova a pedida da União Colonial e acabam se envolvendo em um conflito de proporções enormes que pode ameaçar a própria espécie humana.

Depois disso, foi vez de Infoquake, por David Louis Edelman. Esse é o primeiro volume em um trilogia chamada Jump 225 e é um começo bem promissor. Edelman cria um futuro onde humanos utilizam tecnologia rotineiramente para atualizar seus corpos e os programas para isso são comercializados em um ecossistema econômico dinâmico, extremamente volátil e perigoso. O livro acompanha a trajetória de um jovem empresário que deseja subir ao topo desse mundo e se envolve com uma nova tecnologia chamada MultiReal que promete revolucionar complemamente o mercado. Natch, o protagonista, é manipulador e inescrupuloso, e ainda assim, simpático, o que tornar a narrativa bem interessante.

O quarto livro do mês foi Brasyl, por Ian McDonald. McDonald passou três meses no Brasil pesquisando para o livro e a estória se passar em torno de três possíveis versões do Brasil: uma no século 18, seguindo um agente jesuíta nas selvas amazônicas; uma em 2006, seguindo uma produtora de reality shows no Rio de Janeiro; e uma em 2032, seguindo um jovem empresário em São Paulo. As três estórias se juntam em uma misteriosa tecnologia que permite a movimentação por entre os múltiplos possíveis mundos. McDonald fez o seu trabalho e mostra um razoável conhecimento geográfico do Brasil, conseguindo inserir isso na trama, mas, como qualquer autor estrangeiro tentando fazer a mesma coisa, falha miseravelmente em várias áreas culturais. O livro é ao mesmo tempo intrigante e frustante nesse aspecto. Vale a leitura, mas o leitor deve se preparar para várias concepções erradas sobre o Brasil.

Seguindo, reli Ender’s Game, o livro mais famoso de Orson Scott Card. Fazia tempo que eu não revia a estória de Andrew Wiggins e sua preparação para lutar contra os buggers, uma espécie alienígena que ameaça a Terra. O livro é considerado um dos maiores clássicos de SF tanto pela caracterização feita por Card quando pelas surpresas e a nova leitura foi tão interessante quanto as anteriores. A surpresa final da primeira leitura foi substituída pela compreensão das sutilezas que Card acrescenta à narrativa e isso prova a força original do livro. Vale a leitura repetida.

Depois disso, li o diminuto Whatever You Think, Think the Opposite, por Paul Arden. O livro se apresenta com uma série de conselhos para o sucesso mas acaba sendo um monte de clichés sobre como supostamente viver sua vida de maneira diferente e como oposto do usual é o ideal. Bobinho e nada inspiracional.

O penúltimo livro do mês foi The Lions of Al-Rassan, por Gavriel Guy Kay. O livro se passa no mesmo mundo de The Last Light of the Sun, que eu havia lido anteriormente e é igualmente evocativo e doce-amargo. Kay consegue mostrar um mundo inteiramente real e povoado por pessoas que você quase consegue acreditar terem existido como figuras históricas. Neste livro, a inspiração vem dos Mouros, no fim de sua época de dominiação árabe sobre a península ibérica, e a subseqüente Reconquista. A estória segue a vida de dois homens cujos destinos os colocam primeiro em favor um do outro e depois contra o outro a serviço de seus respectivos monarcas e povos. No meio disso, o destino das mulheres que amam, filhos e aliados tornam a estória inteiramente crível e marcante. Kay é certamente um dos melhores autores de ficção histórica atualmente e esse livro prova sua força mais uma vez.

Para fechar o mês, li The Difference Engine, uma colaboração entre William Gibson e Bruce Sterling que reconstrói a época vitoriana da Inglaterra em um mundo em que Babbage conseguiu desenvolver seu computador mecânica e a Revolução Digital aconteceu ao mesmo tempo que a Industrial. O livro é mais uma apanhado de estórias que se passam durante essa época, ilustrando diversos aspectos da sociedade, do que um todo coerente. Como muitos outros leitores, eu senti que esse aspecto tirou qualquer graça do que poderia ter sido um fascinante exemplo de steampunk.

Nos filmes, comecei o mês com American Gangster. Denzel Washington, como de costume, está soberbo em sua interpretação de Frank Lucas, um rei da heroína dos anos 70 em Manhattan, e Russell Crowe também não está tão ruim. Não chega aos pés de Dia de Treinamento, mas vale a pena.

Hellboy 2, o filme seguinte, decepcionou um pouco. Enquanto o primeiro era cheio de humor, bem acabado e com uma estória que fazia sentido em todos aspectos, o segundo pareceu uma desculpa para mostrar efeitos especiais. A estória é quase inexistente, a interpretação de alguns atores bem forçada e os efeitos visuais dão a sensação de que o filme se chama O Labirinto do Fauno. A única coisa razoável foi a representação dos “elfos” do filme.

The Happening foi mais uma prova de que M. Night Shyamalan deveria se dedicar a fabulas e esquecer filmes de suspense. Ele só consegue suspense corretamente quando tenta fazer outra coisa. O filme é grotesco na falta de mistério e nas tentativas patéticas de dar sustos no espectador.

O filme seguinte foi Shoot ‘Em Up que é uma comédia de ação com Clive Owen, que no filme é um pistoleiro que resgata um bebê de ser morto por “homens de preto” e tem que proteger o pimpolho com a ajuda de um prostituta e sua infalível mira. Cine pipoca de primeira qualidade para ser visto sem preocupação com a verosimilhança de qualquer coisa.

The Kingdom é um tentativa de mostrar que terrorismo gera terrorismo e que tudo pode ser visto de ângulos diferentes e explicado assim, mas também falha em porque tenta ser tudo ao mesmo tempo, um filme de ação com uma mensagem filosófica que acaba não dando em nada.

21, baseado na história do grupo de contadores de cartas do MIT é razoavelmente interessante, mas não chega a ser tão bom quanto as críticas levaram a crer. O tema é legal, mas acreditar que o tipo de ação representada no filme poderia enganar a segurança de um cassino por mais do vinte segundos é pedir demais. Tudo bem que o filme precisa de amenizar as coisas para a audiência, mas o resultado foi bem exagerado e tira um pouco da graça do filme.

O último destaque do mês foi Tin Man, uma deliciosa reinvenção de O Mágico de Oz com um tom de ficção cientifíca e steampunk. Os demais filmes, infelizmente, foram uma perda de tempo.

Rails é o novo ASP

October 7th, 2008 § 40 comments § permalink

Eu achei que o efeito ASP demoraria mais tempo para acontecer, mas que nada, o futuro já está aí.

Amigo meu pegou dois projetos esses dias para manter. Olhou o código e desistiu imediatamente com horror profundo. Eu não vi o código, mas, pelo que ele mencionou, o código do Windows provavelmente é menos complicado do que essas aplicações Rails.

Rails é novo ASP. ASP está morto. Viva o Rails.

Atualização: Eu amo os pundits!

Where am I?

You are currently viewing the archives for October, 2008 at Superfície Reflexiva.