Introducción​

Quizá suene un poco nostálgico, pero todavía recuerdo el primer programa que resolví solo, sin copiar nada, sin preguntarle a nadie. Era una tontería, un bucle que imprimía números pares, pero la sensación de haberlo armado con mi propia cabeza fue de las cosas que más me engancharon a programar. Ese subidón hace tiempo que no lo siento.

Lo que pasa después de un tiempo trabajando en esto es que el código deja de ser un juego. Se vuelve una herramienta, una obligación, algo que resuelves porque hay que entregarlo, no porque te divierte. Y programar solo, sin nadie del otro lado, sin nada en juego más que tu propio tiempo, termina sintiéndose distinto a cuando había alguien con quien compararte o competir.

Así que hice algo al respecto: cada semana publico un reto de programación en la Cueva. Nada del otro mundo, nada de estructuras de datos complicadas a las tres de la mañana. Problemas del tamaño justo para recuperar esa sensación de la primera vez, con la diferencia de que ahora hay un leaderboard real esperando del otro lado, así que ya no soy solo yo hablándole a mi propio editor de texto.

Introducción​

Seguramente ya te ha pasado. Corres un pnpm install, todo funciona bien, te vas a dormir tranquilo, y al día siguiente el build está roto sin que tú hayas tocado ni una sola línea de código. Vas a investigar y resulta que una dependencia se actualizó sola de la 2.4.1 a la 3.0.0 y decidió, sin avisarte con la debida cortesía, cambiar por completo su API.

Ahí es cuando uno se pregunta: ¿para qué existen los números de versión si de todos modos nos rompen el proyecto? Pues resulta que sí existe una respuesta, y es que ese numerito no se escribe al azar, tiene un nombre y unas reglas bien definidas que la mayoría ignoramos hasta que nos pega en la cara. Se llama Semantic Versioning, o como le decimos de cariño, SemVer.

Introducción​

Instalé Hermes Agent en mi servidor para vigilar dependencias desactualizadas en mis PRs de GitHub sin tener que estar pendiente: usuario dedicado sin sudo, systemd hardened, toolset recortado a 9 herramientas de solo lectura, cron cada 5 minutos en vez de webhook público. Lo que no preví fue cuánto me iba a costar correrlo sin supervisión.

Introducción​

Todos conocemos el patrón: el proyecto arranca con un README cuidado, tal vez un par de diagramas, quizás hasta una wiki. Pasan tres sprints, el código cambió por completo, y esa documentación sigue hablando de una arquitectura que ya no existe. Nadie la borra porque "algún día la actualizamos", y nadie la actualiza porque siempre hay algo más urgente. La documentación no muere, simplemente se vuelve mentirosa. Y el equipo de LangChain decidió atacar ese problema con OpenWiki, una CLI que le da a un agente la responsabilidad de escribir y mantener la documentación de tu repositorio.

Introducción​

En un post anterior les conté cómo convertí una HP Pavilion vieja en mi servidor personal, con Docker, Cloudflare Tunnel y un montón de servicios self-hosted corriendo ahí. Hoy les cuento la otra cara de esa historia: qué pasa cuando uno de esos servicios queda expuesto al mundo sin la protección que debería tener, y alguien (o algo, un script automatizado) lo encuentra antes que uno.

Spoiler: terminé con un contenedor de Gitea minando criptomonedas para otra persona, 4743 cuentas de spam, y un fin de semana entero limpiando el desastre. Este post es la bitácora completa del incidente, cómo lo detecté, cómo lo contuve, y lo que armé después para que la próxima vez me entere en minutos y no por accidente.