Marco Gomes

O Google Wave é como um cliente de mensagens instantâneas muito poderoso. A comunicação é síncrona, todos os envolvidos numa discussão veêm em tempo real o que você escreve. Os waves, que são as conversas nesta plataforma, podem ter elementos colaborativos multimídia como mapas, enquetes, vídeo, áudio, aplicativos.

O e-mail é um meio de comunicação arcaico. Criado em 1971, foi pensado como uma metáfora das cartas em papel enviadas pelo correio, o objetivo era trocar mensagens curtas de texto, entre computadores pouco poderosos, em conexões lentas, de maneira assíncrona – você pode esperar uma hora, ou um mês, para responder uma mensagem – e com poucos participantes – uma discussão com mais de 10 pessoas pode se tornar um martírio de identação, citações multicoloridas, códigos com cabeçalhos de remetentes e destinatários (veja imagem ao lado).

O Google Wave foi criado para a infraestrutura Internet moderna. Com recursos multimídia integrados, plataforma de aplicativos, projetado para computadores capazes de reproduzir vídeo e áudio conectados em banda larga, possibilitando comunicação síncrona – em tempo real – entre 2 ou centenas de pessoas de maneira fluente, com colaboração integrada. Se você vai redigir um documento com alguém, não precisa ficar trocando anexos numa confusão de versões e datas em que um pode arruinar parte do trabalho do outro.

Por enquanto você precisa conseguir um convite para testar o Wave, assim como foi no início do Gmail e orkut. Você pode conseguir pedindo pra algum amigo que já esteja usando a plataforma ou fazendo um pedido público no Twitter.

O Google Wave não pretende matar o e-mail, são meios diferentes, o Wave é uma plataforma inovadora de comunicação e colaboração, que ainda precisa entrar no dia-a-dia das pessoas, como aconteceu com o telefone, e-mail, instant messenger e redes sociais. Quando essa mudança acontecer, tudo será diferente, como sempre foi :)

Saiba mais

Google Wave: What’s All the Fuss About?

O Writing About analisa os twitts de um usuário e diz sobre que assuntos ele tem postado ultimamente.

Acabo de desenvolver uma ferramenta que identifica palavras-chave no Twitter e classifica-o segundo uma árvore de categorias personalizada. Não é uma comparação direta do tipo “encontre termos relacionados com tecnologia”, há uma análise do significado das palavras do texto.

Teste agora mesmo o serviço de análise semântica do Twitter!

É meu mais recente projeto de uma madrugada, por enquanto ele não tem utilidade real para usuários, é apenas uma prova de conceito. Em breve pretendo liberar o acesso ao serviço na forma de API JSON, com isso outros progamadores poderão usá-lo pra criar aplicativos que usem a interpretação dos twitts dos usuários.

Exemplo de aplicação que pode ser desenvolvida a partir da API do Writing About:

Recomendação de conteúdo a partir do que você tem tuitado: A aplicação analisa as categorias e palavras-chave dos seus twitts mais recentes e te recomenda conteúdo que pode te interessar.

Milestone a ser cumprido antes de liberar API pública:

Suportar no mínimo mil requests por hora. Atualmente o Twitter aceita no máximo 100 consultas por hora, com esse limite fica impossível usar o Writing About pra algo com um mínimo de escala. O ideal seriam 100 requests por minuto.

>> tech stuff

O Writing About

• foi desenvolvido em uma madrugada
• é programado em Python
• roda na infraestrutura do Google App Engine
• usa a API do Twitter pra pegar os posts mais recentes do usuário
• usa API externa pra análise semântica, ainda não posso dizer que API é, direi assim que for autorizado
• todas as consultas são gravadas num log no não-SQL App Engine datastore. Não-SQL é um sistema de armazenamento de dados não relacional e livre de schema, projetado especialmente para aplicações web de alta escala e grande volume de dados
• não tem tratamento de erros, porque sou afobado e queria mostrar logo pra vocês :)

Copyright boo-box 2009.

Eu e o Mauricio escrevemos um texto explicando um pouco da infraestrutura de servidores Web do Sistema boo-box, publicado no blog da boo-box, abaixo um trecho:

A boo-box possui uma infraestrutura em camadas, capaz de escalar horizontalmente e que hoje tem robustez pra servir milhares de requisições por minuto. Neste post iremos apresentar algumas soluções usadas atualmente pra garantir melhor performance do Sistema de Publicidade Para Mídias Sociais.

Leia tudo no boo-blog.

Comentários fechados pra este post, comente no post original.

Generalizando ainda mais, você pode se perguntar:

Devo continuar tentando resolver este problema desta maneira?

É muito comum que desenvolvedores passem batido por esta questão. O piores programadores acham que a primeira abordagem que encontram é a única maneira de resolver um problema.

Se você já se fez alguma das perguntas acima, ótimo, não sei se há resposta definitiva, mas vou mostrar como eu me respondo.

Estabeleça um prazo e trabalhe com toda a sua energia até lá, depois faça uma estimativa da distância que se encontra do objetivo final, e se vale a pena continuar trabalhando no projeto.

Prazo claro e inadiável

Durante o desenvolvimento dos meus projetos de uma madrugada (insôniaware), eu seto uma meta: 8 am vou parar de trabalhar neste projeto. Não importa o que estará pronto, eu vou parar. Se houver algo funcional, vai pro ar, se não é útil ainda, vai ter seu desenvolvimento interrompido por algumas horas pra que eu reflita um pouco.

Você pode estabelecer um limite de um mês pra tocar profissionalmente um projeto pessoal, ou uma semana trabalhando diariamente com o futuro sócio. O prazo não precisa ser 8 am e a madrugada não é o único período produtivo do dia :)

Não empurre com a barriga

A maior importância desse prazo é estabelecer um momento exclusivo de reflexão, ele vai evitar que você vá “empurrando com a barriga”.

Empurrar com a barriga, porque já estava assim, fui fazendo e quando vi já estava todo enrolado são situações que sempre me deixaram frustrado. O artigo de Programação Orientada a Gambiarras (P.O.G.) da Desciclopédia define essa situação como Faca nos dentes – O famoso Vai fazendo ai!.

Definir um prazo inadiável foi a maneira que encontrei pra não deixar meus projetos saírem do controle.

Getting Real

Projetos como o Wallpapr, Busica, Wallpapr for iPhone e Webriga (que fiz com o @mauricio) eram funcionais já nessa primeira parada obrigatória e foram pro ar, com bugs, mas foram.

O protótipo da boo-box, ImageDolly e AdBird não estavam funcionais neste primeiro checkpoint, o trabalho neles foi interrompido pela manhã (lembro como se fosse hoje) e era o momento de fazer uma reflexão se o projeto realmente valia a pena, e se aquela era a melhor maneira de resolver o problema.

Como você pode imaginar, tenho alguns outros projetos que nunca foram continuados, achei que não valiam a pena, ou que existiam outras maneiras de abordar o problema. Alguns ainda estão adormecidos aqui na pasta /labs do MacBook :)