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.
TL;DR: ¡Ya puedes practicar cómo crear pull requests en GitByBit!
¿Alguna vez has encontrado un bug en el código de otra persona y has pensado: "¿por qué no han arreglado esto todavía?" Abres un issue, esperas... y no pasa nada.
La cosa es que ya no tienes por qué esperar.
Puedes arremangarte y aportar tú la corrección. Envías una pull request, consigues que se fusione y, de repente, toda la gente que usa esa librería se beneficia de tu trabajo.
Nunca sabes qué puedes sacar de una pull request.
Un bug real, una corrección real
La práctica empieza con una situación muy reconocible: tu app de seguimiento deportivo falla cuando alguien intenta registrar su actividad en un campo de golf usando distancias en yardas. La app no sabe convertir yardas a metros y se rompe. La corrección es sencilla: añadir la conversión que falta (1 yarda = 0,9144 metros). Parcheas la librería y sigues con tu día.
Pero, al cabo de un tiempo, llega una actualización que rompe tu corrección. Tienes que volver a aplicar el parche. Luego vuelve a pasar. Y otra vez. Te das cuenta de que estás perdiendo el tiempo parcheando sin sentido, cuando la corrección debería estar en la propia librería. ¿Cómo la metes ahí?
La todopoderosa pull request
La mayoría de proyectos de código abierto están alojados en GitHub o plataformas parecidas, y todos permiten usar pull requests. Una pull request (PR) es una solicitud para incorporar cambios a un proyecto. Haces un fork del repositorio, aplicas tus cambios y luego envías una pull request al repositorio original, proponiendo que tus cambios se fusionen en la base de código principal.
Además de la parte técnica de hacer forks, trabajar con ramas y fusionar cambios, el proceso de una pull request también va de comunicación. Tienes que explicar qué has hecho, por qué hace falta y cómo mejora el proyecto. Ahí puedes demostrar que entiendes la base de código y que sabes contribuir con criterio. No sirve de mucho destrozar una pull request con mensajes de commit cutres, subir un montón de cambios sin relación o no seguir las guías de contribución del proyecto.
Esta actitud en los comentarios de una pull request no te lleva a ninguna parte.
Además, las idas y venidas de una pull request pueden obligarte a actualizar tu fork, hacer rebase y resolver conflictos. El proceso implica todo un paquete de habilidades de Git, y ahora puedes practicarlas todas con GitByBit en un escenario realista con repositorios reales de GitHub.
Bordar una pull request exige mucha paciencia y atención al detalle.
Además de la práctica de pull requests, he añadido varias entradas nuevas a Gitopedia, incluidas y . También hay dos buenas prácticas nuevas: y .
¡Hola! Me llamo Alexander Shvets y soy el creador de GitByBit. Me alegra anunciar que el blog ya está en marcha. 🎉
Sinceramente, tendría que haberlo hecho mucho antes. Llevo más de un año trabajando en GitByBit y, por el camino, he reunido bastantes ideas sobre Git, control de versiones y prácticas modernas de desarrollo de software.
También iré compartiendo algunas de las ilustraciones que he creado para el proyecto, como estas:
Tengo casi 40 años. Un amigo insiste en que la gente más joven no entenderá las referencias a Terminator, pero a mí me encantan y sigo pensando que funcionan muy bien. ¿Tú qué dices?
Lancé mi primer recurso sobre Git allá por 2011: se llamaba GitHowTo.com. Sigue en línea y, sorprendentemente, todavía es popular: solo el año pasado lo visitaron más de 100.000 personas.
Pero, para los estándares actuales, aquel formato es demasiado rígido. Seguía un único recorrido y se centraba solo en los comandos de Git más habituales. Dejaba fuera muchos problemas del mundo real y, si te atascabas, tocaba rebuscar respuestas en Stack Overflow o en otros recursos. No había IA que te echara una mano.
Así que decidí crear algo mejor: una experiencia interactiva para aprender Git, centrada en la práctica más que en la teoría. En vez de saltar entre el navegador y la terminal, me pregunté: ¿y si todo ocurriera dentro de tu editor de código? ¿Y si pudieras aprender Git trabajando en tus propios proyectos, sin salir nunca de tu IDE?
Así nació GitByBit. Ha costado llegar hasta aquí, pero por fin está listo, y espero que te resulte útil de verdad.
Lo siguiente: diarios de desarrollo. Iré compartiendo ideas sobre el proyecto, los retos que he encontrado y las lecciones que he aprendido por el camino. No te lo pierdas.