Cuando el campus es lo que falla

Trabajo sobre Moodle LMS: despliegue, performance, actualizaciones de versión, integraciones con los sistemas que ya tenés, y desarrollo de plugins a medida. Sobre infraestructura propia o en la nube, siempre con el código a la vista.

Los síntomas con los que suelen llamarme

Nadie contrata «optimización de plataforma». Llaman porque pasa algo concreto, y casi siempre es alguno de estos:

  • El tablero tarda. Ocho segundos en abrir, y el primer día de cursada directamente no abre. Nadie midió nunca dónde se va ese tiempo.
  • La actualización quedó postergada. Dos o tres versiones atrás, y cada vez da más miedo. La versión que corre ya no recibe parches de seguridad.
  • Se cae cuando más se usa. Inscripciones, parciales, cierre de notas: justo los tres días del cuatrimestre en los que no puede fallar.
  • Los avisos no llegan. Salen por correo, caen en spam o nadie los abre, y después el alumno dice que no se enteró.
  • Está aislado. Las altas se cargan a mano porque nadie integró el campus con el sistema de gestión académica.
  • Nadie sabe qué tiene instalado. Plugins que puso alguien que ya no está, sin inventario y sin saber cuáles siguen manteniéndose.

Qué hago con eso

Performance, medida antes de tocar nada

Primero se mide y después se cambia. Perfilado de las consultas que realmente duelen, caché correctamente configurada, revisión de la base y del almacenamiento de archivos, y el cron —que es el que hace la mitad del trabajo invisible de la plataforma y el que más veces encuentro mal puesto o directamente sin correr.

Actualizaciones de versión sin apostar

Ensayo de la actualización en una copia del sitio real, no en una instalación limpia, que es donde no aparece ningún problema. Inventario previo de plugins y temas, y la lista de cuáles sobreviven a la versión nueva. Moodle 5.0 movió el árbol servido dentro de public/, y eso rompe supuestos de despliegue, de reglas del servidor web y de scripts propios que venían funcionando desde hace años.

Integraciones

Altas y bajas automáticas desde el sistema de gestión, autenticación única contra el directorio que ya usan, y salida de datos hacia los tableros de la institución. Con la API de servicios web cuando alcanza, y con código propio cuando no.

Desarrollo a medida

Plugins escritos como pide el proyecto: con sus pruebas, sus cadenas de idioma, su proveedor de privacidad y sus actualizaciones de base de datos. Un plugin sin pruebas es una deuda que se cobra en la próxima actualización.

La prueba, y está publicada

Podés no creerme nada de lo de arriba y verificarlo vos mismo. Publiqué message_whatsapp, un plugin de canal que manda las notificaciones del campus por WhatsApp: cola propia para que nada salga a la red durante el pedido del usuario, plantillas aprobadas, reporte de entrega, pantalla de estado y consentimiento explícito de cada persona.

450 pruebas unitarias y 10 escenarios de navegador, en verde sobre Moodle 4.5 y 5.2 a la vez, contra PostgreSQL y MariaDB. Software libre bajo GPL v3: el código está entero y cualquiera puede leerlo, usarlo o forkearlo sin pagarme nada.

Eso es lo que quiero decir con «con el código a la vista». No es una captura de pantalla en una presentación: es un repositorio que podés clonar ahora.

Cómo empezamos

Casi nunca conviene arrancar contratando horas a ciegas. Conviene saber primero qué hay, y para eso está la auditoría técnica a precio cerrado: te queda un informe con lo que encontré y en qué orden lo atacaría, lo arregle yo o lo arregle tu equipo.

Si ya sabés lo que necesitás, escribime directamente.