<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Em 28-11-2010 19:35, Alexei Znamensky escreveu:
    <blockquote
      cite="mid:AANLkTimMnkrRXLz5TsWJ2w-mzdYyncMBFY713+2LaXVS@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div><br>
        </div>
        <div>Pessoal,</div>
        <div><br>
        </div>
        <div>Estou fazendo um trabalho paralelo ao do maluco e tenho
          "quebrado" as rotinas dessas classes em rotinas separadas de
          fetch, parsing e storage.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    Ótimo, a ideia é realmente separar estas tarefas em componentes.<br>
    <br>
    <blockquote
      cite="mid:AANLkTimMnkrRXLz5TsWJ2w-mzdYyncMBFY713+2LaXVS@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div>
        </div>
        <div>Acabei de alcançar algo funcionável e talvez merge-ável
          para a coleção de dados 'CEIS' (Empresas Sancionadas) do <a
            moz-do-not-send="true"
            href="http://PortalTransparencia.gov.br">PortalTransparencia.gov.br</a>.
          Acabei de subir para o branch 'rearch' no meu fork:</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <blockquote
      cite="mid:AANLkTimMnkrRXLz5TsWJ2w-mzdYyncMBFY713+2LaXVS@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div>
          <meta http-equiv="content-type" content="text/html;
            charset=UTF-8">
          <a moz-do-not-send="true"
            href="https://github.com/russoz/OpenData-BR/tree/rearch">https://github.com/russoz/OpenData-BR/tree/rearch</a></div>
        <div><br>
        </div>
        <div>Para conseguir fazer funcionar e apresentar prova de
          conceito, tive de fazer algumas pequenas gambis:</div>
        <div><br>
        </div>
        <div>* 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.</div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    <blockquote
      cite="mid:AANLkTimMnkrRXLz5TsWJ2w-mzdYyncMBFY713+2LaXVS@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div>* 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.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    A ideia do mongodb é exatamente ser um intermediário rápido, a
    utilização do RabbitMQ por exemplo é muito "simples" de ser
    "adotada".<br>
    <br>
    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.<br>
    <br>
    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 ? <br>
    <br>
    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().<br>
    <br>
    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.<br>
    <br>
    Então devemos manter uma base mais "esperta" para este tipo de
    tarefa.<br>
    <br>
    <blockquote
      cite="mid:AANLkTimMnkrRXLz5TsWJ2w-mzdYyncMBFY713+2LaXVS@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div>O código neste branch, agora (19:26), está passando nos
          testes, e o script ./scripts/<a moz-do-not-send="true"
            href="http://portaltransparencia.pl">portaltransparencia.pl</a>
          está funcionando.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    Ótimo, eu vou testar hoje pela noite, ou amanhã. Mas pelo código que
    vi, gostei! <br>
    <br>
    Valeu Russo! <br>
    <br>
    Abs!<br>
    -Thiago Rondon<br>
    <br>
  </body>
</html>