 Ready? I think so. Okay. Just a few days to remember how to select, that's pretty much how everybody here heard me talking about that. I think I implemented the last, the ultimate feature, I mean the last one I'm going to implement ever on the component. From now on it's up to you. And it's basically this small thing where you can type even if somebody is slow, like in real selects, as the last feature is going to go in the core. You can type it when the component is focused and when you have it open, typing basically selects the thing you are typing and if you wait one second, the type is, sorry, the search is reset, like in real selects. And that made the last release, if we go to GitHub, we, that's the release I advise you to use now, this one, this, the very latest thing, probably it's not going to be any change before 1.0, apart from bug fixing, probably a bootstrap theme out of the box, or even a material, material design theme, but probably only styles and obviously additions, not changes. And another big feature of this release is, the previous one actually, but it's included in this one, is fast boot support. Chicken Milanese with fries. Ah yes, the release names is always what I ate this day. So, no, no, I mean I have a lot. I'm going to check. That's what, coming up with names for releases is the hardest part. No, no, it's very important. No, probably over, I mean, I don't know, it's, I don't know, poor Reeves, I don't know, I have more, I guess, not bad, well, going back to the topic. We have, sorry, releases again, we have now fast boot support and accessibility. And the thing I want to show is about fast boot. I've been playing with fast boot for a while. I thought it was still in very early days, but after using it for a while, it happens to work pretty well. I mean, everything I tried worked. And if something breaks, it's because something was not prepared to, for fast boot because I was using jQuery, jQuery maybe, or something like that, which obviously doesn't work when there is no DOM. So basically, I'm not going to try to install things from MPM again, everything is installed. If I open here this thing, the only thing you need to do for make something work in fast boot is basically add this line, basically Ember install Ember CLI fast boot, and when it's done, if you go to Ember CLI fast boot, first of all, everybody's aware of what fast boot is. Okay, for running in the back end, sorry, for running fast boot after the install, you just do this locally, at least. So, oops, sorry, this is not the proper repo. Building, it happens to run in 3,000, it's running, that is that. And if I expect, I don't know how to disable JavaScript, anyone know how to disable JavaScript? F1, okay, disable JavaScript, I see. Disable, I close, if I go probably to, this is a per-tap thing? Yeah. Okay, so if I go to... Yeah, I'll try having a look in Safari, because you can globally disable JavaScript there. But you can go to Ember browser, I think it is that. And nothing should work, respectively, nothing works. And in localhost 3,000, it does. And things like links and everything works, you can read the documentation without JavaScript. Obviously, examples are not going to work. Oh, actually, they are working, because I closed the DevTools, that's it. Open the DevTools to see it fail. F1, okay. So, now it's not working. I click things, nothing happens. And if you want to see how the page will behave in real world, you can probably open this thing. So, the navigation is working with linked, but is it working with... You have actions in there as well, navigation wouldn't, right? No, it has to be linked. Because linked happens to be just regular anchor tags. Yeah. And if there is no JavaScript, you will make another request. And actually, you say that cookbook, search a docs, and if you hear cookbook again, another request to cookbook. It's pretty fast, it's faster in production. And the idea is fastboot in theory. Serves the HTML with all the styles and the JavaScript. And once the JavaScript loads, basically Ember repaints everything. But the final goal is to have what they call rehydration. So, you render the page, Ember loads, generates the new HTML. But before doing that, compares the existing HTML. And it is the same, there's nothing to do. I continue. Whether or not it's doing a full refresh. But it's something that usually is that fast that you don't realize. And I'm going to enable JavaScript again. If you reload, Ember now is loading and everything is working. Actually, you can see how way Ember loads because I have some kind of logic for making this, I mean, the styles. And when Ember actually boots, you see a small jump in the styles. I should probably fix that. And where is the tooling for network conditions? We simulate something like, I don't know, regular 4G or good 3G, for example. You see, and the application right now has no JavaScript. But once this thing stops spinning, the application is usable. But now, even if this thing hasn't finished, I can open and navigate because it's going to work. So, especially important for mobile. And another thing I want to show, this is pretty much everything I have on fastboot. It's a, first of all, here it is, Ember first of all, we made live. And the other is, I made this demo for a, some people want to use native selects in mobile. But they want a richer experience in desktop. So I built this thing, which is another on top of Ember first select. That is exactly that. You specify Ember first select with fallback. And it will, when certain conditions are met, it will render a regular select instead of the enriched version. For example, fallback when mobile. And that's the other thing you need to do. And in the demo, you will see that's using regular select. Sorry, the power select. And if you decide to fallback, standard select, you select this and this. And if you go back, everything is selected still. I mean, you are exactly wrapping the same, I mean, the interface is the same. But depending on some condition, it renders a regular select or the power select. And that can vary between iOS, Android, phone. You can detect if there is a screen reader perhaps, because you want to have the best accessibility. Even if I implemented accessibility, nothing is going to be better than a plain select. And actually, since not all usages of Ember first select can be translated into standard selects, basically this implements a few naive assertions that only run in development. So if you are trying to use this component and you are passing, for example, a custom search function, there is no such a thing as a custom search function that you can trigger from a select. So that is going to warn you, caution, this is something you cannot translate. Try something else. I mean, if you insist, it's going to continue. The moment is not a hard failure. But you need to be aware that it's probably not going to work very well in plain select mode. That's pretty much it. Ah, no, I have another one. Sorry, about fastboot still. The problem with fastboot I found is not fastboot itself. It's working very well. Who do we test fastboot? There is no literature. I mean, pretty much nothing in the web I found. So talking with Robert Jackson, Tom Dale, and everything, I started spiking something that is going probably to be the way we test fastboot. And as we see, probably fastboot tests are going to live in a different folder. And that's the thing I created called model for fastboot. It's something that, once used, will resemble the same thing we use for regular testing. We have this.visit, and you say you pass a URL. And in the then, you will receive the headers of the request. And we are using jsdom to actually pass the response. So you can do assertions with query selector and everything on the content. So basically, you make a request. The server of fastboot actually happens to be an express middleware. So I would express application right away. And at the moment, the port of the application is hardcoded to this thing, because I want it. But the thing is, the port can be incremental. So you could be able to run a test in parallel with many applications running in different ports. So you can test your fastboot application. For example, crawling all your application in parallel. So you should be able to check that every single page you have renders in fastboot very fast. And we'll be part of the regular test them, ember test, test, assert. And it will all the time check that the changes you make actually don't break fastboot. The ultimate goal is that fastboot will be the default. Pretty much everyone is going to use fastboot. And like right now, people is surprised when they say, I'm not using Ember CLI. Right now, it will be surprising for someone doing Ember not using Ember CLI. I think in nine months from now, it will be surprising for people, I'm not using fastboot. Why not? Why you are opting out for fastboot? It will be so easy to use that pretty much everybody is going to do it. As soon as you install fastboot, probably when you use the blueprint to generate a route, we generate the route, the test, and the fastboot test for this route. And the fastboot test, basically, even the very basic thing will be request and see that at least you get a 200 OK for the backup. And that's everything. Thank you.