Mi experiencia con el Mac Mini M2 Pro

Posted on 24/02/2023 por Dani

He cambiado mi ordenador del trabajo por un Mac Mini M2 Pro. Ahora más que nunca, es importante que separe el uso que hago de mi ordenador cuando es para trabajar, del uso que hago de mi ordenador cuando no es para trabajar. Estos meses no me ha quedado otra que trabajar desde el ordenador de jugar, porque he descubierto que mi viejo MacBook ya no es definitivamente lo que era, pero no se podía caer en la tentación de simplemente reemplazarlo en frío sabiendo que eventualmente Apple acabaría actualizando su Mac Mini.

Elegí un Mac Mini porque ya no tengo la necesidad de trabajar fuera de casa que tenía años, por lo que he preferido sacrificar movilidad en favor de tener un ordenador más potente y una setup más estable y fija en casa. Y un Mac Mini, por ser lo único que me conviene. Un iMac es otra pantalla más que no voy a necesitar, porque ya voy sobrado. Y un Mac Studio es pedir unas prestaciones de hardware en procesador y memoria para las que no estoy a la altura en comparación con el precio que iban a valer también. Con mi Mac Mini M2 Pro he sido capaz de editar ya a estas alturas vídeo en resolución 4K para un proyecto del canal de YouTube a tiempo real, sin cortes ni estar todo el rato cargando.

Creo que otro de los argumentos que ha influenciado esto es el precio de un MacBook Pro en este momento. Me resulta fascinante ver la tabla de precios actual de los MacBook Pro. Entiendo que tienen prestaciones que antes no existían, como Touch ID, Touch Bar, una pantalla de más resolución… pero recuerdo cuando recién anunciada la arquitectura Sillicon, se vendía que una de las características iba a ser una bajada de precio al no tener que pagar royalties a Intel por sus CPUs. Viendo los precios de los MBP en este momento, lo empiezo a dudar.

En términos de conectividad, no ha dado mucho problema. El aparato lleva detrás cuatro conectores USB-C y dos conectores USB-A. Hubo que hacer de nuevo un poco de cacharreo con mis cables, y también comprar algunos cables nuevos, porque es la primera vez que enchufo un monitor por USB-C, pero una vez resuelto el lío, todo funciona bien.

Como tengo dos ordenadores, utilizo un KVM para compartir fácilmente las pantallas y el hardware más esencial (teclado, ratón y algunos aparatos que no quiero estar enchufando y desenchufando todo el rato) entre los dos ordenadores. Con este aparato puedo cambiar con un botón qué ordenador es el que se ve por mis monitores y también a qué ordenador le conecta el concentrador USB.

Un Mac Mini encima de una alfombrilla de teclado, mostrando sus puertos traseros

En términos de rendimiento. Ni sé cómo medir el rendimiento de una forma «profesional», ni tampoco soy el tipo de persona al que le importe. En fin, si alguien quiere una review detallada y bien medida con números, se ha equivocado de persona. Sin embargo, sí que voy a dar algunos números en base a lo que hago en mi día a día y cómo se compara con mi torre o con mi anterior ordenador.

Una cosa muy importante es que es difícil comparar el rendimiento entre un M1 y un M2. Esto es algo que ya han avisado de antemano muchas personas que sí saben reportar este tipo de datos. Apple Silicon es una arquitectura más potente que lo que ofrece x86 en este momento, por lo que el salto de un Intel a un ARM es bastante brusco. Sin embargo, saltar de un M1 a un M2 no es tan espectacular como puede parecer a primera vista.

Algunas notas sobre la velocidad de este ordenador:

Docker para Mac activa el hipervisor en menos de 15 segundos. Nunca había visto que fuese tan rápido. A menudo, para cuando he regresado a la terminal y vuelvo a escribir el comando para lanzar el servidor, o visito localhost, ya ha dado tiempo a que se encienda todo.
Al ejecutar suites de tests en Ruby y JavaScript, la percepción es que es más rápido al reportar información. Por ejemplo, veo aparecer puntos más deprisa en una sesión de RSpec. Sin embargo, no es una reducción de tiempo tan drástica como puede parecer.
En las tareas de edición de vídeo, aunque me he visto forzado a actualizar a ScreenFlow 10 por incompatibilidades del sistema operativo, el cambio ha merecido la pena. En mi viejo portátil, ScreenFlow reventaba si tenía demasiadas pistas de vídeo, o si tenía vídeos de mucha resolución. Esos proyectos se mueven bien aquí. En este ordenador, estoy exportando vídeos de 10 minutos en 3 minutos.

Lo de tener que cambiar a ScreenFlow 10 es una consecuencia de la arquitectura ARM. Hay gente que sigue teniendo problemas con ARM porque considera que ninguno de sus programas va a funcionar. La realidad es que, quitando ScreenFlow, ningún programa que sólo esté disponible para Intel me ha fallado. El sistema integra una capa de traducción que permite ejecutar aplicaciones de otras arquitecturas.

El principal problema con mi viejo ScreenFlow y Sillicon es que no puede exportar vídeo. Posiblemente la nueva tarjeta gráfica use un modelo de trabajo distinto que no se ve venir. Otro problema es que mi vieja versión de ScreenFlow no podía hacer frente al nuevo sistema de permisos para capturar la pantalla y todo lo que grababa se veía negro. Pero esto creo que es más cosa de macOS que de Sillicon.

¿Alguna cosa negativa a destacar? El sistema operativo como tal.

Aunque macOS ofrece una experiencia de usuario bien integrada y en general sigue siendo la mejor experiencia UNIX a mi punto de vista, algunas de las opciones de privacidad por defecto son excesivamente paranoicas y entorpecen el trabajo. El sistema de permisos para las aplicaciones funciona mejor que en versiones anteriores, pero aun así a veces hay aplicaciones que cuesta bastante hacer que funcionen cuando piden permiso para usar el micrófono o la cámara.

En una necesidad, un día me tuve que conectar por SSH a mi Mac desde mi otro ordenador para copiar una cosa que tenía en mi carpeta de descargas, porque no quería cambiar el KVM. No tuve otra opción que hacerlo de todos modos, porque resulta que el servidor SSH que trae macOS tampoco puede acceder a la carpeta de descargas por defecto, debido a que en versiones modernas de macOS ese directorio requiere que se autorice a cada aplicación por separado antes de que tenga acceso.

macOS 13 tiene bugs, incluso todavía en febrero. Las notificaciones funcionan cuando quieren, y a veces se pierden o no salen en pantalla en primer lugar. Se suele recomendar no actualizar de versión de macOS hasta que pasan unos meses para reducir este tipo de problemas, en lo que se estabiliza. Sin embargo, dado que el ordenador llegó al mundo cuando macOS 13 ya estaba aquí, es imposible volver atrás.

Pese a todo esto, en general estoy contento de haber elegido este ordenador y de que generalmente no sea un lastre en mi trabajo. Puedo ser productivo y puedo volver a trabajar con archivos multimedia grandes. Además ahora tengo otra vez todo un ordenador separado para trabajar, así que puedo apagarlo durante el fin de semana y separar el ocio en el otro.

¿Debo recomendar este ordenador? No lo sé. No me gusta recomendar cosas. Hay gente que se piensa que algo le puede valer solamente porque se lo ve a otras personas. Y creo que no es así. En parte pongo esta nota al final del post también para poder enviar el link a este artículo cuando alguien me pregunte por mi ordenador.

Cuando se compra un ordenador, sea del tipo que sea, hay que tener claro por qué se compra (para jugar, para trabajar, como apoyo a una tarea concreta…), y el tipo de cosas que vamos a hacer con él (programar, navegar por internet, editar vídeo, hacer contabilidades…). A mí me soluciona mis problemas y a mí me ha gustado, pero sólo tú puedes responder a esta pregunta en función de tus necesidades.

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

Posted on 17/02/2023 por Dani

En Go, salvo los paquetes de la biblioteca estandar, que son los que suelen tener nombres como "log" o "net/http", lo normal es que el resto de bibliotecas e imports se resuelvan en base a paquetes que tienen nombres de URL.

Esto es bueno porque ahora "golang.org/x/crypto" es una ruta completa que permite meter en un namespace la biblioteca crypto, sin perjuicio de que ahora pueda existir otro example.com/pkg/crypto. Aunque al importarlos habrá que hacer un alias, ambos paquetes pueden coexistir.

Existe toda una especificación sorbe cómo funciona el sistema de imports remotos. Está documentado en su web. La idea es que cuando se hace la instalación de un módulo, como golang.org/x/crypto, lo primero que hay que hacer es una petición HTTP mediante protocolo HTTPS a esa misma URL, por ejemplo, https://golang.org/x/crypto. En el cuerpo de esa respuesta tiene que venir una etiqueta <meta> de nombre go-import, que será la que describa las instrucciones sobre cómo obtener el módulo.

Si se visita https://golang.org/x/crypto, la página en este momento hace una redirección a la documentación de ese paquete. Pero viendo el código de https://golang.org/x/crypto, por ejemplo mediante cURL o wget, hay dos etiquetas meta:

<meta name="go-import" content="golang.org/x/crypto git https://go.googlesource.com/crypto">
<meta http-equiv="refresh" content="0; url=https://pkg.go.dev/golang.org/x/crypto">

La primera de estas etiquetas es la go-import, que describe cómo se importa el módulo. La segunda etiqueta es la que hace la redirección que ocurre cuando se accede a https://golang.org/x/crypto desde el navegador web.

Una de las formas más típicas de alojar paquetes de Go es en GitHub y similares. Y de hecho si repetimos el procedimiento, por ejemplo, si vemos el código fuente de https://github.com/spf13/cobra, vemos que GitHub también tiene su propia etiqueta <meta name="go-import"> en el código fuente HTML:

<meta name="go-import" content="github.com/spf13/cobra git https://github.com/spf13/cobra.git">

Sin embargo, importar una URL de GitHub es menos canónico que importar un paquete desde un dominio propio. Además, quién sabe cuándo las cosas pueden cambiar y cuando puede ser necesario migrar a GitLab o a Codeberg o similares. La ventaja de importar las cosas desde un dominio propio es poder ser independiente a ese tipo de cosas.

Pongamos que tengo un paquete en https://github.com/danirod/foo, pero quiero importarlo como danirod.es/pkg/foo en vez de como github.com/danirod/foo. De acuerdo con la especificación, mientras hacer una petición web a https://danirod.es/pkg/foo devuelva un documento HTML que lleve su etiqueta meta, Go sabrá resolver el paquete.

Entrando en detalle, Go resuelve un paquete haciendo una petición HTTP usando protocolo HTTPS, usando como base de la URL el nombre del paquete, pero también añadiendo el queryparam ?go-get=1 al final. O sea, que hacer un import de danirod.es/pkg/foo hace que Go pida esos metadatos desde https://danirod.es/pkg/foo?go-get=1.

El formato de la etiqueta go-import, según el spec es:

<meta name="go-import" content="import-prefix vcs repo-root">

Donde import-prefix es la raíz del paquete (ahora explico), vcs es un string que indica el tipo de control de versiones que tiene que usar Go para descargar el paquete (por ejemplo, "git" o "svn"), y repo-root es la URL al repositorio desde el que clonar el paquete.

Por ejemplo, ante el siguiente ejemplo:

<meta name="go-import" content="danirod.es/pkg/foo git https://github.com/danirod/foo">

La etiqueta le permite a Go saber que para obtener el paquete danirod.es/pkg/foo tiene que hacer git clone https://github.com/danirod/foo. Otros sistemas de control de versiones como Fossil o Bazaar también están soportados.

Sobre la cuestión del import-prefix, su principal propósito es indicar cuál es la raíz real del proyecto. Esto es importante si se trata de resolver un import de un subpaquete concreto, como pueda ser golang.org/x/crypto/argon2. En ese caso, Go tratará de descargar el paquete inicialmente desde https://golang.org/x/crypto/argon2?go-get=1, por lo que especificar como import-root el nombre golang.org/x/cyrpto le señaliza a Go que en realidad lo que está intentando importar es un subpaquete de otro.

Mi experiencia con Vaultwarden

Posted on 10/02/2023 por Dani

En abril del año pasado, migré mi gestor de contraseñas desde KeePassXC a Vaultwarden. Mi objetivo en esta entrada de blog es hablar de mi experiencia con este software y cómo me he adaptado a él en los últimos meses, desventajas y también ventajas de haber migrado a Vaultwarden.

Bitwarden es una solución cloud para guardar contraseñas en línea. Siempre he sido escéptico ante este tipo de herramientas cloud, debido al riesgo que podría suponer colocar las llaves que protegen toda tu vida digital en una máquina que no controlas. Incluso aunque Bitwarden sea abierto y hable de las formas que tienen de cifrar la información, me resulta un poco incómoda la idea de que los datos se guarden fuera de mi control.

Vaultwarden es una reimplementación alternativa de toda la API de Bitwarden en Rust. Bitwarden dispone de varias aplicaciones oficiales para PC, móvil, tablet y navegador que interactúan con la nube de Bitwarden usando distintas APIs, y Vaultwarden se ocupa de volver a implementar toda esa capa de servicios. De este modo, si configuramos un cliente o extensión de Bitwarden para que, en vez de hablar con el servidor central, hable con nuestro servidor alternativo, todo funcionará, porque el cliente no sabrá que está hablando con un Vaultwarden en vez de con un Bitwarden normal. Además, es mucho más ligera en consumo de recursos que una instalación on-premises de Bitwarden.

Mi manera de desplegar Vaultwarden es en mi infraestructura personal. Lo despliego como un servicio de Docker más, que en condiciones normales consume menos de 100 MB de RAM y que tiene un consumo de CPU mínimo. Si se abre en un navegador web la dirección en la que está instalado, se puede utilizar desde la web, y se ve como un Bitwarden normal y corriente, aunque conectado con la instancia local en vez de con los servidores principales de Bitwarden. Todas las aplicaciones de Bitwarden oficiales tienen una forma de personalizar el endpoint de conexión, lo que permite usar las aplicaciones oficiales de Bitwarden para Windows, Mac, Linux, iOS y navegador con un servidor propio en vez de con el servidor central.

Sobre KeePassXC, me parece un software excelente y seguiré recomendándolo. Ya hablé en el pasado en este blog de mi experiencia y mi forma de usar KeePassXC para todo, tanto como almacén de contraseñas como bóveda para guardar archivos secretos, como certificados, claves RSA y otro tipo de información que me gustaría almacenar de forma segura en un gestor de identidades. Ante todo, es una forma simple de que usuarios avanzados tengan su primer contacto con este tipo de aplicaciones, tan recomendadas bajo mi punto de vista.

Sin embargo, una de las razones que motivó mi cambio a Vaultwarden fue el hecho de que cuando tienes varios dispositivos, tengas que ocuparte manualmente de hacer la sincronización entre cada dispositivo. Debido a que KeePass es una aplicación offline, requiere un archivo de base de datos (KBDX) para funcionar, y opcionalmente un archivo de clave (KEY) para desbloquear la base de datos. Si bien puedes utilizar herramientas cloud externas para mantener sincronizada la base de datos entre múltiples dispositivos e incluso entre móviles y tablets, el proceso es manual y requiere usar aplicaciones separadas. En el peor de los casos, puedes sincronizar manualmente las bases de datos cada vez que hagas una modificación a la misma.

Y es que en realidad tener que depender de servicios de sincronización cloud externos que funcionan mal resultaba problemático. Cuando utilizaba Android, utilizaba KeePass2Android para guardar mi base de datos en Dropbox y mantenerla sincronizada con otros ordenadores conectados a la misma cuenta de Dropbox. KeePass2Android era un software tan valioso que una vez al año hacía una donación para agradecer el esfuerzo de mantenerla. En mi etapa iOS, al final las herramientas de sincronización eran más limitadas y acepté copiar las cosas a mano, algo que resultaba problemático cuando una contraseña se quedaba en un dispositivo pero todavía no se copiaba al resto.

El fin de mis streams grupales de pomodoro

Posted on 03/02/2023 por Dani

El 28 de febrero de 2023 transmitiré mi último stream de cowork o pomodoro grupal en Twitch. En esta ocasión no es un parón temporal, es un parón definitivo. Seré la primera persona que echará de menos los lazos que se han formado en el chat de mi canal de Twitch, donde este tipo de streams se ha mantenido a modo de servicio público durante más de un año por la labor que hacía y por la comunidad de estudiantes y trabajadores remotos que se ha formado, pero creo que es necesario dejar de hacerlo por varias razones.

Antes que nada, para cualquier persona venida de fuera que se pregunte qué quiere decir todo esto de los streams de pomodoro, se viene una definición. Twitch es una plataforma que aunque está asociada al mundo de los videojuegos, en los últimos años se ha abierto mucho a cualquier tipo de contenido que caracterice por ser en directo, incluyendo cosas como los deportes, los podcasts y otro tipo de conversaciones o la programación.

Una de las comunidades más interesantes de Twitch es, sin duda, la etiqueta Pomodoro. Es exactamente lo que puede parecer. En vivo se transmite un reloj de pomodoro, y de algún modo la mayoría de espectadores se pone de acuerdo para sincronizarse con el mismo. A modo de salvapantallas, quien opera el canal activa su cámara para que el resto del mundo le vea trabajar y estudiar, y el chat participa trabajando y descansando de forma sincronizada y escuchando la música de ambiente tranquila que acompaña este tipo de transmisiones.

Durante los últimos 13 meses, aproveché por las mañanas mi canal de Twitch para emitir este tipo de contenido. La razón por la que empecé a hacer esto fue por pura necesidad. A principios de 2022 me mandaron a trabajar a casa en la oficina debido a un nuevo brote a nivel nacional de coronavirus. Para entonces, mi capacidad de trabajar de forma remota estaba severamente impactada por la fatiga de haber sufrido estrés en el trabajo en todos los meses anteriores, sin forma de concentrarme. Después de descubrir este tipo de contenido en Twitch, decidí iniciar el mío propio bajo la idea de que si transmitía durante varias horas una imagen en vivo de mi webcam, por lo menos me forzaría durante un tiempo a estar concentrado en el trabajo. Eventualmente, el brote se controló, pero yo continué manteniendo ese tipo de streams después de haber aprendido a trabajar mejor y más efectiva de forma remota debido a la nueva subcomunidad que se estaba formando en paralelo a la de mis streams de programación.

Tal como he empezado a anunciar esta semana, he decidido que el próximo día 28 será el último cowork que transmita por mi canal de Twitch. Aunque no descarto pregrabar de vez en cuando segmentos de pomodoro y subirlos a YouTube, dejará de haber emisiones en directo de ese tipo y a partir del 1 de marzo de 2023, mi canal de Twitch se centrará más en los streams de programación de las tardes, los cuales van a cambiar de horario igualmente para hacerlos antes, algo que también me está sentando bien debido a que acabar mis streams tan de noche me venía impidiendo descansar correctamente desde hace meses.

¿Por qué? Existen varias razones al respecto. Ninguna tiene que ver con cuestiones profesionales respecto al trabajo que hago, empleadores o clientes. Nadie me ha afeado nunca que haga este tipo de contenido, ni tampoco ahora mismo estoy teniendo problemas de ese tipo por transmitirlos y trabajar así.

Desde hace tiempo noto que el proceso de arranque cada mañana del stream es lento y que me supone perder entre 5 y 15 minutos configurando todas las aplicaciones necesarias para hacer funcionar el vivo, ajustar las opciones que la cámara olvida cada vez que se apaga el ordenador, montar la música… al cabo de un mes, se acumulan varias horas perdidas en montar una y otra vez los mismos programas y las mismas configuraciones. Si multiplicamos esas horas por lo que cuesta una hora de mi tiempo en la tarifa estandar que le aplico a nuevos clientes en este momento, el resumen es que al mes estoy perdiendo dinero cada día. Bastante, de hecho, podría estimarlo en unos 1000 euros al mes tranquilamente.

Al margen de eso, no solamente trabajo como desarrollador de software autónomo. También produzco cursos y le dedico una parte de la semana a avanzar mis proyectos en línea sobre cursos y a hacer investigación sobre temas. Es imposible de hacerlo si todo mi material de grabación está bloqueado por el propio stream de pomodoro, ya que no puedo usar ni el software de grabación, ni el micrófono, ni en ocasiones la cámara, lo cual está dificultando las cadenas de producción y es parte de la razón por la que algunos de mis proyectos en línea parece que se han estancado en los últimos meses, porque no tengo la posibilidad de rellenar horas muertas a lo largo de la semana.

Esto es especialmente problemático los días en los que, que por cuestiones de época baja, me he encontrado falto de trabajo externo pendiente para el día, y con una agenda vacía antes de la hora de comer. No tengo trabajo externo que facturar, pero tampoco puedo ponerme a avanzar la grabación de cursos porque tengo las herramientas de grabación ocupadas. Todo lo que puedo hacer es destinarlo a investigación sobre futuros temas y a adelantar tiempo escribiendo notas sobre temas futuros; o a formarme por mi cuenta para poder adquirir conocimiento que pueda explotar en el futuro, lo cual me hace sentir incómodo debido a que lo que estoy transmitiendo esencialmente es una webcam en la que se me ve durante varias horas haciendo scroll con el ratón en un navegador y anotando cosas, lo cual transmite una imagen que no es la que quiero enseñar y que creo que me puede hacer daño a título personal y profesional.

En sí la comunidad no es complicada de gestionar en la mayoría de ocasiones, pero hay excepciones. Antes decía que los streams de pomodoro funcionan bien cuando todo el chat está de acuerdo en seguir los ciclos de trabajo-descanso y conoce cómo funcionan las reglas, pero no siempre es así. En ocasiones (cada vez menos, sobre todo desde que abandoné la categoría de Just Chatting y empecé a parasitar la categoría de Software Development, pese a no ser un stream de programación como tal), recibo la visita de simpáticos amigos que vienen simplemente a calmar su aburrimiento de formas un poco raras con el chat. Aunque ya he aprendido a aplicar el protocolo, siguen siendo momentos tensos debido a que realmente juego en desventaja ante un troll que aparece en el chat en medio de un momento donde el stream debe transmitir focus y aparentar normalidad para el resto de personas. A la larga este tipo de vigilancia continua acaba cansándome.

Finalmente está la cuestión de cómo a nivel personal me afecta el tener la cámara puesta todo el día y el estar emitiendo 9 horas de contenido como éste. A nivel físico, no poder tener la flexibilidad de realmente descansar y levantarme durante los descansos debido a que hay que generar interacciones con la gente del chat durante el descanso está acabando conmigo. Sí, podría simplemente levantarme y poner vídeos en bucle durante el descanso, pero después de varias pruebas, no es por eso por lo que viene la gente.

No poder despejar la cabeza durante un rato cuando estoy bloqueado en el trabajo porque hay que pulsar botones en el centro de emisión después de cada sesión me agota y me estresa. Y, lo más importante, me está empezando a costar saber cuándo estoy en vivo y cuándo no, debido a que al durar este tipo de streams todo el día, empiezo a tener problemas para cambiar el chip a modo stream en las primeras horas del día, y a salir del modo stream después de cerrar. Ciertos patrones como tener que comprobar varias veces los LEDs de los micrófonos y las cámaras porque no me termino de fiar de si realmente están activas o no son una pista de que igual algo no estoy haciendo bien.

En definitiva, me he visto obligado a poner punto y final porque he empezado a encontrarlos poco sanos y poco buenos para mí, y eso significa que estoy fallándole a la razón por la cual los empecé en primer lugar: para servirme de ayuda.

Durante este año, este tipo de streams han servido de refugio y de lugar de encuentro para mucha gente, y me alegra haber podido mantener este servicio público tanto tiempo en marcha por su utilidad, pero también es importante recordar que dentro de todas las personas a las que debe ayudar, también estoy yo.

Años después, he conseguido dejar Twitter, ¿por qué?

Posted on 27/01/2023 por Dani

Antes que nada, decir que esto no tiene nada que ver necesariamente con el cambio de rumbo que ha tomado Twitter desde que Elon está al mando. Ni siquiera lo dejé cuando estaba de moda hacerlo: en noviembre, cuando todo el mundo anunciaba que era el fin y ponía su handle de Mastodon en la bio o en el username. Me he esperado a hacerlo ahora, cuando ya no es guay.

En fin, la cuestión es que en mis vacaciones de navidad, probé a cerrar sesión de Twitter en todos los navegadores y a eliminar las aplicaciones allá donde estuviesen instaladas. Y una de las cosas que noté al poco tiempo de dejar de mirar Twitter es una mejora en mi bienestar, en mi ánimo y también un poco en mi salud mental.

Durante enero he entrado de vez en cuando a publicar mensajes forzados con actualizaciones sobre mi contenido en YouTube y a dar un par de RTs sueltos, pero sin hacerle mucho caso. Durante este tiempo seguí recibiendo menciones e interacciones, las cuales por otro lado me daba pena ignorar. Por eso el otro día, después de pensarlo, llegué a la conclusión de que si iba a dejar de mirar la app, había que hacerlo de forma menos silenciosa. Así que, primero exporté una copia de seguridad de mis tweets en todas las cuentas de mis proyectos (las cuales, por cierto, se tardaron bastante en generar, probando que tal vez algo ha pasado ahí), y después de borrar todos los tweets con una herramienta de borrado masivo, anuncié tanto en @makigas como en @nosgustalinux que las cuentas estaban fuera de servicio y que no iba a leer ningún mensaje que me llegase.

La bandeja de interacciones de esta cuenta no está siendo leída.

🔵 Puedes encontrar cursos y más material para aprender gratis y en español a programar que voy generando en https://youtube.com/@makigas y en https://makigas.es.

🟢 Puedes encontrar las noticias y tutoriales sobre GNU/Linux, BSD y otros sistemas libres que voy generando en https://youtube.com/@nosgustalinux y en https://nosgustalinux.es.

Durante mucho tiempo pensé que con simplemente ajustar y medir al milímetro el tipo de cuentas que se seguían y con las que se interactuaba permitiría conseguir una aplicación más higiénica de usar. Pequeños hacks, como que bloquear a @MomentsES (están muy callados desde hace unos meses, me pregunto por qué será… 🤭) provocaba que dejasen de salir noticias en la sección de tendencias, o que configurar la ubicación en un país cuyo idioma no hablase, como Japón o Rusia, permitía por lo menos usar la aplicación sin tantas distracciones debido a que las tendencias y las noticias me eran imposible de leer.

Sin embargo, no es suficiente, por varias razones.

En primer lugar, el enemigo está en casa. Al principio mediante lista secreta, y luego finalmente dando follow de forma pública, mi timeline de Twitter consistía en cuentas sobre programación y también otros canales que se dedican a la creación de contenido. Un poco para seguir a los creadores que sí me interesan, y también medir el termómetro de lo que ocurre en general.

Incluso en el caos de una red social como esta, también existe cierto orden, cierta jerarquía y ciertas subcomunidades. Twitter-Tech es una de ellas. Y como subcomunidad, también está expuesta a sus propios dramitas, sus propios debates mensuales sobre si HTML es un lenguaje de programación o no, y todas esas cosas.

En ocasiones, tampoco necesitas ir fuera a buscar la crispación porque la crispación está dentro, cuando un tema polémico se convierte en el tema del día y todo el timeline se convierte en indirectas jocosas referentes al mismo tema, lo cual a la larga tampoco resulta demasiado sano de leer.

Por otra parte, el buscador tampoco está demasiado lejos. Una mente curiosa y unas ganas de saber si «todo ahí fuera es tan malo como parece» es suficiente para acudir al terrible buscador, poner una palabra clave correcta, y hacer doomscrolling durante minutos leyendo lo que podría ser el inminente fin del mundo, o alguna chorrada similar.

Finalmente, lo que hay tampoco es tan bueno. Si algo es excesivamente bueno o sobresaliente, probablemente lo vea enlazado desde alguna fuente de información más prioritaria. Cada día se publican muchísimos mensajes, pero queda saber cuántos de ellos son realmente importantes y cuántos vamos a olvidar en cuanto pasemos a otra cosa.

¡Pero Dani! Como creador no deberías pensar eso, se supone que tú quieres lo mismo para tus proyectos. Precisamente ahora vamos con los problemas que hay en el otro lado, después de este separador.

La cuestión es que como creador de contenido tampoco estoy satisfecho con la forma en la que hay que tener presencia en varias redes sociales simplemente porque cada una se especializa en una cosa concreta y nada más. Hay que usarlas todas a la vez para poder contar una película completa, y también hay que ocuparse de enlazar desde cada red social a todas las demás y ocuparse periódicamente de reenviar gente de un sitio a otro. Personalmente, lo encuentro agotador y un derroche de tiempo que le podría dedicar a otras cosas.

Además, cosas como las que vimos en diciembre cuando Twitter intentó prohibir cualquier enlace a Instagram, TikTok o Mastodon son la prueba de que, realmente, este tipo de conglomerados existen simplemente porque las plataformas no se oponen, pero que en el momento en el que a una red le deje de parecer bonito que existan caminos con otra red, se sentirá libre de cortarlos. Parece que es nuevo, pero es sabido desde hace años que YouTube tiene un problema con Twitch, y que en vez de buscar opciones para atraer gente a su plataforma, encuentra más sencillo simplemente penalizar a la gente en vez de atraerla.

Sobre mi opinión sobre el tipo de contenido que tendría que generar para promocionar mis proyectos en Twitter, por ejemplo, tampoco voy a decir mucho de forma pública. Se podría resumir en que no soy fan de la cultura actual de crear hilos sobre cualquier cosa simplemente para tener esa dosis de relevancia durante el día. No voy a desarrollar porque tendría un conflicto de intereses al llevar proyectos similares en internet a los de otras personas que sí hacen esto, lo cual puede hacer que suene innecesariamente violento cualquier cosa que diga por mi parte.

En definitiva, Twitter tampoco era una red social en mi caso demasiado productiva y que desde el punto de vista de mis proyectos me robaba demasiado tiempo de cara a gestionarla y a crear ganchos para conseguir traer gente de una red a otra todo el tiempo.

Echaré de menos el sentimiento de comunidad en algunas cosas, por ejemplo, en las menciones más directas, pero por otra parte, las pocas cosas buenas que tienen no permitían contrarrestar todas las partes negativas que exponía. He mejorado bastante en bienestar este mes y me gustaría mantenerme así.

Mi opinión después de probar Miniflux (RSS)

Posted on 20/01/2023 por Dani

El mes pasado, durante mis vacaciones, reemplacé mi instancia local de TinyTinyRSS por una instancia de Miniflux. Ambas son aplicaciones cloud que actúan como lector RSS. Ya hablé la semana pasada sobre las razones por las cuales prefiero mantener mi cliente RSS en un servidor, pero se resume en que la falta de sincronización entre dispositivos que tienen Mozilla Thunderbird o QuiteRSS los hace inaceptables si unas veces leo cosas con mi PC y otras con mi móvil.

TinyTinyRSS es un pepino de software. No tiene otro calificativo. Es un software que voy a seguir recomendando y del que voy a seguir hablando bien. Es flexible, potente y tiene una interfaz de usuario web avanzada que recuerda a la de otros clientes RSS mayores y llenos de funciones. Tiene filtros con los que se pueden marcar como leídas o borrar entradas que cumplan unas condiciones (ideal para filtrar ruido), y también tiene un sistema de plugins extensible para agregarle nuevas funciones.

Sin embargo, no todo es bonito. TinyTinyRSS también es desafortunadamente un software que tiene bugs. En particular, dos veces se me ha corrompido la instalación y he tenido que tirar de copia de seguridad para rescatar mi lista de feeds y vaciar la base de datos, perdiendo el historial, las entradas marcadas como favoritas, y también parte de mi tiempo. 2 veces en 4 años tampoco es demasiado desde el punto de vista estadístico, pero sí es cierto que es una molestia que preferiría evitar.

Existen otras razones por las cuales he acabado cansándome del comportamiento de este software. Fundamentalmente tiene que ver con el proceso de instalación, especialmente ahora que está basado en Docker. Iba a contarlas aquí, pero son muchas y por otra parte se supone que quiero hablar de Miniflux hoy, así que corto y pego en otro borrador y ya lo dejo para otro día.

Miniflux es otro lector RSS cloud que puedes ejecutar en un servidor y ponerle a cargo de revisar periódicamente si los sitios que sigues tienen novedades, dejándolas en una base de datos para que las puedas leer cuando puedas.

Su interfaz web es excesivamente minimalista, pero a cambio esto le permite ser compatible con teléfonos móviles y otro tipo de pantallas táctiles, e incluso se puede instalar como PWA para un acceso más conveniente en la pantalla de iOS o Android. Tiene las funciones que se pueden esperar de este tipo de programas, e incluso tiene un sistema que permite ajustar dinámicamente la frecuencia con la que mira si una web tiene novedades según la cantidad de posts que publica a la semana (para sitios de noticias diarias cambia la frecuencia a 1 hora como mucho, y para sitios personales no suele mirar más allá de una vez cada pocos días).

Además, se puede desplegar en un único binario de Go. En mi caso, lo corro desde Docker y consume bastante menos recursos que lo que consumía TT-RSS, lo que permite aliviar la carga del servidor y lo que espero que en algún momento me ayude a ahorrar recursos y tal vez hacer downgrade a una máquina más pequeña si veo que no me hace falta tener una máquina tan potente.

También tiene APIs que me permiten usar Miniflux como un backend cuya interfaz web apenas reviso, sino que me conecto desde mi propio cliente de escritorio o de móvil como quien lee el correo. En este caso, Miniflux implementa la GReader API. Es una API mucho más flexible y potente y que me permite hacer cosas que antes no podía hacer, como suscribirme rápidamente a una fuente desde mi móvil o cancelar una suscripción si deja de interesarme un sitio web. Antes, tenía que entrar al panel de control web para poder hacer esto.

Al haber pasado a usar la GReader API, ahora puedo usar más clientes de escritorio, por lo que también he cambiado los programas que uso para leer mis noticias. En Mac y en iOS/iPad, me he pasado a NetNewsWire, que es un cliente libre y gratuito. NewsFlash también es compatible con la GReader API, de modo que en GNU/Linux he podido seguir usando NewsFlash cambiando únicamente una cuenta online por otra.

Sigo pensando que para meterse en el mundo del RSS existen opciones mucho más accesibles, como Feedly, y como he dicho varias veces, es mi opción recomendada. No obstante, para alguien que quiera ensuciarse las manos y ocuparse de instalar servicios autoalojados en su VPS o en su nube propia, Miniflux es fácil de instalar y depende únicamente de si mismo y de una base de datos PostgreSQL en la que volcar el estado de la aplicación, y que aunque tiene una interfaz web que no a todo el mundo le va a gustar, tiene más formas de ser accesible desde otras aplicaciones para no sufrirla tanto.

¿Por qué utilizo un lector RSS cloud?

Posted on 13/01/2023 por Dani

De cara a un futuro post que quiero hacer sobre clientes RSS y algunos cambios que he hecho en mis flujos de lectura durante estas vacaciones, he querido hacer un post de preámbulo. Si hago posts más cortos y centrados en un tema, me será más sencillo de escribir y revisar, y también más fáciles de referenciar en el futuro.

Hoy quiero hablar sobre por qué mi forma de consumir feeds RSS es la que es. En mi servidor web tengo instalado un cliente RSS que se ocupa de comprobar los blogs a los que estoy suscrito, 24×7, y almacenar las novedades en una base de datos a la espera de que las lea cuando tenga tiempo.

Y aquí lo que quiero es explicar por qué trabajo así y no simplemente descargo en mi ordenador una aplicación como QuiteRSS o NetNewsWire, o alguna de las que encuentre en la tienda de aplicaciones de mi móvil. Ya me ocupé de contar en un post anterior por qué no uso Feedly, pese a que me sigue pareciendo la forma más sencilla de no complicarse tanto la vida, y a que lo sigo recomendando para que alguien que quiere meterse en el mundo del RSS pueda tener un primer contacto sin pegarse cabezazos contra la pared.

Sobre por qué utilizar un servidor para mis feeds RSS y no simplemente descargar una aplicación en mis dispositivos, precisamente la razón es porque utilizo varios dispositivos. Si usase simplemente una aplicación de escritorio o una aplicación de móvil que no esté sincronizada con ninguna nube, acabaría teniendo cuatro aplicaciones RSS diferentes con cuatro listas de blogs diferentes y donde habría que marcar cuatro veces cada cosa que vea como leída.

Si utilizo una aplicación cloud, como es TinyTinyRSS en mi caso, puedo tener un único cliente RSS en un servidor, al que accedo desde todas mis pantallas. Por la mañana en el PC leo un artículo y lo marco como leído, y por la noche desde el móvil aparecen más artículos nuevos pero no el que ya he leído por la mañana.

Hasta ahora he venido usando TinyTinyRSS. Es una de las aplicaciones web de software libre más usadas de cara a lanzar un lector RSS en un servidor, y también una de las más veteranas. Tiene una interfaz web que permite leer artículos desde cualquier navegador web y es lo suficientemente avanzada como para cubrir los casos de las personas más «power users», que se parece a lo que era en su momento Google Reader (porque, de nuevo, la única forma de medir un cliente RSS es compararse a Google Reader, incluso aunque hayan pasado 10 años desde su cierre).

Sin embargo, una de las cosas que valoro de TinyTinyRSS es que tiene una serie de APIs que permiten crear integraciones con otras aplicaciones. Con ellas, es posible utilizar algo que no sea el navegador web para leer noticias de una forma más flexible y bonita según las circunstancias. Por ejemplo, la interfa web original de TT-RSS es un poco complicada de usar en teléfonos móviles, precisamente porque está pensada para ser usada en aplicaciones de escritorio.

De modo que en mi móvil tengo una aplicación aparte, que se parece a una aplicación de teléfono móvil normal, con letras y botones grandes, pero que cuando se abre, se comunica con mi servidor para ver qué noticias hay descargadas ahí y mostrármelas como si fuese un cliente de correo. A medida que las voy leyendo, va empujando esa información al servidor para que luego me salgan como leídas en el resto de dispositivos que uso.

En MacOS he venido usando Reeder. Normalmente sería de pago, pero he tenido la suerte de pillar en el pasado tanto la versión 3 como la versión 4 en momentos en los que estaban temporalmente gratis. En mi móvil y en mi tablet también tengo Reeder. Juraría que por Reeder para iOS sí he pagado en el pasado, aunque ahora no lo recuerdo.

Cuando uso GNU/Linux, NewsFlash también tiene conector para interactuar con mi instancia, y es la aplicación que utilizo para interactuar con mi servidor y leer mis noticias desde una aplicación con el look and feel de GNOME.

O al menos así ha sido hasta esta navidad, pero esto es algo que dejo para otro día. Entre tanto, aquí he hecho un diagrama para resumir este lío.

¿Por qué no uso Feedly pese a que lo sigo recomendando?

Posted on 06/01/2023 por Dani

Fui usuario de Google Reader hasta prácticamente su fecha de cierre. El cierre de Google Reader es curiosamente uno de esos eventos traumáticos donde pese a que ya han pasado prácticamente 10 años desde su cierre, para quienes lo usábamos sigue siendo algo que incluir en la tarjeta de presentación. «Hola, me llamo Dani y fui usuario de Google Reader».

¿Qué fue Google Reader?, se preguntará tal vez alguien que se perdió esa época del internet mágico. Era un lector de RSS. Por ponerlo en contexto de forma breve, RSS es un protocolo que permite que una página web comunique de forma automatizada de sus novedades, por ejemplo, las últimas noticias publicadas en un periódico o los últimos posts publicados en un blog.

Un lector RSS es un programa con el que podemos «suscribirnos» a varios sitios web, y se ocupará cada pocos minutos u horas de consultar mediante protocolo RSS si la web tiene algo nuevo que no hayamos visto todavía, y que lo mostrará en pantalla como si se tratase de un cliente de correo.

La mayoría de clientes RSS hacen un buen trabajo al detectar novedades duplicadas y así saber qué hemos visto ya y qué no, y tiene memoria suficiente como para guardar docenas de artículos que podemos leer vorazmente cada día, o dejar un tiempo esperando en una cola de lectura que finalmente podemos marcar como leída de golpe y sin compasión.

Tras su desaparición, estuve un par de años utilizando Feedly. Feedly es uno de esos servicios que suelo recomendar a cualquier persona que quiera probar el mundo del RSS. Es un servicio en el que puedes tirar un par de páginas web que quieras tener al día, y que cada vez que una de esas páginas publique algo interesante te lo mostrará al abrir la aplicación.

Quizá el mayor atractivo de Feedly es el motor de descubrimiento, y la posibilidad de encontrar nuevos sitios exclusivamente a través de feeds RSS. Esta es también una de las principales razones por las que, como digo, seguiría recomendando Feedly a personas que estén entrando ahora en el mundo del RSS.

Sin embargo, pese a que lo sigo recomendando, realmente no uso Feedly. Nunca terminé de cogerle gusto. Por lo menos en este caso veo más difícil que desaparezca, debido a que aunque tiene un modo gratuito, también tiene algunas limitaciones que te invitan a pagar por él si vas a usarlo mucho. Y mientras haya gente que siga pagando por el servicio, en principio debería seguir habiendo dinero para que Feedly siga existiendo como empresa ofreciendo su producto. A estas alturas Feedly ya ha vivido más años que Google Reader, así que parece que lo están consiguiendo.

Mi principal problema con Feedly está en la cantidad de características que ofrece, y en lo confusas que son algunas de estas características. No deja de ser un software cloud, y qué software cloud hoy en día puede denominarse un «servicio» si no está constantemente reinventándose y agregando nuevas funciones o cambiando su forma de ser cada pocos años para mantenerse fresco.

Durante mis últimos tiempos con Feedly, la mayoría de funciones que me encontré, como el algoritmo de prioridades o las funciones de equipo (¿por qué activarlas para todas las cuentas en vez de preguntarme si las quiero en primer lugar?), me resultaban muy complicadas de utilizar. No quiero que un algoritmo filtre las noticias por mí; precisamente la gracia del RSS es ver, como si fuese un cliente de correo, cada uno de los artículos nuevos de los sitios que explícitamente he solicitado seguir.

En definitiva, creo que Feedly es un buen servicio, y que también es un producto que le puede gustar a la mayoría de personas que solo quieren una forma simple de consumir contenido sin complicarse con aplicaciones. Sin embargo, después de un tiempo utilizándolo, descubrí que no es para mí, y lo sustituí por otro tipo de aplicaciones que sí me eran más prácticas.

También, todo hay que ponerlo en su debido contexto. La época de Feedly y de la muerte de Google Reader es también la época del boom de las redes sociales. En esa época, como la mayoría de personas, había movido mi forma de enterarme de la actualidad a las redes sociales, fundamentalmente Twitter y Facebook, así que apenas consultaba el RSS. Sólo hace un par de años, probablemente 2018 o 2019, que volví a preocuparme por esta dieta informativa mía y decidí volver a estar más pendiente del RSS.

El plan para 2023 es no programar

Posted on 30/12/2022 por Dani

Evidentemente, es mentira. Trabajo como desarrollador, así que si no programo, no entra el dinero. Mi plan es no programar fuera del trabajo. Excepto que eso también es mentira, porque sí voy a seguir programando fuera del trabajo. Y aun así, siendo freelance, ¿qué puedo considerar trabajar? Voy a explicarme un poco.

En 2022 han hecho 15 años desde que tiré mi primera línea de código. Ni siquiera había terminado la secundaria y no tenía muy claro nada de lo que estaba haciendo. Todo el código hecho por esta época está perdido, porque no hacía copias de seguridad de nada y perder carpetas era algo demasiado frecuente en mí por entonces. Por un lado, esto es algo que da un poco de pena debido a que se tratan de las primeras cosas que hice y pueden tener algo de valor simbólico. Por otro… tampoco es que ese valor sea mucho en cualquier caso.

Siempre me he caracterizado por ser una persona cuya forma de trabajar es crear prototipos de cosas, para probar tecnologías, para hacer experimentos, o para crear una maqueta de algo serio que pueda ser explotado más adelante. Estos prototipos siempre se han hecho tirando líneas de código a partir de la nada, en muchas ocasiones con poco diseño y poca arquitectura detrás, allá donde sea posible. En algunos casos, como mucho una pensada a alto nivel y poco más.

Sin embargo, nunca he invertido tiempo de verdad en simplemente sentarme a aprender bases, o a aprender despacio sobre alguna tecnología concreta, con calma y sin intentar tratar de responder desde el principio a la pregunta ¿qué puedo hacer con esto? Cuando llevas demasiado tiempo en esto, la tentación de tratar de buscar usos prácticos para cualquier tecnología desde el primer momento es un riesgo real que puede impedir ver algunas cosas con claridad.

Esto es lo que busco durante 2023, nada más y nada menos. No digo que no vaya a programar cosas fuera de mi trabajo, porque tengo algunos compromisos abiertos que cerrar y algunos incentivos para acabar algunos proyectos que tengo abiertos ahora mismo. Parte de la razón por la que me hice freelance es para poder construir producto propio que pueda distribuir por mi cuenta, y quiero terminar algunas de las ideas en las que he empezado a trabajar.

He guardado ya algunas listas de reproducción, algunos libros y algunos artículos que quiero revisar y mi objetivo es tomar parte del tiempo que de otro modo pasaría programando cosas por mi cuenta y convertirlo en tiempo para aprender con calma durante 2023. Veremos a finales de año cuánto he avanzado con este plan.

Actualizada clave GPG

Posted on 21/05/2022 por Dani

La clave pública GPG que había subida a mi página de contacto caducaba mañana. Esta clave la uso fundamentalmente para firmar releases en GitHub y otras plataformas, aunque alguna vez he recibido correo firmado y alguna vez hasta correo cifrado.

El mes pasado extendí el periodo de validez por un par de años más pero olvidé actualizar también la subclave de cifrado. Hoy he extendido la fecha de validez y he subido una versión actualizada de la clave. No termino de comprender cómo funciona un keyserver, o si la actualización verdaderamente es efectiva, o qué pasa con las versiones antiguas de la clave, pero en principio he testeado el archivo que hay subido en https://danirod.es/contact/pgp.asc desde otro ordenador y todo está funcionando, así que bien.