The panelists talk about build processes in Angular. Specifically, gulp.js and Grunt.

 

I can tell we're going to have a strange show today. We're talking about potty breaks and…

Honestly, I think we should ban Joe from the show. He should have a suspension of one week for talking like that.

I know. I'm totally offended.

Request denied.

Hey everybody and welcome to Episode 6 of Adventures in Angular podcast. This week on our panel, we have Aaron Frost.

Hello.

We have Joe Eames.

Hey there.

John Papa.

Hey everybody.

I'm Charles Max Wood from DevChat.tv. And this week, we are going to be talking about build pipelines or build processes with Angular. I'm kind of curious what systems do you use to build your assets in your Angular apps?

I've never dove into a Gulp system, but I heard they are great. I use Grunt. I'm not saying everyone should, that’s the one I use and that’s the one I'm most familiar with. I’ve got it pretty streamlined and I really enjoy using a Grunt build system for Angular apps.

I used Grunt a lot in the past. Actually, I still use it quite a bit these days and I like it, but some of the issues I've had with Grunt, Gulp is really helping me out with. And I've kind of switched most of my personal stuff over to Gulp. And honestly, if I do stuff in Gulp and Grunt, I feel like when I do it in Gulp, I'm more efficient.

So Joe, was that you that grunted when someone said ‘Grunt’?

No, it was me.

Chuck, ok that’s your job in the show.

And Joe, you have to gulp anytime someone says ‘Gulp.’

Oh, that can get obnoxious. [Chuckles] [overlapping talks]

…turn off the airways like right away.

So I have a confession: I use the Rails asset pipeline most of the time, because that’s most of the app that I'm building these days.

That does sound like kind of a confession.

Probably not a shock to most people.

Hi, my name is John Papa, and I'm a Gulp user.

Hi, John.

There's no sound associated with the Rails asset pipeline.

[Screams] No, just kidding.

Maybe Crazy Train. A little Ozzy Osbourne going on for Rails.

And then there's a third option, right? Well, fourth I guess, if we're talking about our server-side language asset pipeline -- Maven.

Nooo!

I'm just kidding. [Laughter]

I was going to say ‘Broccoli’.

There’s also Brunch too.

Is there, really?

Yeah. There's Brunch, Broccoli, Gulp and Grunt.

They are all JavaScript based?

Yeah, there's a whole lot we haven’t looked at, and I think we are all kind of just saying, “Nah, I wouldn’t go that way,” but there is a lot of server side stuff out there or even client side tooling that will help you for little things; like Visual Studio has stuff called Web Essentials, which will help you minify by right clicking on the files. And then there's also server side assets like ASP.NET which will help you create bundles and minification and all that. But these days, honestly, I kind of forget all that for a tool that’s really built around doing all of it, which to me, the choices are Grunt or Gulp. I

don’t look in the others.

I think that’s really interesting because a lot of .NET developers obviously are going to look to their IDE and what's built into that. And not having had experience in ASP.NET for several years now,

I'm not necessarily sure how competitive Gulp and Grunt are with what's available in IDE. And so, Chuck, you have same things goes for the Rails asset pipeline, right? Of course you said you haven’t actually done much with Grunt and Gulp, so until you do, you may not have the ability to do a comparison here, but I'm interesting to hear from you, John, what you think about why you choose Gulp over using what's built in to Visual Studio.

I think that’s the key; it's not really built in ASP.NET so much as it is In Visual Studio or some of the tools. When I first started doing pipeline stuff, building out the task automation, I was using Visual Studio to do it for my applications; and they were all .NET. And I was happy with it, but it wasn’t great, and there were a lot of missing pieces. And then I learned about Grunt a couple of years ago, and started using it and realize, “Right tool for the right job.” Grunt really just makes that step so much smoother. And then Gulp came out a year after Grunt and does it well.

whether I'm building OS X, Linux, Windows, whatever, ASP.NET, Java, doesn’t really matter what kind of experience that team has; going the down the Grunt and Gulp pipeline, it just makes it for, “Hey, everybody here can use this. We don’t have to worry about what IDE it is.” And I know the Visual Studio team is (I think it's that team), they are working on integrating Grunt into the tool. And I think there's a blog post about it, if I can find it.

I have to say that that’s kind of the appeal that they have for me, coming from a Rails background. I usually use the Rails asset pipeline because they start off with something simple and I don’t need anything specialized. But yeah, I mean that’s the draw, right? Is that I can plug these tools into any project no matter what backend or system I'm on, and make it work. And so I've really been tempted to switch over; it's just a matter of figuring out how to do it in mostly Rails applications and doing the work.

Yeah, so there's two plugins that have made kind of Gulp or Grunt, like you can pick either one you want, really. It's Gulp-Grunt and Grunt-Gulp. Grunt-Gulp says you can run a Gulp task inside Grunt, and Gulp-Grunt says you can run Grunt tasks inside Gulp. So I mean, if there was something you like from one that you didn’t have in the other, not anymore because you could just run it using those plugins. So I think those two are kind of the main build tools. Because on top of build tasks, they also have development tasks that you can have running, like a live reload or your CSS pre-processing, among other things. They both do those build tasks, as well as the development tasks really well.

I think maybe we should step back and say, to somebody who is not familiar with these things understand, “Ok, I'm learning Angular. I'm going down this road. Why would I even need these things in the first place? What do they do for me that I can’t just do on my own?”

Maybe we should walk you through a build, so that they can kind of understand. You know what I'm saying?

Yeah, great idea.

I think a lot of guys are like, delivering the package straight out of their IDEs sometimes, and not understanding the advantages of, “Why do I care if there is 40 JavaScript files versus one? Or do I really need to minify my HTML?” Things like that. They are kind of wondering why even do it because they’ve never done it. Maybe we walk you through a build real quick.

I think this is a good idea because we talk about minification a lot. That’s only like one piece of the build process though. So yeah, Aaron, why don’t you go ahead and start walkthrough like what you do for your build process and we can share what we do on ours.

It kind of depends on your project. Everyone’s project is different. Some of the things are going to be universal, right? So one of the first things you need to do in our build is process your CSS, right? Actually, that’s not even true. The first thing I always do in my builds is like clean out the destination where I'm going to put all these build files, just so that I know I don’t have any stale assets in there. Maybe if you don’t clean it out, maybe you'll end up with an image that you are not using anymore, and it just stays in there, so you are delivering still assets.

So you are talking about you create a folder where all the stuff that you are going to deploy kind of ends up living after your build process?

Exactly. I made a folder called build, let’s just say that, and just in case the build folder is still there from last build; I just clean it out just to make sure. It's just kind of like a failsafe, right?

As you're telling what you do in Grunt, I'll kind of tell you the similarities on what I do in Gulp. And it's the same process for Gulp so far; you just create a build folder and stick everything in.

Yeah. So then, I'll process my CSS,I I'll process it from all the source as CSS files into the mainapp.css, and I'll put that in to the build file… into the build directory anyway. I'm assuming Gulp is the same thing?

Yeah, you basically put it on its own folder and directory. I think the biggest difference between the two is folders go is in Grunt, you general end up having, at least I do, like a temp folder, so like in process files if you are processing.

Yeah.

And in Gulp, you don’t do that because Gulp does a lot of stuff in memory.

Yeah. So I was about to actually talk about that. Like the very next thing I'm going to do is going to have a temp directory inside that build directory that… and I'm going to delete the temp directory eventually, but…

Hey, Aaron.

AARON: Yeah?

Why don’t you explain SCSS just in case anybody isn’t familiar with that?

Oh yeah, so if anyone is not familiar with CSS preprocessing, there's a bunch of different languages like Stylus and LESS and SASS and… help me out guys, anyone else have one that they like?

Those are the big three I've used.

Yeah, big three.

It allows you to write CSS kind of heirarchly; so if you have one main selector for a thing, and then you are going to select something inside of that, you nest your CSS selectors inside of the file, and then you build that file and turns it into proper CSS. But it's easier to maintain, because you don’t have to retype the selector names a hundred times because you are nesting and you only have to type them once. If you are still writing CSS, you need to not. That’s basically the answer.

Plus variables and math, and usually nicer syntax.

Oh yeah. And they have functions. I mean, you can do a lot of stuff.

The big thing is once you’ve got all that preprocessing stuff, you don’t wanna output that; you want to run it through that preprocessor to generate your CSS. Somebody’s got to do that.

Yeah, that’s kind of first step I do is I build my CSS. The next thing I'm going to do is I'm going to take all of my JavaScript files, (and I'm kind of shooting this off the top of my head. I haven’t pulled up one of my projects. I'm not walking through an Agile project, but this are just things that you need to do.) And I'm going to take all of my Angular files, and I'm going to run them through this plugin called ng-annotate. And for anyone not familiar with ng-annotate… well, Papa, why don’t you explain ng-annotate.

Ng-annotate is rocking because we all hear about dependency injection in Angular, and how if you minify the code, you got to make sure that these variables don’t get mangled. So with ng-annotate is you don’t have to worry about it. It allows you to basically annotate with a comment, or ng-inject prefixed with ‘@’ (SHIFT+2), and put that above any function that you are using, that has dependency injection. And then when you run it through ng-annotate, it basically sticks the dependency injection minification safe code into your code for you, so you don’t have to worry about missing it. And it's evolving really well recently. Even if you don’t put those annotations there, it finds probably 90% of the place that it needs to on its own.

I just wanna interject here with the Rails pipeline, I ran into this where it was changing the variable names, which is one of the things that a lot of minifiers do, and that was screwing up the dependency injection. I was getting errors and I have to actually turn that off. And you can just do that with uglifier, which is the default in Rails, but it takes a while to figure it out.

A lot of times in Angular, you get this error that says like, “injector module cannot find blah, blah, blah,” and you don’t know what the heck it means.

“I can’t find module A.”

Yeah, or T. It was T for me.

Yeah.

[inaudible] “…your 300 files, you have a problem.” Thank you for telling me.

Yeah, essentially what happens is just because it's trying to make it the smallest possible JavaScript file is in your function declaration for like an Angular controller, you say, “I want you to inject $scope and $http.” Like you wouldn’t inject http into [unintelligible] so I'll just use that as an example. And when uglifier runs over that function, it says, “Well, I turned all variable names into shorter versions of themselves.” So it turns ‘$scope’ into ‘a’, and ‘$http’ into ‘b’, and then it will go through it anywhere in your code that you’ve referenced $scope, it will replace it with ‘a’ and when you say ‘$http’, it replaces it with ‘b’, just so you can have the smallest possible file.

So what ng-annotate does is (and you could do this manually; you don’t need ng-annotate. Ngannotate is just a luxury that I like and that John, likes because we don’t like to do this thing I'm about to explain), you could wrap your controller function or your factory function or your service function, you can wrap it in an array, and you can put strings as the first indexes in the array, and then the very last index is the function. What the strings represent the parameters you want passed into that function. So you write a string $scope, and then that means no matter what uglify does to that first variable, Angular knows it needs to inject $scope, right? And then the second thing is $http will inject $http and uglification is not going to clobber the $dollar scope and the $http. So it just protects your code against being clobbered.

The details of it is awesome, but long story short is if you wanna write your code and have it work whether you minify it or not, ng-annotate is your friend.

Yeah.

Is it worth mentioning the difference between ng-annotate and ng

JOHN: yeah, it is. And in fact if you go to ng Bryan’s updated it, say don’t use ngmin?

Yeah, it is. And in fact, if you go to ngmin, Brian as updated it and it says, “Don’t use ngmin.” They do the same thing; we updated our build to use ng-annotate instead of ng min. Our build went from 4 minutes to 1.5 minutes. So ng-annotate is much faster at getting that stuff inline in build-safing your Angular files.

Yeah, it's really the way it goes these days. And it handles more situations than ng min does, too.

Yeah, totally. You just ng-annotate anymore.

So while we are talking about Angular-based tasks, I think it's worth mentioning that we're talking about ng-annotate, but that’s a plugin itself. That’s a package in, which you can also get a Grunt version of it, and Gulp version of it. Meaning, if you wanna run ng-annotate from Grunt or Gulp, there's a Gulp ng-annotate, and a Grunt ng-annotate that you can run. And I definitely recommend those.

Yeah, and that’s what you use to run ng-annotate inside of a build is…

You don’t have to, but I mean, that’s the right way to do it, right?

Yeah. So the difference here, at this stage, like we are going to run to our first difference between Gulp and Grunt, and that is that once Grunt has finished ng-annotating your code, it needs to write that to the hard drive somewhere. And so it's going to take all of your files, and it needs to put them somewhere now that they have all been through ng-annotate. So I make a build directory or a temp folder inside my build folder, where it can copy all those files into, because I don’t wanna override the existing versions of themselves with this ng-annotated version. And Gulp doesn’t have to do that, John. What does Gulp do?

So what Gulp does is different. There's two [unintelligible] in Gulp and Grunt. And one is exactly what Aaron’s pointed out here. Grunt writes the files in the hard drive, and Gulp use a screen based system which basically says, “Ok, you have gone from Step 1, 2 to 3. Instead of writing in the hard drive between each, I'm going to screen the results form step 1 into step 2,” which is kind of nice in a way because you no longer have to be writing [unintelligible] in the hard drive to get your stuff.

The other big difference is Grunt allows you to run basically using a convention using configuration. So it's all configuration-based, and in Gulp, it's all convention-based. So it's a slightly different approach in how it goes. So you are writing code in Gulp, and you are writing configuration in Grunt. And neither one is better than the other; it's just, how do you wanna write your code.

I think for some people, Gulp sounds scary. Like, “Well, I like the configuration.” But when John is saying convention, it's super easy; you just like Gulp.blog.pipe.pipe.pipe. And they are super simple idioms, things to understand. They are not hard. So you shouldn’t pick Gulp or Grunt over Gulp because there's no code involved. It's all configuration.

You can spend like an hour with either or one of them, and you'll learn either one of them. They are both simple and easy.

Exactly. What I was pointing out was that Gulp doesn’t have to write to the hard drive in between these steps. And in Grunt, when you ng-annotate or when you minify in between steps, you need to put somewhere. Anything else you wanna talk about ng-annotate, John?

I think that covers most of it. I mean, there's some open issues on it, which is awesome. Like I found some stuff recently that it wasn’t doing, and I opened some issues on their GitHub site. And the guy closed them out for like three days, which was super awesome. Because that’s the cool part is once ng-annotate got fixed, the Gulp and the Grunt plugin forums immediately got that fixed. So they are not re-implementing it; they are actually pointing to the actual ng-annotate task, which is really helpful for guys like us.

Just to clarify, Grunt and Gulp are both task utilities that you use in your app. It's just that you guys have co-opted them to have tests that run your builds, right?

Yeah. For the build process, I have massive build process that do with my personal stuff, and that’s early on. Another big Angular task that I love doing is the template caching. So I have a Gulper run process that goes through my pipeline and say, “Take all of my little HTML partials.” Let’s say I've got 50 different views using [unintelligible] little HTML files, instead of actually making extra call to get them each time I hit the page, what Angular can do for you is say, “Hey, when you get that URL, let me look in my template cache. I've already got a cache which is in memory in Angular app. I don’t have to make the extra jar call. I can just show it.” So something I like to do is I like to take all of my HTML files and run them through with Gulp or Grunt, template cache task which basically runs through the HTML files, creates an Angular module for me, that actually loads in all the HTML into template cache, and then I actually include that JavaScript file in my final build after minifying it and bundling -- which really speeds up the app.

That’s cool.

Yeah, like everything is already cached. It doesn’t have to make trips and for a lot of views, that’s super important. I mean, there's some views like in apps every time where there's like an admin section, where like 2-3 users have it. So you can get creative and not include some templates and include other template, you know what I'm saying? But it all depends on if 95% of the people are going to see 100% of your templates, then yeah, you need to do ng-template. And that’s actually the name of that plugin is ng-templates.

I believe so. I'll look for the name of it real quick. And Gulp, I know the plugins like gulptemplatecache.

Oh, is that what it is? I need to pull up my GitHub and check it out. I used the one called-ng templates, and that’s exactly what it did, was it walked you through that process that you’ve explained of getting your templates and turning them into JavaScript so they can be minified with the rest of the app.

Wait a second. In the open source world, there's more than one product to do something?

I don’t understand.

That’s a big key because when you’re looking at some of those stuff, you got to make sure that you are getting the one that is actually still being used, because there's like 3-4 of them for like everything these days.

I agree.

How do people afford all of these open source licenses is what I wanna know.

Yeah, really.

So at this point, you’ve got all your ng-annotated files, you’ve got your template cache sitting in the build directory. Concatenation and minification are kind of your next two steps. Like, getting all your JavaScripts into one file and then getting them minified, so that they are compressed and gzipped, and everything. So what's the step for that in Gulp, John?

It's the same plugins really. I mean, there's uglify and there's concat. There's a Gulp uglify and a Gulp concat, and they’ve both used the uglifying and concat processes. I think Grunt, it's the same exact one. So it's just the difference I found is in Grunt, I always do bundle and then minify, because I wanna bundle one file and minify one file just, like less of them writing to the hard drive. In Gulp, it doesn't really matter; I can minify first, then bundle… sorry, concat then I get my bundle. Or I can do it in reversed order because I'm not hitting the hard drive in between.

That’s true. In Grunt there's a huge difference in the order. You definitely wanna concat first before you uglify, because you don’t wanna do all those read and writes twice, right?

That’s expensive. That’s one of the things with Grunt I find is that my build process is slower with Grunt, because it reads and writes in the hard drive, so you don’t wanna add to that.

Can you explain really quickly why you wanna concatenate? I think some people just don’t get…

Well, in these matters on the less quality of the device, this matters more and more, but what you don’t want is when someone loads your page, you don’t want them to have to make 150 HTTP requests to get all your JavaScript files. And on a PC with a plugged in network cable, that’s not as heavy, but on mobile device, that’s horrible. Just think about the amount of latency that you are committing to is just ugly. So the ideal build is that you end up with all your JavaScript in one app.js file. And that’s the only JavaScript embedded on your index.html.

The key there is you're trying to load… this is your app code, so think of [unintelligible] just for a second. They wanna get everything they need to run the app in one shot. Two things slowed it down: one is how many trips do they have to make; and the second is the size. So that's exactly what Aaron is getting at is the concat and the uglify steps, they take care of the size and they care of the trips.

Yeah. Concatting it gets it down to one trip, but now you’ve got this file that's bigger than it needs to be; it's got extra spaces, it's got a bunch of comments inline that you don’t need to give to your users, and your variable names are all really long. And if you shorten them or had some process that automatically shorten them; the file can be much smaller. And that’s really all that’s happening; it's taking out your comments, it's taking all the white spaces out, which is why all your code ends up on like 2-3 lines because it's just putting it in. And you end up as compact as you can JavaScript file, which is obfuscated, so someone can’t read it anymore. And usually, these process will gzip it as well, so that it's ready for production, which is kind of nice.

Yeah, those are the big two Angular ones is the template caching and the minification [unintelligible] the annotations. Those are the two big ones that every Angular app should definitely consider.

Yeah, I totally agree with that.

Then you got concat and you got uglify. You can also minify your images; you can minify your CSS; you can minify HTML.

I minify my HTML as well. It’s nice to have all the comments and stuff taken out. And those HTML minifiers are nice, because they'll leave in IE comments of like you have ‘if IE9 do a thing’ comments, it leaves those where it takes everything else out that you don’t need anymore. So yeah, those are nice.

Yeah, it works pretty good. One thing I've heard about Gulp and Grunt in the past, (which is really not true, but there's ways around it) is some people like Gulp because it can run things concurrently. And that’s the way Gulp works, and it can’t invite you if you don’t understand that. In Grunt, if you run a task, every task runs after another task and then after another task. It's all sequential. In Gulp, by default, If you say this task depends upon JSHint and it depends upon minification and bundling and all those other stuff, if you don’t do it right, it will actually try to do all these things simultaneously, which may not be what you want. And then once its good because it will run things concurrently by default, and the other is you have to be careful to make sure that you don’t want to minify until you’ve already done ng-annotate, for example. That will be bad, so you got to be careful in that with Gulp.

Yeah that’s a good point. If you try and do ng-annotate after you’ve uglified, you’re screwed.

Yeah, it's not going to help you whatsoever.

The same thing with template cache; if you try to do template cache after you’ve minified your JavaScript, it's kind of stupid, because you'd have a bunch of minified JavaScript, but then that template cache wouldn’t be minified. So there's definitely some order. I think the way that we talked it through on the show is how you would implement on your own project if you are listening. But I've never dealt with those things in Gulp. That’s interesting that you could do things in parallel and serial as well. I didn’t know that.

Yeah. And to be fair in Grunt, you can actually do some of them concurrently too. There’s actually Grunt current task which will actually run, “Okay, go off into my image minification, my CSS minification and my JavaScript minification all at the same time because they are different things.” And that will help speed up your Grunt task.

So, are there good examples out there of the build process that people are using?

Yeah, I've got an example up on one of my sites that I'm going to put a link in for the show; it’s a Gulp process that people can take a look at. Do you have one for Grunt that people can take a look at, Aaron?

It's a lot to take in at one glance, but it's really solid. And some of the stuff you can look at is like if you go to Yeoman, you have scaffold out a new Angular project, it will set you up with a really solid Grunt file that does all these build things you needed. It will give you several tasks; like it will give you like a live reload kind of built into it, and it will give you a full build process where it will do all these steps that we've talked about, and you don’t have to go through all of that. So there's definitely some stuff to be taken away from one of those Yeoman, Angular scaffolding projects. I would recommend starting there, if you are looking at it for Grunt build.

That's a great idea.

And it's a lot to take in. You are going to be like, “I can’t do this.” So it's not a tutorial, but it is a functioning build, (which is what Chuck asked for) of what you would wanna do on your own site.

That's one of the things I like about Gulp, actually is when you start looking at Grunt, like I look at those massive Grunt files, when you dissect them, they are not bad. They really aren’t. But I find reading the is difficult. And my Grunt files [unintelligible] my Gulp files, I find reading them is easier because I can see, “I do this, then that, then that.” Whereas my Grunt file, I find it difficult to bounce around between the configuration to make sure I’ve got things right.

So one thing that Mike did, he built this Grunt plugin that allowed you to require different sections of your main init config JSON, so that all your pieces were in the same file. And I thought that was super useful because that way, the init config wasn’t so gigantic, and they are often their own files, so that you can kind of read and see where they are being required from. You know what I'm saying?

Yeah.

And the reason I thought that that was awesome was because then he [unintelligible] it, so let’s say I had one called templatecache.js and I can require the template cache section in, right? Well, if I wanted to allow users to point to different places on their hard drive, he build him this way where you could say, instead of templatecache.js, I can say, templatecache-user.js and it would require those both and kind of extend my preferences on top of the other one, and then it would require them to the main Grunt file. And then that way, if you had any pieces where my system was different than your system, (maybe you're on Mac and I'm on Windows and we need to point to different sections,) and it made it so that can be normalized across systems. And you would never commit your [unintelligible] files, but when you checked out the project, you’d get them so you can see how to config them if you needed to -- if that makes any sense. So there are some cool stuff to make that less ugly, but that is a complaint a lot of people have with Grunt that I've heard a lot.

Something that I think is worth pointing out too is while we are talking about building everything using Grunt and Gulp, (and both of them are great options. You just pick one and be consistent), when you're done, there's other things tests can do for you too. Like I commonly use Gulp or Grunt to run watches, so I can rerun my Karma and my Mocha unit tests or my Jasmine unit tests. So running for watches is awesome. You can run nodemon when you start up your code. You can actually use a Gulp or Grunt task and use nodemon, which actually will restart your node server whenever it sees file changes. So there's a bunch of other little things you could do; like JSHint has a unit testing, serving up your code. Pretty much anything you can think of live reload, all that can be stuff can be [unintelligible] too.

And they are all super easy to config.

Yeah, bottom line is if you are not using it, you are working way too hard.

Yeah, you are doing way too much. You know, at Google I/O two weeks ago, Paul Irish got up and talked about the need for better build tools, and talked about people kind of going out into the world with like sharpened sticks, trying to make websites and he talked about the need for really power tools. And it was the talk where they introduced Yeoman, but it was on the back of Grunt. And says, “Tools like Grunt and now, we have Gulp as well, those are really the power tools you need to deliver a powerful site because these tasks, there are so many of them, and if you try to do them all manually, you are going to end up quitting.” You are going to be like, “This is all too much.” You are going to forget to do one, and you are just never going to them; you are going to stop minifying your images, because you just forgot to and it's getting lost, and some designer checks in a really, really big image that’s not minified, and now you're in trouble because the page load looks wonky. And so you have to automate every step of your process. You don’t ever want to depend on a human actually a part of it. And Gulp and Grunt make those things easy. So I agree with what John said: “If you are doing it manually, you are working way too hard.”

All right. Well, we are about at the end of the time. Should we go ahead and get to the picks?

Yeah.

All right, John do you wanna start us with the picks today?

Sure. Since we are on theme for Grunt and Gulp… grunt and gulp, I can’t make those noises, sorry guys. [Laughter]

My picks are going to be twofold: one is a tool in web storm that helps you do Grunt (and they are promising Gulp soon just like in Visual Studio. If you are using Visual Studio or web storm, you definitely wanna check out the integration they have with Grunt and Gulp. That’s pretty darn good. You can actually debug it too – which is really nice. When you are running some of these tasks, it will set breakpoints in your Grunt or Gulp code and say, it wasn’t creating what I thought it was going to as it goes. And the second pick is there's actually a Chrome Dev tools plugin for Grunt, which is pretty cool and you can actually run your tasks right inside the browser. Check it out there.

That sounds really cool. Joe, what are your picks?

For my first pick, I'm going to pick Brendan Eich. We just had him on JavaScript Jabber yesterday and…

Wooh!

Yeah, exactly.

It was so cool.

That was way cool. Total stud. I’ve got major hero worship when it comes to him, so I definitely wanna pick Brendan Eich, because they guy is just absolutely amazing. It was fun having him on, and the stories that he told. It was just amazing. So I'm going to pick Brendan Eich for my very first pick.

Dice Duels. It's a really long name for a really awesome game. I may have picked this in the past, but if so, it was a long time ago. You play on two teams, teams are evenly matched, as far as size, you have to play it with either 4, 6 or 8 people. But each team has a whole bunch of dice and each team controls a spaceship, and you are trying to blow the other spaceship up, and each of you have a different job kind of like you are in Star Trek, and you are playing a different position on the bridge. And you’re rolling dice and you pass them to the next person, so that he can do his job and them passing them back. And it's really crazy. And you get everything, so you’d have to go and shoot. And then by that time, the other ship has moved and your torpedo goes off into nowhere and its super fun. Have a great time playing it. So I want to pick Space Cadets: Dice Duels as my second pick.

And my third and final pick will be very self-serving, because we talked about Grunt and builds and we talked about CSS and SASS. My course on front end web development kind of covers all these topics in a fair amount of depth, and gives a comparison between all the different CSS preprocessor, and talks about using Grunt. I wanna pick that course mostly because it was the course that I wrote for myself when I went from server-side development into front end development. This is all the stuff I wish I had known, and so I wrote this course as sort of a course to myself.

That’s on PluralSight, right?

Yeah, it's on PluralSight.

All right, Lukas what are your picks?

Since we are talking about Grunt and Gulp, I have to give a shoutout to my boys Aaron and Eric, they actually wrote Gulp. And the funny story is I've actually known Aaron and Eric for years, and that was like, “Oh, we are building this thing. It's going to be huge.” And they we're telling me about Gulp quite some time ago, and then all of a sudden, it is actually huge. And so if you go to wearefractal.com, you just check out the repos; they got really great content. I'm always learning something new from them. And they are Phoenix-based, so fortunately, we get to do a lot of events together.

And then my second pick is I just got my copy of Lock In by John Scalzi. He's one of my favorite authors. And I actually have the audiobook, which is narrated by Wil Wheaton, who just does an excellent job. They are kind of my favorite duo. So if you haven’t read any John Scalzi, run out, and get all of his books. They are hilarious, and entertaining, and awesome.

Very nice. Aaron, what are your picks?

I’ve got quite a few picks. And one’s a pick off of Joe. So I also did a course on these kind of stuff over at egghead.io. It's almost done, and you can check out a lot of the steps that John and I kind of talked about with Grunt and Gulp. I did it in Grunt, and I'm sure that it's probably the same easy to do in Gulp, but they are necessary steps.

That course is like a deep dive into Grunt?

Yeah, it's called Grunt Builds for Angular Apps.

Cool.

I'm going to pick a book. I’ve picked books in the past that I've absolutely loved; this one is like oh my gosh, I’ve finished it and I kind of liked it. It was called Off to Be the Wizards. The concept is it could have been like one of the best books ever, but I think the author under-delivered, but it was still kind of ok book. Going to Lynyrd Skynyrd and Tesla on Friday, so I'm going to pick Lynyrd Skynyrd and Tesla. There's a cool I found this week called NVD3 for Angular. So, it's Angular directives and Angular integration for all the NVD3 charts, which is really cool. And then I'm going to pick a browser extension. It's a Chrome Extension called Momentum. And try it and trust me, you'll like it. It's a like a super, super.. it just replaces your new tab page, and you'll love it. It's awesome. Try it out.

I only have one pick this week, and that is Dr. Who. It's back on TV. So, I'm super excited. I watched the first episode. It was a lot of fun. The new Doctor is different, but I liked it. So that’s my pick. And I guess we'll wrap up. Thanks for coming, guys. Really helpful and educational.