Photo by Mabel Amber
Durante estos pasados días de vacaciones por Navidad han confluido varias casualidades que me han hecho probar, por primera vez, Neovim.
Neovim es un refactor de Vim, en el que se han dejado las partes que más le gustan a la comunidad y se han añadido capacidades que lo convierten en un editor moderno, como la extensibilidad a través de plugins.
Hace un tiempo escribí una artículo sobre el patrón de functional options: Patrón de ‘functional options’.
En este entrada reviso alguno de los errores que cometí al redactarla.
En la entrada anterior mencionaba cómo usar una plantilla para homogeneizar los commits.
Además de la plantilla, usar Conventional Commits permite dotar de un formato standard a los commits. La buena gente de Charm ofrece como parte del tutorial para aprender a usar Gum un script con el que redactar conventional commits.
En esta entrada, ofrezco una versión ampliada que incluye la descripción para cambios que rompen la retrocompatibilidad.
Git proporciona la opción de establecer un fichero como plantilla para los commits de Git.
Cuando defines una plantilla para los commits, al ejecutar git commit, el editor que tengas configurado para componer el mensaje de commmit carga automáticamente la plantilla que hayas definido.
Ni que decir que usar una plantilla para todos los commits ayuda a homogeneizar los mensajes en el repositorio y es una configuración esencial en equipos de trabajo.
Llevo aproximadamente una año y medio en un proyecto de lo más interesante, pero de esos que “nadie ve”; junto a mis compañeros, diseño, implmento y mantengo una “landing zone”.
Cada uno de los principales cloud providers tienen su propia definición al respecto de lo que es una landing zone:
De la definición de Google:
A landing zone, also called a cloud foundation, is a modular and scalable configuration that enables organizations to adopt Google Cloud for their business needs. A landing zone is often a prerequisite to deploying enterprise workloads in a cloud environment.
Y yo me estoy montando la mía (sin tener un cloud provider).
Ayer en el trabajo, de alguna manera se nos notificó que teníamos disponible la actualización a Sonoma para el Mac.
He ido actualizando mi Mac personal desde hace más de diez años (sí, todavía uso mi Macbook Air Mid 2013) sin ningún problema. Así que que no creía que esta vez fuera diferente. Lo que sí es diferente es que ésta vez el Mac a actualizar el mi “equipo de empresa”.
De la actualización en sí fue, como esperaba, no hay nada que destacar… Le di a actualizar y al volver de comer ya estaba todo listo.
A partir de ahí, ha empezado la pesadilla.
Para desplegar un clúster mono-nodo de Kubernetes usando K3s, he clonado una máquina virtual con Ubuntu Server 22.04 LTS que uso como “golden image”.
Una de las tareas que realizo sobre la máquina clonada es la de configurar una IP estática, pero siempre tengo que buscar cómo realizar esta configuración en Google, ya que nunca lo recuerdo.
El objetivo de esta entrada es servirme de recordatorio para el futuro.
En una entrada anterior (Usa un contenedor como entorno de desarrollo con ‘devcontainers’) explicaba cómo usar un contenedor y Devcontainers para suplir las carencias de MacOS con respecto a Bash.
Desde entonces uso Devcontainers más y más; por ejemplo, para desarrollar en Go ya no tengo que levantar una máquina virtual o instalar Go en mi equipo: genero un fichero devcontainer.json, indico la imagen oficial de Go y ¡listo!
No todo es perfecto; una de las cosas que últimamente estaba sufriendo es que Git no autocompleta, por ejemplo, los nombres de las ramas.
La solución a la que siempre acabo acudiendo (y ejecutando manualmente) es Autocomplete Git Commands and Branch Names.
Pero claro, yo quería automatizarlo ;)
Así que hoy explico cómo he conseguido incluir el autocompletado de Git directamente al arrancar un devcontainer.
Uno de los problemas que he encontrado en mi reinterpretación de la API que uso en el trabajo ha sido la conexión con la base de datos.
Siguiendo las buenas prácticas, mi intención era reutilizar el cliente a la base de datos. En vez de usar una variable global, que suele ser la aproximación recomendada, guardaba la struct en el contexto de Gin.
Sin embargo, el contexto se propaga para una misma petición, pero no se mantiene entre peticiones… Así que para cada nueva petición que recibía la API se creaba un nuevo client 😞.
Todo lo relacionado con la base de datos se encuentra en su propio paquete, por lo que tendría sentido crear una variable “global” dentro del paquete…
Sin embargo, seguía quedando pendiente el tema de cerrar la conexión con la base de datos al finalizar la aplicación…
En esta entrada explico la solución que quiero probar (ya veremos si funciona 😉, parece que sí).
Apple no incluye versiones modernas de Bash; la versión incluida por defecto es 3.2. Esto se debe a que a partir de esta versión la licencia que cubre Bash es la GPLv3 y ésta obliga a compartir el código fuente, cosa que Apple no quiere hacer.
El caso es que ahora uso un Mac M2 para el trabajo y algunas funcionalidades como los arrays asociativos (name["dog"]="snoopy"), sólo están disponibles en Bash v4 o superior.
La solución más obvia, actualizar Bash manualmente en el Mac, es posible pero tiene inconvenientes. El Bash “nativo” de Mac OS se encuentra en /usr/bin, mientras que otra versión de Bash, sólo puede ser instalada fuera de /usr/bin, porque el Mac usa algo llamado System Integrity Protection, que evita la ejecución de código no autorizado. Aunque SIP puede deshabilitarse, no es una buena idea.
Dado que en Bash nuestros scripts usan el shebang #!/bin/bash (ver Shell Style Guide de Google), al ejecutar el script en Mac OS, se usaría Bash 3.2 y no la nueva versión (p.ej, Bash v5).
