You all got your swag bags? You got your swag bags, you see it? Did you get the t-shirt? It's cool, it's a little, it's the, it's the Tomster hang gliding.

Although I was looking at it, Leah, he looks a little orange. Is he hitting the tanning booth? I didn't realize that the JS in Ember JS stood for Jersey Shore. Thank you, I'll be here all night, please tip your waiters and waitresses, thank you, enjoy the show.

So I think before Yehuda and I dive into the keynote, we just wanted to mention briefly something I think that we maybe have not taken as seriously as we should have, but we need to say, especially now that we realize just how big the community is, which

is that we really, really want to create a community that is inclusive and welcoming for everyone. So, Yehuda, maybe you can give us the rules that you would like everyone to abide by while you're here. And when we're interacting online in IRC, on GitHub, everywhere, meetups.

So in general, the basic idea here is that you want to make people feel included, which means that people do not feel like they're left out. And I think many people, hopefully, maybe probably everybody, not hopefully, but probably everybody, has at some point experienced something where they were in a room and either by virtue of their gender or minority status or simply because they don't drink alcohol or something,

there was a group of people talking about something and they felt like, oh my god, why am I here, how can I get out of here as quickly as I possibly can. So I grew up as a religious Jew and I definitely experienced cases where I was talking to somebody and rapidly I realized I don't want to be here anymore. And I think that feeling, hopefully people can try to remember when they may

have experienced that, that feeling is basically what it feels like to not be included. And I think in general, we want to make sure that people feel included. And in general, what this means is if you're saying something and you think it might make someone feel uncomfortable or like they don't belong or like they are in, like they might want to get out of there as quickly as possible, that bad feeling, you should not do that.

I think everyone can agree with that. But there's a couple of tactics that we need to use to actually succeed at this. So number one, if someone says to you that you are doing something that is making them uncomfortable, don't argue with them, just stop.

And the other half of that, now that everyone knows that the thing to do is just stop, hopefully if you feel uncomfortable, you will know that you can safely tell someone that you're feeling uncomfortable and that you will not get an argument from them. Because I've just told you, just stop. And then sort of further on is if you are in a room with

friends and you see that your friends are saying something that may make someone uncomfortable, I think everybody, it's well understood that if someone is saying something racist, you say, that is not okay, don't do that. There are many other things that make people feel uncomfortable. If you see your friends doing something uncomfortable, help them out. They probably don't mean to be making people uncomfortable, tell them to stop.

And then I think the final piece of all of this is assume that people are basically good. Assume that people are doing their best to be nice people, that if someone is making someone uncomfortable, they're probably not doing it on purpose or out of malice. They're probably making a mistake. They may be ignorant about the fact that the thing is making someone uncomfortable in the first place. So when you see somebody doing something that makes someone uncomfortable and you want to help them out,

start by assuming that they're a good person, that they're just making a mistake. They're just doing something that if they knew, they might regret what they're doing if they knew that it was making someone feel out of place. So I think that piece really, I think Tom and I realized recently, is really important and often missing in this conversation.

I think people often don't feel like it's, they don't want to step up and say, hey, you're making someone uncomfortable because it doesn't feel like you're helping out your friend. It feels like you're about to screw your friend. And I think we need to make sure that in our community, it's okay to tell someone, hey, you're making a mistake, hey, you're making someone uncomfortable without people assuming malicious intent, without people assuming malice.

So really assume, try to assume that people are generally good, people are complicated, people have a lot of contacts that you may not be aware of, but make sure that people don't make people feel uncomfortable. Make sure people feel included. And if at any time, not just here, but at any time something happens and you don't feel comfortable talking to that person,

please come talk to us, we will help you. So please don't ever feel like you're not going to be listened to because we will listen. So, thank you. Now that that heavy topic is... Okay, yeah, hopefully that's a good way to warm things up.

Okay, so, keynote. EmberConf 2014, holy crap, this is really amazing. I used to say crap, I feel like something's wrong. Oh, sorry. Holy fiddlesticks. This is huge, this is a huge group of people and this is awesome to see. So, as Leah said, last year we did EmberCamp, that was only 150 people, it was much, much smaller than this.

This year we have over 400 people and it sold out insanely quickly, so our apologies to everyone that's watching this later who did not get a ticket. We'll try to get more people next year, I guess. Running a big conference like this is really, really hard and Leah and Kate have both been busting their butts for the last many, many weeks to make this happen,

so if we just start by giving them a round of applause. It is, thank you. It is really inspiring to work with such awesome ladies, such effective ladies, so thank you very much. And the Ember community has grown insanely in the last year.

Don't worry, there's actually two slides. There's two slides. The USPTO. The USPTO, yes, thanks to Edward Snowden, we actually know that NSA in prison was all an Ember app. So that feels really good.

But the point is, we've got some really big companies betting on our technology. We're all here because we believe in Ember, and that is a really, really cool thing. There was a time when the JavaScript community really didn't believe in abstraction in any form. Promises were controversial, and it's really awesome to see that we actually have a community here that believes in working on really hard problems.

So a year ago, when we came on this stage, we talked about Ember 1.0, we announced Ember 1.0 RC. This was in March a year ago. You probably remember that we didn't actually ship Ember 1.0 final until September, so there was a long period of time. And the reason why that happened was that one of the other things we said last year

is that we really are committed to Ember 1.0, post-1.0 semantic versioning. So not trying not to break, but being serious about not breaking compatibility after 1.0. And I think this is something that we feel very strongly about, and something that I think we have been rather effective at, about taking seriously, not just willy-nilly making a breaking change just because we can.

We know that just telling you that something is broken does not necessarily help your app when you have to fix it. And another thing that we did, sort of right after we shipped 1.0, I had this crazy idea that if Chrome could do a six-week release process, surely a JavaScript library could do a six-week release process.

And developers, it turns out, really like this. I think people like the stability of the six-week release process, the predictability of knowing what features are stable and what features are unstable, the ability to use new features when you opt into it, and just the dedication to backwards compatibility that comes from the lockstep process. The thing about the crazy idea is that it required a lot of automation.

So I want to shout out Robert Jackson, who did a lot of the automation work. I mean, you don't want to necessarily... You don't want to have to make all this a manual process every time. Every new feature is a huge manual process. So getting to the point where people can contribute new features

in a way that fits in with the release process, and every six weeks we roll out a bunch of new features, has been really amazing. It's something that I've dreamed of as an open-source developer for a long time, and something that as a core team member who now basically can dedicate my energy to looking at new features as opposed to all the process. It's been really great. So thank you, Robert.

So another thing that we said a year ago at EmberCamp was, hey, we're probably going to make good docs at some point here. And so tweets like this are really awesome to see. The community, Trek in particular, and everyone helping out Trek, has done an insanely good job making the docs better. I think that of all the JavaScript libraries out there,

our documentation is some of the best. The response now isn't, oh, Ember has really terrible docs, it's Ember has really good docs. We're always improving, and I would like to thank everyone that contributed. It was truly a community effort. If you are new to Ember or new to contributing to Ember, one, you should come see Robert's talk later, which is about how to start contributing.

But documentation is a great way. Even if you don't want to write the documentation, just let us know where the holes are. Let us know where the quality is not up to the standards that you would expect out of us, and that's a great way to just jump in and get started. We consider confusing docs a bug, so feel free to file a bug if there's confusing docs. The other thing that Yehuda at last year's EmberCamp,

his one last thing in a very Steve Jobsian form, was to get on stage and demo what was basically a weekend hack for him. He's had this crazy idea, he's like, I think I can hack into the Chrome developer tools, I think I can make a Chrome extension that does that. And now I would say the Ember Inspector

is one of my favorite features in Ember. I think the reason I like it so much, well, when it's useful, it makes you more productive, but more importantly, I think it shows that by creating a community where we have shared understanding around how we solve these similar problems that we all have, we can actually start building amazing tools on top of that shared understanding.

To me, that's what's so powerful about what this is. And now it works in Firefox, so thank you to everyone who contributed to that. And especially Teddy Zini. And Teddy Zini. So one thing I want to say in general is, we just did a bunch of slides about things that actually aren't strictly about the Ember code, and one thing that I care a lot about

as an open source person, as part of an open source community, is that open source communities value contributions that are not just code, that are not just raw code in the core. And so things like documentation, things like auxiliary tools, there was a previous thing before the first thing that we said.

Well, I don't remember anymore. Yeah, things like conferences. These things are very important, and I think if you want to contribute to Ember, infrastructure, of course, with the other thing, Robert Jackson. If you want to contribute to Ember and you happen to be very good at managing EC2, or you happen to be very good at events, these are areas where you will be a first-class citizen as an Ember contributor.

I don't really see the core as being a core group of people that only writes code, and then you're kind of a second-class citizen if you happen to run our events or you happen to do our infrastructure. So I think similar to creating that shared understanding of the value in the inspector is also true about Ember data. I see Ember data as a way for all of us to come together

and create shared understanding about how we solve this problem. Data synchronization, data persistence, web developers lose productivity every day that they go to battle with this problem, and I think we would like to amp up the productivity here, too. So the plan is we've got an Ember data 1.0 coming very soon.

Yeah, it's going to be awesome. We wrote down all the details in this blog post that you can go read. If you're interested in the details, I don't think we want to go into details. And Igor is giving a talk about this. And Igor is giving a talk about this later today, I think. Yeah, but I think the TLDR is just

Ember is really good at helping you be more productive at your job, and Ember data is another area where people lose productivity, weeks and weeks of productivity, doing battle with a problem that ends up being rather similar in a lot of ways, and getting that sane is important. Since last year, we also added two more new core team members, Alex Machner and Robert Jackson of Dockyard.

So today we're announcing... So thank you guys very much. Alex has been here for a while. Robert today we're announcing is joining the core team. So these guys have been kicking butt and taking names, and I personally owe them a tremendous debt of gratitude. So thank you very much to you both.

I'm looking forward to working with you even more in the many years and decades and perhaps centuries to come, depending on how good our nanotechnology gets. And in general, I think one thing I really like about the Ember core team, in addition to the fact that it's composed of a lot of disciplines. You know, Leia does events, and she's on the core team, and I think that's important. Robert does infrastructure, he's now on the core team,

is the fact that the core team is composed of many companies. There's many people on it from different companies. It's not one company that's really manning the reins and has the full control, and I think that that is actually really important for open source communities to be managed by a diverse group of people that actually know, that work on different kinds of problems.

So the point of our talk... So that was all the welcome to the conference. Yeah, that was a fluff. Thank you for saying through that. The thing we want to talk about today, the focus of our talk today is on productivity. So I think fundamentally, people use tools like Ember to help them get their job done faster, to help them get their job done more effectively and more consistently.

That's what being productive is, and I think Ember makes them more productive. So that's what we'll be talking about today, but before we talk about Ember specifically, we're going to talk a little bit more about how we build apps in general from a higher level. So in general, I think a lot of people who build applications, so this section is called screens and flows,

a lot of people start off and they build... Some apps are basically just a single screen of beautiful, highly interactive, delightful functionality, something that makes your users very happy. And it's obvious why you would build experiences like this on the client instead of the server, and indeed a lot of applications actually start off with a single screen.

If you're building an application that's a single screen, there's actually a ton of good tools that are very, very helpful at making you productive at building single screens. And Ember happens to be a tool that is good at that, but that's not really where Ember shines. And while we were preparing this talk, we came across a blog post by Ryan Singer of what is now called Basecamp, what used to be called 37signals,

and he basically talks about the fact that really fundamentally flows, the way your user moves around your app, is just as important to building a good interface as individual screens are. So this is a notation from his blog post. This is an example of a very simple flow. This is the sign-up flow for Basecamp.

And the notation that he uses is basically the screen name at the top and then a list of the flows, the transitions that can happen, written down below the solid line. And you can see here that for a really, really simple feature, there's already a bunch of screens involved and a bunch of flow. And so even small features,

this is an example of the flow for RSVPing to an event. I think this is Basecamp. Even a feature that is pretty simple, if you think about RSVPing for an event, ends up having a surprising amount of screens and a surprising amount of flow between those screens. And I think anybody who's building an application,

an application that's an application and it's not a single screen, viscerally knows, they understand that they're building something that has many screens. So when we talk about ambitious applications, what we're really talking about is this kind of thing. You have a lot of screens, a lot of flow. You're not just building a single screen or a single widget. You're building a whole cornucopia of screens

and linking them together. And if this is the flow for one feature, think about what this diagram would look like if you mapped out your entire app. And I think on the web, it gets even more important to deal with this, to have a good way of describing and managing this, because on the web,

flows aren't just from screen to screen. A lot of times in iOS on mobile apps, because the screen in real estate is limited, you go from screen to screen. But on the web, most of the apps that you know and love have nested screens, and they have nested flows. So who's going to show you an example

of what we mean by that using a tool that hopefully you all know and love, which is GitHub, which you probably use every day. So here I am on my main screen here, my main entry point, my news feed, and you can see there's a lot of ways to leave this screen, a lot of links. And the first thing that I'm going to do is I'm just going to switch from my YCATS organization

to, you can maybe see at the very top, sorry, I switched to the EmberJS organization. This must be a retina projector. Yeah, it's really hard to see. So you can see I switched from the YCATS context to the EmberJS organization. And you can see there is some global stuff on top, and then underneath that I'm switching,

and then under that there's another piece of flow. But now that I'm in the EmberJS organization, I want to switch from the news feed over to a list of pull requests. So now there's another set of flows underneath that. And actually, now I want to switch from open issues to closed issues. So I'll switch from open issues to closed issues.

And there's another level of flow under that. So this seems really simple. I think you can, as a user of GitHub, you can follow what's going on here. It's not very complicated, but really you're getting to several levels of nesting because GitHub really offers a lot of functionality. And they're trying to pack a lot of functionality into a few screens so that you can really understand what's going on and not feel like every single time you want to do something,

you're in a totally new place. And this is, I think, how people build web applications. So now let me go and look at an individual issue. And the thing that you'll notice about this is that some of where I'm nesting inside has stayed the same, but a lot of it has changed. So I'm basically flowing from where I was before, maintaining some context about where I am, and going somewhere else.

And note that the top of the screen there, where you can search GitHub, has now, even though I have actually flowed somewhere underneath that, I have now modified the top of the screen so that it knows that I'm inside a repository and lets me search inside of this repository. So you have the screen at the top, reacting to changes in the child's screen below.

And now I can also, there's another flow under here where I can switch and look at an individual set of commits. And actually there's even more stuff going on. I'm still inside of my application, and I switch to the issues list. So it's a list of issues that you want to prioritize or assign a label to. Confirm. And I can go and I can select an individual issue

and add a label to it. And I can say, okay, I want to approve the label. And not only does that issue update, that individual issue, but a lot of the context around me has changed. The number of issues with that label, there's a count on the left, that has changed. The number of open or closed issues might change. There's many, many things, pieces here

that we could, in theory, have highlighted. So there's like two screens that you need to keep in sync. And so there's much going on here. And I think the really important thing is, you know GitHub, you understand it. It doesn't feel like it's insane, but there's really a lot, a lot, a lot of things going on simply to get this, to get the job done. And I think when people build applications, they end up building things that feel like this.

They end up building a lot of flow, a lot of context that you want to keep up to date, a lot of nesting, so a lot of, I'm inside of here, but now I'm inside of here, and now I'm inside of here. And people build this all the time on the web. So this building apps like this,

when it comes to modeling things like this, this is the productivity sinkhole for most web developers today. This is the part of building an app that makes adding a new screen go from being just a quick job to a multi-week project. The complexity and the amount of time it takes grows exponentially.

And remember, when you first started your project the first time and you added a screen, it felt very easy. Really, no matter what tool you use, it feels very easy. But as you start adding more and more screens and having more and more flow, everybody has experienced it becoming harder and harder and harder. In other words, probably everyone has seen, gone into an app that looks like flow spaghetti.

And adding the new screens requires you to think about how that screen interacts with the entire application. So the amount they have to deal with grows very, very quickly. And I think it's even worse on the web. Dealing with this problem is much harder being a web developer than it is being a cocoa developer.

Because look at this GitHub page. Look at how many links are on this page. URLs make it much, much worse. You have to make sure, one, that every change in flow, every change in the screens that you see updates the URL. So that's number one. But for another thing, unlike native apps, both you as a developer and your users expect that any page can link to any other page.

Developers and users don't think of links as these heavyweight operations. You just put them all over the place. Which means that if you have any two screens in your application, it's a totally normal and legitimate thing to just add a link from one to another. And you really want to be building applications that can handle that.

So even if you have a small number of screens, the fact that these links between them are so lightweight, it causes the possible flow between these things to grow exponentially. And that's the kind of thing that you need to account for. So things that felt easy

when you were building a single screen all of a sudden can take weeks. And we wanted to create a tool where you feel like you can crank out new screens, new flows, without a care in the world, without everything feeling like a huge slog. And more importantly, if you're doing it by hand, every time you add a new screen or a new flow,

that's an opportunity to screw up. Of course, you can do this productively if you're perfect every time, but I have days where I didn't get enough sleep, I'm tired, I'm sick, hired a junior developer, and we gave the commit to the code base. I'm sure you've all been there. The point is, Ember makes you a badass web app developer

because it helps you not have to deal with the problems. It makes you productive. It makes it easy to add new screens, to add these new flows. And I think in general, again, what we're doing here is we're all building web applications with a lot, a lot of flows, a lot of screens that are linked together. And what Ember is really about, it's about making it really easy

to add new screens and link them together without that becoming this exponentially complicated slog of a problem, without it becoming a productivity nightmare. And I think in general, I personally feel, as a person who uses Ember every day, Tom, I think, would agree, hopefully, that using Ember to build applications with a lot of screens

is tons more productive than what we used to do before. So let's look at some examples of real-life apps with flow that use Ember. So the first is, this is a video that we recorded of Vine, so I apologize in advance, probably the content's offensive to some people.

It's like every Vine I've ever seen. Oh, that's okay, chickens are good. So the point is, you can click around, and even something as simple as Vine, which is like, let's look at a bunch of six-second videos. Even the web app for this has a lot of state and a lot of flow, and what's cool is that the URL updates along with all of these things. So even though you would probably think, oh, this is a simple app, I could probably bang this out with a simple tool in a couple days,

the more that the app grows, the more screens you get and the more flow between those screens there is. There's even like a TV mode. This is the TV mode in Vine, which is pretty cool. And you can see there's links to a user page here, right, in the middle of TV mode. I think people don't necessarily think about the flow as being, they don't think about,

oh, I'm going from TV mode to the user. They're just thinking, I have a TV mode and I have a user and I'm going to put a link between them. That's basically how people build web applications. This is another video. This is the app that I've been working on every day. It's been pretty nice working on an Ember app full-time. This is called Skylight. It's for profiling Rails apps. And you can see it's much, much different than Vine.

It's a very highly interactive tool. It uses D3 for all these visualizations. But even this profiler, because we have things like billing, we have, you know, locked accounts if you go over, we have organization management, that ends up requiring us, requiring a tool that lets us deal with the flow in these different screens.

I think one of my favorite Ember apps is Bustle.com because it was the first Ember app that made me think, maybe this is actually a good tool for building content sites too. It feels so, so fast. Again, this is much different than an app like Skylight, right? But even this content page has,

when we were putting together this talk, we went and actually looked at it and it's like, wow, you have slideshows. There are so many ways that these screens cross-reference each other and you can move around between them. I'm really a fan of this video because there was a lot of Kim Kardashian going on. So this is really just an excuse for me to spend some time on gossip sites.

So a lot of fun. And the last one we'll look at is Travis. So probably many of you use Travis for your CI, continuous integration. We use it for all of our open source projects and for all of our commercial products. And this, again, has, like GitHub, very, very deeply nested screens. And you can move between all those screens very, very easily.

And Travis does a great job of keeping the URL up to date as you move between these. Just switching between tabs, going to different builds, going to log output. All of these things keep the URL up to date, which is really awesome. And the point I want to make here is that these are all very different applications.

But we went and looked at how these applications are built using the Web Inspector and they all deal with this flow with the screens using the Ember Router. Yeah. So you can start off with Vine and you can see there's a bunch of stuff.

And you might be surprised at just how many screens, if you're familiar with Ember, whichever one in this room is, you can see there's a lot of functionality here, a lot of screens, a lot of flow, even for something that seemed like a very, very simple web application. And if you look, again, at Skylight, we actually have fewer screens, but we still have a decent amount of screens. We have a couple of main screens and we have a bunch of flow.

We want to make sure that the billing screen actually still works no matter where you happen to have come at it from. We want people to pay us. Bustle, again, lots of routes, lots of flow. And finally, Travis, lots of routes, lots of flow. And I think if you're a Ember developer, you are used to this being the case.

There is a certain way that no matter how your application ends up working, we can think about and talk about the flow between your screens, how they're linked together in a similar way. And one thing that DHH said at one of his keynotes at RailsConf that I think really captures what's true about Ember as well

and what we are trying to build is, what he said was, one of the points I keep coming back to with Ruby on Rails is that we confess commonality, that we confess that we're, and maybe this isn't good for our ego, we're not as special as we'd like to believe. We confess that we're not the only ones climbing the same mountain.

And I think that the conclusion is that we're not as special as we'd like to believe. The fact is that the flexibility that we think we need, flexibility that we think we want, we really don't. And fundamentally, I think this is an idea that transcends specifically Rails or Ember, the idea that when we build software,

there's a lot of things that end up being the same and it's really easy to say, well, Bustle, Skylight, Vine, Travis, those are really different apps. They really call for domain-specific solutions. Everyone should build their own framework because it's just too different. It turns out that with a little bit of grit, with a little bit of work,

with a lot of help from the community, a community of people that buys into the idea that we're actually all climbing the same mountain, we can build a language for talking about what we're doing that is both effective at capturing what's the same and flexible and powerful enough for you to do what's different. And I think that that's what we really strive for with Ember.

It's a way to basically say, let's get rid of the productivity sinkholes that have to do with the things that all of us are doing that are the same, the drudgery that comes from linking together flows, dealing with URLs, all this stuff that ends up just being the same at the end of the day and let you focus on the part that is your application. And that's how you get a 10x productivity boost.

If you're only spending, if you spend 90% of your time gluing a bunch of stuff up together and you're only spending 10% of your time working on your app, now you can spend 10 times as much time working on your app. And I think, interestingly, just having the tools at your disposal to do the right thing isn't enough. So there are some tools that exist that give you enough

to do the things that we're talking about here. But just having the tools at your disposal to do the right thing isn't enough. You can, of course, do the right thing when you're in a good mood, if you have a lot of time, if you're working with skilled people who already know what the right thing is on a team that already knows what the right thing is. But, of course, like we said before, people make mistakes.

People are in a bad mood. People, you hire a junior developer, you have a team, a distributed team of people and it's hard to disseminate the best practices. Maybe you didn't Google the right thing when you were looking for information on how to do something. And the nice thing about good defaults is that they keep you on the right path even when conditions aren't perfect. And so here's an example of, it's a famous example of organ donation.

And so if you look on the left, there's four countries that have relatively low rates of organ donation. And if you look on the right, you have countries that have relatively high rates of organ donation, even above 99%. And you might look at this and ask yourself, what is different about the countries on the left than the countries on the right? And I've answered the question here.

I've given away the plot, but it's somewhat famous. And so you might first say, well, maybe it's cultural. Maybe like, you know, maybe the UK is more conservative than France. So that's why people in the UK tend to not agree to organ donation, but France maybe agrees to it. But actually, then you start to notice that, like, Denmark and Sweden are somewhat similar culturally,

and yet they have really different rates of organ donation. So what is actually the cause? And the actual answer to this, the real answer scientifically, is if you make, when people go to the DMV, if the question is, would you like to donate your organs if you die? Yes or no? People do not check the checkbox. If the question is, by default, you will donate your organs if you die,

do you want to opt out? People do not check the checkbox. People basically do the default behavior. And the really interesting thing is this is not a trivial decision. People feel very strongly about this. This is a thing that feels very emotionally weighty. And yet all the excuses that people tell themselves in their head when they're not checking off the checkbox,

when it's an opt-in decision, somehow fall away when it's an opt-out decision, right? So all the things that you're telling yourself, oh, my mother would be so angry if she found out that I was donating my organs, whatever it is that you're telling yourself to not check the checkbox, suddenly becomes not all that important when it's just a tiny little tweak. And I think the reason why this is so important is that

effects on human behavior are really not intuitive. We would not expect, human beings would not expect this level of disparity. And I think the same thing is true in software. You might think of good defaults in software as a small tweak. It's a small thing. Well, I could do the right thing, and Amber's giving me some stuff, so that's a small improvement. But the reality is that for basically the same reason,

having good defaults is not a small tweak. It's a difference between having to be perfect every single moment, every single time, always thinking about it, always checking off the checkbox, versus having the right thing be there by default, having the right thing happen to you by default. And I think, in closing, I think everyone is here in this room today

because they use Amber, and Amber makes them far more productive than not using Amber. I know that's true about me and Tom, and I've heard from a lot of people that fundamentally, Amber makes them a more productive developer. You wouldn't be here if Amber wasn't making you more productive. And I think it's really important that if your friends ask you, why should I use Amber? I know you're an Amber guy, why should I use Amber? You should tell them the story of you becoming a more productive developer.

You should tell them the story about you getting more done in less time. You should tell them the story about being more consistently effective, the story about not feeling like you're adding a new screen and you're in a slog. Obviously, you and Amber are not perfect, but there is much, much more productivity here than in other solutions and other options,

especially when you're dealing with flows and URLs and big applications. So tell your friends, tell your friends that Amber makes you more productive, makes you a badass developer, and enjoy the rest of the conference. Thank you guys very much.