Primero, un poco de contexto. La madre de mi novia hace algunos años decidió abrir un laboratorio médico. En alguna conversación, debo haber dicho que podría hacer una plataforma para que gestione su laboratorio. En distintos momentos durante muchos años, intenté arrancar el proyecto, en ocasiones solo, en otras con ayuda de un gran amigo, pero nunca me terminaba de animar a completarlo.

Ahora, en qué consistía este sistema. El sistema debe poder llevar todo el ciclo de vida de un laboratorio, desde la admisión del paciente, toma de muestras y entrega de resultados. Suena bastante sencillo a primera impresión, pero la complejidad va aumentando mientras se agregan más módulos a cada etapa, por ejemplo, el módulo de admisión debe permitir registrar pacientes, cotizar órdenes, generar hojas para completar resultados, imprimir órdenes de compra y gestionar referidos (que es algo propio de la industria de laboratorios clínicos en el Perú).

21 Noviembre 2025. Ya he ido usando Claude Code para hacer algunos talleres en clases que voy dictando. Realmente, esta tecnología me permite avanzar muy rápido con casi cualquier cosa, siempre y cuando conozca o esté familiarizado con lo que quiero lograr. Un fin de semana en casa de los padres de mi novia, les digo que voy a avanzar con la plataforma. Comencé 9AM, abrí mi terminal y mi IDE (siempre Pycharm); y manos a la obra. No quise complicarme mucho, decidí usar las herramientas que más conocía: backend con Django, base de datos postgres (dentro de un docker compose) y un Dockerfile para el futuro despliegue a producción. 6 PM: ya estaban listos la gran mayoría de casos de uso del laboratorio, podría decir que ya teníamos un MVP funcional. Quedaban algunos retos importantes aun, que eran cómo se tomaban órdenes y el flujo de entrega de resultados, pero sería tarea para una siguiente semana.

29 de Noviembre del 2025: al medio día ya estaban completos los casos de uso pendientes. Ahora toca algo igual de divertido que programar, que es llevar la aplicación a producción.

Para elegir dónde hostear esta aplicación, me basé en cosas que he querido probar por un buen tiempo. Decidí usar Hetzner porque algunos devs que sigo en twitter hablan de lo barato que puede llegar a ser este servicio. Decidí usar Coolify, porque quería reducir algunas cosas manuales que siempre considero un problema, como pullear nuevos cambios o renovar el SSL de Let's Encrypt.

Decidí usar Tailscale porque quería probar este servicio como VPN para acceder a los servidores sin exponer puertos al internet público. Decidí usar Cloudflare, porque ya lo vengo usando por años y su capa gratuita me da features de seguridad bastante buenos para gestionar cualquier dominio.

Decidí usar Render porque vi que era uno de los servicios gestionados más baratos que encontré - que incluye backups - para bases de datos postgres.

De todas estas tecnologías, la que más me ha sorprendido es Coolify. Es una herramienta bastante sencilla de instalar (Hetzner tiene un template para que ya lo tengas instalado en tu servidor) y puedes montar múltiples proyectos desde la misma plataforma. Se siente un poco como lo que era configurar algo con Heroku en su momento.

8 de Febrero del 2026: El sistema ya tiene un poco más de un mes funcionando y hemos ido lanzando algunas mejoras en este tiempo - y muy rápido el despliegue de las mismas gracias a Coolify. Ya con los datos de un mes, se han podido armar algunos dashboards interesantes en Metabase para tomar algunas decisiones de negocio.

Por mi lado, estoy bastante satisfecho con el trabajo. Me ha permitido reencontrarme con la programación de una forma bastante nueva - usando a Claude - y aprender muchas nuevas tecnologías que tenía pendiente revisar.

A modo de cierre, si han llegado hasta acá, he decidido que el sistema para laboratorios sea Open source, así que para los curiosos, lo pueden ver acá: https://github.com/gustavopp93/libre-lims . Seguiré agregando nuevos features cada cierto tiempo, aún hay mucho por hacer, pero con lo avanzado hay bases sólidas para que el proyecto pueda seguir escalando!

Ahora, por qué leo esto siempre en Navidad. Casi a la mitad de esta historia, en un número titulado Pariah!, Matt Murdock (la identidad secreta de Daredevil) es acuchillado. ¿Pero qué hace de este violento momento que lo lea siempre en Navidad? Pues todo este número transcurre en Nochebuena, se ve en escena a personas cantando villancicos y la persona que lo ha acuchillado anda vestida de Papá Noel!

Ahora, otro punto que se me hace fascinante es un poco el contraste del momento. Navidad es una fecha donde se celebra el nacimiento de Jesús, pero en esta historia, es el momento más bajo de Matt Murdock. Su vida, su reputación, ha sido destruida; está quebrado económicamente, ya no puede ejercer la abogacía y ha sido derrotado físicamente por su enemigo en esta historia. El momento en que Daredevil es acuchillado, es su momento más bajo, luego de eso, solo sigue deambulando por su barrio, Hell’s Kitchen, hasta que es rescatado por una monja.

Todos estos elementos, han hecho que poco a poco, se vuelva uno de mis momentos favoritos de Navidad, porque al final de la historia, Daredevil Vuelve a nacer. No me considero una persona católica (aunque irónicamente Daredevil lo sea), pero me gusta en este momento del año donde se celebra el nacimiento de alguien, poder disfrutar leyendo sobre el renacimiento de alguien.

Segundo, me compré mi primera macbook hace algunos meses, para mi cumpleaños 32. Quería experimentar algo nuevo con este sistema operativo y los cumpleaños siempre son una buena ocasión para esto. En ese momento me di cuenta que también puedo separar mi vida en los sistemas operativos que he ido usando.

Mi primer sistema operativo fue windows (98, 2000, xp y 7). Con windows es donde aprendí a usar una computadora, pasé muchas horas jugando y di mis primeros pasos programando (c++ y java principalmente).

Pero esta relación con Windows se vio interrumpida por un pingüino. Allá por el año 2012 fui “evangelizado“ en Linux. Esto ocurrió mediante un CD donde se encontraba el sistema operativo Ubuntu y una sugerencia donde me sugerían tener un dual boot: Ubuntu para programar y Windows para jugar. Desde ese momento inicié con la sugerencia, hasta que en algún momento decidí eliminar el dual boot y solo quedarme con aquel pingüino.

Esta relación con Ubuntu Linux ha durado más de una década, hasta que tomé la decisión comentada párrafos atrás, la de tener mi primera macbook. ¿Qué impulsó esta decisión?, difícil de saberlo en realidad, puede ser que muchos amigos están muy contentos trabajando con macOS, puede ser que quería probar algo con procesador ARM, o tal vez solo quería darme un gusto. Ahora, hay algunas cosas que nunca hice en mis días con Linux: jamás instalé una nueva terminal (lo intenté un par de veces), siempre utilicé bash (aunque conocía de la existencia de zsh o fish) y principalmente, nunca tuve la necesidad de usar - según yo - vim (siempre usé nano).

Ahora, con un nuevo sistema operativo, me dije, es un buen momento para probar todas estas cosas nuevas, como un nuevo inicio. La pregunta es, ¿Dónde inicio?. Empecé a preguntar a mis amigos qué cosas me sugerían. Algunos me comentaron sobre iterm2 para macOS, otros me decían que solo usaban zsh, mientras otros me decían que usaban fish y por último, un amigo me comentó sobre el mundo de neovim. Todas estas herramientas para mí eran nuevas, así que para investigar un poco más sobre cada una de estas, fui a mi fuente de la (pos)verdad preferida: reddit. Ahí empecé a descubrir todo un mundo de subreddits dedicados a cada uno de estos temas - podría ser Alicia o Neo siguiendo al conejo blanco - pero en mi camino por el agujero de conejo, encontré uno fascinante r/unixporn.

Dentro de este subreddit, los redditors comparten sus configuraciones en sus sistemas operativos (mayoritariamente en distribuciones de Linux, pero igual con presencia de macOS). Mientras me seguía adentrando en este mundo, empecé a descubrir que siempre se referían a esta acción como ricing (que podría describirlo como personalizar tu entorno de trabajo). Otro detalle interesante dentro de este submundo, es que junto a cada post, por lo general estos van a acompañados del enlace a sus dotfiles. Los dotfiles son por lo general un repositorio dentro de GitHub donde se encuentran los archivos de configuración de cada una de las herramientas instaladas. Esto a mi parecer es increíble, la comunidad comparte sus entornos de trabajo - obviamente con cero ánimos de lucro - para que nuevas personas que se involucren en este mundo, puedan también inspirarse en eso e ir mejorando sus propios entornos de trabajo. Algunas cosas que me impactaron de todo este mundo es el énfasis en los themes que se usan, las diversas fuentes o las customizaciones que se hacen a componentes como las barras superiores - que al poder ver los diversos dotfiles he podido adaptar de a pocos en mi propio entorno de trabajo.

Todo este viaje en las diversas herramientas y en los varios dotfiles que he ido viendo, han hecho de estos primeros meses con macOS una verdadera aventura. ¿Volveré a Linux?, posiblemente en un tiempo. He escuchado que ArchLinux con Hyprland están bastante bien últimamente, pero por el momento seguiré con macOS, pues sigo en un proceso de aprendizaje de este nuevo entorno y aún hay algunas cosas que quiero seguir probando antes de dejar este sistema operativo.

Y Antes que me olvide:

• Mis dotfiles: https://github.com/gustavopp93/dotfiles

• Cosas que aún no he podido agregar a mis dotfiles, todo lo relacionado a fish y sus plugins: fisher, tide, fzf ó z

Llevo leyendo cómics desde hace muchos años, pero nunca me gustó mucho la etapa de Stan Lee en Marvel - siempre me pareció algo lento el ritmo de sus historias - hasta que, en una feria, me encontré con un cómic de Silver Surfer escrito por él y con una grandiosa ilustración en la portada (dibujada por el artista francés apodado Moebius). Aquel cómic, titulado “Parábola“ me impactó en su momento y desde ese momento le guardo particular cariño.

Hace algunas semanas, encontré en un kiosko de periódicos el mismo cómic (a solo S/. 9.90 !). Inmediatamente me dije, que debo volver a darle una leída y tener algunos grandes minutos de sano entretenimiento.

Además de la gran historia que se cuenta en este cómic (cuenta con la aparición de Galactus, se tocan temas como el fanatismo religioso y cuenta con buenas escenas de acción), esta edición tiene una buena sección de extras. Aquí nos cuentan un poco sobre el encuentro de Stan Lee y Moebius; y cómo fue el proceso creativo de los dos para este cómic. Lo que me llamó la atención de esto, fue que en un momento se comenta sobre “El método Marvel“, que es la forma de escribir que se tenía en Marvel durante su época clásica (en la cual se crearon a populares personajes como Spiderman, Los 4 Fantásticos o Ironman). El método Marvel consiste en que el guionista (por lo general, Stan Lee) crea un outline de las historias, la cual pasaba al dibujante (por lo general, Steve Ditko o Jack Kirby) para que pueda narrar la historia de forma visual en base al outline compartido. Cómo último paso, el guionista volvía para afinar algunos detalles de las secuencias y completar y/o afinar los diálogos. Esta forma de colaboración es la que permitió que Marvel durante sus años clásicos pueda generar toda su clásica mitología en un corto periodo de tiempo.

El método Marvel y su capacidad para acelerar el trabajo en la industria de los cómics me hace reflexionar mucho sobre los tiempos actuales en el mundo de la programación, donde herramientas como Claude Code, Cursor o Windsurf han generado una acelerada generación de código - no siempre con los mejores resultados a mi parecer - que ha generado un aparente incremento en la productividad de los equipos de desarrollo; pero, ¿Esa aparente productividad nos asegura que lo producido es de buena calidad?. En lugares como twitter o hacker news se ha notado que se han empezado a generar PRs que se podrían considerar como AI slop (código roto o innecesariamente complejo para ciertos casos por ejemplo).

En mi caso, he estado utilizando las herramientas de IA últimamente para entender código sobre el cual no tengo contexto, para generar demos para mis clases o para hacer configuraciones a mi nueva computadora (ricing como se conoce en el mundo de reddit). Pero para realizar todo esto, es imprescindible que entienda lo que quiero realizar, detallando lo que quiero con mucha precisión para poder compartirselo a estas herramientas - alguno diría que podría ser como el outline que Stan Lee le compartía a los dibujantes - con el fin de obtener lo que necesito. A ese outline, las IA me comparten su mejor versión sobre lo que yo les he podido entregar, muchas veces con puntos que yo debo revisar y completas - me gusta pensar que son como los bocadillos de texto de los cómics, donde debo completar el diálogo - para poder dar como concluido lo que les he solicitado.

En esta época, al menos en el mundo de la programación, estamos delegando cada vez más cosas a la IA y en ocasiones no se está revisando lo que nos está entregando - no completamos los bocadillos de texto - , esto en ocasiones puede generar la entrega de código defectuoso o con problemas de seguridad. A mí parecer, si es que queremos usar las IA para alguna tarea en específica, debemos considerarlas como una herramienta sobre la cual nos podemos apoyar en nuestras labores, pero no debe ser más que eso, una herramienta; el trabajo humano aun se encuentra en que debemos compartirles el outline sobre lo que necesitamos y tener que completar esos bocadillos de texto que nos terminan entregando.

Notas del autor:

1. El Método Marvel ocasionó muchas discusiones sobre quién tiene la autoría de muchos de los personajes de Marvel, pero eso es otra historia 🐇🕳️.

2. En este cómic se menciona sobre el método Marvel, pero al parecer no se aplica al 100% para la creación de Parábola, sino que se usa una versión modificada, con más información de la historia por el lado de Stan Lee.

Prólogo

El curso que estoy dictando, tiene como objetivo tocar diversos temas relacionados a la gestión de proyectos sobre Software. Me está gustando mucho ser profesor, pues además de dictar la clase, estoy aprovechando a leer mucho (posiblemente en algún momento escriba sobre los libros que me han servido para este ciclo).

Pero soy humano y, como tal, hay temas que me han entusiasmado más al enseñar. DevOps y observabilidad son de esos. Durante clases, se explicaron los pilares de observabilidad, qué implica DevOps o qué herramientas y/o proveedores nos pueden ayudar con esto. La clase fue amena y hubo consultas de los alumnos; pero con algo que me quedé fue que un alumno me sugirió que deberíamos tener un taller sobre esto. A este comentario, me dije: ¿Por Qué no?. Ya había hecho un taller previamente en clases, pero relacionado a calidad de software (en esa ocasión usando sonarqube). Solo me faltaba definir cómo plantear este taller (porque existen muchos componentes relacionados) y el otro es cómo puedo encontrar tiempo para poder tener algo lo suficientemente decente para presentar en clase.

Capítulo I: Claude

Llevo usando Claude Code de forma recurrente hace algunas semanas. Me gusta que puedo usarlo en la terminal (que es otro interés que he ido teniendo en los últimos meses, pero esa será otra historia 🐇) y tener la pantalla partida entre mi código por un lado y Claude Code en otro. Inmediatamente supe que Claude me ayudaría a poder construir la aplicación que iba a ser monitoreada y todos los demás componentes que formarían parte del taller en clases.

Capítulo II: Qué quería enseñar en clases

Aquí tenía que estructurar bien lo que quería hacer. Ya tenía una aplicación web hecha en Django para el taller anterior de seguridad, así que decidí que repotenciaría este repositorio. Primero, decidí que tenía que asemejarse lo más posible a un ambiente de producción, así que a agregar lo clásico: un Dockerfile para construir la aplicación como una imagen, Nginx para que pueda generar logs de los requests y Gunicorn para conectar Nginx con la aplicación Django. Con esos puntos listos, tocaría lo siguiente: armar un repositorio donde se encontraran Grafana junto con sus fuentes de datos. Aquí habría de definir un poco mejor qué tecnologías tendría que usar como fuentes de datos, así como también que dashboards. Esto me llevo a decidir que las fuentes de datos serían: Prometheus y Loki.

Capítulo III: Yo, Claude

Okey, con todo ya decidido, manos a la obra (con Claude). Primero, toca indicarle qué modificaciones necesitaba dentro del repositorio usando Django: Claude, agrega Nginx y Gunicorn al repositorio. Claude, modifica el Dockerfile para que exponga ya no la aplicación de Django directamente, sino mediante Nginx.

Luego de eso, armar el repositorio donde se encuentre Grafana, Prometheus y Loki. Aquí, tuve que decidir qué dashboards quería utilizar. Felizmente, existe una página dentro de grafana con dashboards habilitados para su descarga. Con estos puntos, a indicarle a Claude que pueda generar el archivo docker compose con los servicios que necesitaba, que pueda configurar los servicios de Prometheus y Loki; y por último, que pueda descargar los dashboards indicados para tenerlos en los repositorios (este punto es vital, para que en clases se pueda examinar de forma visual todo lo aprendido).

Último paso: indicarle a Claude que integre el repositorio con la aplicación Django y lo envie a Prometheus y Loki. Aquí toca decidir donde quiere que se encuentren estos exporters. Me hizo más sentido que estén en la aplicación Django: Claude, agrega prometheus-nginx-exporter y promtail para que exporten datos hacia Prometheus y Loki.

Con los repositorios completos (y obviamente, validando que funcione) ya está todo listo para ser presentado en clases.

Capítulo IV: Claude strikes back

En clases, el taller considero que fue bien, todo funcionó y los alumnos pudieron ver como funciona en sus entornos locales. Hubo algunas dudas muy buenas sobre las tecnologías y cómo se comunican, que sirvieron para explicar múltiples conceptos sobre la arquitectura escogida (particularmente una sobre por qué obtenemos los logs de nginx y no sobre la capa de aplicación). Pero, me quedó algo pendiente: sentía que los gráficos están muy vacíos, no había mucha data. En este punto toca preguntarme, como hago para que pueda haber más data sobre la cual explorar.
Hace un tiempo, un amigo me comentó sobre usar K6 para hacer pruebas de performance en las aplicaciones web y enviar sus resultados a Grafana. Siempre me quedó poder hacer esa implementación, así que decidí que para la siguiente clase, reforzaría el taller con algunos temas más de observabilidad y agregaría data generada mediante pruebas de performance de K6 para que los alumnos pueda explorar los resultados.

Entonces nuevamente: Claude, agrega nuevas fuentes de datos al repositorio de grafana, quiero influxdb y Tempo. Claude, reemplaza promtail por Alloy en el repositorio de Django. Claude, agrega opentelemetry al repositorio de Django y envia esos datos a Alloy. Claude envía los datos de Alloy a Tempo y Loki. Claude, arma un repositorio donde hayan pruebas hacia la aplicación de Django y envia los datos a influxdb.

Con esto estos cambios, se pudo presentar todo en el siguiente taller y se logró un entendimiento algo más amplio de una gran parte de los conceptos de observabilidad. También surgieron algunas dudas, pues en este punto la arquitectura ya es algo más complejo, pero felizmente está siempre la pizarrita para poder explicar todo esto a más detalle.

Epílogo:

Bueno, esto es el fin de esta narración, fue una experiencia muy divertida y muy educativa. Me queda pendiente aun mejorar estos repositorios: me falta agregar algo que pueda ingestar métricas de bases de datos, y ver la forma que las trazas tengan más información; pero todo eso puede ser para una nueva oportunidad. 🚀🚀🚀

Nota de Autor:

1. Las instrucciones a Claude han sido reducidas con fines de esta narración. Han sido algo más complejas las instrucciones 😅

2. Todo lo desarrollado para esta clase tenía un fin más demostrativo para explicar conceptos que para usar en un ambiente de producción. Para ambientes de producción sí hay que revisar mucho más las configuraciones realizadas en las diversas herramientas.

3. Si existe algún interesado, estos son los repositorios:

   1. Aplicación Django: https://github.com/gustavopp93/django-quality-demo

   2. Grafana y sus fuentes de datos: https://github.com/gustavopp93/grafana-demo

   3. Pruebas usando K6: https://github.com/gustavopp93/k6-demo

Subscribe now

Por qué Borges

Hace algunos meses empecé a dictar clases en una universidad (Gestión en Software es el curso) y en una clase, de la nada, se me ocurrió, por alguna razón, hacer una referencia al cuento “Las 3 versiones de Judas“, de Borges. Desde ese día, como si fuera el Zahir, la idea de conectar a Borges con las clases que estoy dictando empezó a dar vueltas por mi cabeza.

Anthropic

Hace poco, me crucé en la internet con eso: A small number of samples can poison LLMs of any size. Al leerlo, me quedé con una idea importante:

[…] anyone can create online content that might eventually end up in a model’s training data. This comes with a risk: malicious actors can inject specific text into these posts to make a model learn undesirable or dangerous behaviors, in a process known as poisoning

Esto es interesante porque, presuntamente, los LLMs están siendo entrenados con información pública de diversas fuentes como github o reddit. Lo interesante de estas fuentes, es que el contenido gana reputación en base a estrellas o upvotes que son entregados por la misma comunidad. En ese sentido, un repositorio de github o algún post en reddit empiezan a ganar más notoriedad o reputación si es que son apoyados por su comunidad, pues en teoría, estas mismas comunidades se automoderan.

Otra idea interesante del mismo artículo es la siguiente:

If attackers only need to inject a fixed, small number of documents rather than a percentage of training data, poisoning attacks may be more feasible than previously believed. Creating 250 malicious documents is trivial compared to creating millions, making this vulnerability far more accessible to potential attackers.

Esto nos da entender que no es necesario crear cantidades enormes de contenido en github o reddit por ejemplo, si es que queremos envenenar a los LLMs, sino que solo bastaría un pequeño número de documentos (Anthropic dixit) para poder impactar de forma negativa a los LLMs.

Tlön, Uqbar, Orbis Tertius

En este cuento de Borges, la trama gira entorno a una referencia que en una conversación se hace sobre un lugar llamado Uqbar. Esta mención, los hace ir a un hoyo de conejo sobre esto: encuentran una versión de una reconocida enciclopedia con algunas hojas sobre este lugar, luego encuentran un tomo completo sobre la misma enciclopedia y al final la colección completa. Lo llamativo de este cuento es que Uqbar no existe, es todo una conspiración de un grupo de personas que tenían la idea de crear este mundo fantástico extraordinariamente coherente, durante muchas décadas, con la idea que pueda ser considera real.

El zahir

Para mí, al momento de relacionar estas dos ideas, el artículo de Anthropic y el cuento de Borges, empezó a rondar por mi cabeza, que ocurría si un grupo de personas, con la suficiente dedicación, empezaran a crear conocimiento coherente, pero a su vez, esto no sea real. ¿Los LLMs los tomarían como ciertos? ¿Y las personas que los usan, también los estarían tomando como ciertos?

Estas ideas, me llevan a pensar qué es lo que consideramos como real. Muchas veces consideramos real como algo que está escrito en libros y tiene una gran reputación. Pero en esta época, la reputación se construye en base a likes o estrellas. Claro, para nosotros, las personas, con la suficiente dedicación, es posible que podamos darnos cuenta que algo es falso o imaginario, pero qué pasa con los LLMs que están siendo entrenados con el contenido disponible en la internet, ¿Estarían considerando todo como real? ¿Y si en algún momento, las personas empezaramos a confiar ciegamente en lo que nos dicen los LLMs? ¿Eso querría decir que, como el cuento de Borges, con suficiente dedicación y coherencia, podríamos terminar reescribiendo la realidad?

Bueno, esto ha sido todo. Es mi primer post en la vida y no se me ocurrió otra forma con qué cerrar.