 Hey, welcome to my talk. It's called Ember CLI Rails, an integration love story. I wrote the title before I wrote the talk, so the love story thing has been done better by other people. So this is more of a history of the interaction between Rails and Ember. So the title is not necessarily relevant to the rest of the talk. My name is Jonathan Jackson. I work at a place called Hash Rocket. It's pretty cool. You can reach out to me at these relevant links if you want to take the time to go back to maybe 2014 or so. You can visit my blog. That's probably the last time I blogged there, yeah. And email me anytime you want if you have any questions. So I mentioned I work at Hash Rocket. There are these clowns in front. They're pretty cool. They're very supportive. I think that's the thing that I would define them the most. So this is my project manager right here. This is the first thing he said to me before I started this talk. You're the worst and you're going to blow it, but remember, you're the best and you got this. He's kind of like being a waste of wash of hair. And then, you know, it's not just the rocketeers that are currently in service. We have rocketeer alum that try to jump in here and help out, obviously. And then this morning, about two hours ago, I said I was excited and nervous and the picture's not there, but it's me being very excited and nervous. And the T-Mock 12, Taylor Mock, he's working with me on a very large Ember app and he said as long as you use a lot of gifts, you'll be fine, but I don't have any. So now I failed him. Once again, Hash Rocket. It's pretty cool. We're also hiring. Okay, so a bit of an Ember fanatic. I've been interested in Ember for a long time. And to that end, recently, I organized a group called Ember Jacks. This is a Jacksonville Ember Meetup group. And with the help of Tildy and Lindsey Wilson, we were able to get this really cool tomster made up for us. It's a paddleboarder. If you've never seen a paddleboarder, come to Jack's Beach. If you're ever in Jack's Beach, you should come to our Meetup. It'll be fun. I also co-host Ember Weekend, which is a podcast on Ember. Talks about Ember-related topics. Mostly news stuff and things that we've learned while dog-fooding Ember apps. So check that out. And maybe there'll be a shameless plug at the end if we have time. Yeah, so, yeah, so I'm Jonathan Jackson. And a little bit about my history with Ember lately. I've been working on a very large Ember app with just a lot of complexity. And it's been really challenging and fun. And to that end, we've created the titular gem, Ember's Deli Rails, and we're dog-fooding it in this large, complex app. So I just wanted to mention that real fast. So I'm going to give you a plan, kind of what I'm going to be covering. It's going to be pretty basic. I was lucky enough to have Sandy Metz help me with this talk a little bit. Just some basic slide etiquette and how to talk to the crowd. And she said, give the talk that you would have wanted to see six months ago. And to that end, I've tried to do that here. But kind of before I can do that, I need to give you a brief introduction to Ember.js just so that we're all on the same page and we're speaking the same language. But after that, we're going to talk about the history of Rails and Ember and how these two tools have interacted and historically and how Rails developers have used and utilized this front of framework. And then I'm going to introduce you to the Ember CLI Rails gem, which I am a co-author of and maintainer along with Sean Doyle and Pawful Prophecyd. And it's our attempt to kind of help facilitate and smooth over some rough edges that will become more clear soon. And then I'm going to talk about the goals of the Ember CLI Rails project and what we want to accomplish. It's not necessarily that simple, but this is kind of the end of the talk and it won't take too long. So yeah, so yeah, so a brief introduction to Ember.js. Luke Melia mentioned a quote in a talk in 2012, I want to say, saying that 98% of building an app is understanding your layers and knowing where your code should go. And I think this is something that resonates a lot with Rails developers. Very frequently, we want to get up and running quickly with new apps and new ideas and once you know where things should go, all of this process becomes a lot easier. So Ember takes this to heart and it's part of its main philosophy is just trying to compartmentalize this stuff and make sure that things are known. You have a place to put this piece of logic. And to that end, many people call this an MVC framework, front end MVC, which kind of gets a bad rap from some people. But it's only kind of MVC. It's kind of more like MVCR+, and I had another slide before where essentially this all breaks down and the acronym no longer makes sense. But yeah, anyways, so if you want to think about it in the terms of MVCR, let's talk about the router first. And I know that's at the end of the acronym, but I'm putting it first because Ember puts it first. The router is the way that you serialize your data. It's the way you nest your UI and things should be copy and pasteable. You should be able to copy and paste your URL, and the URL is at the forefront of all Ember apps. You should be able to copy and paste your URL, give it to someone else, and the applications should be able to boot into the exact state that that person was in. So it deals with application state, and it uses HTML5 APIs and some fallback stuff to ensure that the URL is updated per route transition. So you're always able to use the back button in the way that you'd expect. Yeah, so now the M in MVCR+, models are for persisting objects. This is not entirely accurate, or at least it's not quite detailed enough. There are other objects that are actually responsible for doing the serialization and deserialization, and then also doing the persistence on the back end. Those are serializers and adapters. So I like to think of models as a schema for those other objects to have the minimum set of information they need to do their jobs correctly. And then you have views, and views deal with DOM interactions. Views and controllers are going to be kind of merged soon, but I'm not going to talk about that now. Views are responsible for DOM interactions and transitioning DOM events into semantic events. So when I click on an action, I should handle the click event with a function, and then I should transition that click function into a add user so I can refer to that inside my system semantically rather than having just all these random click handlers. So controllers. So now this is the C. This is kind of the last bit of the overview here. And this is really just for presenting the data for the view layer to render. It handles computer properties, so you're able to give these to templates and they're long lived. So they don't disappear when you transition routes. They only disappear when you do a hard refresh or manually tear them down. That's important. The long lived nature of Ember gives you a lot of power and flexibility. So now you have your little primer of Ember. I know that's too basic. There are talks that I can point you to that'll give this a little bit more meat to it if you're interested. But why is Ember JS appealing to Rails developers? And I think this is a really interesting question. It's one that I found myself wondering when I see all these other frameworks around, why would I choose Ember as a Rails developer? Yeah, so the first one is Yehuda. So Yehuda Cats is, or was rather, Rails Core started Rails Core in 2008. And then for two years worked on the Merb Merge. During this time, Rails was in, there was a lot of work to be done with Rails. And he was pushing a lot of that. And then in 2010, the Merb Merge happened and we got Rails 3. So that happened in 2010. And then he remained on Core doing a lot of really good work until 2014. And in 2011, Ember was released and he's the co-author of Ember. So I think what I'm trying to say when I say Yehuda specifically, is that there's a lot of crossover ideas. So a lot of the pain that he was feeling in Rails were the solutions that he was trying to implement were brought over into Ember. So that's pretty important, I think. Yeah, and then this is the mantra that all new Rails developers are taught, convention over configuration. You should be able to get up and running with Rails. And you should be able to get up and running with Ember very quickly. And you should not have to waste all of this cognitive mental ability. You shouldn't have to waste it making all these micro-decisions at the onset of a project. A lot of decisions should be made for you. And they should be made with the community at large in mind so that you get a rich and varied understanding of the problem space. And I think this is something that really resonates with a lot of Rails developers. Shared nomenclature-ish, kind of, there's an asterisk there. So views are not views and controllers are not controllers. But I think it gives us enough understanding, shared understanding to start very quickly tying the connections as Rails developers. You see Ember and you're like, oh, okay, I'm used to seeing logic, I'm used to seeing structure. I'm used to seeing knowing where to put things and all this stuff. And the shared nomenclature allows you to quickly draw out that little mind map so that you can start building things. And this is something I mentioned earlier. Obviously it's on meaningful URLs. Rails does this really well. It's restful typically, and the idea is to keep the URL focused on resources. And there's just a slight shift in Ember to basically making the URL represent UI nesting. But the importance here is that Rails developers are already taking the URL into account, and it has to be first class. And then the final and probably most important is that there's a focus on testing. Ember really tries very hard to ensure that you're able to test everything. And Rails, that's the other focus. You know, Rails really wants you to be able to test your things and have this like security and the knowledge that your code will work when it's deployed, that you can bill a client and confidently say that their product is what you said that their product would be. So that's something that Ember and Rails definitely have in common. Yeah, so Rails loves Ember. I don't know why I have that recap slide. So to that end, I wanted to mention this real fast. In EmberConf, 201 created a consultancy in New York City, released a survey that many people who are going to EmberConf partook in. And this is one that I thought was particularly apt, especially for this talk. I don't know if you can see, it's probably really tiny. But the big bar over on the left is Rails. And this is all of the people who are using Ember at EmberConf. What do they prefer to use for their server side? And the overwhelming percentage is Ruby with over 50% using Rails as their back end of choice. Because it's just productive. There's just a lot of things that Rails gives you. It's great, it's awesome. There's really, you can get up and running and be productive very quickly. So, I don't know, I think that's why Rails loves Ember. I think people see these commonalities and they just dive into it and they're like, I'm going to try very hard to see where these pieces will fit. And if you get it to fit, then you're going to have this explosion of productivity. It's pretty cool. Yeah, so now we're going to move into the meat of the talk here. Talk about a history of Rails in Ember. The history, sorry, I had changed it from an indefinite to a definite article because I'm actually describing real things that actually took place, not just kind of, you know, hand-wavy stuff. So yeah, so the first, in the beginning of Ember, Ember used global inline templates. So, once again, the slide is probably a little too small, I expected, I should have zoomed in. But you can see that there's actual inline templates being embedded into the HTML. And then you do some include tags to ensure that you have all of Ember and all of Ember's dependencies loaded. And then you can just create the JavaScript on the right. It's a very simple Ember application that all it does is loop over that model there and print out red, yellow, blue. And this is interesting, right? So this is still possible now. This was from just the other day. I encourage you to go to emberjs.js-ben and fiddle around. It's very valuable. And frequently, if you discover a bug in Ember, they'll ask you to go into an Ember.js-ben and recreate it here. Because if you do it here, it's a problem with Ember. And it's not a problem with your dependencies and your situation. So it's actually a really cool tool that you're able to still do this. And this is still supported. Yeah, so this is what Ember is doing in circa 2011, I want to say. And right around the same time, Rails developers kind of caught this. And they're like, we need some tool to integrate these things. How are we going to do that? So they create the Ember Rails gem. I mean, simple enough. You'll see the common pattern here when we just affix Rails to the end of whatever Ember is doing. And that's the new thing. So these boxes here represent kind of the things that, and it's not always applicable. It's kind of imperfect. I wanted the slides to kind of look right. But these are the things that you generally need for a successful web application. You need to be able to deal with your APIs. You need to deal with testing and asset compilation serving. And it's really nice to have generators to help you get up and running very quickly. So yeah, so this is globals. It's using globals, and it gives you a way to define those globals in a solid file structure. And then it uses, I believe, like string concatenation and just puts them in the asset path and allows you to serve them like you normally would. So it does pre-compiled templates in the asset pipeline. So some of the problems here are that upgrading Ember JS dependencies was kind of difficult because you had to rely on the gem to maintain this relationship. So your dependencies were difficult to keep in sync with what you want. And it's important to note here, and this is something that's common through a lot of these new transitions, is that this is still maintained. This was used from 2011 until 2013, or as the only way, really, like there weren't any other options until 2014, 2013. And it's still receiving updates from Ember Core now. So you'll see some of the Ember Core people come in there and try to make sure that the legacy apps that are still using Ember Rails still works. This is something that you see a lot. You see a lot of this extra work coming back to try to make everything compatible, Core Team, super cool. Yeah, so this is what Rails is doing, and now we're going to step back over to what Ember is doing. So I think, I'm trying to remember the dates, 2014, StepPenner starts Ember AppKit, and it's a precursor of Ember CLI. So it's really alpha software, and what the goal of this project was, was to ensure that there were solid ways, solid answers to a lot of these questions that kept arising. So as you're building these projects, how do you answer JavaScript is really difficult to develop in at the time, and probably still now. So how can we make this more pleasant? How can we make people more productive? And this was the first attempt to try to do some architecture, some build tooling around Ember to make the experience better. I use Grunt build tooling, which Grunt is a build tool that allows you to do all of this really cool stuff, including ES6 versioning. I don't have my slide clicker, so I apologize. I have to keep stepping back over to the podium. Yeah, so ES6 Transpletion. So this is when now we're able to write modular pieces of JavaScript code and explicitly import the dependencies. So we're able to start thinking about things much more modularly and working with JavaScript in kind of like more like sophisticated way. So you're not just concatting things. You're doing some intelligent things to kind of make it more enjoyable. It gives you a solid project structure, so it gives you the skeleton of all of this, the places like what Luke was talking about. It gives you these places for you to put the logical chunks of your code. So you know where and what to do and how to start building your project. And this is a plus or minus. It's front and back in package management with NPM and Bauer. This is kind of asterisky. They do good stuff, but yeah, they're pain points. And this next slide, I am only including because I spent a lot of time in Pixelmator making it, but that's Bauer. That's Austin Bauer, sorry. Yeah. And something I want to make clear about how Ember AppKit worked is when you installed it, its goal was to give you a skeleton structure. So you would actually clone Ember AppKit and then delete the .git directory and then get in your own repo and then you just build inside of that. And that's fine and all, but there's no upgrade path, so upgrades are really hard. And this is kind of a problem. This is a really big problem. So people who are early adopters of this software had difficulty trying to get the latest and greatest. So people were asking these questions and saying, well, this didn't work or this works and whatever. And as the project's maturing, they're finding more and more solutions to these problems, but people who already implemented it found it really difficult to find a way to get those new changes in. So it's very important. And of course, Rails, once again, the Rails community kind of rallied and said, okay, Ember AppKit is a thing. Let's make a gem to let us use it right now. So it has Rails generators for AppKit resources. This is something I really want to stress. These generators were not just shelling out to grunt. They were actually rewritten in Rails. So there was double work here. Not only were the people working in AppKit trying to get grunt to do all the right things, there were other people and sometimes the same people working on this project to make sure that the generators stayed in sync with what was available at Ember AppKit. This is really painful. This is not a very good workflow because getting these things, keeping these things in sync ended up costing a lot of people a lot of time. But yeah, anyways, those are kind of negatives. I'm trying to explain the cool parts of it. The tests are accessible in Rails land. So you can write QNet tests and you can access them via an engine, I think. That's really cool. So you're able to kind of do QNet tests and test your JavaScript in a sensible way and you can kind of view it in Rails and have it be accessible via the command line. It's pretty cool. It did some simple API versioning, which I think talks to some of the maintainers of this gem. And the simple API versioning was great for the majority of cases, but there were some edge cases that were a little weird. And it compiled AMD. So this is from Ember AppKit, but it compiled AMD. They had to write the way that this compiled AMD by hand in order to get some speed boosts over grunt. So that was another pain point where there's a lot of double work. And upgrades are hard. Upgrades are really hard. So once again, if you start an Ember AppKit Rails project, getting the latest and greatest Ember AppKit stuff is just hard. It's not easy. So that's what Rails is doing. The Rails community is doing to pull in this Ember work. And it's a really solid effort. I think it's a very noble goal to do. And then we see the successor of Ember AppKit, Ember CLI be announced at EmberConf 2014. And I think the work began a few months prior to that. And it changed a few things, including the build tool, which before was grunt, as I mentioned. But now is Broccoli. And Broccoli is this really clever abstraction for dealing with the asset pipeline problem. And it's very extensible. So they were able to build really robust toolset for quickly building assets and quickly building and rebuilding assets. It had a testing harness out of the box. So did Ember AppKit. But this is a much more robust solution. So you have test them straight away. Test them allows you to run your test against multiple browsers in your command line. And that's really cool. And I think it's really cool because you can even do things like spin up a VM and have your tests run on an IE virtual machine. Just really, really highly configurable, very robust. You can still access it via an Express server so you can actually go to a browser and run Cunit tests there. There's constant improvements. So in 2014, when Ember CLI was released, there were maybe five or six Ember shared libraries. Libraries that if you started an Ember app over here and you started over here, you would be able to share eight-ish libraries. And three or four months after Ember CLI was announced, they announced that they were going to incorporate add-ons. And add-ons allow you to write really super compartmentalized code and customize your Ember CLI experience without having to actually get changes merged into Ember CLI. So it allows you to make Ember CLI work for you in like a much richer variety of ways. And now add-ons, there are over a thousand add-ons. So within the space of a year, people have really gotten busy putting these new tools and making Ember CLI more robust. So now I'm able to start a project and incorporate things. I need a button. I need this kind of simple auth or something. All of these things. If I need these things, I can just pull them in with one command line rather than having to reimplement it myself. And upgradeability. The upgrade story was the main focus, I think, of Ember CLI. That's my personal opinion. I don't know if that's actually true. So Ember CLI is a command line interface, obviously. And it provides you a command called EmberNet. So once again, the skeleton structure was kind of the goal. Ember AppKit tried to build this way for you to clone in a project structure, make it your own, and then start building right away. And Ember CLI is trying to do the same thing, but now to create that skeleton, it uses these things called blueprints. And then when changes are merged upstream of Ember CLI, you're able to get these changes pulled into your code by doing this guided upgrade with blueprints used as diffs. So for each file in the default skeleton, you're going to see a diff of what was pushed on to the latest version you're upgrading to and what you have. And you're able to actually reconcile those two things so you can very smoothly upgrade. It feels a little clunky at first, but once you do this two or three times, this turns out to be a very elegant way to keep on the latest and greatest thing. So we got here to this Ember CLI land and everything's kind of good and everyone's pretty happy. So how do the Rails developers decide to use this and utilize it? Well, they didn't build a gem. They just completely separated everything. And in an ideal world, if you start talking about architectural purity or the kind of where things, where the separations should live, this kind of makes sense. So both sides are tested independently. It allows for greater specialization. So you're able to focus on your strengths and you're able to hire for very specific sections of your code. The test independently means that you have to write your integration tests stubbing out the back end in Ember and then you write your API tests in Rails. And that turns out to work okay. It gives a flexible back end. I know we're all Rails people here, so we want to use Rails and I think that's a good choice. But if you wanted to write it in something else, you can do that. And it's kind of separation of concern at a system level. So you kind of keep things completely separate. So this sounds great, but what are the kind of perils or pitfalls of using this style of approach? I know DHH mentioned monoliths. This is not a monolith. These are disparate things and trying to keep them in sync becomes difficult. So this is not an integrated system. I'm sorry, integrated system. So there's no full stack acceptance testing conventions. It's not that you couldn't do it. You can do it. I'm going to show you a slide in a minute that shows you some of the ways that we work around things. So there's no full stack acceptance testing conventions. But you could use Forman to spool up either side, the Ember app and the Rails app and then proxy one to the other and then point QCumber to it. But you can see already if I go to another project, I'm going to have to reintegrate this. This is not what we were talking about earlier where this convention over configuration. We don't want to make these micro-decisions at the beginning of the project. So it's ad hoc development workflows. This goes along with the same thing. A lot of conventional problems here where you just don't know what to do. People are struggling. People are investing a lot of time finding the answers to these questions. So it's cool. People write things like this. This is actually out of one of my original apps that I did separate. I don't know if you can see the code here, but can everyone see it? Cool. So it's a rake file that you run just rake and it's going to spool up the things because it assumes that back end and front end, back end being the Rails app and front end being the Ember app live in the same directory and it boots them up and points them and hooks them all up together and then you can develop. But once again, I'm having to do this and I'm probably not going to do this the same way twice. Two teams are probably not going to do this the same way. And it doesn't work well with existing applications. So what people try to draw here is when you start working with Ember CLI if you say, oh, I have an existing app and I want to use Ember CLI, people will tell you just do a rewrite and separate your app and have this complete separation. But that's not possible for a lot of people. A lot of people have invested years building these applications and have teams that are Rails focused and need transition periods to learn new technologies and proficient at these advanced things. And once again, a learning curve is not always easy. So it doesn't work well with current applications. Complete separation doesn't work well with existing applications. Deployments can become more complicated. So once again, this has to do with conventions. A lot of this has to do with conventions. There's knowing what to do and when to do it. But you can see that it gets pretty complicated. So Ember CLI deploy and Ember CLI add-on that is geared towards deploying Ember CLI apps with XYZ back-end. Rails is very common. And a diagram for that looks a little bit like this. So I'm not going to go into too much details. This is actually an excellent architecture and once you get this running, it's amazing. But you can see that you have to do a lot of upfront work trying to understand why these things need to be done this way. A lot of this has to do with cores. You want to serve your index HTML from your Rails server, your API server and then you want to serve the assets from CDN behind CloudFront and trying to make sure that those things both know because the assets are fingerprinted know about each other. You have to use Redis as an intermediary. Once again, this is actually a really great solution but it's a little more complicated and it would be nice to wrap this up. So yeah, so that's the pitfalls. So where does Ember CLI Rails and the gem sit? Well, this is my favorite part of the talk. It's the only animation I have in all my slides. Hold on. Someone say whoosh. Yeah, there we go. Okay, so the responsibility of Ember CLI Rails kind of sits like this and you'll see that this looks immediately very familiar to the way Ember App Kit did it. Ember App Kit Rails did it. The gem to utilize Ember App Kit. It's even thinner. So it's not trying to rewrite the generators. It's not trying to do the job of Ember CLI. All it's doing is it's doing the bare minimum that it needs to do to allow you to close the air gap between the front and the back end with Climbsley Separation. And it's trying to let both Ember and Rails do their own thing, independent of one another. So all of the commands that you use for Ember CLI still work. You still use Ember generators. You don't use Rails generators. You still write your API and everything kind of works great. And then this testing block kind of sits right in the middle and it allows you to do both integration tests and use unit tests just like you would with Ember and Rails. So you write your RSpec API tests and QUnit and integration tests for Ember and then you can write full stack QCumber tests if you want to or whatever acceptance testing framework you'd like. Yeah. And the goal here is once again to avoid the double work of trying to keep these two rapidly moving ecosystems together and unified. So it's really just trying to be a very, very, very thin layer. The thinner the better layer to just kind of give you some of those conventions and solve some of those pitfalls of complete separation while still allowing you to kind of know where your code belongs. So how does it work? It's a... This is kind of a... This is not a hand drawn. This is a hand drawn sequence diagram. There's actually a tool called JSSequence that lets you do this and it looks all hand drawn. It's awesome. I recommend it highly. So the user will request a page from Rails. Rails intercepts it and say, okay, I know that I need to start or restart the Ember build process and wait for the assets to be built so Rails knows where the Ember apps live. Oh, apps plural. I should say that. This, unlike all the other tools, allows for you to include multiple Ember apps. So you can have multiple, you can have an admin panel filled with all of your... an entire Ember CLI app that is only dedicated to your admin panel and then, you know, your rest of your front end can be in another Ember CLI app and Rails still is the one place, the one hub and it's just thin layer. So it's just saying, okay, request a page, start or restart Ember. Ember builds and then when that's done we do some locking stuff to make sure that you don't refresh and get a weird invalid state and then you read the assets and you serve them back to the user via the asset pipeline. Yeah, that's... So how do you use it? So you start with an Ember app and then you can actually place the Ember app anywhere you'd like but I prefer to put mine inside the root level of the Rails app under a directory called front end and then any subsequent also in the root of the application because it just makes things a little bit easier and then you run break Ember CLI in it and that produces this initializer and you're just telling Ember... or you're telling Rails rather where the Ember app lives and then there's many configuration options here to make this a little bit more customizable and work for you better and then this is from the Readme and you can actually do this by putting the... well, I'll explain that in a second. So you put a root path and then you render an index and then in your index page so now when you go to slash the app this ERB template is going to be rendered and it's going to load the... with the two helpers there it's going to load the Ember assets so that your Ember app can be loaded. So Ember CLI will have already built your assets into this nice AMD and then it's going to be included in the top of your file when you come from Ember CLI are also going to be included. I'm actually really close to the end of the talk so we might have time to do some demos. So the goals of the Ember CLI project the thing that I want for people to kind of understand about this project is that first off this is a graph of commits over time to the various projects we talked about in this talk. So the blue line starting in 2011 is Ember Rails and then the red there is Ember AppKit and you can see that that was almost two years where the way you used Ember was you used Ember Rails if you wanted to use it with Rails. Then Ember AppKit came on unseen and at EmberConf 2014 it was announced that Ember CLI was going to be kind of the way forward and it was eventually going to be included in the Ember like ecosystem officially with actual core team support the explosion of commits that happened after that and this is only from January when I initially created this this graph becomes even more impressive when you start seeing how much work is being pushed into Ember CLI and it's really important that you know that this is not going anywhere that's the kind of thing. So Ember CLI is here to stay it's going to be a thing that we use to utilize Ember and it's really really cool it does some amazing things so with that in mind you know Ember has some 15,000 commits or so and Rails has like 50,000 commits I don't know, a bunch maybe 5,000 a year for 10 plus years I want to say and these ecosystems are vibrant they're filled with energy, they're filled with people like you going out there and contributing to the code and it's awesome and I want to use both of these technologies but I don't want to have to keep rewriting these things and doing the double work I want a very thin wrapper that allows these two ecosystems to work together but evolve independently that's the real thing so that's the goal of the Ember CLI Rails project and to that end I think we're going to continue pushing and asking questions on how we should integrate these two services I would like to see I would like to see Ember CLI Rails become even thinner and the interaction just be those conventions right now we're having to use the asset pipeline pipeline in Rails and we're also using an asset pipeline in Broccoli and that seems like double work, why are we doing that so we're probably going to push that even further out but there's a lot of questions to be asked but right now you can use it right now and start using Ember CLI in your Rails apps so yeah so maybe we have time for some demo first off I'd like to thank HashRocket for the time to kind of work on this talk and some design help and obviously all the support that they give me and then I want to personally thank Sandy Metz and Terence Lee who helped me kind of refine these slides yeah I think that's it do we have time for demo? how much time? two, three minutes? okay cool I thought I had changed that so I mentioned earlier that the URL was the URL was at the forefront of Ember's philosophy and kind of to that end I noticed something and this is not a poke at your Jabbit Rails conf particularly this is something that happens to conf a lot of things it happened to Ember conf website acted the same way but you can see when I changed this with JavaScript I'm getting all the new updated schedule right but the URL is not updating so if I go to Thursday and I scroll down a little bit and I press refresh it just kind of like takes me back to Tuesday I go back in time and you know something like this is the shameless plug so this is the podcast site that I mentioned that I work on and you can see that when we go into things the URL is updated we're not actually doing full page refreshes and if I refresh I'll be on the same page and the URL is at the forefront so I don't know that's the kind of quick demo I wanted to show hopefully this will get you really inspired to kind of start looking at Ember's CLI it's an awesome tool and you can use it now in Rails apps so thank you very much