Photo by Mabel Amber
El gophercise para crear una versión en Go de los libros de Elige tu propia aventura de la entrada anterior me hizo ver que debo asentar los conocimientos básicos sobre Go.
No me refieron tanto a saber qué es una variable, la sintaxis de un bucle for ni nada por el estilo; me refiero a la forma en la que debe programarse en Go…
Ayer dediqué una buena parte del día al tercer ejercicio de Gophercises (puedes ver el vídeo de Jon en YouTube: Gophercises #3 - Choose Your Own Adventure Book (via website)).
Estuve tomando notas sobre el vídeo de solución de Jon al ejercicio, pausando el vídeo, reflexionando en cómo atacaba cada parte del problema, etc…
Hoy he vuelto a revisar las notas con la intención de publicarlas, como hice con el ejercicio anterior (Quiz Game, 1a parte y Quiz Game, 2a parte). Sin embargo, quiero aprovechar el flow (y el tiempo libre) para repasar con calma la documentación de los diferentes paquetes usados en el ejercicio, revisar el tema de los constructores y otros aspectos más teóricos que Jon usa con total naturalidad y que a mí me resultan completamente marcianos…
Oh My Zsh es un framework para gestionar la configuración de Zsh.
Zsh es un shell alternativo a BASH, el shell por defecto de la mayoría de distribuciones Linux. Sin embargo, desde Mac OS Catalina, Zsh se convirtió en el shell del terminal de los Mac. Este hecho, junto a la vistosidad de los temas que pueden aplicarse al prompt en Zsh (en especial, gracias a Oh My Zsh), ha convertido Zsh en un shell cada vez más popular.
Update : Joe Block ha sido tan amable de incluir mi tema de Oh My Zsh en la lista que mantiene en GitHub unixorn/awesome-zsh-plugins.
Seguimos con la segunda parte del gophercicio “quiz game”, propuesto por Jon Calhoun.
El ejercicio consiste en realizar una serie de preguntas al usuario (cargadas desde un fichero CSV) y presentarlas al usuario, registrando las respuestas acertadas y mostrando la puntuación al final. Esta parte del ejecicio está resuelta en la entrada Quiz Game, 1a parte (Ejercicios en Go) #gophercises.
En esta segunda parte, añadiremos un límite de tiempo (configurable por el usuario) en el que completar la prueba (o el máximo número de respuestas posibles).
El primer ejercicio consiste en crear un programa que haga un “examen” o prueba de conocimientos al usuario.
El programa debe cargar las preguntas y respuestas de un fichero CSV, presentarlas al usuario y mostrar la puntuación de preguntas respondidas correctamente sobre el total al finalizar la prueba.
En la segunda parte, además, estableceremos un límite de tiempo.
Dentro del mundillo de DevOps, cada vez más y más cosas se definen “como código”; infraestructura como código, configuración como código, seguridad como código, etc…
Mi interpretación de esta “filosofía” de “* como código”, no sólo se refiere a la definición de la infraestructura, seguridad, etc, sino también a la aplicación las mismas herramientas y metodologías que se usan para el código código: repositorios de control de versiones, testing, integración continua, etc.
El objetivo inicial del formato markdown era simplificar la creación de ficheros HTML, como puede verse en la página Markdown del creador del formato:
Markdown is a text-to-HTML conversion tool for web writers. Markdown allows you to write using an easy-to-read, easy-to-write plain text format, then convert it to structurally valid XHTML (or HTML).
La realidad es que en muchos entornos, sobretodo el empresarial, los entregables deben realizarse en formatos propietarios como MS Word (.docx) o en PDF, que no permite la edición.
Gracias a la versatilidad de herramientas como pandoc, podemos desarrollar la documentación en un formato git-friendly como markdown y generar documentos finales en formato MS Word o PDF.
Typora es un editor multiplataforma de tipo WYIYWG (what you see is what you get) de ficheros en formato markdown. Durante la beta pública, era gratuito y se podía usar sin restricciones. Pero desde el pasado 23 de noviembre de 2021, con la salida de la versión 1.0, ha pasado a ser de pago ($ 14.99, impuestos a parte), con un periodo de prueba de 15 días.
Desde mis inicios con Kubernetes, una de las cosas más pesadas del proceso de creación del clúster (para mí) ha sido el tener que desplegar y configurar las máquinas que formarán el clúster.
En esta entrada explico algo de mi relación histórica con Vagrant y el proceso de automatización que estoy siguiendo para desplegar clústers locales (no cloud) en mi laboratorio.
En la entrada anterior indicaba la idea general en la que estoy trabajando para implementar una solución funcional de documentación como código.
Reducida a su mínima expresión, la prueba de concepto lo que tiene que mostrar es la velocidad a la que se puede ir actualizando la documentación si se sigue el mismo proceso -y herramientas- de desarrollo a las que está acostumbrado el equipo de proyecto.
No se trata de crear un sistema listo para producción, sino de mostrar algo que funcione ™ más o menos, como funcionaría la solución final.
