La caída de Freenode

Minientrada

Veo estos días la caída de Freenode como quien ve la caída del imperio romano. Cuando empecé a programar, Freenode era el lugar en el que todo proyecto abierto que se precie debía participar. Hoy muchos proyectos ya no están en IRC: migraron a Matrix, Discord o Slack, y los que aún quedan, huyen estos días de FreeNode como gacelas ante los leones.

Nunca me gustó la interfaz de IRC. Siempre tuve miedo de equivocarme y mandarle un mensaje privado a alguien con mi contraseña intentándome comunicar con NickServ. Los modos, las contraseñas en plano, ChanServ. Admito que IRC es de las pocas tecnologías «clásicas» que menos pena me da que desaparezcan.

Organizar los e-mails de GitHub

Minientrada

Pude poner orden hoy en la carpeta de archivo en la que normalmente vuelco todos los e-mails de notificaciones de GitHub una vez los he procesado, y que estaba empezando a acumular un tamaño no poco considerable. (Sobre por qué archivo todo en vez de eliminar algunos tipos de notificaciones, es otro asunto.)

En las notificaciones que tienen que ver con un repositorio (como un issue, un PR o una release), GitHub rellena la cabecera List-Id con el identificador del repositorio del que procede. List-Id es una cabecera estandar que la mayoría de clientes de correo usa para reconocer listas. En el caso de GitHub, la List-Id de un repositorio es <repo>.<user>.github.com.

De modo que con un poco de análisis, he podido organizar automáticamente por carpetas todas las notificaciones, para que las notificaciones de makigas/clank (cuya List-Id será clank.makigas.github.com) vayan a Archivo/github.com/makigas/clank, o las del repositorio danirod/rectball vayan a Archivo/github.com/danirod/rectball.

Un par de filtros automáticos se van a asegurar de que futuras notificaciones vayan directamente a esas carpetas, ya que normalmente las notificaciones llegan en momentos en los que no les puedo dedicar tiempo y luego es complicado escarbar mi bandeja de correo para localizar todos estos correos cuando sí tengo tiempo de ponerme con ello.

Hemos corregido errores

Alguien hace bastantes años decidió en Apple que sería estupendo que en la aplicación App Store las aplicaciones del catálogo tuviesen un lugar significativo para explicar a sus usuarios las novedades y cambios que trae una actualización. Por ejemplo, Reeder (mi lector de feeds):

En la sección Novedades, Reeder muestra lo que ha corregido o agregado.

Encuentro insultante la cantidad de aplicaciones no indie que se limitan a mostrar en cada actualización un «hemos corregido problemas» pero no cuentan realmente las novedades. Twitter es un ejemplo de esto:

¿Qué hicimos? ¡Mejoras! ¿Para qué? ¡Para ofrecerte un Twitter cada vez mejor!

Por ejemplo, la semana pasada actualicé a iOS 14 e iPadOS 14. Una de las novedades es permitir cambiar el navegador por defecto que se usa cuando sigues un enlace recibido en chat, email o similares. Descubrí casi por accidente que mi Firefox ya tenía esta función disponible a base de abrir las opciones cada día y ver si ya estaba ahí la opción. Si tuviese que fiarme de las notas de versión que hay en la AppStore, jamás me hubiese enterado:

Las novedades de la supuesta actualización que presuntamente añade una función nueva. Si toco Versiones previas tampoco veo nada diferente a esto.

Lo mismo se puede decir para otras apps como YouTube para iOS. Pago YouTube Premium, lo que me permite escuchar vídeos de YouTube de fondo incluso con la pantalla apagada o mientras miro otras aplicaciones, y estoy esperando la futura actualización que agregará modo PiP, para poder seguir viendo el vídeo en una esquina del iPad o el teléfono mientras miras otras cosas. Me temo que ese día me enteraré antes por los titulares de los sitios web de actualidad que por las notas de versión de la AppStore:

Y todas son así.

🙄