Elegir el momento de lanzamiento: superar retos en Transloadit
Hace unas semanas, el equipo se reunió en una de esas diminutas ventanas de conferencia de Skype para discutir una pregunta importante: ¿deberíamos lanzar Transloadit en su versión actual?
Ordenados por importancia, los problemas a los que nos enfrentábamos en ese momento eran los siguientes:
- Estábamos atascados en Node
v0.1.28 - Teníamos muy pocas pruebas unitarias
- El sistema tenía algunos puntos débiles en el diseño
Sin embargo, al mismo tiempo sabíamos que el sistema era capaz de cosas asombrosas. Algunos de nuestros probadores alfa lo están usando para subir videos grandes y producir a partir de ellos hasta 32 archivos de resultado (marcas de agua y miniaturas de distintos tamaños) que luego se suben a S3. Eso supone más de 100 Jobs internos que generamos y gestionamos en armonía, todo gracias a lo genial que es Node.
Con eso en mente, decidimos seguir adelante y lanzar en la próxima JSConf. Hasta la semana pasada estuvimos trabajando sin descanso para cumplir ese objetivo. Integramos los pagos con tarjeta de crédito en el sitio web, ideamos un plan y un modelo de precios excelentes, y dedicamos muchísimas horas a eliminar los últimos errores del sistema.
Y entonces… todo se fue al traste.
Habíamos notado que nuestro servidor node moría cada 1 o 2 semanas, pero lo atribuimos a algo que habíamos estropeado nosotros mismos y desde luego no pensábamos que se convertiría en un problema enorme. Pues al final lo hizo. Mientras probábamos algunas de las Assemblies más intensas mencionadas antes, notamos que el servidor moría con más frecuencia. Resulta que la versión antigua en la que estamos tiene problemas graves en el código de red. Cuando se produce uno de esos problemas, lo último que ves es:
(evcom) recv() Success
Y entonces el servidor muere. Sin segfaults ni detalles.
¡Ay! Un año de duro trabajo fuera de horario se fue de repente en llamas. Ahora bien, podríamos intentar dedicar un esfuerzo enorme a rastrear este error, tal vez incluso a corregirlo. El hecho es, sin embargo, que entonces estaríamos arreglando el problema equivocado.
El problema real es que estamos en una versión antigua de Node. Y la razón de ello es que no seguimos las palabras de Uncle Bob:
«Profesionalismo: ¿se lavó las manos el doctor?, ¿escribiste tus pruebas?»
Si tuviéramos una buena cobertura de pruebas para nuestro código, actualizar Node no sería un gran problema. Refactorizar algunos de los problemas de diseño dentro de la aplicación tampoco sería un gran problema.
Así que ahora estamos haciendo lo que deberíamos haber hecho desde el principio: reescribir nuestra
versión antigua en una nueva, completamente probada, construida sobre el próximo Node 0.2.0. Esto llevará algo de tiempo, pero
por suerte podemos reutilizar mucho del duro trabajo de prueba y error que aprendimos de la
versión 1.
Queremos dar las gracias a todos los que han probado la versión 1, y esperamos mantenerte al día sobre la versión 2.
P. D. Resulta que al final no pude llegar a la JSConf por el volcán. Lo tomaremos como una señal. 😄