tall eye

the higher the point of view, the more you can see

1 note &

Open Friday Hacks of March, 2013

Post written by me at Engineering blog.

abril-engineering:

by Luis Cipriani

Every first Friday of each month at Abril Mídia Digital is Open Friday, a day the teams have to turn ideas into real projects, to study and practice new technologies, to hack internal products and to integrate with other teams. It’s a day without restrictions of scope, anyone can do anything, but all knowledge must be shared with co-workers or people outside the company.

Open Friday happens since 2010 and we had several projects that nowadays are used in production, or got open sourced code, or was presented in conferences. By far, we are having a very good experience with the results from these days.

From now on we hope to share each month the results from it. The Monday mourning right after the Open Friday, the teams gather in a room to share the created initiatives. So let’s share some of the 21 projects done in February, 1st, that were presented today for all teams:

  • will.js: a framework to create web components and asset on-demand loading;
  • ralio: a command line interface for Rally management software;
  • Generic API: a generic resource domain to temporarily fulfill some very specific Platform requirements;
  • A recommendation system for IBA;
  • Fosformol: A Scrum Retrospective organizer;
  • Several performance tunnings or benchmarks (Lua + nginx, Hot Engine);
  • A POC of a responsive design interface for vejasp.abril.com.br
  • A parser for Semantic Search;
  • A mobile app to ease project management with Rally;
  • A POC for image search with Lire;
  • Improvements in Ruby course slides.

image

Above is a picture of the today’s lighting talks.

You can see that some projects already are available as an open source project, so fell free to contribute. If you are interested in any other project that wasn’t shared with public code, please leave your comment and we can start a conversation with the project owner.

Stay tuned to this blog to see next month’s projects.

Filed under openfriday hackday hacks abril tech

1 note &

Spreading the knowledge with our experiences with REST

Post written by me at Abril engineering blog

abril-engineering:

by Luis Cipriani

For three years we have been developing what we believe is the Content Management System that could fit the enormous list of requirements Abril Mídia need to fulfill to achieve goals such as creating value from the content produced by the publishing houses; speeding up the process of online publishing and enabling a fast adoption of user interaction solutions in our Internet products.

This high diversity of requirements (coming from more than 60 publishing houses) has a relevant impact in the complexity of the systems architecture. We had previous experiences showing that any monolithic or short-term solutions were not a good idea, the only plausible solution would be to change the mindset to a long-term solution and dive in a process to find a more adequate solution.

We came up with a solution that rely a lot on REST principles and constraints, started the implementation and continually reviewed the solution strategy.

In August, 2012, we gave a talk at QConSP conference, in Sao Paulo, to share the implemented solution and lessons learned. Furthermore, the talk present a complete review of the REST constraints and how we applied it; and I believe that study cases presentations are the best to learn complex or common misunderstood concepts in conferences.

The talk had a very good feedback from the conference attendants, the room became smaller for the crowd attending the session and since a lot of people weren’t able to view the talk, the conference organizers asked us to do another session, later in the same day. And that session was filmed by the folks at InfoQ Brazil (sorry English readers/listeners, but this one is in Portuguese).

Shame on me to take a long time to write a post about it here, but the good news are that Luiz Rocha and I sent a chapter proposal (now in English, and with more details about the solution) to the next REST book (REST: Advanced Research Topics and Practical Applications), published by Springer. At the moment I am writing this post, the proposed chapter is conditionally accepted (we just need to fix some simple review points). \o/ The estimated date of publishing is Summer 2013.

Follow us for updates and posts showing more and more how we do our stuff at Abril and please, share your comments.

2 notes &

Explaining Semantic Web

Post written by me at Abril Engineering blog.

abril-engineering:

Few weeks ago I gave an introduction to Semantic Web at the Sao Paulo Ruby User Group (GURU, in portuguese). Since Semantic Web is a very broader term that entail tons of technologies and tools, I decided to focus more on explaining the single main reason that make companies apply it in their projects:

Data Integration

We, as software engineers and product managers, face a lot of problems, specially in big companies, when we need to integrate data coming from several sources. Anytime I needed to do this, I realize that I kept rumbling to myself: “Why we don’t have only one universal metadata for our data? How we let this happen?”

The big triumph provided by the Semantic Web set of technologies, specifications and tools is to enable you, as owner of highly variable data and metadata, to organize it in a way that you can find any information and derive knowledge as easily as a SQL-like query. This is possible because we start to represent the data in the simplest way possible: a triple (subject -> predicate -> object).

For example:

  • Abril_Engineering_blog  >  is_owned_by  >  Abril
  • Abril_Engineering_blog  >  is_hosted_by  >  Tumblr
  • Luis_Cipriani  >  work_at  >  Abril

By establishing relationships with all your data based on a controlled and known metadata (better known as ontology), you create the most flexible format for representing a data, and from this point, you can derive anything the quality of your data would allow.

At Abril we have a perfect environment to use this strategy for data integration, since we produce a lot of content that we are able to extract structure, such as, people, events, venues, articles, user comments, etc. Some projects are on their way and others are about to start. We hope to be talking about it sooner.

Meanwhile, check the presentation slides below, it has more detail about the technologies and cases:

Filed under semantic web data integration abril bigdata

1 note &

Learning with Tech Cine

Post written by me at Abril Engineering blog:

abril-engineering:

by Luis Cipriani

As software developers, we are always looking for new technologies and teaching ourselves on the latest techniques and ways to improve the quality or productivity of our work. Thanks to the Internet and the contributions of millions, it’s very easy to find good sources of content freely available, or even greater content at viable prices.

But sometimes we do this by ourselves and often we don’t have time or people to discuss what we learned, to evaluate how we can apply the technique in a practical way. 

Given this, we decided to spread the knowledge in our office, and the result is Tech Cine!

Every Thursday morning, we join all the developers together in the middle of the office to watch a tech video (no more than 50 minutes) and then we reserve 15 to 30 minutes after the video to discuss:

  • the main/relevant points of interest
  • if the technique worth the investment
  • if we have similar cases inside company
  • how could we apply that technology in our projects

The first 2 Tech Cines discussions were very productive, with a good participation of developers. We started with the episode 1 of Clean Code video series and the second was a video from 2012 Strata Conference in Santa Clara. 

Another thing that we did that proved to be interesting is that since we can’t send every developer to international conferences, we bought the whole video collection at the conference website, and now everybody can have access to the conference rich content! \o/

Filed under office learning knowldge

0 notes &

Compilation of my talks so far

After a long time I decided to start to organize some talks that I made in events in Brazil and one in London. The best place I found to to this is Pinboard.in, since I’m a user and as the list changes when I add future talks your readers can be warned if you subscribe to the RSS.

Here it is: pinboard.in/u:lfcipriani/t:mytalks

They are organized by tags and by type of media: slides or video. Since last year I’m always writing in English in all the talks, but unfortunately not all videos are in English, just the Realtime with XMPP talk that I made in the Javascript Meetup in London in 2010.

They cover a lot of subjects, such as:

  • realtime web apps
  • ruby and javascript
  • xmpp protocol
  • http features
  • rest systems
  • nosql databases
  • bigdata
  • some use cases of company or personal projects

I hope to add much more. There are some of the talks I couldn’t open to you yet, because they have proprietary theme/stuff, but I will try to anonymize things and put everything on the URL above.

You can follow me in Slideshare as well.

Filed under mytalks talks slides slideshare computer science

0 notes &

Extração de dados públicos com YQL e Y!Pipes, parte 2

Na primeira parte dessa série, expliquei os problemas que o desenvolvedor enfrentam ao tentar extrair dados públicos e iniciamos um exemplo com a motivação de se tentar plotar num mapa os endereços de feiras livres de São Paulo, no dia da semana e zona da cidade que o usuário escolhesse. O principal resultado que obtivemos até esse ponto foi uma Open Table da Yahoo Query Language que nos permite realizar a pesquisa para obter os endereços. Sucintamente, ao executar a seguinte query:

USE "http://github.com/lfcipriani/yql-feira-livre-sp/raw/master/yql-feira-livre-sp.xml" AS feiras;
SELECT * FROM feiras WHERE zone = 'SUL' AND dayOfTheWeek = 'DOMINGO';

Obtemos o resultado:

<markets>
   <market>
     <dayOfTheWeek>DOMINGO</dayOfTheWeek>
     <address>RUA  CONDE DE PORTO ALEGRE, Sao Paulo, Brazil</address>
   </market>
   <market>
     <dayOfTheWeek>DOMINGO</dayOfTheWeek>
     <address>AV   AMADEU DA SILVA SAMELLO, Sao Paulo, Brazil</address>
   </market>
   ...
</markets>

Você pode relembrar como funciona o YQL executando esse exemplo diretamente no YQL Console.

A proposta dessa segunda parte é utilizar esse resultado, a conversão do HTML em uma estrutura XML fácil de ser lida por um software, no Yahoo Pipes e plotar o mapa. Dessa forma o usuário pode facilmente saber se tem uma feira livre perto da casa dele, uma vez que agora a informação está num formato mais apropriado.

Yahoo Pipes

Da própria definição no site: “Pipes é uma ferramenta poderosa de composição para agregar, manipular e misturar conteúdo (feeds, RSS, Atom, etc) da Web”.

O legal do Yahoo Pipes é que o usuário não precisa ter conhecimentos avançados de programação ou de como manipular vários formatos, pois a interface é bem fácil de usar. Basta criar conexões entre vários módulos (daí o nome Pipes), sendo que cada módulo faz alguma ação sobre o conteúdo que está passando por ele. A idéia é combinar vários desses módulos para no fim obter um novo fluxo de informações, ou um fluxo enriquecido, modificado.

Nosso objetivo é enriquecer o conteúdo, pois queremos pegar meros endereços e representá-los como pontos em um mapa. Então vamos direto ao ponto!

O mashup de feira livre

O Pipes que vamos criar deve fazer o seguinte:

  • Receber do usuário o dia da semana e o zona da cidade;
  • Executar a query YQL para obter os endereços de cada feira livre;
  • Para cada endereço, realizar um geocoding para obter as coordenadas geográficas;
  • Plotar essas coordenadas em um mapa.

Para ajudar no entendimento, você pode visualizar o Pipes de Feira Livre enquanto lê cada passo abaixo (para ver o “código-fonte” do Pipes você precisa estar logado com algum id do Yahoo). Se tiver dúvida no comportamento de um módulo, clique nele e observe a barra inferior apresentando o resultado parcial do mashup.

Recebendo do usuário o dia da semana e zona da cidade

As entradas de usuários podem ser feitas utilizando o Text Input Module, veja a figura abaixo apresentando como configuramos este módulo para as duas entradas necessárias no Pipes de feira livre.

Como se pode ver, com o Text Input, basta configurar o nome da variável, o texto que aparecerá para o usuário (prompt), um opcional valor default e por fim um valor de debug, utilizado quando o criador do Pipes está testando os resultados. Cada entrada dessa é jogada para um String Builder Module, cujo objetivo é bem simples, concatenar strings. Veja que é bem simples, no nosso caso, bastou conectar a saída do Text Input na parte da string que eu quero gerar. A string final obtida com esse módulo será a query YQL que eu vou executar. Aonde? No YQL Module, é claro. Vamos dar uma olhada como fica essa segunda parte do Pipes de feira livre.

Executando a query YQL na Open Table de feira livre

A saída do String Builder é plugada no módulo que executa YQL’s, como mostra a figura acima. O resultado da execução da YQL é uma estrutura de árvore, hierárquica, ou seja, nesta situação, há vários níveis entre a raiz da árvore e a informação que nos interessa (a estrutura XML apresentada no início desse artigo), portanto, temos que usar um Sub-element Module.

O Sub-Element apresentado na figura irá pegar a árvore de resultado retornada pela YQL query e vai retornar apenas a sub-árvore indicada no campo dele, isto é, queremos apenas a sub-árvore que no fim será representada por uma lista de mercados (item.market), que por sua vez contêm dia da semana e endereço de uma feira livre. Nesse ponto o Pipes mostra a sua eficiência, quando focamos o campo do módulo Sub-Element, o Pipes abre um dropdown menu contendo todos os nós dessa árvore retornada pela query, facilitando muito a vida do criador do mashup.

Por fim, temos um Rename Module, e o objetivo dele é renomear atributos de um feed. Esse passo é importantíssimo para a criação desse mashup, pois o Yahoo Pipes, assim como a própria definição dele diz, é um agregador de feeds (RSS, Atom, etc). Portanto, o módulo Rename está sendo usado justamente para esta causa, que é criar o menor feed possível que o Pipes entenda, com título da entrada e descrição.

Se não realizássemos essa renomeação, o Pipes (e outros consumidores desse Pipes de feira livre) não saberia como consumir os dados. Então guarde essa dica: mesmo com a capacidade de trabalhar com várias formatações de dados, todo Pipes deve “cuspir” feeds, dessa maneira você facilita até que outros criadores de Pipes reutilize o seu mashup. Só existe uma exceção para essa regra e vamos apresentá-la na próxima etapa.

Realizando o geocoding para obter as coordenadas geográficas

Esta etapa foi a mais complicada. Inicialmente, colocamos um Loop Module, cujo objetivo é iterar sobre os elementos do feed e realizar alguma operação neles. Essa operação pode ser qualquer outro módulo do Pipes. Olhando no Loop da figura acima, temos o Google Maps Location Extractor, que se você procurar nos módulos padrões disponíveis do yahoo Pipes você não vai encontrar. A explicação é simples, esse módulo é um outro Yahoo Pipes criado por mim. Esse eu não vou explicar como eu fiz, vou apenas passar a URL pra vocês e aí fica como “lição de casa” entender como ele funciona, OK? Aí vai: http://pipes.yahoo.com/lfcipriani/gmapslocationextractor.

O único detalhe importante que vale o comentário é que esse Pipes não retorna um feed válido, mas apenas uma estrutura contendo o resultado da geolocalização, e assim, fugindo da regra citada na etapa anterior. Fiz isso porque o objetivo principal desse Pipes de geolocalização é ser reutilizado somente dentro de outro Pipes, e com restrição na forma de utilizar o seu resultado.

Mas aí vocês podem se perguntar: peraí, o Yahoo Pipes já não tem um módulo de extração de geolocalização? Sim, ele tem, e se chama Location Extractor Module, e para utilizá-lo basta plugá-lo em qualquer saída de feed que ele irá pesquisar por coordenadas geográficas nos campos do feed que são endereços. Se usássemos ele não precisaríamos criar esse Loop, pois ele itera automaticamente nos feeds, mas então porque não usamos?

A resposta é simples, após alguns testes com esse Location Extractor eu percebi que as coordenadas que ele encontrava não era do endereço correto, ou seja, o geolocation não era confiável para os endereços de feiras de São Paulo, talvez ele seja mais eficiente para outras situações. Eu testei alguns endereços no Google Maps Geocoding Webservice e ele foi capaz de acertar mais, mas ainda assim comete alguns erros de vez em quando (vocês podem ver ao executar o Pipes que alguns endereços caem em outras cidades, mas não deveria porque as feiras são todas na cidade de São Paulo). Enfim, como o Google Maps se comportou melhor, não me prendi ao Location Extractor que está disponível no Yahoo Pipes e decidi criar um outro usando um geocoding melhor para a minha necessidade.

Plotando no mapa

O Yahoo Pipes possui uma convenção para coordenadas geográficas, dessa forma, feeds que possuem os campos nesse padrão são automaticamente mapeados quando o Pipes é executado (e você achando que ia ter que aprender a API do Yahoo Maps, hein! :-) ).

O jeito mais simples de utilizar esse padrão é criar o nó y:location e colocar dentro dele os atributos y:location.lat e y:location.lon (você também pode incluir outras informações). Como o webservice de geocoding do Google Maps não me retorna esses campos no formato que o Yahoo Pipes precisa, eu utilizo o Rename Module novamente para renomear a longitude para a forma correta e pronto! Jogo a saída disso tudo no Pipe Output e o Pipes está finalizado.

O resultado final

Se no modo de edição clicarmos no Pipe Output, poderemos ver na barra de debug inferior da interface do Yahoo Pipes a seguinte estrutura de resultados:

Esse é o feed final que o usuário vai obter ao executar o Pipes, que pode ser utilizado assim como qualquer outro feed na Web: assinar em um feed Reader, consumir com outro Pipes (ou software), manipular as entradas, plotar em outro tipo de mapa, Google Earth, [coloque o que quiser aqui].

Você também pode acessar o Pipes de Feiras Livres de São Paulo pelo próprio site dele, e aí obterá um resultado parecido com esse:

Obs.: Lembro vocês que o serviço da prefeitura que serve os endereços é bem instável. Eu tive problemas para acessar principalmente após a meia-noite nos dias da semana e durante o dia todo no fim de semana.

Recapitulando

Na primeira parte desse artigo, focamos em como usar a Yahoo Query Language para oferecer uma linguagem parecida com a SQL para transformar representações, no caso, um HTML desestruturado para um XML conciso e estruturado de forma melhor para ser processada por um software.

Já nesta segunda parte, utilizamos o resultado dessa query YQL para plotar os endereços das feiras livres de São Paulo. O interessante é que isso foi feito inteiramente dentro do Yahoo Pipes, sem a necessidade de escrever uma linha de código.

A minha recomendação de uso para esses serviços é a seguinte: claro que se formos construir uma aplicação mais robusta, processando muito mais dados e que terá uma alta carga num servidor, o Yahoo Pipes e talvez até o YQL não sejam as maneiras apropriadas de se fazer os mashups. Porém, como no caso do exemplo desse artigo (localização de feiras livres), a proposta for apenas de criar um mashup rápido para se ter um ganho no entendimento e visualização de uma informação, que não vai ser utilizada para fins muito críticos, aí sim, esses tipos de serviços são excelentes, pois os resultados vêm rapidamente.

Enfim, sugiro dar uma olhada nos Pipes existentes, tem sempre uma idéia interessante pra ser observada e é muito fácil ver como ela foi implementada, graças a interface que o Yahoo criou para isso. E se você criar ou já criou um Pipes, coloque num comentário desse artigo para que os leitores possam acessar também.

Filed under dados publicos extracao mining pipes sao paulo yahoo yql

0 notes &

Extração de dados públicos com YQL e Y!Pipes, parte 1

Não dá mais para acessar a Web sem esbarrar nos famosos mashups, que são aplicações web, complexas ou simples, que misturam fontes de dados de várias origens com o objetivo de fornecer um novo ponto de vista, uma nova maneira de se divertir ou mais conhecimento sobre um determinado assunto.

Menos comum mas muito importantes, mashups que utilizam dados públicos (aqueles que se utilizam de dados de órgãos públicos ou outras instituições com esse mesmo caráter) também são criados, porém os desenvolvedores enfrentam muitas dificuldades, por exemplo:

  • Falta de interesse da população e dos usuários da Web;
  • Nem todos os dados necessários estão publicados ou disponíveis para acesso;
  • Algumas vezes os dados podem não estar atualizados ou serem pouco confiáveis;
  • Servidores dos dados podem ser mal administrados e os dados podem ficar indisponíveis temporariamente;
  • A forma como os dados são disponibilizados pode ser “ilegível” ou “burocrática” para um software;

Eliminar essas dificuldades depende de boa vontade desses órgãos públicos e dos cidadãos. Enquanto não temos uma solução, nós, como desenvolvedores, podemos utilizar ferramentas e nossa criatividade para extrair esses dados, certo? Sendo assim, vamos implementar uma simples extração de dados utilizando 2 ferramentas que facilitam a nossa vida: a Yahoo Query Language (YQL) e o Yahoo Pipes (Y!Pipes).

Nessa primeira parte, o foco será apenas no YQL, mas eu pretendo publicar a parte do Y!Pipes em 1 dia ou 2.

A motivação

Eu costumo ir sempre numa mesma feira livre, aqui em São paulo, nos sábados. Porém, sempre quis saber se existem feiras livres mais próximas de casa e os dias em que elas ocorrem. Tinha duas opções, ou saía de casa todo dia e andava pela redondeza procurando feiras ou dava uma “googlada” para ver se encontrava localização delas aqui em São Paulo. Acabei encontrando o seguinte site da prefeitura:

http://www.prodam.sp.gov.br/semab/mercados/pesqt.htm

Sensacional, funciona direitinho e escolhendo região e dia da semana eu obtenho uma lista com os endereços. Aí é que aparece mais um problema, eu reconheci poucas ruas e decidi procurar no Google Maps, mas isso não é muito produtivo, tinha que copiar rua por rua e isso se tornou uma tarefa tediosa. Então decidi colocar a mão na massa pra plotar todos esses endereços num mapa, utilizando o que a Web oferece.

Os problemas dessa fonte de dados

Não apenas o design da página, mas todo o código HTML parece que foi criado nos anos 90. Ele utiliza frames, tags <center>, <font>, <table>’s aninhadas, em resumo, uma tristeza para qualquer programador que precisar fazer um parsing. Vamos dar uma olhada na situação:

<HTML>
<HEAD></HEAD>
<BODY>
<HEAD><TITLE>ENDERECO DAS  FEIRAS POR DIA  </TITLE>
</HEAD>
<BODY  bgcolor="f9cd8a">
<!--BODY background="/img_feiras/feiras.GIF"--><br>
<center>
<!--img src="/img_feiras/logo1.GIF" border=0 align=top><BR>
<font color=#006666 size=5><B><I>RELAÇÃO DE FEIRAS</I></B></FONT><BR-->
</CENTER>
<PRE>
<center><table border=0><tr><td>
 <CENTER><TABLE BORDER=1 background=http://www.prodam.sp.gov.br/semab/mercados/img_feiras/Gray.jpg><TR><TD ALIGN=CENTER COLSPAN=4><FONT COLOR=#006666  SIZE=5>ZONA CENTRAL</FONT></TD></TR><TR><TD ALIGN=CENTER><FONT COLOR=Black Size=3><b>DIA</b></TD>
 <TD><FONT COLOR=Black Size=3><b>ENDERECO</b></TD>
 <TD ALIGN=CENTER><FONT COLOR=Black Size=3><b>NRO.</b></TD>
 <TD ALIGN=CENTER><FONT COLOR=Black Size=3><b>BAIRRO</b></TD></TR>
 <TR>
 <TD ALIGN=CENTER><FONT COLOR=Red Size=2>DOMINGO</TD>
 <TD><FONT COLOR=Red Size=2>RUA  SANTO AMARO                  </TD>
 <TD ALIGN=CENTER><FONT COLOR=Red Size=2>  S/N&nbsp;</TD>
 <TD ALIGN=CENTER><FONT COLOR=Red Size=2>BELA VISTA          </TD>
 </TR>
 ... omiti de propósito algumas linhas que se repetem ...

Além disso, o servidor nem sempre está disponível (percebi que de fim de semana a instabilidade aumenta) e o tempo de execução médio de requisições que eu enfrentei foi de 10 a 15 segundos. Solução para esse problema, só cacheando todos os dados em outro servidor (não, obrigado) ou quando eles realizarem melhorias na infraestrutura (mas convenhamos, isso não deve ser prioridade).

O objetivo

A tarefa parece simples:

  • Executo uma requisição POST passando os parâmetros de zona e dia da semana (via wget, curl, API HTTP de qualquer linguagem);
  • Realizo um DOM parsing no HTML retornado, e recupero a tabela contendo os endereços (via navegação de DOM, XPATH);
  • Para cada endereço, faço um geocoding usando qualquer API disponível para obter as coordenadas geográficas (via Yahoo Maps, Google Maps, Geonames, etc);
  • Jogo essas coordenadas em qualquer serviço de mapas (via Yahoo Maps, Google Maps, etc).

Tinha apenas uma preguiça premissa: não queria usar nenhum programa feito por mim nem por ninguém, mas sim apenas serviços na Web.

Yahoo Query Language

A Yahoo Query Language ou apenas YQL, é uma linguagem parecida com a SQL, largamente utilizada nos bancos de dados, porém cujo objetivo é acessar fontes de dados na Internet. Por exemplo, uma query possível de se realizar com ela é:

SELECT * FROM LOCAL.search WHERE query="sushi" AND location="san francisco, ca";

Bem simples, essa query vai pesquisar por restaurantes em San Francisco, California, que servem sushi. O interessante é que o serviço da YQL centraliza as fontes de dados e fornece uma interface única para todos eles, facilitando a vida do programador, pois fica muito mais fácil utilizar os resultados das queries e também de combinar vários serviços. Se você ainda não conhece, sugiro dar uma brincada com o YQL Console, que possui inúmeros exemplos.

Para os serviços que não possuem tabelas disponíveis, o YQL nos dá duas opções. A primeira é simples, basta executar a seguinte query:

SELECT * FROM html WHERE url="[qualquer URL aqui]" AND xpath='[uma query XPATH aqui]

Com essa query obtemos o resultado da query XPATH no código HTML no formato JSON ou XML. Contudo, essa opção não nos ajuda, pois precisamos realizar uma requisição POST e passar parâmetros para ela.

Nos resta a segunda opção, Open Tables!

YQL Open Tables

Mais interessante que a própria YQL, são as YQL Open Tables, que permitem expor qualquer serviço ou API na web como uma tabela na YQL. Basicamente, para isso, basta criar a especificação de sua Open Table com XML, que pode inclusive possuir código javascript para permitir uma manipulação mais flexível dos dados.

Vamos então ver como fica a nossa Open Table para o caso da nossa fonte de dados de feiras livres em São Paulo. Se você está ansioso, pode acessar o código fonte final no GitHub.

O primeiro passo é colocar a meta-informação da sua Open Table, para que os usuários dela possam saber a forma correta de utilizá-la. Todos as tags XML utilizadas estão detalhadas na documentação de Open Tables da YQL, portanto, vou explicar somente aquelas mais relevantes para o entendimento deste artigo.

<table xmlns="http://query.yahooapis.com/v1/schema/table.xsd">
 <meta>
 <author>Luis Cipriani (@lfcipriani)</author>
 <description>
 Busca por Feiras Livres em São Paulo, por dia da semana e zona da cidade.
 - As zonas possíveis são: CENTRAL, NORTE, SUL, LESTE e OESTE.
 - Os dias da semana possíveis são: DOMINGO, TERCA, QUARTA, QUINTA, SEXTA, SÁBADO.
 - Deixe o dia da semana em branco para pesquisar em todos os dias de uma vez só.
 </description>
 <sampleQuery><![CDATA[ SELECT * FROM {table} WHERE zone = 'CENTRAL' ]]></sampleQuery>
 <sampleQuery><![CDATA[ SELECT * FROM {table} WHERE dayOfTheWeek = 'DOMINGO' AND zone = 'OESTE' ]]></sampleQuery>
 <documentationURL></documentationURL>
 </meta>
</table>

Agora precisamos criar a parte da especificação que cria a estrutura da query que desejamos expor para os usuários:

<table>
 <meta>...</meta>
 <bindings>
   <select itemPath="" produces="JSON" >
     <urls>
       <url>http://www3.prefeitura.sp.gov.br/feiras/feiras.asp</url>
     </urls>
     <inputs>
       <key id="dayOfTheWeek" type="xs:string" paramType="variable" default="todos" />
       <key id="zone" type="xs:string" paramType="variable" required="true" />
     </inputs>
     <execute>...</execute>
   </select>
 </bindings>
</table>

Dentro da tag <bindings> podemos ter as tags <select>, <insert>, <update> e <delete>, dependendo do tipo de queries que queremos criar, no nosso caso, somente uma query SELECT. Deixamos o attributo itemPath porque não queremos colocar nenhum namespace precedendo a resposta retornada e escolhemoso JSON como format padrão no atributo produces.

Na tag <url> colocamos a URL do serviço que vamos acessar, no caso, essa é a URL que vamos fazer a requisição POST e passar os parâmetros necessários para obter a lista de endereços de feiras livres.

Só nos falta agora definir quais os parâmetros desejamos na query, o que é feito pela tag <key>. No exemplo acima, ao atribuir o tipo variable para as duas tags, eu estou informando que dayOfTheWeek e zone são duas variáveis que podem (ou devem) ser utilizadas como cláusulas no WHERE da query.

Munido de todas as configurações de nossa query, se o tipo de fonte de dados utilizado exigir, podemos ainda incluir um código javascript para permitir um manuseio mais flexível dos dados obtidos pela query. No nosso caso, nós precisaremos fazer isso, pois a forma como o HTML é entregue após essa requisição não é muito fácil de lidar. Além disso, desejamos que ao executar essa query, o desenvolvedor obtenha apenas os dados necessário, então seria interessante retornarmos os dados limpos e bem estruturados.

Queremos, a partir do código HTML da fonte de dados apresentado acima, obter o seguinte:

<markets>
   <market>
     <dayOfTheWeek>DOMINGO</dayOfTheWeek>
     <address>RUA  CONDE DE PORTO ALEGRE, Sao Paulo, Brazil</address>
   </market>
   <market>
     <dayOfTheWeek>DOMINGO</dayOfTheWeek>
     <address>AV   AMADEU DA SILVA SAMELLO, Sao Paulo, Brazil</address>
   </market>
   ...
</markets>

Vamos então analisar por partes o código javascript, que é incluído dentro da tag <execute>. Veja bem que vamos apenas focar nas partes mais importantes:

var postData = "zona="+ zone +"&dia=" + dayOfTheWeek;
var data = request.accept('text/html').
    contentType("application/x-www-form-urlencoded").
    post(postData).response;
var xdata = y.xpath(data, "//font[@color='Red']");

Como a nossa requisição é do tipo POST e por padrão uma Open Table faz um GET, precisamos usar o objeto request fornecido pelo YQL para realizar a requisição manualmente. O objeto request possui a propriedade de chaining, então fica bem tranquilo realizar a requisição. Só lembrando que a URL utiliza é aquela especificada lá na tag URL.

Depois pegamos o resultado dessa requisição e realizamos uma query XPATH. Diante do HTML totalmente sem estrutura que recebemos da requisição, a query XPATH que busca os resultados que mais precisamos foi:

//font[@color='Red']

Ou seja, todas as tags do tipo <font> que possuem o atributo color igual a “Red”. Se o HTML fosse semanticamente válido com certeza essa query seria diferente e até faria mais sentido, mas ao extrair dados públicos é bastante comum se deparar com esse tipo de estrutura. Mas é aí tá a diversão do negócio! 

Calma que ainda não acabou, agora temos que utilizar o resultado da query XPATH e recuperar dessa lista o dia da semana e estruturar o endereço de uma forma que seja ideal para o geocoding.

default xml namespace = '';
for each (var item in xdata) {
  if (i == 0) {
    day = item.toString().trim();
  } else if (i == 1) {
    address += item.toString().trim() + ", ";
  } else if (i == 2) {
    number = item.toString().trim();
    if (number != "S/N" && number.length != 0) {
      address += number + ", ";
    }
  } else if (i == 3) {
    address += "Sao Paulo, Brazil";
    marketList.push({day: day, address: address});
    address = "";
    i = -1;
  }
  i++;
}

No código acima, nós iteramos sobre o resultado da query anterior. Para cada 4 items, o primeiro é o dia da semana, e do 2o. ao 4o. constitui o endereço, que incrementamos em uma variável address para no final, montarmos um JSON que possui os atributos relevantes: dia da semana e endereço. Um leitor atento vai perceber que tem código meio estranho nesse trecho acima, o fato é que o YQL aceita na tag <execute>, além do javascript, o E4X (Ecmascript for XML), que adiciona suporte nativo ao manuseio de XML no javascript e é por isso que existe a declaração de namespace default xml namespace = ”. Vamos dar uma olhada na última parte desse algoritmo para entender melhor como o E4X funciona.

default xml namespace = '';
var result = <markets />
for (i = 0; i < marketList.length; i++) {
  result.markets += <market><dayOfTheWeek>{marketList[i].day}</dayOfTheWeek><address>{marketList[i].address}</address></market>;
}
response.object = result;

A resposta da query YQL deve ser enviada para a variável response.object e deve ser criada com o E4X, e veja que isso é feito escrevendo XML diretamente no código javascript. Esse algoritmo foi necessário apenas para converter a estrutura HTML do site de pesquisa de feiras livres para um formato XML mais adequado para ser “lido” por um software.

Pronto! A Open Table está pronta, um exemplo de query que podemos fazer é:

USE "http://github.com/lfcipriani/yql-feira-livre-sp/raw/master/yql-feira-livre-sp.xml" AS feiras;
SELECT * FROM feiras WHERE zone = 'SUL' AND dayOfTheWeek = 'DOMINGO';

Veja o resultado no YQL Console.

Ou acesse o todo o código no Github.

Conclusão

Enfim, apesar de todos os problemas com as fontes de dados públicos, é possível extraí-los e convertê-los para uma representação melhor. Vimos também que serviços na Web como o Yahoo Query Language (YQL) permitem expor esses dados com uma API tão fácil quanto realizar uma simples query SQL, por meio de uma interface padronizada e única. E só com a exposição desses dados, num formato apropriado para que possamos programar com eles, teremos vários mashups gerando novos conhecimentos, sejam eles de interesse público ou não.

Nesta primeira parte desse artigo, cobrimos somente a Yahoo Query Language, na próxima parte iremos criar um mashup com o Yahoo Pipes que irá mapear todos os endereços de feiras livres da zona da cidade que o usuário escolher. Está curioso para saber o resultado? Não se aflija. E não perca a segunda parte na qual explicaremos como criamos esse mashup.

Filed under dados publicos extracao data mining pipes yahoo yql

0 notes &

Brincando com APIs de XMPP

Este artigo foi publicado em 03/02/2010 no finado blog.talleye.com, estou apenas mudando ele pra cá.

Primeiramente, antes de ler este artigo, se quiser saber o básico sobre XMPP, leia meu artigo anterior: Breve introdução ao XMPP.

Hoje em dia, todo indivíduo envolvido com Web já consumiu alguma API HTTP, isso já é parte do dia a dia de qualquer desenvolvimento de aplicação web. Porém, nos últimos meses, começaram a aparecer alguns websites oferecendo APIs em outros protocolos, entre eles, o XMPP. Consumir uma API com esse protocolo é um pouco mais complicado que uma versão HTTP, mas o escopo e os benefícios obtidos são bem diferentes, como demonstraremos neste artigo.

XMPP em aplicações Web

Enquanto não temos suporte completo aos websockets do HTML5, que seria uma maneira de criar conexões TCP a partir do browser, a alternativa é usar a extensão BOSH do XMPP, que especifica como um cliente deve usar o XMPP via uma conexão HTTP. Vamos olhar com mais detalhe nos componentes envolvidos nesse tipo de conexão no diagrama abaixo, roubado diretamente da especificação da extensão:

    Servidor XMPP
        |
        |  [unwrapped data streams]
        |
    BOSH Connection Manager
        |
        |  [HTTP + <body/> wrapper]
        |
    Cliente (Browser)
  • Entre o browser e o BOSH Connection Manager: por meio de long polling ou de qualquer outra técnica Comet, o browser envia requisições HTTP que respeitam a especificação BOSH (o HTTP + <body> wrapper no diagrama acima) para um gerenciador de conexões (BOSH connection manager), cuja responsabilidade é identificar a sessão XMPP e manter as informações dessa sessão.
  • Entre o BOSH connection manager e o servidor XMPP: o connection manager deve criar e manter uma conexão TCP para cada sessão aberta com o servidor XMPP e é dessa forma que a tradução HTTP para TCP é feita.

Esse BOSH connection manager pode ser tanto um componente da sua infra quanto implementado dentro do próprio servidor XMPP. Você pode encontrar mais informações sobre esses conectores em http://xmpp.org/tech/bosh.shtml.

Strophejs

O Strophejs é uma biblioteca que implementa um cliente de XMPP em javascript, logo, pode ser utilizado em aplicações web. Entre as funcionalidades que essa biblioteca implementa, podemos citar:

  • está em conformidade com a especificacão BOSH e o XMPP;
  • é cross-browser;
  • possui builders e usa jQuery, o que facilita o manuseio de XML;
  • suporta vários métodos de autenticação;
  • faz long polling e permite requisições HTTP cross-domain por meio de um componente flash;

Mashup de comparação em tempo real

O objetivo dessa aplicação é permitir que o usuário possa comparar dois assuntos (palavras-chave) de sua escolha em tempo real. Por exemplo, podemos disparar uma busca para comparar as linguagens Java e Ruby em tempo real.

Para que isto seja possível, iremos utilizar a API XMPP do Collecta, um site de busca em tempo real. A API do Collecta utiliza o modelo Publish-Subscribe para publicar os resultados de busca em tempo real para os usuários da API. Então vamos rever o cenário:

  • Logo ao abrir o site a aplicação web connecta anonimamente no servidor XMPP por meio do Strophe;
  • O usuário entra com uma busca;
  • A aplicação web se inscreve em um nó pubsub (no caso, a busca);
  • Ao confirmar a inscricão, a aplicação web está pronta para receber os eventos publicados;
  • Ao receber um evento, a aplicação web faz um parse do XML e apresenta o resultado em HTML;
  • O usuário pode agora comparar os resultados;

Todo o código deste exemplo está no Github caso queira acompanhar e executar o exemplo. Antes de detalharmos o que acontece em cada fluxo, as dependências dessa aplicação são as seguintes:

  • jQuery: auxilia bastante no parsing de XML;
  • flXHR.js: componente flash que permite requisições cross-domain, necessário para a aplicação se conectar num servidor XMPP em outro domínio;
  • strophejs: sem ele não conseguimos usar o XMPP;
  • dependências do strophejs: códigos para gerar md5, base64 e usar o componente flash;
  • API key do Collecta: para usar a API do Collecta você precisa de uma chave.

Mesmo sendo todo implementado em HTML e Javascript, é importante servir essa página em um servidor web, para que o componente flash funcione.

Então vamos apresentar como se implementa cada fase do fluxo dessa aplicação (o foco será apenas no código javascript):

Ao abrir o site

A inicialização da conexão ao servidor XMPP já é feita logo que o usuário abre o site.

// config.js
var Config = {
    API_KEY: 'YOUR_COLLECTA_API_KEY',
    BOSH_SERVICE: 'http://collecta.com/xmpp-httpbind',
    HOST: "guest.collecta.com"
};

No arquivo de configuração acima, temos 3 itens importantes: a chave da API, o BOSH connection manager ao qual iremos conectar (tente abrir essa URL no seu browser) e o host (servidor XMPP) que queremos conectar. Temos um problema nesse ponto, a chave da API vai ser exposta aos usuários. Para o caso da API do Collecta, o único problema seria outro usuário consumir o rate limit, mas mesmo assim o time da Collecta deve procurar alternativas ainda, uma vez que a API é nova.

// real-time-comparison.js
// initiating a BOSH connection to create an anonymous connection to the Collecta XMPP server
connection = new Strophe.Connection(Config.BOSH_SERVICE);
connection.connect(Config.HOST, null, onConnect);

Graças ao strophejs, basta criar uma conexão como é feito acima, passando o serviço BOSH que deseja usar e depois chamar a função connect desse objeto. Os parâmetros passados são o host desejado, o usuário (que é null porque desejamos conectar anonimamente) e a referência à função que deve ser chamada (callback) ao receber algum status do processo de conexão.

// real-time-comparison.js
function onConnect(status)
{
    if (status == Strophe.Status.CONNECTING) {
    // ... outros status
    } else if (status == Strophe.Status.CONNECTED) {
        // adding one handler for each type of XMPP stanza
        connection.addHandler(onPresence, null, 'presence', null, null, null);
        connection.addHandler(onIq, null, 'iq', null, null, null);
        connection.addHandler(onMessage, null, 'message', null, null, null);
        console.log("Sending presence...");
        // app is available to use only after sending and receiving presence from the server
        connection.send($pres().tree());
    }
}

A função onConnect, ao receber o status informando que está conectado, irá criar os 3 handlers necessários para tratar o recebimento de cada um dos 3 stanzas existentes no XMPP. O primeiro parâmetro é o callback de referência e depois o tipo do stanza (leia a documentação do strophejs para saber quais são os outros parâmetros). Após a criação dos handlers, em toda conexão XMPP que é feita, o cliente deve enviar um stanza de presença para o servidor. Como estamos conectando anonimamente, neste caso, após o envio desse stanza, o servidor deve retornar um stanza de presença informando o Jabber ID do usuário anônimo.

// real-time-comparison.js
function onPresence(prs) {
    // in this case, presence got from the XMPP server means to activate UI and allow user to enter the 2 terms to compare
    console.log("Got presence!");
    anonymous_jid = $(prs).attr('to');
    // ... outras coisas
    return true;
}

Sendo assim, quando o servidor retorna a presença, nós simplesmente parseamos o xml com jQuery e pegamos o atributo “to”, que indica pra quem o servidor está mandando essa presença, ou seja, o usuário da aplicação. É importante retornar true no fim desse callback, pois sem ele o strophejs irá apagar esse handler. Com o return true, o handler não será apagado e deverá ser reutilizado no próximo stanza de presença que esse cliente receber.

O usuário entra com uma busca

Neste momento o usuário pode entrar com a busca no campo, ao clicar no botão “Go”, a seguinte função é chamada:

// real-time-comparison.js
function startComparison() {
    // creates 2 search subscriptions and send the request to Collecta XMPP API via Strophejs
    console.log("Subscribing to nodes: "+ terms[0] +" and "+ terms[1]);
    connection.send(Collecta.subscribeSearchStanza(terms[0]).tree());
    connection.send(Collecta.subscribeSearchStanza(terms[1]).tree());
}

Inscrição em um nó Pubsub de busca

Para evitar repetição de código, criamos uma pequena biblioteca chamada Collecta que monta os stanzas necessários para inscrever e desinscrever em um nó Pubsub, que representam as buscas. Nesta biblioteca também se encontra uma função para converter os resultados de busca de XML para JSON a fim de ser usado na hora de construir o HTML para o usuário.

// real-time-comparison.js
var Collecta = {
    subscribeSearchStanza: function(searchName) {
    // generate XML for a search subscription on Collecta XMPP API
    return $iq({type: 'set', from: anonymous_jid, to: 'search.collecta.com', id: searchName })
      .c('pubsub', {xmlns: 'http://jabber.org/protocol/pubsub'})
        .c('subscribe', {node: 'search', jid: anonymous_jid})
      .up().c('options')
        .c('x', {xmlns: 'jabber:x:data', type: 'submit'})
          .c('field', {"var": 'FORM_TYPE', type: 'hidden'})
            .c('value').t('http://jabber.org/protocol/pubsub#subscribe_options')
          .up().up().c('field', {"var": 'x-collecta#apikey'})
            .c('value').t(Config.API_KEY)
          .up().up().c('field', {"var": 'x-collecta#query'})
            .c('value').t(searchName);
 },
 // ...

O trecho de código acima apresenta como devemos criar um stanza utilizando o XML Builder implementado no strophejs. No caso dessa função, estamos criando um stanza do tipo iq para realizar a inscrição do nosso usuário (observador) em um nó PubSub. A construção desse stanza respeita a especificação PubSub do XMPP. Dê uma olhada na documentação da API do Collecta para ver como deve ser esse stanza que é enviado ao servidor.

Confirmação da inscrição

// real-time-comparison.js
function onIq(xml) {
    // in this case, the IQ stanzas handled are just subscription results
    xmlDom = $(xml);
    var iqId = xmlDom.attr('id');
    if (iqId == terms[0] || iqId == terms[1]) {
      if (xmlDom.find('subscription:first').attr('subscription') == 'subscribed') {
        console.log("Subscribed to "+iqId);
      }
    }
    return true;
}

Após enviar o stanza de inscrição, devemos esperar uma resposta do servidor. Quem processa essa resposta é o handler que tínhamos criado anteriormente. O procedimento é simples, com jQuery podemos navegar no DOM da resposta, se o id da resposta for o mesmo da busca realizada e o status da inscrição é “subscribed”, então o usuário está inscrito e agora só precisa aguardar os itens publicados.

Recebendo um evento publicado

// real-time-comparison.js
function onMessage(msg) {
    // messages stanzas are converted to JSON and then prepended to the correspondent panel in the UI
    var result = Collecta.processItem($(msg));
    for (var i=0; i < result.length; i++) {
       $('#term'+ result[i].term +"panel")
         .prepend("<p>["+result[i].category+"] - <a href=\""+result[i].url+"\" target=\"_blank\" title=\" Access "+terms[result[i].term]+" information\">"+result[i].title+"</a><br />..."+result[i].description+"...<br />Published in "+result[i].published+"</p>");
       };
    return true;
}

Os eventos publicados vêm em um stanza “message” e extendidos com a especificação PubSub. O único passo necessário e realizar o parse dessa resposta e convertê-lo para JSON, assim poderemos construir todo o HTML necessário para repassar esses resultados de busca para o usuário de forma mais fácil.

Após todo esse processo, o usuário já pode visualizar os resultados na página assim que eles forem sendo publicados no nó PubSub. Ufa!

Quando há a necessidade de se obter resultados em tempo real na web, o antigo modelo de puxar a informação (pull) por meio de uma requisição HTTP já não é tão eficiente, pois perde-se tanto no desempenho do servidor, que terá uma alta carga devido às inúmeras requisições desnecessárias feitas, quanto na velocidade da informação, pois entre uma requisição e outra pode-se perder o efeito tempo real desejado.

Está crescendo cada vez mais o push como modelo para aplicações Web, na qual o servidor deve fornecer a informação para os clientes web logo que ela for publicada. Juntamente com o modelo de push, o modelo Publish-Subscribe também está se provando efetivo, uma vez que não é só implementado em XMPP, mas também em Webhooks, Pubsubhubbub, entre outros.

O diferencial do XMPP neste caso é a especificação da extensão Publish-Subscribe, que é bastante detalhada e cobre vários fluxos que podem existir no modelo PubSub, além é claro dos vários servidores que já implementam este módulo. Vale a pena experimentar.

Filed under api bosh collecta javascript pubsub xmpp

0 notes &

Breve introdução ao XMPP

Este artigo foi publicado em 02/02/2010 no finado blog.talleye.com, estou apenas mudando ele pra cá.

Apesar de ser um protocolo não muito novo (sim, 10 anos não é muito novo), o número de aplicações que utilizam XMPP (Extensible Messaging and Presence Protocol) vêm crescendo substancialmente apenas nos últimos anos. Exemplos de aplicações que usam XMPP para implementar a troca de mensagens entre componentes e usuários incluem: Google Wave, Chesspark, Collecta, Superfeedr, entre outros.

Ele muitas vezes é lembrado apenas como um protocolo para criar chats e restrito apenas à plataforma cliente, mas não nos prendamos a esse pensamento simplista, existe muito mais poder que pode ser extraído das mensagens trafegadas por essa camada de aplicação.

Segundo os autores do protocolo, o XMPP é uma tecnologia aberta para comunicação em tempo real que permite a criação de vários tipos de aplicações, tais como instanting messaging, presença, chats multi-usuários, chamadas de voz e vídeo, colaboração, middleware, content syndication e qualquer transmissão de dados via XML. Talvez a definição mais curta possível seja: é um protocolo para a criação de middlewares orientado a mensagens. E canais de troca de mensagens existem em qualquer sistema distribuído, e acredite, XMPP pode ser usado em cada um deles, desde que, é claro, isso traga benefícios ao sistema ou ao desenvovimento.

Do que é feito o XMPP?

O protocolo XMPP situa-se na camada de aplicação e é comumente transportado por conexões TCP. Ele constitui-se de XML e possui apenas 3 unidades básicas de transporte, chamados stanzas: presence, message e iq. Iremos apresentar brevemente cada stanza, mas se quiser mais detalhes acesse o RFC do XMPP:

Presence

<presence from="cipriani@talleye.com/casa">
    <status>Ouvindo música...</status>
</presence>

O stanza de presença tem a funcionalidade de notificar servidores e a lista de contatos sobre o status de um usuário na rede XMPP. Essa é uma das grandes vantagens do XMPP em relação à outros protocolos de mensageria, pois a propagação de presença faz parte da especificação e portanto deve ser implementado por clientes e servidores por padrão. No exemplo acima, o usuário cipriani@talleye.com/casa está notificando a rede XMPP de que ele está online, e mais, ouvindo música.

Outro detalhe importante é a forma de endereçamento dos stanzas, ou melhor, de que forma você identifica unicamente um usuário na rede XMPP. No exemplo, o usuário é o cipriani@talleye.com/casa. “cipriani” é o nome do usuário, “talleye.com” é o host ao qual esse usuário pertence e a palavra “casa” é o recurso, utiliza-se o recurso para permitir que um mesmo usuário esteja conectado ao mesmo tempo em vários clientes diferentes (o usuário poderia ter um recurso de nome “escritório” por exemplo). Esses três pedaços constituem o Jabberd ID, ou JID, e é utilizado em todos os tipos de stanzas.

Message

<message to="pedro@shorteye.com/escitorio"
     from="cipriani@talleye.com/casa"
     type="chat" >
    <body>Cadê você?</body>
</message>

No stanza acima, um usuário envia uma mensagem para outro, do tipo “chat” com o conteúdo (body) “Cadê você”. Os stanza de mensagem é enviado e o cliente não deve esperar nenhuma resposta do servidor informando que a entrega foi feita, ele apenas envia para o usuário destino ou armazena caso o usuário esteja offline.

IQ (Info Query)

<iq type="set" id="an_id"
     from="cipriani@talleye.com/casa"
     to="talleye.com">
    <query xmlns="jabber:iq:roster"/>
</iq>

Diferente do stanza message, cada stanza iq enviado ao servidor deve obter uma resposta, por isso existe o atributo type, que pode ter valores set ou get, e como resposta o usuário recebe um outro iq de tipo result ou error, dependendo do status.

No caso do stanza acima, estamos requisitando ao servidor XMPP a lista de contatos de um usuário. E a tag query dentro do iq nos remete a uma outra funcionalidade do protocolo XMPP, talvez a mais importante, que são as extensões!

Extensões

O significado da sigla XML é Extensible Markup Language. O XMPP usa XML para implementar o protocolo. Opa, peraí, quer dizer então que eu posso extender o XMPP? Sim!

O desenvolvedor é livre para incluir qualquer XML dentro ou fora dos stanzas, desde que seu cliente e servidor XMPP conheçam o seu significado. Para que o protocolo não virasse bagunça e todos pudessem usufruir de servidores e bibliotecas que implementam extensões, contruiu-se uma comunidade para especificar e publicar as especificações.

Após 10 anos, há um número alto de exensões, por exemplo, algumas disponíveis são:

  • Service Discovery: extensão para que um usuário possa acessar quais serviços um servidor XMPP oferece.
  • Multi-User Chat: extensão para criar salas de bate-papo multi usuários.
  • Jingle: extensão que permite chamadas via vídeo.
  • Bidirectional-streams Over Synchronous HTTP (BOSH): essa extensão permite um cliente HTTP conectar em um servidor XMPP por meio de um connection manager, cuja responsabilidade é converter uma sessão XMPP de HTTP para TCP.
  • Publish-Subscribe (PubSub): essa extensão implementa o modelo Publicador/Observador, no qual um observador pode assinar um canal do publicador. E cada vez que um item for publicado nesse canal, o observador irá recebê-lo.
  • Tem muito mais de onde essas vieram, sugiro dar uma olhada.

Por quê XMPP?

Quais as razões que faria com que eu utilizasse o XMPP como protocolo ao invés de qualquer outra implementação, como AMQP ou até um protocolo mais simples escrito por mim mesmo?

Como tudo na computação, não tem nenhuma tecnologia que é boa para todos os casos, por isso a melhor resposta é aquela de sempre: depende! :-) Primeiro vamos dar uma olhada em alguns motivos que favorecem o uso do XMPP:

Por ter uma comunidade forte o XMPP é um protocolo sólido, vários fluxos já foram pensados, testados e é um protocolo ativo, que se adapta às necessidades dos seus usuários. Além disso ele é apoiado por bibliotecas e servidores que implementam e oferecem as principais extensões, é descentralizado (e por isso, escalável), seguro e extensível.

Por outro lado, dependendo da complexidade da aplicação, o XMPP pode ser muito burocrático e um protocolo mais simples é bem mais efetivo. O mesmo acontece se você tentar utilizar uma extensão XMPP quando na verdade já existe algum outro protocolo especialista em um modelo de mensagem.

Por experiência própria, já iniciei um sistema que nem imaginava utilizar XMPP, mas à medida que a arquitetura foi crescendo ele foi se tornando um protocolo interessante e por fim se transformou no principal componente. Enfim, o importante é conhecer suas opções, estudar e experimentar. Mas sempre tenha na sua lista o XMPP e suas extensões, pois muito do que o arquiteto de software precisa criar já está escrito em algumas de suas especificações.

Filed under mensageria middleware protocol xmpp