brosquinha / legislei Goto Github PK

Criar uma pasta "legislei" na raíz do projeto para conter todo o código do aplicativo (no estilo package do Python) e reorganizar código em módulos onde for possível.

Finalmente arrumaram a rota de listagem de vereadores da Câmara Municipal de São Paulo! Agora, posso substituir o vereança por essa rota, o que finalmente me possibilita utilizar os ids dos vereadores para fazer buscas por suas atividades!

As requisição do Heroku tem limite de 30s. Assim, para gerar um relatório de um parlamentar, é necessário que o relatório seja obtido em um work em background.

Nova feature: adicionar avaliações de notícias da mídia de seu parlamentar

A funcionalidade de configurar um intervalo de envio de relatórios diferente do padrão semanal foi solicitada. Portanto, mãos à obra.

Isso não deveria acontecer.

A única maneira de obter o voto de pautas de sessões é através da API antiga da Câmara dos Deputados, através do endpoint ObterVotacaoProposicao. O problema é que o id da sessão desse endpoint não é o mesmo id do evento da API nova. Portanto, o único jeito de filtrar a votação pelo evento correto é através da data e horário da sessão de votação e o evento em questão.

A tela de avaliações de um parlamentar precisa ser terminada com um import dos componentes de eventos e proposições da view de relatório.

Como é sabido, o servidor imbutido do Flask não foi feito para ser rodado em produção. Dessa forma, preciso escolher algum server para rodar a aplicação em produção. O próprio Flask tem uma lista de recomendações.

Se optar por uWSGI e Nginx, já existe uma imagem Docker com essa configuração, mas é necessário estudar a forma de integrar isso ao Heroku.

Obter a presença geral de cada sessão, inclusive de eventos ausentes, para determinar, por exemplo, se uma eventual ausência foi para obstrução.

Na rota de obtenção de parlamentar, cabe às camadas das casas legislativas verificar se um id fornecido é válido ou não. Hoje, elas (pelo menos a da Câmara dos Deputados não está, vide a issue do Sentry relacionada) não fazendo essa validação e, portanto, é necessário mudar esse comportamento.

Hoje, estourou uma issue no Sentry (LEGISLEI-4) causada por uma falha na migration 003. O motivo dessa falha foi que aparentemente a API REST da Câmara dos Deputados pode retornar eventos repetidos (ou seja, o mesmo evento mais de uma vez). Para corrigir a falha apontada no Sentry, precisei manualmente corrigir os pontos de falha da migration.

Como o Legislei presume que os eventos são únicos, é necessário fazer uma verificação no retorno da API da Câmara para eliminar duplicatas. Um ponto de atenção, porém, é que acontece algumas vezes de uma das instâncias do evento duplicado ter como situação "Não Confirmada" e a(s) outra(s) outra situação definitiva. Dessa forma, é necessário eliminar as duplicatas dando preferência às instâncias "Não Confirmadas" antes de outras situações.

Foi reportado que os dados de votações da API da Câmara de Deputados não eram confiáveis, e agora as rotas foram retiradas do ar. Portanto, é preciso adaptar o relatório com essa nova realidade.

A versão do Flask utilizada é antiga (até acionou um security alert no GitHub). Precisamos atualizá-la para acima da 1.0

Como a lista de parlamentares vai mudar (e pode mudar a qlqr momento), transferir o cache da lista de localStorage para cookie com data limitada.

Reestruturar testes e escrever testes de integração da aplicação.

Com a refatoração que tira lógica de negócio do web controller e substitui PyMongo por MongoEngine, a ideia agora é corrigir algumas coisas do banco de dados e escrever uma migration para prod. As mudanças pensadas são as seguintes:

• Mudar tipo de dataInicial e dataFinal de Relatorio de string para DateTime;
• Remover campo IdTemp de Relatorio;
• Mudar tipo de dataInicial e dataFinal de Evento de string para DateTime;
• Mudar tipo de dataAprentacao de Proposicao de string para DateTime;
• Mover Inscricoes para um campo de Users.

Mais uma vez, houve uma exceção do DTO de relatórios, mais uma vez devido ao parse de data... corrigir esse cara: https://sentry.io/share/issue/6eeee28fdc9543cba2c0bec7f490f5c6/

Na página MinhasAvaliações, quando se clica em Últimos relatórios de um parlamentar, o modal fica com o corpo vazio se o parlamentar em questão não tiver nenhum relatório no sistema, o que deixa o novo usuário confuso. Colocar uma mensagem padrão para esse cenário.

Terminar de obter os dados possíveis dos webservices da Câmara Municipal de São Paulo.

Se houver um erro ao obter relatório de qualquer parlamentar (como aconteceu nesse fds, em que o portal de dados abertos da ALESP estava fora do ar novamente), o scheduler é interrompido porque não há tratamento desse cenário de erro. Consertar isso!

Sugestão: https://sentry.io/for/flask/

Antes dos schemas definidos, eu usava o padrão [{'error': True}] para sinalizar que o campo em questão (pauta de um evento, uma proposição em particular, votações) não foi possível obter do servidor. Agora, com os schemas, preciso definir alguma flag para fazer essa sinalização.

Já que a ALESP não está corrigindo o bug em que a rota de deputados está retornando um id nulo para todos os deputados novatos, então temos que fazer uma gambiarra do nosso lado...

Uma ideia é consultar a página de um deputado através de https://www.al.sp.gov.br/alesp/deputado/?matricula=Matricula, e obter do código-fonte o id IdSPL dos links de normas estaduais e/ou proposições.

Para fazer o app e para uma eventual reestruturação do front com algum framework (como React ou Angular), é necessário primeiro reestruturar a API da aplicação. Para tanto, o ideal seria fazer uma API seguindo os padrões REST. A lib indicada para facilitar essa construção e fornecer documentação automática é a flask-restplus.

O front já está começando a ficar complexo a ponto de um framework (Angular, Vue.js) cair bem. Porém, a consequência disso é que o aplicativo precisará de mais de um container Docker, e o Heroku só fornece um container web por projeto.

Essa semana (27/07/2019), a API REST da Câmara dos Deputados apresentou um problema na rota /eventos (detalhes aqui). Para identificar o problema, porém, precisei fazer algumas modificações na CamaraDeputadosConnectionError para identificar direitinho a rota impactada. O ideal seria que essa e todas as demais classes de exceptions de todas as libs já captassem todas as informações necessárias para um debug em prod. Também preciso de uma forma de guardar o log disso tudo.

Para diminuir o tamanho da imagem Docker do projeto, uma ideia é usar a imagem Alpine ao invés da do Ubuntu: https://hub.docker.com/_/alpine

Para melhorar a legibilidade e lógica do código, melhor fazer uso da lib Flask-MongoEngine para usar seus schemas para fazer verificações de consistência de dados.

Por exemplo, estão disponíveis os dados de votação do PL 11021/2018, mas o gerador de relatório da Câmara dos Deputados não está apresentado-os. Investigar o que está causando esse problema e corrigií-lo.

Adicionar aos SDKs a possibilidade de mockar (stubar mais precisamente) as chamadas de API, visando aos testes (lembrar dos stubs do boto3).

Para começar a resolver a questão da comissão do PL Escola s/ Partido da última semana de Outubro de 2018. Assim, precisa-se obter o resultado de reuniões da Câmara dos Deputados de comissões através da antiga API, o webservice Orgãos.

Acrescentar um botãozinho de remoção de avaliação na tela de avaliações de um parlamentar. Estudar a possibilidade de remover avaliação na página de relatório quando clicar no mesmo botão de avaliação duas vezes.