Tecnologia. Inteligente.

Com o lançamento do Lively, o Google se aventura pela mercado de Mundos Virtuais, ou quase isso. Ao contrário do Second Life, o Lively utiliza o conceito de quartos virtuais (virtual rooms), espaços 3D de dimensões reduzidas se comparadas às de uma ilha do SL.

Os usuários Lively podem criar seu próprios quartos contendo, além de mobília e decoração virtuais (com uma biblioteca interessante e que pode receber contribuições de terceiros), fotos e vídeos vindos diretamente do YouTube, óbvio. O interessante do sistema é a capacidade de embutir tais quartos em páginas WEB normais e assim permitir a qualquer um que esteja navegando pela página o acesso a um ambiente 3D, diretamente no browser (IExplorer 7 e Firefox por hora).

Agora é só esperar o Google abrir a API do Lively (como tem feito com suas outras aplicações) para nós aqui do VettaLabs tornarmos a “brincadeira” ainda mais divertida com nossos cachorros virtuais inteligentes ;-).

Se há uma ferramenta que potencializa os esforços individuais, esta se chama internet. Basta ver o que o Open Source representa hoje.

Quando o google lançou o Google Maps, muita gente parou por um momento e pensou “porque eles estão investindo nisso?”. E de fato, o Google, como qualquer empresa, já tentou várias iniciativas sem sentido ou que não deram certo, mas tentar, e algumas vezes falhar, faz parte do jogo da inovação.

O Google Maps deu muito certo. E abriu o olho de muita gente para a importância da “localidade” das coisas, potencializada pela proliferação das plataformas mobile e das redes wireless.

Uma boa idéia que andou ganhando algum espaço da mídia especializada foi a iniciativa da Outside.In, que explora as interações do que estão chamando de (adoro novos termos…) hiperlocalidade. Blogs, notícias, redes sociais de pessoas relacionadas a um conjunto de quarteirões por exemplo. De onde você mora. Dos seus vizinhos. Da padaria que fica perto da sua casa.

Obviamente, uma aplicação para ambientes urbanos, de preferência, os grandes centros, onde é possível haver massa crítica para fazer isso funcionar. Imagine entrar numa comunidade onde você passa a conhecer seus vizinhos (eu mal conheço os do meu prédio). Ou o comércio perto do seu serviço. Fica sabendo das fofocas, ou dos assaltos na região que aquele moço da imobiliária esqueceu de te contar.

A grande adesão de brasileiros ao Orkut, aliado à incrível capacidade das pessoas de criar comunidades do que quer que seja quase permite isso hoje em dia naquela plataforma. Pode apostar que em qualquer rua em que você morar, pessoas já terão criado as comunidades “eu moro na rua tal” ou “eu moro no prédio tal”. Claro. Redes sociais servem para conhecer pessoas. E conhecer seus vizinhos é a coisa mais velha do mundo.

Só nos resta saber se a idéia da Outside.In vai se pagar. Bem, no último round de financiamentos, eles levantaram US$ 3 mi, então eu diria que eles podem pelo menos tentar

Uma amiga minha (duas na verdade. Carol@Washington e Adrianinha@Atlanta) me deu uma dica outro dia: “confere o pandora”. Pandora é um dos inúmeros sistemas de recomendação de músicas na web. Há várias formas de se recomendar música para as pessoas.

Os papers mais recentes que tentam fazer isso de forma automática e puramente computacional, citam o uso de algoritmos como SVM, Adaboost, Árvores de decisão, tendendo a obter melhores resultados com Adaboost, até onde me lembro.

Mas o fato é que recomendar música não é fácil, porque é difícil definir quais são as variáveis que levam uma pessoa a gostar de uma música, e qual a relação que vai levar aquela pessoa a gostar da próxima recomendação. Por isso, para a maioria das aplicações reais, ainda usamos o elemento humano para resolver o problema.

Prá quem não sabe, o Pandora tem um pool de vários especialistas (uns anos atrás, era algo em torno de 100 pessoas) que ficavam todos os dias triando e classificando manualmente um monte de músicas todos os dias. Nada escalável isso, mas certamente, de qualidade. Um processo bastante caro, mas pelo feedback do que se vê por aí, bastante eficiente também.

Os concorrentes? A Amazon, com seu filtro colaborativo (já falamos dele) e a Last.FM que usa um sistema de recomendação social a la redes sociais, tradicionalzão.

Pena que o Pandora só funciona para usuários rastreados em IPs dentros dos Estados Unidos…

Mas nem tudo está perdido.

O último que me chamou a atenção, eu não sei que método usa, mas inova mais na interface, simplesmente sensacional: o musicovery (dica da Rosi, que está se esbaldando na especialização dela em Design de Interação na IEC-MG). Pessoalmente, eu fiquei maravilhado com esse negócio.

E ele funciona para os brazucas.

Então semana passada o Google anunciou o Google Friend Connect. O que é isso? Uma maneira de adicionar funcionalidades “sociais” ao seu site ou aplicação web sem escrever código. Eles vão disponibilizar um conjunto de widgets que você pode adicionar ao seu site, sem programação nenhuma do seu lado.

Quando você adiciona o seu widget, os usuários de redes sociais podem logar nas redes uma única vez e ter acesso às funcionalidades sociais do seu site, assim como às funcionalidades dos outros sites que se integrarem ao Friend Connect. Eles podem convidar seus amigos nas redes para visitarem o seu site, fazer novos amigos (inclusive de outras redes), navegar pelos perfis públicos dos usuários logados no momento (inclusive de outras redes), adicionar comentários e reviews no seu site, etc.

Dessa forma, você pode tornar seu site mais interativo e atrair visitantes, mas sem gastar esforço com programação. Discussões e comentários podem ser feitos de forma integrada às redes sociais. Você pode criar updates no seu site que são automaticamente divulgados nas redes através dos perfis dos usuários que “assinam” o seu site via Friend Connect.

E esse é só o começo, porque os widgets são compatíveis com o Open Social, a tecnologia do Google para a criação de aplicações sociais portáveis para múltiplas redes. Ou seja, desenvolvedores do mundo todo poderão criar aplicações que você pode usar no seu site via Friend Connect. Talvez haja um novo mercado para desenvolvedores independentes de software: criar aplicações legais usando Open Social para o Friend Connect.

Outro aspecto interessante é a integração de múltiplas redes. Você pode usar o Friend Connect, por exemplo, para permitir que usuários das grandes redes, como o Orkut, participem de redes muito mais especializadas, sem ter que se registrar duas vezes, duplicar listas de amigos, etc.

Esses dois fatores, a facilidade de oferecer conteúdo e funcionalidade diferenciados e a portabilidade do seu “contexto social” podem levar a uma explosão no número de redes sociais especializadas e a uma maior integração entre conteúdo e interação social. A diferença entre redes sociais, de um lado, e fóruns e sites de notícias colaborativos, de outro, tende a sumir, já que o Friend Connect permite que você “leve” seu contexto social das redes para esse tipo de site.

Infelizmente o Friend Connect ainda está em desenvolvimento, e há preocupações com privacidade, também. Mas que a coisa promete, promete.

É interessante como são as coisas. Quando a gente aprende a programar, você aprende a criar bibliotecas e reutilizar código. Você define um monte de funções e aquela biblioteca se torna uma unidade independente e útil. É o nosso processo natural de abstrair e encapsular funcionalidades, para que possamos nos ater no mais importante e poder trabalhar num nível acima de abstração. Porque você não quer saber como se tira uma raiz quadrada, você quer uma função que faça a conta para você.

E este processo vai se repetindo cada vez mais. Depois aparece a orientação por objeto, e você passa a bolar objetos e métodos para aquele objeto. Aí você define interfaces. Depois você organiza os objetos em bibliotecas, que se agrupam em frameworks, que se agrupam em aplicações e por aí vai.

Depois você integra essas aplicações com outras e está feita a sinfonia. Uma das tendências mais interessantes dessa integração entre aplicações são os mashups, onde a partir de API´s disponibilizadas pelos sites, você tem acesso ao conteúdo (os dados) de cada site e pode integrá-los numa nova aplicação.

Muitas vezes, você pode simplesmente correlacionar duas variáveis que ninguém tinha pensado em correlacionar antes, e aquilo é útil para alguém. Um ponto é saber o que correlacionar. Outro ponto é saber como. No fundo, só se trata de mostrar os mesmos dados que estão em outro site de outro jeito.

Um exemplo muito interessante de uma aplicação assim é o timetube, que nada mais é que uma forma de mostrar o resultado de uma busca no youtube ao longo de uma linha no tempo. Afinal, tempo é apenas mais uma dimensão. Para algumas buscas não vai ser grandes coisas, mas pense em fatos jornalísticos, eventos históricos, eleições, carreiras políticas…

Você dá sua API para a internet (e arca com o custo de fazê-la funcionar) e ela te devolve aplicações que repensam em como utilizar seus dados de forma que seja útil para outras pessoas e te devolvem tráfego. Hits. Visitas. Acessos. Atenção. Atenção no oceano da web vale ouro.

Esta semana eu também tive a feliz surpresa de achar o blog do Marco Aurélio, ou Corélio para quem conheceu ele no DCC-UFMG, falando bastante sobre arquitetura, SOA, BPM e etc, que tem tudo a ver com mashups. Recomendo.

Twitter é a mais nova revolução da Web 2.0. Não tão nova assim em tempo de internet, mas explosiva do mesmo jeito. É uma combinação de rede social e micro-blogging.

Você pode escrever micro-posts (o limite é 140 caracteres). Seus amigos recebem seus posts e podem respondê-los. É altamente viciante (um motivo pelo qual optei por me abster). Você pode enviar posts pela interface web, por aplicações desktop, ou via SMS. A opção de postar pelo celular e o limite de tamanho dos posts encorajam uma comunicação frequente e espontânea, parecida com a de mensagens instantâneas como MSN e Google Talk.

Um diferencial é que seus posts também vão (se você permitir, claro) para uma grande linha do tempo pública. Quando os posts de todo mundo são agregados dessa forma, muitas vezes surge um Zeitgeist instantâneo: tópicos que dominam a atenção coletiva dos Twitters em um dado momento.

No bom espírito Web 2.0, o Twitter disponibiliza uma bela API. Essa API, combinada com a linha do tempo pública, levou a diversas aplicações divertidas. Por exemplo, o Twitterverse é uma tag cloud que mostra as palavras mais frequentes na linha do tempo na última hora. Já o TwitterBuzz mostra os sites mais linkados na linha do tempo. E tem usos mais especializados. O Politweets mede a popularidade dos pré-candidatos a presidente dos EUA com base no número de posts (também chamados de tweets). E os candidatos mais antenados com a internet usam o Twitter para enviar propaganda.

O Twitter também tem utilidade pública. Os bombeiros de Los Angeles começaram a usar o Twitter para postar alertas e coordenar atividades via celular no combate aos incêndios florestais de outubro do ano passado, e ainda usam o Twitter até hoje. Outra aplicação legal (essa eu quero aqui pro Brasil com urgência) é o Commuter Feed, que recebe mensagens de motoristas e posta informações em tempo real sobre o trânsito em diversas áreas metropolitanas dos EUA.

Ah, e o Twitter é escrito em Ruby on Rails

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!

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.

Lembra do post sobre Human Computation, de alguns dias atrás, falando sobre uma apresentação no Google Tech Talks que mostrava como usar pessoas para categorizar fotos? (esqueci de contar que esta é uma das maneiras que o google usa para indexar suas imagens… se você já ouviu falar do Google Labeler)

Bem, essa abordagem, comercialmente falando, acaba de ser noticiada no excelente TechCrunch. Após vários startups de empresas que tentaram categorizar fotos automaticamente (Riya, Ookles, Polar Rose), surge a TagCow, que –acredita-se–, usa pessoas para categorizar as fotos. Porque os resultados são impressionantes. (infelizmente, o site deles parece estar fora do ar, provavelmente porque está todo mundo tentando acessar… mas o link que eu deixei aí é de um blog com as impressões de um cara que usou o sistema)

Se for verdade (muita gente está apostando que seja), o negócio passa a ser a infra-estrutura necessária para manter milhares de pessoas categorizando fotos manualmente diariamente. Um problema sério de escalabilidade e disponibilidade, mas não que não possa ser resolvido, no caso de fotos de álbuns na internet.

Não é o tipo de solução que você gostaria para monitorar o uso de equipamento remoto ou para biometria em sistemas de segurança privados.

Até então, sempre tivemos um sistema econômico em que as massas menos favorecidas só podiam vender sua força de trabalho em tarefas simples, e geralmente braçais, que exigem pouca ou nenhuma qualificação. Podemos estar entrando numa era em que um potencial muito básico do cérebro humano (com quantos anos uma criança poderia classificar estas imagens de forma satisfatória?) pode ser a nova força de trabalho. Ou seja, a qualificação pode ser ainda menor…

Você já parou para pensar se isso é bom ou ruim? Imagine gente nas favelas, nos países pobres da África, da Índia (onde a web chegar, claro), passando o dia inteiro em lan houses ganhando centavos a cada foto categorizada… O que você acha?

Esta interessante apresentação no Google Tech Talks (uma fonte eterna de vídeos bacanas, mas apenas em inglês, sorry) mostra todo o potencial que existe na web atualmente quando se trata de usar o potencial de raciocínio humano para resolver problemas complicados.

A apresentação é cheia de informações interessantes e piadas boas [coisa rara. humor costuma ser um bom indicativo de inteligência e confirma minha teoria que o Sr Ahn é muito bom de serviço]

De uma forma muito engenhosa, Luis Von Ahn, professor da Carnegie Mellon, conseguiu criar uma maneira de identificar e classificar imagens usando pessoas… com a ajuda de um viciante joguinho na web. Nunca devemos ignorar o poder de um monte de gente com tempo sobrando na web.

Alguns outros exemplos de “computação humana”

#1 - alguém já se perguntou, ao baixar suas piratarias dos file sharings da vida, se aquele captcha (aquelas letras tortinhas que vc tem que digitar para provar que não é um programa) não é o mesmo captcha que é usado em algum outro site para bloquear comentários de SPAMs ou coisa do tipo? Ou para criar uma conta falsa de email? Ou para acessar pornografia?

#2 - o facebook traduziu o site deles para alemão em 2 semanas com a ajuda de “apenas” 2000 voluntários

A web traz uma escala que possibilita coisas impressionantes. Encontrar a motivação para este poder computacional: eis o grande desafio da Web 2.0.