 So thanks everybody for coming. I know it's one of the later sessions in the day. So it's often attractive to maybe go leave early and get a beer or something like that. But I appreciate you coming. Hopefully I'll make it worth it for you. This is actually part of a three-day workshop and training that my company does on Node.js. But we've gotten a ton of mileage out of this presentation in particular. I just delivered it a little over a month ago at the OSS summit in Shanghai. I'll be delivering it at all things open. So this tends to be one of the more popular sessions. It definitely is a 101, like meant for beginners type of class, though. We're not even going to look at that much code. We're going to be kind of talking more about Node's architecture and kind of what makes it different, what were the motivations involved in really putting it together in the first place. And you will leave, though. You will leave with an understanding of how to get an IDE up and going and run a program. And even debug it. We'll go over an example where you can set up a breakpoint and watch a variable and that kind of thing. So you'll leave with some practical knowledge, just want to let you know it really is meant for beginners. We do have a more advanced kind of deep dive one that I give sometimes. It didn't get accepted this year, but maybe another time. So first of all, who am I? I'm Justin Ryak. I'm the chief architect at a company called OpenLogic, which has also been called Rogue Wave, which was recently bought by Perforce. So it gets a little confusing. But basically, this is what I do. It's mostly an evangelism role at this point. I do set strategy for our company in terms of what pieces of open source we want to adopt and that kind of thing, which will make sense in a second when I tell you what we actually do. So there's still some of that work, but it's mostly this. It's mostly speaking or enabling our sellers or contributing to marketing, that kind of thing. So you'll see me doing interviews and podcasts and that kind of stuff. This is the biggest question I always get right here. Is the code available? Yes. You'll also see the slides linked off of there from a slide share. So if you all want to take a moment, grab that. Of course, the deck is also listed on sked.sked, however you're supposed to pronounce it. So you can grab it from there too. But this will let you grab the code at least. And there's some light instructions. There again, nothing too sophisticated on here. But this will at least allow you to kind of keep up with the demos that we've got. All right, my 22nd sales pitchy part of this. Open Logic is a company that provides support and services for community open source. We don't ship a product. We don't brand a product. We don't assume ownership. We just provide knowledge. So it's support and services, training, and that kind of stuff. So we have the opportunity really to get to see a lot of different technologies adopted in a lot of different ways. And we turn around and try to build knowledge objects out of that. And then just kind of come to you guys and tell a story about what we've been seeing in the industry. And that I promise is the only sales pitch you'll get from me if you're interested. I've got business cards you can talk later. So what are we going to solve today with Node.js? No, I'm just kidding. Asynchronous processing is one of the things that we're going to look at. Because nobody likes the spinning wheel of doom or hope, depending on whether you're a pessimist or an optimist. Node.js itself is an inherently asynchronous language that's really different. If you've been used to object oriented or procedural or imperative languages where typically you're going to execute kind of an order and everything's going to be blocking and the thing in front of your code on the next line is not going to execute until this one finishes, you've got to throw all that away. Because with Node.js it is completely asynchronous. There's very little that's actually blocking behavior. You have to plan for it. You do have control over it when you get a little deeper into understanding the way that Node is able to be completely asynchronous. But bear in mind this is one of the biggest paradigm shifts that comes to the people that really kind of struggle with when it comes to learning about Node. It just takes practice. It just takes really understanding what the code is doing and getting into the right mindset of it. And for this new ish parallel compute, distributed compute, obviously clock speeds aren't increasing the way that they used to in Sto instead of just shoving more processors into substrates and trying to get more stuff to execute in parallel. And an inherently asynchronous language is great for that because if we've got 50,000 nodes of some compute problem running, we don't want blocking behavior. We want our stuff executing as fast as we possibly can. But in this case, we get something that's inherently asynchronous and also built on industry standards. Because as you'll see, there's really not a whole lot new that was added to Node.js to make it do what it does. There were some libraries and things like that. But as you'll see, the famous story is that Ryan Doll, who's a Node chief maintainer, kind of built it over the weekend. And you'll see how that's possible. So what else are we going to look at? So one paradigm shift that we've already discussed is this idea of going from something that's inherently asynchronous to programming more asynchronously. And that's a paradigm shift. But there's a broader cultural paradigm shift that happens when businesses move their stuff over to Node as well. So this is how we've been doing things for a long time. This is your typical model view control, decoupled, maybe web application. This should all look very familiar. We've got back-end servers that are serving up some type of back-end logic through an API, maybe a RESTful API, maybe SOAP, who knows. Maybe the back-end language is like Java or Perl or PHP or something like that. I mean, any of those things. But we've got this separate back-end logic that's usually written in a different language than the language that's controlling the front-end of our application. And so because of that, we had developer silos. We've got the people who understand back-end development doing work on one side of the house. And we had the people doing front-end work, UI work, CSS stuff, whatever, in another side of the house. And we all know that when we have two development teams, they always communicate together perfectly. And they always share information transparently. And there's never a problem with agreeing on things like API contracts and whatnot. So obviously, that doesn't happen at all. So we had this fragmentation, right? So what can we do now, for better or for worse? We can now code our back-end logic and our front-end logic in JavaScript. At core, that's one of the biggest problems that we're solving here. And this is more of a cultural problem. This allows us now to take somebody who's maybe more traditionally been just a front-end developer, and maybe just used to CSS and JavaScript, and put those skills to use developing back-end code as well. And then we get to do really interesting things. Because then we get to use the same framework, for instance, to communicate form data between front-end and back-end. We maybe can do form validation in just one place as opposed to doing form validation all over the place in our application. We're able to unify things throughout the application because everything but the front-end and the back-end is written in the same language. So that allows us to code our front-end and back-end using a single language. So that's another thing that we're solving here, is this fragmentation or siloing of developers based on skill sets. So a little bit, and by the way, stop me at any point if you have questions or if you just want to talk. So the project itself was created by Ryan Dahl, a very smart guy, hard to pin down. I tried to get him to speak at conferences and stuff. He's just a very busy, very busy person. But it was mostly created to address issues with concurrency in JavaScript. So JavaScript itself is inherently single-threaded. But we're going to look at how we work around that problem in Node.js. And Dahl sort of built it on the weekend because when you see what Node.js is, it's really the existing Chrome V8 JavaScript interpreter that's kind of become the industry standard JavaScript engine with some stuff built around it, like an event loop built around it and some client libraries built around it. But really all we're doing is executing individual sort of bits of JavaScript compute in multiple threads, in multiple instances of the JavaScript interpreter running on the back end, and there's an event loop that abstracts that all from you. So he's really just kind of duct tape a few components together here to make Node.js. And really what's really proliferated has been the Node.js module community. And that's what's really kind of had this Cambry and explosion that makes it this super useful framework right now. So built on Chrome's V8 JavaScript engine, which is to say it is a single threaded but asynchronous event driven engine. What does that mean? So the V8 engine which interprets normal JavaScript, like JavaScript running inside of the browser, is single threaded. It can only grab one thread at a time. So if we were to try to throw back end JavaScript and try to do things in parallel, that wouldn't give us any benefit, because a single instance of the V8 engine itself can only grab one thread, can only use one thread. So there's going to be inherently blocking behavior. So what have we done? We've stuck an event loop in front of the thing, and then allowed multiple V8 engine instances to run small chunks of JavaScript in parallel. And then there's all this control that happens in between using this event loop library. I'll show you a picture in a minute, if that's a little confusing to you. So we can achieve vertical scale, then, just by adding more cores to a single instance, and that's one of the benefits that we get here. We're not going to get into clustering or forking. We do talk about that in the advanced session. But JavaScript, or Node.js, rather can do some kind of cool things at the operating system level to allow it to auto-scale to a single environment, spin up like a certain number of workers based on the number of cores it's able to see. Almost the fact that it's pigeonholed into having to deal with the fact that it's single-threaded has led to some interesting innovations in the way that Node.js apps can vertically scale within a single instance. But we're not going to get too much into that in this talk. OK, so that's the Node language itself. We're going to look at the architecture in a minute to try to cement some of that. But one of the most interesting, and I think important parts about Node.js is NPM. NPM is not the Node package manager anymore. It's now supposed to be just thought of as a standard JavaScript package manager, because there's stuff that's not necessarily Node modules that's in it anymore. But it was certainly conceived, at first, as an ecosystem for open source Node modules to be shared between Node developers. Very active and vibrant. That's really old data. I'll show you better data in a second. Here we go. I actually just pulled these statistics to refresh this slide earlier today from modulecounts.com. This is a site that goes out to public repositories that hold various libraries and modules for programming languages. So if you've ever programmed in Java, for instance, you may be familiar with Maven Central, and all the modules that are held in Maven Central. Or if you're a Perl programmer, you know about C-Pan. Or if you're into .NET, you know about Nougat. Or packages, if you're into PHP, right? So you see what's happening here. It's going and it's counting all the available modules that are available to developers. Well, this top red line here is NPM. It's blowing up. When I gave this in Shanghai, the number was only about 850,000. And that was just pretty recently. I had to pull this again and figure out that we crossed over a million pretty recently. So there's no question that in terms of the modules, the dependencies, the libraries that you're going to be able to pull into your applications, there's just a ton of stuff that's available to you. And it's good stuff. It's stuff that's being vetted by lots and lots of developers. So I'm kind of looking at some pros and cons. So very lightweight and low memory footprint. If you've been doing development in a heavier language like Java or something like that for a while, and not to say anything bad or disparage on Java. I've been a Java developer for years and years. That was my early part of my career was in Java development and Java EE development. It's a fantastic language. But it takes a little while to get started. You might need an application container. You have to run stuff inside the JVM. You're going to have to go through a build process. You may have to use Maven or Gradle or something like that to pull in dependencies. It's not. You can't just go. Not like you can with a scripting language. So Node acts like a scripting language in that you do have all these dependencies that you can just pull in. You can just go without having to build your app. And most you may have to download your module dependencies, but they don't have to be compiled or built or anything like that. It just runs. So you can get started very, very quickly. And now with a very prolific module ecosystem, you can get started on a wide range of work. Just went way off topic there. So again, asynchronous event driven, very popular, full stack web development. On the con side, we do have this 1.7 gig memory limit. Now we can stream. We can stream objects through our JavaScript application. We don't have to hold giant objects in memory. We can stream data through it, which is just a better choice to do that anyway. So we can get past this limit architecturally speaking. But of course, there is a vertical scaling challenge. You can't fight that limit no matter what. A single process or a single workload in Node.js is only going to be able to occupy up to 1.7 gigabytes of memory. It's just the way that the V8 interpreter works. Module versions can get a little confusing. In general, Node developers do a pretty good job paying attention to semantic versioning. And you even have, and can rely on in your build scripts, the ability to use semantic versioning to make sure that everything's aligning the way that you want to. But it's not perfect. There's a million modules out there. Of course, people are going to make mistakes. Open source governance is not flawless. Is anybody familiar with the left pad story? I know it's a bit of an older story now. You know this one? This was a lesson learned for a lot of us, I think. There was a module called left pad, literally 18 lines of JavaScript, tiny little module. All it did was add four spaces before a line of text to add an indent to text. That's all it did. It padded left by four spaces. But it was a convenient module and everybody was using it. And they're using it in their build scripts. Well, after a series of events, the developer pulled his code out of NPM. And a lot of people had not done proper best practices and brought in these modules into their local repositories so that they can pull them locally. So when they did that, they ran the build scripts on their code. I mean, we live in a world now where people are building and pushing to prod like every 10, 15 seconds, right? So it broke like half the internet when this developer pulled this one module because it's still open source. And governance isn't flawless. We know that, right? I mean, there's how many talks are there this week about open source governance and management about how we deal with these problems within fragmentation. And then, of course, a learning curve for developers that are just aren't used to dealing with something that's inherently asynchronous. Again, it really is a paradigm shift. Questions? All right. So this is an example of what some of the code might look like. It's also an example of JavaScript doing something really, really weird if you're used to front end development of JavaScript. And that is opening up an HTTP server. Basically, we're using a module called HTTP. This is a Node.js module that gives us constructs on the back end for creating a web server so that we can start sending data back and forth between the back end and the front end over a web port. What are we doing? We're creating a server. We're creating this thing called a callback function. So this is our first kind of look at what's happening with asynchronous code. So without getting too in-depth, because this is still a 101 class, another thing that you have to really wrap your head around is this notion of functions being a first class citizen in Node.js. And you may have heard that concept with other languages to other functional programming languages. What that means is that if you're used to a scalar variable or something like that, float or a character variable or a string or something like that, these are primitives. These are variables that you're allowed to manipulate and work with. You can pass them. I can pass a variable as an input parameter to some function or method that I'm calling. So variables in those cases, scalars or primitives are first class citizens in that case. In the case of Node.js, functions are also first class citizens. Functions are actually wrapped and there's enough metadata in them that they can literally be passed as variables into other functions. And that's what you're seeing happening here. This is called a callback, sometimes called a closure or a promise. And what this means is that when this event happens, this function is getting passed in by the developer. And this arbitrary function is what I want to execute when this event actually happens at some point in the future. That's how we deal with asynchronous callbacks. Now, if you don't understand that or if that's not completely clear, don't worry. It's hard to wrap your head around if you're not used to doing this type of programming. It just takes practice. But that's effectively what we're saying is, just almost like passing in a variable here, we're saying, take this function and I want you to execute it later in the future when this thing happens that I'm telling you to wait for. And that's sort of the nature of asynchronous programming. So weird stuff, asynchronous behavior, and JavaScript opening a web server. Welcome to Node.js. This is definitely what we're dealing with here. So here's the architecture, again, in kind of a more visual way. So we see our app. So this is our Node.js app itself. We have the Node engine. And this engine is responsible for taking our JavaScript code and cascading it through all the various bits that allow it to execute the way that we want it to. This libv is where the magic happens with all of our asynchronous stuff. This is a super fast event loop implementation that was written in C, was written specifically for Node.js. It's now in use for some other things, but mostly still used for Node.js. And this is where some piece of action comes in from an application. Go do this thing. Libv is responsible for queuing that action and then spinning off the normal old V8 JavaScript interpreter that everything else that uses JavaScript uses right here. And spinning off multiple instances of this. That allows communication with the OS. Couple of crypto libraries and little things that are needed. But in general, this is how Ryan Dahl was able to build Node.js overnight. Because all he really did was take this thing, libv, and slap it between an interpreter that he wrote and something that would actually go and process and parse the JavaScript and actually execute it that he would never have to worry about, which is just the V8 engine part of it. Another way to look at it is through this picture, where we zoom in a little bit on the event queue. And this is where our app is going to send in JavaScript calls into our Node.js C bindings that are part of the Node engine, pass these off to an event loop that's just constantly executing stuff using back-end worker threads that are going to execute the V8 interpreter engine itself. So this event loop really is where things start to get different. It's where all of a sudden we can have a whole bunch of different asynchronous processes executing, excuse me, in parallel across multiple cores on a system using JavaScript. So that's the theory. That's kind of the why and the how of Node, the architecture of Node. So practically, how do you get started with it? Well, the first thing you have to do is install it. And you can do that using a lot of different ways. It's all been pretty streamlined at this point. If you're in a Linux environment, I can almost guarantee you, if you're using mainstream Linux, that there's a package available to you for Node.js already. So if you're on Ubuntu or Debian, app getting installed, Node.js, if you're on CentOS or REL or something like that, you can use yum to install it. I mean, pretty much anything is going to have a distribution of Node.js. But there is a standalone installer that's available to you as well that you can run. There's an official Docker image. If you want to just Docker run Node.js, then you can get started really quickly with it there, too. And then there is a shell script that you can get that will do all the W getting and pull all the stuff and build it locally for you. So there's a lot of different ways. But step one, you really need to install it. Once you have it installed, you just want to verify that it's installed correctly by running two commands. You want to make sure that the Node engine itself is installed. You can just do that by running Node version. And hopefully it's going to return something. You also want to make sure that the Node package manager is installed. And you can do that with NPM version. And this is really going to give you everything that you need then to get started with development. You're going to have Node and you can start executing stuff from the command line. This is the only prerequisite, with the exception of maybe getting an IDE up and running, to running the demos that we're going to be looking at here in just a minute, or right now, actually. Questions on any of that before we look at a demo? All right, so this is really going to be super simple. We're just going to execute our basic hello world type of application right here on the command line. This, by the way, I've copied some stuff into here. But this is the Git repo here. So everything that we're looking at, I'm not going to mess with it in this one. I've got another. This is kind of my golden copy. But that's the same structure that you'll see in the Git repo. So let's go to a hello world app. And let's look at it first. Really, really simple. I'm going to delete it and just write it from scratch so you can kind of see how simple it is. I'm going to use VI even, because it is that simple. And so we're just going to say console.log. Hello. That's a summit. All right. And then all we're going to do to execute it is really just run it against the node engine, which is node. So node hello.js. And then it executes. So we didn't do a build. We didn't do a compile. We didn't package it. We just ran. So it looks and feels very much like a scripting language. But because we've got all this powerful, this is the powerful kind of module ecosystem behind it and everything like that, it really takes this world a lot further than you would get with your typical scripting language. So I'm going to keep on moving because this is actually supposed to be like a 50-minute talk. And we've only got 35 minutes. I'm going to speed it up just a little bit. So now I've got node installed. We've verified that node is running. If you can execute that hello world application on your local environment, you're good. You have everything that you need between that and npm. Next thing that you want to do is start thinking about an IDE. And really, I prefer VS Code for a Node.js development. I think it's great if you haven't had a chance to start playing with this yet. I got it handed to Microsoft. They've made a really nice contribution for us here. It's an excellent IDE. And this is coming from somebody who was like a die hard JetBrains guy for a while, IntelliJ. I have had the IntelliJ eclipse debate like a million times. This really is a solid IDE and really good for doing any type of open source development. We've got nice terminal integration. The built-in debugger works really well with Node. You do have other options. You're going to want to go with really what's familiar and available to you. Sometimes businesses and companies are going to limit what you're allowed to use, obviously. The good news is it's ported to just about everything. And we're all going to have our own preferences as developers as to what we want to develop on, obviously. But make sure that you're at least looking at some of these criteria. You really want a debugger. Your life's going to be miserable if you don't have something that you can debug with. Syntax highlighting is getting to be very helpful, especially in Node where you're first starting to learn. And the syntax can be a little weird when you're embedding asynchronous callbacks and all this kind of stuff. It's really useful to be able to have comfortable reading of your syntax. ESLint, this is like lint for ECMAScript. For those who don't know ECMAScript, JavaScript, same thing. ECMAScript is basically the standard behind the JavaScript language. And that's what the ES comes from. You want terminal integration. You want good integration with NPM. You want code completion. I mean, the quality of life things that you want in your IDE. You do have other options, though, beyond VS Code. So VS Code provides all those things that I just mentioned. Cloud9 is an interesting one. I actually started using Cloud9 before. I started using VS Code for Node.js. It's kind of compelling. It's a completely web-based IDE. And your session is effectively your own Docker container that they spin up for you. So it's very kind of cloudy in the way that you're doing your work. And it's pretty portable in that you can easily commit your whole environment into Docker Hub or whatever and start working with it right out of there. So it's a very container-y, cloudy IDE. Of course, JetBrains has their contribution, too, in their WebStorm IDE Komodo. And then Node Clips. If you really love Eclipse and you're not comfortable getting outside of Eclipse, that's fine. You can get the Node Clips framework and do Node.js development inside of Eclipse. But we're going to focus on VS Code. This really has kind of risen to be the most popular IDE that Node developers are working with right now. And we've got all these different VS Code's extensions. But when you first get started, really just start with these two. Make sure that you've got at least the debugger and then the Node.js extension pack. That's going to get you all those things that I just mentioned on the previous slide. It's going to get you lint. It's going to get you the syntax highlighting. It's going to get you the debugger, all of those pieces that you need. But do take the time to kind of poke around and explore. If there are particular frameworks that you're looking at using or particular modules that you want to integrate with, you may have some plugins that are specific to that. I mean, there's just a ton of stuff out there. The ecosystem is really, really big. So inside of VS Code, we're going to have basically a launch configuration. This is going to be something that's specific to VS Code. It's not something that has anything to do with Node.js. But we need this if we want to be able to debug our application. And it's basically a build file that's going to tell VS Code how to launch our app. And that becomes really important as our app gets more sophisticated. Maybe you're going to start relying on environment variables to be set or something like that within your application. Well, if you're going to run your debugger, then the debugger has to have that predefined configuration, or it's not going to work. If I need to provide a Slack API token or something to my app in order for it to run, and I want to do that obviously using an environment variable, I'll need to create a launch configuration inside of VS Code that will be able to provide that key. So that's kind of the purpose of it. And it's created through a file called launch.json. And it's going to be referenced before VS Code launches the app. And while it's debugging, and it's got its own kind of JSON-E syntax to it, just get familiar with it. It's not too hard to learn. But for some people, it's not intuitive at first that this is what VS Code is actually looking for when you launch your stuff in debugging mode that it actually wants this. So just be aware this is what it's looking for. When you go to modify your configurations inside of VS Code, it'll actually create it for you. And we'll do a demo here in a second where I show you that. But that's essential for debugging and very convenient for launching unit tests. So we're going to go through this. I know we're coming up pretty close on time here. It's probably my fault. I rammed it a little too much. But I want to at least show you debugging inside of the IDE. And of course, these slides are available to you. And I'm available if you have questions or anything like that too. What am I doing here? So here is code running inside of VS Code. Let me zoom in a little bit here. So what I've done here is just modified our Hello World program to take our message and keep it inside of a variable, in this case just a constant. And then we're just logging that variable as opposed to logging a hard-coded message. Well, why would I want to do anything like that? Just to demonstrate how debugging works really. If I look at my launch.json, now this was created for me when I went into the debugging mode here in the IDE and came in here to actually hit this little Settings button over here. And it's just going to hurl you over to this little JSON configuration. And there's a little of a black art to it in terms of setting environment variables and stuff. But it's all pretty well documented. So this is everything that I need then to be able to launch my app in debugging mode. So I'm going to come back to my app. I'm going to set a break point. Let's just set one right before we actually log our message so that we can watch the contents of this variable. We'll go ahead and launch in our debug mode here. And great. We can see that we have all of our variables listed over here. We can see that my message has been populated as the way that we think that it should be. We can add watch stuff here too, really anything that any valid expression. I could even do an assertion here. I could say something like my message equals hello, is that a summit? And we see that our assertion is true because it's just going to execute that as code inside of the watcher. So pretty good debugger, pretty solid debugger. And that's how it relates to that launch.json file there. All right, let's just hit the highlights here. So when you're working with Node, your Node app is going to have a pretty basic lifecycle. Hopefully, you're working within some kind of source control. So you're going to start by creating a repository and cloning it. Then you'll start coding within there so that you can do your commits. And you normally get SDLC stuff. Of course, like we just did with Hello World, you can start with a completely blank directory. You don't have to put it into SCM if you don't want to. That npm init is the proper way to initialize a Node.js app. And we'll look at that in a moment here. So you want to use Node's tooling to initialize your application. It's kind of the right way to do it. Again, you don't have to. It's still going to work. We just watched Hello World work without any initialization. But it'll create a build file for you and give your project a name and all that kind of stuff. And it just kind of looks like this. It's just running the tool from the command line. So like we just said, it's best to use npm init to initialize the app. And in fact, we'll just do this really quick so you can see what's happening. So to bring it all back, to get started, install Node, make sure Node works, make sure npm works, pick an IDE, go ahead and get that out of the way, make sure that you can execute a basic Hello World application from the command line. Then the next thing to do when you're actually ready to start coding in earnest is to use the npm init functionality so that you can create your app in a standard way. So I've got another directory here that's empty. We're going to call this proper Hello World. We're going to create this according to best practices. And we'll just say npm init. And it's going to take us through a script. It wants the name of the package. We're going to give it that. We'll give it a version. My awesome Node project. It's my description. Entry point, what is it going to expect to be the bootstrapping file of the bootstrapping module? index.js is the same standard as it's always been. We may as well just leave it there. Test command. So what should be run for my testing framework, my unit testing framework for my app? That's in the advanced stuff. If I have a Git repo, I can put it here. Keywords for my stuff. So just metadata, author, name, and credits, license, GPO, 3.0, I think is right. Yes. So this is all OK. And then this is going to generate a file called package.json for us. And this is going to be used by NPM to initialize a program. But I'm going to skip ahead a little bit because I know we're running short on time and demonstrate really the point of this package.json file, which is really more like a build and dependency descriptive file. So I'm going to add a module to our program called colors, which allows for command line colors to make our output prettier. To do that, the easiest way is to just use NPM. NPM install is the syntax for installing a module. We're going to give it the module's name. In this case, it's the colors module. You go to NPM and search. That's typically if you're looking for some, like, I need a Gregorian date library or something. You're going to go out to NPM, and you're going to search through there to find different libraries that you can then pull in using NPM install. So again, really leveraging here the power of freely available public open source, too. I mean, we have all these modules that we can stand on the shoulders of giants. And I know I don't need to evangelize open source to this crowd, but really taking advantage of it here. So we're going to install colors, and we're going to do what's called dash dash save, which means not only do I want you to pull this module down, I want you to add it to my package.json file so that when I distribute my code, somebody else can just come and run the installer and pull those dependencies for me. So let's see what that looks like. All right, so I just added a module called colors to my app, and two things have now happened. First of all, if I LS my directory, I now have a new directory in here called node modules. If I go in there, here's my colors module. If I go in here, it's just another Node.js app. Every Node.js app is technically a module. There's different ways of exporting functions and things like that to make your module portable, but every Node.js app, everything you write, that hello world thing we just wrote before, is technically a module, right? So nothing too surprising here. This is just another Node.js app that's our colors thing. So it did that. That's the one thing it did. Another thing it did is that it added that dependency to our package.json file. So if we come back and look at this again, now we can see that we've got a dependencies block in here, and I just picked the most recent stable version of colors for me. I could change this. I could use semantic versioning constructs and fancy things if I wanted to. When I go to distribute my code to go and push it to some other environment, let's pretend I've just done that. I'm going to kill this Node modules because you're not going to want to distribute your entire modules, obviously, inside your SCM. You just want to distribute your code in SCM. You don't want to sit there and push hundreds of megabytes versus other modules out with your project as well. That's what makes Java annoying sometimes. So I'm going to kill the dependencies directory entirely. Now I'm back to just, oh, I started from scratch on this one. I didn't even do my index yet. So let's do our app. That's important. And in this one, we're going to say var colors equals require colors. And this is how we import a module. So I'm now importing the colors module. And now I can just use it. Now I can just use this colors object here, however I want in my code. In this case, I'm going to say console.log, colors.green. Hi. I'm green. And now if I go to execute this, it's not going to work because I just blew away my modules directory. So when this thing actually goes to get distributed, it's not like you're going to get distributed with the entire Node modules directory. So what do you have to do? You have to run npm install. So somebody would start with my code base and with that package .json file. And as long as those two things are in the directory that I'm running npm install, and it's going to recognize it, it's going to go pull my modules for me, and if I execute it again, then it's going to work. So that's really the whole process. See if there's anything else that I wanted to hit, because I know we are already over on time, and I'm launching way too many weird things on my computer here. All right. So we really just kind of talked through this whole last part, which was working with dependencies, adding some color. We just did this demo. Great. We actually pretty much hit everything. So kind of to sum everything up, what have we got here? Well, Node is a language that focuses on concurrency and unified development. So being able to execute a lot of things in parallel efficiently to take advantage of distributed compute, and also to help us culturally bridge the gap between various developer silos. Instead of having back end silos and front end silos, now everybody's just a JavaScript developer. Builds are assisted through npm. Node is asynchronous by default, which is one of the hardest things to wrap your head around with the language. We've got lots of IDEs for it. We want to initialize. We want to be good developers and initialize our Node apps with npm init. We can install our modules with npm install. That save is going to add that to our build file so that our app is then portable and can be dropped into any environment that has Node in npm and just npm install be run to get everything we need. They are included as variables in a project using the required directive. But there's still a ton to learn, obviously. This is just scraping the surface. This really is like half an hour out of a three day workshop that we have on Node with a lot more material in it. I also have a deep dive that I submit to pretty much every conference. Sometimes they pick it up. Sometimes they don't. I think all things open picked it up. And I think IBM Common picked it up, too. But a few things to concentrate on on day one. Once you can go through this motion, get to know asynchronous coding. And that just takes practice as all there is. You're just going to have to practice it and practice it. There's tons of examples out there, tons of good material for you to work through it. Get to know events and streams. We didn't talk about that. But Node is able to take advantage of these published subscribe patterns by having its own event stream. And streams are how we get past Node's memory limitations. Learn more about functional programming, closures, lambdas, callbacks, promises, whatever you want to call them. But get to learn about what that means for a function to be a first class citizen. And really the amazing things that we can do with that pattern. Master your debugger and start exploring other modules. And finally, I get lonely. Reach out to me. I like people. I promise you, if you add me on LinkedIn, I'll add you back. I do get political on Twitter. I'm a Pinko-Kami liberal. I'll just put that out there. So if that's going to offend you at all, you probably should just leave my Twitter alone. And then blogs. I do push a lot of blog articles out there whenever I can. In fact, the talk that I'm doing tomorrow on Prometheus and Grafana has a three-part companion blog series that's associated with it, too. Or you can just email me directly. So I know we're way over on time. I'm sorry. But I'm not going anywhere. So if you have questions, feel free to come up. Take a card if you'd like. Thank you. Yeah. Thanks.