Finalizamos a primeira versão do plugin que retornará para o Colab informações sobre os profiles do Noosfero. Assim terminamos essa história nessa sprint.
Nesse primeiro momento mantivemos em um plugin separado e depois reveremos se colocamos no plugin do software.
Terceiro e Sérgio,
Quando possível, podem dar uma olhada para gente para ver se a idéia é essa mesmo?
On Mon, Feb 09, 2015 at 03:38:29PM -0200, Gabriela Matias Navarro wrote:
> Pessoal, > > Finalizamos a primeira versão do plugin que retornará para o Colab > informações sobre os profiles do Noosfero. Assim terminamos essa história > nessa sprint. > > Nesse primeiro momento mantivemos em um plugin separado e depois reveremos > se colocamos no plugin do software. > > Terceiro e Sérgio, > > Quando possível, podem dar uma olhada para gente para ver se a idéia é essa > mesmo? > > Link para o repositório -> >https://beta.softwarepublico.gov.br/gitlab/softwarepublico/colab_integration
comentários depois de dar uma olhada no código:
- acho que vocês esqueceram o requisito de poder receber um timestamp, e retornar todos os itens mais recentes que aquele timestamp. Exportar tudo o tempo todo não é sustentável (pense que em algum ponto podemos ter milhares de usuários e comunidades, dezenas de milhares de artigos).
Cada exportação tem que retornar o timestamp atual pra que o cliente possa guardar pra passar na próxima requisição, e só receber os itens novos ou atualizados desde então.
- eu *detesto* plugins que inserem coisas nas classes do core. se você tiver muitos desses habilitados, uma hora vai dar m****. Além disso, um dos princípios do bom projeto OO é "prefira composição ao invés de herança".
Ao invés de incluir coisas nas classes do core, vocês podem fazer coisas simples como:
```ruby class MyPlugin::ProfileExporter def initialize(profile) @profile = profile end
def to_json # generate the JSON data here, accessing the data from @profile end end ```
nessa Sprint estamos trabalhando com algumas melhorias no plugin que vai fornecer dados de Profiles ao Colab por JSON. Implementamos também o esquema de timestamp para enviar somente dados que foram atualizados e também adicionamos os dados gerais das atividades feitas pelos Profiles.
Temos algumas perguntas conceituais e de implementação também que podem ser respondidas ou pensadas também pelo Sergio e pelo Maia:
- Tem a possibilidade de termos problema de Timeout quando fizermos a primeira requisição para pegar os dados ou conseguimos gerenciar isso no lado do Colab? - A ideia de passarmos as atividades do mural do Usuário e de Comunidades na API do Nossfero para o Colab é com o objetivo do Colab realizar contagem e gamificar depois essas informações de atividade ou é pra ele montar um mural próprio com as informações da atividade e links para ela? - Por enquanto, implementamos o mecanismo de filtro com timestamp somente para filtrar quais perfis sofreram atualização desde a última requisição. Uma vez filtrados os perfis que foram atualizados, retornamos todos os seus dados completos novamente. É esse o comportamento esperado mesmo?
att Arthur
Em 12 de fevereiro de 2015 11:10, Antonio Terceiro < terceiro@softwarelivre.org> escreveu:
> On Mon, Feb 09, 2015 at 03:38:29PM -0200, Gabriela Matias Navarro wrote: > > Pessoal, > > > > Finalizamos a primeira versão do plugin que retornará para o Colab > > informações sobre os profiles do Noosfero. Assim terminamos essa história > > nessa sprint. > > > > Nesse primeiro momento mantivemos em um plugin separado e depois > reveremos > > se colocamos no plugin do software. > > > > Terceiro e Sérgio, > > > > Quando possível, podem dar uma olhada para gente para ver se a idéia é > essa > > mesmo? > > > > Link para o repositório -> > > >https://beta.softwarepublico.gov.br/gitlab/softwarepublico/colab_integration > > comentários depois de dar uma olhada no código: > > - acho que vocês esqueceram o requisito de poder receber um timestamp, e > retornar todos os itens mais recentes que aquele timestamp. Exportar > tudo o tempo todo não é sustentável (pense que em algum ponto podemos > ter milhares de usuários e comunidades, dezenas de milhares de > artigos). > > Cada exportação tem que retornar o timestamp atual pra que o cliente > possa guardar pra passar na próxima requisição, e só receber os itens > novos ou atualizados desde então. > > - eu *detesto* plugins que inserem coisas nas classes do core. se você > tiver muitos desses habilitados, uma hora vai dar m****. Além disso, > um dos princípios do bom projeto OO é "prefira composição ao invés de > herança". > > Ao invés de incluir coisas nas classes do core, vocês podem fazer > coisas simples como: > > ```ruby > class MyPlugin::ProfileExporter > def initialize(profile) > @profile = profile > end > > def to_json > # generate the JSON data here, accessing the data from @profile > end > end > ``` > > -- > Antonio Terceiro >http://softwarelivre.org/terceiro > > > > _______________________________________________ > spb-dev mailing list > spb-dev@listas.softwarepublico.gov.br >http://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev > >
On Thu, Mar 26, 2015 at 11:46:23AM -0300, Arthur Del Esposte wrote:
> Terceiro, > > nessa Sprint estamos trabalhando com algumas melhorias no plugin que vai > fornecer dados de Profiles ao Colab por JSON. > Implementamos também o esquema de timestamp para enviar somente dados que > foram atualizados e também adicionamos os dados gerais das atividades > feitas pelos Profiles. > > Temos algumas perguntas conceituais e de implementação também que podem ser > respondidas ou pensadas também pelo Sergio e pelo Maia: > > - Tem a possibilidade de termos problema de Timeout quando fizermos a > primeira requisição para pegar os dados ou conseguimos gerenciar isso no > lado do Colab?
se o noosfero demorar demais pra mandar todos os dados, é ruim pra ele também. podemos pensar em fazer uma chamada que retorna razoavelmente rápido que contém só a lista de usuários (adicionados/modificados deste o timestamp passado, se for passado), e uma outra que retorna dados de um usuário específico. aí do lado do colab a gente pode escolonar isso pra colocar essas requisições pros dados de cada usuário adicional (ou de N em N) a serem feitas numa fila, e processadas em background.
> - A ideia de passarmos as atividades do mural do Usuário e de Comunidades > na API do Nossfero para o Colab é com o objetivo do Colab realizar contagem > e gamificar depois essas informações de atividade ou é pra ele montar um > mural próprio com as informações da atividade e links para ela?
essa eu não sei responder.
> - Por enquanto, implementamos o mecanismo de filtro com timestamp somente > para filtrar quais perfis sofreram atualização desde a última requisição. > Uma vez filtrados os perfis que foram atualizados, retornamos todos os seus > dados completos novamente. É esse o comportamento esperado mesmo?
acho que isso resolve, e que algo mais sofisticado do que isso agora pode dar muito mais trabalho e não está claro pra mim se vai trazer valor adicional.
> On Thu, Mar 26, 2015 at 11:46:23AM -0300, Arthur Del Esposte wrote: > > Terceiro, > > > > nessa Sprint estamos trabalhando com algumas melhorias no plugin que vai > > fornecer dados de Profiles ao Colab por JSON. > > Implementamos também o esquema de timestamp para enviar somente dados que > > foram atualizados e também adicionamos os dados gerais das atividades > > feitas pelos Profiles. > > > > Temos algumas perguntas conceituais e de implementação também que podem > ser > > respondidas ou pensadas também pelo Sergio e pelo Maia: > > > > - Tem a possibilidade de termos problema de Timeout quando fizermos a > > primeira requisição para pegar os dados ou conseguimos gerenciar isso no > > lado do Colab? > > se o noosfero demorar demais pra mandar todos os dados, é ruim pra ele > também. podemos pensar em fazer uma chamada que retorna razoavelmente > rápido que contém só a lista de usuários (adicionados/modificados deste > o timestamp passado, se for passado), e uma outra que retorna dados de > um usuário específico. aí do lado do colab a gente pode escolonar isso > pra colocar essas requisições pros dados de cada usuário adicional (ou > de N em N) a serem feitas numa fila, e processadas em background. >
Acho uma boa ter chamadas alternativas assim mesmo. No mais, talvez se as atualizações forem constantes e as chamadas também, cada requisição tende a ser a menor possível né!
> > > - A ideia de passarmos as atividades do mural do Usuário e de Comunidades > > na API do Nossfero para o Colab é com o objetivo do Colab realizar > contagem > > e gamificar depois essas informações de atividade ou é pra ele montar um > > mural próprio com as informações da atividade e links para ela? > > essa eu não sei responder. > > > - Por enquanto, implementamos o mecanismo de filtro com timestamp somente > > para filtrar quais perfis sofreram atualização desde a última requisição. > > Uma vez filtrados os perfis que foram atualizados, retornamos todos os > seus > > dados completos novamente. É esse o comportamento esperado mesmo? > > acho que isso resolve, e que algo mais sofisticado do que isso agora > pode dar muito mais trabalho e não está claro pra mim se vai trazer > valor adicional. > > -- > Antonio Terceiro >http://softwarelivre.org/terceiro > > > > _______________________________________________ > spb-dev mailing list > spb-dev@listas.softwarepublico.gov.br >http://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev > >
On Thu, Mar 26, 2015 at 10:04:28PM -0300, Arthur Del Esposte wrote:
> > On Thu, Mar 26, 2015 at 11:46:23AM -0300, Arthur Del Esposte wrote: > > > Terceiro, > > > > > > nessa Sprint estamos trabalhando com algumas melhorias no plugin que vai > > > fornecer dados de Profiles ao Colab por JSON. > > > Implementamos também o esquema de timestamp para enviar somente dados que > > > foram atualizados e também adicionamos os dados gerais das atividades > > > feitas pelos Profiles. > > > > > > Temos algumas perguntas conceituais e de implementação também que podem > > ser > > > respondidas ou pensadas também pelo Sergio e pelo Maia: > > > > > > - Tem a possibilidade de termos problema de Timeout quando fizermos a > > > primeira requisição para pegar os dados ou conseguimos gerenciar isso no > > > lado do Colab? > > > > se o noosfero demorar demais pra mandar todos os dados, é ruim pra ele > > também. podemos pensar em fazer uma chamada que retorna razoavelmente > > rápido que contém só a lista de usuários (adicionados/modificados deste > > o timestamp passado, se for passado), e uma outra que retorna dados de > > um usuário específico. aí do lado do colab a gente pode escolonar isso > > pra colocar essas requisições pros dados de cada usuário adicional (ou > > de N em N) a serem feitas numa fila, e processadas em background. > > > > Acho uma boa ter chamadas alternativas assim mesmo. No mais, talvez se as > atualizações forem constantes e as chamadas também, cada requisição tende a > ser a menor possível né!
Gabriela Navarro
Antonio Terceiro
Arthur Esposte