NOTA: Esto aún no ha sido actualizado en la documentación de Earthly, pero estoy bastante seguro de que lo será pronto (y actualizaré este post en consecuencia)

¿Qué hacen los labels a las builds reproducibles?

Por defecto, Earthly agrega labels dev.earthly.* en la imagen construida. Puedes encontrarlos haciendo un docker inspect <imageID> | jq -r '.[].Config.Labels'.

Aquí hay un ejemplo de la configuración de la imagen incluyendo los labels dev.earthly.*:

Si estás en este post, es porque necesitas implementar una forma consistente de agregar paralelización a tus scripts. Esta implementación es limitada, ya que no contempla agrupar trabajos para establecer diferentes grupos de procesos con diferentes configuraciones o prioridades.

Aunque, probablemente la mayoría de los casos solo necesitas ejecutar código que corre dentro de un bloque o simplemente hace algo en paralelo. El comando parallel es una buena opción, pero requiere perder algo de legibilidad del código, particularmente en bloques de código que podrían inyectar una semántica compleja.

Testcontainers te permite probar tu código con contenedores efímeros directamente dentro de tus pruebas. Proporciona diferentes módulos para simplificar el proceso, sin embargo, a veces puedes necesitar personalizar el contenedor más allá de los parámetros predeterminados o su contenido.

Código Fuente del laboratorio. Todos los ejemplos son funcionales, sigue las instrucciones en el archivo README para configurar. El archivo csv se genera por la configuración de Docker Compose, puedes regenerar el ejemplo ejecutando docker compose up -d.

Read More…

Caso

He estado desarrollando una aplicación en Go que usa SQLite como caché local del backend. La historia terminaría ahí si no fuera que decidí ir por una imagen distroless para propósitos de optimización, y también, ¿por qué no?

La cosa aquí es que para habilitar ciertas características del driver database/sql, el artefacto debería estar dinámicamente enlazado a través de CGO_ENABLED=1 y con -tags "fts5" (para el soporte de la característica FTS5, ver este comentario del issue).

Una herramienta útil para paralelización

Si estás leyendo este post, es porque has oído sobre parallel. Es una herramienta desarrollada por GNU para paralelizar comandos a través de conjuntos de argumentos. Seré honesto, suelo olvidar su existencia hasta que necesito hacer cosas rápidas y sucias cuando trato con tareas que requieren paralelización, y siempre que el tiempo es una restricción.

Tiene muchas opciones y argumentos, aunque una vez que te acostumbras a su uso, es muy útil en muchos casos.

Hace unos meses, compré el Ergodox OrthoLinear Split Keyboard. Después de un período de probarlo, encontré que el layout QWERTY era considerablemente incómodo para escribir en la disposición del teclado. No era el único, por supuesto, así que empecé el viaje para buscar un layout adecuado. Durante un período de tiempo, cambié de un lado a otro entre tres layouts (QWERTY, Dvorak, y Colemak), aunque elegí Colemak al final.

Background

Hubo un concurso en un hilo de internet sobre cómo codificar un intercambio de variables tan bajo nivel y minimalista como sea posible. Entonces, terminé escribiendo una función de bajo nivel en C llamando instrucciones para una plataforma amd64 moderna.

#include <stdio.h>
#include <stdlib.h>

void swapshit(int *arg1, int *arg2) {

   __asm__ __volatile__ ("movl %2, %%eax;"
                         "movl %3, %%ebx;"
                         "movl %%eax, %0;"
                         "movl %%ebx, %1;"
                         : "=g" (*arg2) , "=g" (*arg1) 
                         : "a" (*arg1), "b" (*arg2)  );
} 

int main(int argc, char *argv[]) 
{
   int arg1 = atoi(argv[1]);
   int arg2 = atoi(argv[2]);
   swapshit(&arg1,&arg2);
   printf("arg1 es %d , arg2 es %d\n",arg1,arg2);
   return 0;
}  

La explicación de lo anterior es bastante simple. Usamos registros para asignar los valores y los llamamos en un orden diferente usando la instrucción movl. El main es solo un wrapper que pasa argumentos.