[SP-pm] OpenData-BR

[Thiago Rondon]

Em 28-11-2010 19:35, Alexei Znamensky escreveu:
>
> Pessoal,
>
> Estou fazendo um trabalho paralelo ao do maluco e tenho "quebrado" as 
> rotinas dessas classes em rotinas separadas de fetch, parsing e storage.
>
Ótimo, a ideia é realmente separar estas tarefas em componentes.

> Acabei de alcançar algo funcionável e talvez merge-ável para a coleção 
> de dados 'CEIS' (Empresas Sancionadas) do PortalTransparencia.gov.br 
> <http://PortalTransparencia.gov.br>. Acabei de subir para o branch 
> 'rearch' no meu fork:
>
> https://github.com/russoz/OpenData-BR/tree/rearch
>
> Para conseguir fazer funcionar e apresentar prova de conceito, tive de 
> fazer algumas pequenas gambis:
>
> * o role 'Provider::Collection' está implementando a funcionalidade do 
> browser (método get(), para ser preciso), mas esse não é um bom lugar 
> para isso.

Eu fiz algumas alterações nesta role no final de semana, que assim que 
tiverem mais estáveis eu vou jogar no repositório. Basicamente utilizei 
o Coro para ganhar velocidade com as chamadas ao método get.

> * o role 'Provider', segundo a idéia original, teria um atributo 
> 'loader' que seria do tipo 'OpenData::Loader' - e isso implementaria 
> um método 'load()' que serviria para carregar os dados em algum 
> repositório (ou canal de comunicação - nada impede que, no futuro 
> tenhamos um loader que jogue os dados em uma file RabbitMQ, ou mesmo 
> IBM MQ, ou um feed RSS, whatever). Como esse role Loader ainda não foi 
> criado, e para simplificar a demonstração, mudei a restrição de Loader 
> para Object, implementei o método 'load()' na classe 
> 'OpenData::Output::Dumper' e deixei a classe 
> 'OpenData::BR::Federal::PortalTransparencia' usando esse "loader" ou 
> "output" por default, ao invés do MongoDB que é o que estava antes.
>

A ideia do mongodb é exatamente ser um intermediário rápido, a 
utilização do RabbitMQ por exemplo é muito "simples" de ser "adotada".

Imagine no caso de rodarmos vários "buscadores" em máquinas diferentes 
por conta de velocidade, restrições de acesso, e etc, etc.. e todos 
estes buscadores jogarem os dados coletados em uma fila única para 
processamento.

Se formos mais adiante.. Deixar o processo asincrono pode ser uma grande 
vantagem, caso a ideia seja vamos jogar tudo o que estamos buscando em 
uma fila, e então depois nós retiramos e jogamos por exemplo no storage 
(eg. mongodb), correto ?

A ideia do mongodb é para introspecar dados em uma busca mais 
inteligente, a vantagem dele não ter esquemas (assim como o rabbitmq) e 
ser você pode enviar documentos (assim como no rabbitmq), porém ele é um 
"storage". Um exemplo é de ter um método create_or_update() no 
collection, no lugar de add().

Outra preocupação e já levantada no canal de IRC, e que o nosso papel é 
também auditar, saber se o website do governo foi alterado de um dia 
para outro, por algum interesse.

Então devemos manter uma base mais "esperta" para este tipo de tarefa.

> O código neste branch, agora (19:26), está passando nos testes, e o 
> script ./scripts/portaltransparencia.pl 
> <http://portaltransparencia.pl> está funcionando.
>
Ótimo, eu vou testar hoje pela noite, ou amanhã. Mas pelo código que vi, 
gostei!

Valeu Russo!

Abs!
-Thiago Rondon

-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20101129/b7938c01/attachment.html>