Un exceso de newsletters

Minientrada

Twitter anunció la compra de Revue, y ha pasado a modo gratuito buena parte del servicio, bajando también los costes de la versión premium. ¿Que qué es Revue? Una alternativa a Substack.

Ya he hablado sobre estas cosas. Las newsletters en sí no están mal como alternativa a las redes sociales, pero resulta complicado de gestionar todo lo que se recibe a larga escala. Pueden quedarse en la bandeja de entrada esperando días su momento de ser leídas, pero mi experiencia haciendo esto es que al final elimino de golpe 10-15 e-mails una vez por semana. Aparte, le veo varios problemas:

  • No es anónimo, porque tengo que dar mi e-mail para formar parte de una lista.
  • No es gratis para quien publica, porque muchos proveedores cobran cuotas por tener más de un determinado número de suscriptores en esa lista. Esto quita voces interesantes que podrían crear una newsletter y no lo hacen porque hay que pagar, o provoca que algunas newsletters busquen estrategias de monetización (esperemos que sin involucrar hacer cosas feas con la lista de e-mails).
  • Algunas newsletters se han “desuscrito” de mí automáticamente simplemente porque, como mi e-mail lo leo en modo texto plano, no puedo descargar y ver los pixel beacons, por lo que cuento en sus listas como un seguidor inactivo.

Mis recuerdos de Endomondo

Minientrada

Vengo de solicitar en la web de Endomondo un ZIP con todos mis entrenamientos cargados en la plataforma.

Endomondo dejó de estar disponible el 31 de diciembre de 2020 y los usuarios que tuviesen entrenamientos cargados tienen 3 meses para solicitar un ZIP con sus datos antes de que se eliminen permantentemente el 31 de marzo de 2021.

En la época de las aplicaciones de seguimiento de carrera por el GPS del móvil, Endomondo fue la primera satisfactoria que probé y con la que empecé a despegar. La empecé a usar cuando le pillé los ritmos a correr después de estar usando un par de semanas Adidas MiCoach, cuando más que centrarme en distancias y tiempos me centraba en entender ritmos (más deprisa, más despacio…)

Eventualmente, Endomondo empezó a funcionar mal, a la vez que Runtastic se empezó a poner de moda debido a la integración con Facebook y el poder mostrar mapas, y poco más se pudo hacer. El cambio fue inevitable. Que UnderArmour comprase Endomondo para integrarla en su portafolio de apps y luego empezar a hacer experimentos raros no ayudó a mejorarla.

Pantallazo de Endomondo
Pantallazo de Endomondo en Google Play. Probablemente en algún backup tenga mis propias capturas de pantalla de Endomondo, pero tendría que buscarlo.

Un año federando en Mastodon

Se cumple un año desde que configuré toot.danirod.es y lancé mi primer toot. ¿Alguna conclusión que sacar este año?

Evidentemente, cuando decidí probar Mastodon, quise configurar mi propio nodo. Podría haberme dado de alta en mastodon.social o en algún nodo popular, pero consideré que si el propósito de Mastodon era participar en una red federada, no tenía mucho sentido entonces unirse a un nodo centralizado y ya de por sí con un exceso de población.

¿Configuración técnica? Un dolor de muelas. Mastodon es un software que requiere correr varios microservicios. La aplicación web principal, el servicio de streaming, y el Redis que alimenta ese servicio de streaming. Por supuesto, la única opción oficial es Docker. Probar Mastodon prácticamente requirió cambiar la arquitectura de mi servidor web, un Debian en el que todo estaba instalado sobre la propia máquina raíz, para dockerizar toda la infraestructura. Tuvo sus cosas buenas, como que una vez dockerizado todo, la migración de Debian 8 a Debian 10 se hizo en un suspiro -a costa de un cierto overhead en el consumo de recursos de mi máquina que me sigue molestando a día de hoy, y algún contenedor reiniciándose o fallando cada poco tiempo.

Otro dolor, el almacenamiento. Si vas a participar en la red federada tienes que tener en cuenta que los toots que recibas de otras instancias se van a guardar en tu propio sistema de almacenamiento. Tu base de datos debe estar preparada para guardar toots, y en función de cómo de grande sea tu red, habrá más o menos toots. Y si esos toots tienen adjuntos, también se va a guardar una copia en tu sistema de almacenamiento, local o S3. Así que mejor contar con sitio.

¿Ha intentado mi máquina acceder a contenido ilegal? Por el momento, tampoco me consta; aunque tiene trampa porque no estoy participando en relés ni nada por el estilo. Para mi nodo de Mastodon, si no tootea una cuenta que siga, o no lo retootea una cuenta que siga, no existe. Considero que este punto es esencial, porque es uno de los puntos que más me preocupa, debido a que no siempre se puede controlar el origen de los toots, y debido al anonimato que a veces entregan las instancias, te pueden comprometer con contenido cuestionable o directamente ilegal.

Para que mi instancia descargue una copia de un toot, lo tiene que publicar una cuenta que siga. Las cuentas que sigo pueden hacer retoot y eso implica que también se descargan toots que compartan. El único riesgo está en las respuestas que reciban los toots de las personas que sigo (o yo mismo), ya que eso provoca que Mastodon se descargue información sobre esa cuenta, y si tiene toots fijados, también sus toots fijados.

Seguridad. ¿He sido hackeado? Hasta el momento no. Es un nodo pequeño con el registro desaprobado en el que sólo existe mi cuenta y las de algunos de mis proyectos. Me ocupo de tener mi docker-compose actualizado, así que no voy muchas versiones por detrás.

¿Estoy contento con Mastodon? Sí y no. Resulta curioso e innovador poder participar en una red descentralizada en la que sé que los datos están bajo mi control. Si acaso, mis únicos problemas en este año con Mastodon son:

  • El descubrimiento. Seguramente sea peor porque no participo en relés, pero es dificil descubrir cuentas nuevas. Alguna vez he cotilleado los feeds públicos de otros servidores como Fosstodon, BSD Network o Functional Café, en busca de contenido interesante, pero no siempre es fácil encontrarlo. Esto puede ser visto como una ventaja o una desventaja en una red federada.
  • La carga. Mastodon pone a mil mi pobre servidor. He tenido que alquilar más almacenamiento para no tener el disco siempre lleno. Y sin embargo el uso que hago de él es residual. Pleroma es una alternativa que consue muchísimos menos recursos, y aunque ambos proyectos hablan ActivityPub y hay sobre el papel un camino de transición para cambiar Mastodon por Pleroma sin que nadie note la diferencia ni pierda seguidores o seguidos, es complicado debido a que son esquemas de datos diferentes y hay que ir con cuidado.
  • La utilidad de los mensajes. Instancias como Mastodon.social son mucho más políticas, pero es un tipo de politiqueo que no encaja con mi manera de pensar ahora mismo. Como digo, las redes en las que más bicheo son Fosstodon, BSD Network y Functional Café. Se ha convertido en una red en la que enterarme de cosas y datos interesantes sobre computación y programación.

Emitir en Twitch vs Emitir en YouTube

Minientrada

Durante 2020 he pasado bastantes horas emitiendo en vivo por internet a través de YouTube, y eso ha cambiado mucho mi percepción ante el arte de emitir en directo frente a lo que hacía en años anteriores.

Eso significa que he empezado a ver Twitch con otros ojos. Sobre todo comparado con lo que tengo más acostumbrado actualmente.

No sé si voy a quedarme en Twitch o no, pero he encontrado algunas cosas interesantes sobre la plataforma que lo hacen un poco más atractivo comparado con YouTube.

  • No quemo la marca. Ciertos contenidos que tengo en mente emitir entran en conflicto con lo que representa la marca makigas y no me parece prudente emitirlos en mi canal de YouTube.
  • No estropeo tanto las estadísticas de mi canal de YouTube. Este es uno de los puntos que más me interesan, porque últimamente estoy intentando subir contenido de calidad que me facilite el plan de expansión, el cual debería llegar este año por fin. Como no estropeo las estadísticas; por lo tanto:
  • No enfado al algoritmo. El algoritmo de YouTube se ofende fácilmente y con los planes a futuro que tengo para mi canal, eso no me interesa, porque eso podría suponer menos impresiones y menos ocasiones de aparecer en los buscadores. (A mi canal no le interesa la relevancia en el tiempo, le interesan los buscadores)

Y sobre todo, un aspecto que no pensé hasta 2020 que me iba a importar tanto:

  • No le tengo que prestar tanta importancia al VOD. Quizá haya contenido que valga la pena preservar de forma seleccionada, pero conservar íntegramente y de forma infinita streams de 2 horas de duración en los que tampoco pasa gran cosa.

Hasta siempre, «Asignar app a espacios»

Una opción discreta pero útil que había en versiones anteriores de macOS era la posibilidad de fijar ventanas de una aplicación a todos los espacios o escritorios virtuales. Así, daba igual en qué escritorio virtual te colocases, podías tener algunas ventanas mostrarse en todas partes. Útil si organizas ventanas en escritorios pero hay momentos en los que necesitas mostrar una ventana concreta en todas partes. (Por ejemplo, en el escritorio 1 tienes una hoja de cálculo, en el escritorio 2 un navegador web, pero quieres tener visible la calculadora tanto en el escritorio 1 como en el 2).

Pues bueno, parece que esta opción ha desaparecido en la última versión de macOS. Quería fijar mi llamada de Google Meet a todos los escritorios virtuales, para tener el botón del micrófono a mano mientras miraba cosas, pero al ir al menú contextual ya no aparece.

Captura de pantalla del dock de macOS.
Esto es lo que veo al hacer clic derecho en el icono.

No encuentro comentarios al respecto en Reddit, lo cual me resulta llamativo porque siempre hay alguien en Reddit que critica este tipo de regresiones argumentando que «es el fin de macOS como lo conocemos y Apple no nos escucha» o cosas así.

Pero en el manual de usuario de macOS sí que ha desaparecido. En el manual de instrucciones de macOS 10.15 hay un epígrafe llamado «Asignar apps a espacios». En el manual de instrucciones de macOS 11.0 ya no está esa sección.

Triste.

El origen de AWS

Enlace

Un hilo de Twitter (meh) escrito por alguien que estuvo ahí para verlo nacer y crecer.

«En el año 2000, servidores Sun recién estrenados aparecían en eBay a 10 centavos a medida que las start-ups empezaban a caer (esto era pre-AWS, así que tenías que montarte tu propio datacenter). […]»

Como retailers, siempre nos enfrentamos a una gran estacionalidad. El tráfico y el beneficio siempre surgía en noviembre y diciembre. Jeff empezó a pensar: tenemos este exceso de servidores por 46 semanas, ¿por qué no empezamos a alquilarlo a otras empresas?

El hilo de @DanRose999

Supongo que en términos de recursos, hoy es un poco más eficiente que tu empresa quiebre, si el cadáver que dejan tus servidores puede ser aprovechado por la siguiente empresa a la que alojen… 🤔

discordjs-voicerole

Enlace

Una pequeña librería Node.js para Discord.js que hice este fin de semana para facilitar esconder y mostrar canales cuando entras a un canal de voz. Ya está integrada en mi bot, pero he considerado más oportuno extraer esa funcionalidad a una librería separada para poder reusar la función en otros bots.

Este código fuente vive en GitHub y no en git.danirod.es por la misma razón por la que existe este código fuente en primer lugar: por visibilidad. Por eso tampoco está en mi namespace personal, sino en el de mi canal de YouTube.

Pequeños detalles sobre los átomos en Erlang

La semana pasada empecé a publicar mi curso de Elixir en YouTube, y la recepción está siendo buena e incluso algo mejor de lo esperado. Intento ir lento para ponerlo fácil a quien nunca haya trabajado con este tipo de lenguajes, pero a la vez intento ir rápido para satisfacer a quien esté intentando seguirlo según lo subo (aunque casi sería mejor esperar un par de meses antes de verlo del tirón…)

Uno de los vídeos que subí ya habla sobre los átomos. Es un tipo de datos interesante para representar valores constantes que equivalen a su propio nombre. Al principio puede sonar raro. Al menos a mí me lo sonaba cuando vi por primera vez el concepto en Racket durante la universidad. En Racket, se les llama quotes, y se utiliza la tilde en vez de los dos puntos. Por ejemplo, 'banana, pero el principio es el mismo.

Una cosa que para no hacer un vídeo de nivel introductorio tan complejo no cuento, es que en la máquina virtual de Erlang, cada vez que se declara un átomo, se registra en una tabla de átomos (o Atom Table), que se comporta como un diccionario de átomos conocidos por la máquina virtual.

Si las operaciones que trabajan comparando átomos son rápidas (por ejemplo, x == :ok), lo es porque una vez que todos los átomos están indizados, a nivel interno la máquina virtual de Erlang no trata a un átomo como su valor, sino como su posición en la tabla, así que al final los átomos se gestionan también como números que representan posiciones, y sólo en el momento de comunicar un átomo al exterior es que vemos su representación alfanumérica.

Hablo siempre de alfanumérico porque un átomo contiene letras y caracteres del alfabeto, pero es importante distinguir que los identificadores en Elixir entienden de Unicode, y que por lo tanto, otros alfabetos diferentes también pueden ser codificados en átomos (:Βόρειος, mismamente).

Otra particularidad interesante es que el recolector de basura de Erlang nunca va a recolectar átomos que hayan caído en desuso. De modo que con el tiempo, la máquina virtual de Erlang va a tender a absorber todos aquellos átomos que hayan sido empleados. Dado que en Erlang ciertas construcciones como los propios nombres de los módulos o las listas de argumentos también se codifican con átomos, estas construcciones también van a tomar espacio.

Además, la tabla no es infinita. Los límites declarados por la máquina de Erlang avisan que, salvo que se modifique como parámetro al iniciar la máquina, como mucho se podrán declarar 1.048.576 átomos en la tabla. ¿Qué pasará cuando se alcance ese límite? Que la máquina fallará, como podemos probar rápidamente con este pequeño script:

for x <- 1..1048577, do: x |> Integer.to_string |> String.to_atom

Es una forma un poco fea y barata de generar 1.048.577 átomos a partir de cadenas de caracteres que generamos a su vez a partir de los números de un rango. Cuando ejecuto esto en mi máquina, la máquina de Erlang falla:

$ elixir foo.exs 
no more index entries in atom_tab (max=1048576)
Crash dump is being written to: erl_crash.dump…done

2020 en lo deportivo

¡Feliz año! Iba a resumir qué tal me ha ido haciendo deporte este mes, pero al ir a mirar el post del mes pasado he visto que con esto de perder la contraseña del WordPress nunca llegué a contar qué tal me fue noviembre, y es una pena.

En noviembre batí mis marcas y corrí más de 170 kilómetros. Hice otra media maratón. De hecho, casi hago varias porque ha habido varios entrenamientos que acabaron por encima de los 18 kilómetros. La funcionalidad de los logros de Strava resulta tan atractiva como adictiva, porque a principios de mes me apunto a todos los que puedo y luego se trata de intentar completarlos antes de que acabe el mes: correr 100 kilómetros en el mes, hacer un ejercicio de 21,1 kilómetros…

Diciembre ha sido un mes más complicado. Súmale que al dedicarle las primeras horas de la mañana a organizar mis livestreams del Advent 2020, todo lo que me ha quedado libre después del trabajo ha sido ya en tarde bien caída, el que con el frío que ha hecho la mayor parte de este mes, se hace poco apetecible salir. “Sólo” han caído unos 120 kilómetros, con su media maratón de turno para obtener el logro del Strava.

Sigo perfeccionando los recorridos urbanos por los parques y las ciclovías de mi municipio. Se supone que el objetivo era ensayar para el día que cierren mi municipio por los contagios de coronavirus y tenga prohibido practicar trail (todo el mundo sabe que el trail es peligrosísimo, no como juntarse en un bar con gente sin mascarilla… 🙄), pero con el mal tiempo que ha estado haciendo este último mes, se agradece no preocuparse por un invierno de ir esquivando barrizales.

Entonces, ¿cómo ha acabado el año? Mejor de lo esperado. La barrera psicológica de los 1000 kilómetros se cruzó a principios de diciembre y el año acaba con 1070 kilómetros en las suelas. El objetivo de este año era correr una carrera popular, pero como sabe dios en qué año volverá a ser seguro organizar una carrera popular (igual hay que camuflarlo como concierto o entrega de premios… 🙃), no ha quedado otra que hacer un cambio a mitad de curso.

Con algo de ironía, Strava ofrece un resumen del año igualmente. Se trata de una métrica un poco trucada. Los que no teníamos nada para preservar la forma lo máximo posible durante el arresto domiciliario de primavera estamos en desventaja frente a los profesionales que habrán estado tirando de máquinas, rodillos y esas cosas. Sin embargo, el resultado final que marca son 1217,3 kilómetros repartidos en 130 horas. Parte de esta marca se debe a los entrenamientos de marcha, que aun no siendo running, los registro igualmente en otra categoría de Strava.

A nivel de forma física, noviembre ha sido un mes bueno y diciembre ha sido un peor mes. No tengo muy claro todavía por qué. Cansarme a los cinco kilómetros corriendo en mayo se podía explicar en la falta de forma física tras el arresto soviético. Cansarme a los cinco kilómetros corriendo en diciembre es más difícil de explicar, sobre todo después de todo lo que he corrido en octubre-noviembre.

Aquí está el Gráfico de Mierda (TM) hecho en cinco minutos con el iPad en el Apple Numbers. Cada banda azul representa una salida. El área verde representa la suma de los kilómetros corridos en los últimos 7 días. La línea roja es el total de kilómetros corridos en 2020.

Ahora a por el 2021.