Primeros pasos creando blueprints con GNOME Workbench (resumen del stream de ayer)

Este post forma parte de la saga dedicada a la creación de una alternativa verdaderamente libre (o sea, GNU GPL) a Postman, Insomnia y Bruno. A su vez, esto es un resumen de texto de lo que hice en un stream de livecoding anterior. Así si te lo perdiste, es fácil de leer. Principalmente, lo que voy a contar aquí es cómo utilizar Blueprint y el lenguaje de diseño. Es un post que sirve como referencia y que estaré enlazando más adelante.

En el stream de ayer, después de contar la razón por la que quiero empezar a crear una aplicación de este estilo, empecé a fabricar el prototipo de una interfaz de usuario con GNOME Workbench. Esta aplicación permite diseñar una ventana y verla en tiempo real, para poder iterar más rápido y sin tener que recompilar código.

Sigue leyendo

Montaje automático de discos USB en Arch Linux

Los entornos de escritorio grandes (como GNOME o KDE) probablemente harán esto por ti. Pero ¿cómo se hace fuera de las grandes? Hace poco tuve que enchufar mi memoria USB en Arch Linux para poder quemar una ISO (es para lo que han quedado). ¿Cómo se haría para enchufar y disfrutar, sin tener que abrir la terminal y escribir el comando mount?

Sigue leyendo

Generar AppImages con AppImageKit

Para un proyecto estoy generando ejecutables para GNU/Linux, y el compilador me produce una carpeta con una distribución de archivos. Carpeta bin/ con el ejecutable, carpeta lib/ con las .so… Podría empaquetar eso en un .zip, podría aprender a generar un .deb o un .rpm… o podría aprovechar la ocasión para aprender a crear archivos AppImage.

AppImage es un formato ejecutable autocontenido para GNU/Linux. Es decir, el ejecutable y todas las dependencias (imágenes, bibliotecas dinámicas…) van dentro del propio archivo. La ventaja de esto es que acabas con el conflicto de versiones de bibliotecas dinámicas (la típica de que en GNU/Linux dos programas no se llevan bien porque uno espera que /usr/lib/libwhatever.so sea la versión 1.2.3 y otro espera que /usr/lib/libwhatever.so sea la versión 2.5.8). Al final tienes un único archivo, que haces ejecutable con chmod +x, y que cuando ejecutas funciona normal en cualquier distribución GNU/Linux. Como lo que también buscan conseguir Flatpak y Snap, vaya.

Para crear AppImages, utilicé AppImageKit. Es una herramienta que convierte un directorio en formato AppDir (es decir, con el esqueleto de la aplicación), en un archivo ejecutable de tipo AppImage. Aunque es muy flexible, a la vez es muy sencillo de empezar a usar.

Sigue leyendo

let, apply y similares en Kotlin

De mis características favoritas de Kotlin, una de las más top es que todos los tipos tengan como funciones de extensión una serie de métodos auxiliares: let, apply, also… Son una forma limpia de encadenar código y hasta de transformarlo. El problema es que nunca recuerdo qué diferencia hay entre ellos, así que voy a dejarlo por aquí escrito para la próxima.

Su nombre correcto es scope functions y aceptan como parámetro una lambda con el código que queremos que se evalúe a consecuencia de invocar esa scope function. Su principal gracia, como muestro ahora, es que desde dentro de la lambda se puede referenciar al objeto cuyo método de extensión es invocado. Bajo mi punto de vista, esto está muy bien porque permite no escribir tanto código cuando se usan expresiones largas.

Por ejemplo, supongamos que hay que llamar a varios métodos del objeto accesible desde context.server.settings. Tendríamos que escribir varias veces todo el chorizo de clases. Me invento el código:

context.server.settings.port = 8080
context.server.settings.protocol = Protocols.HTTPS
context.server.settings.resetLogger()

Para no cansarnos de escribir tanto context.server.settings, las opciones serían, o crear una variable local con val sett = context.server.settings para luego hacer sett.port y sett.protocol, o… usar las scope functions y que la variable se declare implícitamente.

Sigue leyendo

Cómo importar un paquete de Go usando un dominio propio

La idea final es explicar cómo se puede hacer para importar un paquete de Go usando una construcción como import "example.com/package/foobar/lib" y que funcione bien, en el sentido de que la ruta que se le pone en el import es una ruta que resuelve y desde la que se puede descargar el paquete correspondiente, pero sin tener que poner explícitamente github.com o gitlab.com en la ruta del import.

Sigue leyendo