Plataforma para Cidades Inteligentes 2016: mudanças entre as edições
Sem resumo de edição |
|||
Linha 13: | Linha 13: | ||
* [https://gitlab.com/smart-city-software-platform Repositórios de código fonte] | * [https://gitlab.com/smart-city-software-platform Repositórios de código fonte] | ||
* [https://docs.google.com/spreadsheets/d/1DeJXh8m6sKoPvf85kGV_0V_u2yjlI_94Xn5-N2WkwEY/edit#gid=0 Planilha de presença] | * [https://docs.google.com/spreadsheets/d/1DeJXh8m6sKoPvf85kGV_0V_u2yjlI_94Xn5-N2WkwEY/edit#gid=0 Planilha de presença] | ||
== Histórinha == | |||
Durante a disciplina, a equipe de Smart Cities trabalhou ao longo das interações para contemplar três frentes principais: | |||
* Processamento de Dados Coletados | |||
* DevOps para desenvolvimento | |||
* Serviços de Visualização dos dados | |||
Foram realizadas quatro iterações, com duas semanas cada. | |||
Devido a complexidade da arquitetura de microserviços, que envolve vários repositórios, conceitos e integração, a primeira iteração foi focada na configuração do ambiente de desenvolvimento. A equipe observou que era necessário automatizar esse ambiente para que fosse possível e menos custoso ter a plataforma completa rodando, facilitando futuras contribuições. | |||
Assim, durante as duas primeiras iterações, foi negociado com cliente que metade do escopo da iteração seria destina à resolução dívidas técnicas, automatização do ambiente, melhoria da documentção e estudos. A outra metade foi utilizada para o desenvolvimento do microserviço Resource Viewer cujo objetivo é apresentar uma página web com os sensores integrados na plataforma e seus dados. | |||
As outras duas iterações foram focadas nas prioridades do cliente relacionado ao processamento de dados da plataforma e à visualização dos recursos. Assim, avançamos em direção a integrar os dados de ônibus da API Olho Vivo na plataforma e processar esses dados com o Spark (Framework de Big Data). Para isso, foi necessário realizar mudanças arquiteturais na comunicação dos serviços, onde adotou-se uma comunicação baseado em eventos com o Message Broker RabbitMQ. A equipe também avançou no serviço de visualização, apresentando dados em tempo-real dos sensores, uma página de detalhes para cada sensor com um mapa que apresenta sua localização na cidade. Por fim, vale ressaltar que foram adicionados testes automatizados para verificar a integração dos microserviços da plataforma, testes de aceitação para o Resource Viewer e correção da Integração Contínua de alguns repositórios. | |||
A equipe evoluiu muito durante as iterações, se tornando mais auto-organizável e aprimorando conhecimetos técnicos. Destacamos aqui os conhecimentos relacionados ao Docker, automatização de ambiente, ao framework EmberJS, Spark, ShellScript, Rails e sobre arquiteturas distribuídas. Da mesma forma, a equipe experimentou novas abordagens visando melhorar o desempenho no desenvolvimeto, compartilhamento de conhecimento e qualidade do código. Como exemplo, tentamos aplicar uma estratégia de rotacionamento dos pares a cada 30 minutos, que não se mostrou eficiente devido a complexidade das tarefas as quais requeriam maior tempo para total compreensão. Por outro lado, a prática de revisão de código baseado em Merge Requests funcionou bem para motivar os membros da equipe que desejavam finalizar as tarefas fora dos horários pré-estabelecidos e posteriormente explicavam o código implementado para todos os membros da equipe. | |||
Todo o código desenvolvido está disponível https://gitlab.com/smart-city-software-platform |
Edição atual tal como às 12h08min de 9 de dezembro de 2016
Time
- Ariel Palmeira
- Arthur de Moura Del Esposte (coach)
- Macártur de sousa carvalho
- Thiago Petrone
- Marisol solis yucra
- Lucas Kanashiro Duarte
Informações gerais
Histórinha
Durante a disciplina, a equipe de Smart Cities trabalhou ao longo das interações para contemplar três frentes principais:
- Processamento de Dados Coletados
- DevOps para desenvolvimento
- Serviços de Visualização dos dados
Foram realizadas quatro iterações, com duas semanas cada.
Devido a complexidade da arquitetura de microserviços, que envolve vários repositórios, conceitos e integração, a primeira iteração foi focada na configuração do ambiente de desenvolvimento. A equipe observou que era necessário automatizar esse ambiente para que fosse possível e menos custoso ter a plataforma completa rodando, facilitando futuras contribuições.
Assim, durante as duas primeiras iterações, foi negociado com cliente que metade do escopo da iteração seria destina à resolução dívidas técnicas, automatização do ambiente, melhoria da documentção e estudos. A outra metade foi utilizada para o desenvolvimento do microserviço Resource Viewer cujo objetivo é apresentar uma página web com os sensores integrados na plataforma e seus dados.
As outras duas iterações foram focadas nas prioridades do cliente relacionado ao processamento de dados da plataforma e à visualização dos recursos. Assim, avançamos em direção a integrar os dados de ônibus da API Olho Vivo na plataforma e processar esses dados com o Spark (Framework de Big Data). Para isso, foi necessário realizar mudanças arquiteturais na comunicação dos serviços, onde adotou-se uma comunicação baseado em eventos com o Message Broker RabbitMQ. A equipe também avançou no serviço de visualização, apresentando dados em tempo-real dos sensores, uma página de detalhes para cada sensor com um mapa que apresenta sua localização na cidade. Por fim, vale ressaltar que foram adicionados testes automatizados para verificar a integração dos microserviços da plataforma, testes de aceitação para o Resource Viewer e correção da Integração Contínua de alguns repositórios.
A equipe evoluiu muito durante as iterações, se tornando mais auto-organizável e aprimorando conhecimetos técnicos. Destacamos aqui os conhecimentos relacionados ao Docker, automatização de ambiente, ao framework EmberJS, Spark, ShellScript, Rails e sobre arquiteturas distribuídas. Da mesma forma, a equipe experimentou novas abordagens visando melhorar o desempenho no desenvolvimeto, compartilhamento de conhecimento e qualidade do código. Como exemplo, tentamos aplicar uma estratégia de rotacionamento dos pares a cada 30 minutos, que não se mostrou eficiente devido a complexidade das tarefas as quais requeriam maior tempo para total compreensão. Por outro lado, a prática de revisão de código baseado em Merge Requests funcionou bem para motivar os membros da equipe que desejavam finalizar as tarefas fora dos horários pré-estabelecidos e posteriormente explicavam o código implementado para todos os membros da equipe.
Todo o código desenvolvido está disponível https://gitlab.com/smart-city-software-platform