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:
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.
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.
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.
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).
Ayer estaba revisando un script desarrollado por un compañero y me llamó la atención la manera en la que solucionaba un problema “habitual”: ¿cómo añadir una línea a un fichero sólo si no está ya presente?
El functional options pattern permite crear un objeto con un número arbitrario de “opciones” manteniendo siempre la signature de la función que lo crea.
La idea original fue propuesta, si no estoy equivocado, por Dave Cheney allá por 2014 en el artículo Functional options for friendly APIs. El artículo muestra múltiples maneras de atacar el problema y cómo las functional options es una de la soluciones más sencillas.
Imagina que quieres crear un objeto pizza. Pero no todo el mundo quiere la misma pizza; unos quieren masa fina, con extra de queso o con peperoni y champiñones, otros masa normal sin ningún extra o topping adicional, etc.
¿Cómo defines la función NewPizza para que puedas satisfacer a todos tus clientes? Tampoco quieres tener que cambiar la función cada vez que se añada una nueva opción o ingrediente a la pizza…
La solución son las funcional options.
Actualización: 26/12/2023
Algunos aspectos de este artículo quizás no están del todo bien explicados; por ejemplo, las propiedades en config están en mayúsculas (exportadas), por lo que se puede establecer sin necesidad de functional options. La signatura de la función NewClient es incorrecta, pues no incluye que devuelve (*DBClient, error)… En vez de corregirla, he creado una entrada más concisa y sin errores conocidos, al menos por ahora.
