Sobre las mentorías

01/12/2025

¿Por qué alguien pagaría por un mentor?

Es una pregunta seria.

Muchas veces vi anuncios ofreciendo este servicio. Muchas veces, amigos y compañeros me han sugerido que debería dar este servicio.

Pero siento que la idea de pagar por un mentor va en contra del concepto de un mentor en sí mismo.

¿De hecho, cómo llega alguien al punto de necesitar un mentor as a service?

Al menos como yo entiendo el concepto de mentor, se supone que sea un compañero con más experiencia que acompaña y guía a otro.

En condiciones “extremas” puede si quien va a ser mentoreado carece por completo de experiencia, es valido que la relación comience con una dinámica más parecida a la de un profesor y un alumno, pero esa dinámica debe cambiar a la de compañeros en cuanto se tenga un mínimo de autonomía para llevar a cabo trabajos simples.

El mentor debe ser un senpai, no un sensei.

En este esquema, el mentor se ve beneficiado de la posibilidad de delegar trabajo. De contar con un par extra de manos. De poder perpetuar su profesión y su existencia mediante el legado y la huella que deja en su protegido.

Para mí, una mentoría paga es solo una forma de agregar mística al concepto de un profesor particular.

El concepto de un profesor particular no tiene nada de malo. De hecho, me parece excelente para que alguien pueda aprender de manera acelerada.

Un curso acelerado de 3 meses para aprender Python puede hacer maravillas. Y deja mucho más claras las expectativas para todos. Un profesor. Por 3 meses.

Siento que un mentor no debería tener fecha de caducidad.

También puede ser solo TOC mío con el uso de las palabras y el lenguaje.

Dicho todo esto,

Si creen que les serviría acompañamiento temporal; de alguien con espíritu de hacker open source, que por vocación hubiera estudiado filosofía y letras, pero prefirió no pasar hambre y enfocó su carrera profesional en la arquitectura de software (con programación orientada a objetos) como Product Engineer hasta que la parte de “product” se le fue de las manos y terminó cumpliendo el rol de Head of Product donde pasó a tener gente a cargo y terminó interesándose más por el People & Teams Management que por la programación, pero a pesar de eso no deja de programar; pueden contactarme a me@iyaki.ar.

Larga y prospera vida 🖖.

Hice un jueguito

29/11/2025

Papa online - Para jugar con familiares o amigos de facebook.

En realidad no sé si decir que HICE un juego porque prácticamente no toque nada del código fuente, no diseñe las reglas, ni siquiera fue mi idea hacer una versión online de este juego.

A principio del 2024, hicimos una reunión con mis compañeros de la escuela, a la mayoría los conozco desde los 6 años y compartimos prácticamente todos nuestros días hasta los 18 años, cuando terminamos el secundario. A pesar de eso, a algunos, hacía prácticamente 10 años que no los veía.

—Cosas de la vida—.

Supongo.

Dejando de lado la melancolía, la cuestión es que mientras hablaba con uno de mis amigos, no sé muy bien cómo, llegó a la conclusión (o quizás fuese algo que ya venía fraguando hace tiempo) de que era inadmisible que no existiera una versión online del juego de la papa. Y que además, por alguna razón, yo debería desarrollarlo.

Podría haber quedado como una charla cualquiera más que no lleva a nada, pero la verdad es que la idea me gustó.

Lo primero fue buscar cómo se jugaba. Si bien estaba seguro de que las reglas eran muy simples, era algo que hacíamos, principalmente, durante la primaria, así que necesitaba refrescar la memoria.

Así me enteré de que, al parecer, las reglas completas eran un poco diferente a lo que recordaba e involucraban una especie de puntajes durante la partida. La versión simplificada, donde solo se ganaba o se perdía que yo recordaba, me gustó más.

Lo siguiente era desarrollar el juego. Hay personas que aman la idea de desarrollar sus propios videojuegos. Les apasiona la parte relacionada con los gráficos, interacción, ambientación.
Yo no soy una de esas personas.

Así que me pareció una excelente oportunidad para probar herramientas de desarrollo impulsadas por IA para lograrlo.

Quizás el problema fue que no supe usarlas adecuadamente, pero no conseguí el resultado que buscaba con ninguna de las herramientas que conocía en ese momento.

Copilot, Windsurf, Codex, ninguna me daba un resultado lo suficientemente bueno como para que no tuviera que involucrarme en los pormenores del uso de canvas y los algoritmos del juego.
En algún punto este proyecto se convirtió en mi forma de probar las IAs, LLMs, agentes y herramientas del estilo.

Pasaban los meses y ninguna lo lograba.

Hace unas semanas leí sobre el lanzamiento del IDE Antigravity de Google. Y adivinen qué.

Lo consiguió.

Necesitó de unos cuantos prompts e iteraciones para llegar al estado actual, pero desde el primer resultado generó una aplicación que cumplía las expectativas mínimas para poder considerarse un prototipo funcional.

No es perfecto. La mitad de las veces que le pedí agregar nuevas features o resolver bugs, lo hizo a costa de romper otras cosas que ya funcionaban. Por otra parte, eso no es muy distinto del resultado de muchos programadores humanos (?).

Anyway.

El punto es que ahora existe una versión online de uno de los juegos de mi infancia con el que pasé horas libres, clases aburridas y me divertí con amigos:

Papa online - Para jugar con familiares o amigos de facebook.

Literalmente ese es el nombre que le dio mi amigo esa noche, no sé por qué fue tan específico respecto a con quién se debe jugar.
Por desgracia, las reglas para restringir a quien se elige como adversario eran un poco difíciles de implementar, por lo que podrán jugar con quien sea que quieran ;).

Espero que se diviertan.

Hasta la próxima.

Devcontainers de cero a cien, en español

03/03/2025

Los lenguajes de programación evolucionan a una velocidad increíble, esto puede generar que tengamos que trabajar con distintas versiones de un mismo lenguaje de programación para distintos proyectos pero en una misma computadora.

Este es un problema bien conocido y con algunas soluciones que las distintas comunidades han ido desarrollando con el tiempo, dándonos herramientas específicas como nvm para node.js o algunas con un mayor alcance como asdf-vm.

Y aunque estas soluciones pueden ser excelentes a la hora de permitirnos cambiar rápidamente entre versiones de nuestros lenguajes de programación, también presentan algunos inconvenientes, ya que, al basar su funcionamiento en el compilado desde el código fuente de las distintas versiones, requieren que uno cuente con todas las dependencias necesarias para poder compilarlas.

Esto en muchos casos puede resolverse simplemente con la ayuda de Google, pero en otros casos puede resultar bastante complicado.

Especialmente si tu sistema operativo ya no provee las versiones específicas de las dependencias necesarias para compilar alguna versión en particular (por ser demasiado nuevas o demasiado viejas).

Otra complejidad de estas herramientas aparece al tener que trabajar en equipo, ya que requieren que cada uno, de manera individual, configure su computadora según las necesidades del proyecto.

¿Pero qué tal si existiese una herramienta que permitiera asegurar la replicabilidad de los entornos de desarrollo?

Y no solo de los lenguajes de programación, sino de todas las herramientas adicionales que se puedan requerir para mejorar la Developer eXperience, permitiendo incluso instalar extensiones específicas en tu IDE y teniendo todo esto versionado junto con el código fuente del proyecto.

Pues existe.

Hoy vengo a compartir una herramienta que uso cada vez más en mis proyectos de desarrollo software: devcontainers.

Sobre esta guía

Devcontainers utiliza virtualización mediante containers para crear entornos de desarrollo personalizables, replicables y versionables.

En esta guía exploraremos sus casos de uso y configuraciones sin detenernos en conceptos propios de docker (el motor de containers que utiliza por defecto).

En los ejemplos utilizaremos Visual Studio Code, Docker y Docker compose.

Tener algunos conocimientos básicos de estas herramientas o de GNU Linux (S.O. utilizado dentro de los containers) puede ayudar a facilitar el entendimiento de algunas de las cosas que haremos a lo largo de esta guía.

Al momento de escribir esto me encuentro utilizando:

• KDE Neon 6.3 (Distribución de GNU Linux derivada de Ubuntu).
• Visual Studio Code 1.97.2.
• Docker Desktop 4.38.0.

Todos los pasos de esta guía deberían poder seguirse también, sin problemas, tanto utilizando Docker Engine como en los sistemas operativos Mac o Windows (utilizando Windows Subsystem for Linux).

Para instalar devcontainers en Windows existe una guía, escrita por el equipo de Visual Studio Code.

Devcontainers posee integraciones con una amplia lista de IDEs y herramientas de desarrollo, no solo se integra con el Visual Studio Code.

Mención especial para vscli, una herramienta que aunque no se encuentra listada oficialmente, se ve interesante.

Para poder seguir los distintos pasos deberán contar con Docker instalado y ejecutándose.

Por último, para aquellos con experiencia en Docker. Muchos de los “problemas” que solucionaremos a lo largo de esta guía mediante las características y opciones de devcontainers podrían resolverse (a veces, incluso de manera más simple) mediante el uso de Docker puro o eligiendo mejor las imágenes base, pero el objetivo aquí es explorar estas características y opciones.

Comenzando un nuevo proyecto con devcontainers

Como ejemplo para poder explicar el funcionamiento de estos entornos de desarrollo crearemos una pequeña aplicación PHP.

Por lo que en un directorio vacío comenzaremos creando el archivo public/index.php y en el escribiremos:

Hola mundo

¡Excelente! Ya tenemos la aplicación más simple del mundo. Pero para poder ejecutarla necesitamos PHP. Y ahí es en donde entra en juego devcontainers.

Para utilizarlo comenzaremos por instalar la extensión Dev Containers del VSCode.

Pueden buscarla en la pestaña de extensiones.

O bien instalarla mediante el comando ext install ms-vscode-remote.remote-containers en el Qucik Open (Ctrl+p) del VSCode.

Ya con la extensión instalada y activa, en la paleta de comandos (Ctrl+Shift+p) ejecutaremos Dev Containers: Add Dev Container Configuration Files.

Esto nos desplegará un pequeño Wizard en el que configuraremos algunas opciones básicas del entorno de desarrollo.

Where would you like to create your container configuration?
> Add configuration to workspace

Elegimos esta opción para poder versionar el entorno de desarrollo junto con el resto de la aplicación.

Select a container configuration template or enter a custom template id
> PHP (devcontainers)

Elegimos la plantilla para proyectos PHP publicada por el equipo de devcontainers.

PHP version (use -bookworm, -bullseye variants on local arm64/Apple Silicon):
> 8.2-bullseye (default)

Seleccionamos la versión de PHP que deseamos utilizar. En esta guía usaremos PHP 8.2.

Los sufijos -bullseye y -bookworm indican la versión de Debian que el container utilizará como base para el entorno de desarrollo.

Select additional features to install

De memento no agregaremos ninguna funcionalidad adicional, por lo que solo damos click en OK par finalizar la configuración.

Finalmente, se nos preguntará si deseamos configurar Github Dependabot para que actualice automáticamente las dependencias de devcontainers. Para mantener esta guía lo más simple posible continuaremos sin esta opción, pero en proyectos reales puede ser muy recomendable utilizar esta actualización automática de dpenedencias.

Luego de seguir estos pasos se creará el archivo ./devcontainer/devcontainer.json y el VSCode nos preguntará si deseamos reabrir el proyecto dentro del container (cartel de abajo a la derecha)

Damos click al botón Reopen in Container.

Si por la razón que fuese el cartel dejase de visualizarse, podemos abrir la paleta de comandos y ejecutar Dev Containers: Reopen in Container

Al hacer esto se comenzará a crear el container con el entorno de desarrollo (este proceso puede demorar algunos minutos la primera vez).

Al terminar de crear el container y conectarse deberíamos tener en pantalla algo así:

Sabemos que nos encontramos conectados al container porque así lo indica en la parte inferior izquierda del VSCode (barra azul) y también el nombre del proyecto (barra superior central).

Ahora que ya nos encontramos dentro del entorno de desarrollo podemos, desde la terminal integrada del Visual Studio Code, ejecutar: php -S 0.0.0.0:8080 -t public/ y con esto habremos puesto nuestra aplicación en ejecución. Si en una pestaña de nuestro navegador web introducimos la URL http://localhost:8080/ deberíamos ver:

También deberíamos ser capaces de commitear e incluso pushear nuestra aplicación a Github desde dentro del container, ya que, este se encarga de replicar la configuración de git de nuestro usuario local.

Link al repositorio del proyecto de ejemplo con los cambios hasta este punto de la guía.

Eligiendo templates o imágenes según nuestras necesidades

El equipo de devcontainers mantiene una serie de templates e imágenes predefinidas para facilitar el despliegue de entornos de desarrollo.

En este link pueden encontrar la lista completa de templates.

Y en este link una lista de las imágenes mantenidas por el equipo de devcontainers.

En caso de que no encuentren ninguno que se ajuste a las necesidades exactas de su proyecto, siempre pueden optar por el template base de Debian y ajustarlo según necesiten.

Lo más básico y primero que nos enfocaremos en cambiar es la imagen a partir de la cual se genera el entorno de desarrollo.

Volviendo a nuestra aplicación de ejemplo, supongamos que la versión de PHP que queremos utilizar es la última disponible (a día de hoy, la versión 8.4).
Durante la ejecución del Wizard, y utilizando el template de PHP las únicas versiones que se nos ofrecían eran la 8.0, 8.1 y 8.2.

Lo bueno es que al utilizar una tecnología bien establecida como lo son los containers contamos con muchísimas imágenes ya preparadas en distintos repositorios, que podemos utilizar sin problemas.

Primero verificamos la versión actual de PHP ejecutando, desde la terminal integrada del VSCode:

php -v

En nuestro caso, utilizaremos la imagen oficial de PHP, proveniente de Docker Hub.

Desde Docker Hub, en la sección de tags buscamos el correspondiente a la versión 8.4.

Ahora que ya tenemos el nombre de la imagen y tag que deseamos utilizar en nuestro .devcontainer/devcontainer.json modificamos el atributo image.

{
        "name": "PHP",
        // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
-       "image": "mcr.microsoft.com/devcontainers/php:1-8.2-bullseye",
+       "image": "php:8.4-cli-bullseye",

        // Features to add to the dev container. More info: https://containers.dev/features.
        // "features": {},

Luego de esto, desde la paleta de comandos, ejecutaremos Dev Containers: Rebuild Container.

Al hacer esto, el antiguo container se destruirá y se creará uno nuevo con los cambios que hemos realizado.

Una vez que el nuevo container ha sido creado, volvemos a revisar la versión de PHP.

Link al repositorio del proyecto de ejemplo con los cambios hasta este punto de la guía.

Agregando funcionalidades (Devcontainer Features)

Ya tenemos la versión de PHP que queremos utilizar, pero si intentamos commitear nuestros cambios nos encontraremos un pequeño inconveniente.

La imagen oficial de PHP está diseñada para ser utilizada en entornos productivos, por lo que no cuenta con git instalado.

Por suerte contamos con un mecanismo muy simple para agregar herramientas adicionales a nuestros entornos de desarrollo, mediante las Features de devcontainers.

Para configurar la features, en la paleta de comandos escribimos Dev Container: Configure Container Features.

Esto nos desplegará una lista de features disponibles, similar a la que ya vimos al ejecutar inicialmente el wizard.

Aquí buscamos Git (from source) y marcamos su checkbox.

Luego damos click a OK y en el siguiente paso elegimos la opción Keep Defaults.

Esto nos agregará una nueva sección en nuestro archivo de configuración.

        // "customizations": {},

        // Use 'forwardPorts' to make a list of ports inside the container available locally.
-       "forwardPorts": [8080]
+       "forwardPorts": [8080],
+       "features": {
+               "ghcr.io/devcontainers/features/git:1": {}
+       }

        // Use 'postCreateCommand' to run commands after the container is created.
        // "postCreateCommand": "sudo chmod a+x \"$(pwd)\" && sudo rm -rf /var/www/html && sudo ln -s \"$(pwd)\" /var/www/html"

Podemos revisar la lista completa de Features en este link.

Para reconstruir el container con el agregado de git damos click al botón Rebuild que nos debería haber aparecido abajo a la derecha o bien, en la paleta de comandos, ejecutamos Dev Containers: Rebuild Container

Et voila! Una vez que el container se haya reconstruido ya podremos utilizar git.

Link al repositorio del proyecto de ejemplo con los cambios hasta este punto de la guía.

Ciclo de vida del container de desarrollo, comandos y scripts

Tener un entorno de desarrollo con la versión más nueva de nuestro lenguaje de programación y git está muy bien, pero todavía podemos llevarlo al siguiente nivel.

El único próximo paso lógico es agregar herramientas de debugging, porque, enfrentemos la realidad. Nuestra aplicación el día de mañana podría tener millones de usuarios activos. ¿A fin de cuentas, por qué alguien no querría una aplicación diseñada específicamente para saludar al mundo?

Pero junto con los usuarios llegan los pedidos de nuevas funcionalidades.

Saludar al vecino, saludos de cumpleaños, quizás una comunidad de yoga quiera un saludo al sol.

Y junto con las nuevas funcionalidades llegan los bugs.

Definitivamente, necesitamos agregar herramientas de debugging a nuestro entorno de desarrollo.

Según la documentación de PHP en Docker Hub, instalar xdebug es tan simple como ejecutar 2 comandos.

pecl install xdebug
docker-php-ext-enable xdebug

Podríamos simplemente ejecutar esto en nuestra terminal y tendríamos la extensión instalada… Hasta que por alguna razón reconstruyamos nuestro container de desarrollo.

Podríamos dejar una nota en nuestro README indicando que luego de crearse el container deben ejecutarse dichos comandos… Si tan solo siguiera existiendo gente que leyera la documentación de los proyectos.

Por suerte para nosotros, devcontainers nos da una mejor solución.

Podemos configurarlo para que luego de crearse el container ejecute comandos que definamos.

Esto lo haremos mediante el atributo postCreateCommand de nuestro archivo de configuración.

        "forwardPorts": [8080],
        "features": {
                "ghcr.io/devcontainers/features/git:1": {}
-       }
+       },

        // Use 'postCreateCommand' to run commands after the container is created.
-       // "postCreateCommand": "sudo chmod a+x \"$(pwd)\" && sudo rm -rf /var/www/html && sudo ln -s \"$(pwd)\" /var/www/html"
+       "postCreateCommand": "pecl install xdebug && docker-php-ext-enable xdebug"

        // Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
        // "remoteUser": "root"

Una vez más reconstruimos nuestro container y revisamos que nuestros cambios hayan tenido éxito con php -m | grep xdebug.

Luego de ejecutar el comando la terminal devuelva xdebug es indicador de que la extensión se encuentra instalada y activa.

En la documentación de devcontainers pueden encontrar la lista completa de los puntos del ciclo de vida del container en los que es posible ejecutar comandos personalizados.

Link al repositorio del proyecto de ejemplo con los cambios hasta este punto de la guía.

Montajes, puertos, variables de entorno y otras hierbas

¡El desarrollo de nuestra aplicación va viento en popa! Pero algo no termina de sentirse correcto.

¿Cómo es posible que cada vez que abrimos nuestro container de desarrollo debamos iniciar manualmente nuestro servidor web?

¡Inaceptable!

Aprovecharemos el atributo postStartCommand para arrancar automáticamente nuestro web server.

    },

    // Use 'postCreateCommand' to run commands after the container is created.
-   "postCreateCommand": "pecl install xdebug && docker-php-ext-enable xdebug"
+   "postCreateCommand": "pecl install xdebug && docker-php-ext-enable xdebug",
+
+   "postStartCommand": "php -S 0.0.0.0:8080 -t public/"

    // Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
    // "remoteUser": "root"

Reconstruimos nuestro container y podremos acceder a nuestra aplicación en http://localhost:8080 sin necesidad de ejecutar comandos adicionales de manera manual.

Mientras observamos con aires de victoria como nuestra aplicación saluda al mundo, un pensamiento nos ataca por la retaguardia sin previo aviso.

Un pensamiento que comenzó a formarse en lo más recóndito de nuestra mente, utilizando memorias distantes, ahora viene a por nosotros.

Buenas prácticas…

… The 12 Factor App, una de las convenciones de DevOps para sistemas cloud…

… X Factor - Dev/prod parity…

… El Built-in web server de PHP, tal como indica su documentación, no debería ser utilizado en entornos productivos.

… Entonces, según el factor Dev/Prod Parity de los 12 Factor App, tampoco deberíamos estar usándolo en nuestro entorno de desarrollo, ya que debemos buscar que nuestros ambientes de producción y desarrollo sean lo más similares posible…

😞

¡No importa! Algo como esto no va a detenernos.

Vamos a usar en nuestro entorno de desarrollo el mismo websever que utilizaremos en producción.

Existen varias opciones perfectamente válidas, pero hoy usaremos FrankenPHP.

Para esto, eliminaremos el postStartCommand que acabamos de agregar y cambiaremos la imagen por la de FrankenPHP.

 {
    "name": "PHP",
    // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
-   "image": "php:8.4-cli-bullseye",
+   "image": "dunglas/frankenphp:1-php8.4",

    // Features to add to the dev container. More info: https://containers.dev/features.
    // "features": {},
@@ -18,9 +18,7 @@
    },

    // Use 'postCreateCommand' to run commands after the container is created.
-   "postCreateCommand": "pecl install xdebug && docker-php-ext-enable xdebug",
-
-   "postStartCommand": "php -S 0.0.0.0:8080 -t public/"
+   "postCreateCommand": "pecl install xdebug && docker-php-ext-enable xdebug"

    // Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
    // "remoteUser": "root"

La imagen de FrankenPHP, por defecto, tiene su WORKDIR configurado en /app/public/ asi que el proyecto intentará montarse allí. Pero nosotros ya contamos con un directorio public/ por lo que deberemos configurar tanto el working dir como el punto de montaje.

    // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
    "image": "dunglas/frankenphp:1-php8.4",

+   "workspaceMount": "source=${localWorkspaceFolder},target=/app,type=bind,consistency=cached",
+   "workspaceFolder": "/app",
+
    // Features to add to the dev container. More info: https://containers.dev/features.
    // "features": {},

Dentro de wokspaceMount estamos utilizando una variable propia de devcontainers (${localWorkspaceFolder}), para más información sobre las variables disponibles y como utilizarlas pueden visitar este link.

Además, siguiendo la documentación de FrankenPHP agregaremos algunas variables de entorno para configurar nuestro webserver.

    // Use 'forwardPorts' to make a list of ports inside the container available locally.
    "forwardPorts": [8080],
+
+   "containerEnv": {
+       "SERVER_NAME": "http://localhost:8080",
+       "CADDY_GLOBAL_OPTIONS": "auto_https off" // Disable automatic HTTPS
+   },
+
    "features": {
        "ghcr.io/devcontainers/features/git:1": {}
    },

El atributo forwardPorts no lo modificaremos ya que estamos configurando nuestro nuevo webserver para escuchar en el puerto 8080 por lo que queremos seguir exponiendo este mismo puerto.

Por último configuraremos overrideCommand para evitar que devcontainers sobreescriba el proceso default de la imagen, ejecutar el webserver, ya que eso es exactamente lo que queremos que haga.

    // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
    "image": "dunglas/frankenphp:1-php8.4",

+   "overrideCommand": false,
+
    "workspaceMount": "source=${localWorkspaceFolder},target=/app,type=bind,consistency=cached",
    "workspaceFolder": "/app",

El resultado final debería ser que nuestro .devcontainer/devcontainer.json se vea así:

{
    "name": "Helloer",
    "image": "dunglas/frankenphp:1-php8.4",

    "overrideCommand": false,

    "workspaceMount": "source=${localWorkspaceFolder},target=/app,type=bind,consistency=cached",
    "workspaceFolder": "/app",

    "forwardPorts": [8080],

    "containerEnv": {
        "SERVER_NAME": "http://localhost:8080",
        "CADDY_GLOBAL_OPTIONS": "auto_https off" // Disable automatic HTTPS
    },

    "features": {
        "ghcr.io/devcontainers/features/git:1": {}
    },

    "postCreateCommand": "pecl install xdebug && docker-php-ext-enable xdebug"
}

Reconstruimos nuestro container y una vez más tenemos nuestra aplicación funcionando en nuestro entorno de desarrollo, esta vez utilizando el mismo webserver que utilizaríamos en producción.

Al haber cambiado el workspaceFolder en la configuración es posible que luego de recrear el container el Visual Studio Code falle al intentar conectarse. Si esto ocurre solo debemos dar click a Open workspace y buscar el directorio que hemos configurado para ser el nuevo workspaceFolder (/app/).

Link al repositorio del proyecto de ejemplo con los cambios hasta este punto de la guía.

Intermedio

Por fin, nuestro entorno de desarrollo es perfecto y estamos listos para seguir agregando valor a la vida de millones mediante nuestra aplicación.

Nuestra siguiente funcionalidad será recibir un número como parámetro y saludar indicando si el número es par o impar.

Pero como somos desarrolladores que se respetan a sí mismos y siguen las mejores prácticas de comunidades importantes como la de Javascript sabemos que para realizar semejante proeza necesitaremos utilizar alguna biblioteca de terceros.

En PHP se utiliza el gestor de dependencias composer para gestionar bibliotecas de terceros en nuestra aplicación.

Procedemos a instalar la biblioteca que necesitamos ejecutando en la terminal integrada, composer require kylelamse/is-even.

Otra herramienta que nos falta.

🫠

Si trabajan como DevOps (si, si, ya se que ne realidad no es un rol), SysAdmin, Platfom engineer, etc lo que van a leer no es ninguna novedad; pero si son programadores es importante que sepan esto.
Este tipo de trabajos, aunque gratificantes cuando las cosas finalmente funcionan, pueden ser sumamente tediosos e iterativos.
Aprecien que alguien se preocupe por ustedes e intente facilitarles las cosas. Si ven un DevOps cansado ofrezcanle un cafe y recuereden, en sú día comprar unas facturas para compartir o algo por el estilo.

Llegados a este punto creo que ya todos tenemos bastante claro como proceder.

Buscamos si existe una feature de composer.

Sí, existe.

La agregamos a nuestro archivo de configuración y reconstruimos el container.

O tal vez nó…

Quizás para cuando estén leyendo esta guía este problema ya se haya arreglado, pero hoy, al agregar el feature de composer ocurre lo siguiente:

El container falla.

Debugging y solución de errores

Cuando se encuentren con un error que impide que el container compile correctamente, hay algunas cosas que pueden probar.

Primero pueden dar click a Retry. Si el error proviene de alguna causa externa y temporal (por ejemplo, si se cortó el internet mientras el container se creaba) con esto debería solucionarse.

Si Retry no funciona, pueden dar click en Edit devcontainer.json Locally y comenzar a leer, de abajo hacia arriba, el log que se abrirá del lado derecho de la pantalla, mientras rezan para que la causa del error sea comprensible.

Si conocen mejores maneras de debuggear estas configuraciones, por favor déjenlo abajo, en los comentarios. Yo ya perdí bastantes horas de mi vida con errores de lo más simple, pero todavía están a tiempo de ayudar a personas que se estén iniciando en este mundo.

El único consejo real que puedo darles es que commiteen tan seguido como puedan. Cada vez que tengan una versión de la configuración que compila (aunque todavía no funcione al 100% como ustedes quieren) commiteenla.

En este caso el problema está claramente en el feature de composer.

Si revisamos la documentación del feature vemos que el único parámetro que acepta es para configurar la versión que se instalará, por lo que no parece que haya mucho que podamos hacer desde allí.

En nuestro caso será más fácil buscar una manera de instalar composer por algún otro medio, pero si se encuentran con algún problema persistente que los bloquea pueden recurrir a los Issues de Github del repositorio que corresponda.

Composer cuneta con una breve guía para realizar instalaciones automáticas. Siguiendo sus instrucciones (y adaptándolas un poco) haremos lo siguiente.

Creamos un nuevo archivo .devcontainer/composer.sh.

#!/bin/sh

EXPECTED_CHECKSUM="$(php -r 'copy("https://composer.github.io/installer.sig", "php://stdout");')"
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
ACTUAL_CHECKSUM="$(php -r "echo hash_file('sha384', 'composer-setup.php');")"

if [ "$EXPECTED_CHECKSUM" != "$ACTUAL_CHECKSUM" ]
then
    >&2 echo 'ERROR: Invalid installer checksum'
    rm composer-setup.php
    exit 1
fi

php composer-setup.php --quiet --install-dir=/usr/local/bin --filename=composer
RESULT=$?
rm composer-setup.php
exit $RESULT

Y desde la terminal integrada le damos permisos de ejecución.

chmod +x .devcontainer/composer.sh

Luego configuramos nuestro .devcontainer/devcontainer.json para ejecutar el script.

        "ghcr.io/devcontainers/features/git:1": {}
    },

-   "postCreateCommand": "pecl install xdebug && docker-php-ext-enable xdebug"
+   "postCreateCommand": {
+       "install xdebug": "pecl install xdebug && docker-php-ext-enable xdebug",
+       "install composer": ".devcontainer/composer.sh"
+   }

    // Configure tool-specific properties.
    // "customizations": {},

¡Ahora sí!

Instalamos la dependencia is-even

composer require kylelamse/is-even

Esto debería crear los archivos compose.json, composer.lock y el directorio vendor/, donde se encuentra el código fuente de la dependencia que hemos instalado

Crearemos manualmente un archivo .gitignore para evitar commitear la carpeta vendor/.

printf "/vendor\n" > .gitignore

Y modificamos nuestro archivo public/index.php para agregar nuestra nueva funcionalidad:

-Hola mundo
+<?php
+
+declare(strict_types=1);
+
+require __DIR__ . '/../vendor/autoload.php';
+
+$number = $_GET['number'] ?? null;
+$number = is_numeric($number) ? (int) $number : null;
+
+$helloed = match (true) {
+    ! is_int($number) => 'mundo',
+    is_even($number) => 'par',
+    default => 'impar',
+};
+
+echo "Hola, $helloed";

¡Perfecto! Nuestra aplicación ya puede diferenciar números pares e impares de manera correcta y cortes.

Aplicación saludando sin parámetro numero.

Aplicación saludando con parámetro numero en 1 (número impar)

Aplicación saludando con parámetro numero en 2 (número par)

Link al repositorio del proyecto de ejemplo con los cambios hasta este punto de la guía.

Customizations

Algunas de las herramientas y servicios que poseen integración con devcontainers permiten configuraciones específicas para ayudar a configurar ciertos aspectos de nuestro entorno de desarrollo.

La integración con Visual Studio Code nos permite definir preferencias que aplicarán al proyecto dentro de nuestro entorno de desarrollo y extensiones que se instalarán de manera automática.

Siendo que estamos trabajando en un proyecto PHP puede ser deseable agregar lo siguiente a nuestro archivo de configuración para tener un mejor soporte del lenguaje.

    "postCreateCommand": {
        "install xdebug": "pecl install xdebug && docker-php-ext-enable xdebug",
        "install composer": ".devcontainer/composer.sh"
-   }
+   },

+   "customizations": {
+       "vscode": {
+           "settings": {
+               "files.eol": "\n",
+               "files.trimFinalNewlines": true,
+               "intelephense.completion.fullyQualifyGlobalConstantsAndFunctions": true,
+               "intelephense.completion.triggerParameterHints": true,
+               "intelephense.environment.shortOpenTag": false,
+               "php.suggest.basic": false
+           },
+           "extensions": [
+               "bmewburn.vscode-intelephense-client",
+               "xdebug.php-debug"
+           ]
+       }
+   }
 }

Estas preferencias y extensiones afectarán a todos los que utilicen el entorno de desarrollo de devcontainer. Son especialmente útiles para definir sensible defaults que ayuden a todos los desarrolladores.

Además de esta opción propia de devcontainer, el Visual Studio Code nos brinda una manera de configurar, solo para nosotros, extensiones que queremos que se instalen siempre de manera automática en todos nuestros containers de desarrollo.

Para configurar esto nos dirigimos a las preferencias de VScode (Ctrl+Shift+p > Preferences: Open Settings (UI)).
Y una vez allí buscamos dev.containers.defaultExtensions. Con el botón Add Item podremos agregar las extensiones que deseemos.

Los nombres de las extensiones que debemos agregar corresponden a los IDs de las extensiones. Para saber el ID de una extensión la buscamos en la pestaña de extensiones del VSCode (Ctrl+Shift+x), damos click al icono de engranaje que hay al lado de los botones de instalar y elegimos la opción Copy Extension ID. Esto copiará el ID de la extensión al portapapeles.

Link al repositorio del proyecto de ejemplo con los cambios hasta este punto de la guía.

Back to the basics, Dockerfile

Con todo lo que hicimos hasta ahora debería ser suficiente para poder trabajar sin problemas en una amplia variedad de proyectos.

Pero, en caso de despliegues mas complejos o si necesitásemos contar con muchas herramientas instaladas que no estén disponibles como features, escalar la creación de estos entornos de desarrollo utilizando exclusivamente características de devcontainers puede ser inviable.

A partir de este punto trabajaremos en gran medida con características propias de Docker. El objetivo de esta guía no es dar una introducción a Docker ni Docker Compose por lo que no profundizaremos en aspectos que no sean propios de devcontainers.

Entonces, ¿Qué hacemos si devcontainers nos queda “corto”?

Recurrir a características nativas de Docker.

Devcotnainers brinda la posibilidad de trabajar directamente con archivos Dockerfile y compose.yaml.

Comencemos moviendo las configuraciones que actualmente tenemos en .devcontainer/devcontainer.json a un Dockerfile.

Para esto creamos el archivo .devcontainer/Dockerfile y escribimos:

FROM dunglas/frankenphp:1-php8.4

COPY --from=composer /usr/bin/composer /usr/bin/composer

RUN pecl install xdebug \
    && docker-php-ext-enable xdebug \
    && apt-get update \
    && apt-get install -y --no-install-recommends \
        git \
        unzip \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

y modificamos nuestro .devcontainer/devcontainer.json

 {
    "name": "Helloer",
-   "image": "dunglas/frankenphp:1-php8.4",
+   "build": {
+       "dockerfile": "Dockerfile"
+   },

    "overrideCommand": false,

@@ -14,15 +16,6 @@
        "CADDY_GLOBAL_OPTIONS": "auto_https off" // Disable automatic HTTPS
    },

-   "features": {
-       "ghcr.io/devcontainers/features/git:1": {}
-   },
-
-   "postCreateCommand": {
-       "install xdebug": "pecl install xdebug && docker-php-ext-enable xdebug",
-       "install composer": ".devcontainer/composer.sh"
-   },
-
    "customizations": {
        "vscode": {
            "settings": {

Reconstruimos el container y todo debería seguir funcionando como hasta ahora.

Este ejemplo es bastante simple, pero es posible configurar context, arguments y target y prácticamente todos los parámetros que podríamos utilizar al ejecutar docker build. La lista completa de opciones disponibles se encuentra en este link.

Link al repositorio del proyecto de ejemplo con los cambios hasta este punto de la guía.

Múltiples containers con Docker compose

¿Por qué necesitaríamos varios containers en desarrollo?

Simple, los containers están diseñados para ejecutar únicamente un servicio. Y si bien existen maneras de ejecutar múltiples servicios en un mismo container; si queremos agregar una base de datos a nuestro entorno de desarrollo, suele ser más simple agregar un nuevo container para esta base de datos y orquestar su creación con docker compose.

Así que eso haremos.

Agregaremos una base de datos a nuestro proyecto y la utilizaremos para configurar saludos personalizados.

Comenzaremos migrando las configuraciones presentes en nuestro .devcontiner/devcontainer.json a un archivo de docker compose.

Primero crearemos el archivo .devcontainer/compose.yaml.

services:

  app:
    build:
      context: ..
      dockerfile: .devcontainer/Dockerfile
    working_dir: /app
    volumes:
      - ..:/app
      - caddy_data:/data
      - caddy_config:/config
    environment:
      SERVER_NAME: "${SERVER_NAME:-http://localhost:8080}"
      CADDY_GLOBAL_OPTIONS: "auto_https off"
    tty: true

volumes:
  caddy_data:
  caddy_config:

Y modificamos .devconytainer/devcontainer.json.

 {
    "name": "Helloer",
-   "build": {
-       "dockerfile": "Dockerfile"
-   },
+
+   "dockerComposeFile": "compose.yaml",
+   "service": "app",
+   "workspaceFolder": "/app",

    "overrideCommand": false,

-   "workspaceMount": "source=${localWorkspaceFolder},target=/app,type=bind,consistency=cached",
-   "workspaceFolder": "/app",
-
    "forwardPorts": [8080],

-   "containerEnv": {
-       "SERVER_NAME": "http://localhost:8080",
-       "CADDY_GLOBAL_OPTIONS": "auto_https off" // Disable automatic HTTPS
-   },
-
    "customizations": {
        "vscode": {
            "settings": {

Una vez más reconstruimos el container y todo debería seguir funcionando como lo hacía hasta ahora.

Agregamos el servicio que contendrá la base de datos en nuestro archivo `.devcontainer/compose.yaml’

+x-db-default-params: &db-default-params
+  MARIADB_ROOT_PASSWORD: ${DB_ROOT_PASSWORD:-SUPER_SECRET_ROOT_PASSWORD}
+  MARIADB_DATABASE: ${DB_DATABASE:-helloer}
+  MARIADB_USER: ${DB_USER:-app_user}
+  MARIADB_PASSWORD: ${DB_PASSWORD:-SUPER_SECRET_PASSWORD}
+
 services:

   app:
@@ -10,10 +16,20 @@ services:
       - caddy_data:/data
       - caddy_config:/config
     environment:
+      <<: *db-default-params
       SERVER_NAME: "${SERVER_NAME:-http://localhost:8080}"
       CADDY_GLOBAL_OPTIONS: "auto_https off"
     tty: true

+  db:
+    image: mariadb:11.4-noble
+    restart: unless-stopped
+    volumes:
+      - mariadb:/var/lib/mysql
+    environment:
+      <<: *db-default-params
+
 volumes:
   caddy_data:
   caddy_config:
+  mariadb:

Configuramos .devcontainer/devcontainer.json par aunque inicie el servicio.

@@ -4,6 +4,7 @@
    "dockerComposeFile": "compose.yaml",
    "service": "app",
    "workspaceFolder": "/app",
+   "runServices": ["db"],

    "forwardPorts": [8080],

E instalamos la extensión de mysql para PHP y el cliente de mariadb en nuestro container desde .devcontainer/Dockerfile.

@@ -4,9 +4,11 @@ COPY --from=composer /usr/bin/composer /usr/bin/composer

 RUN pecl install xdebug \
     && docker-php-ext-enable xdebug \
+    && docker-php-ext-install mysqli \
     && apt-get update \
     && apt-get install -y --no-install-recommends \
         git \
+        mariadb-client \
         unzip \
     && apt-get clean \
     && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

Reconstruimos los containers y ya estamos listos para agregar saludos personalizados.

Empezamos creando la tabla de saludos y agregando algunos registros desde la terminal integrada.

mariadb -h db -u "$MARIADB_USER" -p"$MARIADB_PASSWORD" "$MARIADB_DATABASE" -e '
CREATE TABLE greetings (
  name varchar(255),
  greeting varchar(255)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 DEFAULT COLLATE utf8_unicode_ci;'
mariadb -h db -u "$MARIADB_USER" -p"$MARIADB_PASSWORD" "$MARIADB_DATABASE" -e '
INSERT INTO greetings
  (name, greeting)
VALUES
  ("Marta", "Doña"),
  ("Graciela", "Señora"),
  ("Laura", "Señorita"),
  ("Aureliano", "Coronel"),
  ("Gervasio", "Don"),
  ("Ezequiel", "Rey"),
  ("Matias", "Bro")
;'

Agregamos la nueva funcionalidad al código de nuestra aplicación.

@@ -7,7 +7,32 @@ require __DIR__ . '/../vendor/autoload.php';
 $number = $_GET['number'] ?? null;
 $number = is_numeric($number) ? (int) $number : null;

+$name = (string) ($_GET['name'] ?? null);
+
+$custom = null;
+if ($name) {
+    $db = new mysqli(
+        'db',
+        getenv('MARIADB_USER'),
+        getenv('MARIADB_PASSWORD'),
+        getenv('MARIADB_DATABASE')
+    );
+
+    $query = <<<SQL
+        SELECT greeting FROM greetings
+        WHERE name = ?
+        LIMIT 1
+    SQL;
+
+    $result = $db->execute_query($query, [$name])->fetch_all(MYSQLI_ASSOC);
+
+    if ($result) {
+        $custom = $result[0]['greeting'];
+    }
+}
+
 $helloed = match (true) {
+    $custom !== null => $custom,
     ! is_int($number) => 'mundo',
     is_even($number) => 'par',
     default => 'impar',

Y ya tenemos saludos personalizados y configurables mediante la base de datos.

Si revisan el repositorio de templates de devcontainers encontrarán uno diseñado para aplicaciones PHP con MariaDB. Es bastante similar a la solución a la que hemos llegado pero puede ser interesante verlo y buscar que hemos hecho distinto y por qué.

Link al repositorio del proyecto de ejemplo con los cambios hasta este punto de la guía.

Sintiendonos como en casa con dotfiles

Aunque no es una característica propiamente de devcontainers, sino del Visual Studio Code, hay una cosa más puede ayudarnos a que nuestro entorno de desarrollo nos resulte más cómodo: el uso de dotfiles.

En linux es bastante común versionar ciertas configuraciones de las computadoras para poder tenerlas sincronizadas entre distintos equipos. A estos repositorios donde se versionan estas configuraciones se los suele llamar dotfiles.

Suelen utilizarse para modificar la apariencia de la terminal, agregas aliases, funciones, etc (casi siempre nos ayudará a ser más eficientes trabajando con la terminal).

Yo, por ejemplo, tengo mis dotfiles en Github (link al repositorio).

El VSCode puede configurarse para clonar estos repositorios y utilizar sus configuraciones.

Para esto utilizaremos las siguientes configuraciones:

• dotfiles.repository: Aquí debemos escribir la URI del repositorio que deseamos clonar, en mi caso utilizo https://github.com/iyaki/dotfiles.
• dotfiles.targetPath: El directorio donde se clonará el repositorio. Por defecto ~/dotfiles.
• dotfiles.installCommand: Comando a ejecutar luego de clonar el repositorio. Aquí generalmente se ejecuta un script que mueve o “linkea” los archivos de nuestro repositorio a las ubicaciones donde los archivos de configuración deben encontrarse para surtir efecto. Por defecto intentará ejecutar el primero de estos archivos que encuentre dentro del repositorio (en orden) install.sh, install, bootstrap.sh, bootstrap, setup.sh, setup.

Impresiones finales

Hemos experimentado con múltiples formas de configurar devcontainers, iniciando por las más simples hasta llegar a las más complejas.

A medida que la complejidad del deploy crece, el usar devcontainers y no simplemente las tecnologías en las que se basa (Docker compose) va perdiendo sentido, aunque la integración que brinda con ciertas herramientas, como el Visual Studio Code, puede seguir siendo interesante.

Por desgracia, la complejidad no puede ser eliminada, pero herramientas como esta nos ayudan a poder tenerla más ordenada e incluso “escondida” de quienes dependen de ella para poder realizar su trabajo.

Esto ha sido todo. Espero que les sea de utilidad y como siempre, por dudas, preguntas, consejos, recomendaciones o lo que sea que quieran compartir, tienen disponible la caja de comentarios o pueden escribirme a me@iyaki.ar.

Hasta pronto!

La IA conversacional como hypermedia client

03/05/2024

Motivación

El proyecto htmx siempre me llamó mucho la atención, me parece una propuesta (aunque aún no he tenido la oportunidad de probar esta biblioteca en escenarios reales) de lo más interesante. Pero aún más interesantes me parecen los ensayos que su equipo escribe (suelen ser bastante cortos, que la palabra ensayo no los desaliente de ir a leerlos).

De entre todos sus ensayos, por alguna razón el de Hypermedia Clients quedó grabado en mi cerebro y se volvió una referencia muy importante para mí a la hora de pensar en como diseñamos aplicaciones web y como estas interactúan, tanto con humanos como con otras aplicaciones.

No es el primero de sus ensayos que trata el tema de las Hypermedia APIs (forma cool de decir HAETOAS sin asustar a la gente), ya que es una temática recurrente e importante para ellos, por lo que también tienen escritos al respecto en el 2022 y 2021. Pero Hypermedia Clients, de fines de enero del 2023, fue el primero en visibilizar y hacer notoria la relevancia que realmente tiene el cliente y no centrarse solo en los aspectos del server.

Casi a la par de la publicación de dicho ensayo, el mundo se veía revolucionado por uno de los, tal vez mayores, pero sin duda, más impactantes, avances tecnológicos con ChatGPT alcanzando los cien millones de usuarios luego de solo 2 meses online tras demostrar sus increíbles capacidades.

Desde entonces comencé a rumiar la idea de que una inteligencia artificial podría funcionar muy bien como nexo entre aplicaciones web que han sido diseñadas para ser utilizadas por humanos (y que utilizan fuertemente los conceptos de hypermedia) y aplicativos o bibliotecas que buscan consumir estas aplicaciones.

En ese momento ChatGPT no tenía la capacidad de acceder a internet, pero, desde hace un tiempo, esto ya es posible, así que decidí ponerme a experimentar un poco para averiguar que tan útil podía llegar a ser.

A continuación les comparto una muy informal prueba sobre este potencial uso de las inteligencias artificiales conversacionales. Este experimento lo realicé utilizando el GPT WebPilot de ChatGPT.

El experimento

Link a la conversación con ChatGPTutilizando WebPilot.

El experimento se centró en probar la capacidad de la IA para navegar por una página web e interactuar con la misma, extrayendo información o incluso realizando acciones.

Para eso, primero, utilicé esta misma página, iyaki.ar. Por alguna razón no supo identificar como ir desde la página principal al blog. Pero una vez “dentro” del blog no tuvo problemas para identificar los distintos posts y, posteriormente, poder recopilar información de los mismos; pudiendo incluso extraer el archivo .gitconfig de mi post .gitconfig y realizandole algunas modificaciones, como eliminar la mayoría de los comentarios o unificar una sección que se encontraba duplicada (la de [diff]).

A continuación les dejo un diff entre el .gitconfig original y el modificado por la IA:

--- a/.gitconfig
+++ b/.gitconfig
@@ -1,62 +1,67 @@
 [user]
-    email = ****** # El email que utilizo para github
-    name = iyaki # Usuario coincidiendo con el de github
-    signingKey = ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFsDjKjz0+2nt9YmqETTLNM9PtxfKP/2ihhcj/q27Mtu # Clave pública correspondiente a la clave privada que utiizo para firmar los commits
+    email = tu_email_aqui # Cambia esto por tu email real
+    name = tu_nombre_de_usuario # Cambia esto por tu nombre de usuario de GitHub
+    signingKey = tu_clave_publica # Cambia esto por tu clave pública de SSH

 [core]
-    pager = delta # https://github.com/dandavison/delta Excelente herramienta para mejorar la experiencia al realizar diffs
-    editor = vim # https://xkcd.com/378/
-    autocrlf = input # \r quien te conoce?
-    excludesfile = ~/.gitignore-global # patrones para excluir de manera global
-    untrackedcache = true # https://github.blog/2022-06-29-improve-git-monorepo-performance-with-a-file-system-monitor/
-    fsmonitor = true # https://github.blog/2022-06-29-improve-git-monorepo-performance-with-a-file-system-monitor/
+    pager = delta # Utiliza Delta para mejorar la salida de los diffs
+    editor = vim # Establece Vim como el editor por defecto
+    autocrlf = input
+    excludesfile = ~/.gitignore-global # Utiliza un archivo global para ignorar patrones
+    untrackedcache = true
+    fsmonitor = true

 [color]
-    ui = auto # Colorcitos lindos
+    ui = auto

 [help]
-    autocorrect = prompt # No hay que dejar que la dislexia nos gane
+    autocorrect = prompt

 [diff]
-    colorMoved = default # Diferencia (en los diff) lineas movidas de lineas eliminadas y nuevas
+    colorMoved = default
+    tool = difftastic

 [interactive]
-    diffFilter = delta --color-only # https://github.com/dandavison/delta
+    diffFilter = delta --color-only
+
 [add.interactive]
-    useBuiltin = false # Utilizar delta tambien al ejecutar `git add --interactive` https://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging
+    useBuiltin = false

-[delta] # Mis configuraciones para delta
+[delta]
     navigate = true
     light = false
     line-numbers = true

 [gpg]
-    format = ssh # Formato de la clave utilizada para firmar commits
+    format = ssh
+
 [commit]
-    gpgsign = true # Firmado automático de los commits
+    gpgsign = true
     verbose = true
+
 [tag]
-    gpgsign = true # Firmado automático de los tags
+    gpgsign = true
+
 [gpg "ssh"]
-    allowedSignersFile = ~/.config/git/authorized_signers # Claves publicas consideradas "seguras" para los commits firmados
+    allowedSignersFile = ~/.config/git/authorized_signers

 [init]
-    defaultBranch = main # Branch default
+    defaultBranch = main

 [merge]
-    conflictstyle = diff3 # Mejor resolución de conflictos durante los merge
+    conflictstyle = diff3

-[diff]
-    tool = difftastic # Herramienta alternativa para hacer diffs "estructurales". Cuando la conocí me pareció una idea excelente pero la verdad es que despues nunca la usé
 [difftool]
     prompt = false
+    difftool = true
+
 [difftool "difftastic"]
     cmd = difft "$LOCAL" "$REMOTE"

 [pager]
-    difftool = true # Use a pager for large output, just like other git commands
+    difftool = true

-[alias] # Esto necesita explicación?
+[alias]
     a = add
     b = branch
     c = commit -m
@@ -68,7 +73,7 @@
     dft = difftool
     l = ! git log --show-signature
     lo = ! git log --color --pretty=format:'%Cred%H%Creset - %C(blue)(%G? %GT)%Creset%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'
-    lol = ! git log --color --graph --pretty=format:'%Cred%h%Creset - %C(blue)(%G? %GT)%Creset%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --
+    lol = ! git log --color --graph --pretty=format:'%Cred%h%Creset - %C(blue)(%G? %GT)%Creset%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
     p = push
     psu = push --set-upstream
     pr = pull --rebase --autostash

El comportamiento a la hora de extraer y resumir contenido de cualquier de las páginas en todos los casos fue correcto.

Después de un rato de jugar con el contenido de esta web, le pedí que, utilizando el servicio de Simple Newsletter, me suscribiera a un cierto feed RSS, indicándole además un e-mail para realizar la suscripción.

Ante esta petición, la IA se negó indicando que no le era posible interactuar de esa manera con páginas web y brindando una serie de pasos genéricos para suscribirse a servicios.

Cómo el servicio se consume únicamente realizando una petición HTTP GET, cosa que la IA estuvo haciendo continuamente para acceder al contenido de las distintas páginas de mi sitio web, insistí en que sí podía realizar dicha acción y argumentando que tenía la capacidad de realizar ese tipo de acciones.

Aun así decidió no realizar la petición, pero esta vez sí me dio indicaciones muy precisas de como armar el URI para poder suscribirme.

Yo, por supuesto, no iba a darme por vencido en lograr que la IA realizara la suscripción, por lo que procedí a consultarle por el contenido correspondiente al URI que acababa de proveerme. Esta vez funcionó y ejecutó la suscripción.

Conclusión

El uso de agentes autónomos impulsados por LLM me parece prometedor como una forma de simplificar las aplicaciones y evitar la necesidad de diferentes presentaciones para comunicarse con humanos y otras aplicaciones.

Es evidente que es algo que a día de hoy aún no sería 100% funcional, ya que incluso en unas pruebas tan básicas como las que realice yo tuvo problemas para identificar links cuando se utilizaban patrones un poco menos convencionales en el diseño de la interfaz web (la página principal tiene los links a las demás secciones “desparramadas” y la IA no los identificó adecuadamente; en cambio, cuando los links se encontraban en los títulos de los posts, lo cual es un patrón bastante común, funcionó de maravilla), pero esto se debería poder resolver con el entrenamiento adecuado de sus modelos de lenguaje.

El otro problema que debería resolverse para que el uso de la IA como un Hypermedia Client sea viable es el de la eficiencia. Si bien los tiempos de respuesta fueron aceptables para un uso distendido, es cierto que todas las interacciones requirieron mucho más tiempo del que consumiría cualquier aplicación para realizar una petición HTTP y procesar el contenido de su respuesta.

Esto es todo por hoy, espero que les haya resultado tan interesante como a mí. Como siempre, si quieren conversar al respecto pueden dejar un comentario o contactarme vía e-mail a me@iyaki.ar.

Bye!

Llegaron las Newsletters

02/05/2024

Durante el último mes estuve trabajando en desarrollar una pequeña aplicación web que he bautizado como: Simple Newsletter.

Simple Newsletter es un servicio fuertemente inspirado en Kill the Newsletter (del que ya les hablé en este artículo), pero que hace exactamente lo contrario. Permite subscribirse con una dirección e-mail a un Feed Atom o RSS y recibir las actualizaciones de dicho feed en tu casilla de correo mediante una newsletter.

En lo personal, considero que la practicidad de un buen gestor de Feeds supera ampliamente en comodidad de uso a una Newsletter, pero viendo como este medio de comunicación ha crecido en los últimos tiempos, me pareció que un servicio así podría llegar a ser útil.

Por ahora, la única manera de utilizar el servicio de Simple Newsletter es mediante su API web, pero mi intención es poder seguir mejorando el servicio y, entre otras cosas, agregar una página de inicio que permita a cualquiera subscribirse al feed que desee sin tener que estar escribiendo parámetros en la query string manualmente.

Si bien es un servicio pensado para ser utilizado por usuarios particulares y que cualquiera pueda recibir actualizaciones de los blogs y páginas que le interesan vía correo electrónico, Simple Newsletter también puede ser aprovechado por cualquiera que tenga un blog o página web con un feed Atom o RSS para mantener a sus lectores informados y en contacto agregando un simple formulario (tal y como está funcionando ahora mismo en este blog).

Cómo siempre, espero su feedback al respecto, se trata de un proyecto en muy temprana edad y cualquier sugerencia es más que bienvenida.

Hasta la próxima.

No solo de software vive el hombre

13/02/2025

Usar las herramientas adecuadas para el trabajo adecuado, saber utilizarlas y darles el mantenimiento necesario para que sigan funcionando son formas importantes de aumentar nuestra productividad. Pero existe algo con un impacto mucho más profundo y de mayor magnitud: Tomar las decisiones que más nos acercarán a nuestros resultados deseados. Porque uno puede ser extremadamente rápido para construir un auto, pero si lo que se necesitaba era un barco, de poco servirá todo el esfuerzo que se invierta.

En este aspecto hay dos puntos elementales que nos ayudarán a alcanzar el mayor impacto posible mediante nuestro trabajo.

El primero es conocer cuál es el resultado deseado, en este sentido, por lo general, cuanto más contexto e información tengamos sobre el problema que buscamos solucionar, mejor preparados estaremos para brindar una solución.

El segundo aspecto relevante es poder predecir, de la manera más acertada posible, las consecuencias de nuestras acciones. Para esto podemos optar por opciones poco ortodoxas como el tarot, la bola de cristal o la lectura de la borra del café; o centrarnos en aprovechar lo que otros han estudiado al respecto en el pasado y sus conclusiones. Conclusiones que en muchos casos se han recopilado en leyes, teorías y principios ampliamente conocidos en el ámbito de la gestión y la tecnología.

En este artículo nos centraremos en estas últimas.

Por eso hoy, dejo un breve resumen de las que considero más útiles a la hora de avanzar sobre un proyecto como colaborador individual o como parte de su management.

Principio de Pareto o Regla del 80/20

Durante el siglo XIX el economista italiano Vilfredo Pareto observó que aproximadamente el 80% de los efectos proviene del 20% de las causas.

En el contexto de proyectos de software, este principio cobra una relevancia significativa. Al aplicarlo, nos damos cuenta de que el 80% del valor agregado proviene del 20% de las características o funcionalidades implementadas.

Y entonces, ¿por qué esto es tan relevante para nosotros?

Porque nos ayuda a priorizar.

Si sabemos qué pequeña parte de nuestro trabajo es responsable de la mayoría de los resultados, podemos concentrarnos en eso primero.

Ya sea que estemos trabajando en solitario o en equipo, el Principio de Pareto nos da una hoja de ruta inteligente para maximizar nuestra eficiencia y lograr mejores resultados.

Carga cognitiva

La carga cognitiva no es un principio como tal, pero sí un concepto que, si tenemos en cuenta, puede ayudarnos a nosotros y a nuestros compañeros a obtener mejores resultados.

La carga cognitiva se refiere a la cantidad de esfuerzo mental requerido para realizar una tarea o procesar información.

Imaginemos que estamos trabajando en un proyecto de software y debemos recordar todos los detalles sobre cómo funciona cada parte del código que se está escribiendo. Bueno, esa es la carga cognitiva en acción.
Cuanto más complicado sea el proyecto, más trabajo mental habrá que hacer para mantener todo en orden.

A la hora de programar existen múltiples maneras de disminuir la carga cognitiva que una pieza de código fuente requiere. A mí, en particular, me agradan bastante las sugerencias de Object Calisthenics.

Context Switching

Otro concepto que, a pesar de no tratarse de una ley o principio, puede impactar significativamente en nuestra productividad.

Context switching se refiere al proceso de cambiar nuestra atención y enfoque de una tarea a otra. Este cambio constante de contexto puede ser perjudicial para nuestra productividad, ya que requerimos tiempo y energía para ajustarnos a la nueva tarea.

Y peor aún, aunque la interrupción fuese breve, volver a the zone o the flow puede tomarnos hasta 15 minutos.

Principio de parsimonia o Navaja de Ockham

El Principio de Parsimonia, también conocido como la Navaja de Ockham, es un principio filosófico que sugiere que, entre varias explicaciones posibles para un fenómeno, la más simple suele ser la correcta. Este principio, propuesto por el filósofo y teólogo Guillermo de Ockham en el siglo XIV, aboga por no multiplicar las entidades innecesariamente.

Entonces, en el mundo del desarrollo de software, esto significa que cuando nos encontramos con un problema a resolver (un bug, una nueva funcionalidad a implementar, un desafío a nivel de arquitectura, etc.), deberíamos intentar encontrar la solución más sencilla posible. En lugar de enredarnos con soluciones complejas que pueden generar más problemas, deberíamos seguir el camino más simple y directo.

Dentro del mundo de la programación, esto se encuentra también muy relacionado con los principios YAGNI y KISS.

Ley de Conway

La Ley de Conway viene a recordarnos lo importante que es la comunicación en el desarrollo de software, formulada por el programador Melvin Conway en 1968, establece que las organizaciones que diseñan sistemas están inevitablemente limitadas a producir diseños que sean réplicas de la estructura de comunicación de sus propias organizaciones.

He visto muchas veces artículos y explicaciones que se centran en cómo un equipo con poca organización y falta de comunicación producirá software de baja calidad y que, probablemente, no resuelva necesidades reales. Pero a mí me resulta mucho más interesante tener en cuenta esta ley a la hora de diseñar sistemas y definir su arquitectura.

El impacto de la ley de Conway en la arquitectura de software es muy significativo y es algo que he podido comprobar de primera mano. Hace algunos años y en medio del hype por los microservicios, en la empresa donde trabajaba, nos propusimos a, para sorpresa de nadie, migrar a una arquitectura de microservicios. Los beneficios de esta arquitectura son bien conocidos, y entre ellos destacan:

1. Mejor tolerancia a fallos, al facilitar desacoplar los servicios, permitiendo que una pieza de software fallé sin afectar a las demás.
2. Agnosticismo tecnológico, cada microservicio puede desarrollarse con las tecnologías que considere más apropiadas para lograr su cometido.
3. Mayor independencia a la hora de evolucionar y desplegar cada servicio al poder hacerlo de manera individual.
4. Reusabilidad entre áreas de negocio, si partes de la lógica de negocio se repiten entre distintos procesos y áreas, es posible reutilizar los servicios ya desarrollados.
5. Permite la experimentación y la evolución rápida, al poder ser desarrollados sin comprometer al resto del sistema.

Pero nunca llegamos a beneficiarnos de ellos y es que:

1. Nuestras reglas de negocio, aunque bien definidas, eran bastante complejas y la forma en que el equipo las concibe hace que estén fuertemente acopladas entre sí; por lo que, incluso desarrollando diferentes aplicativos, el nivel de dependencia entre ellos impedía una mayor resiliencia ante fallos de un componente.
2. Todo nuestro equipo tenía experiencia en los mismos lenguajes de programación, por lo que las posibles tecnologías a utilizar eran bastante limitadas.
3. Al haber dependencias tan fuertes entre las distintas reglas de negocio, cualquier cambio terminaba afectando múltiples componentes.
4. Nuestras reglas de negocio, aunque complejas, se mantenían dentro de un alcance bastante acotado, por lo que la reutilización de servicios era muy poco probable.
5. Al tener un equipo conformado, principalmente, por desarrolladores Junior, la experimentación resultaba casi nula.

Y, para empeorar, las cosas, los integrantes del equipo siempre había trabajado de manera muy cercana entre ellos, por lo que no existía un ownership claro sobre procesos o módulos que permitieran la independencia necesaria para desacoplar las distintas piezas de software. Resultando en que los intentos de separar servicios y comunicarlos solo generara confusión y frustración.

Este es un claro ejemplo de cómo un equipo que tenía la capacidad técnica para desarrollar microservicios falló en hacerlo por razones meramente organizativas y comunicacionales.

Para poder implementar exitosamente una arquitectura de microservicios, primero deberíamos haber comenzado por cambiar la forma en que trabajábamos. Armar múltiples equipos (idealmente uno por microservicio) con un alcance y objetivos claros, capacitar a los desarrolladores en nuevas tecnologías, probablemente contratar más colaboradores, etc.

Por suerte, esta migración fue lanzada como una prueba piloto, y notamos todos estas fricciones antes de que se volvieran un problema.

Así, de común acuerdo con el resto del equipo, decidimos volver al esquema monolítico con el que trabajábamos hasta entonces y centrar nuestros esfuerzos en mejorar la estructura y modularidad de nuestra aplicación, en lugar de intentar separar todo de manera artificial y forzada en distintos servicios independientes.

Ley de Parkinson

En 1957 Cyril Northcote Parkinson enunció: el trabajo se expande hasta llenar el tiempo disponible para que se termine.

Al realizar la gestión de un proyecto, ya sea como colaboradores individuales, estimando tareas que deberán realizarse o realizando planificaciones de alto nivel, como Project Manager, siempre es buena idea tener en cuenta esta ley.

Según nos advierte, aumentar “por las dudas” el tiempo que se planifica para dedicar a una cierta tarea puede no ser la mejor idea, ya que terminaremos consumiendo ese tiempo en detalles superfluos y probablemente innecesarios (este es un buen punto en el que aplicar el Principio de Pareto para decidir cuando detenerse) en lugar de aprovechar ese tiempo en adelantar otras tareas que puedan aportar un mayor valor real.

Ley de Brooks

Fred Brooks, en su libro The Mythical Man-Month publicado en 1975, afirma: añadir más personal a un proyecto de software en retraso, lo retrasará más.

Esta es especialmente relevante para los roles de Management y Liderazgo en proyectos de desarrollo de software, ya que antaño era una práctica muy normal el intentar resolver los problemas de un proyecto mediante la adición de más y más colaboradores.

El problema es que, lejos de de generar resultados más velozmente, se produce el efecto contrario; donde la entrega de valor se retrasa aún más, debido a que la comunicación se complejiza de manera exponencial a medida que se agregan personas y se requiere tiempo adicional para capacitar a estas nuevas incorporaciones y transferirles todo el contexto necesario.

Ley de Hofstadter

Esta ley describe la dificultad de estimar el tiempo que llevará completar tareas de gran complejidad acuñada por Douglas Hofstadter en su libro Gödel, Escher, Bach: an Eternal Golden Braid afirma: Siempre nos lleva más tiempo de lo esperado, incluso teniendo en cuenta la ley de Hofstadter.

Sobre esta creo que no hay mucho que agregar, pero conocerla es una buena forma de recordar que la estimación de tareas siempre cuenta con su cuota de incertidumbre.

Teoría de las ventanas rotas

Esta teoría proviene de la criminología. Introducida en un artículo de 1982 por los científicos sociales James Q. Wilson y George L. Kelling y popularizada en la década de 1990, sostiene que los signos visibles de la delincuencia, el comportamiento antisocial y los disturbios civiles crean un entorno urbano que fomenta la delincuencia y el desorden, incluidos los delitos graves; sugiriendo que los métodos policiales que se centran en atacar los delitos menores, como el vandalismo, la vagancia, el consumo de alcohol en público, el cruce incorrecto de peatones y la evasión de tarifas, ayudan a crear una atmósfera de orden y legalidad.

Esta idea es portada en 1999 al ámbito de la programación por Andy Hunt y Dave Thomas en su libro The Pragmatic Programmer, donde aplican el concepto de las ventanas rotas a la calidad de software.

En su libro, sugieren nunca dejas las ventanas rotas sin arreglar y repararlas en cuanto se las identifica. Evitando así esparcir malas prácticas al resto del código fuente.

Considero esto particularmente importante cuando un equipo cuenta con una gran cantidad de desarrolladores Junior, ya que es mediante el mismo código fuente sobre el que están trabajando que, día a día, siguen aprendiendo cómo programar. Sin embargo al ser una práctica que depende en gran medida de la cultura del equipo (y del área o la empresa donde esté trabajando ese equipo) puede ser un desafío notable implementar prácticas que fomenten la reparación constante de estas ventanas rotas.

Principio de Hanlon

El Principio de Hanlon (o navaja de Hanlon) no trata de manera directa sobre productividad pero es una herramienta que puede ayudarnos a lograr mejores resultados cuando se trabaja en conjunto.

Este principio establece: Nunca atribuyas a la maldad lo que se explica adecuadamente por la estupidez.

Me gusta porque es simple y pragmático, y nos invita a darle a las personas el beneficio de la duda. Recordándonos que muchas veces un conflicto que estemos teniendo con otras personas puede ser producto, simplemente, de un malentendido.

Redondeando

Esas fueron la leyes, principios y conceptos que, a mi parecer, resultan mas útiles a la hora de participar en un proyecto software.

Espero que les puedan ser de utilidad también a ustedes.

Si quieren charlar sobre este o cualquier otro tema siempre pueden contactarme via e-mail o dejar un comentario (Me olvidé de avisar eso! Ahora hay una sección de comentarios al final de los posts 😁).

До побаченія!

.gitconfig

24/02/2024

Continuando con la temática de herramientas y productividad, y envalentonado por el post de Julia Evans: Popular git config options, hoy quiero compartir con ustedes mi configuración de git.

# ~/.gitconfig

[user]
    email = ****** # El email que utilizo para github
    name = iyaki # Usuario coincidiendo con el de github
    signingKey = ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFsDjKjz0+2nt9YmqETTLNM9PtxfKP/2ihhcj/q27Mtu # Clave pública correspondiente a la clave privada que utiizo para firmar los commits

[core]
    pager = delta # https://github.com/dandavison/delta Excelente herramienta para mejorar la experiencia al realizar diffs
    editor = vim # https://xkcd.com/378/
    autocrlf = input # \r quien te conoce?
    excludesfile = ~/.gitignore-global # patrones para excluir de manera global
    untrackedcache = true # https://github.blog/2022-06-29-improve-git-monorepo-performance-with-a-file-system-monitor/
    fsmonitor = true # https://github.blog/2022-06-29-improve-git-monorepo-performance-with-a-file-system-monitor/

[color]
    ui = auto # Colorcitos lindos

[help]
    autocorrect = prompt # No hay que dejar que la dislexia nos gane

[diff]
    colorMoved = default # Diferencia (en los diff) lineas movidas de lineas eliminadas y nuevas

[interactive]
    diffFilter = delta --color-only # https://github.com/dandavison/delta
[add.interactive]
    useBuiltin = false # Utilizar delta tambien al ejecutar `git add --interactive` https://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging

[delta] # Mis configuraciones para delta
    navigate = true
    light = false
    line-numbers = true

[gpg]
    format = ssh # Formato de la clave utilizada para firmar commits
[commit]
    gpgsign = true # Firmado automático de los commits
    verbose = true
[tag]
    gpgsign = true # Firmado automático de los tags
[gpg "ssh"]
    allowedSignersFile = ~/.config/git/authorized_signers # Claves publicas consideradas "seguras" para los commits firmados

[init]
    defaultBranch = main # Branch default

[merge]
    conflictstyle = diff3 # Mejor resolución de conflictos durante los merge

[diff]
    tool = difftastic # Herramienta alternativa para hacer diffs "estructurales". Cuando la conocí me pareció una idea excelente pero la verdad es que despues nunca la usé
[difftool]
    prompt = false
[difftool "difftastic"]
    cmd = difft "$LOCAL" "$REMOTE"

[pager]
    difftool = true # Use a pager for large output, just like other git commands

[alias] # Esto necesita explicación?
    a = add
    b = branch
    c = commit -m
    ca = commit --amend --no-edit
    cl = clean -fd .
    co = checkout
    d = diff
    dd = difftool
    dft = difftool
    l = ! git log --show-signature
    lo = ! git log --color --pretty=format:'%Cred%H%Creset - %C(blue)(%G? %GT)%Creset%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'
    lol = ! git log --color --graph --pretty=format:'%Cred%h%Creset - %C(blue)(%G? %GT)%Creset%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --
    p = push
    psu = push --set-upstream
    pr = pull --rebase --autostash
    r = reset
    s = status
    td = tag --delete
    tdr = push --delete

Adicionalmente, esta es mi configuración de exclusiones globales (excludesfile)

# ~/.gitignore-global

.*.sw? #Vim swap file
.directory
.vscode

Esta era mi configuración de git desde hace ya unos años y hasta hace unos pocos días, cuando, en base al artículo que les compartí al principio del post decidí hacer los siguientes cambios y adiciones:

[merge]
    conflictstyle = zdiff3 # Mejor x2 resolución de conflictos durante los merge

[rerere]
    enabled = true
[push]
    default = current
[rebase]
    autostash = true
[transfer]
    fsckobjects = true
[fetch]
    fsckobjects = true
[receive]
    fsckObjects = true
[status]
    submoduleSummary = true
[branch]
    sort = -committerdate
[log]
    date = iso

Estas nuevas configuraciones se ven prometedoras, pero aún no he tenido suficiente tiempo para probarlas a fondo.

Esto es todo por hoy, espero que puedan aprovechar alguna de estas configuraciones para mejorar sus propios flujos de trabajo.

Пока́!

Breaking Changes

23/01/2024

Si utilizan RSS para seguir los artículos que escribo en mi blog personal, es posible que a fines del 2023 se hayan encontrado con este post en el que comento algunos cambios importantes sobre mis feeds RSS, que acompañan la migración de mi sitio web a eleventy.

Hoy vengo a contar un poco sobre como estoy gestionando estos cambios en las URIs de las distintas páginas de mi website, siempre con el objetivo de mantener la mayor retrocompatibilidad posible, evitando así breaking changes.

Al migrar a eleventy decidí hacer caso a los consejos de Cool URIs don’t change y eliminar la extensión .html de las URIs de mis páginas (el cual es ademas el comportamiento predeterminado de eleventy). Inmediatamente, comencé a buscar una manera de mantener las antiguas URIs funcionando.

Como soy una persona de bien, que respeta el protocolo HTTP, mi primera intención fue configurar redirecciones (301 - Moved Permanently) para que todas las direcciones antiguas redirigiesen de forma automática a las nuevas y el cambio en las URIs fuese explícito y visible para los visitantes de mi web. Esta era la opción más adecuada, pero, al parecer, Github Pages (hosting que utilizo para mi website) no tiene soporte para configurar redirecciones más allá del clásico 404 - Not Found.

Fue entonces cuando revisando los directorios y archivos de mi sitio descubrí cuál sería la primera solución que implementaría: No hacer nada. ¿Nada? ¡Sí, eso mismo!

El proceso de deploy de este sitio es extremadamente simple, se basa en copiar archivos de un directorio a otro. Y como todos los archivos que eleventy había generado, tenían rutas distintas a los originales, la primera solución resultó ser seguir sirviendo los antiguos archivos en sus URIs originales, teniendo así duplicados de muchas de mis páginas.

Esto servía para salir del paso, pero no me terminaba que convencer como solución, ya que, más pronto que tarde, estos duplicados comenzarían a diferir en contenido, generando inconsistencias. Entonces, me embarqué en la búsqueda de una solución más elegante y sostenible, la cual aún no encuentro.

Pero esto no significa que no haya mejorado la solución original.

Actualmente, he cambiado las copias de las páginas por enlaces simbólicos (symlinks, para los amigos). Los enlaces simbólicos me permiten tener una única versión de cada página, pero mantener accesibles las antiguas URIs. Esto solo resuelve el problema de la consistencia, ya que el cambio en las URIs sigue sin hacerse visible para los visitantes. Otro problema que todavía mantiene esta solución es el de la canonicidad de las páginas, al haber múltiples URIs para un mismo contenido, los motores de búsqueda como Google no saben cuál deberían sugerir en los resultados porque sus bots no tienen manera de saber que una de las direcciones corresponde a un enlace simbólico.

Este problema con los motores de búsqueda, de momento, lo estoy resolviendo, incluyendo, en todas las páginas, tags HTML del estilo: <link rel="canonical" href="https://iyaki.ar/blog/"> lo que, según Google debería resolver el problema.

Aún no termino de decidir si eventualmente debería dar de baja las direcciones antiguas de manera definitiva (Opción tentadora para simplificar el mantenimiento, sobre todo teniendo en cuenta que esta web es bastante joven y las posibilidades de que haya enlaces de terceros a sus páginas aún son muy bajos) es por esto que, de manera cautelar, he agregado en la página de 404 un script JS del Internet Archive que permite recomendar automáticamente páginas web guardadas con anterioridad en su base de datos en caso de no existir la dirección solicitada.

Además, aprovechando esta posibilidad que brinda WayBack Machine del Internet Archive, para asegurarme de que mis posts y páginas queden almacenados, en el Github Action que se encarga de realizar las publicaciones agregué una sección para respaldar automáticamente el contenido de mi sitio web mediante la API REST que exponen.

Esto es todo por ahora, si tengo novedades sobre esta migración, sus ventajas y desafíos los verán en mis posts.

Au revoir!

Actualizaciones

Durante mayo del 2024, después de varios meses de haber implementado WayBack Machine y comprobar su correcto funcionamiento he decidido, eliminar los enlaces simbólicos.

Esto se debe, principalmente, a que la generación de estos enlaces simbólicos complejizaba el nuevo proceso de deploy de este sitio web.

También como consecuencia de los cambios del proceso de deploy fue necesario cambiar el proceso de archivado de las páginas en WayBack Machine del Internet Archive que ahora se realiza en un Github Action independiente y utiliza una pequeña aplicación que desarrollé para archivas páginas a partir de un sitemap.

Conoce tus herramientas

21/01/2024

Este post se centrará sobre una de las formas que considero más importantes para lograr ser productivo, especialmente, como colaborador individual: Conocer nuestras herramientas de trabajo en profundidad.

Los seres humanos contamos con un único recurso universal e inmutable. Nacemos con él y morimos cuando finalmente se nos acaba. A diferencia de otras aptitudes que también podríamos considerar recursos como la fuerza o la inteligencia, las cuales pueden entrenarse para mejorar en el transcurso de nuestras vidas, este recurso en particular no es renovable ni podemos aumentarlo: nuestro tiempo.
Nuestro tiempo es limitado y valioso, por lo que es normal querer asegurarnos de aprovecharlo al máximo. Pero aunque no exista manera de contar con más de 24 horas en un día, sí tenemos el poder de utilizar ese tiempo de manera más eficiente, generando un mayor valor agregado o impacto con el tiempo que dedicamos a ciertos objetivos.

A diferencia de otras áreas o rubros donde una mayor destreza física (por ejemplo, fuerza o velocidad) pueden derivar en una mayor productividad, en IT este no suele ser el caso. Es verdad que, por ejemplo, practicando mecanografía, un programador puede aumentar la cantidad de líneas de código que escribe por minuto, pero estrategias de este estilo suelen ser mucho menos efectivas que buscar formas de escribir menos código, en lugar de escribir más rápido.
En mi opinión, debemos aspirar más a ser artesanos experimentados que trabajan con precisión y meticulosidad sin dar una sola cincelada de más; en lugar de buscar convertirnos en fábricas de producción masiva.

Es aquí donde entran en juego nuestras herramientas, y el conocerlas para saber cuál se adecúa mejor a cada una de nuestras necesidades y como utilizarlas para aprovecharlas al máximo.

¿Cuales son nuestras herramientas?

Todo el software que utilizamos es parte de nuestra caja de herramientas. Desde el sistema operativo que ejecuta nuestra máquina, hasta el editor de texto o IDE en el que escribimos nuestro código e incluso los propios compiladores o interpretes de los distintos lenguajes de programación que utilizamos.

También los frameworks y bibliotecas que utilizamos son parte de nuestra caja de herramientas, y aunque el resto de este post no se centra en ellos, vale la pena mencionar su importancia ya que, conocerlos y entender las posibilidades y facilidades que nos brindan así como sus limitaciones es otra excelente manera de aumentar nuestra productividad a la hora de programar.

Aspectos esenciales

A mi entender, hay algunos aspectos transversales a casi todas las herramientas informáticas que resultan claves para aumentar nuestra eficiencia. Estos son:

• Configuraciones
• Atajos de teclado
• Respaldos y Sincronización

Configuraciones

La mayoría del software dispone de distintas opciones y configuraciones que, dependiendo de nuestras tareas diarias, experiencia y preferencias personales, pueden simplificar nuestro trabajo.

Siempre es recomendable al utilizar una nueva herramienta, dedicar un tiempo a leer su documentación y explorar sus distintas opciones y configuraciones. Esto nos permitirá tener, por lo menos, una idea general sobre las posibilidades que ofrece para poder, a medida que la utilicemos, realizar los ajustes necesarios para poder trabajar de la manera que nos resulte más cómoda, práctica y productiva.

Atajos de teclado

Es muy común que los sistemas operativos y programas que utilizamos cuenten con múltiples atajos de teclado para realizar distintas acciones. La cantidad de teclas que podemos combinar para conseguir distintos resultados es realmente inmensa y no tiene ningún sentido intentar memorizar absolutamente todos los atajos de teclado de los que disponemos, pero sí, puede ahorrarnos bastante tiempo el aprender los atajos correspondientes a las acciones que realizamos con más frecuencia.

Respaldos y sincronización

La mayoría del software incluye alguna opción para crear backups, puntos de restauración o por lo menos realizar exportación de sus configuraciones. Es importante conocer estas opciones y utilizarlas.

Inevitablemente, en algún momento, vamos a romper nuestro ordenador. Pueden ser hoy, mañana o dentro de tres años. Puede ser intentando ajustar configuraciones para que la computadora funcione de manera más fluida, puede ser intentando crackear un juego o puede ser que nuestro gato camine arriba del teclado. Ni el momento ni la razón importan. Lo importante es que va a pasar. Y por eso debemos estar preparados para restaurar nuestro equipo a un estado en el que sea utilizable con la mayor rapidez, posible.

Mejor aún si además de crear estos respaldos tenemos alguna herramienta que nos permita almacenarlos en la nube o incluso sincronizar nuestras configuraciones entre dispositivos.

Menciones de honor

A continuación voy a dejar un repaso rápido sobre los aspectos que acabamos de discutir sobre algunas de las herramientas que más utilizo (y, por lo tanto, en las que valor me aporta el aumentar la eficiencia)

Sistema Operativo

No creo que nadie se sorprenda de ver el sistema operativo primero en la lista. ¿Es una obviedad que es importante saber usar una computadora? Sí. ¿Me va a volver más productivo por ser un Power User y conocer cada posible configuración de mi sistema operativo? No.

En el apartado de configuraciones lo que considero más relevante es conocer:

1. La estructura de directorios (carpetas, si son usuarios de Windows).
2. Cómo visualizar archivos y directorios ocultos.
3. Sistema de permisos.
4. PATH (Si van a programar esto es mucho muy importante).

Sobre esta base se pueden seguir incorporando otros elementos que ayuden a organizarse mejor como, por ejemplo, el uso de múltiples escritorios o workspaces.

¿Atajos de teclado? Muchísimos. Solo voy a dejar las listas de atajos de algunos de los sistemas operativos más comunes. Queda a criterio de cada uno decidir cuales les resultaran más útiles.

• Atajos de teclado Windows
• Atajos de teclado Ubuntu
• Atajos de teclado KDE (Ya sé que no es un sistema operativo como tal, ¿pero a quién le importa?)
• Atajos de teclado Mac

En cuanto a los respaldos, los sistemas operativos suelen incluir alguna solución nativa para realizar respaldos.

Adicionalmente, a mí me gusta utilizar git para versionar las configuraciones y documentos más importantes. Es algo bastante simple de realizar en GNU Linux, pero desconozco que tan efectivo sería esto en Windows.

Y para mantener backups en la nube yo utilizo el servicio de Mega.

Terminal (Consola)

En mi día a día yo suelo utilizar KDE Neon, una distribución de GNU Linux y, probablemente por costumbre más que por otra razón, mi terminal preferida es Bash, pero los puntos que voy a mencionar aplican a cualquier otra shell (Z shell, Fish shell, etc) o (al menos la mayoría) incluso a consolas de Windows como Powershell o el inmortal “cmd” .

Las terminales son herramientas de los más versátiles y sus opciones de configuración son prácticamente infinitas, pero entre todo lo que se puede configurar, personalmente, destaco:

Alias

s posible asignar un alias a una comando largo y complicado (incluso con flags o argumentos predefinidos) para simplificar su uso.

Funciones

Si un alias se queda corto para simplificar la ejecución de una tarea, siempre podemos definir funciones personalizadas (pequeños programas) que realicen una serie de comandos específicos.

Autocompletado

Muchas aplicaciones de CLI cuentan automáticamente con autocompletado de argumentos, pero para las que no, es posible definir un script o configuración que permita el autocompletado de forma personalizada.

# git checkout remote
# For usage, execute `gcr` without any argument
function gcr() {
    local REMOTE='origin'

    if [ -z "${1}" ]
    then
        echo "gcr creates a new branch based on an ${REMOTE} branch.
If the branch already exists it is overwritten.

Usage:
    gcr <${REMOTE} base branch> <name-for-new-branch>
Example:
        gcr development new-feature
    will result in the creation of the branch development_new-feature
    tracking ${REMOTE}/development
"
        return
    fi

    git fetch -t -P "${REMOTE}" &&

    local BRANCH_NAME='' &&

    if [ -z "$2" ]
    then
        BRANCH_NAME="${1}"
    else
        BRANCH_NAME="${1}_${2}"
    fi &&

    git checkout -t "${REMOTE}/${1}" -B "${BRANCH_NAME}"
}
# gcr bash completion
function __remote_branch_completion() {
    local REMOTE_BRANCHES="$(__git_remote_heads)"
    COMPREPLY=($(compgen -W "${REMOTE_BRANCHES//'origin/'/}" "${COMP_WORDS[1]}"))
}
complete -F __remote_branch_completion gcr

Ejemplo de función bash que simplifica el comando git checkout para crear y cambiar a una nueva rama basada en una rama remota específica y la configuración de su autocompletado.

Las terminales también cuentan con atajos de teclado que pueden resultarnos de los más útiles.

Visual Studio Code

Otra herramienta con una cantidad enorme de configuraciones y atajos, además de la posibilidad de sincronizar estas entre dispositivos.

En cuanto a sus configuraciones sugiero revisarlas minuciosamente, la manera de hacer esto que a mí me resulta más práctica es:

1. Presionamos la combinación de teclas Ctrl+Shift+p para abrir la barra de comandos.
2. Escribimos Preferences: Open User Settings (JSON) y pulsamos Enter. Esto nos abrirá un archivo JSON donde podemos definir nuestras configuraciones personalizadas.
3. Comenzaremos agregando: "workbench.settings.useSplitJSON": true. Esto nos permitirá ver, a la vez, las configuraciones que nosotros hayamos definido y todas las configuraciones disponibles (incluidas las correspondientes a extensiones) con sus valores por defecto.

De este modo, podemos explorar todas las opciones y ajustarlas según nuestras necesidades.

De manera similar con Preferences: Open Keyboard Shortcuts podemos revisar todos los atajos de los que el Visual Studio Code dispone, asi como configurar nuestros propios atajos personalizados.

Git

Lean la documentación de git. Sus configuraciones son muchas y de los mas variadas, permite la creación de aliases y personalizar muchos de sus comportamientos con herramientas de terceros como delta

Próximamente

Hasta aquí llega el post de hoy. Próximamente espero poder compartir algunas de las configuraciones que mas aprovecho en mi día a día.

¡Hasta pronto!

Sobre el Governace Crew en esquemas unFIX

10/12/2023

Este artículo fue escrito a lo largo de varios meses y mis ideas respecto a unFIX han ido mutando durante todo este tiempo. Este post busca reflejar la transformación que fueron sufriendo esas ideas. Si en algún punto encuentran inconsistencias o notan que algo se vuelve confuso, por favor háganmelo saber. Cualquier aporte es más que bienvenido y voy a estar encantado de poder dialogar sobre este tema. Como siempre pueden contactarme a: me@iyaki.ar.

Introducción

UnFIX es un proyecto relativamente nuevo y como tal evoluciona constantemente. Lo descubrí hace varios meses y desde entonces lo he seguido desde cerca. Sin embargo, hasta hace poco, y sin que me percatara, estaba ignorando uno de sus conceptos (en mi opinión) más poderosos.

El objetivo de este artículo no es brindar una introducción al modelo, sino ahondar en algunos de sus aspectos, por lo que si no están familiarizados con unFIX les recomiendo estos dos excelentes artículos introductorios de Javier Garzas:

• Innovador modelo de escalado o un refrito gourmet parte I.
• Innovador modelo de escalado o un refrito gourmet parte II.

O bien, que vayan al primer post del blog de unFIX o a su explicación “oficial” y luego sigan recorriendo las distintas secciones del website.

Mi motivación

Actualmente, trabajo como director del área de Producto y Tecnología de una empresa enfocada en proveer un SaaS dirigido a la industria de la salud. Es por esto que siempre me encuentro buscando nuevas formas de mejorar los procesos y la organización para ser más eficientes. Y en ese sentido, desde el comienzo, unFIX me pareció una forma innovadora de organizar el equipo de personas que trabaja conmigo.

Las responsabilidades de mi rol incluyen todo lo relativo al diseño, desarrollo y mantenimiento de nuestro SaaS, así como los temas relacionados con RR.HH. del plantel del área de Producto, evaluaciones de desempeño, coaching o acompañamiento en el desarrollo profesional.

Cuanto más leía respecto al modelo unFIX más convencido me encontraba de que podía aportarnos valor y ayudarnos a seguir creciendo.

Aunque algunos de sus conceptos podían aplicarse de manera aislada dentro del área de Producto, estaba convencido de que el mayor valor que tenía para aportar se encontraba en la implementación del modelo en toda la compañía. Pero al intentar convertir toda la empresa al modelo unFIX siempre había un aspecto que no podía terminar de acomodar: El management.

Este es un organigrama aproximado del esquema de trabajo que manejamos actualmente (que probablemente sea vea similar al 90% de los organigramas de cualquier empresa pequeña o mediana).

Lo más natural (al menos para mí), en una primera aproximación, fue pensar una migración al modelo unFIX de la siguiente manera:

En esta migración, tanto los puestos C-Level, como los de dirección, pasan a conformar el Governance Crew.

Y hasta acá todo parecía funcionar. Sobre el papel, las piezas encajan. Todo puede ser modelado según las reglas de unFIX. Pero aún sentía que había algunos puntos que definir antes de poder implementar este nuevo esquema. Principalmente en lo que respecta al management. Suena tentador (por lo fácil que sería) mantener la separación de responsabilidades dentro del personal que forma el Governance Crew igual que hasta ahora. Pero también se siente poco natural al observar el nuevo “organigrama” y ver que no existen separaciones fuertes de cara al resto de los Crews respecto a las responsabilidades de cada uno de los integrantes del Governance Crew.

UnFIX propone algunos lineamientos en cuanto a como debería funcionar el management, un resumen de estos lineamientos sería:

1. El trabajo de “gestionar gente” solo puede ser realizado por aquellos con el rol de Chief.
2. Solo los Chief pueden ser People managers de otras personas.
3. Los Chief únicamente pueden reportar ante otros Chief.
4. Los Chief son, en última instancia, responsables por todo lo que ocurra en la Base.
5. El rol de Chief solo existe dentro del Governance Crew.
6. El Governance Crew suele estar compuesto por múltiples Chief.
7. El Governance Crew es el encargado de asegurar la motivación del resto de las personas.
8. El Governance Crew es el responsable del negocio frente a los stakeholders externos.
9. El Governance Crew define el propósito de la Base.
10. Existe un único Governance Crew por Base.

Son buenos lineamientos pero muy generales. Por lo que, me dispuse a agregar algunas reglas más para “ordenar” un poco el equipo en nuestro caso particular.

Así comencé a pensar distintas maneras de separar las responsabilidades de los integrantes del Governance Crew. Y llegué a múltiples opciones, algunas de ellas fueron:

• Gobernanza por Perfil: Definir un Chief en el Governance Crew por cada área o función específica dentro de la organización, como por ejemplo, un Chief de Marketing, un Chief de Recursos Humanos, etc.
• Gobernanza por Value Stream: Separar las responsabilidades del Governance Crew según los diferentes flujos de valor de la organización, lo que implicaría tener un Chief encargado de cada uno de ellos, como por ejemplo, un Chief del proceso de producción, un Chief del proceso de ventas, etc.
• Gobernanza por Investment Horizon: Dividir las responsabilidades del Governance Crew según los diferentes Investment Horizon en los que se enfoca la organización.
• Gobernanza por entropía: Tirar dados para decidir como separar las responsabilidades de los miembros del Governance Crew. Aunque es la opción menos seria de todas las que pude pensar, finalmente me pareció igual de arbitraria que cualquiera de las anteriores.

Además, al reflexionar en como sería un día normal de trabajo con cualquiera de estas nuevas estructuras, no puedo evitar sentir una sensación de inconformidad al profundizar en algunos detalles.

Cuanto más intentaba encontrar una respuesta que me satisficiera, más me alejaba de las opciones de gobernanza que había pensado, y es que en múltiples artículos del blog de unFIX (Manage the System, Lead the People, How Do We Keep the Business Agile and Aligned?, Middle Managers Should Stop Coordinating ) y algunos recursos externos quedaba bastante claro que el enfoque que estaba dando al trabajo que debía realizar el Governance Crew era incorrecto y gran parte de las responsabilidades de dirección que hoy cubro no tenían lugar en el Governance Crew.

El problema

Mi trabajo ya no existía.

O mejor dicho, para seguir las directivas del modelo unFIX mi puesto de Middle Management no debía existir.

En una primera instancia darme cuenta de esto fue un shock importante. También fue el punto en que dejé este artículo sin terminar durante bastante tiempo y pensé en abandonar mi proyecto de implantación del modelo unFIX en mi trabajo.
Pero a media que pasaron los días y las semanas, al seguir dándole vueltas al asunto, y buscando más información sobre el tema, finalmente, todas las piezas encajaron.

La revelación

Aunque mi puesto no pudiese existir como lo había hecho hasta ahora, eso no tenía por qué cambiar mi rol o responsabilidades como individuo. Y es que unFIX contempla la posibilidad de participar en múltiples equipos a la vez, así como distintos Participation Levels, Time commitments y la existencia de Facilitation crews. Mis responsabilidades y todo lo que disfruto de mi trabajo seguían ahí, pero ya no englobadas en un único puesto.

Esto permite tomar decisiones sobre la base y su funcionamiento, como parte de los miembros del Governance Crew, pero también seguir participando en el coaching de otros colaboradores como parte de un Facilitation Crew o colaborar en distintos equipos y proyectos de manera más flexible.

La posibilidad de participar en múltiples equipos es, en mi opinión, una de las características más interesantes y liberadoras del modelo unFIX. Y una de las que más lo diferencia de la mayoría de los frameworks Agile que prohíben esta práctica y buscan equipos lo más estables posible. Es cierto que esta estabilidad tiene sus ventajas, pero dependiendo de factores como el tamaño de la organización o la velocidad a la que cambian los objetivos puede no ser la opción más beneficiosa.

¿Conclusión?

Actualmente, estamos trabajando en adaptar nuestra organización interna a un modelo más fluido y fuertemente influenciado por las propuestas de unFIX, pero es una labor que apenas estamos comenzando, por lo que hoy no podría brindar una conclusión sobre las ventajas, desventajas o desafíos que esto nos presente. Espero tener noticias al respecto pronto para poder compartirlas.