v2.5.0

[unRob]

Por acelerado, no pensé jamás en la arquitectura de esta madre y terminó siendo un cagadero. Hablando con @miguelsalazar me puse a hacer memoria de pa dónde quería que se moviera este pedo y pa que les cuento, mejor lo documento. Representantes Patito debe ser tres cosas: "Repre", "Sentantes", y "Patito". No, no es cierto, pero si deben ser tres partes:

Generadores / Agregador

Lo que existe ahora en /bin es difícil de mantener pues los congresos cambian en chinga, y la dependencia de ruby me late que limita a que más banda contribuya. Era el año de 2015, cuando en retiro-jaq-v0.0.0 le escuché una muy buena idea al @tlacoyodefrijol, y quedé convencido que sería ideal desacoplar la adquisición de datos, de la fuente final para su consumo. Entonces, para lograrlo, este asunto debe:

Generar datos de congresos de manera distribuida

El plan es separar cada scraper a su propio repo encargado de generar archivos con la información de cada congreso. Hoy existen 8 scrapers escritos en ruby que no han sido actualizados desde hace dos años (y que pues hice con las patas). Los archivos generados deben seguir una estructura común y encontrarse en un formato estándar de intercambio de datos. Yo soy fan de YAML, pero chance hay algo más adecuado.

Abusar de git y Github

Por otro lado, creemos un repo para que los generadores puedan aportar la información y desde aquí se distribuya. Creo que podemos abusar de Git y github, pues da chance de clonar el repo para obtener la información vigente del congreso, con el beneficio de poder usar el historial para navegar cambios. Además, se puede usar el API de github para obtener programáticamente los mismos datos.

Como seguro sigue habiendo congresos que entiendan por formato de intercambio de datos un PDF de asistencias escaneadas, este esquema permite hacer pull requests que no necesariamente vengan de un generador, sino de peticiones de información pública y/o valientes que transcriban.

Por ejemplo, la información se podría guardar como:

- /camaras
  - /($ID_ENTIDAD-)?$NOMBRE (senado, diputados, 01-aguascalientes)
    - ln -s $LATEST _actual
    - /$STARTED-$ENDED (20160130-20161231)
      - info.???
      - comisiones.???
- /representantes
  - /$CURP
    - imagen.jpg
    - info.???
    - stats/
      - asistencias.???
      - votaciones.???

---

TODO:

• Determinar estructuras de datos (schema)
• Determinar formato de intercambio de datos (yml? json?)
• Determinar id para representantes
• Crear el repo agregador
• Separar scrapers existentes a sus repos
• Actualizar / Reemplazar scrapers exsitentes

Ingesta / API

Ingestar los datos fue un pedo porque nunca averigué cómo seguir mostrando la info de la legislaturas vigentes y anteriores; esto resultó en que se detuviera por completo el desarrollo del proyecto. Ya que la idea empezó como un cliente para la ALDF, el API fue hecho para atender necesidades de render y en consecuencia los endpoints no son claros por si mismos. Esto se puede resolver en corto:

Haciendo una herramienta de ingesta

Bien pues, se trata de crear una herramienta que se encargue de obtener los datos en el formato estándar de ... (yayson, digámosle yayson porque ya me cansé de escribir formato estándar ...) y proyectarla a una base de datos.

Secretario es una herramienta de comandos que se encarga de obtener datos de Github. Por ahora sólo consume los distritos electorales, pero la idea es que haga uso del repo agregador para crear la base del API. El nombre de dos lados: secretario par-ti-cu-lar y mi total agrado con Bojack Horseman 🐴.

El plan es usarlo continuamente para mantener la información siempre actualizada, hasta se puede integrar con webhooks y nadie tiene que amenazar con usar jenkins.

API

Ya con los datos machacados en la base de datos, entonces sí extraemos el API existente que puede:

• Obtener representantes por [lat, lng],
• Obtener representantes por id_seccion,
• Buscar representantes por nombre,
• Obtener representante por slug, y
• Obtener imagen de representante por id

Eso sí, creo que no hice bien REST y pensé más en lo que usaría el cliente. Habrá que re-acomodar endpoints y pensar bien en la arquitectura.

---

TODO:

• Implementar consumidor del repo agregador
• ¿Mudarlo a postgres? + ¿postgis?
• Hacer tests
• Documentar el API
• Hacer REST bien
• Montarlo en un server
• Implementar webhooks

Cliente s?

Por fin, con un API decente entonces sí se hace un cliente web que haga uso de ubicación geográfica del usuario para mostrar loas representantes que correspondan y la información detallada de los mismos. Ya de ahí pal real.

---

TODO:

• Separar/eliminar cliente del repo
• Implementar JS SDK
• Evitar que @GobiernoFacil entre a junta un rato
• ???
• PROFIT!!

[ghost]

@unRob, no me quedó muy clara la sección de Abusar de git y Github y el repo agregador;
sería usar GitHub como base de datos para guardar la info scrapeada de los congresos?

Después, con Secretario tomarías estos datos del repo para mostrarlos en un front-end?

---

Un TL;DR de lo que entendí (del roadmap) es tener una API RESTful que cumpla con:

• Obtener representantes por [lat, lng]
• Obtener representantes por id_seccion
• Buscar representantes por nombre
• Obtener representante por slug
• Obtener imagen de representante por id

y que sea fácil de mantenerla actualizada.

¿Me la estoy tripeando?