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.
Desde hace unos días he empezado a usar de forma exclusiva un teclado Magic Keyboard, tanto con mi equipo de trabajo (un Mac) como con el personal (con Linux - Pop!_OS).
Como el teclado no incluye una tecla dedicada PrtSc, en esta entrada indico cómo asignar una combinación de teclas en Pop!_OS para realizar capturas de pantalla.
Ya he hablado de k3d otras veces en el blog; del mismo modo que kind permite desplegar Kubernetes en Docker: cada nodo del clúster se ejecuta en un contenedor.
k3d hace lo mismo pero en vez de Kubernetes vanilla, usa la distribución ligera de Kubernetes, k3s.
Este fin de semana he actualizado la documentación del repositorio onthedock/k8s-devops en lo relativo a k3d y he aprovechado para explorar un par de cosas nuevas: deplegar el clúster de forma declarativa (como código) y el uso del registry interno en k3s.
En este artículo me centro en la primera parte: el despliegue del clúster como código.
El ejemplo habitual para introducir los sparse checkouts es cuando todo el código de un equipo se encuentra en un mono repo, es decir, un repositorio para todo.
En el repositorio cada “carpeta” contiene el código de un microservicio, por ejemplo…
En esta situación, un miembro del equipo tiene que clonar el repositorio entero aunque sólo tenga que trabajar en una parte muy pequeña del mismo, generalmente circunscrita a una funcionalidad que se encuentra en una carpeta del repositorio.
Del mismo modo, para compilar el código de uno de los microservicios de este mono repo, es necesario clonarlo completamente…
En este tipo de situaciones es cuando podemos usar git sparse-checkout.
Hace unas semanas comentaba que estaba trabajando en un proyecto personal para implementar un parseador de reglas para el proxy, en Go.
Después de leer los artículos Write packages, not programs y From packages to commands de John Arundel (así como los artículos a los que enlaza), decidí enfocar de manera diferente el parseador de reglas del proxy.
Empecé a escribir un nuevo módulo rules guiado por tests…
El resultado se encuentra disponible en ontehdock/proxy-rules en Github, pero aquí apunto algunas pinceladas (a modo de notas personales).
El CIS publica imágenes hardenizadas en el Marketplace público de Google Cloud Platform (GCP). Estas imágenes se actualizan de vez en cuando, por lo que es importante usar siempre la versión más actualizada.
