 give you a quick update on the status of Embers Heli deploy. I'm Athea. And I'm Aaron. And a few months ago Aaron and Luke were here at the last Ember camp announcing Embers Heli deploy 0.5. You have to notice the pants. Yeah I know, I should buy Canadian ones. So what happened since then? We did a few things. That day we released 0.5 that was a complete rewrite and we moved to what we call the pipeline architecture. And this is the idea is that each deploy is a series of steps. And what we can do is that we can enable you to install different plugins. And each plugin can implement one or many steps. And the combination of the plugins and the pipeline running will produce your deploy. And then in February, you have the wrong emoji. Anyways, in February we released a quick update that did a few niceties. So we added a progress bar. We added some extra deploy hooks. We now better support .m and we allow you to configure logs, callers. And we allow you to, we will basically validate your config and tell you if you don't have plugins, any plugins that implement certain hooks, because some commands will require you to have certain plugins. And so we just detect that. And then... Yeah, so today we released the first beta of version 1.0. There's a couple of cool things in there. I guess the main one, or we did this really just as an excuse to actually write some code. That's why we're talking today. It's a conference-driven development. Essentially the main big thing here is we've improved the plugin control. So previously in the config, when you wanted to run multiple plugins, run them in different orders or disable them, there was in the config a plugins property, which was quite confusing because it just took an array of strings and that essentially let you disable plugins by not adding the name of the config into the array. It allowed you to reorder them and it also allowed you to run multiple instances of a plugin by aliasing them. It was completely confusing. Most people screwed it up. So thanks to Ed Faulkner doing most of the work, we've now improved that so you can specify the run order by just doing pipeline.runOrder. S3 runs after Redis or whatever. You can disable them by just setting the disabled true for any of the plugins and you can also alias them. So it's a much more improved way of controlling those plugins. And we've got some new docs. So they were not particularly easy to read before. Most people didn't understand that you needed to look to aliasing if you wanted to run a single plugin more than once. So we've improved that to kind of be directed more at the way you guys use MBC later play. We've got the, we've improved the output for the listing of revisions a bit more like Heroku now. Thanks to Matia. We've got a cool webhook plugin which allows you to ping different webhooks. So Simplabs and Mike worked on that which is awesome. And we've now, we've got community badges as well. So you can, on any of your add-ons, you can, you put some code into your, you read me and it basically says what version of MBC a lot of play this, this particular plugin works with. And since last Ember Camp, we've had a bunch of different contributions to the core plugins and MBC a lot of play itself. We've had a bunch of releases 61 loads of new plugins since we, since Luke and I gave the original talk, we had about 45 back then. And there are 12 deploy packs, which is a way to package up a number of different plugins. A bunch of different companies are creating their own plugin packs when they want to have the same sort of bunch of plugins used across multiple apps. So it's really cool. And there's a couple of different deploy strategies that we sort of talk about in the docs. All right. Last few interesting things. Again, the plugin packs company use them. And we're just pointing out a few here that you might want to look at if you haven't used Ember to deploy yet and you're interested in bringing it in. And you can see like, yeah, pass one with a better lightning strategy with a couple of fancy things and Zesty automatically deploys the poor request on every deploy to a staging environment. And at PN the company work for we automatically fetch the environment variables from a remote server. So that we're always in sync, we don't have to store them. Another interesting plugin, this is just one of many is like the GitHub status one that shows you the little badge. So if you automatically deploy poor request, you can say in the in the poor request, you will show passes Travis deploy to the server, you can click and see the deployed version, which is nice. And a couple of things with we want to release their private steel. Yep, wrote a deploy bot from Slack. So you can deploy from Slack and it will trigger an AWS Lambda function. And then use Travis to deploy. And we wrote internally instead the Sinatra app because we can't use a we need to run on internal network. And so we hope to release this as soon as possible. So what's coming up basically dry run, which is just an option you're gonna be able to pass in to to just essentially output the order of the pipelines going to run the public plugins are going to run in. So it doesn't actually do anything, but allows you to verify that your config works and things will run in the order that you expect. We're going to release the final version, I guess of 1.0 docs fast boot. Lots of people ask how fast boot works. And we don't actually have a good idea of a good mental model of how fast boot works. So Tom, I want to chat to you before today's out, please. So you can explain things to me. Tom's done some good stuff around embassy later ploy and fast boot. And we want to look at web UI. So there's been a couple that have been created. So we're keen to maybe consolidate those. So we can have a web front end to embassy later ploy. So that's all in the pipeline. And that's it. Thank you guys. Thanks. Currently, I have 300,000 milliseconds. So I have to be quick. So my name's Jew. Hi. You can find me online at Zarkam with a four. We're working for a company here in London. It's called AlphaSize, so you should check them out. So what is Elm? How many people here know what Elm is? Come on, bring it out. That's pretty good. So Elm, it's a purely functional language. It reminds a lot of Haskell. Sorry, I should start my timer. Start. Awesome. It's optionally typed. So it supports types of definition, but doesn't require to have types. It's monad-friendly. Officially, they're not monads, but they're actually monads. So whatever. It's a very mutable language, and therefore it's awesome. And right now I know what all of you guys are thinking, and yes, it does compile to JavaScript. So, yeah, demo. Cool. Basically, you open their website. It's pretty cool. You go to try. Oh, that was pretty much. Hello, world. They have this amazing editor where you can just type things out and say, okay, this is some weird, oh, can you actually see? Maybe it's this better. Awesome. So, yeah, important HTML exposing text. Then we have a main program. It prints out a text. So if you actually inspect this, you'll see that it's actually HTML. Somewhere. Script. Something. Okay, cool. So actually, I'll show you how to define a function. You can do add. If any of you guys have done some Haskell, it will remind you a lot of the syntax. So it's pretty weird. So actually, if you think about it, just look at the implementation. You're going to do something like this. And then we're going to print this out. So we're doing add one, two, and run this. And it crashes. But actually, the error message is pretty cool. It says, function text is expecting the argument to be string, but it is int. So to fix that, we can just write to string. And compile again. Boom. Fixed. Cool. So this is okay. So basically, if you think, if you read the type of definition again, it's taking two ints, it's returning int. But what is a bit cooler is that actually, you can do partial applying of functions. So you can do something like this. And this will store a reference to that. So, and actually, if you really like a link there in pipes, you can type pipe stuff. And compile. And it works. Not only that, you can also do, let's say I'm going to create another function which adds 64. Okay. And it adds 64. And here, you can actually do an operation which is function composition, like the true mathematical meaning of the word. So compile. Oh, no. Almost. Something with parenthesis, I think. Awesome. Cool. What is even better than that can just rewrite the whole thing. But we want to be special about that. We can also do it in the opposite way. So it supports backwards piping. Oh, sorry. One, two. And actually, it hurts my brain as well because I don't really know what I'm going to now. But anyway, it doesn't matter. I just go back and show you something else which is, I have three minutes. Awesome. So you might have heard of this framework which is called React. And it's pretty simple. And this is like something quite similar. You have a beginner program which tells you how complex its app is. You pass a model. You pass a view function. You pass an update function. And if you see, like the model is just instantiated as zero. And then you have the update function which is defined here. And actually, see, like the type of definition in this case is optional because in theory it should be something like this. Oh, missed message. And then takes a model. And then returns another model. But the actual concept like underlying that is really similar. So you just like take an update function. You take a view function. And this just works. So if I'm doing this, it works. Which is pretty cool. In my last minute, I'm going to show you something really cool. Which is, I have to compile this again. I'm afraid. Okay, awesome. So there's a Mario character here. And you see he can jump. And he can move around. And on the left, there's a code which makes the whole thing run. Which is 112 lines of code. Not bad. Okay, made this guy jump a little bit. But now actually I'm going to stop time and rewind it. And the guy will go back. Which is, okay, we've seen this. But if I tamper a little bit with the physics engine, and I change this one, and I drag it to something else. You'll see, oh, oh, Mac OS. You'll see what happens, right? And to keep dragging, you'll see that all the history and all the actions have been reapplied. And the state has been recalculated and like showing in real time. Since we are not building this sort of stuff every day, you can just think about really complex forms. And instead of waiting for a whole page to refresh and then typing the actions again and clicking all those like weird links again, you can just change the code and see all your changes that we applied instantly. I've put some code here, and there's like more links. There's this repo just called awesome Elm, which you should all check out. And that's it. Just going to start with a quick history about me, and then I'll get into the meat of what I want to actually talk about. My name is Chris Manson. I started using Ember in December 2011. I was just reminded of state manager there today. Oh, they were good times. Yeah, so back then I actually transferred from Angular, also pre 1.0, but I fell in love with the concepts of Ember and just what the community was trying to do. This was even pre-router, but just the way that we approached that and we tried different things and kind of progressed. It was really what kind of just draw me to the community. Since then we've come a very long way. You know, we've already had that from Tom and Yehuda at the beginning. I loved the summary that Matthew Beale gave and the Be The Bark blog post. And I saw your keynote in Ember account as well, the fact that you're promoting the sub teams into official sub teams and all that. That's really kind of a good progression off the community. After the Be The Bark, after that kind of a concept, I've kind of been thinking about what comes next and at the risk of torturing the metaphor. I'm trying to think of what the forest looks like. So like a connected ecosystem of different systems that just talk together as one. I don't know, it's kind of getting a bit funny here. But it's all for the same reasons. You know, we want a really first class developer experience for us to get going with applications as quickly as possible. So that's the background. That gives you a little bit of how I feel about all this sort of stuff. So, right, get to the meat of it. Five years ago, I started my first startup. And when we started it, we were just looking around and I was just surprised that there wasn't a login system that I could just take off the shelf and just use and then get to actually developing what I wanted to develop. Obviously, there were a few sign in as a service companies out there and products, but they weren't, it didn't seem to gel with what I wanted out of it. And it didn't gel with the community that I was starting to fall in love with at the time. So as any good developer would do, I built one. And I would like to announce Authmaker. It's something that we've been using for the last year or so with four or five clients. It's a little bit battle tested. We have actual running applications in there. It's a system that's really designed to get you going quickly. It solves that problem that I had. You don't want to have to write the login system, the password reset, the confirm email, all that sort of stuff. And when I say get you going quickly, I'm thinking, or at least the goal of Authmaker is to get you going from cold no application at all with a full login system in less than two hours, actually deployed in live. Obviously that's, you know, standing on the shoulders of guys working on Ember CLI, Ember CLI deploy, the generators and things like that. But the added benefit of Authmaker is that you can, I expect in that two hours for you to be able to accept payments. Obviously you need to put some features into the app so that you can have people pay for something. But yeah, so that's the kind of goal. And the thing that I'm most excited about is that Authmaker is going to be fully open source. So it's not like these sign up as a service applications where you can only do it through their proprietary implementation. You can run it yourself. But again with our goal of getting people up and running as quickly as possible, we're going to give you a way to run it on our servers so that you can get up and running as quickly as possible. And like I said, we've got four clients actually using this in production, but we now have to go into the next phase of getting it ready for just general wide adoption, people just downloading it, running it, seeing how it works. So what I'm looking for is I'm looking for about 10 people who are using Ember in the front end. Do we know anybody? And node and express in the back end. And hopefully we'll be able to expand that as time goes on, but iterative release cycles and all that. Yes. So if anybody is interested in playing around with this, just come and talk to me afterwards. I'll be hanging around a little bit after the conference. So that's that's it. That's all I wanted to say. I hope you're not sick of me, but I wanted to briefly talk about an add-on I mentioned in my talk, which was called Ember Chainset. So if you want to follow along, you can actually try out the demo in your browser. It's bit.ly slash ember-chainset-demo. Mayor, can everyone see that at the back? Okay, so Ember Chainset and Ember Chainset validations are two add-ons that basically make the process of validating forms a lot simpler. Chances are you probably use something like Ember CP validations or Ember validations to validate your form. And in order to get an experience where, you know, it's like a nice user experience for editing this form, you actually have to go through a lot of intermediate steps in order to get things to work the way you want. For example, here, if you look to do this out of the box with Ember CP or like one of those observer or computer property-based validations, it's kind of hard because what happens is the moment the form renders, it's already invalid because the computer property is already running. And then you basically have to write all these extra computer properties just to get this really basic kind of form experience working. But with Ember Chainset, you know, it's a really functional approach. It's all just functions. There are actually no computer properties or observers at all. And if when I show the code later, it's actually very little code to get this kind of like nice validation behavior right out of the box. Yeah. So let me go through the code really quickly. So over here in my application template, I have an edit user component, which contains my form. And you'll see that it's just a really simple form using the with keyword here. So I pass in the Chainset wrapping the user record. And then I also pass in a validation object that I defined, which I'll show you a bit later. And then I have a bunch of fields that basically just go through these four properties on the model. So you can see it's actually a pretty simple template. So let's take a quick look at the validations themselves. So there is a base validator here. You'll notice that it's actually really, really simple. It's basically just a pojo with a bunch of keys and validator functions. So here, for example, with the first name property, it's going to run through the present validator as well as the length validator, which are all just regular functions. And the benefit of this approach is that you can actually compose validations really simply. So for example, maybe I have a user which a user like under the age of 18 that needs to be validated differently from an adult user. So as you can see, I can simply import that base user validations object I defined just now. And then just by using the assign function, I can actually just merge those two objects together and I can get, you know, composed validator. And then the actual inputs themselves are super simple. You could use like a native input, you could use the input helper, you could use one way input. It doesn't really matter because how the chainset work is it essentially checks for the changes to be valid before it gets set on an intermediate object. So you'll notice that when I actually type in this field here, and this is the actual data on the record, it doesn't update immediately. And this is kind of like data down actions up and built into Ember chainset. Because even if I use the input helper, which is two way bound, this would still work the way you'd expect it to. And then of course, you know, you can't save this record. So I can actually cannot make this invalid. Postman, actually need to give Rob your postman. So I save it and Robert Jackson is a postman, cool. Then you can also, like if I, let me refresh this again. Yeah, if I, if I decide, like, you know, I actually don't want to change, it's super simple to roll it back. And this is all built into Ember chainset itself. So as you saw, there is this like, so little code here, but you get this really nice form experience just right out of the box. So if you're interested, you can try it out. Where's my keynote? And try it out over here. Oops. Yeah, so the link to the add on this here, GitHub under the Dockyard organization and it's Ember dash chainset. So yeah, I hope you find it useful when you're trying to deal with validations, which I'm sure is a really enjoyable experience. Thank you.