Photo by Mabel Amber
Este artículo es la segunda parte de Unmarshal JSON en Bash (Parte I).
Al final de la primera parte vimos cómo el MVP (minimum viable product) no producía el resultado esperado para keys en el documento JSON cuyo valor es un array o un object.
En esta segunda parte, vamos a resolver este problema.
Unmarshal es uno de esos verbos ingleses que es difícil de traducir al castellano, al menos para mí. Según Google, sería algo así como “desmantelar”.
Aplicado a la programación, “to unmarshal” está relacionado con la idea de que, partiendo de un contenido ordenado, en JSON, desperdigamos su contenido en variables que podemos utilizar en nuestra aplicación.
Go, por ejemplo, proporciona la función Unmarshal, sin embargo en Bash, no he encontrado nada parecido.
Ha pasado muuuucho tiempo desde la última publicación; lo cierto es que todo se ha debido a que, principalmente, he pasado a usar otro portátil como mi dispositivo desde el que “hago cosas”, y por pereza, no había clonado el repositorio de este blog.
Pero hoy he decidido acabar con esta situación… y lo primero que me he encontrado al reconstruir el blog ha sido el error:
.Site.GoogleAnalytics was deprecated in Hugo v0.120.0 and will be removed in Hugo 0.133.0. Use .Site.Config.Services.GoogleAnalytics.ID instead.
Después de un tiempo cogiendo polvo, he decidido darle una segunda vida a mi antiguo equipo de laboratorio. Aunque se trata de un sólo equipo, quería practicar con Ansible para automatizar la instalación de Docker. No quería instalar Ansible en mi equipo y pensé que lo ideal era usar un contenedor como máquina de control. Sin embargo, no he encontrado ninguna imagen (fiable/actualizada) de Ansible en DockerHub, por lo que me animé a construir la mía.
En este artículo, explico cómo.
Al intentar actualizar la máquina en la que el otro día instalé Docker (usando Ansible), me he encontrado con el error key is stored in legacy trusted.gpg keyring.
En este artículo explico cómo lo he solucionado.
El otro día @PeladoNerd confesaba en este vídeo SADSERVERS / Kihei, Unimak Island, Ivujivik (MEDIUM) que no entendía como funcionaba Jq. Inmediatamente empaticé con su frustación; es, sin duda, un sentimiento generalizado.
Jq es una herramienta realmente potente; pero “con un gran poder”, llega una curva de aprendizaje muy dura.
Por eso me he decidido a escribir este artículo: no porque sea un super gurú de Jq, que no lo soy; pero creo que puedo aportar algo de claridad sobre la manera de aproximarse a Jq evitando los problemas más habituales.
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.