 So, I'm going to talk to you about Ember Twiddle. Some of you may know me from IRC where I ended up spending a lot of time helping people new or not new to Ember and ended up needing a way to demonstrate code and show stuff a lot. Initially, there was JS Fiddle and JS Bin, which were great solutions for this. Now, obviously, there's gists or paste bin or whatever, but it's really nice to actually share a live example of the code that actually runs and because it's JavaScript, it's really easy to do that. You just send someone in a browser to it. JS Fiddle, JS Bin, pretty great. They're great for general JavaScript code. They're great because they run the actual code that you're demonstrating. They're great for demonstrating problems. So, you know, you can show someone an actual error that's happening. You can share them, edit them, fork them. I think one or both of them update live as people are typing, although I've never really got that to work, but apparently they do. They're really quick and easy, but they're totally not suited to Ember code specifically. Templates are a really big pain there because, you know, you have to write these annoying script tags in the little editor and you have to type out data, template name, equals whatever. You don't get handlebars syntax highlighting and, you know, as you know, the templates is, you know, the key part of Ember, really, or one of the key parts of Ember and handlebars is really key to that. So, back in 2013, I think, I was at the EmberFest conference in Munich and at the hack day, I decided to work on something called EmberWang. So, this is basically, yeah, I'll, if you don't know, you know, NumberWang, Michelin Web script, Sketch, the name is based on that. Yeah, unfortunately, when I released this, it has a kind of different connotation to the US-centric Ember audience. Show me your Wang seems to mean something very different over there, because I learned. So, anyway, it's, the idea is kind of basic. You've got different editors where you can easily add templates and name them without having to mess around with script tags. You can type in JavaScript or there was a coffee script and Ember script option, I think, shows the result and shows the URL as well. I think that's like quite an important thing for Ember apps. It's really nice to see what URL the app thinks it's on. So, yeah, you know, it's got Ember pre-loaded, you don't have to type in the Ember scripts. So, it was extremely basic and rough. It was made in a day. It was built with Ember Rails, which was kind of on the wane even at that point. And it's totally obsolete now. All of the files were persisted in a relational DB. I think it was Postgres. So, it had to have a server running. Someone had to maintain that to keep it up and running. I put it up on Heroku, but, you know, still things break. You know, you need someone, you need, it's just a pain to have to have a server and someone has to pay for that. And eventually, it didn't really get much traction and it was abandoned. When it came to EmberConf this year, I decided to revisit it because the issues with JS Fiddler and JS Spinner getting worse with Ember CLI, the code you share with those kind of services just doesn't look like the code that you write in an Ember app. And it's really confusing for people just getting started because the code that you send them and the code they have to write, or when they're trying to demonstrate a problem, the code that they want to copy paste from their Ember app into JS Fiddler, they have to know a lot even to be able to demonstrate a simple problem. So, I decided to try and make something to solve that. I was at EmberConf and then Ruby on Ales in Portland. That is a great conference, by the way. It's like a Ruby conference over two days with unlimited craft beer and cider included in the ticket. So, if you get a chance to go to that, do go. I always have a conference project at Projects. I really like to take some time away from my normal work and just hack on something in between the talks and try and build something. The idea is to base it on Ember CLI so that you get the same conventions but easily shareable on the web. The persistence is handled through GitHub Gists. So, you don't have to really run a server. You just save it to a Gist and you can look at the Gist separately. You can clone Gists and edit it on your local machine, push it back up, fork, all of that kind of stuff. And this one ended up getting traction. So, it's now part of the Ember CLI organization, it's an active project, lots of people are using it. It's great. So, I'm going to do a quick demo. So, this is what it looks like when you go to Ember Twiddle and you get basically an application controller and application template. You can easily add some new files. So, this is my favorite feature. You can add a component JavaScript and HPS at the same time. And you get both of these. And it doesn't actually matter that I've misspelled that. Then go back to application and there we go. Misspelled? That's fine. What else have we got? So, there's a nice file tree. You can inspect all of the files in your Gist. You can save it to GitHub. And as you can see, it just stores all of the files in a Gist as multiple different files. There's this twiddle.json, which I'm going to talk about a bit more in a minute. You can use your favorite editor mode. What else? It's just kind of really, really slick. So, and that's not because of me, by the way. So, I'm going to talk about the attribution for all of this in a minute, but it's had some really great contributions to making it as good as it is now. So, let's go back and talk a bit about the architecture. So, Ember CLI is written in JavaScript, which is great because it means that you can pretty much use wholesale loads of the infrastructure from Ember CLI and just put it in a browser. So, if you look at Ember Browserify, it's an Ember CLI add-on and it lets you use stuff from Node just really easily. You just use one line and import Babel from MPM Babel or whichever MPM package you want to use, and you can use it. So, as you may know, Babel is used to compile ESNext JavaScript that you write in Ember CLI into ES5 that you can use in the browser. And this is how the JavaScript compilation happens. So, this is kind of like the core part of Ember Twiddle. It's taking the code that comes from one of the editors in the browser compiling into AMD modules. And you can see this is just so simple. I mean, I thought this would be like quite a big project, but actually to get the initial hacked version up, it was so simple to do. And that's one of the benefits of building your tools in the same language that you're coding for. Like, I've used Ember Rails for a long time before Ember CLI, and it's great. And Rails has a great asset pipeline, but you don't get these kind of benefits unless you're doing everything in JavaScript. It's really good for some things. For handlebars compilation, we just basically outsourced that to the page. So, we put the template in an Ember HTMLBars compile statement, and that's executed by Ember template compiler when the page loads. So, we're not doing any kind of pre-compilation like Ember CLI would do, but it's not really necessary. I mean, it doesn't really make sense to pre-compile when you're running on the browser anyway, because you just compiled it like a few milliseconds before you would have anyway. We keep the code isolated with several features that are relatively new. SourceDoc allows setting an iframe's HTML content. You could previously do this with like some hacks or using data URIs as the source attribute for the iframe, but SourceDoc just works really easily. It allows things like cookies to work properly. It makes it really easy to kind of build isolated sections into an app. And Sandbox gives you control over what documents in an iframe can do. So, you can kind of make sure that the Ember app in the iframe doesn't leak out into the outside app, and that can be important. Like, you don't want someone to easily be able to send you a link to an Ember twiddle that like messes with your your GitHub account that you're signed into. So, this kind of security stuff is quite important, even though it might not seem it at first, because it's only like an app for like throwaway code, but actually you want to be careful. The editor is Ivy CodeMirror. It's really great. It's another Ember CLI plugin that's so easy to use. I mean, I'm just so happy that JavaScript has something now that like Rails had for a while. The ability to like really easy drop-in code from other people without having to like, you know, download a zip file and figure out where to put it in your assets and, you know, figuring out which, you know, need the minified version. You know, it's just like the it might not seem like much, but being able to just type like Ember, Ember add-on Ivy CodeMirror and then have a code editor in your app like right away, it's just so frictionless. It's great. So, Ivy CodeMirror is the the Ember CLI add-on that allows you to do that. The gist backend uses Ember data and some adapters and serializers. So, it's surprising little code here as well, even though the gist API is like slightly more convoluted and very non-standard compared to the kind of REST APIs you'd normally integrate with Ember data. We use the embedded records mixing, so a gist object has many files and it's kind of like it's a really good example. If you want to see like examples of an adapter and a serializer kind of process for dealing with a non-standard API, it just makes things it's just quite clear. It's quite easy. It's quite simple. The code to actually serialize like all these Ember data objects into like the format that GitHub needs and we use something called GateKeeper. So, unfortunately that's like the one server component that we need and it's like, I think it's like 10 lines of code or something. Basically, with the OAuth that Git uses, you can't do it fully client-side because you need an application secret and you can't just publish that in your client-side app. So, basically it's like a 10 lines of code that does the OAuth hand-off basically and sends you back your client-side token and someone's obviously had exactly the same problem trying to build a client-side app for GitHub and GateKeeper is just for GitHub or OAuth, basically. We just deployed it to Heroku, I think and it just simply does that one thing. And because of that, we don't need to maintain a database, we don't need to deal with spam or none of the problems that would normally be associated with running an app that allows people to publish random content and code on the web. We've just outsourced that to GitHub. So, that's great. Thanks, GitHub. Twiddle.json is, lets you specify your dependencies at the moment. I think it's about to be extended to allow you to set Ember feature flags well, but at the moment it lets you specify the different versions of libraries that you want on your page. So, you can use any version of Ember or jQuery, Ember data, that kind of thing or other libraries and you can just edit that in the interface and you'll get those libraries loaded up in the order there. In the future, I think it will probably support embedding Twiddles into other sites. So, it would be really nice if the Ember Twiddle was used in the Ember docs, for example, to give illustration examples. Add on support would be really good. Unfortunately, like at some point you're going to have to end up either running a Linux VM in JavaScript in the browser or having a server that runs Ember CLI proper, because the add-ons depend on if you look at SAS or something, like generally the Ember CLI SAS add-on uses lib SAS and that's C or C++ something and you can't really run that in the browser. But it might get to the stage where M-script or something allows us to run way more in the browser than you ever thought you could. But I think there could be some support for very basic add-ons that are pure JavaScript sooner than that and easier than that and, of course, writing your Ember app for you. That's the ultimate goal. You just press the button and go to the pub and let it do its thing. So, finally, I like to give the credits for Ember Twiddles. So, as you can see, I did a very little bit and got the very basic version up and running at the beginning and essentially handed it off to Gower of Zero and Juiced of Rays, who have done like everything to take this from a silly hack to a real project that looks beautiful and works really well. So, I mean, I think I'm really proud of this because it's probably the most successful open source project that I've launched, like it's got real people using it and it's become part of the official Ember organization. But, unfortunately, just time constraints. I'm just not that involved with it anymore. So, that feels really great and I'd like to thank all the people who have contributed to it and made it a success. So, that's it, really. Has anyone got any questions? Yeah, well, you know, I'm not the one with the dirty mind here. I can't control for that. So, I'm just interested given that you've managed to perform as much of it as possible out to the clients I can get help. Does it still include you or someone at cost? Or to what extent does it sort of give you a cost? Well, I mean, it has a domain name. It's ember-twittle.com. So, there's domain hosting cost. I'm pretty sure the Heroku instance is a free instance but I'm not sure how that works anymore. I know it was initially a free instance but then they stopped. It's doing so little. Yeah, exactly. Well, yeah, I mean, it does very, very little. I mean, it does one request per sign-in basically and that request is like 10 lines of code. It's like very, very minimal. I don't think that that actually costs anything but I know Heroku changed their pricing after it was initially set up so I'm not sure if that's grandfathered or not. Yeah, it's basically zero. Okay, great. Thanks, everyone.