El Plugins Directory de Moodle cierra tras 15 años: ya está en modo solo lectura y el lunes 20 de julio lo reemplaza el Moodle Marketplace. La novedad no es que se pueda cobrar por un plugin —eso ya se hacía por fuera, con tu propia web y tu pasarela—, sino que ahora hay una tienda oficial y centralizada. Con su comisión: un 20% el primer año y un 25% después. Y ojo, porque no es como Apple: la App Store se lleva el 30% pero te pone todo el sistema de cobros; aquí el cobro lo montas tú con Stripe y eres el merchant of record, así que impuestos, soporte y devoluciones corren de tu cuenta. Ese 25%, comparado con el 30% de Apple, en el fondo es más caro, porque te da mucho menos. Todo esto me toca de cerca: tengo un plugin de Jitsi publicado gratis en ese directorio y llevo tiempo dándole vueltas a si monetizarlo y, sobre todo, dónde: dentro del Marketplace con su peaje, o por mi cuenta. Y encima son plugins GPL, así que montarías una tienda para vender algo que, por diseño, el comprador puede regalar. Lo que cambia de fondo no es que ahora se pueda ganar dinero con Moodle: es que ahora hay una caja registradora oficial en medio, con su peaje.

Estos días medio internet grita que la UE ha aprobado el escaneo obligatorio de tus mensajes. No es verdad: lo aprobado es la prórroga del escaneo voluntario, no el que rompe el cifrado de extremo a extremo (ese sigue atascado). Pero cómo lo han aprobado es lo que de verdad debería preocuparnos: recuperaron por un procedimiento de urgencia algo que el Parlamento ya había rechazado, con un mecanismo en el que hacían falta 361 votos para frenarlo y esos votos no se reunieron. No salió porque una mayoría dijera que sí, sino porque a la oposición le faltaron los números para decir que no. Y eligieron esa vía para esquivar el debate y las enmiendas. Es el ensayo general de cómo colarán la versión dura el día que se pierda el foco. No te fijes solo en qué se aprueba: fíjate en cómo.

Moodle 5.2 traía en las notas de la versión una línea que no entendí: soporte para OpenTelemetry. Tiré del hilo y acabé montando observabilidad para mi propio servidor. Cuento qué es en cristiano —las trazas, esa cascada que te enseña por dónde se va el tiempo en cada petición—, cómo lo monté en casa sin mandar nada a la nube, y los tres sustos del camino: el motor de PHP que olvidé reiniciar, cómo medir un solo sitio sin tocar a los vecinos, y la herramienta de observabilidad que venía sin contraseña. La lección: dejé de adivinar por qué mis páginas van lentas, pero cada pieza nueva que añades al servidor es también una cosa más que mantener, actualizar y, sobre todo, proteger. Autoalojarse tiene una factura que se paga en atención.

Mi servicio de videollamadas, un Jitsi propio, corre en el Mac mini sobre OrbStack. Apple ya trae contenedores nativos en macOS —sin Docker ni máquina virtual pesada— y yo soy de los que prueba lo nuevo el primer día… pero esta vez he frenado. Cuento los dos muros que me lo impiden: no hay forma nativa de orquestar varios contenedores y el reenvío del UDP que necesita el vídeo era lo más inestable. Repaso qué se movió en la última WWDC (incluido Container Machine, que tampoco encaja) y la lección que me llevo: para un experimento, lo nuevo sin pensarlo; para algo en producción que usa gente, lo aburrido que funciona le gana a lo nuevo que casi funciona. Que una cosa funcione no es excusa para dejar de mirar qué viene detrás, pero tampoco razón para cambiarla antes de tiempo.

Una tarea de mi plugin de Moodle dejó de generar los justificantes de asistencia a examen: terminaba con un críptico "no se ha proporcionado ningún documento" y reintentaba sin parar. Lo curioso es que no fallaban todos, solo los alumnos nuevos. La universidad había cambiado de directorio sin avisarme y había dejado de dar de alta a los nuevos en el antiguo, que era justo al que mi código seguía preguntando (y que seguía respondiendo, por eso no saltaba ninguna alarma). Era fin de semana y no tenía las credenciales del directorio nuevo… hasta que caí en que Moodle ya tenía esa conexión configurada y funcionando. La lección va más allá de Moodle: cuando el sistema sobre el que trabajas ya tiene algo configurado, reutilízalo en vez de duplicarlo. Una sola fuente de verdad.

La semana pasada hablé de las herramientas con correa. Esta semana la correa ha tirado: un gobierno ordenó apagar el modelo de inteligencia artificial más potente jamás abierto al público y la empresa tuvo que desactivarlo para todo el mundo de un día para otro. Lo uso para una idea incómoda para quien construye encima de estas herramientas: dependes de algo que un tercero puede apagar cuando quiera. No te deja tirado del todo —puedes bajar a un modelo menos potente del mismo proveedor— pero el mejor desaparece sin avisar. Y no va de una empresa ni de un gobierno concretos: en Europa lo vivimos por el otro lado, con la nueva Siri que no llega por la regulación. Incluida una confesión: yo también llevo la correa.

Hoy se puede usar el modelo de inteligencia artificial más potente jamás abierto al público… pero domado. Uso ese lanzamiento como excusa para una idea más grande: cada vez trabajamos con herramientas más capaces de lo que sus propios creadores se atreven a soltar. Vienen con bozal (se niegan a hablar de ciertos temas), con vigilancia (te quitan la opción de pedir que no guarden nada) y al doble de precio. ¿Por qué tanta correa? Porque la herramienta, suelta, encuentra fallos de seguridad ella sola: muerde de verdad. Y esto no va de una marca concreta, va camino de ser el patrón. Una reflexión sobre el estado de la IA contado a través de cómo nos la entregan.

Durante años, una parte de mi plugin de Jitsi para Moodle hizo algo de lo que no me enorgullezco: en lugar de devolver datos, fabricaba páginas web enteras. El servidor escribía a mano, como una larguísima cadena de texto, el HTML y cientos de líneas de JavaScript. Este episodio va de la idea pequeña que lo cambió todo al refactorizarlo: el servidor debe entregar datos, no comportamiento. Te cuento cómo partí una función de 900 líneas en tres capas (datos, plantillas y módulos), qué destapó esa separación (un caché que tapaba una consulta que recorría la tabla de registros de todo el sistema, 21 veces más lenta de lo necesario; código muerto; una cápsula del tiempo de la app móvil) y, sobre todo, para qué sirve un trabajo que no se ve por fuera: es el cimiento exacto que el nuevo Moodle, el que va hacia interfaces reactivas con React, va a necesitar.

Llevo un tiempo sin sacar novedades en mi plugin de Jitsi para Moodle, y es a propósito: estoy pagando deuda técnica. Dos archivos enormes —uno de casi tres mil líneas— troceados en clases pequeñas, con los tests por delante. ¿Por qué ahora? Porque Moodle va a cambiar sus tripas (React entra en el núcleo con la 5.2, y los viejos callbacks dan paso a los hooks) y prefiero llegar preparado que a remolque. Por el camino, tres lecciones: los tests por delante encuentran bugs que no buscabas (aparecieron seis o siete, y hasta una "mina" que renombraba la actividad del profesor), desconfía de tus propios atajos de verificación, y "mover no es mejorar". Y una reflexión final sobre el trabajo invisible: ese que nadie aplaude, pero que decide si tu proyecto sigue vivo dentro de tres años.

Una batallita de sysadmin con dos incidencias encadenadas. Acto 1: lancé una actualización de macOS en mi Mac mini servidor y, al resetear la configuración de energía, el equipo se durmió toda la noche provocando caídas fantasma (y un revelador HTTP 000 que no era ningún hackeo). Acto 2: al día siguiente, la propia herramienta que me avisa de los problemas —el plugin de Telegram— se desbocó al 100% de CPU, con su mecanismo de autoprotección anulado justo por el fallo que debía resolver. Y un epílogo sobre cómo reportar bien un bug: el fallo ya estaba documentado, así que en vez de duplicar, aporté tres datos nuevos a un issue existente. Empieza con una disculpa por el volumen bajo de los dos episodios anteriores, ya corregido.