Wattlas - Nova Versão

Ontem foi publicada a nova versão do Wattlas, quatro meses depois da primeira liberação da utilizando o App Engine para Java.

A principal mudança foi relativa à arquitetura interna para representação de dados. Anteriormente todos os dados eram registrados como objetos padrão no modelo do object store do App Engine. Agora, embora utilizando a mesma infraestrutura, todos dados seguem o padrão KML para representação de dados geográficos. Isto é possível graças ao formato extensível do KML, que permite agregar metadados com facilidade.

A mudança foi motivada para facilitar o compartilhamento de dados entre aplicativos (agora os dados são naturalmente compatíveis com o Google Earth por ex.), tirando proveito de uma especificação bastante completa, o KML 2.2. No momento apenas um subconjunto da especificação é suportado, orientado a visualização no browser e aos elementos comuns em trilhas.

Baseado neste formato XML, todo dado pode ser editado como um arquivo texto, facilitando a edição online. Na versão atual, a edição ainda é restrita a administradores, mas futuramente deve ser liberada num modelo Wiki.

Outra mudança envolveu a otimização de código da versão anterior, especialmente no processamento de XML. Depois de algum estudo com as ferramentas do App Engine para avaliação de desempenho (App Stats e console admistrativo), foi detectado um gargalho com o parsing baseado em DOM. A implementação antiga baseada em JAK (arvore DOM completa em memória e mapeada em classes Java / KML), foi substituída pelo mais enxuto e eficiente JDOM. O parsing de uma entidade que anteriormente levava 7s baixou para 30ms (!).

Mais mudanças de otimização foram realizadas na serialização de objetos GWT, um outro gargalo identificado e em geral causado por grandes árvores de objetos Java sendo convertidas do servidor para o cliente. Isto é especialmente notado rodando o GWT em modo de desenvolvimento (não compilado). A serialização de 19 objetos estava tomando 32s, baixando para menos de 400ms na nova implementação.

Outro ponto considerado foi a indexação de conteúdos. Sendo primariamente uma aplicação AJAX, todo conteúdo estava excluído da indexação dos buscadores. Foi então criada uma visualização simples sem Javascript para este propósito. A interface suporta hoje duas línguas, o português e inglês, de acordo com a língua do navegador.

Sendo uma aplicação JavaScript em geral, também todo suporte tradicional de estatística de acesso teve de ser adaptado (i.e. Google Analytics). O mecanismo de Event Tracking provido pelo Google foi integrado, fornecendo os dados de visualização de locais, contagem de cliques, etc. Desta forma é bastante prático de acompanhar os locais mais acessados, assim como as fotos, mesmo numa interface JavaScript.

Para finalizar, foram incluídos dados de mais três trilhas, todas na região do Santinho em Floripa: a Trilha do Topo do Morro das Aranhas, a Trilha do Morro das Aranhas e o Caminho da Lomba do Ingá.

Boas Trilhas!

Wattlas

Em meados de 2007, com o lançamento de uma ferramenta para criação de mashups pelo Google, iniciei um projeto para expor os conteúdos de algumas trilhas de Floripa na Web. Juntando uma tecnologia legal e o desejo de expor mais informações sobre o tema, nasceu o Trilhas e Caminhos. A ferramenta, em termos de ambiente de desenvolvimento, mostrou-se prática e rápida para criação de funcionalidades na web que em outros casos requerem um alto esforço de programação. Era bastante trivial combinar informações de blogs, feeds RSS, conteúdo georeferenciado, fotos e outros em uma aplicação web. No entanto, as limitações de um ambiente de desenvolvimento dentro de um browser naquele tempo e do próprio modelo de programação, contribuíram para o projeto ser abandonado em 2009. Neste período, iniciou a transição para um novo ambiente de desenvolvimento, mais poderoso e flexível.

O App Engine, inicialmente disponível apenas na linguagem Python, foi o ambiente escolhido para a nova versão do Trilhas e Caminhos. Das primeiras versões até o estágio atual, foram adicionados recursos como o suporte a linguagem Java, serviços de email, imagem, cache e mais recentemente, uma integração com o framework GWT.

O Wattlas, como foi batizada a nova versão, é construído em cima desta infra-estrutura e visa fornecer conteúdos sobre atividades outdoor. O objetivo é fornecer conteúdos livres e criados de forma colaborativa, num modelo inspirado na Wikipedia, sendo o foco inicial as trilhas de Floripa e região.

Esta primeira versão oferece a visualização do local no mapa, álbum de fotos, perfil de altura, controle dos detalhes baseado no zoom do mapa, desenho da trilha e interface em duas línguas. O conteúdo inicial traz trilhas bem populares de Floripa, como a Lagoinha do Leste, Naufragados e Costa da Lagoa, mais alguns locais menos explorados como a Cachoeira do Retiro em Sto. Amaro.

Para o próximo release, está sendo preparado o suporte à edição colaborativa dos conteúdos, construído em cima do padrão KML, o formato popularizado pelo Google Earth para dados geográficos e maior detalhamento dos conteúdos atuais.

Então, pronto para colocar o pé na estrada? Confira o Wattlas e fique à vontade para deixar seus comentários no site.

Scrum Gathering Brasil

Aconteceu esta semana em São Paulo o primeiro Scrum Gathering Brasil, evento promovido pela Scrum Alliance e que pela primeira vez ocorre fora dos EUA e Europa. Foram dois dias de palestras com temas como a gestão ágil de projetos, práticas de aplicação e cases de Scrum e muito network entre os participantes, grupos de usuários e empresas.
Grosso modo, Scrum é um framework para melhorar a gestão e a taxa de sucesso em projetos. É aplicado na criação de produtos complexos, principalmente no ambiente de software, onde existe uma alta taxa de mudanças ao longo do desenvolvimento.
O Gathering Brasil teve várias palestras ocorrendo simultaneamente e das que eu assisti posso destacar:

• O grupo de usuários de Scrum de Recife falou sobre Definition of Done (DoD), um conceito que muitas vezes na aplicação do Scrum não se tem clareza e é mal aplicado. Eles propõem a realização de um workshop com o time do projeto, onde o time define desde o início como caracterizar que um item do backlog esteja “pronto”. Não vou entrar em detalhes neste post, mas que quiser saber mais pode ir direto nas fontes (artigo do Mitch Lacey, artigo do Dhaval Panchal).
• Ken Schwaber, um dos criadores do Scrum fez uma palestra de introdução ao tema e falou avanço do Scrum e metodologias ágeis nos últimos anos. Alguns dados impressionam, o que mais me chamou atenção é que numa pesquisa realizada sobre a adoção de metodologias de software nos EUA mostra que desde meados de 2008, a aplicação de métodos ágeis superou os métodos baseados em Waterfall.
• Boris Glogger, com quem fiz o treinamento de CSM, trouxe “6 segredos para um retrospectiva de sucesso”. Não vou me estender muito aqui, pois ele fez a publicação dos slides no seu próprio Blog, mas recomendo fortemente para aqueles que estão lutando para aplicar uma boa retrospectiva de Sprint (é... aquele que você aprendeu e aos poucos parou de fazer direito nos seus projetos).
• José Papo apresentou diferentes modelos de contratos ágeis, tema que eu pessoalmente estou batalhando para evoluir na minha empresa. A idéia básica é você evoluir dos modelos de escopo e valor fixos para um modelo de escopo variável, que permita a sua adequação à medida que o projeto evolui e mudanças ocorrem no desenvolvimento.
  

Espero que o evento continue todo ano no Brasil, já que é uma ótima oportunidade para aqueles que praticam metodologias ágeis trocarem experiências e aprenderem mais.

App Engine em Java

O Google lançou neste mês a nova versão do App Engine, agora com suporte a linguagem Java. O sistema já dava suporte ao Python e o suporte ao Java era um pedido freqüente nas listas de discussão e issue trackers do App engine, tornando uma escolha quase natural ao processo. Num post recente do Paul McDonald, já estava sendo anunciado que era breve a liberação do novo runtime e eu estava particularmente ansioso por isso, já que fiz alguns testes com a primeira versão do runtime em Python e fiquei bastante surpreendido com o potencial.
Ao primeiro olhar, o App Engine é uma solução que fornece uma série de recursos que simplificam o processo de publicação de um aplicativo na web e libera o programador de tarefas de configuração e infra-estrutura: não há necessidade de configurar um servidor web, nem um banco de dados, nem DNS, nem cachê, entre outros.
Muito além de simplificar estas tarefas de publicação, o App Engine é um ambiente de execução altamente escalável para aplicações web. Um exemplo disto é o seu Datastore, um repositório de dados escalável e sem esquema, baseado na tecnologia do Big Table do Google. Em resumo, você pode guardar grande quantidade de dados sem se preocupar com o particionamento, múltiplos bancos e a redundância do armazenamento. Outro exemplo é a sua capacidade de automaticamente lançar novas máquinas virtuais à medida que o número de acessos a aplicação aumenta, o que pode ser útil em situações de um pico nos acessos da aplicação.
Fora estes e mais outros recursos bem atrativos fica a questão se você realmente quer sacrificar a portabilidade da sua aplicação para poder tirar proveito de todas estas facilidades que o App Engine oferece. Seria muito legal se você pudesse migrar a aplicação para a sua própria infra num momento desejado.
No mais, a plataforma vem evoluindo muito rápido e com a promessa de recursos bem interessantes de processamento offline também. Experimente!

(ATUALIZADO: assisti a uma demonstração onde uma aplicação criada no App Engine roda na infra de um servidor Web Sphere fora da infra do Google, apenas alterando arquivos de configuração e sem mudanças no código. Isto é possível porque a camada de acesso a dados usa o JDO/JPA, padrão Java)

Teorizando sobre dados

Em palestra recente no TED, Tim Berners-Lee aborda o tema da publicação de dados brutos na Web. Na sua visão, existem muitos dados escondidos em bancos de dados não acessíveis na internet. Estes dados disponíveis em padrões aberto poderiam formar um campo de exploração para pesquisadores do mundo todo. Recomendo!



Acredito que o potencial para pesquisa com base nestes dados é enorme, não só em dados brutos mas no que temos hoje na Web. Um dos exemplos que considero excepcional é o aprendizado de idiomas com base em textos da Web em diferentes línguas. Na palestra do Peter Norvig, ex-NASA e atual pesquisador do Google, ele mostra como são usadas técnicas computacionais para melhorar as traduções automáticas. O sistema é treinado com o volume de dados superior a qualquer sistema tradicional e os resultados mostram a diferença: o uso da Web com base aumenta significativamente a qualidade das traduções.

"It’s a capital mistake to theorize before one has data.", já dizia Sherlock Holmes em suas investigações, 1891.

Trilhas e Caminhos

Mashup do Projeto Trilhas e Caminhos, com indicações de trilhas de Floripa. O site foi baseado na tecnologia Mashup Editor, do Google. Para compor o serviço, são agregados dados do Flickr, Google Base e Google Maps.



Acessível neste link.

O Feiticeiro de Menlo Park

Tantas foram as invenções de Thomas Edison que torna difícil saber por onde começar. Nascido na costa leste dos EUA, descendente de holandeses e britânicos, Edison foi capaz de conceber invenções nos mais variados ramos da ciência e da indústria.

Embora não fosse pobre, a família de Edison também não gozava de riqueza. Desde garoto começou ganhar seus trocados vendendo jornais, trabalhando inclusive com a venda em percursos de trem, parando de estação em estação. Aquilo que ganhava com a venda destas notícias era o capital necessário para investir em seus experimentos - estas notícias eram especialmente desejadas pois tratava-se do período que antecipava a gerra civil americana.

Chegou mesmo a montar um pequeno laboratório dentro do proprio trem, fazendo ali experimentos em química. Num incidente em que o trem descarrilhou causando confusão e quebra dos vagões, o pequeno laboratório chegou a pegar fogo e incendiando o vagão. Sem o mesmo interesse pela química que o jovem Edison, o maquinista expulsou e correu com o pequeno cientista do trem.

Seguindo o seu caminho, Edison tornou-se operador de telégrafo. Dominava como poucos da sua idade o código morse, destacando-se rapidamente no meio. Durante os longos anos em que trabalhou com telégrafos nunca deixou de inventar e experimentar. Suas contribuições nesta arte foram das mais variadas e reconhecidas em seu tempo, criando dispositivos mais rápidos, capazes de trafegar mais mensagens na mesma rede, reduzindo ruídos de comunicação, etc.

Despontava ali um ancestral da atual Internet, um sistema elétrico de transmissão de dados a longa distância. Junto ao telégrafo, surgiam aos poucos os primeiros sistema de telefone nos EUA. Aqui Edison também inscreveu seu nome com a invenção de um telefone usando um transmissor de carbono. Esta invenção melhorava o telefone inventado por Bell e era capaz de transmitir a longas distâncias, enquanto a invenção de podia transmitir apenas em distâncias de 3-5km.

“Nunca fiz nada de valor por acidente; da mesma forma, nenhuma de minhas invenções aconteceu por acidente; elas ocorreram depois de muito trabalho”
(Thomas Edison).

As invenções e empreitadas ainda vão longe, passando pela lâmpada incandescente, o cinema e tantas outras. Conheça mais sobre Thomas Edison na Wikipedia.