nicosommi

devops

posts

slides

about

Debugueando node

April 20, 2014
4 min read

To see this article in english click here.

Cuando programamos en Node.js siempre hay cositas que vuelan por la cabeza. Hay muchas cosas en las que pensar. Muchas cosas que tener en cuenta. Es simple, pero hay que saber lo que se está haciendo al altísimo precio de llegar a un lío muy importante. Javascript. Npm. Lo bueno, lo malo y lo feo.

Una de las cosas que más me asustaban en este node-hell es poder depurar nuestro script. Muchos solemos usar muy frecuentemente logging de distintos tipos, desde el simple console.log hasta paquetes más copados como debug, ain2, winston o algo así. Pero muchos evaden el viejo y conocido debug, que nos permite agregar watch expressions, evaluar ejecuciones en el contexto actual, observar el backtrace, y otras cositas mas.

En mi experiencia había debuggeado previamente node en mis comienzos, pero de una forma muy distinta. Usando eclipse. Vengo de Java así que me resultaba familiar, y el debugger V8 se conecta sin problemas a un proceso node ejecutando en modo debug (con –debug). Sin lugar a dudas es una muy buena alternativa. Sin embargo hoy tengo un entorno de desarrollo mucho más dinámico y liviano en memoria. También puedo abrir el chrome y hacer lo mismo que del eclipse pero desde ahí. Pero hay dos motivos en contra de eso: los que no usamos Chrome (yo uso Firefox por ahora) y los que encima no desarrollamos necesariamente algo web con node.js y no necesitamos abrir el browser. Gedit y Sublime son los editores que uso frecuentemente. Perder el miedo a la consola es algo que aprendemos todos los que somos habitué de ubuntu, git, y esas cosas. Perder el miedo a la consola es también clave para no complicarse la vida con la depuración en node.js.

Es tan sencillo como lo siguiente: es un debugger como los que conocemos de toda la vida pero comandado por consola. Desde algunos lenguajes ya vienen acostumbrados a esto, sin embargo yo que vengo de Java, y anteriormente C# y TIBCO, estoy acostumbrado a debuggers de todo tipo pero es la primera vez que experimento con la consola.

Primero que nada repasemos la necesidad. Esto surge de la experiencia en ambientes reales en donde solucionar un problema complejo en ambientes productivos es algo habitual. Los logging de consola algunas veces son precarios en algunos aspectos y nos limitan a la hora de solucionar un problema rápidamente. Muchos podrán discutir sobre este tema apoyados en su rapidez y lucidez mental constante. Yo prefiero saber que no dependo de eso. Prefiero no sentir esa presión. Prefiero saber como debuggear y detectar el problema mirando mejor el contexto. Demás está decir que algunas veces los errores son tan complicados que la reproducción del mismo nos lleva mucho tiempo y sincronización, y por ende estaría buenísimo si descubrimos el error en la menor cantidad de intentos posibles.

Mencionados ya los beneficios de usar un debugger, vayamos al acto. El uso trivial es sencillo: ponemos un debugger; en donde nos plazca y luego ejecutamos la aplicación con el argumento debug.

node debug script.js

Algo tan simple como eso ya nos deja en la consola de debug. Ahora es sencillo, para lo que antes haciamos en entornos gráficos ahora tenemos un string que dispara el comando. Por ejemplo poniendo ‘cont’ o ‘c’ el debugger avanzará hasta el próximo debugger;

Hay una lista completa de comandos en la sección Commands reference en el siguiente link http://nodejs.org/api/debugger.html

Los más destacados son

  • step in: se hace escribiendo s
  • step out: escribiendo o
  • next step: n
  • pause
  • watch(‘variableName’) : imprimira el valor en cada paso
  • unwatch(‘variableName’) : dejara de monitorear el valor
  • list(4) : imprime el contexto en un radio de 4 lineas
  • repl : importantísimo, nos permite evaluar algo en el contexto actual como el console del browser (tenemos todo lo del contexto pero no podemos modificarlo). Salimos con ctrl+c

Hay “complicaciones” extra para quienes utilizan gulp/grunt (casi todos) ejecutando algunas tareas previas a iniciar la aplicación… pero buenas noticias, se puede utilizar algo como por ejemplo nodemon en esos casos, con la opción nodeArgs.

Por ejemplo:

nodemon({script: './app.js', nodeArgs: ['debug']})

Otro caso común. Test unit. Con debug? Sí. Por ejemplo si ejecutamos

mocha debug test/ejemplo.js

entonces nos llevará a la consola de debug.

Combinando mocha y grunt/gulp se puede hacer esto (también con nodemon):

nodemon({script: './node_modules/mocha/bin/_mocha', nodeArgs: ['debug']});

donde ponés la ruta a tu instalación global del ejecutable _mocha (con guión bajo) y listo, con eso tenés tus test con el debugger built in y tus tareas previas ejecutadas.

Obteniendo un error ENOSPC?

Eso es porque hay muchos archivos abiertos (o tenés un editor que suele abrir muchos archivos como Sublime o nodemon está incluyendo muchos archivos).

Lo podés solucionar incrementando el valor de maxuserwatches con este comando

sudo sysctl fs.inotify.max_user_watches=20000

El número correcto depende de tus necesidades. Podés ver que tenés actualmente ejecutando esto

more /proc/sys/fs/inotify/max_user_watches

También recordá executar nodemon con el argumento -i nodemodules

En definitiva. Si todavía no lo hiciste animate que es sencillo. Hace un script sencillo que cuente hasta 100 en un for y probalo vos mismo.

Tenés una idea para mejorar este artículo? Mandámela a nicosommi@gmail.com

nico
Copyright by nicosommi 🐒