Rails and EmberCLI
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Part Number | 85 | |
| Number of Parts | 94 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/30692 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Common Language InfrastructureMultiplication signEndliche ModelltheorieService (economics)Point cloudPower (physics)Group actionMaterialization (paranormal)Projective planeNumberWater vaporEvent horizonRule of inferenceSemantics (computer science)Error messageSicObject (grammar)SpeciesSpeech synthesisSerial portBuildingCodeFunctional (mathematics)Complex (psychology)Physical lawAdaptive behaviorSoftware frameworkUniform resource locatorProcess (computing)Link (knot theory)Asynchronous Transfer ModeInformationInteractive televisionCartesian coordinate systemWordResultantGraph (mathematics)RadiusState of matterSoftware developerMonster groupQuicksortGame controllerBlogComputer programmingConfiguration spaceRoutingControl flowTemplate (C++)Category of beingSlide ruleINTEGRALTerm (mathematics)Natural numberRouter (computing)Lattice (order)BitExecution unitVideo gamePhysical systemRandomizationFormal languageWeb pageMobile appVolumenvisualisierungLogicOnline helpMereologyVelocityRight angleView (database)Data managementMaxima and minimaSet (mathematics)NeuroinformatikBootingNetiquetteCore dumpChromosomal crossoverSmoothingComputer-assisted translationFront and back endsExpected valueEmailComputer animation
09:33
Axiom of choiceLengthDecision theoryPosition operatorFocus (optics)Electric generatorProjective planeSolid geometryLine (geometry)Right angleMultiplication signNoise (electronics)Software testingACIDProduct (business)Poisson-KlammerBuildingSlide ruleView (database)Point (geometry)Game controllerWordBounded variationProcess (computing)Information securityCodeComputer fileData structureClient (computing)Data managementFront and back endsTemplate (C++)Computer architectureReal numberWeb applicationEndliche ModelltheorieLogicSummierbarkeitReplication (computing)Connected spaceSkeleton (computer programming)Semantics (computer science)Information technology consultingArchaeological field surveySynchronizationSheaf (mathematics)WeightMedical imagingPattern languageCuboidShift operatorSoftware developerLevel (video gaming)Mobile appDigital electronicsComputer configurationSoftwareSemiconductor memoryNumberDirectory serviceServer (computing)Group actionCore dumpAlpha (investment)Uniform resource locatorBinary fileSoftware bugCloningSoftware development kitCompilation albumModul <Datentyp>Revision controlWritingCartesian coordinate systemShared memoryGoodness of fitString (computer science)Social classLoop (music)Computer animation
18:54
Line (geometry)Software testingCuboidMathematicsCodeProjective planeWeb browserMultiplicationFlow separationSoftware developerRevision controlComputer architectureDifferenz <Mathematik>Default (computer science)Computer fileWritingRight angleMobile appCartesian coordinate systemVariety (linguistics)Software maintenanceCommon Language InfrastructureView (database)Library (computing)CASE <Informatik>Execution unitOrder (biology)Data structureAuthorizationAbstractionSkeleton (computer programming)Point (geometry)Doubling the cubeSpacetimeStress (mechanics)Electric generatorMultiplication signDecision theoryINTEGRALUnit testingVirtual machineLogical constantNegative numberFront and back endsBootingSynchronizationAxiom of choiceFocus (optics)Sheaf (mathematics)Proxy serverSubsetLebesgue integrationSlide ruleLevel (video gaming)Physical systemMedical imagingSeries (mathematics)Real numberLattice (group)Solid geometryElectronic program guideBuildingACIDGoodness of fitDebuggerQuicksortPoisson-KlammerConstructor (object-oriented programming)SkalarproduktraumCellular automatonMereologyError messageBit rateProcess (computing)AverageScripting languageSymbol tableProduct (business)Shared memoryMetropolitan area networkCivil engineeringTexture mappingCommitment schemeConfiguration spaceVideo gameInheritance (object-oriented programming)Position operatorService (economics)Directed graphComputer animation
28:14
Template (C++)Cartesian coordinate systemWeb pageFocus (optics)Poisson-KlammerStructural loadProduct (business)Real numberWrapper (data mining)Subject indexingSemiconductor memoryElectric generatorACIDFlow separationMaxima and minimaLie groupGroup actionService (economics)Interactive televisionStudent's t-testMultiplication signDimensional analysisIndependence (probability theory)FrequencyCurveBlock (periodic table)WebsiteSoftware testingScripting languageOnline helpAreaSlide ruleRootConvex setGraph (mathematics)Rule of inferenceQuicksortElectronic mailing listNumberFigurate numberReading (process)MereologyComputer configurationCodeTheoryFood energyMaterialization (paranormal)State of matterWordUtility softwareSequenceProcess (computing)BuildingSystem administratorLine (geometry)Projective planeServer (computing)FingerprintExecution unitComputer architectureDiagramSpherical capVideo gameDebuggerWritingINTEGRALSubsetComplete metric spaceSoftware frameworkContent delivery networkSequence diagramBookmark (World Wide Web)POKEMobile appFront and back endsDemo (music)2 (number)Home pageMultiplicationDependent and independent variablesInclusion mapEntire functionCore dumpRight angleLevel (video gaming)Common Language InfrastructureConfiguration spaceControl flowDirectory serviceComputer animation
37:35
Right angleBitPoint (geometry)WebsiteFitness functionWeb pageIdentifiabilityDemo (music)Computer animation
Transcript: English(auto-generated)
00:01
Hey, welcome to my talk. It's called Ember CLI Rails and Integration Love Story. I wrote the, I
00:20
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 Hashrocket. It's pretty cool. You can reach at me, reach out to me at these relevant links.
00:42
If you want to take, 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, you know, email me anytime you want, if you have any questions. So I mentioned I work at Hashrocket. There are these clowns in front. They're pretty cool. They're very
01:03
supportive. I think that's the thing that I would define them, define a name the most. So this is, this is the, 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 gonna blow it, but remember, you're the best and you got this. He's kind of like being wishy washy here.
01:21
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, you know, help out, obviously. And then, this morning, about two hours ago, I, I said I was excited and nervous and there, the picture's not there, but it's me being very excited and nervous. And the tmock12, Taylor Mock,
01:43
he's, he's working with me on a very large Ember app, and he said as long as you use a lot of GIFs, you'll be fine. But I don't have any, so now I've failed him. So once again, Hashrocket's pretty cool. We're also hiring. OK, so a bit of an Ember fanatic.
02:00
I've been interested in Ember for a long time. And to that end, recently we started a, I organized a group called EmberJax. 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, it's a paddleboarder. If you've never seen
02:21
a paddleboarder, come to Jax Beach. If you're ever in Jax Beach, you should come to our meetup. It'd be fun. I also co-host Ember Weekend, which is a podcast on Ember. It talks about Ember-related topics. It's mostly news stuff and things that we've learned while dogfooding Ember apps. So check that out. And maybe there'll be a shameless plug at the end if we
02:41
have time. Yeah. So, 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, you know, a lot of, a lot of complexity, and it's been really challenging and fun, and to that end we, we've created the, the
03:04
high-tueller gem, Ember CLI Rails, and we're dogfooding it in this large, complex app. So I just wanted to mention that real fast. So I'm gonna give you a plan, kind of what I'm gonna be covering. It's, it's gonna be pretty basic. I was lucky enough to have Sandy Metz help me with this talk
03:22
a little bit. Just some basic slide etiquette and how to talk to the crowd. And she said, she said, give the talk that you would have wanted to see six months ago. And to that end, I've, 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
03:41
all on the same page and we're speaking the same language. But after that we're gonna 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 the front, this front-end framework. And then I'm gonna introduce you to the Ember CLI Rails gem, which I am a
04:03
container, along with Sean Doyle and Pavel Prabhasin. And it's a, it's our attempt to kind of help facilitate and smooth over some rough edges that I'll, that will become more clear soon. And then I'm gonna talk about the goals of the Rails, the Ember CLI Rails project, and
04:20
what we want to accomplish. It's, it's not necessarily that simple, but this is kind of the, the end, the end of the talk, and it won't, it won't take too long. So, yeah. So yeah, so brief introduction to Ember, EmberJS. Luke Melia mentioned, wrote a quote in a talk in 2012,
04:41
I want to say, saying that, you know, 98 percent 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, 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, this process becomes a lot easier. So Ember takes this
05:04
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, you have a place to put this, this piece of logic. And to that end, you know, many people call this an MVC framework, a front-end MVC, which
05:22
kind of gets a bad rap from some people. But it's, it's only kind of MVC. It's kind of more like MVC R+. And I had another slide before where essentially this all breaks down and you, the acronym no longer makes sense. But yeah. Anyways, so, so if you want to
05:41
think about it in the terms of MVC R, 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, and things should be copy and pastable. You should be able to copy and paste your URL, and
06:00
the URL's at the front, 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
06:22
always able to use the back button in the way that you'd expect. Yeah, so now the M in MVC R plus. 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
06:42
doing the persistence on the back end. Those are serializers and adapters. So I like to think of models as a schema for, 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 gonna be kind
07:03
of merged soon, but I'm not gonna 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, I should handle the click event with a function, and then I should transition that click function into a add user,
07:20
you know, so I can refer to that inside my system semantically, rather than, you know, having just all these random click handlers. Yeah, so controllers. So now this is the, see, this is kind of the last bit of the, of the overview here. And this is really just for presenting the, the data for the view layer to render. It handles computer properties, so you're able
07:42
to give these to templates, and they're long lived, so they, they don't disappear when you transition routes. They only disappear when you do a, a hard refresh or, or manually tear them down. That's important. The, the long lived nature of Ember gives you a lot of power and flexibility.
08:02
So, so now you have your little primer of Ember. I know that's too basic. There are talks that, that I can, I can point you to, that'll, 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, I think this is a really interesting question. It's one that I, I found myself
08:24
kind of wondering, when I see all these other frameworks around, why would I choose Ember as a Rails developer? Yeah, so the first one is, is Yehuda. So Yehuda Cats is, or was, rather, Rails Core started in, started Rails Core in 2008, and then for
08:42
two years worked on the Merb merge. During this time, you know, Rails was in, they, they, there was a lot of work to be, 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,
09:00
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, 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, the solutions that he was trying to implement were, were
09:21
brought over into Ember. So that's, that's pretty important, I think. Yeah, and then this, this is the mantra that all new Rails developers are, 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
09:41
cognitive mental ability. You should not 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, a rich and varied understanding of the problem space. And I think this is something that really resonates with a lot of Rails developers.
10:03
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, OK, I'm used to seeing logic. I'm used to seeing structure. I'm used
10:22
to seeing, knowing where to put things, and all this stuff. And, 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. This is on meaningful URLs. Rails does this really well. It's restful, typically, and, and the idea is to keep
10:40
the URL focused on resources. And there's just a slight shift in Ember to basically making the URL represent UI nesting. But the, the importance here is that Rails developers are already taking the URL into account, and it has to be first class. And then the, the final and probably most important is that there's a focus on testing. Ember really
11:02
tries very hard to ensure that you're able to test everything. And Rails, that's, 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 build a client and, and confidently say that their product is, is what
11:22
you said that their product would be. So that's something that, that Ember and Rails definitely have in Yeah. So Rails loves, Rails loves Ember. I don't know why I have that recap slide. So to that end, I, I wanted to mention this real fast. In EmberConf, 201 created a consultancy
11:41
in New York City, released a survey that many people who were 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. It's probably really tiny. But the, the big bar over on the left is Rails. And, and this is all of the people
12:01
who are using Ember at EmberConf. What do they prefer to use for their server side? And the overwhelming percentage is Ruby, with over fifty percent, using Rails, or, not Ruby, Rails, using Rails as their, as their backend of choice. Because it's just productive. There's just a lot of things that Rails gives you. It's great. It's, it's awesome. There's, there's really, you can get up and running and be productive very quickly.
12:22
So I don't know. I think that's why Rails loves Ember. I think people see these, these commonalities and they just dive into it, and they're like, I'm gonna, I'm gonna try very hard to, to see where these pieces will fit. And if you, if you get it to fit, then you're gonna have this explosion of productivity. It's pretty cool.
12:40
Yeah. So, now we're gonna move into the meat of the talk here. Talk about a history of Rails and Ember. The history. Sorry. I 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, the first, in the beginning, you
13:01
know, of Ember, Ember used global inline, inline templates. So once again, this 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's, all of Ember and all
13:21
of Ember's dependencies loaded. And then you can just create the, the JavaScript on the right. It's a very simple Ember application that all it does is going to, is loop over that model there and print out red, red, yellow, blue. And this is interesting, right. So this is still possible now. You, this is, this is from just the other day. I encourage you to
13:41
go to emberjs dot jsbin and fiddle around. It's, it's very valuable. And frequently, if you discover a bug in Ember, they'll ask you to go into an emberjs bin and re, recreate it here. Because if you do it here, it's a problem with Ember. And, 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
14:01
still do this. And this is still supported. Yeah. So, so this is what the ember, what Ember's doing in, in circuit 2011, I want to say. And right around the same time, you know, Rails developers kind of caught this and they're like, we need some tool to integrate these things. How are we gonna do that?
14:22
So they create the Ember Rails gem. I mean, simple enough. You'll, you'll see the common pallet, pattern here when we just affix Rails to the end of whatever Ember's doing, and that's the new thing. So these, these boxes here represent kind of the things that, and, and it's not always applicable. It's kind of imperfect. I wanted the slides to kind
14:41
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 do, 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, it gives you a way to
15:03
define those globals in a, 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, yeah, precompile templates in the asset pipeline. So some of the problems here are that
15:22
upgrading the Ember JS dependencies was kind of difficult because you had to rely on the gem to maintain this, this relationship. So your dependencies were difficult to keep in sync with what you want. Oh, and it's, and it's important to note here, and this is something that's common through a lot of these, these new transitions, is that this is
15:41
still maintained. This was used from 2011 until 2013, or as like the, the only way, really. Like, there weren't any other options until, yeah, 2014, 2013. And it's still receiving updates from Ember Core now. So you'll see some of the Ember Core people
16:00
come in there and try to make sure that these, these, 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, this extra work coming back to try to make everything compatible. Core Team. Super cool. Yeah. So, so this is what, this is what Rails is doing, and now we're gonna step back over to what Ember is doing. So I, I
16:24
think, I'm trying to remember the dates. 2014. Step Penner starts Ember App Kit. And it's a precursor to Ember CLI. So it's, it's really alpha software, and what, what the goal of this project was, was to ensure that there were solid ways, like, solid answers to a lot of these
16:43
questions that kept arising. So as you're building these projects, how do you answer, you know, like, JavaScript is really difficult to develop in at the time, and probably still now. So like, 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, some like, architecture, some build tooling around Ember
17:04
to make the, the experience better. I use grunt build tooling, which, grunt is a, is a build tool that allows you to do all of this really cool stuff, including ES6 versioning. I don't have my, my slide clicker, so I apologize. I have to keep stepping back over to the podium. Yeah, so ES6 Transplication. So this is when,
17:21
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 ways. So you're not just concatenating, concating things. You're doing some intelligent things to, to kind of make it more enjoyable.
17:41
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, the logical chunks of your code, so you know where, where and what to do and, and how to, how to build, start building your project. And this is a plus or minus. It's
18:02
front-end, back-end package management with NPM and Bower. This is kind of asterisk-y. It, they do good, good stuff, but yeah, they're paying points. And this next slide, I am only including because I spent a lot of time in Pixelmator making it, but that's Bower. That's Austin Bower, sorry. Yeah. And something I want to, I want to
18:22
make, make clear about how Ember AppKit worked is, when you installed it, it was only, its goal was to give you a skeleton structure. So you would actually clone Ember CL, or Ember AppKit, and then delete dot git, the dot git directory, and then git init your own repo, and then you just build inside of that. And that's fine and,
18:43
and all, but there's no upgrade path. So upgrades are really hard. And this is kind of a, a problem. This is a, 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
19:01
projects are maturing, they're finding more and more solutions to these problems, but people who already implemented it found it really difficult to, 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, OK, Ember AppKit is a thing. Let's make a gem to let us use it right now.
19:24
So it has Rails generators for AppKit resources. This is, 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
19:41
do all the right things, there were, there were other people, and sometimes the same people, working on this project to make sure that the generator stayed in sync with what was available at Ember AppKit. This is really painful. This is not a very good workflow, because getting this, getting these things, keeping these things in sync ended up costing a lot of people a lot of time.
20:02
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 Q unit tests and you can access them via an engine, I think. That's really cool. So you're able to kind of do Q unit tests and, and test your, your JavaScript in a, in a sensible way, and you can kind of view it in Rails and have it be accessible via
20:22
the command line. It's pretty cool. It did some simple API versioning, which at, I think, I think, talked to some of the, 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 you know, it compiled AMD, so this is,
20:42
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 new, latest and greatest
21:01
Ember AppKit stuff is just hard. It's not easy. So, so that's what Rails is doing, to try, the Rails community is doing to pull in this Ember work, and, and it's, and it's, 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
21:24
I think the work began a few months prior to that. And it's 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.
21:43
So they were able to build really robust toolset for using, for quickly building assets, quickly building and rebuilding assets. It had a testing harness out of the box. So did Ember AppKit, but the, this is a much more robust solution.
22:00
So you have Testome straight away. Testome allows you to run your tests against multiple browsers in your command line. And that's really cool. And I think, I think it's, 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 like, really, really highly configurable, very robust. You can still access it via an express server,
22:22
so you can actually go to a browser and run Q unit 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
22:40
you started over here, you'd 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, to actually get changes
23:00
merged into Ember CLI. So it allows you to make Ember CLI work for you in much, like a much richer variety of ways. And now, add-ons, there are over a thousand add-ons. So within, within the space of a year, people have really gotten busy putting these, these new tools and this new, like,
23:20
making Ember CLI more robust. So now I'm able to start a project and incorporate things. I need a button. I need this, this kind of simple auth or something, you know, all of these things. If I need these things, I can just pull them in with one command line rather than having to re-implement myself. And upgradeability. The upgradeability story was the main focus, I think, of Ember CLI. That's my personal opinion. I don't know if that's actually
23:42
true. So, so Ember CLI is a command line interface, obviously. And it provides you with a command called Ember init. So once again, the skeleton structure was kind of the goal. Ember appkit tried to build this, 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
24:02
to do the same thing. But now, to create that skeleton, it uses these things called blueprints. And then when, when changes are merged upstream of Ember CLI, you're able to get these, these changes pulled into your, your code by doing this guided upgrade with blueprints used as diffs. So for each file in the default skeleton, you're gonna see a diff
24:21
of what's, what was pushed onto the latest version you're upgrading to, and, and what you have. And you're able to actually reconcile those two things so you can very smoothly upgrade. Feels a little clunky at first, but once you do this two or three times, this, this turns out to be a very elegant way to keep on the latest and greatest thing. So, so we got here to this Ember CLI land,
24:44
and everything's kind of good, and all, everyone's pretty happy. So how do, 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, excuse me. And in an ideal world,
25:03
you know, if you start talking about architectural purity or, you know, the kind of where things, where the separation should live, this kind of makes sense. So both sides are tested independently. It allows for greater specialization. So you're able to, you know, focus on your strengths, and you're, you're able to hire
25:22
for, for very specific sections of your code. The test independently means that you have to, you know, write your integration tests, stubbing out the back end in Ember, and then you write your API tests in Rails. And that, that turns out to work OK. It gives a flexible back end. I know we're all Rails people here, so we're all kind
25:41
of, you know, 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, so this sounds great, but what are the kind of perils or pitfalls of using this
26:02
style of approach, you know. I, I know DHH mentioned monoliths. This is not a monolith. This is, you know, these are, these are disparate things, and trying to keep them in sync becomes difficult. So what are the, what are the issues? This is not an integrated system. I'm sorry. Integrated system. Yeah. So, so there's no full stack acceptance testing
26:22
conventions. It's not that you couldn't do it. You can do it. I'm gonna show you a slide in a minute that shows you some kind of, some of the ways that we work around things. So there's no full stack acceptance testing conventions. But you could use Foreman to spool up the, the, either, either side, the Ember app and the Rails app, and then proxy one to
26:41
the other, and then point cucumber to it. But you can see, like, already, if I go to another project, I'm gonna have to reintegrate this. So this is not what we were talking about earlier, where this convention over configuration, we don't want to make these micro, micro decisions at the beginning of the, of the project. So it's ad hoc development workflows. This goes along with the same thing. A lot of conventional problems
27:00
here where we just don't know what to do. And people are struggling, they're not struggling. People are, people are investing a lot of time finding the answers to these questions. So it's, it's cool. Like, people write things like this. Like, this is actually out of one of my original apps that I did separate. And I don't know if you can see the code here, but, can everyone see it? Yeah? All right. Cool. So yeah. So it,
27:22
it basically, it just, it's a rake, rake file that you run, you run just rake, and it's gonna spool up the things like I was mentioning. So it's CD, so this assumes that backend and frontend, backend being the Rails app and frontend being the Ember app, live in the same directory, and it boots them up and it points them and hooks them all up together, and then you can develop, right.
27:40
But once again, I'm having to do this, and I'm probably not gonna do this the same way twice. Two teams are probably not gonna do this the same way. So, and it doesn't work well with existing applications. So the, the kind of, the line that people try to draw here is, when you start working with Ember CLI, if
28:01
you say, oh, I have an existing app and I want to use Ember CLI, people will tell you just do a rewrite and, you know, separate your app and have, have this, this complete separation. But that, that's not possible for a lot of people. A lot of people have invested years building these applications, and, you know, have teams
28:20
that are Rails focused and need transition periods to learn new technologies and become efficient, proficient at these, at these like advanced things. And once again, a learning curve is not always easy. So it doesn't work well with our current application. Complete separation doesn't work well with existing applications. Deployments become more complicated. So, once again, this has
28:42
to do with conventions. A lot of this has to do with conventions, just knowing where to, what to do and when to do it. But you can see that it gets pretty complicated. This is, so Ember CLI deploy is a Ember CLI add-on that is geared towards deploying Ember CLI apps with, you know, XYZ backend. Rails is very common.
29:04
And the diagram for that looks a little bit like this. So I'm not gonna go into too much detail. This, 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 up-front work trying to understand why these things need to be do, be done this way. A lot of this has to do with
29:21
cores. You want to serve your index HTML from your, your Rails server, your API server, and then you want to serve the assets from a 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. And it's, it, once again, this is actually a really great solution, but it's, it's a
29:40
little more complicated. And it would be nice to, to wrap this up. So yeah. So that's pitfalls. So, so where does Ember CLI Rails, the gem, sit? Well, this is my favorite part of the talk. Favorite part of the talk. It's the only animation I have in all my slides. Hold on. Someone say a whoosh. Whoosh. Yeah, there we go.
30:04
OK, 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 AppKit did it. Ember AppKit Rails did it. The, the gem to utilize Ember AppKit. But it's even thinner. So it's, it's not trying to rewrite the
30:20
generators. It's not trying to, to do the job of, 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 climsy separation. And it's letting, it's trying to let both Ember and Rails do their own thing, independent of one another.
30:42
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, and everything kind of works great. And then these testing, 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.
31:01
So you write your RSpec API tests and Q unit, unit and integration tests for Ember, and then you can write full stack Cucumber tests if you want to, or, you know, whatever acceptance testing framework you like. Yeah. And this, this is the, the, the goal here is, is once again to, to avoid the double work of trying to keep these
31:21
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, this is kind
31:45
of a, this is not a hand-drawn, this is a hand-drawn sequence diagram. There's an actual, actually a tool called JS sequence that lets you do this and it looks all hand-drawn. It's awesome. Recommend it highly. So yeah, so the user will request a page from Rails. Rails intercepts it and says, OK, I know that, you know, that,
32:02
that I need to start or restart the Ember build process, and wait for the assets to be built. Because, 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, to include multiple Ember apps. So you can have multiple, you can have an admin panel filled with all of your, an entire Ember
32:23
CLI app that is, only dedicates your admin panel, and then 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, OK, request the page. Start, start or restart Ember. Ember builds, and then when that's done, we do some, some locking stuff to make sure that you
32:41
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. And yeah, that's, yeah. So how to use it? So you start with an Ember app, and then, and then you, you can,
33:01
you can actually place the, the Ember app anywhere you'd like, but, but I prefer to put mine inside of the root level of the Rails app under a directory called front end, and then any subsequent also in the root of the, of the application, because it just makes things a little bit easier. And then you run, break ember-cli init, and that
33:21
produces this config, this initializer, and you just tell, you're just telling Ember, or you're telling Rails, rather, where the Ember app lives, and then there's, 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. You can actually do this by putting the, well, I'll explain that in a second. So you have a, you, you put
33:42
a root, a root path, and then you render an index in your index page. So now when you go slash the app, this ERB template is gonna be rendered, and it's gonna load the, with the two helpers there, it's gonna load the Ember assets so that your Ember app can be loaded. So Ember, Ember-cli will have already built your assets into this nice AMD, and then it's gonna
34:02
be included in the top of your file, and then all of the styles that come from Ember-cli are, are also gonna be included. So I'm actually really close to the, to the end of the talk, so we might have time to do some demos. So the goals of the Ember-cli project. The, the thing that I want for people to, to
34:21
kind of understand about this project is that, first off, this is, 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, and then the red there is Ember AppKit. And you can see that that was almost two years where the, the way you used Ember was, you
34:43
used Ember Rails, if you wanted to use it with Rails. Then, then Ember AppKit came on, on scene, and at, at EmberConf 2014, it was announced that Ember-cli was gonna be kind of the way forward, and it was gonna, it was eventually going to be included in the Ember-like ecosystem, officially, with actual
35:00
core team support. And you could see the explosion of commits that happened after that. And this is only from January, when I initially created this. 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, you know that this is not going anywhere. That's, that's the kind of thing. So Ember-cli is here to stay. It's gonna be a thing that we use
35:21
to, to utilize Ember. And it's really, really cool. It does some amazing things. So, so with, 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
35:41
5,000 a year for ten 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, and it's awesome. And I want to use both of these technologies, but I don't want to have to keep rewriting these, these things and doing the double work. I want a very thin wrapper that allows these two ecosystems to work together,
36:03
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 gonna continue pushing and asking questions on how we should integrate these two services. I would like to see the, I would like to see Ember-cli Rails become even thinner. And,
36:20
and the, the interaction just be those conventions. Right now, we're having to use the asset 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, so we're probably gonna 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
36:43
your Rails apps. So, yeah. So maybe we have time for some demos. First off, I'd like to thank HashRacket 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 Cindy Metz and Terrence Lee, who helped me
37:01
kind of refine these slides. Yeah. And I think that's it. Do we have time for demo? How much time? Two, three minutes? OK, cool. I thought I had changed that. OK. So, so I mentioned earlier that the URL was, the URL was at the forefront of, of Ember's philosophy. And kind of to that end, I
37:22
noticed something, and this is not a poke at your jab at RailsConf, particularly. This is something that happens to Conf, a lot of, a lot of things. It happened to EmberConf. EmberConf website reacted 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's not updating.
37:40
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, and, you know, something like, this is the shameless plug. So this is, 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.
38:00
We're not actually doing full page refreshes, and, and if I refresh, I'll be on the same page, and the URL's at the forefront. So, I don't know. That's the kind of quick demo I wanted to say, show, and I don't know, hopefully this will get you really inspired to kind of start looking at Ember CLI. It's an awesome tool, and, and you can use it now in Rails apps, with minimal effort. So, thank you very much.