dadosjusbr / api Goto Github PK

Hoje em dia, a tabela aparece assim:

Melhorias:

1. O total também deveria aparecer aqui
2. Os números deveriam aparecer formatados (se possível também colocar o Bilhão e o Milhão como letras)
3. Subsídio não diz muito, precisamos colocar um nome melhor e em par com #81

Existem algumas planilhas na página que não estão dentro de um de uma "table" e consequentemente não estão dento de um "td"
Exemplos:

Tribunais Federais:

Tribunal Regional Federal da 1ª Região (Abrange os estados: AC, AM, AP, BA, DF, GO, MA, MG, MT, PA, PI, RO, RR)
Tribunal Regional Federal da 2ª Região (Abrange os estados: ES, RJ)
Tribunal Regional Federal da 3ª Região (Abrange os estados: MS, SP)
Tribunal Regional Federal da 4ª Região (Abrange os estados: PR, RS, SC)
Tribunal Regional Federal da 5ª Região (Abrange os estados: AL, CE, PB, PE, RN, SE)

=========================

 Tribunais Militares:

Tribunal de Justiça Militar do Estado de Minas Gerais
Tribunal de Justiça Militar do Estado de São Paulo 
Tribunal de Justiça Militar do Estado do Rio Grande do Sul 

Agora não é mais necessário o envio do arquivo zipado para o parser, basta enviar a url da planilha do CNJ.
Além disso, o parsing da planilha agora deve ser feito individualmente.

Parte importante. Seria massa vir antes do lançamento.

Como essa é a operação mais demorada e mais propícia a erros, acho importante logar arquivo a arquivo o tempo de parsing e o resultado.

Atualmente ele mantem a apiKey e cria uma instância do cliente a chamada do método Send. Ao invés disso, ele deve manter *sendgrid.Client.

Atualmente não há uma validação que não permita que os resultados do processamento de um mês sejam publicados mais de uma vez. Isso faz com que o mês em questão apareça diversas vezes na sidebar do dashboard, além de ocupar espaço desnecessário na nossa base de dados.

Descrição:

O intuito do parser é extrair, limpar e formatar os dados das planilhas (em formato .xls ou .xlsx) coletadas pelo crawler.
Atualmente temos um micoserviço implementado em NodeJS que recebe via requisição HTTP um zip contendo planilhas e devolve um CSV contendo todos os dados limpos e formatados.
Contudo, esse microserviço não é muito robusto, pouco performatico e a utilização da sua API adicionou bastante complexidade a essa aplicação.

Nesse sentido, proponho a implementação de um módulo escrito em Go, que irá funcionar de forma semelhante, contudo, a interação com ele será bem mais simples.

Sua API será simples:

func Parse(sheetReader io.Reader, type Type) ([][]string, ParsingError)

Onde Parse recebe:
r - o Reader da planilha
t - o tipo de planilha (Enum contendo XLS ou XLSX)
e retorna:
[][]string - os dados prontos para serem convertidos para CSV
ParsingError - uma estrutura de dados que encapsula todos os erros gerados durante o parsing

Detalhes de implementação

As bibliotecas

Para converter as planilhas que vem em formato .xls ou .xlsx em algo que possamos trabalhar, usaremos as seguintes bibliotecas: XLSX e XLS.

Como temos que usar uma biblioteca para cada formato de arquivo, elas serão usadas apenas para converter os dados contidos nas mesma para uma estrutura de dados que usaremos para coletar, limpar e formatar, evitando assim ter que escrever uma lógica para cada uma.

A estrutura de dados consiste em um array tridimensional, onde temos:
[aba][linha][coluna]

`aba` - o índice da aba, infelizmente a API de nenhuma das bibliotecas utilizadas para lidar com XLX/XLSX nos fornece uma forma de pegar o nome da aba, apenas seu índice
`linha` - o índice da linha
`coluna` - o índice da coluna 

Os Erros

É crucial para a aplicação que lidemos com os erros gerados de forma adequada.
Durante o parse, temos basicamente dois tipos de erro:

1. Erros da aplicação: Normalmente fruto de algum problema com leitura de arquivos ou gerado por algum problema na aplicação.
2. Erros nos dados: Erros provenientes de problemas nos dados da planilha, como informações fora do padrão, ou problemas com o preenchimento.

Como queremos tratar esses tipos de erros de forma diferente, dessa forma iremos classificá-los criando assim um tipo que encapsula os dois tipos de erro: ApplicationError e DataError.

Além disso, como um só parsing pode gerar mais de um erro, iremos criar outro tipo que encapsula um conjunto de erros: ParsingError.

Isso faz com que a versão do schema não seja validada

Aqui tem uma boa noção de como fazer: https://echo.labstack.com/guide/templates

Será que seria bacana ter um arquivo de contribuidores?

Link para o doc: https://drive.google.com/open?id=1_Q-QokIeaN6jkpMDaB6RMViCmFc7JYaArzEnKy46APA

Acho que vale a pena melhorar os seguintes pontos no gráfico:

1. Remover aquele resquício de legenda da parte de cima
2. Nos números do eixo y, se possível, colocar bilhão e milhão.
3. Subsídio não deixa claro que é salário (ou salário base). Temos que colocar um nome mais claro
4. Precisamos de uma legenda no texto explicando o que é cada um dos campos.

Atualmente o relatório de erros vem como abaixo. Como a ideia é a gente poder agir sobre ele, precisamos de mais informações:

1. Mês e Ano
2. que linha e, se possível, que coluna

Além disso acho que podemos formatar mais as coisas para deixar melhor para quem vai ler. Por exemplo, o nome da planilha, já pode vir em formato de link, dessa forma a pessoa que vai agir sobre o erro já pode baixar a planilha. Assim como o Mês e o ano virem em evidência.

O assunto também pode ser melhor descrito. Algo como "[dadosjusbr] Erro processando $mês/$ano"

the following error was found when parsing the file [895632a25f1d0693630735f57bd3846a.xls] The request returned an error with http status code 500 Error: [{ "Message": "sheet[headerLine] is not iterable", "Stack": "TypeError: sheet[headerLine] is not iterable\n at _getHeader (/app/src/parser.js:345:43)\n at _getOutraAndDetalheColumns (/app/src/parser.js:368:33)\n at _getSubsidioData (/app/src/parser.js:199:21)\n at parse (/app/src/parser.js:482:48)\n at getParsedSpreadsheet (/app/src/parser_service.js:51:29)\n at Layer.handle [as handle_request] (/app/node_modules/express/lib/router/layer.js:95:5)\n at next (/app/node_modules/express/lib/router/route.js:137:13)\n at Route.dispatch (/app/node_modules/express/lib/router/route.js:112:3)\n at Layer.handle [as handle_request] (/app/node_modules/express/lib/router/layer.js:95:5)\n at /app/node_modules/express/lib/router/index.js:281:22" }]

Isso é útil para facilitar checagens e auditorias

Criar um diretório mppb dentro de crawler.

A implementação deve ser um binário que recebe como flag o mês e o ano. A priori, deve poder ser executado de forma simples. Por exemplo:

go run main.go --mes=10 --ano=2018

Pode buscar dicas de implementação no crawler, mas não se atenham ou tentem reusar. Enquanto implementam observem o que é necessário baixar para criação do CSV segundo o dicionário de dados e a saída irá ser consumida pelo parser.

Isso vai facilitar também na hora de guardar os registros no BD

Atualmente é dífcil para um novo membro saber quais são os parâmetros para executar a CLI. Idealmente, esses parâmetros devem estar num formato auto-documentado, como flags.

Objetivo do projeto
Configurações necessárias
Como rodar a CLI
Como levantar o servidor

Hoje em dia nós obrigamos usuários a entrar na página se cada mês para baixar arquivos. Creio que podemos ter uma espécie de API para isso. Por exemplo:

dadosjusbr.online/2019/4/planilhas poderia servir como atalho e redirecionar para o arquivo com planilhas no pcloud. Da mesma forma dadojusbr.online/2019/4/datapackage ou algo do tipo poderia redirecionar para o pacote de dados.

O que acha, @viniagostini ?

Assim a página vai ficar ainda melhor como bookmark :D

Uma vez que as planilhas do MP são em ODS, vale a pena apostar no formato aberto e criar o parser usando Go.

Caso não existam bibliotecas boas ou estáveis o suficiente em Go, temos que começar a pensar no plano.

Essa separação do crawler está atrapalhando mais que ajudando. Se, no futuro, houver interesse, a gente cria um novo repo.

Isso pode ser importante para pessoas que quiserem realizar checagens.

Did some initial research and found out that the error is happening at store/client.go#77. The pcloud service is returning a 200 and actually failing the login phase.

{
  "result": 2000,
  "error": "Log in failed."
}

@tonysm .. any ideas?

Atualmente o responsável pelo envio de emails é o o processor.go, esse deve apenas retornar o erro e o tratamento (enviar email ou fazer log) deve ser de quem chama esse cara (worker e CLI)

For sucesses, lets keep the timestamp, link to pcloud raw and cleaned data.

For failures, lets keep as much information as we can.

Que dados queremos apresentar para resumir o mês dos magistrados? Temos que pensar essa tela o quanto antes para poder definir onde e como armazenaremos os dados. Somado a isso, que tipo de pré-processamento será executado.

Criar um diretório mppb dentro de crawler.

A implementação deve ser um binário que recebe como flag o mês e o ano. A priori, deve poder ser executado de forma simples. Por exemplo:

go run main.go --mes=10 --ano=2018

Pode buscar dicas de implementação no crawler, mas não se atenham ou tentem reusar. Enquanto implementam observem o que é necessário baixar para criação do CSV segundo o dicionário de dados e a saída irá ser consumida pelo parser.

A página http://www.cnj.jus.br/transparencia/remuneracao-dos-magistrados deixa claro que os tribunais enviam e eles só consolidam. Desta forma, seria muito útil se o dadosjusbr avisasse aos administradores quais tribunais não enviaram os dados. Dessa forma poderíamos colocar na página e agir para ter acesso a essas informações.

Hoje em dia listamos os meses que houve sucesso, porém visando aumentar a transparência sobre os problemas que na libertação desses dados, também temos que ter uma página para quando ocorrem erros.

O parser pode receber os vários conteúdos de arquivos e pode conter a lógica de consolidar tudo em apenas um CSV (uma vez que isso varia muito quando a API varia, tem que estar encapsulado lá).

Sugestão, no pacote parser/

type ServiceClient struct {
   url string
}

func NewServiceClient(url string) *ServiceClient {
   return &ServiceClient{url}
}

func (s ServiceClient) Parse(contents [][]byte) ([]byte, error) {
   ...
}

A ideia é, como só colocamos arquivos zipados na nuvem, vamos colocar esse código para dentro do store.

Isso permitirá vários tipos de filtragens

1. Criar consulta que retorne todas os campos Month e Year dos documentos que tenham o campo Success: true
2. Gerar as urls com base nos meses e anos recuperados no passo acima
3. alimentar o template do mês com esses caras

Criar um diretório mppb dentro de crawler.

A implementação deve ser um binário que recebe como flag o mês e o ano. A priori, deve poder ser executado de forma simples. Por exemplo:

go run main.go --mes=10 --ano=2018

Pode buscar dicas de implementação no crawler, mas não se atenham ou tentem reusar. Enquanto implementam observem o que é necessário baixar para criação do CSV segundo o dicionário de dados e a saída irá ser consumida pelo parser.

Link do doc: https://drive.google.com/open?id=1GAvCyPPkiFnAUvNLfMfJF4jYLeOnVE0JyY6tRlFAkCI

O CLI deve ser uma aplicação que permite processar um conjunto de planilhas para um mês específico localmente obtendo os mesmo resultados da execução automática.

Para funcionar o CLI precisa das seguintes variáveis de ambiente:
SENDGRID_API_KEY, PCLOUD_USERNAME, PCLOUD_PASSWORD
é de sua responsabilidade capturá-las e instanciar seus respectivos clientes que serão passados para o processor executar o trabalho.

Além disso, o CLI recebe como parâmetro em sua chamada alguns argumentos, são eles:
mês, ano e caminho para o diretório onde estão as planilhas

No pacote crawler/

type Result struct {
   Name string
   URL string
   Body []byte
}

type Results []Result

func Crawl(url string) (Results, error) {
  ...
}

Essa mudança tem que ser usada pelo process

Quando um erro ocorre no Parser o mesmo manda como resposta um httpStatus 4xx ou 5xx, é preciso fazer essa checagem em parser.go -> request e coletar o erro para que o mesmo seja tratado por quem chama esse cara.

Hoje, ao compartilhar o dadosjusbr.online no whatsapp a caixinha de compartilhamento aparece assim:

Precismos colocar as tags de compartilhamento social para aparecer a logo e etc.

Algumas modificações no packager dever ser feitas para contemplar modificações arquiteturais que fizeram com que o schema seja requisitado via http request ao serviço do Parser.

• fazer com que o processor faça a requisição para obter o JSON do schema¹
• modificar a API do packager para que o mesmo passe a receber o schema
• modificar chamada para o packager no processor, agora passando o schema

¹ essa tarefa é do processor porque ele precisa da versão do schema. Inclusive, acredito que ainda seja trabalho dele fazer o json.Unmarshal do JSON retornado na requisição.

O pacote de dados prevê um campo para licença, que acho que devemos usá-lo. Além disso, temos que deixar claro que todo material disponibilizado sobre uma licença.

Minha sugestão é utilizar CC-BY-SA. O que acha, @viniagostini ?

Isso é importante pois esperamos ter uma base de usuários mobile grande acessando o portal

Temos diversos logs que acabam poluindo a visualização dos logs que teremos em produção, esses caras são importantes para desenvolvimento e devem estar escondidos atrás de uma flag de debug.

É desejável que os dados coletados sejam publicados no datahub.io.

Até o momento a única forma fácil de fazer isso é utilizando o cliente javascript provido por eles. No entanto, queremos que nossa aplicação em Go interaja com esse serviço.

Assim, precisamos investigar qual a melhor forma, podendo ser esta escrever um cliente em Go.

Com isso, ele salva o html enviado da página de 404 do CNJ e quando chega no Parser um erro ocorre.

Esse erro sendo detectado na etapa de crawling evita que todas as outras planilhas seja baixadas e Parseadas.

Uma vez que temos os dados e um bom esquema, podemos validar esses dados. Uma opção seria googletables.io, porém precisamos tornar nossos dados publicamente acessíveis (sem precisar apertar o botão download do pcloud). Opções são AWS S3 ou GCP.

Com isso, podemos disparar usar a versão que automaticamente checa o bucket (atualmente só disponíve no S3) ou usar a API JS. No segundo caso, talvez o o próprio parser pode realizar a validação.

Outra opção é criar um pacote cliente em Go baseado na versão JS.

Seria bacana uma seção sobre o projeto. Tipo essa http://vidinhadebalada.com/#!/sobre