El desastre de julio o la importancia de la monitorización de errores en tiempo real
TL;DR: perdí varias semanas de nuevos usuarios por un bug aleatorio en la nueva versión de VS Code. Lección: implementa pronto monitorización de errores en tiempo real, si puedes.
Desarrollar un proyecto en solitario es duro. Te toca encargarte del desarrollo, el diseño, el marketing, el soporte y unas cuantas cosas más. Tienes que malabarear tareas y prioridades, y a veces alguna se escapa.
Durante la primera semana de julio, una actualización aleatoria de VS Code cambió el sistema interno de autenticación e hizo que las versiones existentes de GitByBit entraran en un bucle infinito nada más arrancar. Básicamente, nadie podía usar el curso hasta que se resolviera el problema. Sin enterarme de nada, yo estaba trabajando en la próxima práctica de pull requests (que está muy bien y se publicó la semana pasada, por cierto).
En algún momento, alguien por fin informó del problema en GitHub, así que pude arreglarlo y publicar una versión nueva. Pero básicamente perdí varias semanas de nuevos usuarios, porque no podían usar el curso.
Cuando te das cuenta de que tu proyecto lleva un par de semanas sin funcionar.
La mayoría de mis otros proyectos son apps web normales, servidas desde mi propio servidor. Si están hechas con frameworks populares como Laravel o React, puedes integrarlas fácilmente con algún sistema de informes de errores en tiempo real, como Sentry o Rollbar. Así, cuando ocurre un error, recibo el aviso al instante, puedo subir la corrección a mi servidor y todos los usuarios la reciben enseguida. Depurar el problema también es más fácil, porque tengo acceso a los logs del servidor y puedo ver qué ha fallado exactamente.
Sin embargo, GitByBit no es una app web normal. Está la extensión de VS Code y la versión web, cada una con frontend y backend separados. Todo está hecho con tecnologías distintas, así que montar informes de errores no es tan fácil como meter una clave de API de Rollbar en algún punto de la configuración. Hasta ahora, todos esos sitios enviaban telemetría a mi servidor principal, donde se guardaba en un log centralizado.
Pero claro, no había ningún sistema de monitorización que me avisara de errores en tiempo real. Así que tenía que abrir y leer esto para enterarme:
No es muy legible, salvo que hables klingon.
Puedes revisar logs así de vez en cuando, pero, salvo justo después de publicar una versión, no es demasiado práctico. La mayor parte del tiempo no pasa nada malo, así que dejas de mirarlos con regularidad. Quizá los revisas una vez a la semana o algo así, pero luego te lías con otras cosas y se te olvida.
En realidad, sí... Pero también tienes que monitorizar los logs, no solo recogerlos.
Das por hecho que, si algo va mal, acabarás enterándote por los usuarios o lo verás en los logs tarde o temprano. Algo de verdad hay en eso, pero puedes tardar bastante en detectar el problema y, para entonces, quizá ya has perdido a mucha gente que no pudo usar el curso por culpa del bug. Eso es exactamente lo que le pasó al proyecto en julio.
Oye, Alex, ¿no se supone que eres un desarrollador con experiencia? ¿Por qué no implementaste un sistema de informes de errores en condiciones desde el principio? ¿Por qué has esperado hasta ahora?
¡Buena pregunta! Ese es el reto de desarrollar en solitario: hay muchísimo por hacer y solo tienes dos manos (esperemos). ¡Hay que PRIORIZAR! Además:
- Ya tenía logs básicos, así que podía ver qué iba mal si los miraba.
- He estado ocupado con todo el trabajo de contenido, así que dedicar semanas a implementar la infraestructura de backend no parecía una prioridad enorme.
- Esto es acceso anticipado, así que la gente más o menos espera encontrarse algunos problemas y bugs. Yo confiaba en que, si algo iba mal, los usuarios me avisarían y podría arreglarlo rápido.
Pero ahora que el curso está ganando popularidad, supongo que toca tener una forma mejor de monitorizar errores y problemas en tiempo real.
PostHog al rescate
Llevo varios años intentando desgoogleizarme, pero en mis proyectos sigo usando sobre todo Google Analytics para hacer seguimiento de las interacciones de los usuarios. Hace poco descubrí PostHog y decidí probarlo. Combina varias funciones que necesito: seguimiento de eventos, grabación de sesiones e informes de errores. También tiene un plan gratuito generoso, así que puedo usarlo en mi proyecto de acceso anticipado sin preocuparme por los costes, al menos de momento. Además, tienen una mascota erizo muy mona llamada Max, que me tiene ganado.
Si Max no te cae bien, eres mala persona.
Las directrices para desarrolladores de VS Code prohíben usar tus propios scripts de analítica dentro de la extensión, sobre todo por motivos de rendimiento y seguridad. Sin embargo, la telemetría que recopilas mediante la API de VS Code sí entra dentro de lo permitido, así que puedes recibirla en tu servidor y luego reenviarla a PostHog o a cualquier otro servicio de analítica. De esta forma, puedes seguir registrando interacciones y errores en tu extensión de VS Code sin saltarte las directrices.
Ahora los errores se recopilan en un formato legible, así que puedo ver qué ha fallado y dónde. Los errores duplicados se agrupan, de modo que puedo ver a cuántos usuarios afectaron.
Cada error incluye bastante detalle para ayudarte a depurar el problema de fondo. Cuando un error queda corregido, puedes marcarlo como resuelto para que no ensucie la lista.
Esto resolvió el problema de legibilidad y seguimiento, pero seguía necesitando una forma de recibir avisos sobre errores nuevos en tiempo real. PostHog tiene un sistema de alertas integrado que puede enviarte notificaciones por Discord, Slack u otros canales cuando aparece un error nuevo. Así puedo enterarme de cualquier problema al instante y solucionarlo rápido.
Ahora, si oigo un flujo constante de BOOP!!! desde Discord, sé que el curso se ha roto. Entonces puedo mirar rápido el panel de PostHog y ver qué pasa.