The crew talks AngularFire with David East and Kato Wulf.

Special Guests: David East and Kato Wulf.

 

I part time as a CSI audio analyst and I can say for sure that you're in a rodeo.

What?

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

Hello.

Lukas Reubbelke.

Hello.

John Papa.

Got to keep ‘em separated.

Joe Eames.

Hey there.

I'm Charles Max Wood from devchat.tv. And we have two guests, we have Kato Wulf.

Hello.

And David East.

How's it going?

Do you guys wanna introduce yourself really quickly?

Sure. I'm David East; I'm a Developer Advocate here at FireBase.

And I'm Kato, I'm also a Developer Advocate. I also do support here at FireBase.

I know that some people are familiar with FireBase, but can you just quickly give us a thumbnail sketch of what FireBase is and what it does?

A lot of people think FireBase is this real time database, but we kind of think of ourselves as better way to build apps. And we're really kind of in the business of helping developers create extraordinary experiences, and kind of give their users better experience than what they usually get. So really, it's a way for you to sign up for the service that gives you essentially a real time API, to store and sync your data in real time. So you don’t have to request for your data; it gets pushed down to all the clients whenever something updates.

I think a great point there is that we're really competing in two markets: one is the backend business service; you can use FireBase as your complete backend without setting up any servers, without the need for any sort of hosting. And the other environment we're competing in is real time data; so synchronizing your data, getting it out in a scalable manage thousands of users at once.

Awesome.

If I can just jump in here as a FireBase user is that kind of is the two sweet spots for me; one is not having to set up a backend, so being able to spin up like prototypes really, really quickly. Where we're taking sometimes days, I can do it in minutes because I don’t have to worry about that. It's there. And then the other part is actually doing real time data, where if your interface calls where it makes sense, it's a really easy tool to do real-time stuff as well.

That raises an interesting question about sweet spots, and I think John was the one who really kind of wanted to ask this question, so go for it, john.

I've been involved in a lot of conversations in the last days couple of days oddly, about FireBase and the first thing that usually comes is, “Look at this. It's freakin’ tool. It's really data binding. And I can do this and it does magic toast. And wow, let’s cook some breakfast.”

It makes toasts? Sweet!

Yeah. [Chuckles] But then, “Where am I actually going to use this in the real business application?” And then the second thing after that, the follow up is, “Is this thing secure?”

So David, is that real type toast in the documentation? Did we document that? I thought that was just an Easter egg.

Actually, John, the first thing I ever implemented with FireBase was actually real time Toastr notifications. [Laughter]

Oh, cool. So you are using ToasterJS? Awesome.

Yeah.

So back to the topic, I mean one of the best ways to find out what FireBase is useful for is to look at our customer page, to sort of see what our current customers are using it for. So for example, we have Twitch who was using it for a lot of their chat applications when they are doing their live streaming. CBS is using us for a huge application when they do their Big Brother series. They recently logged somewhere around 600,000 concurrent users all at once in their chat.

Can I just interject, “Holy crap.” [Laughter]

Another great example is Roll20, which is a worldwide table top gaming system. They use FireBase for pretty much everything, synchronizing user groups; they have maps on there with real-time tokens on them, and calculations for rolling dice in virtual space so everybody can see them. The tad applications, the sort of lobby rooms where you go in to find groups and join them and all that stuff is coming through FireBase.

And we have a real time drawing app. Citrix is using us for their Talkboard App, which does a real time drawing, almost like virtual white boards. And another great application for FireBase is code collaboration; so we have tools like Nitrous.IO, Kobra.IO and CoderPad, who use us for online code collaboration and you can actually edit the same document at the same time, do tutorial, teaching or job interviews, things like that.

So just to make sure we're clear on what FireBase does and what it's sweet spot is, are those people using that for collaboration documents that aren’t persistent? Meaning it's going to let them share a collaborate and then once you were able to persist it, use another database backend type thing or are you using them to actually persist them between sessions as well?

That’s actually one of the cool things about FireBase is a lot of people we compete with in the real time space, either do persistence well or they do their real time aspect well. Where FireBase is real-time and persistent, and it's also based on state model, so you're synchronizing the state of data versus the message queue model where you're just transferring events and making the client sort of figure out how to compile those and deal with it, merge all the conflicts.

So the answer is yes? [Laughter]

Yes.

Got it.

So you named a couple of pretty interesting places where Angular really hits the sweet spot. We had a conversation yesterday via JavaScript Jabber, it was about Backend As a Service and one of the themes and topics that came up there is, “Is backend as a service going to become as dominant and ubiquitous as platform as a service?” What do you guys think of that? And if so, where do you think FireBase is going to fit in that space, and where it might go from where it's at right now?

I think that FireBase is such an amazing backend. One of the reasons I got involved in FireBase when I first started (using it as a user before I became an employee), was because I wanted to scale up an app with two people for writers. It was a pretty ambitious project. And we went through a lot of different backend options, hosting stuff on Heroku, working with different libraries to try and cut down on the amount of the rest APIs and things like that we needed to build. And when I found FireBase, I called up my partner, my cofounder and said, “We don’t have to worry about the backend anymore.” And he said, “Great.” And that was that. We just wrote the app and that was the end of the story.

So I really feel like backend as a service is not only going to be ubiquitous and pretty much the way to go in the future, but I think that there are some ground to be laid on how that’s going to work, and what the ideal model is. And I think what FireBase is offering is really and truly a better way to scale and build apps. And we're sort of forging that groundwork.

So I think we've kind of talked about the sweet spot and I really like the direction that things are heading. The question I run into is security. We've brought this up a few times.

Yes. So FireBase uses declarative security rules. And one of the amazing things about this is that they are not in your code. You don’t have to hide your code behind a server or you don’t need it behind a firewall to make sure everything is secure. Basically, you lay out the ground work: “You can access this data if you are logged in, if you follow these rules, and if the data happens to be a string that’s less than 100 characters, you can write to this field.”

So you lay out the data structure, the validation architecture, and the authentication schema that’s required to access the data. And the clients don’t have to worry about that. And you also don’t have to worry about how the client is. If somebody wants to spin a, say a mobile app that connects to your FireBase, it's just this huge API sitting out there, and as long as you follow the rules and commit the security requirements, the data is available to you.

And I think there's a huge advantage to this because of the amount of code you don’t have to write. You still need some basic validation in your client to be responsive. You don’t wanna make server trip everytime somebody enters an invalid data for instance. But you are no longer constrained with sort of dealing with all the aspects of how security is going to be implemented in your code.

How complex can that get? Say for example on HabitRPG, every time you do something, you get a certain amount of experience points, right? Well, it would certainly be easy on the client side to go on there and say, “Hey, whenever you submit, that I'm going to get a certain number of experience points, change that to something else.” Of course, HabitRPG, it would be useless for you to hack it because you could just hack it yourself anyway like clicking buttons a bunch of times, as an example, right? Some kind of validation that says, “Hey, you can’t have a million of these points whenever you do something. There's supposed to be some logic that’s going on in there.” How complex can that be with FireBase?

Right now, you can get pretty complex. I recently wrote some security rules that throttled a number of messages you can post. So you can only post one message every five seconds, make sure they are sequential. We recently did some security rules for a chess game, so that you can enforce who moves first and who moves second. And sort of the turn sequencing and that you can go out of order, get extra turns in the game.

Wow.

You can get pretty good with those. Part of it is a sort of art form between your data structure and your security rules. And when you start to understand how security rules work, structuring the data properly makes the security rules much more powerful. We also have a new tool called the Blaze Compiler, which will allow you to write much more sophisticated security rules that then get compiled into the actual rules language.

How do you write these rules? Is it JavaScript?

It's really just annotations on top of your data structure. So essentially, just JSON, really because your data is JSON.

And inside the rules, they have little basically JavaScript syntax, and then for comparators, contains and regular expressions and things like that.

I was looking inside your documentation on security and I see the JSON structure here. It's not clear to me and I haven’t read the whole thing yet, it's where do you apply this? Is this inside of like a dashboard in FireBase, or inside your code?

Yeah, when you have an account, you go into your dashboard and there's a security rule section, and that’s where you can do editing, and they won’t say that you have any errors in them, so they get all compiled out and saved there.

Cool. So it's not like you're saving your JSON with your… you know, I can just view source in the browser and see it.

Yeah. And you can also edit those programmatically, but you need a special auth tokens to do that with, and then you can upload and write and read them via REST API. So that allows your [unintelligible] build sort of your own build tools on top of that that can modify, maintain your security rules.

Where wouldn’t FireBase [unintelligible]? Everything has got a sweet spot. I think you hit some very key areas, but where isn’t it supposed to be used?

We've had some people try and use it for some interesting use cases. And being in support, I get to hear about all those. And the couple that hadn’t worked well are say log aggregators, where you're just writing millions of records a day from various server’s logs, trying to aggregate those into an admin tool. That hasn’t worked very well because of the huge write throughput and just the huge number of nodes. And we still have some work to do in that area before were going to be a great resource for that sort of tool. Dave, can you think of others?

Yeah, if you need to do a lot of really heavy custom image processing or like any type of really heavy stuff that you're going to have to write like use some type of library for and do a lot of custom stuff. And that’s not going to work best.

That’s interesting point. It's just a matter of bandwidth, right? Like uploading and downloading images in real time, like real-time syncing images, if they fairly big, it's going to be a problem just because of bandwidth.

So you are not doing like Skype type application where you're uploading your video stream for your FireBase to synchronize?

Yeah, that wouldn’t be so great.

[Chuckles] Okay.

Although one of the great things about it is you can use FireBase to control all the metas on that, you know, all the available streams and what's going on the background, and then just do the streaming on the side for another service.

So we talked a lot about FireBase – what about AngularFire? What's that?

So Angular is something not built for us a while back and that’s become my baby over the last year. And so essentially what that is, is a bindings library. Angular of course is pretty famous for their two-way bindings between JavaScript and the DOM. And what AngularFire does is it turns out into a three way binding between your persistence layer which is FireBase, your JavaScript memory variables and the DOM, so that you can basically synchronize stuff right from an input field into the FireBase have it immediately pushed up in a stateful manner to thousands of users.

Is that as cool as it sounds?

It's even cooler.

[Chuckles] It's pretty darn cool. At 1200 lines of code, it's pretty amazing what it can do. And the thing that is not obvious though for people though is that AngularFire is not a reimplementation of say the entire FireBase API for Angular. So it's not just the FireBase API with dollar signs in front it. It's specifically just meant to bind into collections and objects, and to synchronize those. Because we find that’s the majority of what you need to do from the client side.

Let’s talk a little bit about the service itself. It's essentially a database with an API on the front. How exactly is the data stored? It appears to be like key value store? Or you push an object into there?

Yeah, it's JSON, so it's hierarchical key-value store, so you can nest objects within each other, although you probably shouldn’t nest too deeply, but you can do that.

No limits to the nesting, huh?

You can go 32 nodes deep.

Oh, man. Just 32?

Just 32.

One other thing I noticed that’s provided is an authentication user sort of thing. So essentially, you can create user account, or you users can create users accounts and then they can sign in. How do you partition the data once you are in? Or the does the [unintelligible] can just give you general access to the entire thing, and your app is responsible for the data separation?

Those work in tandem with our security rules, so essentially, a user will have an ID and we have a special auth variable within security rules, so you can actually check up against an auth variable when you're writing your security rules and see if it's null. And if it's null, then you know the user isn’t logged in. And if it isn’t nulled, it's going to have information that’s pertinent to the user, so that way you can check to see if their email or if their ID matches what you expect it to be, and you can lock down the data so only that user can do actions on their account or within their group or something like that.

And what's great from there is really all you need is a user id at that point for security rules. And anything else you wanna build off that, you can just put in the FireBase data itself. So if you wanna establish a role structure, like you have say a blog application and you wanna have administrators, supervisors, moderators, you just add something in their user profile that says they are a

moderator and then you can reference that in the security rules as well. So the sky is really the limit there.

I've been playing with AngularFire this morning, one thing that I ran into that I was wondering about was that, it kept calling .REF, and I wasn’t quite sure what that did, so it was setting up some object and then it was calling .REF, but I hadn’t actually created anything.

I'm a little lost on that. You can have like a FireBase reference which is your base, and usually what you do with that is you get an object or an array alphabet. We have a dollar as array, and a dollar as object. And what you get out of that is actually synchronized data, which is automatically synchronized back and forth to FireBase. You can get a reference off of that, which just basically takes you back to the FireBase API, so it takes you back to the SDK level. If you wanna do something more advanced with it, that the bindings aren’t automatically handling it for you.

Generally, you don’t need to drop to the FireBase API level though, because mostly what people need to do with AngularFire is data transformation. So the either one I add something on to the prototype of their objects, so they have a special method they can call like say that gives you a sum from all of your records in an array, or they wanna transform data like dealing with data objects is a pretty common use case there. And we built in to the latest version, the 0.8 version, the extend factory method, that will basically allow you to override methods internally in the synchronized array, so you can control how the get data gets created on the client, and then how it gets saved back to the server. Once you get to that point, I mean, AngularFire becomes a really sophisticated tool that you can write services from.

So if I wanna add a new object, so I call “as object”, or is that just simply look up…

Yeah, I mean you can write directly to FireBase if you already have a reference. One of the things you do when you work with AngularFire is you call new FireBase to get a reference to your FireBase data, and then you pass that into AngularFire. You can always just call setup that if you just wanna create a new object on the fly. If you already have say a synchronized array downloaded, you can just call $add on your synchronized array, and it will push new data into FireBase for you.

And if I call set, is that an AngularFire call that will give me two-way binding, or is it a FireBase call that I need to set up?

Yeah, so when you're working at the [unintelligible] FireBase level, you know, I have a synchronized array or synchronized object, we have some methods on there like set and update, and basically what those do is they call the FireBase SDK and then they take care sort of the cleanup work for you that you need in Angular. So if you have something that’s referencing that data in the DOM. And I'm going to mention the Angular compiler here. I know that a lot of times, when I do that people get really scared.

But if you start working with the Angular compiler, you need to run the digest scope whenever you do an update that’s outside of Angular’s per view, right? So your FireBase updates come in asynchronously, Angular doesn’t know anything about them. You either have to call $timeout or $apply to make all that stuff happen. So what AngularFire does is take care of all that internally so that you don’t have to manage those things and know when the scope needs to be updated, and when the compiler gets to run. So the simple answer to your question is $set just to wrap around the FireBase SDK that also tells Angular to run digest scope.

One of the issues I've been able to take a look at closely lately is unit testing in Angular as a whole and mocking some of the services. Is that there a good testing and mocking stored for AngularFire?

Yeah, AngularFire itself uses a mock I wrote a while back called Mock FireBase, and you can actually read the AngularFire test units [unintelligible] and see sort of how those work together. Mock FireBase is basically a complete implementation of the FireBase API, but it's local. It doesn’t actually make any calls off of the local machine. And it pretends to be asynchronous if you want it to, but one of the really super things about it, is you can use it synchronously, and avoid all of the timing issues and weird stuff that makes the test cases unreliable.

Yeah, I definitely am going to play with that, because I've been writing some stuff for FireBase lately, and I haven’t seen the mocks for that, so I'll keep digging around.

They are great. And one of the nice things is they are built in the sort of Angular framework. So Angular love the .flush on time out, things like that and it uses the similar strategy. So if you are familiar with Angular’s mocks, it will fit right in.

Sweet. So what's the coolest thing you guys have seen somebody use FireBase to create?

The coolest thing I've seen is probably not even like a real app, is are you familiar with Warby Parker. They essentially have this big store up in New York City, and everytime someone orders a pair of glasses in store, they don’t like get it handed to them; they walk up to the register and then they have these pneumatic tubes where they shoot up a bunch of glasses container to you, like something you would see in a [unintelligible] room, and it just hops up in front of you, and how they send those tubes to their customers, they do all that with FireBase.

That’s cool.

It's like real time snail mail delivery.

Yeah, it's pretty cool. One of my coworkers, she's working on a real time Rock ‘Em Sock ‘Em Robots with trying to hook up a Raspberry Pi to Rock ‘Em Sock ‘Em Robots, and get them to fight from your browser.

Oh, you know what you should do with that, is [unintelligible] with a robot thunder dome type thing, and you’ve got everybody in there. [Laughter]

I've got to say that my pick for the coolest thing built with FireBase would have to be the Fruit Tester. Jenny had our company for experiment week project. She hooked up a couple of screws to a vault meter and hooked that up to FireBase to an LED, so that you can actually stab these screws into a piece of fruit and it will tell you what kind of fruit it is in real time on your phone.

Or I can just look at the fruit. [Laughs]

Yeah, she's plugging it in and it's like, “It’s a Strawberry.” [Laughter]

There are some fruits that are difficult to identify.

Kato, you told me about another application the other day that was pretty wonky. Are you allowed to share that?

I can’t think of which one you're telling me.

The video? [unintelligible]

So I'm just going to say it. You can tell me to cut if I'm not allowed to, about how the streaming video over FireBase, using Base 64. Oh, no, no, that was not you, that was Greg Soltis.

Okay.

And he told me about that. Sorry.

Actually, I do know what you are talking about. At FireBase, when you get here in your first week, we get like an experiment week where you get to spend the first couple of days, just making something with FireBase, so really get familiar with the API. And one of our core engineers set up like web RTC and essentially piped all that video streaming through it, and so you could anyone open up their laptop and it was like this big tiles, like 100x100 tiles like everyone like video chatting on one page. It was pretty cool.

Through FireBase?

Yes, through FireBase.

All you FireBase guys look alike to me, so. [Laughter]

I do have one more question and it goes back to the security. It seems like you can have some kind of user login that does the security, but what about if you're just doing like a basic key based authentication. So you essentially pass an API key and it just stores the information generally? What's to keep somebody from popping up a JavaScript console on your chrome dev tools and just using your API to put bogus data in there.

Yeah, that's pretty easy. You don’t even need a simple log in client for that. Essentially, when you give a secret key for your FireBase and you essentially can form that secret key, you generate out tokens that people can use to authenticate. You basically will create a token and you pass that through that client and that person can authenticate and only the person with the token can access anything. And so you can check to see if this person is the one account that can access that, and if it's not that person, it's not going to get anywhere.

Another great option there is anonymous authentication, which would allow you to basically authenticate people without them having to do anything. They don’t have to enter any credentials or anything. It's location based, so you just get a unique key assigned to you and you can utilize that to sort of store data for yourself that nobody else can access.

I love the inherent [unintelligible] more anonymous authentication.

Yeah, it's pretty cool.

Yeah, like I absolutely know that you are somebody who I don’t know.

Exactly.

Which you are a unique individual that I can identify.

That is such a cop out, isn’t it? [Laughter]

“You're unique, you're wonderful. I just don’t care who you are.” [Laughter]

It's a really cool tool because a lot of people have used it to essentially start someone through a check out process and then attach all these data to them. And then at the end, they have to make an account, and then from there they can take all these stuff that’s already essentially stored in their database and they are only writing one record to it, rather than having to upload everything as they go. So it's a pretty fast way to track stuff on somebody and try to sort of bug them to into actually signing up for your service.

Yeah, and we’ve had it used for a few mobile apps where they don’t wanna do authentication, and they just wanna allow everybody to enter their name and be your unique ID and be able to do chat and so on.

Another question we get asked a lot is are we viable? With some of the big players in our industry going at a business recently, people wanna know if we're around to stay. We're super well-funded right now. We have a huge amount of funding coming in and more coming in the next couple of months. So funding is certainly not a problem for us. We're moving fast. We're also growing pretty quickly. I'm guessing we're going to have another 50-100 people on the team here in the next months. And we're also going to, I mean, you can also look at our customer base to see some of the big people who are using us now, so we have enterprise contracts with some big names. And on our customer page, we have some big guys like CBS and Twitch, so we're definitely around to stay.

Good to hear that.

So if you are hiring, you can go ahead and just throw that in now. How do people find out about job opportunities?

We have a jobs page on our website and we're definitely hiring. Always looking for great talent. And we also have jobs@firebase.com. Everybody is welcome to email their resume.

All right, before we get into the picks, Joe, is there any news you wanna share about ng-conf?

We announced the call for papers last week, right?

I think so.

So this week, no new news.

All right. Well, go check out ng-conf, and if you wanna speak, let them know. All right, let’s go ahead and do some picks. Lukas, do you wanna start us off with the picks?

Sure. I just started a new blog post series on building restful Angular web application, and my pick is the LoopBack framework. So I'm not really a backend developer, which is I why I like tools like FireBase. And LoopBack is actually built in kind of with Yeoman to actually generate your rest API. And there's a video on my blog post where I basically [unintelligible] API on 90 seconds with commentary, so really enjoyed working with LoopBack. It's a really good tool such as JavaScript front to back. I really enjoy it.

What about your Angular tip of the week?

I really think that you should decorate the log service to do interesting and useful things. Check out Thomas Burleson’s article on how to do that.

All right, Joe what are your picks?

I'm going to pick a show I listened to off of Audible. It's a BBC radio broadcast show. It's a dramatization called Cabin Pressure. It's a comedy. It has short like 20 minute episodes. I think there is something like six of them that have been put out. It's not very expensive. Just a few bucks to pick up off of Audible. It actually is voiced by several kind of big British authors, kind of which is Benedict Cumberbatch. And it's quite hilarious. It's about an airline and a copilot and his copilot and their crew. It's really funny. I've been enjoying listening to that, getting a big chuckle.

My Angular tip of the day will be to use ngIf, because sometimes, ng show and ng hide just don’t cut it. And ngIf is the answer. Take the DOM element right out of the DOM.

John, what are your picks?

My only pick is going to be Once Upon a Time, I'm a big Disney guy, and I love those kind of stories. And my wife and I have been getting into that TV show and their fourth season just got started. And it's just fun. We get to watch TV together and it's pretty wicked cool. So I love Once Upon a Time, imagine that.

And then my Angular tip is going to be use controllerAs view syntax. Get rid of your scope out of your controller. Use controllerAs. Why? Because, because. [Chuckles] I actually got a lot of reasons why it's great thing. We can actually do a whole show on that. Lot of good stuff in there. It actually isn’t just stylistic; there's things that can help prevent you from falling into traps if you use it. So, good stuff.

I really enjoy Once Upon a Time as well.

My wife is really hooked up on Once Upon a Time.

Yeah, I got to take my kids to a local convention in Orlando last year. They had a lot of the cast from Once Upon a Time, and my kids got to meet some of the members. It was really cool, so that kind of hooked them in.

I've got a pick, it's actually kind of there's a little bit of backstory to it. Basically, we interviewed a fella named Kurt Elster on the Freelancers Show, and he was talking to us about building like small sites you can build in a day kind of thing. And I just thought it sounded like fun, so I built one. It’s up. It’s called TodayIsASuccess.com. That’s the app that I've been playing with FireBase on. It's not using FireBase in production yet, but you can go check it out.

My tip is that when I build the register together with the cookie store to store the data, it's kind of a neat little way of storing data on the client, so check that out.

Kato, what are your picks?

I'm feeling a little rebellious here because I have four picks, and all of you only gave one.

We'll forgive you.

[Chuckles] So the first thing I’d like to suggest is CodingPad.IO. it's an app that actually uses FireBase and does real time collaboration. I've seen it used for interviewing processes and also for working remotely with other coders when you wanna get help or go over some design. A really great app for that, and recently integrated Google Hangouts, so you could do Hangouts right there on your code page while you're editing it. Pretty cool stuff.

I have a couple of picks. I'm going to go a little off the beat and pick some music here, because when I'm having a hard day getting involved with my code, I really love to listen to this band called Two Steps From Hell. And you guys have probably heard of them even if you don’t know their name. You’ve probably heard a lot of their music, because they are kind of like the defacto for all of the epic game and movie trailers that you see on television. Anything that’s got an awesome soundtrack behind it and happen to be a movie trailer probably came from them.

My last pick is a book by Cormac McCarthy which you probably don’t know this, one of my hobbies is stacking Cormac McCarthy. So as a professional writer, I have that privilege of being a stacker without that being too creepy. It's a little creepy. But I do enjoy just really getting after him because he's just an amazing writer. And he wrote a book called The Road, which turned into a TV series a little bit later. I read this review online about this story, it said, “When you read this book, you feel like the only thing keeping the characters alive is you flipping the pages. And if you stop flipping the pages they are going to die.” And I said, “Okay, with a review like that, I'll read it.” And it's every bit true. Amazing book.

David, what are your picks?

My first pick is we just released the chrome extension called Vulcan, and it's actually even cooler than its name. It allows you to look at your FireBase data in your chrome dev tools and so you can see all your data update as you're developing, and it gives you a nice view of the state of your data. So download Vulcan, it's pretty awesome.

The next pick is pretty much as a front end developer, I've done a lot of stuff at Photoshop, but not really actually learning it well, kind of learning things as I go. So one of the things I was really horrible at using was pen tool. And recently, saw this one website called The Bézier Game, and that teaches you how to use the pen tool all in the browser, and it's pretty amazing.

And my last pick, I'm going to give you guys some props. I just recently listened to the JavaScript Jabber episode with Brendan Eich, and that was one of the most interesting things I have ever heard in the tech landscape. And I'll probably make an effort to relisten to it once every couple months or something. It was really awesome.

Yeah, that was a fun episode to record. And we were all like going all fan boy and stuff.

I was geeking out just listening to it.

Yeah, super good episode. All right, thanks for coming guys. And hopefully folks will check out AngularFire and FireBase.

Thank you.

Thanks for having us.

All right. We'll wrap this up, and we'll catch you all next week!