Tecnologia. Inteligente.

Outro dia (vários meses atrás) li em sites de noticia uma nota sobre o falecimento de um adolescente, vítima de uma queda do telhado de sua casa. O motivo: exibicionismo. O fato é que o rapaz nasceu sem a capacidade de sentir dor física.

Apesar da dor ser um fenômeno necessário para a vida humana (o sentimento de dor pelo menos inibe os seres humanos de se jogarem de telhados ;-), uma vida sem dor é o sonho de todos que passam por momentos difíceis.

Agora vamos ao tema desse post: o caminho para essa panacéia já esta sendo trilhado pela ciência atual. Há pouco mais de um ano (o artigo científico foi publicado no final de 2006), o perfil genético de pessoas que não podem sentir dor física foi traçado. Chegou-se à mais espetacular conclusão: um único gene, o SCN9A, estava mutado, impedindo o funcionamento correto da proteína que ele codifica.

Essa proteína, situada na membrana de células neuronais, denominada canal para sódio dependente de voltagem , tem o papel (grosso modo) de permitir a entrada do íon sódio nas células. Estas proteínas estão diretamente relacionadas com o papel da nocicepção, pois regulam o estimulo elétrico em neurônios e fibras nervosas relacionados à dor. Daí o nome da doença da insensibilidade: chanelopatia associada à insensibilidade à dor (tradução livre).

O legal agora seria a descoberta de uma droga que atue bloqueando especificamente esse canal. Só lembrando que substâncias bloqueadoras de canais de sódio já são conhecidas. Sabe aquele peixe muito apreciado no japão, mas venenoso, o baiacu, ou Fugu? Pois é, ele produz uma das toxinas mais potentes já conhecidas, a tetrodotoxina, que bloqueia especificamente canais de sódio dependentes de voltagem. Paralisa e mata a vítima em poucos minutos.

Agora é só desejar toda a sorte aos cientistas que estão trabalhando com isso (e mais ainda às suas cobaias)! Quem sabe em breve surgirá o analgésico mais poderoso já conhecido.

Eu me lembro muito bem a extasiante sensação de ser aprovado no vestibular. Na época eu fui aprovado em duas escolas, uma privada e outra pública. As duas excelentes. As duas me agradavam na mesma proporção. Mas, curiosamente, a alegria de passar na segunda era maior. Na época eu achei que era porque a escola em questão era mais perto de onde morava minha família mas hoje eu sei que não se trata disso. Na verdade a diferença mesmo é que a escola pública é “de graça” (nem preciso explicar as aspas). Hoje eu entendo muito bem que “receber” dinheiro público ao invés de pagar é uma fonte de enorme satisfação pessoal!

Felizmente está cada vez mais viável conseguir dinheiro do governo para fazer coisas “interessantes”. O país tem evoluido de maneira louvável neste sentido e a legislação cada vez mais prevê mecanismos para alimentar constantemente o mercado com inovações tecnológicas. Por favor não venha com flames por eu estar defendendo o governo quando o sistema de ensino público sofre com orçamentos muito aquém do necessário e com regulamentações totalmente arbitrárias e eleitoreiras. Na verdade estou apenas elogiando a evolução da legislação brasileira no sentido de criar fundos, órgãos e mecanismos para fomentar a pesquisa direcionada a inovação tecnológica.

Os fundos setoriais são um bom exemplo do que estou falando. Empresas
como as grandes distribuidoras de energia elétrica, por exemplo, são obrigadas a destinar parte do seu faturamento a fundos cujos recursos são utilizados por órgãos como a FINEP para fomentar projetos de inovação tecnológica na área.

Outras iniciativas mais recentes dizem respeito a criação entidades (nas diversas esferas da administração pública) cujo fim é especificamente gerir processos de inovação tecnológica nos mais variados setores da economia. Esse tipo de entidade é, na minha opinião, a grande peça-chave que faltava para que o ciclo de inovação contínua se fechasse e garantisse o gradual avanço tecnológico do país nas mais variadas áreas. Até então tínhamos excelentes escolas e centros de pesquisa, fontes de financiamento (agências como o CNPq, FINEP, FAPEMIG etc) com recursos garantidos pela legislação vigente e todo o suporte legal para o incentivo a projetos de inovação tecnológica mas não tínhamos o essencial: entidades cuja operação consistisse em juntar todas essas peças e facilitar a vida de uma empresa ou de um pesquisador que quisesse criar um produto inovador e lançá-lo no mercado. Uma espécie de SEBRAE voltado para empresas de base tecnológica.

Isso ainda é incipiente mas a evolução é visível. O Governo de Minas Gerais, por exemplo, criou cinco pólos de excelência no Estado, com o objetivo de coordenar e orientar o desenvolvimento econômico das regiões conforme a vocação de cada uma. Eles estão reunindo todas as informações sobre os segmentos da economia em que Minas Gerais detém tradição e expertise. Já estão em funcionamento o Pólo de Excelência do Leite, em Juiz de Fora; o Pólo de Excelência do Café, em Três Pontas; o Pólo de Excelência em Florestas, em Viçosa; e o pólo Mineral e Metalúrgico, no Vale do Aço. As atividades desses pólos de excelência ainda não estão totalmente formatadas mas a idéia é que eles sirvam de catalizadores em suas respectivas áreas de atuação, de maneira a aproximar o trabalho de produção científica do mercado. Para centralizar as atividades dos pólos ainda foi criado o Sistema Mineiro de Inovação que deve atuar como uma espécie de entidade de classe para empresas de base tecnológica que trabalham com inovação, compilando problemas comuns, provendo orientação sobre a legislação pertinente e a participação em editais públicos de subvenção econômica etc.

Quando todos esses processos estiverem maduros, será bem mais fácil você transformar aquela sua brilhante idéia inovadora em um produto disponível no mercado. Isso pode não ser tudo mas é essencial para que o país tenha uma economia competitiva e moderna.

Escalabilidade é um conceito importante em qualquer sistema web, embora eu ache que às vezes as pessoas se preocupam demais com isso. A grande maioria das aplicações web simplesmente não precisam escalar muito. Existe, então, um trade-off entre tempo de desenvolvimento e o esforço extra necessário para planejar e implementar sua arquitetura de forma a escalar da melhor maneira possível. Quando você não precisa lidar com enormes volumes de dados e usuários simultâneos, muitas vezes a decisão correta, do ponto de vista de negócio, é minimizar o tempo de desenvolvimento e arcar com algum custo extra de hardware caso preciso. Hardware que fica mais barato a cada dia.

Existem outras alternativas, que tentam garantir que sua aplicação é escalável sem cobrar um preço caro em termos de tempo e esforço de desenvolvimento. Um ponto chave é minimizar o compartilhamento de dados entre componentes da sua aplicação. Se você não compartilha nada, fica mais fácil escalar. Esse modelo, chamado de “shared nothing”, é encorajado por diversos frameworks para desenvolvimento web, e é praticamente obrigatório quando se desenvolve com Ruby on Rails, por exemplo.

Quando sua aplicação segue o modelo “shared nothing”, você pode obter escalabilidade simplesmente usando os serviços da Amazon. Precisa de mais servidores web? Adicione instâncias à sua conta da Elastic Computing Cloud. Precisa de mais servidores de banco? A mesma coisa, mas as instâncias são configuradas de outra forma (que você pode definir, através de uma imagem de máquina virtual). Espaço em disco? Sem problema. Tudo sobe e desce de forma quase instantânea. Um grande avanço comparado ao processo tradicional de estimar suas necessidades de hardware e comprar os servidores com alguma antecedência — ou sair correndo para apagar o incêndio quando ele estoura.

Pois agora tem gente que acha que mesmo serviços como os da Amazon são muito complicados. Estão querendo transformar escalabilidade em algo totalmente transparente para o desenvolvedor. Um exemplo disso é a Heroku, que lançou recentemente um serviço de escalabilidade automática. Você registra sua aplicação (Ruby on Rails) com eles e eles cuidam de escalar usando os serviços da Amazon. Você não precisa se preocupar com a monitoração dos seus nodos de processamento, decidir quando adicionar ou remover nodos, etc. Você pode até desenvolver sua aplicação usando um IDE web que eles oferecem.

Claro que um serviço desses tem suas desvantagens. Em primeiro lugar, você perde em flexibilidade: vai ter que usar as versões de Ruby, Rails e bibliotecas que a Heroku suporta. Não há como integrar facilmente sua aplicação com sistemas legados. E assim por diante.

Mesmo assim, é mais um grande avanço em uma das tendências-chave por trás da Web 2.0: a redução de barreiras de entrada. Cada vez que um obstáculo técnico ao sucesso de um produto web é removido, fica mais fácil e barato desenvolver novos produtos inovadores. Sob essa ótica, viva a escalabilidade transparente!

Jornada nas Estrelas, processamento de linguagem natural, e o que os computadores podem fazer para lhe ensinar a causa da Dengue

Numa cena antológica do filme Jornada nas Estrelas IV: A Volta para Casa, a tripulação da USS Enterprise volta no tempo para o longínquo ano de 1986. O engenheiro-chefe Scotty então se vê diante de um computador da época (um Mac Plus, da Apple), e, da forma mais natural do mundo, começa a falar com o micrinho, que se recusa a responder. O Dr. McCoy, então, gentilmente entrega a Scotty o mouse que estava em cima da mesa. Scotty sorri, pega o mouse como se fosse um microfone, e fala de novo: “Computador…” (veja essa cena no Youtube).

A cena virou uma piada recorrente contada por todo mundo que sonha com computadores capazes de estabelecer um diálogo de forma natural com o usuário - como os computadores da ficção científica e dos quadrinhos (o Bat-computador não precisa de mouse ou teclado!). E, mesmo hoje em dia, não é incomum usuários inexperientes digitarem em serviços de busca como o Google frases completas, conversacionais (”em que ano o Rio de Janeiro foi capital do Brasil ?”).

Obviamente, não é assim que funciona; o próprio Google, considerado por muitos o serviço de busca mais sofisticado da Internet, não faz absolutamente nada referente ao que chamamos de Processamento de Linguagem Natural (em inglês, Natural Language Processing), as técnicas usadas para compreender frases escritas na língua do dia-a-dia dos humanos. Ao invés disso, o Google, como todos os outros serviços de busca tradicionais, simplesmente conta quantas vezes as palavras aparecem nas páginas e nas pesquisas dos usuários (uma abordagem simples, mas que dá bons resultados em muitos casos).

 Quer dizer que Processamento de Linguagem Natural é ficção científica ? Não, de jeito nenhum! Empresas como a californiana Powerset oferecem (em breve, para o público) um sistema de busca capaz de “compreender” linguagem natural.  E nossa equipe no Vetta Labs trabalha há vários anos em tecnologia capaz disso - com resultados surpreendentes.

O sistema que desenvolvo atualmente, o RelEx, Semantic Relation Extractor, extrai informações semânticas (isso é, relativas ao signficado) de um texto, baseando-se em técnicas sofisticadas de análise sintática (identificação de “sujeito”, “predicado”, como aprendemos no ensino fundamental), algoritmos semânticos construídos manualmente e uso intensivo de técnicas de aprendizado de máquina. E o mais interessante disso tudo é que praticamente todo o código é open source (ainda que árido para desenvolvedores não familiarizados com essa área).

E o que o RelEx faz ? Imagine que você quer saber, por exemplo, o que causa a dengue. Se uma página na internet tem a frase Dengue is caused by four closely related virus serotypes of the genus Flavivirus, mas você procura num serviço de busca tradicional dengue microbe, você não encontra coisa alguma.

Se procura Which virus causes Dengue ?, numa tentativa de busca com linguagem natural, também não dá em nada (porque a frase na página diz Dengue is caused by Flavivirus, não Flavivirus causes Dengue).

A tecnologia usada no RelEx interpreta tanto a frase na página quanto a sua pergunta, e consegue casar ambas por compreender, por exemplo, que Dengue é uma doença, vírus um agente patológico, e que vírus que dá dengue e dengue é causada por quê ? referem-se à mesma coisa.

Como uma imagem vale mais do que mil palavras, vejam só como o RelEx “enxerga” as frases do exemplo:

Fica simples então casar a variável (associada à palavra which) à palavra Dengue.

É claro que por trás  das imagens bonitinhas há muito mais coisas interessantes. Por exemplo, é trivial obter análise sintática tradicional:

(S Which virus (VP causes (NP Dengue)) ?)

E informação semântica específica também é produzida:

^1_Temporal_colocation:Event(present,cause)
^1_Temporal_colocation:Time(present,cause)
^1_Causation:Affected(cause,virus)
^1_Transitive_action:Agent(cause,virus)
^1_Causation:Effect(cause,Dengue)

Definitivamente, Processamento de Linguagem Natural não é ficção científica - mas pode ser tão divertida quanto!

Quem trabalha com “Desenvolvimento Web” quase certamente já ouviu falar de Ruby On Rails. Assim como muitas tecnologias, RoR (pra encurtar) gerou muito hype nos últimos meses e, consequentemente, uma legião de fanboys que pregam fervorosamente que RoR é a melhor coisa que já inventaram desde o pão-fatiado.

O quê

Mas em que consiste exatamente o tal “Ruby On Rails”? Traduzindo diretamente do site oficial:

Ruby On Rails é um framework web de código aberto que é otimizado para a satisfação do programador e produtividade sustentável. Ele permite que você escreva código elegante ao favorecer convenção ao invés de configuração.

E ainda:

Ruby On Rails é um framework completo para desenvolvimento de aplicações web de acordo com o padrão Model-View-Controller (ou MVC).

Até aí, nenhuma novidade. Antes da popularização de RoR, já existiam diversos outros excelentes frameworks como ASP.NET, a pilha Servlets+JSP+Struts+Hybernate e PHP/Zend, só pra citar alguns. O diferencial de RoR está justamente na adoção da metodologia de desenvolvimento de software “Ágil”, ao focar as funcionalidades do framework nas necessidades diretas dos desenvolvedores e diminuir tanto quanto possível o tempo gasto com instalação e configuração do ambiente.

Por esse motivo, RoR se tornou especialmente popular entre desenvolvedores e empresas que adotam processos semelhantes ao “Extreme Programming”, onde a elaboração rápida de um protótipo e a constante refatoração do código são essenciais. RoR realmente prima nestes casos. Chega a ser assustador a facilidade com que se gera o esqueleto e o protótipo de uma aplicação MVC, ou o número ínfimo de linhas de código que são necessárias para implementar funcionalidades relativamente sofisticadas.

Porquê

Descontando um pouco do exagero típico dos fanboys, é fácil notar com pouco tempo de uso porque Ruby On Rails se popularizou tão depressa.

• Convenção ao invés de Configuração: Levante a mão quem nunca perdeu pelo menos umas 2 horas de trabalho tentando instalar ou configurar uma aplicação/sistema/etc e descobriu no fim do dia que o problema era um “;”, ou um path errado. Pois é, RoR procura acabar com essa dor-de-cabeça ao eliminar tanto quanto possível os malfadados arquivos de configuração através da adoção de uma série de convenções que permite integrar as diferenças partes do framework sem praticamente nenhuma intervenção direta do desenvolvedor.As convenções englobam todo tipo de aspecto de uma aplicação web: o nome dos modelos e tabelas relacionais associadas; o nome da colunas das tabelas que constituem chaves primárias e estrangeiras; o nome dos arquivos e das classes que implementam cada camada da estrutura MVC; o nome e identificador dos campos HTML e diversas outras.
• ActiveRecord: Active record é um design pattern utilizado para acessar bancos de dados e fazer o mapeamento Objeto-Relacional. O padrão em si é bem mais antigo do que RoR, mas a implementação utilizada em RoR em específico prima pela qualidade e é um dos pontos fortes e mais badalados do framework. A extensa utilização de instrospeção, tanto do lado da estrutura relacional, quanto da parte das classes e objetos torna praticamente desnecessário escrever mais do que meia dúzia de linhas de código para se fazer o mapeamento de uma classe/tabela.
• ActionView: Da mesma forma que o módulo ActiveRecord é responsável pela implementação dos modelos, ActionView é o módulo responsável pela implementação das visões. O diferencial está no fato de este módulo ser fortemente influenciado pela metodologia ágil: quase todas as funcionalidades tipicamente utilizadas para construção de uma interface web podem ser adicionadas através de uma API concisa e intuitiva. Mesmo as tendências mais recentes das aplicações Web modernas — como Javascript, DHTML e AJAX — estão fortementes integradas ao framework. Em RoR, usa-se apenas uma linha de código para adicionar funcionalidades relativamente complexas como “atualizar uma tabela/list assincronamente” ou “adicionar um campo de texto com auto-sugestão” (no estilo Google Suggest))
• Plugins: Outra grande vantagem de Ruby On Rails é sua extensibilidade. Devido à sua crescente popularidade, existem hoje literalmente centenas de plugins (normalmente gratuitos) disponíveis para os desenvolvedores incrementarem suas aplicações conforme as necessidades individuais de cada projeto — permitindo assim que uma gama enorme de problemas sejam rapidamente resolvidos sem necessariamente tornar o core do framework demasiadamente inchado. Mas cuidado: em alguns casos, é preciso ficar atento para não se perder mais tempo escolhendo o melhor plugin que implementa uma deterinada funcionalidade do que efetivamente instalando e utilizando o plugin.
• Ruby: Flamewars discutindo qual a melhor linguagem são quase tão antigas quanto a própria computação — portanto não vou me alongar demasiadamente nesse tópico — mas é inegável que parte da atratividade de RoR advém da linguagem Ruby. Pra quem ainda não conhece, sugiro o tutorial rápido do site oficial, ou ainda o divertidíssimo“Guia Pungente”, por “Why The Lucky Stiff”.

Por que não

Nenhuma boa análise técnica estaria completa sem uma seção de “Contras”, e esse post não poderia ser diferente.

• Performance: Um dos compromissos que precisam ser feitos para se tirar proveito da elegância e agilidade de se utilizar uma linguagem como Ruby é o desempenho. Por ser uma linguagem dinamicamente tipada que executa sobre uma interpretador (pra lá de ineficiente, diga-se de passagem), Ruby On Rails é inegavelmente um framework com overhead alto. Muita gente vai argumentar que baixa performance não é tão crítico se sua arquitetura tem boa escalabilidade, e outros ainda irão citar diversas técnicas para minimizar esse overhead, mas ainda assim, em alguns casos a recomendação é deixar de usar justamente as funcionalidades que tornam o framework interessante.Por outro lado, as comunidades por trás de Ruby e RoR estão cientes desse problema e tem trabalhado para atenuá-lo. A versão 2.0 de RoR, por exemplo, já apresenta significantes melhorias, e a próxima grande revisão da linguagem Ruby que deve ser lançada ainda nessa década também promete ganhos substanciais de performance, graças à utilização de um nova máquina virtual.
• Código legado: Uma das máximas de RoR — “Convenção ao invés de configuração” — perde seu appeal quando consideramos sistemas legados. Nesses casos, é provável que sua base de dados ou suas classes existentes não tenham adotado as mesmas convenções utilizadas por RoR. Com isso, é necessário adicionar diversas diretrizes no código para sobrescrever os valores e padrões utilizados pelas tais convenções. Não chega a ser a mesma dor-de-cabeça de se editar um “hibernate.cfg.xml” ou um “web.xml”, mas é possível que você acabe sendo forçado a escrever alguns trechos de [gasp!] SQL.
• Documentação: Algumas tecnologias promissoras perdem momento devido à carência de documentação. Ruby On Rails sofre do problema inverso: excesso de documentação. Hoje em dia é natural utilizar a Internet para buscar por trechos de código, recomendações, receitas ou (no caso de RoR) plugins para se solucionar um problema específico ou implementar corretamente uma funcionalidade. O problema é que, frequentemente, a documentação ou plugin encontrados estão defasados por terem sido escritos/implementados com foco em uma versão do framework que já está deprecada. Como o desenvolvimento de RoR é muito dinâmico — a versão 1.0 foi lançada em Dez/05; a versão 1.1 em Mar/06; a 1.2 em Jan/07; e a 2.0 em Dez/07 — e não existem garantias de compatibilidade, muitas vezes torna-se difícil encontrar a solução correta para a versão específica do framework que você está utilizando.

Pra finalizar

Se você se é desenvolvedor Web, mora em Belo Horizonte, se interessou por Ruby On Rails e gostaria de saber mais a respeito, o Instituto Turing está oferencendo um curso intensivo à partir do dia 14 de abril. Para maiores informações, mande e-mail para cursos@institutoturing.org.

As vezes escutamos afirmações do tipo: “Vazamentos de memória são comuns em linguagens baixo nível. Coisas do passado. Linguagens modernas estão livres desse pesadelo.” Quem acredita nisso também deve acreditar em coelhinho da Páscoa, Papai Noel e certamente em “almoço grátis”. Linguagens “modernas” que utilizam gerenciamento próprio do espaço de memória no processo (como Java e .Net) também podem produzir vazamentos de memória ou sofrer com o mau uso da memória. Claro que não tão frequentes quanto em C ou C++, mas essas linguagens também permitem a construção de sistemas ou componentes com um consumo de memória sempre crescente, contra a vontade do desenvolvedor.

Lembro-me de que nos longínquos anos 90, quando falavam de Java a performance era o ponto mais questionado. Com o passar do tempo e a evolução do hardware, esse ponto foi deixado de lado. Hoje o comentário sobre sistemas em Java mais comum é que “consomem muita memória”. Mas algumas vezes, isso apenas mascara para o cliente o verdadeiro problema: vazamento de memória.

Durante minhas experiências profissionais já vi soluções brilhantes (e outras nem tanto) para vazamentos de memória. Algumas específicas para uma ou outra arquitetura ou ambiente, outras genéricas (de uso geral). Fazendo uma analogia com o mundo palpável, vamos supor que um vazamento de memória seja uma torneira gotejando sobre um balde. Se o balde entornar, o cliente pode ficar muito bravo. Vamos então a alguns exemplos de soluções para nossa torneira:

• Aumento de memória: No mundo das grandes corporações, a primeira e mais comum solução é aumentar o tamanho do balde! Isso é fácil, barato, e de rápida implementação e de resultado instantâneo: O que demorava 1 semana, agora demora 1 mês;
• Restart da aplicação: Outra solução comum, quase tanto quanto a anterior nas grandes empresas. Durante a noite, quando geralmente o gotejar é mais lento, você pega o balde, corre e joga a água fora em um lugar apropriado. Um ponto importante é que tem que ser rápido o suficiente pra fazer o trabalho entre uma gota e outra. Caso contrário algumas gotas caem no chão. Mas o cliente pode nem perceber o piso molhado.
• Bloquear o acesso ao módulo: se não for uma torneira útil, você pode simplesmente fechar o registro para esta tubulação. Se alguém precisar da torneira, que use a de outro lugar.
• Liberação de memória logo após a alocação: Isso só é possível em alguns ambientes e sistemas (por exemplo, os feitos em C). É difícil de imaginar, mas existe! Trocamos o balde por cachorro, treinado, jeitoso e delicado (por exemplo um dog alemão) pra beber as gotas de água que goteja. O cão pode ficar ali durante horas. E funciona bem. Mas ele vai sair do lugar, pra realizar outras necessidades, ou porque deu vontade mesmo. Que a água vai pingar no chão vai, mas ninguém saberá exatamente quando nem quanto.
• Resolver o vazamento de memória: Essa é a última solução. Muita gente acredita que a hora do bombeiro é cara, outros acham que a torneira já está muito velha mesmo, e a solução seria trocar todo o encanamento. As vezes a solução não compensa mesmo. Mas algumas vezes a torneira está vazando por um motivo simples : não foi fechada direito. Outros casos podem ser mais complicados: seu mecanismo interno está estragado, foi montada com peças de má qualidade ou foi montada com peças de boa qualidade, mas foi montada de forma errada.

Para resolver vazamentos ou mau uso de memória uma ferramenta de qualidade é indispensável. Depois de entender o fluxo de execução do sistema ou componente, a utilização de ferramentas de profiling nos dá o “mapa da mina”. Dentre as existentes, duas que merecem destaque são:

- YourKit: para sistemas desenvolvidos em Java e C#, uma ferramenta de grande utilidade é um profiler como o YourKit, já comentado em um post anterior. O YourKit possui um recurso excelente pra procurar por vazamentos de memória e mesmo analisar sua utilização após o start: é possível criar snapshots da memória do processo para uma posterior verificação. Sem degradação da performance do sistema, este recurso em algumas situações pode ser usado inclusive no ambiente de produção.

- Valgrind: é a ferramenta indicada para uso em sistemas desenvolvidos em C e C++. Com ele são detectados os pontos onde memória ou objetos alocados e “esquecidos” na memória, e também a distribuição do uso memória pelos objetos e módulos do sistema. Além de vazamentos de memória, é possível detectar um mal uso da memória do sistema. Mas o Valgrind é uma ferramenta pesada, impossível de ser utilizada em ambientes de produção.

Embora algumas vezes a correção do problema não é viável, sua identificação sempre é. Depois da compreensão do funcionamento de um módulo e o uso correto de ferramentas de análise de memória é possível identificar qualquer vazamento de memória. Mas qual decisão tomar com essa informação? Solucionar o problema, utilizar um “ajuste técnico de contorno” ou simplesmente deixar como está ? Isso já é trabalho da gerência.

Há algum tempo contei das minhas experiências com o Firefox 3 beta 4. Fiquei impressionado com o desempenho, mas alguns bugs ainda me incomodavam (especificamente, a caixa de texto de Compose do GMail se corrompia, mostrando linhas e pixels espúrios enquanto eu digitava).

Ontem eu comecei a usar a nova beta 5. Surpreendentemente ela é ainda mais rápida que a beta 4, e resolveu todas as questões que levantei no outro post. Até onde vi, é um browser pronto para uso no dia-a-dia; o consumo de memória está baixíssimo (e sem memory leaks; a beta 4 rodou por vários dias sem iniciar, até ser substituída por essa nova).

Acreditem: o Firefox 3 beta 5 é o melhor browser que conheço - não tem para Safari, Opera ou (ha-ha!) Internet Explorer.

Como eu disse no post anterior sobre o desafio da Netflix, a grande maioria dos times no topo da tabela de classificação utiliza variações dos mesmos algoritmos básicos. Cada time cria novas formas de tornar os algoritmos mais sofisticados e inteligentes, refinando suas técnicas de forma incremental.

Computadores que jogam Xadrez funcionam da mesma maneira: todos os melhores programas utilizam variações do mesmo algoritmo básico. O algoritmo original é bastante simples, mas as variações são cada vez mais complexas e ricas, refletindo avanços incrementais e bastante focados.

Muitas vezes esse foco em sofisticação da tecnologia faz com que as pessoas ignorem idéias muito mais simples e eficazes. Um bom exemplo aconteceu recentemente em Stanford, onde o Prof. Anand Rajaraman ministra uma matéria de mineração de dados. Como trabalho final na disciplina, vários grupos de alunos atacaram o problema da Netflix.

A maioria dos grupos agiu de forma parecida com os times que lideram o desafio, criando variações complexas e refinadas de algoritmos de recomendação simples. O grupo que se deu melhor, e chegou perto dos melhores resultados na tabela de classificação, usou um algoritmo muito simples e, ao invés de refiná-lo, melhorou os dados. Eles aumentaram os dados iniciais com meta-informação sobre cada filme extraída do IMDB. Com dados melhores e mais ricos, um algoritmo simples bateu técnicas bem mais sofisticadas.

Algum tempo atrás, durante o desenvolvimento de um dos nossos produtos, surgiu a necessidade de codificarmos uma daquelas features recorrentes em vários sistemas de computação: um estimador de tempo, que daria ao usuário uma previsão de quanto tempo uma tarefa levaria para ser concluída.

A reação intuitiva da grande maioria das pessoas é acreditar que um estimador de tempo é algo fácil, talvez até óbvio de ser feito. Quem nunca riu das estimativas de tempo fora da realidade fornecidas por vários programas, bem como de suas barras de progresso “loucas” que avançam aos saltos de forma bizarra e às vezes até retrocedem? Elas soam engraçadas em parte porque estão executando de maneira esdrúxula uma tarefa que deveria ser fácil. Afinal, um computador é uma máquina determinística, e sabendo as complexidades dos algoritmos envolvidos, o tamanho da massa de dados que os mesmos usam de entrada, e a capacidade de processamento da máquina ou máquinas executando o sistema, é trivial calcular o tempo requerido para uma tarefa completar, certo?

Errado.

Na prática, um computador do mundo real está longe de funcionar de forma tão previsível assim. Vários eventos que normalmente ocorrem em um computador - por exemplo outros processos rodando na mesma máquina, necessidade de swap em disco, acesso a rede (no caso de aplicações distribuídas), só para ficar nos mais mais óbvios, podem fazer a diferença (às vezes drástica) entre o tempo estimado e o realmente medido. Nos casos em que o próprio processo cuja duração você quer estimar já tem algum “indeterminismo” embutido, independentemente de fatores externos, a situação pode ficar ainda pior para seu estimador de tempo.

Anos atrás, durante o desenvolvimento de uma das primeiras encarnações dos nossos softwares de bioinformática desenvolvidos para a Biomind, nos deparamos com esse enganadoramente “simples” problema da estimativa de tempo. Nosso produto possuía um lugar-comum de vários sistemas de computação, uma fila de tarefas que eram processadas sequencialmente. Quando uma nova tarefa era submetida, deveria ser apresentada ao usuário uma estimativa para o tempo de conclusão da mesma, que seria a soma do tempo estimado para a tarefa em questão mais os tempos estimados de todas as tarefas à sua frente.

No início, ingenuamente determinamos a complexidade computacional de todos os algoritmos envolvidos, rodamos um número razoável de vezes algumas tarefas diferentes para determinarmos valores médios que seriam usados como constantes de tempo, e desenvolvemos um estimador baseado nesses preceitos que pareciam lógicos e de muito bom senso. E foi um completo desastre, com as estimativas frequentemente errando o tempo medido real por mais de uma ordem de magnitude.

Em parte esse desastre poderia ser explicado por ao menos alguns dos componentes envolvidos na execução de uma tarefa não serem lá a coisa mais previsível do mundo. Tratavam-se de algoritmos de aprendizagem de máquina, cujo tempo de execução pode variar conforme as escolhas que o programa faz para “caminhar” pelo Espaço de Busca. Outra parte poderia ser explicada pelos velhos conhecidos que atrapalham a vida dos estimadores de tempo, as já mencionadas “distorções de tempo” causadas por outros eventos ocorrendo na mesma máquina, máquinas ou rede. (A propósito, nosso sistema também era distribuído, ainda que com poucos nodos de processamento.)

Como, então, lidar com todos esses fatores de incertezas?

Interessantemente, a inspiração veio dos próprios processos de aprendizagem de máquina trabalhando no cerne de nosso produto: decidimos criar um estimador de tempo que aprendesse a estimar o melhor o tempo à medida que mais e mais tarefas fossem sendo rodadas.

Nossa escolha metodológica para o estimador de tempo é um dos mais simples algoritmos de aprendizagem de máquina existentes: o KNN. Em sua forma mais simplória - que de fato foi a usada - o KNN começa como uma lista de exemplos conhecidos do que se quer prever - um “conjunto de treinamento”, em jargão de IA. No caso do nosso estimador, esse conjunto era uma massa de centenas de tarefas já rodadas: cada tarefa continha o seu tempo de execução real, medido, e um vetor de características contendo vários parâmetros e medidas relativos aos dados e algoritmos usados. Quando então uma nova tarefa era apresentada ao estimador, o mesmo comparava os parâmetros e medidas da nova tarefa com todas as existentes, e descobria a tarefa antiga mais parecida com a nova. O tempo estimado para a tarefa nova então era assumido como sendo igual ao tempo de execução dessa tarefa antiga “irmã”.

Depois de completada, e com seu tempo real medido, a tarefa nova era então adicionada à base de comparação. Assim, as estimativas de tempo tendiam a ficar mais precisas quanto mais tarefas eram processadas, o que de fato, com o sistema já em testes avançados, pudemos comprovar plotando gráficos mostrando a convergência. Aliás, essa capacidade do KNN de naturalmente e com custo computacional desprezível incorporar mais “experiência” foi um dos fatores que nos levaram a escolher como o método definitivo para o nosso estimador de tempo. Além disso, na primeira rodada de testes, usando só a base de treiamento inicial, o KNN não mostrou resultados ruins quando comparado com métodos bem mais sofisticados (e com custo computacional bem maior).

Esse “causo” do estimador de tempo encerra umas duas lições de “auto-ajuda para computeiros”, como diz nosso amigo Kenji. A primeira é a de que nivelar por baixo a estimativa da dificuldade de se implementar um requisito é uma política que pode se mostrar desagradavelmente errada mais para a frente. A segunda é a de que nosso velho conhecido, o princípio KISS (Keep it Simple, Stupid) às vezes atende não só seu objetivo primordial de tornar desenvolvimento descomplicado e rápido, mas também atinge resultados finais de alta qualidade, superiores aos que seriam conseguidos de formas mais elaboradas…

Bichos de estimação virtuais estão se tornando populares, seja em comunidades na internet, seja como jogos para consoles, como o Nintendogs. Em jogos ou mundos virtuais como esses, os usuários podem comprar bichinhos e “treiná-los” para aprender um conjunto de truques pré-estabelecido. Os cachorrinhos virtuais são divertidos, mas bastante limitados. Eles não aprendem de verdade, uma vez que os truques são animações pré-programadas que são simplesmente “ligadas” pelo jogo. A personalidade dos bichos também não é individualizada, ao contrário de animais de estimação de verdade.

O Vetta Labs está colaborando com a Novamente LLC, uma empresa americana de IA, para desenvolver bichinhos virtuais muito mais inteligentes e interessantes. A New Scientist acaba de publicar uma matéria que discute o Petaverse, nome provisório do projeto. O Petaverse usa tecnologia de Inteligência Artificial Genérica para permitir que os animais virtuais realmente aprendam com seus donos.

Os cachorros podem ser ensinados a buscar e trazer brinquedos, jogar futebol, dançar, guardar a casa virtual do dono e uma infinidade de outros truques. Eles aprendem imitando o dono (um avatar controlado pelo usuário dentro do jogo ou mundo virtual), então a imaginação do dono é o limite para o que pode ser ensinado. Você pode conferir um videozinho do protótipo [Download] / [Youtube]

Os cãezinhos também têm personalidade individualizada: você poderia criar um cão medroso ou agressivo, sociável ou na dele, e assim por diante. E a personalidade determina se o cão vai latir ou fugir na presença de estranhos, quão obediente ele vai ser e assim por diante.

O Petaverse ainda está em desenvolvimento e será lançado em alguns mundos virtuais em 2008. Estamos trabalhando com o Second Life e o Multiverse como plataformas iniciais e procurando fundos para desenvolver nosso próprio mundo.

E, por falar nisso, estamos procurando programadores para nos ajudar a desenvolver uma demo de mundo virtual em Flash voltado para crianças, assim como um widget Facebook. Interessada(o)? Entre em contato