01:52 - Zackary Chapple

02:02 - Performance; Metrics and Analytics

08:23 - Performance in Angular 1 vs Angular 2 Apps

09:43 - Mobile Performance

10:51 - Migration Work from 1 to 2

16:20 - Single-page Apps

21:00 - The RAIL Performance Model 

21:42 - Speed; Efficiency

25:21 - HTTP 1.0/2.0

26:49 - Websockets

27:11 - Mobile Performance Testing

29:20 - Production Monitoring

Picks

Angular 2: Getting Started by Deborah Kurata (Lucas)
Electron (Lukas)
Flyover Country (Jules)
Snapchat (Jules)
#AskGaryVee: One Entrepreneur's Take on Leadership, Social Media, and Self-Awareness by Gary Vaynerchuk (Lukas)
Betterment (Stephen)
Upwork (Chuck)
QuickBooks Online (Chuck)
Crazy Egg (Zack)
Grafana (Zack)

Special Guest: Zack Chapple.

 

Hey everybody and welcome to episode 91 of the Adventures in Angular show. This week on our panel we have Jules Kremer.

Hey.

Lukas Reubbelke.

Yo, yo.

We've got Stephen Fluin who is also hanging with Jules and filling in.

Hey there.

We also have Zack Chapple.

Hey everybody.

Now Zack, do you want to introduce yourself really quickly?

My name's Zack Chapple. I'm an architect here at CareerBuilder, an ng-conf speaker, and I'm also a member of the Angular CLI team.

Very cool. Now, what we have on the docket as far as our calendar goes is performance. So, not Angular CLI. I have to revisit that. Do you want to give us a little bit of background as far as what you've done on performance with Angular?

Yeah, so one of the things I've been working on as part of my ng-conf talk was performance tuning not just around Angular but also for the browser itself, trying to write allocations that are performant but also how to quantify that performance. So, it's really easy to be theoretical about things but when you actually try to measure it that's where the rubber hits the road.

Now, are you talking Angular 1 or Angular 2 or the web in general or where are we at here?

Mostly the web in general and Angular 1. Angular 2, hopefully I'll have some material around that maybe after it's released.

Gotcha.

So, [inaudible] know is really truly, how fast is fast? How do you even quantify that?

And that's one of the hard things to do, is to quantify what is fast. But I think one of my slides said [inaudible], it's that magical feeling that you get when things are just right. And I think that's different for everyone.

With more cow bell, right?

Right. Can you give me some metrics on what you look at? So, I'm thinking of Steve Souders. He has done a lot of really good talks on web performance. I use Sitespeed.io, a Gulp plugin, quite a bit. And so, if I'm doing something in a project it's pretty easy to drop that in as a Gulp plugin. You get a really good dashboard and you're going to have some agreed upon metrics that these are the best practices for performance. But I would love to hear your take from an Angular side what you look at and what you quantify and what those metrics are.

Around the website itself, I tend to use stuff that runs in the browser rather than something that's more of a Gulp plugin. So, I use Perfmap and Performance-Analyser, are the two that I use that plug into Chrome pretty nicely. And those give me metrics around different parts of the page as well as request timings and stuff like that. But I've actually used Batarang quite a bit to do my Angular 1 performance testing. And I had a couple of slides around that, too. And that gave me some good information… sorry, I just got messaged asking to describe those two plugins. They are, one is Perfmap and it's offered by Umar. And that's a Chrome plugin. And the other is Performance-Analyser from Michael Mrowetz. And those two are both Chrome plugins. And then I use Batarang quite a bit for the Angular 1 stuff because it gives watcher counts and digest cycle timings and all that fun stuff.

So, what information do you get out of Perfmap and Performance-Analyser?

A whole boatload of stuff. So, if you pull them up, the nice thing about the Performance-Analyser is it will actually break down how many requests your page has, the domains it's hitting, request for host, time to first byte, all the nitty-gritty performance API stuff that the browser has and you can dig in yourself. But it gives it to you in some nice graphs that make it easier to understand that you could share with people pretty quickly.

Very cool. And Performance-Analyser is kind of the same thing?

Yeah, well that was Performance-Analyser. And then Perfmap gives you timings in a graph on the page that says if you have multiple components on a page or multiple, I don't want to call them portlets but multiple parts of a page, it will tell you which ones are the slow ones. And it gives timings for the low times of those individual components.

Gotcha.

And I think Batarang took some of that and wrapped it for Angular 2 but that's more, it's still a work in progress.

Now, you found, is there a sweet spot in terms of how many watchers you have in a page or how many bindings? I know initially anecdotally it was 10,000 things on a page you could bind to before things started to get a little heavy. And there's actually a demo I did a long time ago, some balls bounding around the screen which became a performance demo of, “Hey, we're going to have these 10,000 balls flying around the screen and nothing really falls apart.” Do you have a sense of when, what that number may be? Or if you were just advising let's say your best friend over a beer, “Hey, you're doing this Angular app? Make sure you keep the watchers under this X number,” what would that be?

So, the magic number that I've seen, at least in the apps I've worked on, is around 5,000. 10,000, it starts to get scary. But then we also had a page that was getting up to the 30 or 40 thousands. And that was particularly noticeable, even for the users. So, if you're not doing too much on the page and you just expect to go look at the data you could even go higher. But if you want to user to actually interact with that data then obviously you want that number to be lower. So, it really depends on what you're trying to achieve. But with Angular there is really no hard rule, right?

So, do you measure… I'm going to go back to Lukas's first question for a minute. So, do you measure all of this by feel? So, it feels fast enough. Or do you actually pull some hard numbers off of this? Like how responsive the backend is or how long it takes before it actually loads up and you can use it. I've heard a lot of metrics here. We actually had a talk at JS Remote Conf about web performance.

And I think that's something that's kind of been missing. A lot of the places use New Relic or Splunk to do analytics around their API timings and how quick the APIs respond. And then there are people who look at the page speed and how fast the page took to render. But the side that they're missing is the interaction side for the user. Just because your API responds in five milliseconds it doesn't mean that that 25 meg response got down to the user in that speed. So, what I started to track, and it was actually really easy to do in Angular, is  how long are the XHR requests taking to come back? How long are the route changes taking to actually resolve and complete? And that's the sweet spot of performance that really matters I guess. If the responses are lazy loaded and all the assets are lazy loaded, you can get away with a lot of things. But if the user's navigation throughout the app is slow that's where it really hurts.

Hey Zack.

Yes, Jules.

Hey, I have a question maybe going a slightly different direction. So, I know that you had written a lot of lines of code in Angular 1, written some fairly large apps. But I also happen to know from personal experience with you that you've delved into Angular 2 and you've started working on big apps with Angular 2. So, I'm curious how your experience with evaluating performance is different between writing Angular 1 apps and Angular 2 apps.

It's been a little bit harder initially with Angular 2 simple because some of the stuff that I was using to measure wasn't there yet. So, especially the hooks I was working on with the router were not available in the new router yet. I was able to hack those in or I'd say monkey-patch those in and get it going again. But it wasn't quite the same because the component router behaves differently than we were using UI router in that other application. So, they behaved differently. So, it's not really an apples-to-apples comparison. And at the same time, watchers are gone, right? So, you have to completely change how you're measuring things. So, I'm looking to leverage zones quite a bit more when it comes to that. But I'm kind of waiting for things to land a little bit before I start reworking the library that I wrote to do a lot of this for me into an Angular 2 centric methodology.

Cool.

So, let's say that I have an application and I pull it up on my laptop. And it's fast. It's good. And then I pull it up on my phone and it's show and it's terrible. How do you start figuring that out?

And that's where a lot of the stats and even Benchpress have some room for growth. Because Benchpress, which I think Igor worked on quite a bit, tests the speed of a component itself in isolation. But like you said, you have no visibility into the user's actual experience. So, that's where having those hooks into the app itself, and actual production usage comes into play. Because then you could start to look at the user's bandwidth. You could start to look at the render times and the component resolve times and actually figure out how fast the app is working in reality. And that's one of the other cool things that you could actually test because the performance API gives you all the information you need to get the user's bandwidth. So, that also gives you opportunities to tweak the experience to their bandwidth.

Hey Zack, I know that the topic was on performance. But I think one of the things that are interesting about you in particular and I'm fortunate to have had some days in a room with you, is that you are one of the first people who really embraced taking a large Angular 1 application and moving it to Angular 2. so, aside from just performance I wonder if you again as Lukas said were over beers with a friend – and I hope it's really good beer because otherwise I will judge you harshly – I'm wondering…

So, no PBR.

No. No, PBR. Although I just got a canned beer for the first time in years last night. I haven't tried it yet. But they told me it's a great way to bring beer on big long hikes because then you can just smash down the can. So, I'm pretty excited to try it.

Nice.

But anyway, my question was more to bring you to, because I think one of the things that you can give to our listeners is that experience you've had in doing a little bit of upgrade and migration work from 1 to 2.

Yeah. So, as you can imagine, that application upgrade was, actually it's still in progress. It is quite an undertaking. It was over a quarter million lines of code and worked on by 80-some odd developers for one frontend application. And I guess the easiest way to start with that was actually with the CLI, because that gave us the patterns and it gave us all the infrastructure. So, we didn't really have to think about how to set up the application. So, we took the CLI and used that to create out components and to create a base app. And then we started working that back into our existing app and tweaking it to work. And eventually the entire app would then get refactored into the CLI. So, upgrades would be easier in the future. But that was our initial starting point. And we made sure that all of the files were fitting the patterns that we wanted to have in terms of structure and style guide.

But, one of the things you have to keep in mind too is you can't, especially in big apps you can't just do a big bang approach. You have to figure out what your leaves are and then start from there. So, we went through and figured out what components we could do first. And actually, one of the things that we had our other developers working on in the meantime was moving to the 1.5 components. That way when we refactor them to the Angular 2 components it's just a step closer.

And some groups were actually taking it so far as to moving them to TypeScript Angular 1.5

components. And then that made again the conversion even easier.

So, just to be clear you have a big app that you're converting from Angular 1 to Angular 2. Are you converting it now to Angular 2 or are you waiting for it to come out of beta?

It's already in progress. And some parts should be in production shortly. And the other parts will hit as they're completing development. I don't think we're going to wait for production to flip that switch because we have enough confidence in the Angular team and there's been enough communication with the Angular team that we're very confident with what they're doing. That level of trust is something that I think the team has earned. And I believe in that wholeheartedly.

Yeah, I guess my hesitation just comes from the fact that since it is still in beta there are probably still pieces that are a little bit in flux. It seems like they've pretty well stabilized on the API so it should be a safe bet. But there's a little part of me that hesitates just a little bit just because it still has that beta flag on it.

When you lock down versions of the stuff you could push and give yourself time to refactor, right?

Yeah, that's true.

Because you're not going to have an npm install with a tilde or a carat in production. You're going to lock down those versions. And once you get to that point, you really don't have to worry about it, right? Because it's just the code going forward and you have time if you're following agile development to take a step back and refactor. And that's one of the advantages of the CLI is it generates stuff in the correct pattern and correct structure. So, as updates to the style guide come and the CLI updates, you'll be able to see those changes and then respond accordingly.

So, maybe bringing it back to performance a little bit, one of the design goals of Angular 2 is to dramatically improve performance. Do you have any initial results? I know you mentioned your benchmarking tools haven't caught up yet. But just in terms of some of the user experiences that you're building as well as what you're seeing in the Chrome Dev Tools, any initial development there?

Because the apps are so large, they're not all in Angular 2. So, there is actually, I hate to say this, a slight degradation in performance simply because you're running both simultaneously. There's more weight on the browser in terms of download size. But as the Angular 1 stuff gets pulled out we expect performance to increase quite a bit, because we're not pulling down both frameworks simultaneously. So, short answer is no, I haven't had a chance to see that yet. Long answer is, we know it's coming. And that's a tough topic, too.

Yeah.

It is a tough topic to keep the momentum going, especially given some of the changes to the tooling too.

Right.

Yeah.

And that's one thing I'm hoping will keep up. And I've tried to communicate with those groups as much as possible saying, “Hey, I'd really like to have the performance tuning stuff back into Batarang.” And I think I opened an issue on GitHub for that because they didn't put it in the Angular 2 version. And it's something that they're going to try to get into it. But they just haven't had time to yet.

Are you working with them on trying to implement that? I know you do a bunch of open source contributions.

Yeah. I offered to help on that and they said that they're actually… something on the road map already so they're going to try and tackle it.

Cool.

So, one other question that I'm wondering about a little bit here is a lot of people are going towards single-page apps. And I hear all kinds of advice from people as far as getting that initial load time down. And so, what they usually… I've heard both ends. Load as much of it as you can into Angular or whatever your frontend framework is and then just get a skeleton loaded so that it loads really, really fast from the backend. And then it can get what it needs to fill in the blanks as it goes on the frontend. And then I've heard other people say yeah, but then you don't have a functional page until it makes five more requests to get more data or even just one more request that says give me all the data I need for the first renderer. Where do you come down on that for performance? Does it make more sense to side-load everything from the API and then just give people a framework page? Or do you do it the other way and load all the information in and then make the page come to live as you load the behaviors from Angular?

So, I've actually seen all those approaches. And it really depends on what the experience you're trying to go for is. So, one of the ways the application I worked on when I came out to see Jules, they pulled down the vast majority of things on actually the login page. Then anything that was missing would get lazy loaded as needed and they used ocLazyLoad. And that helped a little bit with the size. But the same time, it just felt like it was still too large because it had to pull down a lot of stuff that there weren't able to lazy load like filters and a lot of the directives they wanted to still pull in because they had no idea when they might be leveraged. So, you had to pull it all in.

I've seen people try to do some of that on the server in Angular 1 where they inline stuff on the server and then cache it. That actually I kind of like, and it leans more towards the Angular Universal pattern that's coming out where you can start compiling things and caching them on the server side. And I think that's going to help performance quite a bit. And I really look forward to actually starting to use that. But at the same time you don't want to have too big of that first hit. So, you don't want to have a five meg page you inlined the world and sent it down if the user doesn't have the bandwidth to handle that. And if they're not going to see any of that in the initial page view like the login or whatever, there's really no reason to do that. You should be able to just send in the simplest thing possible and then progressively load through web workers or whatever the rest of your content. And that's…

So, you just put up some spinners and say, “Hey, the rest of this is coming?”

Well, hopefully you don't need to do that because login, that takes a period of time. You should be able to intelligently know what the next logical step is. And because you're doing analytics on your user and tracking of your users you know, logically my users go from page A to page B so I could start lazy loading page B while they're on page A. if they happened to go to C instead then maybe you have to throw up a spinner because you haven't got there yet. But if you start tracking your users' behavior and the path through the application, you can begin to lazy load in that order.

That's actually really interesting. Because I think a lot of times we don't think about the analytical part of this and we just, “Okay, well what's the technical solution to this?” as opposed to “Well, let's gather some information and then intelligently choose what we do and what we don't do for performance.”

Yeah, that was actually one of my series of favorite slides as part of the ng-conf talk was we as developers, we imagine that we're creating the yellow brick road, right? And then what we kind of end up hoping for at the end of the day is more like Dora the Explorer where you can  go to these magical places and there are multiple ways to get there. You kind of have to find your route. But at the end what we usually end up with is a bowl of spaghetti and we're trying to hop from meatball to meatball. And what we really need to do is understand which meatballs they're trying to get to and at least try to make that trip a little bit shorter.

[Chuckles] Those analogies were really funny. [Laughter]

I know, right?

The analogy that I would create is you could pave a rode straight from Salt Lake City to Los Angeles but you'd wind up paving a road through a whole lot of nothing and people would probably detour to Las Vegas anyway. So, why not build the highway to Las Vegas and then to Los Angeles?

I guess you like Vegas.

Not particularly but that's the way the highway actually goes. [Chuckles]

Just wait for the Hyperloop.

Exactly.

So, there are a lot of different ways of thinking and talking about performance. We've touched on a bunch of them in terms of page load time, responsiveness. So, Google actually has a framework for modeling that they call RAIL which looks at Response, Animation, Idle, Load. How do you think about performance? Are there different component that are more important to you?

So, I think the time to first interaction is what I consider one of the key things around performance. When can a user actually do something on my page? And the performance API built into the browser actually has that. So, that's something that I try to leverage as much as possible. I actually haven't seen RAIL yet. I'm actually going to take a peek at that after this.

Yeah, I dropped a link in the chat for the show notes. So, can performance… when we talk about performance we're usually talking about speed. And so, if you have too many different objects in memory that you have to sort through or page through or whatever, iterate over, then a lot of times that can cause some slow-downs. I think the classic performance in Angular 1, we start talking about watchers and how many watchers do you have? And how long does it take for everything to update itself and go through that loop as many times as it has to? But can you also for example have memory problems that slow things down? In other words, I remember when I was doing lowlevel programming, operational/operating systems type programming you'd actually have to page out memory and stuff like that. Do you run into that kind of thing where you hit up against a memory barrier with your applications and have to deal with that?

On one of our pages that would get into the 40, 50 thousand watchers and the [inaudible] I think that's what was happening. But it was really hard to track down because the page would just stop responding. And so, it was really hard to actually test. But we did figure out how to cut those watchers down. That did drop that memory pressure. At least that's what I'm assuming it was. Chrome is actually one of the few browsers that implemented the memory part of the user timing, user performance API. So, they're the only ones that support that right now. And that is something that you can track, the JavaScript heap size. And you can see how much of that's being used. But with Chrome being the only one to support it, it's not the easiest thing to use to profile your app.

But I actually want to agree but disagree with the statement about speed is the only thing that comes to mind with performance. Because I think efficiency is also the other thing that we should look at, because like I was joking about Dora the Explorer. Performance is great if you have a fast and snappy app. But if you have to have 20 clicks to get to something valuable, that's not efficient. So, that also degrades performance but not in the way that you would usually expect. So, trying to optimize things to come down fast to the browser is one thing, but optimize things in such a way that your user gets to the value quickest I think is something that we need to really pay attention to.

So, what you're saying is instead of focusing just on how quickly can I get the data into the page, how quickly can I actually serialize the information from the data so that people can do stuff with it?

Or deserialize it.

Right. How quick can the user get to the data and how quick can the user get value out of the data, right? Because if I got to click through three accordions and four tabs to get to something I actually want to see, it doesn't matter how fast your page is because it's inefficient. And therefore it feels slow because it's cumbersome.

Okay.

So, performance is about experience as well?

Correct.

At this point you're not optimizing then for the computer's time. You're actually optimizing for the user's time.

Right, because that's who we're really trying to target at the end, right? We're not servicing and we're not building things for computers. We're building them for people. And we need to take that interaction into effect.

No, no, no. we're building for computers.

People are just [inaudible]. [Chuckles]

Hey, I for one welcome our robot overlords.

Ah.

I'm very disappointed I didn't get to get in one of the self-driving cars while I was out there. So, maybe on the next trip we'll have to do that.

Well, we were just fortunate to have the Angular team lunch in which we also had these Ludicrous versus Insane tests slo-mo'd race off on the way back.

That sounds safe.

Well, self-driving. They stopped. [Inaudible]

That's true. You know, one of the things we missed is the whole conversations around HTTP 1, part 1 versus 2. And that might be something we've…

Yeah, I keep hearing that. But I…

I keep hearing like, “It's going to make it better because of this and that,” but are we ever actually going to get there?

Well, a lot of… the browsers already support it. And there are pages already using it. It's been kind of held up by the CDNs and the people actually deploying the apps, right?

Okay.

So, if you deploy your app in a way that supports HTTP 2 and your CDNs support it then you can actually start leveraging some of it for the users who happen to be on a browser that supports it. But an interesting thing is Akamai put out a really cool demo that shows the difference between HTTP 1.1 and 2 and it's something that I put inside my PowerPoint for this pre-ng-conf. But it's really dramatic when you look at how much faster the app can come down when you don't have to worry about the waterfall effect of you can only pull down five to ten assets at a time. And it also allows you to be more granular with how your app is broken up. So, then you can cache at the file level rather than having to cache at a bundle level. So then, if you make changes you can only bust the cache on one part of your app and the rest of it stays cached. So, that helps performance as well. So, you lose the bundles but you're not really losing anything because it comes down just as fast if not faster.

And then along similar lines, what about WebSockets? Are you using any sort of WebSockets for performance reasons?

I will with Angular 2. With Angular 1 I didn't have to because we just used what was available to us. But we're going to turn it on with Angular 2 and leverage what's natively available. I don't foresee writing any manually. I'm just going to use what comes with Angular 2.

One of the things Zack that you haven't talked about really is how the performance testing you do impacts mobile. And so, I'm curious if you have any experience there.

So, with mobile one of the things that we often forget is it's not just the difference in screen size. A lot of times it's the difference in bandwidth. So, part of our performance testing is finding out what resolution the user's at that's well and good and allows us to do responsive design and we can progressively load images, right? But the other thing to be cognizant of is the user's bandwidth. And once we started testing that it was interesting to see that if a user's on Wi-Fi hey, we can send down bigger things than if they're on 3G. And once you have that information it becomes extremely powerful. Because then you can start to not just lazy load but just stop loading or not load something. Why send down a 4K image to someone who's on a phone that could handle it but doesn't have the bandwidth to handle it? So, just because it would look pretty doesn't mean that you should send it down.

Is that the only thing though? How does the fact that your phone usually doesn't have the computing power of your computer affect things?

Well, you can start to do some of that. But a lot of the apps that we're actually working on are… at least the ones I've been working on are not big data apps in the sense that I'm looking at proteins folding and stuff, right? I'm looking at somewhat more simplistic data. And the phones these days can handle it. I have an iPhone 6 Plus and most people around me have S6's and stuff. So, the phones can handle it in terms of that. But like what you're saying though, we can scale it back for performance because you can watch the digest time, at least in Angular 1. One of the things that I found it useful to send back was not just the count of watchers but also how long the digest cycles took. So, once you have that information you can start to scale things back and maybe do some heavier restriction on how much data you send down. But then you start to possibly cause other issues because the user is having to make more requests, which can slow things down. So, it really depends on how you want your app to behave.

One other question I have is that it's one thing to monitor performance say in development or on staging. But how do you actually keep track of it on production? Do you have some kind of instrumentation that you install there as well? Or…

So, I wrote a small library. I called it Heimdallr which that was fun because he watches over everything. And I used that to monitor applications in production. And it basically will just send those stats up to any arbitrary URL and allow you to do stats on it or do tuning on it. That proved pretty useful because it gave us a good chunk of information on how the app is actually behaving. There's a lot of room for growth in that in terms of how to leverage that data. But until you have the data you can't really decide what you want to do with it. So, that's the best way to do that. Because you can hook into all kinds of different things, at least in the 1.5 world. You're able to hook into the digest cycle and the watchers and be able to start tracking that. With Angular 2 I think it will be also easy. I just need to do some tweaks to accommodate for the changes [inaudible] and stuff.

Alright, let's do some picks. Lukas, do you have some picks for us?

Sure, I do have some picks. My pick this week is actually Deborah Kurata did an Angular 2 Getting Started course on Pluralsight that I checked out last week. And I thought it was actually really quite well done. And I was really impressed with just the overall production value and the material and the content. I thought it was really, really quite good. So, big thumbs up to Deborah for putting out a great Angular 2 course on Pluralsight. And that is my pick one.

Pick two is I'm doing an Electron workshop at ng-conf. And Electron is just amazing. So, you basically take any kind of web app and you can just wrap it in Electron and now you have a desktop app. And I think everybody should Electron all the things. And those are my picks for the week.

And just for a note, Deborah is also going to be at ng-conf speaking and she's awesome. So, [inaudible] check it out.

You should get a link in the show notes to the episode we had with her as well.

And if you're at ng-conf and you see Deborah, please give her a high five for being awesome.

Yeah. We are definitely coming up on ng-conf, aren't we?

Yes, we are.

Alright. While we're on the topic I guess I'll bring this up. We are going to be doing a meetup on the 5th. I don't have a location yet. If you go to AdventuresInAngular.com and sign up for the mailing list, I'm definitely going to be sending out an email letting you know where to go, where to meet up. It'll be close to the conference venue. And I shouldn't have any trouble lining that up since I'm actually here in Salt Lake. So, keep an eye out for that and we'll try and get the information posted in the show notes before the show comes out. But yeah, it'll be on the 5th. It'll be right after the last talk and we'll just miss the first little bit of the game night that night.

Jules, do you have some picks for us?

I do, but first let me update on my pick from last week.

Oh yeah.

So, remember last week?

My pick was ThingsOrganizedNeatly.Tumblr.com. And so yes, we did in fact try to recreate the lucky charms organization. However, please not that once you touch about 10 lucky charms, your fingers end up completely saturated in stickiness. And so, we never succeeded. But it was a really valiant attempt.

My picks this week are two. So first, most of you or some of you probably know that I actually live in Southern California but I work here in Angular's Mountain View headquarters. So, I am on a plane every Monday and every Wednesday. And I fly a little tiny airplane, seven-seater. And so, we fly a little bit low to the ground. And one of the things I'm always trying to figure out is what's underneath me. I'm afraid of flying so I spend the whole time looking out the window. And a new app came out this week called Flyover Country. And you can get it on iPhone and on Android apps. And I've been using it and it's freaking awesome if you're flying because it basically uses your GPS and it will tell you what's on the ground underneath of you. Not only will it tell you things like river names and mountain range names, but it will also tell you how old the sediment is that's underneath the view. And it's kind of weird to pull up your phone and all of a sudden see that there's 66 million year old sediment that you're flying over. It's a really cool app if you fly a lot. I highly recommend it.

And my second pick is Snapchat. And really important because we're actually going to get an ngconf filter for Snapchat courtesy of Tracy Lee. And I really thought I was old because I couldn't understand how to use Snapchat. So, I had to get my 15-year-old daughter to give me a lesson over the weekend. She's not a great teacher but I think I finally figured out at least how to do basic activity on it. So, Snapchat. We're going to be snapchatting at ng-conf.

Ooh, I want to jump in. I'm sorry. Don't get mad. I have another pick. Can I go? Is it cool?

Yes, you can go. [Chuckles]

Lukas.

So, I just finished actually the book 'Ask Gary Vee' by Gary Vaynerchuk who's one of my favorite web guru marketing personalities. And he spends a lot of time talking about Snapchat and how it's really going to be the social media platform of the future, especially among teenagers. And really some interesting things. But 'Ask Gary Vee', that book is phenomenal. And if you even have an ounce of entrepreneurial spirit and hustle in your bones, go check that book out. Everything he says is amazing but this is easily his best book yet.

Yeah, we should see if we can, since we're a big show now, we should see if we can get Gary Vee to come on for a bonus episode and tell us all how to use Snapchat.

I will, I'll reach out to him.

Okay. Yeah.

And see if he can come on the show.

Yeah. Awesome.

Okay.

Stephen, do you have some picks for us?

So, my pick would be Betterment. It's a service I just started trying out. I'm trying to actually get some control of my investments and 401Ks and things like that.

What is it? A website or a service? What is it?

Oh. Yeah, so Betterment is a book. It's got a website and an app. The idea is that you tell it how you want to invest or basically what level of risk you want. And then it automatically puts you into those categories and buckets. And then you theoretically never need to look at it. Because I'm a big fan of the idea that savings of any kind are best kind of forgotten.

Okay, I'm going to check back in with you in five years and see how that ignorance of where your investment is, is going.

Sounds good.

That is one heck of an Adventures in Angular follow-up right there. [Laughter]

Five years.

Where are they now?

That's right.

We might be on Angular 6 by then or something like that.

Yup.

We need a [inaudible] in five years.

Yeah.

[Inaudible] too.

Alright. I've got a couple of picks I'm going to throw out there. The first one, so I changed a few things. I'm still changing a few things with DevChat.tv and other aspects of the business that I've got going on over here. And I have to say that first of all I am addicted to Upwork now for getting crap done. You can find people at pretty much every range of price and experience you want. So for example, I just listed a job for some data entry and I'll get somebody, it doesn't have to be too terribly talented, can log into WordPress and enter stuff. But I've also hired a bookkeeper off of Upwork. She is not a couple of dollars an hour. She is also very talented and has done a terrific job for me. So, it's worked out really nicely. Also, our transcriptionists, if you're interested, are all hired on Upwork. So, super awesome stuff there. And I really just, really like the service. You sometimes have to be a little bit discerning about who you hire. But it's worked out really nicely.

The other pick I have besides Upwork and the fact that I did find a really awesome bookkeeper that has made me very happy with the way this has all gone is QuickBooks Online. I tried it several years ago and I just was totally lost with it. And maybe this time my experience is better because I can just go ask my bookkeeper what's going on and she just tells me. Okay, click here, click here, click here. Okay, this is what you need to review. [Chuckles] And then yeah, then I look at it and we get it all fixed up right. Anyway, QuickBooks Online is my other pick. And I'm really liking it.

Also on the avenue of Upwork I put up a job for video editors to see who I could get to edit the conference videos for the remote conferences and stuff. And interesting enough, I got 30 people that bid on the job and they all bid under 20 dollars for each video. So, I'm just trying them out. I

hired 8 of them because I figured that was worth it to me to find somebody that I then had something I could pull out and say, “Yeah, I want the person who did this because it's awesome.” So anyway, really enjoying that.

So, those are my picks. Zack, what are your picks?

So, I have two as well, one of which is Crazy Egg. And that's actually something I love using to track user interactions and find out what people are actually doing on the application as well as just to provide another dataset.

And the other is Grafana. And Grafana is a beautiful charting library that I'm using to track the analytics for everything from Google Analytics to the custom stuff that I'm sending up to Splunk. And I'm pulling it all into one dashboard and that uses Grafana. So, those are fantastic tools and I use them quite a bit.

Very cool. Well, we'll go ahead and start wrapping up this show. Say hi to all the folks at CareerBuilder for me.

I will.

We'll wrap this up and we'll catch you all next week or at ng-conf.