El harness vino para quedarse: data viz, nginx y mis dos pasiones
Hace unos meses habría dicho que la IA era un truco. Hoy digo algo distinto: el harness llegó para quedarse — ese ecosistema de herramientas de IA que nos asiste mientras codeamos, que revisa nuestro código, que renderiza lo que imaginamos y que nos obliga a ser mejores arquitectos, no peores programadores.
Este post es un poco distinto a un tutorial. Es una foto de dónde estoy parado ahora mismo: un proyecto nuevo que me tiene emocionado, un montón de aprendizaje técnico en el camino, y una teoría personal sobre cómo el arte y la tecnología terminan siempre encontrándose.
El proyecto: data viz deportiva en 2.5D
Llevo semanas trabajando en un proyecto de visualización de datos deportivos que consume APIs grandes de datos en tiempo real. La idea: tomar métricas en vivo de deportes, procesarlas, y representarlas de una forma que no sea otro dashboard plano más.
Y aquí es donde entra mi parte favorita. Propuse implementar 3D para hacer una visualización 2.5D: profundidad visual, perspectiva, una escena que se siente viva — pero manteniendo siempre el estado reactivo de la data. No es un render estático bonito; es una escena que respira con los datos.
La decisión 2.5D sobre 3D completo fue deliberada:
// El truco del 2.5D: perspectiva real, pero interacción en 2D
// para que la data siga siendo reactiva y accesible
const config = {
depth: true, // profundidad visual
fullOrbit: false, // sin órbita completa — UX más predecible
reactive: true, // cada update de data muta la escena
frustum: 0.1, // menos objetos visibles = mejor performance
}
Aprendí que no todo necesita ser VR. A veces la mejor decisión técnica es la que limita: el 2.5D te da el wow del 3D sin sacrificar la legibilidad de los datos — que al final es lo único que importa en una visualización.
Lo que aprendí de verdad: nginx y el viaje de una petición
Este proyecto me obligó a salir del frontend y entender qué pasa entre el navegador y mi API. Ahí conocí a mi nuevo mejor amigo: nginx como reverse proxy.
Entender cómo viaja una petición cambió mi forma de debuggear todo:
Cliente
│ 1. DNS: resuelve api.midominio.dev → IP
│ 2. TCP handshake (SYN, SYN-ACK, ACK)
│ 3. TLS handshake (si es HTTPS)
▼
nginx (reverse proxy, puerto 443)
│ 4. ¿Qué server block? (Server Name Indication)
│ 5. Termina SSL, decide el upstream
│ 6. Reenvía con proxy_pass
▼
Upstream (Node/API)
│ 7. Procesa, responde
▼
Cliente (con headers + cookies + cache)
Y el config que hace todo eso:
server {
listen 443 ssl;
server_name api.midominio.dev;
ssl_certificate /etc/letsencrypt/live/api.midominio.dev/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/api.midominio.dev/privkey.pem;
location / {
proxy_pass http://localhost:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Tres lecciones que me llevo:
- HTTPS no es magia: es un handshake TLS negociando cifrado antes de que viaje un solo byte de tu data.
- El reverse proxy es tu portero: autentica, balancea, cachea y protege tu upstream del mundo.
- Los headers hablan:
X-Forwarded-Forte dice de dónde viene realmente la petición — porque detrás de un proxy,REMOTE_ADDRya no es el cliente.
El porqué de los mantras (y si funcionan)
Un mantra no es magia: es un filtro de atención. Tu cerebro tiene un sistema que destaca lo que le declaras importante — si repites "quiero hacer data viz", empiezas a ver data viz por todos lados: APIs, demos, artículos que antes ignorabas. El mantra no atrae cosas: le dice a tu cerebro qué buscar.
Por eso un guru funciona: no te da el conocimiento, te da el mapa. Te ahorra años de explorar terreno equivocado. Pero ojo — el guru te acorta el camino, no camina por ti.
¿Y funcionan los puntos de visión propios? Sí, con una condición: tienen que ser visibles y dividibles. "Ser full-stack" no es un objetivo, es una dirección. "CCNA para fin de año" es un objetivo. El punto de visión solo funciona si cada mañana sabes cuál es el siguiente paso — el mantra te da el porqué, el plan te da el cómo.
Un mentor (o un guru) lo cambia todo
En este proyecto empecé a tener un mentor. Y el cambio no fue en código — fue en criterio. Las decisiones de las que estoy orgulloso (el 2.5D, la elección de stack, cuándo no optimizar) vinieron de conversaciones, no de tutoriales.
Un guru no es quien te da respuestas; es quien te da las preguntas correctas.
Arte + tecnología: mi única fórmula
He pasado años tratando de explicar por qué me gusta lo que hago. Al final lo resumí en una frase: siempre intento mezclar mis dos pasiones — el arte y la tecnología.
El arte me da el criterio visual: qué se ve bien, qué comunica, qué emociona. La tecnología me da el cómo: cómo renderizarlo, cómo hacerlo reactivo, cómo hacerlo rápido. Este proyecto de data viz es eso en su forma más pura — deportes (pasión), datos (tecnología) y una escena 3D (arte).
La gente cree que son mundos opuestos. Yo creo que el arte sin tecnología es una idea, y la tecnología sin arte es una función. Juntas, son un producto.
Dónde estoy parado ahora
Para que este blog sea honesto, el estado actual de mi camino:
- 🎯 CCNA en camino — quiero entender redes a fondo: que el viaje de una petición deje de ser magia y se vuelva protocolo
- 💻 Avanzando en front y backend web — nginx fue mi primer paso del lado servidor; el objetivo es manejar el stack completo
- 🦀 Rust, más adelante — el viaje al bajo nivel cuando el momento llegue: el siguiente punto de visión en el mapa
- ✨ Buscando nueva inspiración — cada demo nueva que veo me recuerda cuánto falta por aprender
- ✍️ Manteniendo el hábito de escribir — este blog existe exactamente por eso
Lo que estoy leyendo
Esta semana leí un artículo que me tocó directo: What I learned building an opinionated and minimal coding agent, de Mario Zechner. Construyó su propio harness de agente de código por pura frustración con los existentes: demasido features que no usa, contexto que se inyecta a escondidas, y APIs que huelen a evolución orgánica.
Su filosofía es minimalismo puro: herramienta mínima, sin plan mode, sin to-dos, YOLO por defecto. Y la idea que más me quedó grabada: el context engineering importa más que la cantidad de features — controlar exactamente qué entra al modelo produce mejores resultados que cualquier feature nueva.
También sigo de cerca a Maxime Heckel, cuyo talk en Figma Config 2025 vi y me recordó por qué empecé todo esto: shaders y 3D en tiempo real en la web como pasión, no como feature. Su blog es la prueba viva de que se puede mezclar arte y tecnología y vivir de ello.
El cierre
El harness no viene a reemplazarte. Viene a subir el piso: ahora todos pueden escribir código, pero no todos pueden decidir qué construir. Eso sigue siendo humano.
Este proyecto me está enseñando que el conocimiento se acumula raro: aprendes nginx por culpa de una API deportiva, aprendes HTTP porque querías que tu dashboard fuera rápido, y de repente eres más dev de lo que eras hace seis meses — sin darte cuenta.
Escribir en público me obliga a ordenar todo esto. Gracias por leer hasta acá.
Próximo post: el tutorial completo de la visualización 2.5D — cómo mantengo el estado reactivo de la data dentro de una escena Three.js sin sacrificar rendimiento.