Server-Sent Events con ExpressJS

Recientemente tuve una excusa para jugar con la API de Server-Sent Events en el navegador web, y utilizar un microservicio ExpressJS como proveedor de eventos en tiempo real.

Server-Sent Events es una API que permite a una página web incorporar eventos push enviados desde un servidor. A diferencia de un websocket, Server-Sent Events sólo permite comunicación unidireccional enviada desde el servidor al cliente, pero el cliente no tiene la posibilidad de comunicarle nada al servidor. Sin embargo, en casos donde solamente queremos que el servidor nos pueda mandar mensajes en tiempo real y reaccionar a ellos, puede ser más que suficiente.

Además, a diferencia de WebSocket, que normalmente requiere una biblioteca específica para hacer el ugprade a websocket y la gestión de eventos, el protocolo SSE es lo suficientemente simple como para poder usarlo con casi cualquier lenguaje de programación, porque por fuera es una petición HTTP regular. Yo lo voy a usar con ExpressJS, pero en MDN hay un ejemplo para conectarlo desde PHP. Ojo, no Symfony, Laravel o algo, sino puro archivo events.php sin framework. En frontend, el cliente de SSE es compatible con todos los navegadores, y además lleva disponible desde hace años: Chrome 6 y Firefox 6 ya lo soportaban.

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

Más cosas que he cambiado por aquí (esto es una prueba)

Estado

Además de lo que contaba en mi otro post, he aprovechado para instalar Hum. La propia extensión de ActivityPub lo recomienda, para que los enlaces permanentes sean cortos y así más fáciles de compartir. Iremos viendo qué tal.

En fin, este post es una prueba para ver si se muestra bien el estado o no. Ya dije que la única forma de probar estas cosas es escribiendo.

Configuración dinámica para las plantillas de ActivityPub de este blog

Utilizo el plugin de ActivityPub para WordPress para agregar un endpoint webfinger, un outbox y un inbox a mi blog. A efectos prácticos, esto es todo lo que hace falta para tratar al sitio web como un usuario del fediverso, lo que significa que en teoría debería poderse seguir al blog desde la mayoría de softwares compatibles (Mastodon, Pleroma, microblog.pub…) siguiendo a @dani.

He estado haciendo algunos cambios a la forma en la que los posts de este blog se renderizan cuando se comparten por ahí. Esto es algo que siempre me ha dado pereza de hacer, por lo lento que es, porque para depurar el aspecto con el que se muestra un post, primero lo tienes que escribir (así ves el post salir en la portada), y además hacerlo público. Últimamente lo estoy volviendo a hacer más, y casi cada artículo que escribo es una excusa para ver si mis cambios funcionan, pero no cantemos victoria.

Sigue leyendo

pacdef como gestor declarativo de paquetes en Arch (y Arch-like)

Mi problema con los gestores de paquetes es que a menudo instalo cosas para probarlas, esas cosas instalan dependencias, luego me olvido de borrar los paquetes una vez me dejan de hacer falta, o si lo hago, estas se olvidan de borrar sus dependencias y dejan un sistema con paquetes innecesarios y con suciedad acumulada.

Una de mis formas favoritas de resolver esto, es con herramientas que permitan declarar en un archivo la lista de paquetes que debe tener un ordenador. Como un package.json o un requirements.txt, pero a nivel sistema operativo. En cualquier caso, un mantenimiento periódico de la lista de paquetes es altamente recomendable para mantener limpio el ordenador, bajo mi punto de vista.

Sigue leyendo

El FrankenMac ahora usa Arch Linux

El FrankenMac (diminutivo cariñoso de Mac-Frankenstein) es el nombre cariñoso que recibe mi viejo MacBook Pro. Cuando lo reemplacé por un Mac Mini el año pasado, el portátil se fue al cajón por falta de uso. Como igualmente ya no recibía actualizaciones de seguridad por parte de Apple, eventualmente decidí borrar su disco duro e instalar EndeavourOS en él, donde se ha convertido en un ordenador para hacer experimentos antes de ensuciar mi otro ordenador.

La razón por la que elegí EndeavourOS fue porque quería una distribución tipo Arch, que es lo que ya de por sí uso en mi torre, pero no quería hacerlo a mano todavía, ya que por muchas veces que haya instalado Arch en sobremesas, en portátiles nunca lo había hecho a mano, y me daba pereza ponerme a aprender cómo configurar el wifi o cómo instalar los paquetes térmicos.

Más de medio año después, he aprendido lo suficiente sobre administración de un Arch-like en este portátil como para no tenerle miedo a la versión original, así que aprovechando ciertos experimentos que quiero llevar a cabo, he decidido reconvertirlo a una instalación de Arch Linux.

Sigue leyendo

Acciones de GitHub simples que interactúen con la API de GitHub

Quería hacer una acción de GitHub que cerrase educadamente cada PR recibido en algunos repositorios. GitHub permite desactivar el gestor de issues en un repositorio, pero no permite desactivar el gestor de pull requests. Es decir, siempre un proyecto va a aceptar pull requests y contribuciones externas. Algo con lo que en algunos casos no me llevo bien.

Aunque para algunos proyectos me parece bien, en proyectos más artesanales no me gusta aceptar código ajeno porque al fin y al cabo es una artesanía. Igual que en la playa no voy por ahí poniéndole torres a los castillos de arena que están haciendo otras personas, incluso aunque los estén haciendo en un lugar público y no en el jardín de su propia casa, me interesaría restringir la participación en algunos repositorios donde la gracia es precisamente que se construye artesanalmente.

La GDPR me pone una excusa bastante buena para hacer esto, puesto que si son repositorios que voy a estar alojando en mi servidor y sirviendo desde mi propio servidor de Git, me puede poner en un problema legal estar sirviendo nombres y direcciones de correo electrónico de otras personas, dentro de los commits del repositorio y de la interfaz web.

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

Los formularios en PDF son una mala práctica

Esta es una opinión subjetiva pero me voy a agarrar a ella y pienso morir defendiéndola: los PDF son un formato terrible para representar formularios interactivos. La administración pública parece que se ha agarrado a ellos como una lapa, y es algo que resulta entendible. Si el PDF ya representa de facto un documento digital, un PDF con formularios es visto como el equivalente digital a una hoja de papel que hay que rellenar, pero bajo mi punto de vista esto es un error.

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