WARD:
He's being really quiet to realize what a big mistake this was to come on the show.
[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco and New York and LA get on JavaScript developers providing to put the salary and equity upfront. The average JavaScript developer gets an average of 5-15 introductory offers and an average salary of over $130,000 a year. You just can either accept an offer and go right into interviewing with the company and neither with that any continuing obligations. It's totally free for users, and when you're hired, they'll also give you a $2,000 signing bonus as a "Thank You" for using them. But if you use the Adventures in Angular link, you'll get a $4,000 bonus instead. Finally, if you're not looking for a job but know someone who is, you can refer them to Hired to get a $1,337 bonus if they accept the job. Go sign up at Hired.com/AdventuresinAngular.]
[Does your team need to master AngularJS? Oasis Digital offers Angular Boot Camp, a three-day, in-person workshop class for individuals or teams. Bring us to your site or send developers to ours -AngularBootCamp.com.]
[This episode is sponsored by Wijmo 5, a brand new generation of JavaScript Controls. A pretty amazing line of HTML5 and JavaScript products for enterprise application development. Wijmo 5 leverages ECMAScript 5 and each control ships with AngularJS directives. Check out the faster, lighter and more mobile Wijmo 5.]
[This episode is sponsored by Digital Ocean. Digital Ocean is the provider I use to host all of my creations. All the shows are hosted there, along with any other projects I come up with. Their user interface is simple and easy to use. Their support is excellent. And their VPSes are backed on solid-state drives and are fast and responsive. Check them out at DigitalOcean.com. If you use the code “angularadventures” you'll get a $10 credit!]
CHUCK:
Hey, everybody! Welcome to Episode 51 of the Adventures in Angular show. This week on our panel, we have Ward Bell.
WARD:
Hello!
CHUCK:
Lukas Reubbelke.
LUKAS:
Hello!
CHUCK:
Joe Eames.
JOE:
Hey, everybody!
CHUCK:
I'm Charles Maxwood from DevChat.tv. We've got a special guest this week, and that's Tero Parviainen.
TERO:
Nailed it.
WARD:
[Laughs] [Incomprehensible]
TERO:
[Chuckles]
CHUCK:
Do you want to introduce yourself, Tero?
TERO:
Sure! I'm a programmer based in Helsinki, Finland. I've done a bunch of web, full stack development over the years, like a background in Java and Ruby and Clojure. But for the past couple of years, I've pretty much specialized in front-end development and doing web applications as an independent contractor for different companies here in Helsinki, and I've mostly been doing that with Angular. As part of that story, I've also started writing a bunch of things about Angular. I've written some articles and I'm also in the process of writing a book about Angular "Build Your Own Angular". And as part of that, I've gotten some internals of that framework in a much more depth than I really ever wanted to. That's where I am at the moment.
CHUCK:
Alright.
LUKAS:
Tero, if you don't mind, this is what I would like to know. How did you actually get into just digging into the Angular source code? And, what was your first and immediate reaction within the first 30 seconds of seeing it?
TERO:
The reason why I went into it is, I started using Angular and people were saying that it's really difficult to learn and there's like bunch of magic in it; all the change detection stuff and the Directives and things like that. And, I always feel like very uncomfortable using APIs, and then frameworks, and libraries that I don't understand fully. I've had this experience with a bunch of different things in the past, like there are parts of moving on Rails where it's something I used for years that I still don't quite know how they work. And it's not nice to use APIs like that because you always have this feeling that you probably could do whatever you're doing better in a more idiomatic way or a more concise way or whatever if you only knew how to do that. And it seemed like with Angular, there was a big chance of that happening again because people were saying that it was difficult and the documentation wasn't there or things like that. So, what I started to do is, I started to explore the source code. I actually started from the Scopes and the change detection system because that was something I hadn't really been in any of the frameworks I had used before so I wanted to know how that works and sort of demystify it for myself. And then I ended up writing an article about that and then the book.
So yeah, first 30 seconds... I can't really remember. Maybe it's just something I wiped from my mind because it was a shock or something. But I think, one of the first things that came to my mind was that, there was a lot of code, like there's just a wall of code because the Angular 1 code base is written so that there's not a huge amount of files in it, but there are very large files in it. When you open up one of them, it's daunting to look at something like root scope JS or compiler JS when there are more than a thousand lines of code in there. That's one of the reasons why I actually started to learn it in the strategy that I [incomprehensible], which was to actually reverse engineer it to write my own version of it, or like a clone of it and going to force myself to learn from the first principles, what's going on there, instead of trying to approach the existing code like [incomprehensible] and try to understand that.
CHUCK:
We've got you here to talk about the Compiler, which I'll admit I had to go look up [laughs]...
TERO:
Right.
CHUCK:
Because I just took for granted that Directives work, I guess...
TERO:
Yeah.
CHUCK:
So, the Compiler is the thing that goes through the HTML code and identifies the Directives you have in there and then makes them work?
TERO:
Exactly. The Compiler is sort of internal Angular facility that makes it possible for us to use Directives. What it does is, it goes through the whole HTML DOM tree that you have in your host page and your templates and finds all the Directives that match and applies them to those elements. While doing that, it'd also goes over all the Directive definition objects that you have; all the configuration objects that you have there that have to do with linking and scope creation and scope binding [incomprehensible] Controllers, and Templates, and Transclusion, all these different features are all things that are implemented by the Compiler. So everything that you can do with Directive really is things that are driven by the Directive Compiler.
CHUCK:
I have to ask.. I came at Angular as kind of I-want-to-just-make-it-work. What are the advantages to me to actually understanding the Compiler as opposed to just taking for granted that the Directives will do what I want them to.
TERO:
To me, at least, it was that the Directive API itself is so difficult to understand. It's a very big API with I think 15 different configuration options and who knows how many combinations of those options that you can have.
I think what happens with most people, at least what happened with me initially, was that you end up learning a sort of subset of that API, but you don't ever bother learning everything about it and then you just use that subset like you know that there's a link function that you can have and you can do things in there. And, that's fine! You can get your problems solved like that. It's great. But what I tend to see happening is that people end up doing things in the Directives that they could accomplish much more easily by using more of the Directive API. They end up doing some DOM manipulation that you could replace with Transclusion or something like that.
I just wasn't able to pick up all the nuances of that API from the API and the documentation itself.
And I just want to understand a little bit more about what goes on inside because that's the ultimate documentation, it's the source code itself.
WARD:
May I back up a little bit? Because we have our applied audience who are Angular folks so I'm going to tell you, the way I came to Angular, I don't think I wrote a Directive for at least 2 months. I was very happy for developing in Angular and I saw that the Directive was sitting out there and that the API was, well, let's just say was bizarre. But it didn't trouble me because I came equipped with enough Directives to make it useful. I didn't actually write a Directive for a very long time. Is my experience unusual in that respect? And why is it that when I read about people talking about Angular like the thing they go for is Directives and the thing they think is hard is Directives, whereas, to me, it's like "why is everybody obsessing about Directives?" So, tell me, what's crazy about my experience or not? And, what's the big deal about Directives?
TERO:
In my opinion, it's not crazy at all because that's, at least, my experience as well. I started using just ngController and Controllers because I knew Controllers were coming from Backbone or something like that. I thought that Directives were this thing that you use for special purposes when you need to do something to extend HTML that you'd just write your app using Controllers. That's what I did for a good while. But it started to shift at some point when I started thinking that you could actually get a lot more mileage out of this idea that you can extend HTML while coming up with your own elements and attributes that you wish existed in HTML, but don't. And Directives are the way to do that. I think that's actually pretty much the original idea of Angular back from 5 or 6 years ago, which was to have this HTML-DSL for applications. At some point, it seems that it wasn't really being used like that by the community, which has used Controllers and treated it as sort of MVC framework.
But then, for myself and I think more generally in the community Directives have, people have started to use them in more scenarios in the past year or so especially when after the material about the Angular 2 has been started to come out where Directives have a much more central role in the sets of components. I think, that's where Angular itself and the community seems to be going at the moment; not using bare Controllers as much as having Directives for pretty much everything.
WARD:
I want to ask a little bit about that because that is a dramatic move and the whole Directive languages, we all agree, is so much harder. So, somebody is approaching their own application. I've seen that shift, too, like they're saying "Never write a Controller; always put in the Directive", I probably over simplifying that. But, what's the criteria by which you think somebody approaching their application should say, "That's the right place for the MVC-style, for the Controller-style", and over there, that problem set is the right kind of target for thinking about the Directive-style. First of all, do you see it that way? Do you see that kind of developer coming from that kind of decision?
And if so, how would you guide them?
TERO:
What I tend to do recently is not treat this as 2 different ways to do it, but actually combine those 2 by actually still using Controllers, by having each Controller paired with a Directive, which is pretty much essentially what components in Angular 2 will be like. I still have the Controller, but it always comes with a Directive that's applied to some element. And then the big reason, the good thing about that is that you can have Directive with Isolate Scopes. That's, at least for me, the big difference. Whereas with ngController or Controllers without Directives always share this surrounding scope and have this prototypical scope inheritance going on, and that causes a lot of confusion for a lot of people with all the shadowing that goes on, and more generally with the fact that all the state on the scope is being shared between all this different Controllers in a way that's not controlled them anyway.
WARD:
Didn't that go away with the Controller S pattern? With the Controller S pattern, you're really insulated from the outside scope, right?
TERO:
Yeah, but by convention, yeah. From your expressions, you can see which Controller things come from, but they're still there; you can still access them by aliasing Controllers so they're still there.
But with Isolate Scopes, actually, they just won't be there so you have true encapsulation, where the data is just not going to be on the scope. So, it's a stronger guarantees about modularity there.
WARD:
Okay. But all the routing systems like the UI-Router and the new router and all that other stuff are thinking in terms of, again, of Controllers rather than Directives. So, how do you cross that boundary?
TERO:
What I usually do is, for each route, I tend to have one Controller which receives any data from the route that it needs. But all it really does is have a template that instantiate one root component for that View, and then everything else downwards from that is all Components.
I think, with the new router that's coming out, it's actually going to change a bit since it's supposed to be able to have route directly to Component instantiate. Even that kind of bridging won't be needed anymore. I'm not sure if that's going to be the case for Angular 1, but at least for 2, that's going to be the case, I think.
WARD:
Yeah, that sounds right for Angular 2. Okay! So, that helps position me Controller versus Directive and where your thinking is. Now, [chuckles] I'm more comfortable having you say, "Okay, folks, now that I'm just stirring you towards Directives, here is what you need to know." So, what do we need to know?
TERO:
Well, yeah, quite a lot of things to know about the Directive APIs; you can do anything really with it because the API is so huge. But one thing, at least, is that for use case which we're talking about for Components, there are really I think 3 or 4 options that you need to understand. One is that, when you make a Component Directive, you have the scope attribute on the Directive definition object, which you can define this Isolate Scope and you want to understand how those work and how you can pass things into a Component Directive from outside and how those bindings behave when things change over time. And then you want to know how templates work and how you can have this Directives that actually provide their own internal HTML, and optionally, you might want to know about how Transclusion works and how you can actually pass in pieces of HTML from outside to that Component. And finally, you want to understand how Controllers integrate with Directives and then that you can have this Controller attribute on your Directive definition object that gets paired with the Directives in which you then have the actual logic of that component.
Those, I think, came up with 3 or 4 attributes in total that, I think, Component Directives should have, and that you can get a lot of mileage out of those.
WARD:
For those of our audience who gag on the very word "Transclusion", can you translate that into the very simplest finish that you...
TERO:
[Laughs]
WARD:
[Laughs] How would you tell somebody what Transclusion is without ever saying or using the word Transclusion? It's actually, in my view, something that people would recognize as something that they would want to do but the word gets in the way. So, how would you tell people what they're really dealing with so they don't get scared?
TERO:
Right. For the use case for Transclusion is. it's like you have some Component in your application. I think the economical example of something like that would be like a tab bar with a tab component. So you have a component that sets itself up as a tab with its own template that sets up the various elements and attributes that are needed for a tab. But then you want, as the user of that tab Directive, to actually provide the actual content that goes inside the tab from outside. What you do there is, in your HTML, you type in the tab element and then inside, it's you nest whatever HTML you want to go inside the tab. The way you can make that work with Angular is you can have this Directive tab that has its own template, but then you can specify this Transclude option on the Directive, which gives you the possibility to get the HTML that was nested inside, whether that was applied, and put it somewhere inside the template of that Directive where you want it to go inside somewhere in that tab [incomprehensible], so essentially, just like passing in. A no argument to a Directive which happens to be a bunch of HTML or tree of DOM nodes. That's really what it is. Yeah, the API gets in the way and the word gets in the way. But as a concept, I don't think that's complicated and it's very useful in many scenarios.
WARD:
Right. So if I have a page and has got rainbows and unicorns and bunnies and I want to have those in separate tabs, you're just saying that right those and then the goal is to move bunnies into the bunny Directive and so forth, that kind of thing?
TERO:
Exactly, yeah. In Angular 2, I think, the same is accomplished with web components standard where I think you have what it called "Content Text" or something that actually in the standard way. You can say that "I want to shift this content from the component user to inside the component to this location." So, it's really a concept that's useful outside of Angular as well as in the web component standard just not by that name.
CHUCK:
So, if people want to dig into the compiler and see where all of these stuff is implemented so they can understand better how it does this stuff, where do people get started? Do you just open up the compiler in JS file? Or...
TERO:
Yeah, you can do that...
JOE:
I think somebody has recently given an awesome talk that explains this.
[Chuckles]
TERO:
Yeah. So you can open up that file, it's just that it's really scary. I think something like 15,000 lines of JavaScript code plus another thousand or so of documentation. It's, by far, I think the biggest thing in the whole Angular code base, and it's really kind of dense code, and I've spent several months exploring it myself. I wouldn't necessarily recommend doing that to anyone else, but yeah, I did a talk about this at ng-vegas and before that, at NG-NL in Amsterdam where I essentially introduced the most fundamental parts of the compiler from the ground up, which was hopefully will give someone who's interested in that some pointers on how to get started with that.
And there's a whole treat-its-own on the Compiler in my book, which I think there's about 300 pages on Compiler JS in that book because it's so big and so complicated. I think it makes sense to spend a lot of time on that because it's hard to understand and it's really essential to how Angular works.
WARD:
How deep do we need to understand it in order to be able to write Directives effectively, the kind that I would normally write, not something exotic. Do I really need to know all of that stuff, Tero? Or, is there a straightforward way for me to do the straightforward things?
TERO:
Not necessarily everything. I don't think to be able to use this, say, something like Components or something like that because it could be a really failed abstraction if everyone had to understand all the implementation details in order to use it. And, I don't think it's that bad. But, when you get into trouble, when it doesn't behave like you expect, when something isn't working or you get an exception or just something isn't being applied, I find that having insight into how it works gets you into those kinds of problems. It's a lot quicker because you can actually think about what's going on there instead of trying to formulate the Google search for the same [incomprehensible] and trying to find out what's going on. So, it's really a tradeoff between how much headaches you have been getting from the Compiler as you've been doing Angular development and whether spending time learning the internals will actually help you save time during your [inaudible] work. That's actually the reason for me. And I found that I can solve problems much quicker when I'm doing applications, when I know how the thing I'm using is actually doing what it's doing. And as a bonus, you get to do all these esoteric feature that aren't documented [inaudible] and can do things that most people don't even think of doing because they're not known that well and not documented that well.
WARD:
That reminds me of something that we kicked around several months ago which is -- and I think, Lukas, you raised the question -- that with any Directive, there's a Compiler phase and a link phase and almost all of us spend all of our time just thinking about the link phase and we couldn't come up with really very many great reasons to use the Compile phase. You got any insights on that [laughs]?
TERO:
I don't think I've ever, in any of my applications (I've done many things really in the Compile phase). I think the only reason you would be interested in that is when you have to do some DOM manipulation and you want to save some cycles on doing that in Compile phase because when you have like [incomprehensible] or something, you get compiled once, but you can't get links several times, for example, for each item in some array for different clones. So, when you want to manipulate at the DOM, you can do it just once before the thing gets cloned so you can save [inaudible] really. But outside of that, I don't really see any points in doing anything there.
WARD:
Okay, I'm going to ask you a forward-looking question. We know that Angular 2 is coming and it's going to be different. What kinds of things -- by that mean, you're going to have a similar constructs in Angular 2 to try and cope with the same kinds of tasks that we address with the Directive -- what are you hoping to see in terms of capabilities they carried forward and what are you hoping to see in the way of simplifications?
TERO:
I'm hoping to have this component style, and I know it will be carried over to Angular 2 and it's refined to be able to construct the component, and I really hope to see a lot more of that as well like things that are already in the Directive API, but the API isn't good enough for something that's too hard to use that people don't use them as much, and get those streamlined into separate things that are understandable, and not all are part into that single configuration object. So most of all, I'm looking forward to having the current features in a nicer package because I think you can do pretty much everything we want to do with the current API; it's just some of it is too difficult.
That's my main hope for Angular 2. I'm also looking forward to the actual digging into the source code of Angular 2 as well because I'm interested in that. Base on what I've seen so far, it seems that it's going to be a lot easier to do that for a couple of reasons. One is that it seems to have been actually designed to the code right now, whereas the current version is such grown over the years with features being added to the same file, which is the reason it has ended up in the state that it is currently. For example, the compiler in Angular 2 is this whole sub-system of tens of different classes that have different responsibilities that actually are well-defined so you can actually think about feature-like templates in isolation of everything else. The second reason is that, it's in TypeScript. And whatever you think about of TypeScript, one thing is that it makes reading code a lot easier because of the Type Annotations that you have in there. So when you look at a function inside the Angular code base, you can see its arguments and it's returned by you, the types of those right from the function signature without having to dig into the function implementation and try to figure out what this function is supposed to return and what it takes, which is what you have to do with ES5.
WARD:
That's a good observation. I guess you know what your next book is going to be -- Inside Angular 2!
TERO:
Maybe!
WARD:
[Laughs]
TERO:
I hope the quality of the code won't be too good because then everyone would understand it without having to buy a book.
CHUCK:
[Laughs]
WARD:
Exactly. Well, you can have a pamphlet. I have one completely sideways question for you. You said that you had spent a lot of time in Clojure, how does that inform your thinking? Is there any relationship in your mind between what's going on in the Clojure world and what's going on in the JavaScript world?
TERO:
Yeah, there's a lot of things that, especially in the JavaScript world, that the Clojure including form, especially right now with what's going on, with what David Nolan is doing with Om library for ClojureScript, which is a React wrapper that has big ideas based on immutable data structures and things like that. And actually, just today, I was watching what they're doing right now integrating GraphQL and pull-based queries into the Om library. What I immediately thought about was that I want someone to do this for Angular 2 like have query annotations on components that will actually declaratively specify what data an Angular components needs and have the system pull that in using something like real-life from the server. I think it's just begging to being implemented something like that, and they're doing that in ClojureScript in Om. And just more in general things like immutable data which is going to be a possibility for us to use in Angular 2 application; it's the Clojure, well, it's all about that and they've been doing that for years. They're building substantial web applications now all based on immutable data. I'm really looking forward to exploring, bringing those things into Angular 2. It's not really practical to do that with Angular 1.
WARD:
Yeah, that will be an interesting -- immutability will have an interesting effect on the style in which we write our applications. It's not so much what's in Angular 2 as it is in terms of how we think about arranging things, right?
TERO:
Yeah, definitely. Yeah, exactly. And the whole architectural forcing you to do one-way data flow, for example, because you can't do mutation with components; you have to go to the Root and things like that. It'll completely change the way architecture applications. And I'm liking what I'm seeing than doing in the Clojure world, especially with Angular 2 and the way the components work there.
It would be a nice fit, I think.
LUKAS:
One more very technical question, Tero... What is the hottest place in Finland?
TERO:
Well... [Laughter]
TERO:
Hottest place in Finland... Alright, now, it seems to be my apartment because I don't have airconditioning, and it's pretty hot in here right now.
LUKAS:
I was going to say, the sauna, but I think we just said the same exact thing.
WARD:
Oh, god... [Laughter]
TERO:
Yeah, yeah, we all live in saunas in Finland.
LUKAS:
[Laughs]
WARD:
I think that's the only thing we really know about Finland over here.
CHUCK:
[Laughs] Yeah.
TERO:
We do have Angry Birds and things like that we're really proud of.
CHUCK:
Awesome. Alright, should we do some picks? Lukas, do you want to start this off with picks?
LUKAS:
Sure! So I'm going to spite everyone, and I'm actually going to choose Tero's book as my pick, "Build Your Own AngularJS". I purchased it, and it is a treasure trove of information. It's actually quite, quite large so I've just spent going through it buffet-style and picking up the pieces that I like, but it's very well-written, lots of very good examples and kind of meat to dig your teeth into so well done, Tero.
TERO:
Nice. Thank you!
CHUCK:
Alright, Joe, do you have some picks for us?
JOE:
You bet. I'm in a very quickly pick, the "U.S Women's National Soccer Team". Chuck, if you're hoping to pick that, sorry, buddy.
CHUCK:
I know. That's why I hate going last, but...
JOE:
[Laughs] Yup. They won the Women's World Cup, they're awesome, and I cannot see enough good things about them. And then, I'm also going to pick a TV Show that was on TV quite a few years ago. It's called "Better Off Ted". You can find that on Netflix. I think it only had one season, but it was awesome. Hilarious show if you liked Seinfeld, the office arrested development, parks, those kinds of corky humor shows. It's particularly appealing because it's set in an office space where they develop all kinds of things, doing a lot of research and development, and it's nice corky humor sitcom. Very funny; love watching just some hilarious episodes. So, that's my pick!
WARD:
And I thought you watched Alf and Three's Company.
CHUCK:
[Laughs]
JOE:
I watched those, too!
CHUCK:
There goes Ward, dating himself again.
JOE:
Uhuh...
CHUCK:
Ward, what are your picks?
WARD:
Actually, I wanted to watch the Howdy Duty show, but that's really going back. Actually, I'm not going tech today. I'm going to pick "Inside Out", the Pixar movie, which I was surprised by how intelligent and funny and thoughtful that was. I don't happen to have an 11-year old daughter in my life, but I thought they were real insights into what's going on as children mature and what happens to the emotions. It's actually based on some real science in there, and yet it never fails to be entertaining. I hoped there's something in there for kids because for an adult, it was very strong. I don't know how many of you have seen it, but it's definitely worth your money.
CHUCK:
Yeah, I enjoyed that, too. Alright, I've got a quick pick. I got some headphones a couple of weeks ago and I just really like them. They're the "Bluez 2 AfterShokz". They've got the, I don't know what you call it, the headband that goes behind your head, and that part I don't particularly love, but it holds the pads in place for the phone conduction, the phone conduction headphones and so they sit right in front of your ear and they sound great and I really like them, so I'm going to pick those. They're not particularly cheap, but they're really nice. That's my pick. Tero, do you have some picks for us?
TERO:
Yeah! I have a couple of picks. One is an old essay by Paul Graham called "Programming BottomUp" in which he writes about Lisp, and the fact that Lisps are these extensible programming languages. What happens with them is that when people write applications in the Lisps, they don't just write their applications in Lisps, but they actually write DSLs by using the extension features of the languages that give them a higher level languages in which writing applications is easier. What you end up doing is you'll evolve 2 things, which is your application code and the DSL in which you write that application code. The reason I'm picking it is because I think we have that, too, in Angular. We have Directives which give us an extensible DOM. So, what we can do, what I often find useful to do when I'm running a new feature for an app is going to the HTML and just dream up the perfect elements and attributes and events that I hope existed in HTML that would make writing that feature really easy. And then when I'm done with that, I can go into the other side and implement the Directives that make that dream HTML a reality. I think that that idea from Lisp that you can do with macros applies well to what we can do with Directives in Angular.
My second pick is a book I recently read called "Flash Boys", which is about high frequency trading. It reads like a thriller, almost. It's about the fact that really trading, stock trading is not done by traders directly anymore, specifically computers talking to each other. It goes into help people exploit this by a game in the system by doing things like co-locating their computers with the computers of the stock markets to game [inaudible] see some things like that. It's kind of really scary stuff and I really enjoyed reading it.
Those were my picks!
CHUCK:
Alright. Super cool! Well, if people want to know more about you or your book or anything else that you're working on, do you want to let us know where all that is?
TERO:
Sure! Everything is on my website, teropa.info, that's my blog. I have the link to my book page in there and I have the link to my Twitter and GitHub and everything on that website.
CHUCK:
Alright! Well, we'll go ahead and wrap up the show. Thank you all for listening. Leave us a review on iTunes. I'll catch you all next week!
[This episode is sponsored by Mad Glory. You’ve been building software for a long time and sometimes it gets a little overwhelming; work piles up, hiring sucks, and it's hard to get projects out the door. Check out Mad Glory. They are a small shop with experience shipping big products. They're smart, dedicated, will augment your team, and work as hard as you do. Find them online at madglory.com or on Twitter at @madglory.]
[Hosting and bandwidth provided by The Blue Box Group. Check them out at bluebox.net]
[Bandwidth for this segment is provided by Cache Fly, the world’s fastest CDN. Deliver your content fast with Cache Fly. Visit cachefly.com to learn more.]
[Do you wanna have conversations with the Adventures in Angular crew and their guests? Do you wanna support the show? Now you can. Go to adventuresinangular.com/forum and sign up today!]