IDO GREEN: Hello, and welcome to another episode of GDL-IL,
GDL-Israel.
Today, we're going to speak about NodeJS and Chrome, and
how you could leverage the powerful DevTools that we have
today and Chrome and Chromium in order to debug NodeJS
applications.
Now, it's true that you could debug your NodeJS with
WebStorm, there are some other options out there.
But I really like to focus on Chrome and the open-source
project Chromium, because not only it's giving you the
ability to it without any money, which is nice, it's
actually a quite efficient way to get insight of what your
application is doing and be more productive when you are
building larger and larger applications.
So without further ado, let me just share my screen with you.
And we'll do it quite quickly today.
So we'll start, and actually, I'll put all those links in
show footnotes.
It's a blog post that I wrote and published yesterday.
And basically, we see that today--
and I see it more and more in Node--
you're starting with a small script, and then quite
quickly, you're getting to a larger, larger app that you
want to get insight and see how productive you could fix
things and understand what is going on behind the scenes.
When we we're going to use it today, we're go, basically, to
get what Blink is giving us, so the DevTools that are
sitting inside it.
And you'll see that they are quite similar to the DevTools
that we get in Chrome itself.
So if I open them quite quickly, as you saw here,
we're getting quite a lot of tabs over here at the top.
In our case, when we're going to debug NodeJS, we only get
to the source stub and the console one.
And I'll show you in a minute what does it mean.
And let me just make it even larger.
So the first step, in order to install it, is of course,
first and foremost, we install Node.
And after you install Node, you'll just run this command
of installing the
node-inspector, which is a model.
Luckily for us, npm, the ability to manage models
inside Node is already coming when you're installing Node.
So if we just come here and make this one a bit bigger,
what you could see here is that I'm just
going to install it.
And I could see here that it quite quickly will let me know
that I already have it.
I need just to do it with a sudo.
And since I already have it, again, hopefully this time it
will run without any problem.
Of course.
I wrote it with a mistake.
Let's take it again, hopefully this
time without any mistakes.
And hopefully when you're typing it without mistakes
like what I did, it will run fluently and much quickly.
After installing this model, and we have the ability, we
need, basically, just to attach it to the script that
we are going to work on.
So here it's just fetching a bunch of stuff.
And at the end of the day, we just have this ability.
Now if we'll go and, let's say, run a specific Node
script, like in this case, it's a Monte Carlo simulation
that I showed you four weeks ago-- and again, I'll put a
link to it so if you want to see how to run Monte Carlo
simulations inside NodeJS, you'd be able to do so.
Actually, in that episode, in the last episode, we did it
inside Google Cloud, basically, Compute Engine.
And it's a quite powerful tool to run NodeJS applications.
Here, the only main difference, as you can see, is
just putting this dash, dash debug break.
So our script will just stop at the first line.
And when I'm doing it, I'm getting now the response of,
OK, the debugger now is listening on port 58.
Here, you could see here that I already started the
node-inspector.
So I'm getting the ability to just go and [INAUDIBLE]
copy this dislocation.
And [INAUDIBLE]
just another Chrome tab we could pass it,
just refresh the page.
And now what's happening behind the scene is that it's
connecting to our script.
And when we just let it run, right now it's detached.
But if I try it again--
Yeah, it's not working.
Let's try it again.
We're running it.
And now let's try to call it.
We'll just have the running script in the background.
But now that we do have it, if we'll just run, you could see
immediately see that it's going.
It's connecting to it.
And I have it with a breakpoint at the beginning.
What they could do is go in and do much
more interesting stuff.
It's just going to my code.
And let's say that I'm putting a breakpoint at the beginning.
And now I'm just running to do is breakpoints.
Some powerful things could be achieved here.
So first, I just could inspect what's going on with each and
every variable.
And as you could see here, it's undefined.
But after I'm passing it, I see exactly what is the
variable that I got here.
That's quite trivial.
I could do more sophisticated stuff, as you all know, just
setting out a breakpoint, and running to it quite quickly.
And then, of course, I could dive into the function itself,
run scenario blending.
But if I just want to see what's going on after the
function has returned, I could now go to the expression
itself, see that it's containing
some interesting values.
I could do local modification.
I could get edit to the watch.
And as you can see here, now I have it permanently.
So I could do some nice things [INAUDIBLE] see exactly what's
going on here.
I could also, of course, click Escape and get
in the console here.
And in the console, the great benefits that you already have
in Node, like doing nice things like autocompletes on
the variables that you have in your scripts, and then diving
into a certain object to see what's going on there, and
lots of other things, of course.
You have the call stack, so you could see exactly what's
going on and how the application path, in terms of
the function calls went.
And the scope, of course, of the variables, what's going on
in each and every one of them.
And, of course, breakpoints.
So if you want to see where you set the breakpoints.
In our case, it was at the beginning of the script, and
then a bit later on.
And lots of others possibilities.
Of course, when you are just releasing the lock of the
breakpoints, and you could see here in this window that the
script will continue to run.
And let me try to adjust that.
So of course, since we are breaking a point inside
function, that's inside a loop, we continue to do so.
But now that I removed it, and I could move this one, as
well, I could just run it.
And as you can see here, quite nicely, it's all running in
the background.
We actually ran 10,000 trials, and got the
response quite quickly.
Actually it took us this amount of time because we
showed how to do things.
But if we run it without breaking, to just let me show
you the powerful node, in terms of performance, how
quickly doing things.
So we got 10,000 trials in 357 milliseconds,
which is quite nice.
So that's basically what we got.
The node-inspector's giving you the powerful DevTools
under your arm when you're going and want to check and
verify and debug your scripts.
Hopefully in the near future, we'll have here other
thoughts, like the profiler, the audit, and more and more.
And all the links for how to do it and what are the steps,
as you can see here, will be
published in the show footnotes.
So feel free to just go and try it on yourselves.
If you want to have questions or comments, please feel free
to reach out to me on greenido at Twitter or greenido in G+.
So until next time, thank you very much and be strong.
Thank you.
Bye bye.