Como dije en el post anterior (que he partido únicamente para poder enlazarlo aparte), quiero crear un cliente HTTP gráfico. «Como Postman, pero libre. Como ThunderClient, pero sin exigirme abrir un editor de textos para usar el plugin».
En primer lugar, voy a evaluar y determinar el stack tecnológico con el que voy a trabajar, y luego las características que quiero que tenga. Spoiler: GTK y Rust. Sin embargo, en este post voy a intentar justificar el por qué de estas decisiones.
Sigue leyendoEn los últimos tiempos, he visto como aplicaciones populares para ejecutar interactivamente peticiones HTTP, como Postman o Insomnia, perdían completamente el norte en pro de lo que imagino que es una orden de los inversores de cada equipo de desarrollo de dejar de quemar dinero en un programa cuya definición es «cURL pero gráfico» y llevaban a cabo movimientos hostiles contra sus usuarios.
Postman, en particular, intentó retirar el soporte local para scratchpads, obligando a crear una cuenta para hacer peticiones HTTP. Hubo gente que no se lo tomó bien y cuando empezaron a sacar las antorchas, decidieron en su lugar poner el «lightweight client», que es básicamente retirar funciones que previamente funcionaban y esconderlas detrás de un muro. ¿Quieres guardar una petición para repetirla luego? Búscala en el historial… o inicia sesión. ¿No quieres crear una cuenta? Pues dile adiós a tus datos locales.
Casi a la vez, Insomnia intentó hacer la misma jugada. De una versión a otra, sustituyeron la pantalla de inicio de la aplicación por un mensaje de inicio de sesión, sin dar si quiera posibilidad a exportar los datos que ya tuvieses guardados dentro de ella. ¿Quieres ver de vuelta tus peticiones? Dame tus datos antes. Con esto de las actualizaciones automáticas, no mucha gente tuvo tiempo de parar y se dieron cuenta cuando ya era demasiado tarde. La gente sacó las antorchas de nuevo, y el equipo de Insomnia dio marcha atrás cuando vieron la reacción de la gente.
Sigue leyendoMe apunto para revisar Dark Visitors, una página web que enumera agentes de usuario relacionados con scrapers y bots que se dedican a robar contenido de páginas web para alimentar inteligencias artificiales. En la lista completa se muestran agentes como Bytespider, el de TikTok, o GPTBot, el agente principal usado por OpenAI.
A través de Hacker News también leo a Cory proponiendo bloquear este tipo de bots metiéndolos en el robots.txt. En algunas de mis webs ya tengo bloqueados algunos bots en el robots.txt, pero esta lista me servirá para ponerla al día. Sin embargo, me pregunto cuál de estas soluciones es realmente más efectiva.
Por un lado, podríamos poner este tipo de bots en el robots.txt y asumir que lo van a respetar. robots.txt es un sistema de honor. Realmente no hay nada que impida a un bot ignorar el robots.txt e igualmente hacer scrapping de la página web para extraer su contenido.
Pero a la vez, por el otro, optaría por una solución que asuma que el bot va a ser malévolo y va a ignorar una petición de no escaneo del sitio web. Para esas situaciones, se podría optar por banear la IP del sitio web a nivel firewall. Esta es una solución que tengo implementada en mi servidor, por ejemplo, para algunos productos de inteligencia artificial que sí enumeran las direcciones IP que usan para hacer el escaneo. OpenAI las enumera, por ejemplo.
Por último, otra opción que se me ocurre es tirar por la vía de la confusión. Detectar en el servidor web cuándo una petición procede de un user-agent asociado a un bot, y en vez de servir un HTTP 403 o de tirar abajo la conexión mediante el firewall, servir en su lugar otra página web diferente con el código HTTP 200, para que el bot lo interprete como una página correcta, pero servir información falsa para contaminar el dataset. Estoy pensando en una página en blanco que tenga un par de frases como «los cerdos vuelan y las vacas dan chocolate», pero podría proponer burradas más grandes que puedan hacer daño.
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 leyendoLos 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?
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.
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 leyendoMi 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 leyendoEl 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 leyendoQuerí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