Cristian Amigo

Aplicación web para gestionar estudiantes, cursos y evaluaciones. Separa controlador, servicio y repositorio; distingue dos roles con permisos distintos y expone una API REST para integrarse con otros sistemas.

Al cerrarlo encontré que la API redirigía al formulario de login en vez de responder 401: un programa que la consumiera no podía distinguir un rechazo de una respuesta válida. Corregido y verificado con 35 comprobaciones sobre la aplicación corriendo. Al cierre del módulo el proyecto quedó con 43 pruebas automáticas y 64 comprobaciones, en H2 y en MariaDB, más JWT en la API, reportes con JdbcTemplate e integración con RestTemplate.

Código y documentación →

Freno de despacho para comercio electrónico: ningún pedido sale mientras tenga una gestión abierta. Reúne WhatsApp, Instagram y correo en una bandeja, y cada tipo de ticket decide por sí mismo si bloquea el envío.

Salió de un problema real que viví como cliente: avisé un error de dirección en menos de una hora y el paquete salió igual, porque el mensaje y el sistema de despacho no se cruzaban. No era una falla técnica — nadie preguntaba si había un ticket abierto. CERBERO es esa pregunta convertida en código.

Dos de las cinco pruebas son controles negativos: comprueban que el freno no actúa cuando no corresponde. Un freno que retiene de más es tan inútil como uno que no retiene.

Código y pruebas →

Aplicación web de préstamos de libros construida con Java EE puro, sin framework: servlets como controladores, JSP como vistas, capa DAO sobre JDBC y sesión propia para el control de acceso. Se empaqueta como WAR y se despliega en Tomcat.

Es el proyecto donde entendí qué hace Spring por debajo. También donde aprendí a revisar el bytecode del WAR antes de entregarlo: compilado con la versión de Java equivocada, la aplicación devolvía error 500 en un servidor distinto del mío.

Código y capturas →

Agente de consola que revisa un equipo y diagnostica riesgos de datos antes de que se pierdan: bases sin respaldo, datos personales expuestos, credenciales en texto plano y disco lleno. Seis detectores distintos detrás de una misma interfaz.

Sólo lee metadatos —nombres, tamaños, tipos— y nunca copia ni envía el contenido. Esa restricción se decidió antes de escribir el primer detector, porque una herramienta que revisa datos ajenos tiene que poder explicar qué no hace.

La prueba que importa es la del round-trip: empaquetar y descomprimir una carpeta y comprobar que los datos vuelven byte a byte. En una herramienta de respaldos, demostrar que se restaura es parte del producto. El checksum se valida además contra un SHA-256 calculado por fuera, como control positivo: sin eso, una implementación consistentemente equivocada pasaría igual.

Código →

Gestor de tareas por consola con jerarquía de clases —tareas normales y urgentes que se comportan distinto tras la misma interfaz—, persistencia mediante DAO y pruebas unitarias con informe de cobertura.

El proyecto donde el polimorfismo dejó de ser un concepto de manual: agregar un tipo nuevo de tarea no obligó a tocar el gestor, que era exactamente lo que la teoría prometía y yo no había visto pasar.

Código y pruebas →

Plataforma de cursos en línea, desplegada y en uso. Dieciséis unidades, sesenta y ocho lecciones y doscientas noventa y una tarjetas de estudio, con registro de avance por persona detrás de autenticación.

Es el proyecto donde más aprendí sobre lo que pasa después de programar: desplegar, migrar la base y darse cuenta de que la primera visita del día tarda dieciséis segundos porque el servidor estaba dormido.

Aplicación en vivo → Presentación → Código →

Treinta y una rutas REST sobre nueve entidades, con autorización por rol probada de punta a punta: un usuario común recibe 403 en las rutas de administración y el administrador las lee. Veintidós pruebas en verde.

Es el único que usa una persona que no soy yo, y eso cambió el trabajo: los errores que importan no son los que rompen la aplicación, sino los mensajes que no se entienden.

Para probarlo: correo demo@portafolio.cl · clave DemoPanel2026 — cuenta de demostración con una cartera ficticia. Cada usuario ve sólo sus propios datos, así que esta cuenta no alcanza ninguna cartera real. El servidor es gratuito y se suspende por inactividad: la primera carga puede tardar cerca de un minuto.

Aplicación en vivo → Código privado

Asistente omnicanal que corre solo: clasifica y archiva correo, arma un resumen diario, responde por Telegram citando la documentación del servicio, registra oportunidades comerciales y agenda reuniones en el calendario. Cuatro tareas programadas lo mantienen vivo sin que nadie abra una sesión.

Es el sistema con más pruebas que escribí: 213, sobre integraciones que fallan de verdad —una casilla que no responde, una API que corta, un archivo a medio escribir—. Varias existen para fijar lo que el sistema no debe hacer: hay una que impide que el clasificador reciba el cuerpo del correo.

Al revisarlo para este portafolio encontré que cuatro pruebas habían dejado de pasar sin que nadie tocara el código: fijaban fechas de julio contra una ventana móvil de catorce días, y se pudrieron solas al llegar agosto. No era un fallo del producto, era el reloj. Corregidas.

Código privado — lee correo personal

Colector de acontecer mundial sin claves de API: reúne titulares de medios internacionales, los agrupa por historia y los ordena por cuántos medios distintos cubren lo mismo.

Lo que más me interesó resolver: un barrido a medias no puede parecerse a uno completo. Si tres de nueve fuentes no responden, el informe lo dice en la primera línea. Cero noticias porque no pasó nada y cero porque se cayó la red se ven igual en casi cualquier colector.

El criterio de corroboración lo corregí después de correrlo contra fuentes reales: la historia mejor rankeada decía «2 medios: BBC Business, BBC Tech» — un solo diario en dos secciones. Estaba inflando justo la señal que dice medir.

Código y pruebas →

Servicio que intercala una aprobación humana antes de que un proceso automático ejecute una acción sensible. Doce rutas documentadas y un control de duplicados para que reintentar una petición no la ejecute dos veces.

La idea salió de un problema concreto: si el cliente reintenta porque se cortó la red, el servidor no puede saber si es una acción nueva o la misma de antes. La respuesta fue que el cliente nombre cada operación.

Presentación → Documentación viva de la API → Cliente →

Interfaz de una billetera digital, adaptada a móvil, tablet y escritorio, con su modelo de datos relacional documentado en un repositorio aparte: diagrama entidad-relación, script de creación y consultas de ejemplo.

Fue lo primero que publiqué. Lo dejo tal como quedó: sirve para ver de dónde salí, y porque un portafolio que sólo muestra lo último no muestra el recorrido.

Ver la interfaz → Código → Modelo de datos →

Un usuario reportó que el disparador de sistema de archivos no ejecutaba nada. La causa resultó estar en la documentación: el ejemplo de configuración indicaba el nombre del paquete, mientras el motor compara contra el nombre completo de la clase. Seguir el ejemplo al pie de la letra equivale a no configurar nada.

Reproduje el fallo en una instancia local, descarté cinco causas candidatas midiendo —no opinando—, usé un disparador de control para probar que el planificador seguía vivo, y ubiqué la causa desensamblando el bytecode del motor de plugins. El cambio final es de una línea. El trabajo fue llegar a ella.

El cambio, ya integrado → El análisis completo →

La guía oficial para migrar a la versión 2 enseñaba a comparar una fecha contra un texto. Dentro de esa condición la fecha no es texto, así que la comparación no se puede resolver: quien seguía la guía no obtenía un flujo que se saltea las ejecuciones, sino uno que falla en cada ejecución programada. Kestra acepta el flujo al guardarlo, de modo que nada avisa hasta que corre.

Lo medí sobre un Kestra 2.0.2 local durante 24 ejecuciones, con un flujo de control en paralelo para demostrar que el planificador estaba sano: el de la guía falló las 24 veces y el de control pasó las 24. La corrección convierte ambos lados a instante antes de compararlos, en vez de ordenarlos como cadenas de texto —que para fechas con distinto huso horario da el resultado opuesto.

El cambio, ya integrado → El fallo reportado →

Volviendo sobre la misma página para responderle a un mantenedor, encontré que la tabla de variables disponibles anunciaba una que no existe en ese contexto. Quien la usaba quedaba en un callejón sin salida, a dos párrafos de la expresión que acababa de corregirse.

Es un cambio de una palabra y no tiene mérito técnico: lo dejo acá porque muestra algo que sí lo tiene, y es volver a mirar una página que uno ya dio por corregida. El error original y este vivían en el mismo archivo.

El cambio, ya integrado →

La herramienta oficial que convierte los flujos de la versión 1 a la 2 generaba, para las condiciones de rango de fechas, la misma comparación que había corregido en la guía: una fecha contra un texto. Todo flujo migrado con ella fallaba en cada ejecución programada, y Kestra lo aceptaba al guardarlo sin advertir nada.

Fue mi primera contribución de código y no de documentación: cambia lo que la herramienta genera para que ambos lados se comparen como instantes, trata aparte los límites que traen sólo una hora del día y agrega las pruebas que lo demuestran. Medido sobre un Kestra 2.0.2 local: la salida anterior fallaba en cada ejecución; la nueva se ejecuta cuando la fecha cae dentro del rango y no se dispara cuando cae fuera. Un segundo cambio corrige dos expresiones del mismo tipo en su documentación. A partir del reporte, el mantenedor agregó a Kestra la función isDateBetween (versión 2.0.4), la sintaxis más simple que habíamos discutido.

El cambio de código, ya integrado → La corrección de su documentación → La conversación con el mantenedor →

El plugin que descifra archivos PGP nunca comprobaba el sello de integridad del mensaje. Si alguien alteraba el archivo cifrado en el camino, Kestra lo descifraba igual y daba la tarea por exitosa. Lo demostré con una factura: cambiando un solo bit del archivo cifrado, sin la clave, "Pay 100 USD" pasaba a "Pay 900 USD".

Es mi primera contribución de código en Java a un proyecto ajeno. El cambio verifica el sello en los dos formatos del estándar (MDC y AEAD), rechaza los mensajes antiguos que no lo tienen y distingue una alteración de un problema de clave. Las pruebas nuevas fallan sin el arreglo y pasan con él. Lo probé en un Kestra 1.3.39 antes y después, con mensajes reales de GnuPG: ninguna de 961 alteraciones produjo una salida corrupta. El mantenedor revisó el código, pidió cinco ajustes, repitió la prueba por su cuenta (11 de 11 escenarios) y lo integró.

El cambio, ya integrado → El reporte →

El mismo plugin de descifrado PGP solo probaba la primera clave de destinatario del mensaje. Cuando un archivo se cifra para varios destinatarios y el tuyo no es el primero de la lista, Kestra fallaba con "No private key found" aunque tuvieras la clave correcta.

Segunda contribución de código al mismo plugin. El cambio recorre todos los destinatarios del mensaje hasta encontrar una clave privada que coincida, en vez de mirar solo el primero. Las pruebas nuevas —un mensaje cifrado para dos destinatarios, descifrado con la clave del segundo— fallan sin el arreglo y pasan con él. Verificado antes y después en un Kestra 1.3.39 local.

El cambio, ya integrado → El reporte →

La tarea que envía eventos a Sentry tomaba el DSN —la cadena de conexión— y lo reenviaba tal cual, fallando con "deprecated userinfo component" en las versiones nuevas de Sentry. Tampoco servía para instancias self-hosted ni para DSN que llevan un prefijo de ruta.

El cambio parsea el DSN en sus partes —clave secreta, host, prefijo de ruta— y arma la petición correctamente, en lugar de mandar la cadena cruda. Las pruebas nuevas fallan sin el arreglo y pasan con él. El mantenedor lo revisó en tres rondas y lo re-probó por su cuenta contra una instancia self-hosted de Sentry antes de integrarlo.

El cambio, ya integrado → El reporte →

La tarea DatabricksSQLCLI ignoraba dos de sus propias opciones: no cargaba los namespaceFiles que el comando necesita y no usaba el containerImage configurado, corriendo siempre con la imagen por defecto.

El cambio hace que la tarea use de verdad las dos: monta los archivos del namespace y respeta la imagen declarada. Con las pruebas que lo verifican y el control antes y después.

El cambio, ya integrado → El reporte →

Las tareas FileTransform documentan rows como la forma de emitir varias filas de salida por cada fila de entrada, pero no funcionaba en ninguno de los tres lenguajes: en Python la tarea fallaba con "No serializer found", y en JavaScript y Ruby rows se ignoraba en silencio y se escribía la fila original.

Había dos causas en el mismo método: rows se buscaba en el valor devuelto por el script en lugar de en los bindings, donde se lee row, y sus elementos se emitían sin convertir. El cambio lo lee de los bindings, convierte cada elemento, lo reinicia antes de cada fila para que no se repita en las siguientes, descarta la fila si la lista viene vacía y falla con un mensaje claro si no es una lista. Las pruebas nuevas de los tres lenguajes fallan en main y pasan con el cambio. Lo verifiqué de punta a punta en un Kestra 2.0.2, antes y después.

El cambio, ya integrado → El reporte →

Bancos, procesadores de pago y proveedores de nómina suelen dejar archivos cifrados y firmados con PGP en un servidor SFTP. Este blueprint vigila la bandeja de entrada y acepta un archivo solo si se descifra con tu clave, pasa su verificación de integridad, lleva la firma de la clave y el usuario del socio configurados, y su contenido no se había aceptado antes. Todo lo demás va a cuarentena con su motivo.

Es un flujo nuevo, escrito para Kestra Hacktober, que usa un disparador por evento de SFTP y complementa un blueprint existente de verificación PGP. Lo probé en un Kestra 2.0.5 con un servidor SFTP real y mensajes de GnuPG: archivos válidos, sin firma, firmados por otra clave, con un bit alterado y reenvíos del mismo contenido con otro nombre. Cada caso terminó en el resultado esperado. Documenta también lo que la firma no prueba. Lo revisó y aprobó un miembro del equipo de Kestra.

El cambio, ya integrado →

Las tareas Add, Delete, IonToLdif y LdifToIon solo aceptaban inputs escrito como lista literal: pasarles la salida de una tarea anterior con una expresión, como {{ outputs.convertir.urisList }}, hacía que el flujo se rechazara al guardarlo.

Las cuatro tareas pasaron a recibir una propiedad dinámica que se resuelve una sola vez antes de procesar los archivos, con el mismo patrón que ya usaba Modify. Las pruebas nuevas fallan en main y pasan con el cambio, y la suite completa del plugin pasa. A pedido del revisor, la documentación de las cinco tareas muestra además cómo pasar un único archivo. El mantenedor lo verificó en Kestra 1.3 y 2.0 antes de integrarlo.

El cambio, ya integrado → El reporte →

La tarea SentryAlert fallaba con un error 400 de Sentry cuando el mensaje tenía tildes, eñes o emojis, en cualquier sistema, y con cualquier texto cuando Kestra corría en Windows. La alerta no llegaba.

Al armar el mensaje a mano, el largo se contaba en caracteres en lugar de bytes y los saltos de línea cambiaban según el sistema operativo, cuando el formato de Sentry pide bytes y saltos de línea fijos. El cambio corrige las dos cosas y suma pruebas que fallan en main y pasan con el arreglo. Lo verifiqué contra sentry.io en Linux y Windows, y el mantenedor lo validó en Kestra 1.3 y 2.0 antes de integrarlo.

El cambio, ya integrado → El reporte →

Al mover archivos por SFTP hacia una carpeta, los nombres con tildes o eñes quedaban corruptos en el servidor (por ejemplo, facturación.txt llegaba como facturación.txt) y la tarea informaba un nombre que no existía.

El nombre se codificaba dos veces al armar la ruta de destino. El cambio arma esa ruta sin la segunda codificación, en los tres lugares donde se repetía el mismo patrón, y suma pruebas que fallan en main con el nombre corrupto y pasan con el arreglo. Lo verifiqué en un Kestra 2.0.5 real, antes y después.

El cambio, ya integrado → El reporte →

Las descargas y el disparador por SFTP fallaban con cualquier archivo que tuviera % en el nombre (por ejemplo, report 100%.txt): la ruta se codificaba dos veces y el archivo "no existía". Además, el filtro regExp nunca encontraba esos archivos y la tarea terminaba en éxito sin hacer nada.

Fueron dos cambios. El primero toma la ruta decodificada al armar la lista de archivos. El segundo compara el filtro contra esa misma ruta, en List, Downloads, Delete y el disparador, y lo deja documentado. Los dos traen pruebas que fallan en main y pasan con el arreglo, con la suite completa en verde. Los mantenedores los validaron en Kestra 1.3 y 2.0, con SFTP, FTP y FTPS, antes de integrarlos.

El primer cambio, ya integrado → El segundo, ya integrado →

La tarea que guarda varios archivos en una carpeta local escribía my%20report.csv en vez de my report.csv: tomaba el nombre de la dirección interna sin decodificarla.

El arreglo usa la misma función que ya usaba la tarea de un solo archivo y trae una prueba que falla en main y pasa con el cambio. Lo reporté, me lo asignaron, y el mantenedor lo aprobó y lo integró el mismo día en que abrí el cambio.

El cambio, ya integrado →

Documenté la propiedad responseBody del disparador Webhook, que permite responder a quien llama con un texto exacto en lugar del JSON de salidas. Es lo que necesita, por ejemplo, la validación de suscripciones de Microsoft Graph, que espera de vuelta el token tal cual.

La página incluye el ejemplo de Microsoft Graph, el aviso de que esa respuesta la recibe cualquiera que llame al webhook (por lo que no debe llevar secretos) y una nota sobre los tiempos de espera. La propiedad en sí está en revisión en el repositorio principal de Kestra; la documentación quedó integrada en la rama de la versión 2.1.

El cambio, ya integrado → El reporte →