makigas 6.1.1

Normalmente no subiría a producción un martes dado que el sitio web ha empezado a recibir más tráfico que hace unos meses y suele haber usuarios concurrentes entre semana. Actualmente subo a producción los sábados, que es cuando menos tráfico recibo. Sin embargo, quería sincronizar los cambios que hay en la web desde hace unos días con los de las notas de versión.

Nuevo flujo de trabajo

Para no tener que hacer batch-push los sábados y matarme a hacer commits los sábados, a partir de esta versión voy a optar por trabajar con un pull request separado que me permita ir encadenando los commits que quiero subir en el próximo despliegue. El texto de ese pull request me permitirá también ir preparando las notas de versión que luego van a la release. Quizá en algún momento pueda automatizar esto (spoiler: lo dudo).

Disculpa si el vídeo no tiene notas de versión

Sigo aportando notas de versión al contenido de la web. Para sorpresa de nadie, cuando una página tiene más texto en vez de únicamente ser un título, una descripción y un vídeo, los buscadores lo presentan mejor, y la página tiene más oportunidades de llevarse una impresión y un potencial clic porque ahora puede abarcar un mayor número de términos de búsqueda. SEO 101.

A medida que vayan pasando las semanas tendré datos más limpios, pero todo parece indicar que publicar notas de versión en una lista aumenta bastante el tráfico que llega a ella. Ejercicio para lectores ávidos: en la siguiente imagen, que muestra el tráfico de todas las páginas de vídeo de uno de mis cursos, ¿qué día cargué artículos de texto completos, bien formateados, con negrita, cursiva con ejemplos de código?

Para el contenido que todavía no tiene notas de versión, he metido en la web un banner que avisa que el contenido todavía no tiene notas de versión. También muestra un sondeo con botones, que están conectados mediante eventos analíticos a Plausible, con la idea de poder saber cuánta gente pulsa alguno de los botones y en qué página lo hace. En el tiempo que lleva en producción, ya ha empezado a ser utilizado, y es un input más que me va a ayudar a determinar la prioridad del proceso de curación, junto al volumen de tráfico en la web y en YouTube Analytics.

Mostrar la transcripción si está disponible

Ahora que estoy empezando a aportar más transcripciones para el contenido, y que estoy revisando el catálogo viejo, me interesa incluir también las transcripciones en todas las páginas, incluso las que tienen unas notas de episodio correctas. Como la transcripción suele estar peor formateada (y a veces es un único párrafo), la estoy mostrando plegada por defecto.

Este bloque se está mostrando en todas las páginas que tienen transcripción, incluso cuando no tienen notas de versión, por lo que es otra forma de poder incorporar texto a la web incluso cuando no hay unas notas de versión disponibles. Todavía queda por comprobar a largo plazo si afecta al SEO, aunque dado que está plegado por defecto, voy a asumir que no debería influenciar demasiado; si me equivoco en mi predicción, por lo menos estaré más feliz.

Corrección en las listas que duran menos de una hora

Para sorpresa de nadie, había un bug en el contador que dice cómo de larga es una lista de reproducción cuando esta dura menos de 1 hora, ya que la palabra “horas” va grabada a fuego esperando que luego el reloj use el formato H:MM (por ejemplo, 0:45), cuando en realidad está usando el formato MM:SS (por ejemplo, 45:12).

Para listas de menos de 1 hora, ya se muestra correctamente la duración.

Corrección en las páginas canónicas de vídeo y lista

Otra cosa que no debe ser buena para el SEO es tener más de una página canónica. En la siguiente captura de pantalla, Google está indexando una página que utiliza identificadores numéricos en la URL.

Esto se ha corregido y ahora tratar de visitar una página de vídeo cuando en la URL va algún número en vez de algún slug hará una redirección transparente hasta la página correcta a la página correcta.

Actualizaciones de runtime y dependencias

Novedades más importantes:

• Las GitHub Actions y el container de Docker ahora usan Ruby 3.2.1.
• En las últimas versiones de Rubocop, el linter marca como incorrectos los archivos de test que sólo tienen un caso pending. He aprovechado para borrarlos en previsión de que no los voy a implementar.
• He actualizado esbuild, lo que ha exigido cambiar el buildscript porque ha cambiado la API JavaScript.