4 cosas que existen porque alguien las pidió
Hecho a pedido
Buena parte de lo que este sitio hace no salió de una hoja de ruta: salió de un correo, de un issue en GitHub o de una pregunta que alguien hizo en público y que acá no estaba contestada. Esta página lista esos casos, con qué se pidió, qué se hizo y qué se aprendió haciéndolo.
Lo que no vas a encontrar es quién lo pidió. Un nombre o una casilla son datos personales y nadie los entrega esperando figurar en una página web.
Cómo llega un pedido, y qué se publica de él
Tres puertas, y cada una cambia qué se puede contar después.
Alguien escribió pidiendo algo concreto. Publicamos el pedido, nunca quién lo hizo.
Reportado en el repositorio público. El issue queda enlazado para que se pueda leer entero.
Nadie escribió: la pregunta estaba hecha en un foro y el sitio no la contestaba.
Lo que se construyó
Cotizaciones de toda la región, con API y series históricas
Qué se pidió
Un equipo de estudiantes de la Universidad Tecnológica (UTEC) amplió el alcance de su proyecto académico a las cotizaciones de la región y preguntó si existía algún endpoint que contemplara divisas regionales. No existía: la API era uruguaya.
Qué se hizo
Quince fuentes públicas nuevas —cuatro de ellas bancos centrales— para Argentina, Brasil, Paraguay, Chile y Bolivia, unidas al tablero uruguayo propio. Seis endpoints (tablero, series diarias, inventario de series, comparación de rutas, conversión y catálogo de fuentes), tres páginas y series que arrancan en 2011 para los dólares argentinos y en 1995 para el fixing brasileño.
Lo no obvio
"El dólar" de un país no es un número: Argentina publica siete precios simultáneos y Brasil tiene un fixing legal más un precio de mostrador que difiere un 6,5 %. Por eso cada cotización dice de qué tipo es. La sorpresa fue la fuente de respaldo internacional: el mismo día que salió, estaba 39 % equivocada en el boliviano y 12 % en el peso uruguayo mientras acertaba el peso argentino. Ahora una referencia internacional que contradice al banco central del país queda afuera, y el motivo se publica.
Cotización y variación dentro del día
Qué se pidió
Un estudiante de UTEC pidió poder consultar, además de la cotización del día, cuánto se movió dentro del mismo día.
Qué se hizo
`GET /intraday` devuelve, para un día calendario de Montevideo, la apertura, el último valor, el máximo, el mínimo y la lista completa de cambios reales de cada casa de cambio, más una página que documenta el contrato.
Lo no obvio
La fila diaria de la base guarda el CIERRE, no la apertura: se sobrescribe en cada sincronización. Así que la apertura hay que reconstruirla del registro de cambios, y la respuesta trae un campo que dice por cuál de los cuatro caminos posibles se reconstruyó. Un endpoint que devolviera "apertura" sin decir eso estaría inventando precisión.
Guías escritas a partir de lo que la gente pregunta en público
Qué se pidió
Nadie escribió un correo: las preguntas ya estaban hechas en foros uruguayos —sueldos, alquileres, herencias, deudas, reclamos— y el sitio no las contestaba.
Qué se hizo
71 guías publicadas a partir de esas preguntas, cada una con la norma o la fuente primaria al lado, más el mecanismo que las detecta: cuando varias personas tropiezan con el mismo faltante en la misma página, eso se investiga.
Lo no obvio
La trampa recurrente fue copiar listas que circulan por internet y son de otro país. Al escribir sobre estudios de cobranza no apareció ninguna norma uruguaya que limite la frecuencia de los llamados: se publicó la ausencia en vez de importar la regla argentina. Publicar "esto no está escrito en ningún lado" es información; inventar el límite habría sido cómodo y falso.
Una casa rota dejaba al sitio con una sola cotización
Qué se pidió
Un reporte en el repositorio mostró que la portada listaba una única casa de cambio, y llegó con el diagnóstico hecho: el parseo de una casa cortaba la sincronización de todas las demás.
Qué se hizo
Hoy cada casa corre aislada: su propio try/catch, su propio tiempo máximo y un presupuesto total para la corrida. Si una falla, las otras 45 siguen, y el resultado por casa queda registrado y publicado.
Lo no obvio
Lo que arregló el problema no fue el parser de esa casa: fue dejar de tratar 46 scrapers como un solo proceso que se cae junto. Y la segunda mitad importa igual — una corrida que cubre la mitad de las casas es indistinguible de una sana si nadie cuenta cuántas respondieron, así que el estado por casa se publica en una página.
Qué no vas a leer acá
De cada pedido se publica el contenido funcional y nada más. No hay nombres, ni direcciones de correo —ni completas ni ofuscadas—, ni capturas, ni citas textuales del mensaje, ni institución, curso o cátedra cuando el pedido llegó por privado. Tampoco en el repositorio ni en el historial de commits.
Una casilla de correo es un dato personal en los términos del artículo 4 literal D de la Ley Nº 18.331, y publicarla sería una comunicación de datos que el artículo 17 sólo admite con consentimiento previo del titular. Ese consentimiento no existe: nadie escribe una consulta técnica esperando aparecer en una página web.
Un issue de GitHub es distinto: es público desde que se abre, así que se enlaza el issue para que cualquiera lo lea entero. El razonamiento completo, con los artículos, está en la página del endpoint intradía.
Qué tiene sentido pedir
Sin promesas de plazo: esto lo mantiene una persona. Pero estas cosas suelen salir, y estas otras no van a salir nunca.
- Un dato que ya publica una fuente pública y acá no está: una moneda, un país, un indicador.
- Un campo o un filtro nuevo en la API, si se puede calcular con lo que ya se guarda.
- Un formato distinto de algo que ya existe, para poder integrarlo.
- Una página que conteste una pregunta concreta que hoy no tiene respuesta clara en ningún lado.
- Un error: un precio raro, una casa que falta, una cuenta que no cierra.
- Datos personales de nadie, ni de clientes de casas de cambio ni de quien escribe.
- Cifras que ninguna fuente publica. Si no está escrito en ningún lado, se dice que no está.
- Recomendaciones de inversión, o "decime cuándo comprar dólares".
- Sacar o maquillar el precio de una casa porque no le gusta cómo quedó en la comparación.
- Acceso privilegiado o exclusivo a los datos: la API es pública para todos o para nadie.
Preguntas frecuentes
- ¿Cómo pido algo?
- Por la página de contacto o abriendo un issue en el repositorio de GitHub. El issue es público y no expone tu correo; si escribís por mail, tu dirección no se publica en ningún lado. Cuanto más concreto el pedido —qué dato, para qué, en qué formato— más rápido se puede evaluar.
- ¿Cuánto tarda?
- No hay plazo comprometido: el sitio lo mantiene una persona. En los casos de esta lista, dos salieron el mismo día o al día siguiente porque los datos ya estaban del lado de acá y sólo faltaba exponerlos; un reporte de scraping tardó bastante más. Si algo requiere una fuente nueva, el tiempo lo define esa fuente, no las ganas.
- ¿Cuesta algo? ¿Hay que registrarse?
- No. Todo lo que sale de un pedido queda público y gratis para cualquiera, sin clave ni registro. No existe una versión "premium" ni un acceso reservado a quien pidió: si se construye, se construye para todos.
- Estoy haciendo un trabajo académico, ¿puedo usar los datos?
- Sí, y varios de los casos de esta lista salieron justamente de proyectos académicos. Lo único que pedimos es que cites la fuente primaria de cada dato: la API devuelve la URL original de cada cotización precisamente para eso. Si necesitás un volumen alto o una descarga masiva, escribí antes: es más fácil pasarte los datos de otra forma que aguantar el tráfico.
- ¿Por qué publicar esta lista?
- Por dos razones. La primera es que muestra que pedir sirve, que es lo que hace que alguien se tome el trabajo de escribir. La segunda es que cada caso deja algo aprendido —una trampa de los datos, un supuesto que era falso— y eso es más útil compartido que guardado en un commit.
Pedí lo tuyo
Si te falta un dato, una moneda, un país, un campo en la API o una página que conteste algo que nadie contesta, escribí. La mitad de esta lista empezó exactamente así.