What do you want to learn? Leverged jhuang@tampa.cgsinc.com Skip to main content Pluralsight uses cookies.Learn more about your privacy Introduction to MEAN.JS by Mark Scott This course introduces web developers to MEAN.JS, a free, open-source, full-stack solution for MEAN applications. Start CourseBookmarkAdd to Channel Table of contents Description Transcript Exercise files Discussion Learning Check Recommended Introduction Welcome Welcome to this Pluralsight course, Introduction to MEAN.JS. My name is Mark Scott. Since you're watching this course, there's a pretty good chance that you've at least heard of the MEAN stack and perhaps you are exploring using a full-stack JavaScript framework on your next web project. We'll start this module off by briefly discussing what the MEAN stack is and how it came to be. We will also discuss the origins of MEAN.JS and look at how to extend a scaffolded or boilerplate-generated website into a production-ready web application. We will also discuss and try to answer the question, why use a boilerplate framework in the first place? Next, we will do a general comparison of some of the other MEAN stacks that are available. Then, we will wrap things up in this module by taking a look at our demo project which will be used to illustrate how to begin a basic scaffold boilerplate framework and extend that into a full-blown application using a custom theme and features. Let's get started. What Is the MEAN Stack? So, what is the MEAN stack? Simply put, it is a collection of tools, or frameworks if you will, MongoDB, Express.js, AngularJS and Node.js, that when used together, form the acronym MEAN. The Acronym or term MEAN was coined Valeri Karpov on a MongoDB blog post when he stated, my team uses a set of tools that we affectionately call the MEAN stack. Since then, the MEAN stack in its various forms has been gaining a lot of attention in the web development community. Perhaps one of the more compelling reasons developers are moving in this direction, has to do with the stack's single technology platform, JavaScript from the database all the way through to the UI. In this course, we will not be going into depth on each of the tools or frameworks that make up the MEAN stack. There are already a number of Pluralsight courses available on MongoDB, AngularJS and Node.js that go a lot deeper into those particular technologies. Some of those course titles are listed here but there are many more in the Pluralsight course library. MEAN.JS, the variation of the MEAN stack that we will be learning about in this course, is described in the project's online documentation as a boilerplate. You may also choose to think of this as a template or code generator or scaffolding tool. And we'll be using those terms somewhat interchangeably throughout this course. So, next, let's talk about some of the reasons you may choose to use a boilerplate framework, such as MEAN.JS to get your full-stack JavaScript project started. Why Use a Boilerplate Framework? We throw terms around the time, like coke when we may generically just mean a soda or a cola, maybe not the specific brand Coca-Cola. So, let's take a short departure and find out what the term boilerplate really means. The origins of the term boilerplate are kind of interesting to learn about, and then to see how that term may or may not apply to software development. Interestingly, the term arose from the newspaper business. Columns in other print pieces that were syndicated were sent out to subscribing newspapers in the form of a mat. Once these mats were received by the newspaper, boiling lead was pored into the mat to create a plate. This plate was used to print the piece, hence the name boilerplate. Knowing that history, we fast forward to software development. In that space, this term and its use are a little murky. It can mean different things to different people but generally just means a block of code that is used over and over again. The original contributors to MEAN.JS used the term boilerplate, so we will use that term in this course as well. But it may be more appropriate to think of this as an application scaffolding tool. Similar to framing in a house or building, we were given the framing and some basic plumbing by MEAN.JS but we get to decide what type of drywall, paint colors, flooring, lighting fixtures etc., we want to put on our new software home. We can also think of this as code generation through the use of templates. Speaking of code generation, and back to our original question, why use a boilerplate framework, let's discuss some of the benefits of generating code versus hand rolling the entire application from scratch. First off, consistency. It goes without saying that if you use a template to generate boilerplate code, you're going to have a consistent start to that code base. Next, fewer bugs. The code in code generation templates is generally clean, tested and proven code. Best practices. A large number of frameworks are open source with wide community involvement and support. When something is poorly developed, or worse, breaks, there's a lot of noise. When something does not make sense or structured poorly, the crowd of open source developers cries and it typically gets fixed. Not always but in a lot of cases you will find clean, well-structured, best practice following code in a well-liked community-supported framework or code-generator template. Support. While this certainly cannot be said for every open source framework out there, popular ones, such as MEAN.JS, have good documentation, good community involvement and helpful code examples. You'll not be out there on your own should you need some support. And lastly, time. Don't waste your time doing the same things over and over again. Use a framework or a code generator. In future modules, we'll see how MEAN.JS utilizes code generation through the use of Yeoman. But first, let's discuss the origins of MEAN.JS, its family tree, if you will. Comparison of MEAN Stacks MEAN.JS, what this course is obviously about, began life as MEAN.io, but due to some differences of opinion on the direction things were going, MEAN.JS was forked off and went its own direction. It's not important in this course to go through the details of why they forked off, but if you would like to read more about that, check out this link. MEAN.JS strives to be less opinionated, although there are some opinions expressed here for sure. EJS is more of a foundational starting point than a full-blown, you-must-do-it-our-way type of framework. Since MEAN.JS originated as MEAN.io, in way of comparison, let's talk about that next. MEAN.io would be considered more of a framework than a boilerplate. It feels like it is more in line with a CMS platform in structure and in use. It is very opinionated, and don't just take my word for it, they even say as much right on their website. In the blog post URL shown here, you can read, quote, MEAN.io is very opinionated and tries to protect the developer from any core changes and we have moved everything to be package based. This means we have a more complicated core, yet a trivial way to extend it through packages. Being opinionated is not necessarily a bad thing. This may be exactly what you or your company needs for your particular web development style or needs. We've already briefly touched on Yeoman and code generation, and as an alternative to MEAN.JS there are a number of yo generators out there to choose from. Some examples are shown here, but there are a number of them to pick from. Just keep in mind the community involvement and support, or lack thereof, when selecting one of these other generators. The URL listed here will get you started on that search for MEAN generators. If you are more of a pioneering, do-it-yourself kind of person, and it just feels right to hand roll all of your code to piece together the application folder structures, and all of the many various JavaScript libraries and Node.js packages, then, that, of course, is also a viable option here. We are not going to do that in this course, we'll be using the code generator approach primarily for our demo application. Demo Project Preview For our demo project, we will be building a website that post the volunteer needs of various charitable organizations. Visitors to the site may click on a particular volunteer opportunity to get more details and then sign up to volunteer for that particular need. As we will see in a moment, the default, out-of-the-box MEAN.JS application comes with a reasonably nice bootstrap theme. But regardless, for real-world applications, you will want to use your own style. So, we will have a look at how to incorporate a custom theme that you may have either downloaded or obtained from a web designer. There are a number of very nice bootstrap and angular-based themes available. Some are free and other professional quality themes are very reasonably priced. For our demo project, we will be using a bootstrap theme called Solid, available for download here at this URL. Let's start out by taking a look at the out-of-the-box MEAN.JS application. I'm going to kick the website off by typing grunt here on the command line interface. Don't worry, we'll talk about this in more detail as the course moves forward. But for right now, we'll just jump right in and see what we have. By the way, I already have MongoDB running locally here. Opening up a Chrome browser and navigating to localhost port 3000, we can see the scaffolded site MEAN.JS initially gives us. It's a bootstrap responsive theme that's not too bad, but again, we're going to want to swap that out for one we downloaded. Moving back over to our command prompt, let's move over to a version of our demo site that already has the theme changed out. Rerunning grunt to kick things off here and refreshing the browser here to see the new themed site. Here's our Solid bootstrap theme. This is also a responsive design. Different fonts and color schemes here. Clicking on the View Current Volunteer Needs button here, will take us to a list of volunteer needs previously loaded in the database. Let's select dog walker to look at the details view for that volunteer need. We can see here on this page, the user is presented with a description of the volunteer need, how many people are needed and who I want to put some authorization around the edit and delete buttons here, so that only those who are logged in, and also in the admin role, can edit or delete a record. On the right side here, users of the site can sign up to volunteer for this need. An email will be fired off to the admin of the site. Let's log in to the site now and create a new record. I'll sign in and enter the username admin and the password. Under the Volunteer Needs drop down, I'm going to select New Need and we are presented with the New Volunteer Needs page where we can add a title, a description, the name of the organization and location and, as applicable, the start and end dates of the volunteer need. Then finally, the number of volunteers wanted for this particular need. Saving the record returns us to the Need Details view and we can see the volunteer need data was saved successfully. Returning to the full list of volunteer needs, our new record shows up there as well. This theme is not going to win any design awards but it will be useful in demonstrating where in the MEAN.JS framework we need to go to swap out our CSS and HTML elements. Summary Meanie, the cat here, is going to help us summarize each module. He's pretty grumpy, especially since there is nothing to summarize in this introduction module. In the next module, we will go over the tools and libraries that we will need to get our MEAN.JS boilerplate application off the ground. So, join me in the next module on Getting Set Up. I'll see you there. Getting Set Up Introduction Welcome to this module on Getting Setup. My name is Mark Scott. Let's start this module out by going over a few of the prerequisites for this course. Prerequisites As noted in the Mean JS online documentation, before we can start, we need to make sure that node JS, MPM, mongoDB, Bower, and Grunt are all installed on our system. Future versions of Mean JS will also support, and give you the option to use Gulp, for your build system and task runner. At the time of this recording, the current version of Mean JS is 0.3.3. And you will notice on the meanjs.org website, under troubleshooting, that the version of Node JS which is supported is 0.10.X. You may be tempted to simply install the latest and greatest version of node JS, but you may run into some odd issues if you do. For example, installing node JS 0.12.0 seems, at first, to work, but there are some compatibility issues with the Mongoose and Mongo Connect packages that are used within Mean JS 0.3.3. Therefore, it would be wise, at least for now, stick with the latest 0.10.X version of node JS. And for this course, I'll be using node JS version 0.10.36, and that can be found directly at this url. That url takes you to a rather nasty looking page that looks a little like this. If you want or need the 64 bit version of node, be sure to go into the X64 folder shown here. Windows users, you'll want the MSI file, shown here. And again, if you want the 64 bit version of this, be sure to go into the X64 folder. Mac users, you'll want to download the PKG file, and finally Linux, Sun OS and others, can download the respective TAR file. Follow the instructions for your particular platform. Installing node JS is pretty straightforward and simple, but please do refer to the online documentation at nodejs.org should you get into trouble with your particular installation. While it certainly is not required that you install mongoDB on your local development box, it probably is a good idea to have it on hand, at least initially while you follow along in this course. You can certainly utilize a cloud based instance of mongo DB, such as mongo lab or compose.io later. To install mongoDB, head on over to mongodb.org/downloads, as shown here. There, you will find the installer appropriate for your operating system. Simply follow those directions. Even though mongo DB version 3.0 has been released, for this course we will be using version 2.6.7. Mean JS has not yet been thoroughly tested against 3.0, it should work just find with mongo DB 3.0, but again, for this course, we'll stay with the 2.6.7 version. Now that you have node JS installed, the node package manager, or npm, is available to you. We'll be using npm to install our other required libraries now. Bower, for our client side package management, and Grunt for our task runner. To install bower, simply enter in nmp install dash g bower into the command line interface. Notice the minus g, which instructs nmp to install bower globally, making it available for use in any project folder location. Next, let's install Grunt by entering in npm install dash g Grunt dash cli. We will start with Grunt in this course, since that is what the current version of mean JS uses by default, but as mentioned earlier, you will see that, in the upcoming version of mean JS, you have the choice of using either Grunt or Gulp. In reality, you have that choice right now. Mean JS is only slightly opinionated, and you are fairly free to swap out and use whatever you want here. Although it is not listed as one of the prerequisites, because we will be using the yo generator to scaffold out our application, we need to make sure that YEOMAN is installed as well. We will do that here by entering in nmp install minus g yo at the command prompt. At the time of this recording, the master branch version is 0.3.3, as mentioned earlier. However, version 0.4.0 is right around the corner and it's also available on the get hubbard pository. By the time you watch this course, it may actually be the master branch, but for now, it's just not ready for prime time yet. We'll be looking at the upcoming 0.4 code in this course as well, in preparation for the changes that are coming. The path to the 0.4 repository is listed here. In the next clip we will use the YEOMAN generator that is available to us in the current version, and again that's 0.3.3, to scaffold out our mean JS demo application. We will then take a quick preview of the scaffolded boilerplate website that was generated for us. So let's fire up our command line interface and get started generating our site. Scaffolding a Full-stack Application I'll start this demo out by changing directories into our project folder named volunteer. Now, let's install the YO mean JS generator using the dash global flag, so that this generator will be available to use in any folder on our system moving forward. By convention you will notice that all of the YOEMAN generators begin with the word generator, followed by a dash, and then the name of the generator itself. Okay, the YO mean JS generator is now installed and ready to use. By the way, for a list of all of the YO generators available, head over to the YOEMAN website, found at this URL. YOEMAN.io/generators. If, for example, we enter in the search term of mean here, and while mean JS does seem to be the most popular one right now, which is good since you are taking the time to learn about it, you can see there a number of other YO generators related to the mean stack here. Let's jump back over to our command line and make sure we're in the proper folder before we begin generating our application. We are, so at the command prompt we simply need to run the YO command, followed by the name of the generator that we wish to use. And in our case that's obviously going to be mean JS. Notice that we do not have to enter the full name of the generator, just a portion of the name following generator dash. The YOEMAN generator will begin by asking a series of questions, starting with what would you like to call your application? We will name our application volunteer. For the question, how would you describe your application, let's just accept the default value for now, we can always go back in and change this later. For how would you describe your application, we will also accept he default values here, for now. As we examine the structure of the application in later modules, you will see where these values are injected. Next, for company or author name, we'll enter plural site. Or, of course, if you're following along with me here, you can enter in whatever you'd like there. For this demo, and so that we have something to review in the next section, I'm going to go ahead and say yes on the generation of an example article crud module here. We'll take a look at what that gives us here in just a moment. Now we are being asked about which angular JS modules to include, ng cookies, ng anime, ng touch and ng sanitize. For now, we'll just keep all of these options selected. If you do not wish to include one or more of these, you simply navigate to that option and press the space bar to toggle the selection. After answering the last question, our generator is off and running, stubbing out our new website. Depending on your system, this may take a few minutes to complete. The YO generator is hard at work, setting up our applications folder structure, stubbing in files, using npm and bower to install server and client side dependencies. In the next demo, we will go through and preview the scaffolded out site the YO generator just finished for us. Preview of Scaffold Site First things first, and let's make sure that mongo DB is running locally and on the default port of 27.0.1.7. Next, let's launch the site using grunt. So, you may be asking, why run the site using grunt? In the next module, where we take a tour of the scaffolded site's code and folder structure, we will take a quick look at the grunt file that was generated here and explore the tasks that are run for us by default using grunt. For now, to get this site up and running, let's just type in grunt at the command prompt. Here on the command prompt, we can see that our site it up and running now and available on port 3000. Let's open that up and take a look at what we have. Okay, nice, it's pretty basic, but it is a boilerplate scaffolded site after all. You may recall that we told the YO generator that we did want to build out a sample article crud module. Before we can take a look at what that gave us, we need to sign up first on the site. That gives us a quick look at the sign up and authorization that is provided out of the box, too. We'll select sign up, and then provide the first name, last name, email address, user name and password details. One thing to note here, as a brief side, you'll probably want to add an extra password verification field here, to help users avoid typos with their passwords. Great, okay, now I'm officially logged in to the site, and now we see the articles menu option here on the navigation bar. Selecting the list articles menu, I can see that we currently do not have any articles in the database. I'll select create one here, and enter the new title and contents for a sample article. I'll just copy and paste in some sample text from dummytextgenerator.com. Submitting that saves our article to the mongo DB database and returns us to the articles list page. Now that we have an article, we have a couple of additional buttons over here that allows us to edit and or delete this article. This is pretty basic stuff, but really that's the point. You will be building on top of this boilerplate code to make something really great and useful for your own business needs. Summary In this module we covered the tools and libraries we needed to get our mean JS boilerplate application off the ground. In particular, node JS, mongo DB, Bower, to manage our client side dependencies, Grunt for our task runner, and of course YOEMAN, which we used to actually generate our boilerplate scaffold site. We took a short preview tour of the boilerplate site that mean JS gave us, out of the box, via the YO generator. But in the next module we will take a more in-depth tour of the application's folder and code structure. I hope you'll join me in the next module for that tour. I'll see you there. Tour the Scaffold Site Introduction Welcome to this module where we will tour the scaffold site. My name is Mark Scott. In the previous module, we used the yo generator to generate out a fairly nice boilerplate site for us. The nice thing is that the yo generator generated a lot of well-structured code for us. The bad thing is that Yo generated a lot of well-structured code for us. As we go through this module together, I'm sure you will understand what I mean. If you had to hand-roll all of that code yourself, you would be very familiar with it, but you would have spent a lot of time doing so too. The main purpose of this module is to give you a roadmap of sorts so that you can navigate through the code and folder structure that was just set up for us. We do not need to understand every single aspect of this boiler plate application, to get started and to be productive. But a good foundational understanding goes a long way in avoiding a fair amount of frustration. We need to start this module off by first looking over the Boilerplate application's structure, discussing how things are laid out and where to find key pieces of your application. Next, we'll move on to discuss configuration. You know, things like connection strings to MongoDB, for example. You're clearly going to need to know where to make those types of changes. Finally, we're going to take a quick look at the upcoming 0.4.0 version of MEAN.js, and do some comparisons between 0.3.3, the current version, and 0.4.0. Application Structure (Server-side) When it comes time to customize the Boilerplate code that MEAN.js provides for us, it will be very helpful to understand the folder structure and other patterns that MEAN.js uses. In this section, we will see that files are primarily divided up into two parts, code for the server side and code for the client side. We will start by looking through the folder structure that houses the server-side code, and then move on to our client-side folders and files. Let's jump back into our editor and take a look. The server side code for MEAN.js 0.3 lives here under the app folder. Any time you need to work on a server-side controller, model, route, test, or view, this is where you'll want to go. And as we can see here, those various file types are separated out into their own respective sub folders, controllers, models, routes, tests, and views. We'll start with the controllers folder. As discussed in the course introduction, the E in MEAN stands for Express. Here we find our server-side controllers, which is where your business logic and restful API service code lives. In the previous module, we examined the sample application that will scaffolded out for us, and we created a sample article of record. Now let's take a quick look at the controller code here that was used to create and list those article records. First take note of the naming convention in use here, articles.server.controller. Later when we look at client side code, you'll notice that the same naming convention is in use there with files being named .client and so forth. We'll not go into great detail right now on this particular controller file, but here is the article Mongoose model used to retrieve data from and save data to MongoDB. Next we see the CRUD, or create, read, update and delete functions, as well as a list and article by id function to get a full list of articles or an individual one by its id from MongoDB. We will go in to more detail on these functions and build out our own controller for our volunteer needs demo application as the course progresses. The next subfolder down the list here is models. This is where we find our backend models for the application. As noted earlier, these are Mongoose models, and are what we use to communicate with M in MEAN, MongoDB. We will be building out a custom Mongoose model for this course, but to get more detailed information on Mongoose, please take a look at my other Pluralsite course, Introduction to Mongoose for Node.js and MongoDB. Next we find the routes folder, which contains our server side route mappings. For example, if we open the core.server.routes.js file, we can see that the root of the site is getting core.index. Notice above where the core variable is defined and we can see that we are requiring the core.server.controller file and this is where the index method is located. For another example, let's take a look at the article routes that were setup for us by the generator. Here we can see the various get, post, put and delete routes. As an example here, take a look at this get route. Notice that the articles.list is obtained by requiring the server side controller we looked at a moment ago. Now we'll open up the tests folder. MEAN.js uses Mocha for testing server side code, and while we will not go into any details on testing here in this particular module, we will cover that in the testing and deployment module later on in this course. For now, just know that this is the folder these tests will live in. Now let's take a look at our server side views. There are not many views here, and that's a good thing. Keep in mind, these are server side views. The vast majority of the views in our application are going to be Angular client side views. As you can see, we have views for handling 404 and server side errors. The index view is the shell in which we load our client side Angular views and the layout view file is our master layout, or theme template if you will. We will modify the layout view in a future module when we apply our custom theme. Let's move on down to the server.js file for a moment. You may also see this named something like app.js and other Node.js web applications. This is the main entry point for the application, where everything gets kicked off from. The contributors to MEAN.js have done a good job of keeping the server.js file clean and clutter free. I'm sure we've all seen demos where everything was placed in this file. Here are the main things to take note of in this file. Here at the top is where our node module dependencies are defined. Next we see where we are establishing a connection to our MongoDB database. And initializing the express application. You can see the various places where files are being required from a config folder. We'll be covering configuration and revisiting that folder in that section of the course. Here you can see the MEAN.js utilizes Passport for authentication. And finally we will open up a port and start listening for inbound requests. Now let's open up the package.json file and take a brief look at that. There are four sections to this file, metadata here at the top, scripts, dependencies and development dependencies. When we ran the yo generator in the module on getting set up, we were asked what we wanted to name our application to provide a description, version number and so forth. This is where that information landed for us. So should you want to make some tweaks to that information, here's where you'll find those details. There are a number of node packages utilized in MEAN.js. And those are all listed here in the dependencies section of the package.json file. The last section is where we find our development dependencies. These are the node packages that will not be included in a production build. That was a tour of the folder structure and key aspects of the server side code that were given out of the box by MEAN.js. Now, let's shift our focus on to the client side code. Application Structure (Client-side) Our client side Angular code lives here under the public folder. The first folder we see here is the live folder. After we go through our first build process, we will also have a dist folder here as well. We will see this in action during the module on testing and deployment. For now, just make a mental note that this is where the minify JavaScript and css files will be sent to by the grunt build process. The live folder is the library of all of our client side bower packages, such as Angular, Bootstrap, and jQuery and any package you may add in the future as you expand your own MEAN.js application. The modules folder is where we find our AngularJS application modules. When we first looked at a preview of the basic Boilerplate site that we get from MEAN.js after running the yo generator, we landed on the homepage. That would be a good place to start exploring how the client side Angular modules are structured. Note we do not see a home module here. There is, however, a core module. And this module houses the Angular controller and the view html for our homepage. So let's take a look at that. Opening the core folder, we see a number of subfolders. We will discuss a number of these, but let's start with the config folder here. The Angular route file here is used to configure, or map the route to a particular html page. We can see here that the route of the site is mapped to the home.client.view.html page. Let's take a look at that homepage now. This is the html for our homepage. And we can see this is an Angular view based on the mg-controller directive at the top of the page here. We will be replacing the html found here with our own there in a future module, but for now, let's just take a look at the home controller associated with this view. There's not a lot going on with this controller. But in a moment we will take a look at a busier example when we look at the articles controller in the articles module. Note that scope and authentication are being injected into this controller by Angular using dependency injection. So where is authentication coming from to be injected? That may be a little tricky to grasp at first, but there is an authentication factory defined in the user module. Let's take a quick look at that. Here is where authentication is being defined so that it can be injected into our controller. But for now, let's just stay focused on the core module and its folder structure. MEAN.js provides a basic navigation and menu system. You may wish to utilize something different for your own project, but for our demo application, we will continue to utilize the built-in mini system provided by MEAN.js. So let's take a look at that now here in the core module's services folder and see how that is configured. I'm going to collapse this down a little so it's easier to see, and if you're on WebStorm on a Windows platform, that's Cntrl+* and the number one. There are a number of menu related functions exposed to this Angular service for us. And anytime my menu service is needed, we simply need to reference this. And an example of that, let's open up and take a look at the header controller file. We can see where the menus service is being dynamically injected here. The other two folders here we have not yet covered are the css and image folders. Those should be pretty self-explanatory. For this core module, this is where we can place the css and image files that we may wish to make available to all views within our application. Other modules can have their own css or image folders that could be used specifically for that module. Now let's take a look at the articles module. Here we find a very similar folder structure to what we saw in the core module, config, controllers, services, and a new folder test. And a views folder to house our Angular views. As with the core module, let's start by opening up and taking a look at the config folder. Here we see our config and route files. The config file is where we will set up the navigation menu for this module. If you recall menus here is being injected in by Angular's dependency injection services. Next we'll see the routes file. MEAN.js utilizes the Angular UI project's UI router which uses a state machine design pattern abstraction on top of the traditional router. Routes are referred to as states and the URL simply becomes a property of that state. A default route for URLs that do not have a specific route was handled for us in the core module's route file using the built in Angular ngRoute. Now let's dive in to the controller file for articles. This is more interesting than what we saw earlier with the core module. Here we can see that we are attaching create, remove, update find and findOne functions to the scope object, which makes those functions available for use in our Angular view. $scope is glue, if you will, between our controller and our view. You'll notice here too that there is a whole lot of dependency injection going on in this controller. $scope, $stateParams and $location are being injected by Angular. And we've seen that authentication is being given to us from the user's module, but it may not be obvious where articles is coming from. Once again, let's take a look at our services folder and see if we have a factory in there spinning up this object for us. Sure enough, he we find our articles factory method and we can see that this is providing us a gateway back to our server site API endpoint, allowing us to grab data from MongoDB via Mongoose, and also send back data to the database via a put. So how are all these modules registered in the system? If we open up the articles.client.modules.js file here, we can see that our articles module is being registered here using the application configuration registerModule function. And that can be found in the config.js file. Let's open that up and take a look. We can see here that this function takes in the module name and any dependencies, and then creates the Angular module and then pushes the module onto the AngularJS configuration file. Moving back to article's client module file, we can see that the article's module did not pass over any dependencies. But modules you develop very well may. If you wish to utilize this method of registering your own Angular modules, simply pass any module dependencies into the register module function. When we use the yo generator, and told it to go ahead and include ngCookies, ngAnimate and so forth, here's where those dependencies were automatically added for us. If you add additional packages to your application, you may need to add those to the list as well. The last file that we will look at in this section is the application.js file. This is the main Angular application file for MEAN.js. It's job is to kick things off, bootstrap the application, if you will, and attach the right modules for us. So that was a tour of the boilerplate code provided to us by MEAN.js. As stated earlier, knowing where things are will help to reduce your frustration levels when it comes time to dive in here and customize this code base to make it something production ready. And of course, we will be doing just that in an upcoming module. Configuration In a previous module, we generated our new boilerplate application and we took a quick look at the app and what we get out of the box. We headed some sample articles and that all seemed to go pretty well. So we can assume this data was saved to our local running instance of MongoDB, but where is that data connection information stored? What if we decided to change the name of our application or the connection string to MongoDB, or change the keyword details for SEO purposes. Where do we go to configure our application. That is what we're going to talk about next. So let's jump back into our editor and take a look at how configuration is setup in a MEAN.js application. Let's start by opening up WebStorm or whatever editor you choose to use and head over to the config folder and open up the config.js file. Notice in this section of the file that this is where the app configuration files are loaded. One named all.js and the others based off of the node environment variable setting. For example, we are by default set to use the development node environment so we can expect to find a development.js configuration file. Opening up the environment or env folder here, we can see the various application configuration files available to us, and those will be loaded based again off of the node environment variable setting. Well start by taking a look at the all.js configuration file. Do you recall some of the questions asked of us when we used the yo generator to scaffold out our site? Here's where some of that information landed. Our application's title is here, a description, and keywords for SEO purposes are all here as well. Moving on down the list, we can see that we're using swig for our view engine. And here's where the various assets for our scaffolding site are defined. Any future module where we provide our own theme, it's going to be important to remember that this is here. This application configuration file will get loaded regardless of the node environment variable settings. So let's take a quick look at what the development.js environment file gives us. Okay, so you can see now that this is where MondoDB connection string is defined. We're going to leave this as is for now, but should you need to change this to, let say point two Mongo lab or compose.io or some other cloud provider, this is exactly where you'd want to go to make that change. We will not be using any of these other configuration settings in our application. But should you choose to provide authentication through, say, Facebook, Twitter, Google, LinkedIn or GitHub, this is where you would configure that. We will take a closer look at the production configuration settings in the module on testing and deployment. For now, just know that this is where you'll need to go to make configuration setting changes for your production environment. Earlier we were talking about which configuration file would get loaded based upon the node environment variable setting. The question may be how does our application know to use the development by default. Heading over to the net.js file here, we can find that answer. If we had specifically set the node environment variable, this section of code would validate that we indeed have a matching configuration.js file to load by that same name. If, however, we did not set the node environment, then we can see that development will be set as the node environment variable for us, ensuring that the development.js configuration file will be loaded in the subsequent call to config.js, what we looked at first here. So where is all of this configuration loading originally kicked off from you may be asking. Let's take a quick look at the server.js file here. Notice the first two requires are to our config/init.js file and then to config.js. That is what sets this whole thing in motion. While we are here in the server.js file, let's move down just a little and notice one more configuration file that is getting called. The one to initialize our express application, the E in MEAN. Let's take a quick look at what's in express.js file. We will not go through this entire file, but you can quickly notice that this is where the module dependencies are required. The main takeaway from this file is that this is where the express application is defined and returned to the startup server.js file. One other thing to make note of while we're here, is how the contributors to MEAN.js have set this up in such a way as to have several objects automatically loaded during the application Bootstrap process. Let's run down the list of what those are. Here we can see that all the server side model files are loaded, and here we can see the various routing files that are loaded for us. If we reopen our server.js file and move down just a little, we can see the section of code where our passport configuration is loaded up. MEAN.js utilizes the passport.js library for user authentication. A moment ago, we saw the settings for logging via Facebook, Twitter, Google, LinkedIn, or GitHub. Passport uses various strategies for this and depending on the needs of your application, you will want to ensure those strategies are loaded. This is where the various Passport strategies you have defined are loaded automatically for you. For other specific configuration settings you may need to make tweaks to, such as a particular passport strategy, or how to setup custom configuration properties, I would encourage you to visit the MEAN.js site and review their good documentation. Coming Changes Now that we've explored the application structure of the current version of MEAN.js, let's take a look at some of the coming changes in version 0.4. For this demo, we'll take a quick look at some of the key structural differences between the current version 0.3.3 and the pending version 0.4.0. Since the upcoming new version of MEAN.js does not have yo generator to fully stand up a project, version 0.4 has already been downloaded from the URL shown here and MPM and Bower installs have been run to pull in server side and client side package dependencies. We'll pull both versions up side by side but we will primarily focus on the folder structure and files rather than the code differences. Let's open up two editors and get our comparisons started. We have the current MEAN.js version 0.3.3 and the upcoming version 0.4.0 open side by side here. We've already toured the scaffolded site and its code and folder structure. So, we will not do that again here, but one thing that needs to be pointed out in way of comparison, is how the 0.3.3 version's code is divided up by type, for example, opening up the app folder here we can see folders for controllers, models, routes, tests and views. Again, groupings of types, not features here. Now let's compare how version 0.4 has things organized. I'll open up the controllers folder here on the 0.3.3 side, and select our articles controller. Over on the 0.4 side, we do not have an app folder. Things here are organized by feature. Opening up the modules folder, we can find all of those features. For example, articles is a feature here. Opening that folder up, we see folders for client, server and tests. If we want to find the equivalent server side articles controller, that's found here under server, controllers. And you can see that we've retained the naming convention here, articles.server.controllers.js. Now let's compare server side models, same thing here. And the server side articles route is found here in the 0.4.0 version. Have you noticed yet how with the 0.3.3 version all of the controller files are listed in the controllers folder, and all of the models are listed in the models folder. Same for routes and tests as well. That is precisely what is meant by the type based folder structure versus the newer feature based structure on the right with version 0.4. Alright, let's close these folders up and move down to discuss configuration files. You can see that both versions have a config folder; however, things under the config folder have changed. Here we have an assets and environment folder. And rather than an all.js environment config file, we now have default assets and default environment files. You may recall from the previous clip that environment config settings are things like port number, MongoDB connection, and the application, title and description. What view engine we're using and the current version the settings for assets are placed here too. Things like where our css and JavaScript files live. Those have been broken apart now in the 0.4 version into separate folders. So things that are related to assets are in the well, assets folder and likewise with the environment settings. Okay, next let's take a look at our Passport strategies. You'll notice there is no strategies folder here under config on the 0.4 side of things. So where do those live now? Really, since Passport strategies deal more with authenticating a user to our site, it makes a little more sense to place those over here under the modules, users, server config folder. And there you can see the exact same strategies as before. Next we see that the config.js file remains the same but the express.js file has been moved and now lives under the live subfolder here. Additionally, we now have two new files here. One for Mongoose settings and the other for socket.io. Version 0.4 includes a nice chat client example which uses socket.io. Now let's change gears and look at the difference to client side code. To start, we'll open up the public folder and modules, and articles. We once again see our folder structure for Angular controllers, services, views and so forth. On the 0.4 side here, we see a public folder, but that's not where our client side code lives anymore. If we go back into our modules, and our articles folder, you can see the client folder here. You probably noticed that earlier when we were in this folder. Here we find the same AngularJS files such as our articles controller and our various views too. At the root folder here, you can see that very little has changed. You will notice in this example that we have both a grunt file and a gulp file. That is because this code was downloaded directly from the GitHub repository and not generated from the Yeoman generator. At the time of this recording, the generator was not yet complete. They do have the CRUD module sub-generator working pretty well, but not the full MEAN.js scaffolding generator. Now that you've had a side-by-side breakdown of some of the structural changes coming to MEAN.js I would invite you to visit the GitHub repo and grab a copy of the 0.4.0 code and tour through it on your own. You'll find that while things have changed, they're not vastly different and are frankly pretty smart changes. Summary That was a lot to take in all at once. You may want to re-reference this module and also take a look at the online documentation at meanjs.org. The main goal of this module was to give you a roadmap so that you can navigate through the code and folder structure that you will find, whether you use the Yeoman generator as we did earlier to kick off a boilerplate site, or if you simply cloned the MEAN.js repository on GitHub. Granted, there is a lot of code here, but having a foundation of what files go where and how to configure your site, you should be able to get started right away. In the next module, we'll do just that by using the Yeoman generator to generate a CRUD module that we'll need for our demo application. I'll see you in the next module. Code Generation Introduction Welcome to this module on code generation. My name is Mark Scott. In this module, we will learn about the Yeoman Project and in particular, the Yo web application scaffolding tool that was used in the getting set up module. A number of the MEAN.JS sub-generators will be discussed and demonstrated as well. In the demo, we'll take a look at the CRUD module sub-generator and utilize Yo to generate out code similar to that which was provided to us in the article example from MEAN.JS. What Is Yeoman? Most of the time when you hear someone talking about Yeoman, chances are they are actually referring to only one part of the Yeoman workflow, the Yo web application scaffolding tool, which uses generators, or templates if you will, to stub out web projects for you. But there are two other tools that make up the full Yeoman workflow. Those are a package manager, such as Bower, and a build system, such as Grunt or Gulp. None of the three tools that comprise the Yeoman workflow provide a user interface and therefore are used via the command line interface, as you've already seen when we stood up the basic MEAN.JS scaffold site in a previous module. The Yeoman team has done a great job providing documentation, tutorials, and examples on their website, and I would encourage you to visit their site for more details on the Yeoman Project, including a full list of generators that are available, one of which of course is the official MEAN.JS Yeoman generator we used earlier. Just click on the Discovering generators link at the top. Sub-generators Provided Many of the Yo generators provide the ability to scaffold out additional parts of your web application. These are called sub-generators. The MEAN.JS generator includes a number of these sub-generators, and we will discuss a few of those here in this section of the code generation module. The MEAN.JS sub-generators fall into one of three categories, a full CRUD module sub-generator, those used for Angular, and those used for Express. We will start by demonstrating the CRUD sub-generator. When we first used the MEAN.JS Yo generator, one of the questions asked of us was whether or not we wanted to generate a sample articles CRUD module. We selected yes and have since examined the results of that action. By selecting yes, the MEAN.JS Yo generator actually utilized its own CRUD module sub-generator to create the modules folder and supplemental folders for images, CSS, routes, controllers, and tests. The sub-generators were also used to build on Express and Angular module files to create Angular module views and if we indicated that we wished to add this CRUD module to the navigation menu, the necessary menu configuration as well. In the next module, we will need to utilize the CRUD module sub-generator to add in to our demo application an additional CRUD module to handle our volunteer needs. When you need to generate out a one-off CRUD module like this, simply run the yo command plus the main MEAN.JS generator, followed by a colon and then crud-module, plus the name of the module you're wanting to build out. For example, if you want to generate out a customer CRUD module, this is what it would look like at your command prompt. By the way, should you want to dig into it and look at the actual code behind all of this magic, the CRUD module's sub-generator source code has been made available on GitHub at this URL. In fact, you can find the source for all of the sub-generators on GitHub. One of the first sub-generators the CRUD sub-generator used was one to scaffold out our express controller. In the example shown here, we can see that the main MEAN.JS CRUD module utilized the express controller sub-generator to generate the articles controller. As before, should you need to generate a one-off express controller, you can simply type in yo meanjs:express-controller, plus the name of your controller in the command line interface. And likewise, should you need to generate a one-off express model, you can simply type in yo meanjs:express-model plus the name of your model in the command line interface, as shown here. Our scaffolded boiler plate demo application included a sample article CRUD module. Part of the code that was generated there for us was the express routes, which allow for data to be retrieved from and saved to MongoDB. Occasionally, you may need to build out an individual express route file, and using this sub-generator will do just that for you. As with other sub-generators, simply enter yo meanjs:express-route plus the name of your new route. This sub-generator doesn't do a whole lot. It merely stubs in an empty route file for you. Feel free to use the article route as an example of how you can build out your own route, should you need to. Now, let's take a look at some of the sub-generators that allow us to build client side angular modules, routes, controllers, views, services, directives, filters, configurations, and tests. As with the express modules that were generated for our example articles module, there were a number of client side angular sub-generators that were put into motion for us to generate out angular routes, a controller, a service file, and some tests for our controllers, and finally, the various views to create, edit, list, and view our sample articles record. Should you need to generate a one-off angular module, you can simply type in yo meanjs:angular-module plus the name of the angular module you wish to generate on your command line, as shown here. Let's say for example that we wanted to generate out a angular module named widget. We would enter on the command line yo meanjs:angular-module widget, as shown in the example. The sub-generator will ask, "Which folders would you like your module to include?" Simply toggle the various folder selections on or off as your needs dictate. The angular module sub-generator then goes to work creating the folder structure based on your selections and, for our example here, a file named widget.client.module.js. Taking a look in the angular public modules folder, we now have a widget folder with sub-folders, again based upon the selections when using the module sub-generator. Again, the only file that was generated for us here was the modules file. The config, controllers, services, tests, and views folders are empty at this point. But as you might imagine, there are sub-generators to help us out there, and we'll take a look at some of those now. If you generate a one-off angular module, chances are you may want an angular route as well. The pattern here is the same, yo, followed by meanjs, a colon, and then angular-route, plus the name of the route you wish to generate. Let's take a look at another example of generating a widget route for this widget module. Notice here that the first question the sub-generator is asking is, "Which module does this route belong to?" Use your arrow key to move down and select the appropriate module, which, for our example, is widget. The angular route sub-generator will ask a few more questions, such as, what would you want your route path to be and what you want to name the associated view and controller files. The assumption here is that since you are generating an angular route, you very likely will want and need a controller and view as well. In this example, you can see that the sub-generator created four new files for us, the routes.js file itself plus the controller file and tests for our controller file as well, that's a nice bonus, and then, the view.html file. However, should you need to generate out a separate angular controller, here's how that can be done. Again, the exact same pattern as before, yo, then meanjs:angular-controller, and the name of the controller you wish to generate. Tell the sub-generator which angular module this new controller belongs to, as we've seen before, and the new controller and the test files will be added to that angular module. And to add a one-off angular view, you guessed right. Same pattern here, too, yo meanjs, then angular-view, and the name of the view you wish to generate. In this example, we've already answered the question, which module does this belong to, and what is the name of the controller for this view. But notice the question about adding a route for this view. Much like when we used the angular route sub-generator, it will ask us about generating a view. The reverse here is true as well. If you start with the view sub-generator, you're going to be asked about generating an associated route as well. After answering the last question, what is your route path, the view.html file is generated. As you utilize these sub-generators, you will notice that they are only getting the basic scaffolding done for you, laying out the folder structure, generating some files which follow the name convention we've seen in use here, and stubbing in some basic code and not a lot more than that. It's up to you to add the meat to the skeleton, if you will. Building out the Scaffold For our demo application, we're going to need a new CRUD module, one that we will use for the volunteer needs we want to list out on our demo application. Just like the example articles CRUD module we have been exploring already, this module will need to provide us with the ability to create new volunteer need records, or MongoDB documents to be more precise, read in existing volunteer needs, update existing documents, and naturally delete those documents as well. We could copy all of the files originally generated for the articles example CRUD module and start swimming through code, changing names from article to something else, but we're not going to do that. Instead, let's utilize the provided sub-generators to stub in a new CRUD module for us. Let's open up a command prompt and get that going. Here in our command line interface, to get to our MEAN.JS CRUD module sub-generator, we first start by entering yo, followed by meanjs, then a colon, followed by the name of the sub-generator we wish to use, in this case, crud-module, then the name of the CRUD module we want to generate. We'll name this CRUD module need to go along with the volunteer needs that we wish to save and display to our potential volunteer site viewers. The first prompt we see is a question about supplemental folders. Available selections are css, images, directives, and filters. If, for example, you are pretty certain that you will need some custom CSS styling for your module, then toggle that folder selection on. Same for the other folders as well. For this example, let's just say that we may need some custom CSS styles and images, so we'll toggle those two on by arrowing down and hitting the space bar and then moving on to the next question. This next question is asking about the menu system that MEAN.JS provides and whether or not you want this new CRUD module to be part of that navigation or another menuing system. In the introduction module, we saw this menu in use at the top of the page. We do need to give our users a couple of different ways to navigate to our volunteer needs listings, so let's select yes here. And then, accept the default menu identifier of topbar. Before we move on and generate our CRUD module, this question should be a clue to you that we can't have more than one menu and that your CRUD modules can interact with different menus. Say for instance, you only wanted this module listed in a side navigation menu but not the main navigation menu at the top of the page. Here's where you can make that determination. Hitting enter one more time and we're off generating code. Look at all that code that was generated for us. That's really nice. You may not have noticed just now because the code was generated rather quickly, but the CRUD module sub-generator is actually packaging up and running some of the other sub-generators we spoke about just a moment ago, both for client and server side. We can see that we have a server side model, routes, and tests, as well as a client side angular route, controller, service, test, configuration, module, and angular views to create, edit, and list documents, as well as a view to display individual records, all stubbed in for us at the route folder for our project. So unless the creators of this sub-generator have figured out a way to read our minds, and I assure you that they have not, we're going to have to go into these files and work on them a little. So let's jump back into our editor and take a look. For example, let me open up the model file here. This is not exactly what we're going to need for our mongoose model. We will get to that in the next module in this course, where we build out this model to meet our demo application's specific needs, as well as customizing the look and feel of our site. While we are here in our editor, let's take a quick tour of the files we just saw generated. Here in the app controllers folder, we see our needs controller and our routes and tests and over here on the client side of things, we have a new needs sub-folder, with angular routes, controllers, services, views, and tests. And since we said we wanted the css and images folders stubbed in for us, those are here as well. Summary In this module, we discussed the Yeoman Project and in particular, the Yo web application scaffolding tool that was used in the getting set up module to stand up our boiler plate web application. A number of MEAN.JS sub-generators were also discussed, and in the demonstration, we utilized the CRUD module sub-generator to generate out code for our volunteer needs, similar to that which was provided to us by the article example. In the next module, we will pick up where we left off here and take our application from merely being a scaffolded site to a usable application by building out our mongoose model, styling the application, and adding views and controllers to create and list out volunteer needs from MongoDB. From Scaffold to Application Introduction Welcome to this module on taking our generated code from scaffold to application. My name is Mark Scott. When this course was introduced, a partially finished version of our final demo application was shown. We saw the replacement Bootstrap theme called Solid which is available for free to download. In this module, we will download that theme, learn where in the MEAN.JS application structure the CSS and new HTML needs to be placed, and test out our new look and feel. Additionally, we will build out a new mongoose schema and model, based on the business needs for our volunteer needs demo application. Once we have our volunteer needs model in good shape, we'll move on to developing our server and client-side controller and our angular views. That will get us in pretty good shape, but we'll also want to visit the various tests that the cred generator built for us, and make adjustments to those as well. Let's get going on restyling and adding functionality to our demo application now. Styling Your Application In the Tour the Scaffold Site Module, we examined the folder structure given to us by MEAN.JS, and part of that structure is where our CSS and image files live. Not to mention the client-side views we need to change to match our demo application's specific needs. Let's take a moment to revisit the specific parts of our MEAN.JS boilerplate application that we will need to touch in order to replace our theme. One really helpful thing to understand up front is, where all the various CSS and image files are loaded from in the first place. Let's jump back into our Editor and take a look at that now. If we examine the application's main layout view, there you will see where and how the CSS files are loaded. As a reminder here, MEAN.JS uses the Swig view engine for server-side views. This layout view is a foundational part of the base view that is sent over to the client from the server. If you are familiar with ASP.NET master pages or layout views for MVC, this layout view serves a very similar function. This is the Swig view engine's way of looping through a collection of CSS files, providing a link to each one of them. But where is this collection of CSS files created from, you may ask. To answer that, let's start by heading over to the all.js environment file. Here we see that an array of CSS assets has been set up for us. If we need to point to additional CSS files, we'll want to add those in here as well to ensure that they are loaded. But where is this CSS assets array used at? Let's take a look at the config folder and the express.js file here. Notice here, where app.locals.cssFiles is being set to the return value of config.getCSSAssets, and the getCSSAssets function is found in the config.js file. Here, near the bottom of the file where all of the CSS assets we looked at a moment ago in the all.js environment file are globed together and returned. We then looped through those CSS files in the layout view and load each one. With that all in mind, we have a decision to make. Where do we want to put our new CSS and image files? We just saw in the all.js environment file that we're grabbing all of the CSS files under the public/modules folder, which suggests that each module can have its own CSS file, and images too for that matter. But what about the main CSS file for the entire application? That we find in the public/modules/core/CSS folder. So we can replace what we find here, and that would certainly be acceptable, or we may also choose to simply create a new theme folder that can easily house our downloaded theme. Either approach is fine, so for our demo application, let's just create a completely new theme folder here under our public folder, and copy and paste in some CSS font and image assets from our downloaded theme. I have already downloaded the Solid theme and made some minor modifications to it. But before I copy and paste in those files, let's take a moment to see where the original theme is available from. If you're following along here, feel free to download this theme or any other Bootstrap theme you may find here. There are a number of free themes available, and others are very reasonably priced. Back in our editor and here in the new theme folder, I'll copy in all of the assets needed for our new look and feel. That's great, but our demo application will not yet know about these files. We'll need to go back to the all.js environment file and make some adjustments now. We'll want to use the Bootstrap and style CSS files from our new solid theme, so we need to change out the assets lib CSS section here. Now we also need to add all of the CSS files to the assets CSS section here to ensure that these CSS files get loaded and used. For now, we'll just leave the existing CSS files here to load. We may use some of that styling for things like menus and other core parts of our application. Whether you decide to create a theme folder, as we've done here, or place the CSS and image files under a specific module folder, the process here will be the same. You just need to wire that information up in the configuration files as we've done. Now let's change gears a little and work on the mongoose model for our volunteer needs views. Mongoose Models In the cogeneration module, we use the Yo MEAN.JS cred module sub-generator to stub in our need module. Part of the cogeneration process created a new express mongo model for us. There's not much here. The sub-generator merely set up a shell schema and model with a bare-bones minimal mongoose schema and code to build out the mongoose model based off of that schema. We're going to need a lot more than this. For our volunteer needs mongoose schema, we're going to want to store a title and description, and which organization the need is for, and the location for the volunteer need. These volunteer needs may be ongoing or they may be needs an organization has opened between specific start and end dates, so we'll want to capture that in our schema as well. The organization requesting volunteers may need one person or many people, so we'll add to our schema the number of volunteers needed as well. We need to go back into our editor now and fix up our mongoose model based on what we've just discussed. Let's open up our model file and add the various fields we just defined that we will need for our demo application. Again, this stubbed in model is just not going to cut it. We need a lot more here. Let's clear this out and start building the model we'll need for our volunteer needs. We'll need a title, which will be a required field, a description, which is also required, the organization, and location, start and end dates, which are of type date, and the number of volunteers needed for this. Next, we'll add into the schema an array of volunteers, which will be the object ID from our logged-in user. This array will house the user IDs of those logged-in users that sign up for a particular volunteer opportunity. I've also added in isActive flag here and set its default value to true. Boolean fields such as this can be handy in a number of ways. Let's say, for example, we need to add a volunteer need into this system, but deactivate it because it's just not ready to be displayed to the public yet. Another use could be, say, for a soft delete. Finally, we have the typical audit fields of created on and created by. Okay, I think our mongoose schema and the model built from that schema are now in pretty good shape. If you would like to dive into mongoose a little more, I would invite you to take a look at the Introduction to Mongoose for node.JS and MongoDB course here on Pluralsight. Views and Controllers We will first start off with the homepage and its controller and view files. We do not need to change the home.client.controller.JS file or the header.client.controller.JS file either. We can just use those as they were generated for us. Let's open up the angular home view HTML file now and see what we have there. Oh, yes. We've got a lot to change in here. It would take far too long and you may fall asleep on me if I typed all of this new code out that we'll need, so with the help of some video editing, I'll be pasting in HTML code here, and we'll review in the browser what we end up with. This homepage HTML code is a slightly modified version of what you'll get right out of the box with the Solid Bootstrap theme. Now for the client-side needs controller. One of the things that we notice here is that the stubbed-in needs object does not match our mongoose model, the model we fixed up in the previous video. Let's fix this view now to match our model. And here in the clear forms field portion of the code, we'll want to clear out all of the model fields once the data has been saved to MongoDB. If you recall from the introduction module, when a mostly completed demo application was presented, we had a sign-up form on the volunteer needs detail page to allow someone to send an email to the site administrator stating that they wish to volunteer for a particular need. We will need some controller code to handle that, but we'll revisit that in a moment. Let's first move on to the various views that we'll need new HTML code for. The MEAN.JS cred sub-generator stubbed in the create, edit, list, and details view pages for us. That's great, but they did not have the look and feel, nor the correct HTML that we need so let's fix those up now. We'll start with the create view. The only form field we see in this boilerplate code is one for name. In way of review, we'll need fields for title, description, organization, location, start and end date, and the number of volunteers needed. Let's pop that HTML in here now and review it. And here we have our form input fields that match our mongoose model. We'll need very similar HTML for the volunteer needs edit page, too, so let's take care of that now as well. We need to list out all of our volunteer needs and we have a view stubbed in for us there, too, so let's take a look at that now. As before, I have some prepared HTML that will get pasted in here. We can see here that we are utilizing angulars NG repeat to loop through a collection of volunteer needs that we retrieved from MongoDB through our express API service endpoint. When a user clicks on a particular volunteer need, we want to take them to a details view for that need. That will be our view-need.client.view.html page So let's replace this HTML now, too. Besides replacing this boilerplate HTML, we're also going to need to add in our sign-up form on this view, so let's get to it. Okay, there we have it. All of the views we need to create, edit, list, and display volunteer needs, as well as allowing the site users to sign up for a particular volunteer need. Let's kick off node and run our site just to see what we have now. Of course, we need to make sure also that we have a instance of MongoDB running. We already have some sample data in a MongoDB database, so let's run over to the volunteer needs list and see what we find there. Okay, looks good. Now we need to sign in to the site so that we can see the create new volunteer needs view. And there we have it. Going back to the list of volunteer needs, and now that we're signed in, we can click on a need and see the details view of that need, and the form to allow us to sign up for this particular need. In the next video, we will add in the necessary code to actually send off that email. Sending Email While we certainly could use a package such as Nodemailer to send volunteer sign-up email notifications back to the admin of our demo site and use our own email server or perhaps a Gmail account, we are instead going to use a really nice service called SendGrid, a cloud-based email service provider to send our email messages. I will not go through the details of signing up for an account here in this course, but if you would like to follow along and sign up for a free account, visit this URL. SendGrid has provided us with a NPM package over here at NPMJS.com/package/SendGrid. To install SendGrid so that we can use it on our application we need to fire up a command prompt and use NPM to install that. And here is what that would look like. NPM install sendgrid and --save. Don't forget to use the --save to ensure that this package is saved to the package.json file. The SendGrid team provides really good documentation on their main site, but recommend that you visit their github repo to view code examples for Node.JS, and that URL is found here. Let's jump back into our editor and add in an API end point to expose this new SendGrid service. Our email API controller needs to live here under the app folder, controllers subfolder, and here in a minute we will create that new controller and name it email. In way of review, do you recall the module on generating code? Why don't we try to utilize the Yo Generator here to stub this controller in for us, and see what we get. I'll open up a terminal window and type in yo meanjs:express-controller, and we'll name the controller, email. You know, while we're here in the terminal window, we're also going to need a route to this new express API controller, so we might as well take care of that as well. To spin that up, let's enter in yo meanjs:express-route, and we'll name this route, email, as well. Let's open up our new route and see what we have there. Well, it's just a basic stub, so we need to fix this up a little, and have it point to our new email controller. We'll open up that controller in a second, and when we do, we'll want to expose a create function to create and send email messages with. Here's what that will look like. All right, a new email server-side control file was stubbed in for us by the Yo Generator earlier, so let's open that up now and take a look. Well, thanks, but not exactly what we need here. While that was a nice review of using the MEAN.JS sub-generators, we do not need create, read, update, and delete functionality here. What we do need is to be able to send emails using the SendGrid service, however. Let's remove all of this code, and paste in some code that was derived off of the SendGrid documentation that we looked at a moment ago. That's more like it and should get us what we need now. Keep in mind that you too can sign up for a free SendGrid account, so don't try using this one later. I've already change the password. So that's our API endpoint controller, and we're exporting create here but what we'll use this function. The sign-up form is on our view need page, so let's open that up again and take another look at that. In the previous video, we just pasted this HTML code in and then viewed the results of that. Now it's time to dig in a little deeper We can see here that NG-submit is calling the sign-up function and passing in a need object. If you recall, that need object was attached to our angular $scope. We will need to add that to the angular controller that this view is referencing here in a moment. Next, we can see that our various input fields are bound to sign-up data. But where is the sign-up data object coming from? Let's open up the angular controller and take a look there. Sign-up data was added to $scope, up here in the find function, while you were not looking, and also so that I could get the previous demo to run. All right, down here, below find one, let's tag onto $scope, the sign-up function our view needs. $HTTP.post is what we're using here to call into our API endpoint. That fires off the SendGrid service by hitting the email route we set up earlier. You can see here that an object with properties of name, email, and message are being passed over to that service. One important step to not overlook here is that we need to add $HTTP to the list of angular dependencies so that it can inject those for us. Let's scroll up to the top here, and add in $HTTP to the dependency list. If we open the server-side email controller file back up, you can see where the values from the HTTP request are being consumed here, off of the request.body object. For example, the from email address and the message body text. Okay, we should be in pretty good shape now to make an initial test run at sending an email message through the SendGrid service from our application. For now we're just logging the results out to the console, but it would certainly be a good idea to notify the end-user of success or failure, and to also clear the sign-up form upon success. Let's fire up Node.JS by using our default grunt task runner and see what we get now. But before we run grunt, real quick, let's make sure we have the SendGrid node package installed by entering NPM install send grid --save. That may take a second or two to install. And now we're good to go with our grunt task to kick off our site. Just in way of reminder here, I still have my local instance of MongoDB running. Let's get logged in here using our demo account and the password, and select a sample volunteer need. And we'll try to sign up for this need now, filling in some dummy data into the sign-up form just to make sure everything is wired up correctly. I'll press Submit and then move back over to the command line interface to see what our console is telling us. Great, we get a response code of 200, and we can also see our email response object here, too. Let's log into the demo email account this message was sent to, and see if that was successful as well. Sure enough, there is the message to the administrator. I think we're in pretty good shape here. The main purpose of this video was not to teach about SendGrid per se, but more to show that you're free to swap out whatever pieces of the MEAN.JS framework that you do not want to use, or add in completely new libraries as your needs dictate. Tests The last thing we need to do in this module is examine the tests that were generated for us by the MEAN.JS Yo sub-generator for both the server-side express models and routes, as well as the client-side angular controller test. While we will not go into depth on testing in this course, it nevertheless is still helpful to review and understand the test that we get from MEAN.JS, and what we may have to change to get the stubbed-in test to work the way we need them to. We will start with the express model test file, here under the app folder, tests. Before we dive into this test file, let's talk a little about the testing framework in use here. MEAN.JS utilizes Mocha for server-side tests. Mocha does not provide its own assertion functionality, so should.js is being used here for that purpose. You'll notice a reference to the should.js library in your package.json file. For information on should.js, check out their website over at unitJS.com. A number of examples are provided here, and of course, you can also learn a lot by examining the test generated from the example article cred module. Back on our test here, the first section before each is where we arrange or build out any of the objects we may need during our test. In this case, we need a user object and a new need object initialized for our test. However, you may notice that this need objects structure does not match our mongoose schema, so let's fix that up now. The only two required fields defined in our model are for title and for description, so that is all we have to provide here for a successful test. Now I correctly formatted need object will be set up for each test that will execute, which brings us to the next described section here, the save test. Pretty nice description on this test, too, "It should save without problems." Okay, let's hope so. Here's where we see the should.js assertion library being put to use. An error object should not have been passed back if everything with the test's save went well. By the way, in case you were wondering if we are dumping test data into what may become the production database, the answer to that is no. You really don't want to do that. If we jump over to the config folder and open up the test.JS environment file, we can see that for testing purposes, we are connecting to a completely different MongoDB database, one named volunteer-test. Okay, back to our model test file. After the various tests are run, then we need to perform some cleanup, and that's done here in the afterEach section of the test. In this example, we're simply utilizing the remove method, found on the mongoose model, to delete the test need and user documents that were set up for us in the beforeEach section. That way we can keep our test database clean and happy. Now let's take a look at our need routes test file. This set of tests are a little more complicated, and while we will not go through the structure of these tests, we do have the same issue here that we did with the model test file. And if this test is to run and do its job properly, we need to correct the setup of the need object here. I hope you're seeing the pattern here. The MEAN.JS Yo sub-generator stubbed in a nice chunk of the testing code we want and need for our server-side controllers and routes, but it can only go so far. You'll need to go in here and customize these tests to your specifications, and that's something I will do offline here in preparation for running all of these tests in the next module. Time to move on to examining some of the client-side angular test we get from the generators. As you might expect by now, those tests can be found here under the public folder, modules, and we'll stick with looking at the tests for our new needs module, and those are found here under the test subfolder. Right now we only have the one test, and that's for the angular controller. Let's open this file up and take a quick look. Once again, the sub-generator stubbed in a lot of code for us here, but we're still going to have to go in here and fix this code up to work with our need model. If only they could invent a code generator that could read our minds. Let's take a look at a couple of examples of what needs to be worked on there, and then I will take care of the rest of those fixup issues offline. For one thing, we can see here that our sample need object is getting set up with a field that we do not have, name. What we do need are the two required fields we defined in our mongoose schema, title and description. Okay, that fixes that part of the test up for us. How about one more example? Scroll down a little here. And we see the same thing here. So we'll do the same thing to fix this up. Add in title and description. In closing here and to reiterate the main point of this video, the MEAN.JS Yo sub-generators will get you pretty far down the testing road, but you will have to fix these tests up as we've done in this example. In some cases, you may find it easier to start from scratch, but if you're new to JavaScript testing, these stubs do provide a pretty nice framework to build upon. Summary We started this module off by examining where in the MEAN.JS application structure our new CSS and HTML files are needed to be placed in order to style our application with the downloaded Bootstrap Solid theme. We then fixed up our mongoose schema and model from the schema so that we can begin creating and displaying volunteer needs. Next, we created the new controllers and views to create and list out volunteer needs, as well as a form to allow site users to sign up for a particular need, and we accomplished that by adding in the SendGrid service. We closed off this module by exploring some of the tests generated for us by the MEAN.JS Yo sub generators, both server-side express controller and route test, and client-side angular tests. In the next module, we will go through the steps of actually running our test and learn about getting our site ready for deployment by going through the build process. Testing, Deployment, and Tools Introduction Welcome to this module on testing, deployment, and additional useful tools. My name is Mark Scott. In the previous module, we built upon the base scaffolded site that was given to us by the MEAN.JS Yo Generator, and concluded the module by exploring some of the unit tests built for us by the generator. In this module, we will pick back up where we left off and run those tests, and then move on to discuss build and deployment steps. We'll wrap this module up by exploring some additional useful tools, so let's get started. Testing As things stand right now, our demo application seems to run fine. We've taken the generated scaffolded code and applied style and HTML changes to that. We fixed up the Mongoose schema, and all seems to be fine when we launch the application and run it through its paces in a browser. But is everything really okay? Have we missed some key business rules? Will we find that bug? Or will one of our customers? It's certainly not a perfect world, And I've yet to meet a developer that hasn't accidentally released a bug out into the wild, but testing our code can certainly help mitigate the risk of the customer being the one that finds that nasty, embarrassing bug. In the previous module, we explored some of the tests that MEAN.JS generated for us, and made some modifications to get those tests working for our volunteer needs module code. Now it's time to actually run those tests and see if everything is good with our application, at least according to the test we set up. Here in a minute, to kick the testing process off, we'll go to a command prompt and enter grunt test to fire off our test. With the next version of MEAN.JS, you'll have the option to also run tests using gulp. Well, I say the next version, but frankly, there's nothing stopping you from using gulp right now. One of the premises of MEAN.JS is that it's pretty un-opinionated. Feel free to start with the scaffolded code and packages selected by the core MEAN.JS contributors, and then swap in or out whatever you want. Before we dive in here and run our test, it would be helpful to understand what exactly it is that we're asking the grunt task to do. To discover that, we'll need to open up our editor and take a look at our grunt file. Here in our editor now, let's open up gruntfile.js, and scroll down until we find our test task. Here it is. The second argument here is an array of tasks that we want to run. The first thing being done here is we're setting the Node environment variable to test, and then we're running our service-side mocha test, and finally the client-side angular karma unit test. And if we scroll back up here a little, we can see where those tests' tasks are defined, as well as the environment settings. So you may be looking at the grunt configuration section here for our mocha test, as an example, and asking yourself, so how does mocha know which test to run? To answer that, first notice that we have a watchfiles object here set up. And we scroll to the top, here we can see that we're asking mocha to run all of the JS files under the test subfolder. Nice. So long as our test files live here, it will get run, at least the way it's currently configured. Okay, enough of that. Let's get going on actually running these tests. I'll open up a command prompt, and first off, make sure that we have an instance of MongoDB running. Okay. Now we'll enter grunt test. And we're off and running. Keep in mind, based on what we saw in the grunt file, we're running both server-side and client-side unit tests here. We'll talk about a way to run only server-side tests here in a moment. Looks like all of our tests were successful. One easy to miss item I noticed while fixing up the code to get these tests to run was over in our needs server controller, here in the create a need code, the generator originally stuck this in. Assuming we call the field that represents who created a particular record user rather than created by, as done here. Let's flip that code back to the way it was originally generated by the Yo sub-generator, and then re-run these tests. Back over to our command prompt, and grunt test here again. Now we can see that the test should be able to save need instance if logged in failed, and the details of that are down here. But this error message, uncaught type error, cannot read property should of undefined, is not that helpful in clearly indicating what our true problem is here. But we can see in this stack trace here that the error took place in the needs server route test file on line 79. Let's go take a quick look at that. Okay, here on line 79 we can see that we're asking for the first element of the needs array, and we're looking for created by just prior to chaining into the should assertion library to test for equality. So when we solve the error message cannot read property should of undefined, it's not that the should JS library is not available, it's just that it's unable to extend the created by object that doesn't really exist. Let's go back and fix the controller code now and rerun the test. Before we re-run our test now, why don't we go ahead and set up a grunt task that will run just the server-side test. After all, we're only working with that code right now. No real need to re-test the client-side test now. To do that, we'll re-open the grunt file, and copy the test task here, and simply remove the karma unit test from the array. We can call this something like test-app, since we'll be testing tests within the app folder only. Great, now we'll open up our command prompt back up and run this new test task. Okay, we're back to having successful tests. I truly hope you see the benefit in testing your code prior to releasing it into the wild. Speaking of which, in the next video, we'll be discussing the build process, and guess what? There's a grunt test for that too. For more detailed information on JavaScript testing, I would encourage you to explore some of the other courses here on Pluralsight devoted to that topic. A couple examples of courses you may consider to look into are Testing Clientside JavaScript and Node.js Testing Strategies. And there are a number of other courses that deal with testing in general that you may also find useful. Build and Deployment So you worked really hard on your MEAN.JS application. You've swapped out the CSS and HTML, you've added in new functionality and modules, you've added in additional MPN packages and things are now looking pretty good in the browser. Unit tests have been developed and run to ensure you're following the business rules outline for your app, and now it's time to release this application out to the public. Before we do that, there are a few additional steps that we need to take to prepare this application for public consumption in a production environment, and that's what we'll cover in this section of the course. One of the first steps we need to take is to run the grunt build task, and that's what we'll talk about here first. Keep in mind, there's nothing preventing you from using gulp to accomplish this same task. Let's open up a command prompt and get started on that. To get started, let's open the grunt file back up in the editor, and scroll down to the build task. What exactly is our build task doing for us here? The first task we see is lint. But this is actually another grunt task, defined right above this. In fact, a lot of these grunt tasks are using this. This lint task is running JS hint to lint our JavaScript files, and CS lint obviously for the CSS files. Next we see the load config task. This task sets up the grunt configuration settings to tell the build task where to place the minified JavaScript and CSS files. Next is the ng annotate task, which is used to rebuild the angular JS dependency injection annotations. And finally we have the uglify and css min task to minify both JavaScript and CSS files, placing those files in the folder specified by the load config task earlier. To kick off this build, I'll simply use the built-in terminal window here in Web Storm and enter grunt build. Okay, notice now we have a new dist folder here under the public folder. And we can see our minified CSS and JavaScript files here now. But how do you know, for example, which JavaScript files were globbed together and minified into one .min file here? To answer that, we need to revisit the grunt file, and look at the load config task registration. We can see here that we're requiring the config file, and below, we're dipping into that config object looking at JS files. The configuration file is where all of the JavaScript file names that live underneath the public folder are getting globbed together and returned. So pretty much any .js file that we place under the public folder will get squeezed and minified into a single .min file here. And if, in way of review, we open up the module file here, and say for example the articles folder, all of the config files, controllers, services, and views JavaScript files will be in one minified file now. No need for users of our site to download all of these files individually. What about our test? These files are not included by the configuration file, unless specifically asked for. So none of these will be included. Now let's shift focus to the production configuration file. This is not the connection string to the MongoDB database that we'll want to use in our production environment. We'll be using one host over at Mongo Lab. Let's open up that site and take a look. I've already logged into my Mongo Lab account here, and selected the ps-volunteer database. The connection string we need is here, so we'll grab that and paste it in over in our production configuration file, and replace the username and password information. Okay, good to go there. Everything should be ready to deploy now. Now that we have run our build task, and we have linted, minified code ready to deploy, we need to discuss some of the many cloud services offered that allow us to host our Node.js application. This is the challenging part, because there are a number of really good services to consider, and probably a few that will pop onto the scene after this course has been produced. So which one do we go with? Let's discuss a few of the services out there, and then, ultimately, it's your call. You may have a service you already love, and I would encourage you to leave comments about your experiences with that service on the course discussion board so that other viewers can consider it too. Let's start the list off by taking a look at a service most have at least heard of, Heroku. Heroku is one of the more established, mature, cloud platform as a service offerings out there. It has been around for a while now. They support several programming languages, including Node.js, or I suppose I wouldn't be talking about them, right? As noted on their homepage, you can get stared with Heroku for free, no credit card is required, you just need a valid email address. That's really helpful if you just want to try the service out, or quickly deploy a proof of concept application without a lot of expense involved up front. Next up is OpenShift, which is also a well-known cloud platform as a service offered by Red Hat. Unlike some, they offer a free plan, which lets you host up to three small applications. They call these apps gears. The free plan doesn't have any time limit, so you can use it as long as you want. And surprisingly enough, you can also add custom domains to your apps in the free plan. You'll need to follow a few simple steps to get your Node app deployed onto OpenShift, which includes installing Ruby and the RHC gem. Those instructions are detailed on their site. Next we have DigitalOcean. DigitalOcean does not have a free plan, but does offer SSD cloud hosting for as little as $5 and up, and that's not too bad. Once you create a new account, you'll need to create a droplet to host your app. You'll have a droplet of water in the DigitalOcean. Sorry, couldn't resist that one. They offer a number of pre-configured one-click applications, including one for Node and MongoDB. Once you are ready, you can set up Git and push your app directly from your local machine to DigitalOcean. Microsoft Azure is a very powerful platform as a service and infrastructure as a service offering. It has greatly improved over the past couple of years, and Microsoft continues to put a lot of time, money, and effort into Azure. You may have thought that you could only host asp.net web applications on Azure, but that wouldn't be the case. Azure supports a variety of languages and platforms, including Node.js. Microsoft even provides us with a Node.js developer center for Azure, and has hired Node developers to further this effort along. Microsoft Azure is a pretty broad topic in and of itself. In fact, there are a number of Pluralsight courses devoted to Azure. We need to select a service and get our demo application deployed. We discussed a number of good services, so which one should we go with? Well, my personal favorite is Microsoft Azure. But in the spirit of exploring new paths here, let's deploy our site out to Heroku. Hold on, if your favorite service wasn't selected, don't despair. We'll move through this section of the course pretty quick. The main point here is to go through the deployment steps, not to learn about a particular cloud service. I'm running a Windows box here, and I've already gone to the toolbelt.heroku.com site and downloaded the toolbelt appropriate for my operating system. Part of that package is Git, which you'll need, and hopefully already have installed. If so, when installing the toolbelt, you can skip that part of the installation. One of the first things we need to do here is get our code into a local Git repository. To initialize Git here for this project, I'll enter git init. Now we need to add all of our files to the repo and commit those, and next we need to set up Heroku as a remote. To accomplish this, we'll use the Heroku toolbelt. The Heroku create command creates a new application on your Heroku account, and sets up our Git remote. Let's validate that it was set up correctly by typing in git remote -v. Okay, looks good, we're ready to push our code now. To do that, we'll enter git push heroku master. Our files are getting compressed and shipped off to Heroku now. Once they've arrived, Heroku begins installing the necessary MPM and power packages. This may take a few minutes, so I'll pause the video and come back when it's done. Okay, we're done here, and everything found its way up to Heroku just fine. One more thing we need to do here before we test run our application is set the Node environment variable to production. To do that, we'll enter heroku config set NODE_ENV=production. After Heroku restarts, we can open up our demo application and test it out. To do that, we'll enter heroku open. And there's our site, deployed out to the cloud. Let's see if we can log in here. I'll enter admin and the password. Okay. We'll go to the volunteer needs list here. We have no volunteer needs in this new Mongo Lab database, but we're in good shape to start entering that data in. I believe our deployment was a success. See, I told you it wouldn't be that bad. Additional Helpful Tools Tools are a wonderful thing. The right tool can save you many hours and a lot of frustration. We could spend a lot of time talking about hundreds, no, probably like thousands of useful MPM packages out there, but we'll not do that. Instead let's narrow this down to code editors, deployment tools, and database tools. Please keep in mind, I do not work for any of the companies that offer either free or paid versions of the products that will be mentioned here in this section. The only goal here is to expose you to some tools that you too may find useful, and nothing more. As far as code editors go, Web Storm is a pretty great tool, and that's been used throughout this course. However, there are a number of really good editors available, and new ones coming on the market. Let's get started with a quick run through of some of the alternative code editors now. First up is a newbie to the field, Visual Studio Code. In fact, it's still in preview. On the home page, code.visualstudio.com, you'll find a quick introduction video. Take a look at it, you'll probably like what you see there. Visual Studio Code is a fast-loading, easy to use, minimalistic yet powerful editor. Visual Studio Code is available for free on Linux, Mac OSX, and Windows. Next up we find the Brackets editor, supported by Adobe. It can be found at brackets.io. It is a lightweight, quick-loading editor that offers a number of extensions such as Git source control integration, code beautification, code linting, and many more. Brackets is also a free, cross-platform editor that is available on Mac OSX, Windows, and Linux. Chances are pretty good that you've already heard about this one. In fact, if you ask me, the previous two editors we looked at seemed to have taken some lessons from Sublime Text. Version two is still the official version, but version three has been available for a long time now in beta, and seems pretty stable to me. Sublime Text, like Brackets and Visual Studio Code, is available on Windows, OSX, and Linux. However, while you still can use it for an extended period of time for free, it's not really free. The price for a Sublime Text license key has increased from its original price of $59 to $70. At this point, you may want to first consider either Visual Studio Code or Brackets. Now let's shift gears and talk about deployment tools. The first one up here is Flightplan, which is a very interesting and useful Node.js library that you may want to research further on your own. It is used for automating and streamlining application deployments and even system administration tasks. You can find more information Flightplan on Git Hub at github.com/pstadler/flightplan. As you will see there, an MPM package is also available for it, so take a look. If you're looking for something a little more polished and full-featured, you may want to look into CodeShip. With the limited research I've done thus far on CodeShip, I'm very impressed. If you're looking for a good continuous delivery tool, you should at least take a look at CodeShip. It's not free, but if you need a robust, customizable continuous delivery tool, it may be worth the monthly subscription fee to you. They have really good documentation and tutorials on their site, and for me, a lot of times, that's a deal breaker or maker. And the last group of tools in the list are database tools. And since we're talking about the MEAN stack, that would of course be for MongoDB. At the 3T Software Labs website, which is 3t.io, you'll find a suite of rather nice MongoDB tools. Those are shown here on their products page. The first one in the list is MongoChef. If you want a graphical user interface to view and interact with your MongoDB data, then look no further. If you're currently using RoboMongo, which is also a great tool by the way, you owe it to yourself to at least download this tool and give it a try. If you're familiar with, and in particular if you have used Red Gate tools for Sequel Server, specifically their data comparison and syncing tool, the 3T Data Compare and Sync for MongoDB is that same type of tool, and in my opinion, a must have. This tool makes it painlessly easy to compare different MongoDB databases. And the third tool in their suite is the 3T Schema Explorer. Any time you want to deep dive into a complex MongoDB document schema, this is the tool you'll probably want to reach for. All three tools have free trials, and MongoChef is free for personal, non-commercial use. The Schema Explorer and Data Compare Sync tools require you to purchase them after the trial period is over. Summary In this summary, we could go back over the various topics that were discussed in this module of the course, but if you will allow me to, please let me take this time to re-empahsize the importance of testing your code, especially prior to releasing it out into the wild. Unless you're not concerned about this happening to one of your customers while they're using your site. The MEAN.JS Yo sub-generator stuck in some pretty nice, useful tests for us right out of the box. But as we've seen here, you will need to adjust them to fit your specific needs. I hope you've enjoyed this video on testing, deployment, and tools. If you have a favorite cloud platform as a service provider, or a really awesome tool you can't live without, please feel free to share that information on the comments section of this course. Wrap Up Wrap Up Welcome to the wrap up module. My name is Mark Scott. We started this course off by briefly discussing what the MEAN stack is and how it came to be. We then explored the origins of MEAN.JS and talked about why you may wish to use a Boilerplate framework rather than starting from scratch. A general comparison of some of the other MEAN stacks that are available was done and we concluded that MEAN.JS was the un-opinionated choice. In the module on getting set up, we covered the course prerequisites and installed the various libraries needed to scaffold out the demo full stack Boilerplate application using the MEAN.JS yo generator. We then took a tour of the scaffolded code in order to gain a better understanding of the Boilerplate application's structure and discussed how things are laid out and where to find key parts of your application. We moved on from there to cover application configuration issues. Things such as the connection string to MongoDB for example. The last part of the tour the scaffold site module was spent taking a quick look at the 0.4.0 version of MEAN.JS. We did some comparisons between the current version, 0.3.3, and 0.4.0. In the module on cogeneration, we learned about the Yeoman project and, in particular, the yo web application scaffolding tool that was used in the getting set up module. A number of MEAN.JS sub-generators were discussed and demonstrated as well. Once things were pretty well laid out, we moved onto the module on taking our generated code from scaffold to application. This is where we replaced the Bootstrap theme provided to us by MEAN.JS with one named Solid, which we downloaded for free. We then built out a new Mongoose scheme and model based on the business needs for our volunteer needs demo application. Once we had our volunteer needs model in good shape, we moved on to developing the server and client site controllers and the angular views. That module was concluded by exploring the various tests that the MEAN.JS yo cred sub-generator built for us. We made some adjustments to those tests as needed. Once we looked over the generated test in the module on testing deployment and tools, we ran the unit test we adjusted to match our business needs using the grunt test task. The ever-so-important build and deployment steps were also discussed and demonstrated. We concluded the module by exploring some useful tools. I hope that you have enjoyed this introduction to MEAN.JS course. Course author Mark Scott Mark Scott is an experienced software developer with more than fifteen years experience in IT. He is currently the Manager of Software Development for a small group of talented web developers. Course info LevelIntermediate Rating (192) My rating Duration2h 6m Released5 Jun 2015 Share course