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?
dev
Photo by Mabel Amber
Patrón de 'functional options'
- post
- Xavi Aznar
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ónNewClient
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.La nueva entrada es Functional Options revisitadas
Imagina que te encuentras en el siguiente escenario: creas un rama y haces cambios en un fichero.
¿Cómo puedes ver qué diferencias hay en el fichero en dos ramas distintas?
La solución es mi #TIL (today I learn) de hoy.
k3d: Registry local en Kubernetes
- post
- Xavi Aznar
En la entrada anterior k3d: desplegar un clúster de Kubernetes como código incluí un registry en el despliegue del clúster con k3d.
En esta entrada veremos cómo usarlo para desplegar aplicaciones en el clúster.
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
.CSV Parser (II)
- post
- Xavi Aznar
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).
CSV Parser en Go (work in progress)
- post
- Xavi Aznar
En la entrada Convertir CSV en JSON con Jq comentaba cómo realizar la conversión de un fichero CSV en JSON usando Jq.
En esta entrada repito (parcialmente) el ejercicio, pero usando Go.
Al definir un documento JSON, los campos pueden tener diferentes tipos, como
string
,number
,boolean
, etc… Sin embargo, al crear un documento usando--arg
, el valor siempre se trata como string:--arg name value:
This option passes a value to the jq program as a predefined variable. If you run jq with –arg foo bar, then $foo is available in the program and has the value “bar”. Note that value will be treated as a string, so –arg foo 123 will bind $foo to “123”.
Convertir un fichero CSV en JSON usando Jq
- post
- Xavi Aznar
Una de las automatizaciones que hemos desarrollado consiste en un autoservicio para que los clientes puedan gestionar políticas en un proxy.
El usuario genera un fichero CSV con varios parámetros y los “sube” a un repositorio Git en su proyecto. El evento desencadena la ejecución de una pipeline en la que procesamos el fichero, validamos su contenido, etc. Una vez procesados, construimos un objeto JSON para cada una de las reglas, las agregamos y finalmente las integramos en el documento de configuración del proxy del cliente (que contiene otros campos que el cliente no debe editar).