Introducción​

Voy a ser completamente honesto: cada vez que abro un proyecto nuevo de React para hacer un simple panel interno, algo dentro de mí se apaga un poco. pnpm install, veinte minutos esperando, tres gestores de estado que no necesito, un build pipeline que hay que mantener, y todo para mostrar una tabla con botones de "eliminar". Si estás igual de jodido que yo con esto, quiero contarte de una combinación que me tiene bastante convencido: htmx + Pico CSS (y, si hace falta, un toque de Alpine.js).

No es una tecnología nueva ni mágica. Es, más bien, una negación deliberada de cómo se construye frontend hoy. Y para cierto tipo de proyecto —CRUDs, admin panels, herramientas internas, prototipos— me parece que es objetivamente mejor que meter un SPA completo.

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​

En un mundo donde el software impulsa prácticamente todos los aspectos de nuestra vida —desde aplicaciones móviles hasta sistemas bancarios—, la calidad ya no es opcional. Aquí es donde entran las pruebas de software (software testing): un proceso crítico que asegura que los sistemas funcionen correctamente, sean seguros y cumplan con las expectativas del usuario.

Ignorar las pruebas no solo es un riesgo técnico, sino también un riesgo de negocio.

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.