The panelists talk about best practices for teaching Angular.js.

 

How do I sound, by the way?

Like Barry White; deep...silky.

Like Barry White on helium.

Hey everybody, and welcome to Episode 5 of the Adventures in Angular Podcast. This week on our crew, we have Joe Eames.

Hey, everybody.

Lukas Reubbelke.

Word.

John Papa.

Hey, everybody!

I'm Charles Max Wood from DevChat.tv. And this week, we are going to be talking about teaching Angular. I'm kind of curious what experience you guys have in teaching Angular.

John has none. I don’t have any. I don’t think Lukas any, either.

I taught about it one time.

I gave up because Angular was just too stubborn; it didn’t wanna learn anything I wanted to teach it.

I see what you did there. That was clever.

Very clever.

Most of my experience teaching Angular has been, “Hey, let’s pair on something.” “Oh, that was cool. I learned something.” “Hey, that was cool, you learned something.”

My experience is I run a user group in Phoenix, and so that’s kind of where I started is just getting really excited about something, and getting in front of the group and just sharing it. And then from that, I've done a few workshops in the valley. Now, I do full day workshops. I've done some for egghead.io. So it seems at this point, any opportunity that I have to get up and talk about Angular, I generally feel compelled to do so.

Yeah, my experience has been I've done a lot of PluralSight stuff and some articles, conferences. I also do the corporate training side of things with Angular. My favorite about teaching Angular honestly is to take teams who are new to it, and are doing some [unintelligible] technology and kind of draw [unintelligible] relations to what they are doing and how [unintelligible].

That’s cool.

Yeah, that’s very cool. I've done, let’s see, four PluralSight courses now -- working on my 5th. Done a lot of teaching and talking at conferences; I've also done some consulting, introducing teams to Angular, plus user group presentations. A buddy of mine learned to program, so I taught him Angular while he was learning how to program. And I've also done a lot of pairing and working with other people and teaching them to program at corporate jobs that I've had.

Awesome.

I think the thing that’s right now this going on with Angular too is that we're kind of at the… it's been around for a couple of years. We're right at that cusp where people are really coming in [unintelligible] to Angular still. So there's a lot of demand for early beginner, [unintelligible] start content.

Yeah, that's definitely true. There's a lot of people out there that are talking about wanting more information about Angular, but the fact is that the masses are still…, there's still so many people that are new to Angular, that still need a lot of basic information. And Angular changes a lot; so if people aren’t writing new blog posts or giving new talks about the basics of Angular, there's a lot of people out there that are missing out on up to date information about the basics of Angular.

And one interesting thing that happened to me recently is while I was doing a 2-day training course, and the material that was written by John Lindquist and Joel Hooks was excellent. It was phenomenal. But when I got into this particular context, and we started talking about Angular is I've realized that had I stuck to that course outline, I would have lost everybody in half a day. And so what I had to do is kind of modulate to the crowd, and really take the time to just focus on kind of the core concepts. What I consider to be 80/20 rule in Angular, kind of the core components that you use over and over. And from there, really slow it down, and make sure that people are writing code and understanding it and seeing it come to life. And in the end of two days, the lights went on for a lot of them, and I can see they were finally starting to get traction. And that is ultimately, I think is the most gratifying part about teaching any concept; but really modulating to where the audience was is going over the basics and taking time to do so.

So Lukas, you did a couple of things that are really awesome there that I think is worth clarifying too is one, for the uneducated in Angular, that may come off as sounding like, “Hey, Angular is too hard for [unintelligible].” That’s not what I think you meant either.

Not at all.

Yeah. I think a lot of us had been using Angular for so long and we know it so deeply. I mean, once you're an expert at something, we will have an inherent problem at teaching it, and that problem is that once you are an expert at it, you no longer remember what it was like when you didn’t know that thing. So you have to kind of try to go back and empathize with what it was like before, so you can teach it again. That’s a core problem all teachers have. And in Angular, some of the worse posts out there, quite frankly, by getting started in Angular, are the once that skip past all the basics. I mean, what is a [inaudible] you got to teach them that too.

Yeah, very good point. That’s a common thing with teaching anything; once you get into it is just not realizing how many assumptions that you make. So with Angular, that’s definitely one of those things; talking about mixing Angular into the HTML, and what that means. And just not having the assumption that people already understand how directives work, and how these attributes that you mix in to your HTML are going to affect what’s going on.

Yeah, even though you start off writing code that’s kind of overly simplistic when I teach too, I do it step by step to kind of bring up line by line, from we're learning it, and eventually we're going to evolve it to a better coding practice. But first, let’s learn what it does and why it does it. And I actually try to start with something like a jQuery-based application to show them, “Here’s how you did there. Let’s start using Angular and see how [unintelligible].”

Yeah, that’s awesome.

And even for me, a lot of times when I start teaching Angular is I'll start out just writing the HTML, bootstrap the app, then an ng-init just kind of show the binding right out the gates. But the first cut of whatever I'm teaching will be just everything will be in just a single JavaScript file. And actually, I

believe it helps people visualize, and see kind of the big picture when they can look and see 100 lines of code that consist of controller or service, maybe a directive. But just kind of starting out really simple, and just iterating over that, and allowing people to just build on it and start to kind of visually see those patterns. Because our brains are wired for pattern recognition and so, I would never write an entire Angular application, and put everything to a single JavaScript file. But to start out kind and kind seeing it all together in one place, and then from there, that sets the stage for the next conversation of, “Ok, here’s how we break this out and turn this into something that’s scale.” But right from the beginning, one JavaScript file, one HTML file, you can literally build an entire functional application that way.

Yeah, I think that the key there is how you teach it and how you actually write it. You have to make it clear to the audience that, “I'm doing this, to teach you this.” I always have a rule. I never tell them what I'm not going to do; I always tell them what I'm going to do. Don’t tell, “Look, I would never do it like this in real life.” What you should tell them instead is, “We are doing it this way because we're showing you step by step how to get there.” Because the minute you tell them the negative of what you are doing, I find that a lot of the audience kind of turns off and [unintelligible].

Pro tip! Actually, I'm taking that one and writing it down.

Right.

I'm kind of curious. Joe mentioned that he had taught somebody who was learning to program how to program in Angular. And so I'm kind of curious, do you teach many people who don’t have a lot of programming experience?

I have had the privilege of doing that.

Is there a certain based level of skill or certain things that they need to understand before you can really get them going?

I think you have to understand like what variables, methods and kind of the basic control structures are to get started; so, how do you write a method, how do you do ‘if’, ‘else’, and ‘for loop’, how to iterate over structures. And honestly, if somebody understands that and more importantly, if you know how the IDE works or how to actually write a file and get it to load in the browser, that’s usually the only foothold that I need to start making progress.

I find that the people have the hardest times teaching honestly are the ones who know jQuery really, really well. People who got Backbone or Knockout or Ember and those kind of experience, they kind of grasp on because it's like for like. The people who’ve got ASP.NET or JSP or Spring experience, they can kind of gravitate too, but the ones who are writing a lot of jQuery – like, tons of jQuery apps -- they are the ones that I thought, it's almost like you have to (and I was one of those), you have to unlearn some things first, to learn… “Ok, it's not that jQuery is bad; it just does it differently.” And you can’t take it exactly one for one.

Yeah, definitely. I'm in the process of teaching my daughter how to program at all, and I'm using Angular to do that. And that’s pretty early in the process. I don’t necessarily know that I have much in the way to report in that matter. But one of the things that I did learn right off the bat is to use Plunker when teaching her Angular, so I don’t have to spend time worrying about organizing files and keeping track of files and different things like that. Just get on Plunker; it's one step to add Angular to a project with Plunker. You can even create templates in Plunker if you want, but then you can have somebody up and running with a little Angular app. And like Lukas said, that whole single script file is a great way to go so that they can see all the different pieces all together for simple Angular applications, rather than trying to go back and forth between a bunch of different files. And Plunker is great at that. It also lets you separate files if you need to, but you can stick all your Angular code to one script file, and then have all of your HTML in one file, and it's very simple to look at and understand.

That’s a great tip, Joe. I think Plunker and [unintelligible], all those sites are wonderful for teaching.

Absolutely.

And not only that is you can actually version… you can share your Plunks, but then you can actually version them as well. And so that’s really handy to share it, get an iteration. If somebody sends it back, you can even fork it or it really even sets the stage for kind of collaborating across virtual relationships of, “Hey, I sent this to my friend.” Or I put this out to a blog post. And then somebody forks it and then actually improves upon it, and then you learn something. So it's kind of creating those interesting feedback loops.

Right. And if you are working with somebody, maybe one on one that just has questions, then they can use one of these tools; send you over what they have with the question, you can fix it and get back to and it doesn’t have to be a synchronous activity; you don’t have to be on the phone or sitting next to each other.

Yeah, makes a lot of sense.

Of course, if you are going to teach somebody one on one, by far, the best way to do it is to pair program. There's just no replacement for that. And that’s true of course with anything. There's nothing better.

And you know as I've said before, I mean, I've been in a position where I was trying to learn something or we were talking about something that neither of us really understood, and it's just nice to have another brain sitting next to mine that’s working through the same problem, and we can discuss it verbally and just kind of figure it out. And it doesn’t even necessarily have to be in person; though you have to get better communication in my opinion, but overall, just doing it online with somebody who may have a little bit different experience than yours.

And I think that it's important to have kind of a White Belt Mentality. I heard this phrase the other day, where even though you may be an expert is to realize that even though you are in a teaching position is that you still have an opportunity to learn. Ultimately, you are still a student; to where I've sat with very experienced programmers, even actually not some. For instance, even Jeff Goodman who wrote Plunker is actually not a programmer by trade. And so kind of coming from a place where there is no context, he does some really interesting things that I would have never thought. And so that is for me the beauty of pair programming, is that you have an open mind and you are ready to learn, even though you are there to teach, is it's really amazing what you can pick up just because there's so many permutations of ways to accomplish things. And so I would say, if you wanna be an effective teacher, have that kind of student mindset and look for opportunities to learn yourself.

So one question I have for you Lukas is when you are teaching somebody, what order of concepts do you cover with them? And when you tell them about the different pieces?

So I have this 80/20 rule. I'll send the graphic out. It's just a diagram that I've used, but I'll start with actually just using ngApp to bootstrap the application. And using the ng-init and just the double curly braces, just to show that you have these double curly brace, it renders as a string in the browser, and when I add ng-app, then it actually turns into something. And then from there, I will usually introduce just a module, is the container to kind of put my stuff and then start with the controller. And then once whoever I am working with, understands that if I put a method or a property in the controller, it's available in the view, and they understand that relationship and really spend an extra few minutes explaining that you wanna pull the state out of the DOM and keep it in the controller, which is that view model had which is really important. And I think hard for jQuery developers to kind of wrap their mind around, but once they do, is extremely powerful. And at that point, once somebody understands, “Ok, I have a model, a view and a controller,” everything from there (in my opinion) is an extension that a service is an extension of a controller, and a directive is an extension of a view, and everything else is kind of a specialized version of that.

Yeah, I have shown people the basics. I'm not as expert as you guys are at Angular, but I have shown people some basic stuff. And basically, I just start with HTML and then just enhance it. “So you get this, and if you use this directive, then it does this,” And watch their eyes kind of, “Oh.”

So it's interesting, Lukas, you start off with bindings even before you start talking about controllers then, right?

Only very quickly, because I think that’s really… I don’t think it's the most crucial part of Angular, but it's definitely I think is one of the most impressive parts is having that two-way data binding.

And so that’s where I start just to say, “Here we have an Angular app. You can see the binding working.” And you can do that with ng-init, which I think it has limited usefulness, but to just spin something up; just to get something up cause and effect in 30 seconds, I think is a great way to show them like, “Hey, this thing is alive.”

That’s really interesting, because I think I generally kind of take that sort of things for granted, so I just kind of gloss over it.

Yeah, me too.

And I would have never thought to do it that way except I was doing a workshop with Matias Niemel_, and that’s actually how he started out by using ng-init, is he went through a fairly elaborate example and that was one of the situations where it's like, “I would have never thought to do that,” but awesome and I'm going to work that into my toolbox.

For example, how quickly do you introduce, like, two-way bindings?

Usually, once kind of the view and the controller is in place, so I'll start out with like ng-click to say, “Hey, the view issues a command back to the controller,” and that’s really only kind of… a lot of times you say, ‘two-way data binding’, but really it's most times, with the double curly braces it's just a one-way data binding. But then from there is all work in kind of a form and using ng-model, then I'll hit that up. So actually, that’s not true. So, in an ng-init, a lot of times I'll say, “Ok, here’s the binding. Let’s put input form in.” So I'll just create an input control and use ng-model, within the first 60 seconds I'm introducing that. But then to actually do something substantial with the controller is within 30-60 minutes, is I'm introducing how they actually take input from a form and push it into the controller.

And how soon do you introduce custom directives?

When it's appropriate.

See, I think custom directives are one of those things that you can get really far in Angular without [inaudible] kind of know about.

Right.

For beginners, I don’t usually touch those at all.

So here's another question: what concepts in Angular do you think are counter-intuitive, that have to be really laid out and explained. And I guess as a similar point, what concepts might be things for those already have some programming experience, like we talked about the jQuery mindset previously, what concepts are things that people have to be explicitly told, “This is really different in Angular.”

I think you can go down the rabbit hole with directives and do some really kind of weird things. But even then, I think directives as a whole, there is kind of a simplified world view that once you understand, “This is what a length function does; this is what a controller does; this is how you set it as an element or an attribute.” And so if you build the strong foundation, then I think it's a little bit easier, but I've seen people jump into the deep end -- with directives, especially -- and do some really unconventional things and keep themselves painted in a corner. And so that is one of those things with directives especially, that they are super powerful, but they can be really confusing. And so, start with the foundation and then build on top of that.

Yeah, I think directives are one of those black holes where they are powerful, and understanding not only what they can do, but when you should use one versus using another alternate options as well. Like using an ng-[unintelligible] in some cases, or just doing straight up view.

Are there any other concepts that you guys find to have to explicitly tell people that, “Hey, this is how Angular works and this is going to be a lot different than what you might have experienced with other languages.”

The digest cycle; sooner or later, I have to get into that. And you don’t have to understand the digest cycle. It's actually like digest; you don’t have to understand it to appreciate food, but eventually it is helpful to know how that’s working. So usually, within the first hours of I'll say, “Look, you don’t have to completely understand this, but it's not magic. You can actually program this yourself if you are so inclined. And this is what's happening.”

So with digest cycle, do you also mean explaining dirty checking?

Yes. The invalidation-validation cycle, which being a Flex developer, it made perfect sense to me, and why I liked Angular because I understood that process. But somebody who is not familiar with invalidation validation cycle is it does appear a bit ‘magical’ -- and I hear that quite a bit. And so, just taking the time to actually explain that, it is actually a logical thing that’s happening under the hood.

Well, the first danger they fall into when you tell the [unintelligible] cycles, “Well, it's just magical.” If they go ahead and take your advice and say, “I just accept that it works.” Then maybe something like, “I am going to use jQuery to make AJAX call over some data.” “Uh-oh, wait a minute. My data is not showing up on the screen.” Or something along those situations where the digest cycles, doing something that they are not aware of, so that’s a hurdle [unintelligible].

Yeah. I would say for me, one of things that I commonly point out is when you stay in Angular everything is great; the minute you leave Angular, then you have to understand how to put your digest cycle back in and start it back up. And so if things aren’t binding, then you’ve probably left Angular land and you need to come back; you need to bring it back.

And it's not that Angular doesn’t work with other things, because that’s how people sometimes take that. It's that if you are going to leave the way Angular is doing some of the things it does, you are in danger to have to start getting in how the digest cycle works so you can actually call and apply if you need to.

Right. So what about counter-intuitive concepts? Are there anything that…

What do you mean by ‘counter-intuitive’?

Well, counter-intuitive, meaning if you look at something from the surface, it seems to work that way, but in reality, it works in entirely different way. And if they don’t understand that, then they are going to have a hard time.

So I will say that the one thing that even trips me up sometimes is because in the DOM, ultimately it's very clever kind of string interpolation, is that there are times so for instance like ng-include that you have your double quotes, but then you have to actually put like a single quote in there. So there are kind of conventions that if you are not aware of, they will just not work.

How about you, John? Anything come to mind for anything counter-intuitive?

That is definitely one of the things that hits me up a lot is the double quotes or the single quotes in ng-include. I'll hit that myself. Another thing I get sometimes is when I'm inside of the controller and I'm trying to access something that’s on the scope, sometimes I forget to inject the right services up the top, so the whole dependency injection side of things, I've got my own styles, so how do I avoid these kind of issues? But making sure if I don’t have a service that I've got to go inject, it just becomes a problem as I run my code and, “Oh, I forgot to inject that thing.” Because the error message is usually something extremely obtuse; like, “Hey, you forgot to inject something somewhere, but I'm not going to tell you where that is.”

Oh, I'm so glad it's not just me.

I got one yesterday. It said, “You haven’t injected ng-locale.” I'm like, “I'm not trying to use nglocale.” [Chuckles] “Why are you telling me that?”

Yup. And the errors, you see the errors and you're like, “What?”

Any other concepts that you guys are like always try to make a mental note to cover and talk about something when teaching somebody Angular?

Routing. I always try to teach ng-route right at the box. While ui-route is awesome, (we can talk about that as a whole show), I think the concept of client-side routing is hugely important. And not everybody gets that, because a lot of times, people are trying to make the leap from, “Wait a minute, is this going to do a post back? How does the client know? And then how does this relate to server side routing where I do MVC there.”

I think routing is one that I try to bring right out the gates as well. I actually did a post a while back about how to build a simple web page using ng-route, and it's actually become a very popular blog post to my surprise. Because I think when people see like, “Oh, I can do this large unit of work by simply using ng-route,” kind of helps them, I think take the leap from something that’s theoretical, to something that they can actually use. And so, I completely agree.

You know for me, I think the one thing that I always try to remember to explain to somebody is that Angular is stateful and declarative, and not imperative. And not to be getting to the mindset of, “Ok, I need to do something. I need to make like a change visually to the page. I need to call some function and make that happen.” But instead, to set everything up based on state, so that when you change a variable, then stick changes, right? One of the things that I find people frequently do, is they'll set up their log in, such that it will do a big, huge post back and come to entirely new page, when you really don’t need because we're so used to other places where, “Hey, if I'm not logged in and I want to accept go to log in, I’ve got to change so many things.” It's just so much easier to just post back and come to a brand new page. When in Angular, because everything is stateful, the minute I set a ‘logged in’ flag, then I can have everything on the page changed. So that’s one of those things that I tell people, “Unless there's a real reason for that or something similar, just rely on the fact that, ‘Hey, once you've changed one variable, then everything can be different.’ And it's easy to set that up.”

And to piggy back on that I think that’s a great point is a lot of times, I will talk about separating… you know, you declared a markup where that is good for. So I think Angular really excels in extending HTML or trying not to destroy and do away with it, and separating your declared markup from your imperative logic; why those need to be separated, especially for new people in Angular is how to separate state out of your DOM, and kind of drawing that line there. And once people get that, it really sets the stage for just saying the view is just being the reflection of your controller, your view model and it makes it a lot easier to start to build on more of these concepts.

Right. So what about teaching people services? Is there anything you guys specifically like talk to talk about when talking about services? And, how quickly do you introduce building your own services in Angular?

I do it relatively soon, actually. So kind of what Lukas was saying, I start off in single page and teach people what's there and build up the app. I like people stumble across the problem, so it becomes very apparent early on when they are developing an app that says, “I've got code here that I could use in multiple places. It really doesn’t belong here.” For example, data access was [unintelligible]. So I start off making a couple of calls, I have two screens that are using it. Well, why am I copying and pasting? And that’s when I say, “All right, let’s put this in a place that just reuses it.” And by the way, it's greater refactor. And that’s what that’s for. So I kind of reverse teach in that sense.

and another good way to introduce services is one is, “Here's this code that we need to reuse.” And from then on you say, “These controllers should not talk to each other.” And so when you set that constraint, is very quickly it’s like, “Well, how do they share functionality?” Or “How do they talk to each other?” And so I will usually abstract that method into a service and make it available, and I'll use that as well as a platform to get into kind of like Angular [unintelligible] with broadcast and [unintelligible]. So that’s another one is how to actually communicate across controllers using services [unintelligible]. But that usually comes up very quickly; it becomes very apparent within the first few iterations, that there needs to be some way to extend the controllers to do more across the allocation.

Right. So those are really interesting ideas. I think I take a slightly different approach when I teach people. It's only minorly different, but I kind of like to talk to people about, “Hey, the controller is only for moderating or mediating between the view and the model, so don’t put business logic in the code. There's a place for that.” And I relate services to your typical classes in most other languages. These are classes; they should follow the SOLID principles; they should be reusable; they should be cohesive. And this is where you do all of your main coding.” So I like to talk about those types of things when talking about services. So I probably don’t wait for a need for the service, but throw it in right in the beginning of service is where you put the meat of your code, and controller is simply where you mediate.

I really like that, because the overall separation of concerns makes it a lot easier to reason about your application. And with a lot of these applications and a lot of the problems we are trying to solve, thinking about the code is the hardest part. And so if you can teach people how to organize their thinking so that it's easy to go back through it and figure out what you did, because I have to say that the number one consumer of my code is usually me. And I don’t always remember what I did; it just makes a lot of sense. And when somebody comes in, they can figure out pretty quickly what your thought process is and where you put things.

I will say that that tactic works a lot better with people who have at least a reasonable amount of coding experience. For new people, then that’s a harder concept to relate.

Yeah, but that’s because they are struggling to grasp other concepts, and so they just want to stack it all up and just be able to see it run through it and go, “Ok, that’s what it does.” So it's much more of a procedural thing I found, for a lot of new developers.

I think that when I have to tell some folks, I try to gauge in the beginning and see where they come from. So some of the folks I've taught have come from a world where everything was in one large file, or a class 4000 lines long. And when I teach those kind of people stuff with Angular and I get to services and factories, and concepts like Ravioli, which is small, encapsulated code or single responsibility…

Pro tip! [Laughter]

I need to put that on the sound board: “Pro tip!”

So what I try to do there is say, “They are not going to grasp the concept of factories and services right away – or the value in it.” So that’s why I do that trick of letting them discover it on their own. When it comes to people who are already familiar with that, you can jump into that a little bit earlier, but that’s why I have some example where I show the spaghetti code model where I have… Actually, it's hard for me to write this. I have a really large controller, that’s got about 800 lines of code in it that does everything. And then I've got it broken out to all different pieces where everything is fifty to eighty lines of code each in a file or a component. To show them side by side of why this is better than doing eight hundred lines of code, and how hard it is to unit test, and how hard it is to maintain, and just to find your own code in there. Because just telling somebody Spaghetti versus Ravioli is one thing, but showing them that mess is whole nother story.

Yup. Well, I hate to wrap up the conversation, but we're at the end of our time, and we need to do picks. I know that some folks have some hard stops here coming up. So let’s go ahead and do the picks. Joe, do you wanna start us off with the picks?

Sure. I picked this on JavaScript Jabber, so for those who might have listened to JavaScript Jabber which probably came out a day or two ago, this will be a little bit redundant, but I read a book called Forging Zero, which is a super, super low-cost, like $2 on the Amazon Kindle Store. It's kind of one of those self-published novels. It's a Sci-Fi, war novel and just absolutely amazing. Just loved it. I couldn’t get enough of it; couldn’t put it down. I was in a road trip and begged my wife to drive, so I could read. Absolutely loved it. One of my favorite books that I've read this year. New favorite author. So I'm going to pick that.

Then my second and final pick, since we are talking about running Angular, it would be obviously completely appropriate to talk about PluralSight. And specifically, on a pick, Scott Allen’s course on Get Started with Angular, which is a great introduction for people who don’t have really much in a way of web experience, because it introduces Angular using Plunker, which means you don’t have to do any setup. And it's a great way to give somebody a very gentle introduction to Angular. For those who have more experience doing web, if they’ve done reasonable amounts of JavaScript and stuff, they might find the pace to be a little bit slow, which is that’s a great thing about PluralSight is there is around 20 courses on Angular in PluralSight, so it's well-worth the $30/month.

John, what are your picks?

I think I'll stay with the theme that Joe’s got there on learning Angular. And on the PluralSight side, yeah, there's a lot of great course. Joe’s got one himself as well. Scott’s is really good too. But the nice thing there is you can always fast-forward. I definitely will check out those libraries and see where you go. And then you’ve also got the egghead.io videos, which we've kind of indirectly referred to from John Lindquist and Joel Hooks. Those are nice little 5 minutes or less videos that are online which you can learn these things from.

One thing that I've done too for my second pick is I created a package called Hot Towel – because you can’t go to a spa without a towel. And this package is a jumpstart to creating your first Angular application. And there's a new get package for the .net, and there's a Yo Generator that I am actually going to be releasing later today. It's basically just jump out there and gives you the beginning steps to an Angular application. And that removes that friction of, “I got to set the CSS to create a menu, and create content there and pull in the right libraries. So I use that a lot. It's been pretty popular for me people just to kind of use it for learning tool.

Oh, that sounds totally awesome. And if you are brand new to a single page applications, and Angular is your first intro, then John, your course on single page applications is actually awesome for that.

Thanks, man.

All right, Lukas what are your picks?

I've really been digging on web storm; I use it a lot and it's just amazing how I'm always learning new things, new ways to integrate it into my workflow. So I was doing some [unintelligible] stuff the other day, and it was super seamless and easy, as well as [unintelligible].

I've been reading the book “Free+Style” by Carl Paoli. And I love kind of these definitive ideas. And so the tagline is “Maximize Sport and Life Performance with Four Basic Movements.” So he just essentially talks about these four movements that you can work on to just be a better athlete.

And one last real quick is I've been reading or listening to The Magicians trilogy by Lev Grossman. And it is hilarious and awesome. He's such an incredible writer; he makes me laugh all the time. It's a really good fantasy, Sci-Fi, epic sweeping saga sort. So I really recommend The Magician Trilogy.

You guys are reading quite a bit. I feel like I'm kind of dumb over here. [Laughter]

I got four kids though, so maybe that’s why I don’t read as much.

Yeah, well I have four kids and the only way I get the reading done is by audiobooks.

+1.

Yeah, I mean, I'm in the car, I listen to a whole bunch of audiobooks while I was gone. I guess it's my turn for picks. I spent this last weekend in Dallas at Podcast Movement, which is conference for podcasters, and it was so, so, good. And I'll probably pick some stuff for the conference; I'm still kind of going back through all the notes and everything that I have from it. But while I was there, I actually listened to, on the plane and stuff, I listen to a couple of books.

The first one is My Story, it's by Elizabeth Smart. This is just kind of a general… it's a very interesting and true story. Elizabeth Smart was kidnaped when she was 14 from Salt Lake City and she was found 9 months later with her kidnappers. And it just talks about kind of the crazy stuff that she went through. Just really, really amazing.

Another book that I'm been listening to, if you have your own business or you just feel like you are overly busy, I've been listening to Virtual Freedom by Chris Ducker. And he actually have a podcast out there too where he talks about new businesses. I guess it's a business podcast, actually. But anyway, Virtual Freedom talks about hiring virtual assistants, and freelancers to help you get you work done. If you need a freelancer, I'm available by the way. Anyway, just awesome book.

And then last week, we talked to Daniel Pink, who is the author of To Sell is Human. And if you have this aversion to sales, or you have this idea that sales is this evil profession or something, you really have to go read that book, because the whole idea behind selling really is to share an idea and exchange value. And it's something that we all do all the time; whether we are serving people or whether we are actually helping them find what they need for a price that they are willing to pay. And so, anyway, I really, really enjoyed the book, and talking to Dan was just terrific. So I'm going to pick that as well as The Freelancer Show. As of this recording, it comes out tomorrow, which means that when you hear this, it will already be out. It will be the last Freelancer Show episode. So, yeah those are my picks.

Thanks for coming, guys. Good talk.