 There we go. All right, making the pieces fit. My name is Paul Derwald. I live in Halifax, Nova Scotia, Canada. And I'm here in the UK for the next couple of months. My wife is on a fellowship at Oxford. So that's what brings me here. Yeah, I'm happy to be here. I'm excited to meet all of you. So I have been a little bit quiet because I'm a little bit nervous. But after when we're having some beers, I'd love to meet all of you. I have been a web application developer since 1999, working in a really obscure framework called OpenACS, which none of you have ever heard of. And if you have, I'm sorry. In about 2006, I switched to Ruby on Rails and life got a lot better. And I've been an Ember developer since right about now. I just started, I've been meaning to get into it for a few years as I understand many of you have. It's one of those things that I want to do this but it's hard to get into it because I've got my day job or my client work that's keeping me back in whatever I used to do. Anyway, I decided a few months ago that I'm gonna do it and I got into it at least a little bit until my clients started ringing at my door again and needing more. So this is sort of my first foray into Ember development and sort of getting my head around how Ember hangs together. I find that the guides are a little bit hard to get into because of how they're written. They're written from a very, they're written from a perspective that says this is what a controller is but it doesn't really tell me why I would use a controller and I've sort of had to tease a lot of those things out as I've used the framework. If any of you have written a non-trivial Ember app you already know everything that I'm gonna say today and if you are also that experienced you're probably gonna find all sorts of mistakes in what I'm gonna say. So please be gracious. Those of you who have the experience. Those of you who don't, think of this as a journey with me and my understanding of how Ember works and hopefully there are some grains, little things that you can latch onto that will help solidify your understanding if you think at all the way I do. And as far as that goes, the way I learn my bias in when I pick up a new framework is that I really care about the architecture and more specifically understanding the architecture. I need to see the structure and how the pieces fit together and only then can I work with it. I'll stare at a bunch of code, even a few lines and I'll be googling all over the place to figure out how the code is supposed to run rather than simply running it to find out because I just want to know how it all fits. I'm a little ambivalent about magic in the development environment and this is because I've been burned by all the magic and Ruby on Rails. Things just happen and you're not really sure why. So a fair bit of this talk kind of digs into what I think and what I've been able to test is actually happening in the background. I haven't gone into the Ember source. I'm not that dedicated or not that courageous is a better word. So I haven't gone that far in yet but anyway, these things have helped me figure that out. All right. So what I'm gonna do is we're gonna start by looking at a very simple Ember application. For those of you who are further back, this might be hard to see because I'm trying to cram a lot of code onto the screens and it might be hard to see from the back. I looked, I was able to see it. Certainly some of the examples, code goes right to the bottom of the screen so you will struggle with that so if you stand up, I wouldn't blame you. So here's a really, really simple application that you've probably seen, probably written yourself. ember.application.create, here's some content. For me, what blows my mind is that this actually works. I don't know why it works at a glance because there's nothing here that connects app to what's in here. So something magical is happening and that is what I'm sort of gonna talk about first. What I've learned, when you type this, it automatically, the ember application automatically sets up a router, router, the UK expression, the Canadian, I'm gonna say router and router and it's just kind of interchangeable so bear with me. It automatically sets up a route for the slash path. In fact, to be more specific, it sets up a slash index and I'm even munging details a little bit which I'll get into later. And then ember will also set up a route for you. So the router points to the route and then it will set up a controller for you and it'll set up a view with a template that finally refers to the index. So now it makes sense to me why I can see the content on the screen. So all of this stuff just happened magically. And in fact, there's one more subtlety which is ember also created an application layout which has simply an outlet. So that's where the data goes in. The content that you are rendering goes into. So after much puzzling and much searching, I came up with sort of a bit of an architectural diagram very loose of how ember works or how ember is organized. There's the router which has the maps to all of the different routes. The route sets up a controller and loads a model and sticks it in the controller or any number of models and it can set up any number of controllers. The controllers instantiate views and the views render templates. You've probably pieced all that together but I didn't in my travels find a picture that showed it to me in that way. So this for me has been kind of helpful to organize mentally where all the pieces come to. So I'm gonna show some an example of how some of this hangs together in an app. Here I have much of what we had before. In this case I've created a route called high and I have two templates, one that links a link and a link to the template and it works as you would expect. You click on say high and hello world pops up. What's happened in the background is that a high route was created as was a high controller and a high view. And so, and here I'll change, I've changed the word route to resource. This in and of itself just changing that word route to resource doesn't do anything but as soon as I add an empty function to it magically I get a high route and I get a new high index route. So note I've still got this content here. Everything still works as it did but there's a little bit of a subtlety. So here I've now changed the template a little bit so I've got high index which refers to says hello Ember London. When I run this code and I click the link I would kind of expect high index to appear because the flow, or backing up a little bit. When you set this up, when you back here when I ran this I had in my own development at home I set up some logging when each of these routes was activated and the flow works, the flow runs when I view this first the high route is activated and then the high index route is activated. So the flow works through each of these. So my thought was that when I added hello Ember London that I would see high index rather than high. That's not actually what happens I get hello world. The reason why is because when I used the word resource Ember gave me an outlet and I did not expect that. So once I created an outlet or I added the outlet to a layout the content appeared as it happens here. Is everybody following this at all? Okay, I don't know if it's advanced or not or whatever. Everybody's learning at a different level. So I have another example here. I've added one more route, hey, so high end hey because that's what you do when you're writing demo code. And I've kept this and I've got hello Ember London. I have a link from the hello world to this and what you'll be able to see is that the outlet or the layout for the high route is maintained for both the high index and the high hey routes. So let's return to the Ember architectural diagram. This is one of the other things that I've sort of as I was working with Ember I was trying to figure out well, how do I make these pieces come together? How do I write a non-trivial app? The examples you typically find on the net are the to-do app because there are countless to-do apps. That's what you write these days. Seven years ago it was blog applications that you wrote. So now with the to-do apps they work with a single model and it just all flows really naturally. You have a router and to it you attach a route and the controller is created. There's a view that's instantiated. A single model is used and a single template and that's the relationship. It's a one to one to one to one to one to one ratio or relationship at least that's what is implied in how everything is set up. And I think part of that implication is because of the word resource. Coming out of the Rails world resource means that there's a single model and that you are interacting with a single model and you're creating a CRUD framework around it. So CRUD create, retrieve, update and delete. When you set up a resource you're saying here is a post. I'm going to be able to view it. I'll be able to edit it. I'll be able to create new ones. But it's this sort of vertical column of functionality based around a model. And that's what everything leads to. Now I can see this. It makes sense because it's really, it makes great demo because well you get all this code for free because of all the magic that you get. And it's kind of fun to explain and it's just easy to work with because it's simple. But I don't think it's quite real. I think real applications have you with a single, you might go to a single URL but on that page you'll be looking at half a dozen or a dozen different models and they'll be presented in different ways. And so for me I've started to view Ember as having sort of these two sections of functionality. Over here where the router and the route is that is, that's the way, that's what the URL is. So that's what appears in my address bar and with the resource route that's what I see, that's the layout that I would be provided. On the other hand, the controller and view and template, this is the content that gets put into the various outlets that are provided by the route. So this is about the content, this is about the flow to get to that page. In the middle is sort of this glue and I didn't give it a circle because it's nothing that I would actually circle but it's the route that is, I can picture the route like an army general. So the army general has a whole lot of controllers, the troops at its disposal and it has a whole lot of arms, the models and it equips each of the troops with some amount of models and it sends them out into the webpage battlefield to display themselves. So this is how I've sort of come to think about it. So yeah, so I'd like to show an example of how I broke away from CRUD, broke away from thinking of a single vertical column of functionality based around a model and I'm gonna just talk about one route and show multiple outlets coming out of that route. So this is what's gonna be a little bit hard to see. The example will go all the way down so if you can't see at the back, now's a good time to move forward, but anyway. So I'm creating an Ember application, I have two outlets that I've named outlet one and outlet two and I have a template for the main index content, the content for outlet one and the content for outlet two. And what happens when I run it? As expected, there is no content for outlet one or outlet two, it hasn't been wired in yet. However, the content for the main outlet does appear the way I want it to. So in order to get this to work and again, thinking about it like the route as an Army general, it's saying I have a bunch of controllers, I have a bunch of models, well in this case, I'm not using any models, but I have a bunch of controllers and I'm going to say here controller one, go over there to outlet one, controller two, go to outlet two and I want you to take care of things. I'll get there a little bit slowly. Here I'm saying I would like the index route to render the contents of template one using the current controller into outlet number one and the same thing with outlet two and then render itself and low and behold, it renders the way I want. What did I do here? Oh yes, so in this code, I've just added a little bit of content and a handlebars expression to include some extra content and how do I get it to appear? Well, I created an index controller which provides some content and the content appears all the way through but I can provide different controllers and apply them to different outlets and give them each their own content. So now I've created, I still have the index controllers before, I've added a one controller and a two controller so they say foo bar and baz. In the render template, I find the controller which is here over the controller for one and it's nomenclature that connects them. Controller for two, it connects it and then I render, I tell the route to render with, into the outlet one with the one controller and into the outlet two with the two controller and the different values appear. Oh, there we go. So that was sort of a whirlwind quick tour. In summary, what I've tried to do here is talk a little bit about the magic of Ember and try to demystify because for me, I really got stuck on what the magic was. I couldn't see how I got from A to Z. It just didn't make sense until I broke it down and traced how the code execution worked all the way through from front to back. I showed a picture of the architecture of how I think Ember is all kind of assembled, more or less and I hope I've shown how to kind of break free of implicit constraints. This has been useful for me to start to break beyond just a to-do app into something somewhat more complex. So thanks very much. Are there any questions? Please. Did you come across the render helper, the render handlebars helper that's all in your adventures? Render handles bars helper. No, no I did not. Question is, did I come across the render handlebars helper and no I did not? So it's in a similar territory to what you've done there. It will render, say you did render one, it will go get the one controller and the one template and render it in that place that you said. So it's still assuming you're working with that singleton controller. Oh, okay. Whatever model is wired into that controller at that point in time and then you can kind of place it anywhere. And so it saves you doing the this.render in the root if that's the approach you want to take. Right, I guess that would unleash more magic. And at my level, I don't know how to control the magic yet. Yeah, you have to know where it's getting all the stuff. That's right. Knowing that what I'd probably do is still write it the hard way and then refactor it to do it the easy way because I just I need to understand it at a very basic level in order to make all the pieces fit. There else? Yes. Do you think that the magic that's happened for those easy initial steps makes Ember harder to learn? Do I think that the magic that happens for the initial steps makes Ember harder to learn? Yes. Yeah, the magic, it's something that I find the demo articles or the guide articles, the guides on the website, on the EmberJS website and anything else that I've found. They all love the hand waving of the magic. Look, you can do this. And I, but I just don't understand why. I don't understand how. So that has really tripped me up. And it tripped me up a lot in the Rails time as well. Later on, I appreciate the magic, but I wish I wish that introductory articles would actually be a little bit more tedious and explaining all the details. And later on, only when I understand the details, then I'm ready for the shortcut. But when I was in a high school calculus class, the first derivatives I did were all done by hand and it was painful. And then afterwards, the teacher said, okay, and you can also do it like this and showed a really quick way. And I'm like, oh, okay. But at least I understand how it works from first principles. And the guides with the magic, they just never get into the first principles. Yes. So what's our next step after you? My next step? Oh, so if I can echo that back to you. Now that I've learned what I have, would I continue working with Ember? How would I? Well, continue working with Ember, absolutely. I've bought into the philosophy of Ember and I want to know how it works. I want to be a part of the community. I want to benefit from the good things that are happening in that space. How would I go forward? Well, the nascent of this talk was a couple months ago when I had a bit of free time in my schedule, I started to write a non-trivial application. And part of the way I learn is I jump in head first. For me, the only interesting application is one where I'm talking to a database, I have many models, I'm showing the stuff, showing all sorts of things on the screen at the same time because that's what my customers pay me to do. So if I can't do that, I'm actually not interested in solving the problem. I have to go all that way. So my next step is actually my current step. I've been working on an application for a simple data set for my wife actually. The reason that we're here in the UK is because she has a fellowship at Oxford, she researches 18th century German opera and I have a small database of operas, composers, librettists, performances, the different pieces in the opera. There are enough models, but it's a very simple relationship between those models. So my goal has been to write an application where I can just browse the different parts and using Ember data to set up the relationship between the different models and what this actually feels like. And well, it took me weeks of just plodding along and getting the smallest things because it kept getting tripped up by the complexity of the framework at the outset. But I'm starting, I'd say I'm at the point where if you ski, you sort of ski to the edge of the hill and you're about to go down and I am about to go down. I can feel my acceleration picking up because I'm starting to understand these concepts. So this talk is, I've just finally made it far enough so I'm not falling down all the time while I ski and I'm ready to go for real. So does that answer the question? Yes. Why would I pick Ember over other frameworks? This goes back to my days with Ruby on Rails. Around the Rails 2.3 era, if any of you are Rails developers, I once, I had a problem with some code that I was working on for a customer and I had to dig into the Rails internals and it was a horrifying experience. It was so convoluted and I found a bug somewhere or I found a bug in a test because it was actually a tautology and there's so many things about Rails where it just seemed deeply, deeply broken and I thought, I can't hitch my future to Rails. And then Merb happened and then Merb became Rails 3 and behind Merb in Rails 3 was Yehuda Cats and Yehuda Cats is behind Ember. So fast forward wherever Yehuda goes that's kind of where I'll go because he's really, really bright. He's a lot brighter than I am and I trust him. I've also heard him speak at a number of conferences and one of the things that the core team of Ember say, one of their goals is that they want to make, that Ember is about writing ambitious applications and they want to solve hard problems and make hard problems easy to deal with for the average developer, for the run of the mill developer the developer is just trying to get things done. And I appreciate that. Yehuda would refer to the other frameworks at the time. This was a couple of years ago. So things certainly have changed but he talked about how they're leaving all the hard problems as details for the developer to figure out. Whereas Ember is just sort of like, no, no, no the hard problems, we're gonna figure those out. We're gonna do that and they've taken their time to do it right and do it the solid, well-grounded way. So although I'm having a hard time figuring out how it is that Ember hangs together, I have faith in the people who are developing it but they've done a really good job making it hang together and I'm gonna hitch my wagon to it. Anything else? Thank you.