Software Productivity and Ember: Ember CLI
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 |
| |
| Title of Series | ||
| Number of Parts | 20 | |
| 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/34999 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EmberConf 20149 / 20
3
6
13
15
17
18
20
00:00
VideoconferencingCommon Language InfrastructureEvent horizonSource codeGame theorySoftware frameworkAbstractionSoftwareFormal languageResultantState of matterSurjective functionEntire functionBound stateNP-hardCollaborationismBookmark (World Wide Web)Sheaf (mathematics)Electronic program guideBitActive contour modelRhombusComputing platformSoftware bugSoftwareProduct (business)QuicksortAbstractionBit rateCombinational logicEvent horizonStaff (military)NumberWordAxiom of choiceRow (database)WaveMobile appRight angleNeuroinformatikElementary arithmeticWindowDomain nameFeedbackShared memoryStack (abstract data type)Complex (psychology)Core dumpLastteilungRandomizationXMLComputer animationUML
04:45
CodeProgrammer (hardware)CodeComputer programmingLine (geometry)Right angleMereologyProjective planeVideo gameMobile appProgrammer (hardware)UML
05:34
CodeCodeDomain nameWordAbstractionMobile appAssembly languageDependent and independent variablesBootingRight angleCartesian coordinate systemComputer animation
06:23
Software testingCode refactoringCartesian coordinate systemMereologyMultiplication signProjective planeSoftware testingSocial class
07:09
Software testingProxy serverWeb browserControl flowRevision controlCloud computingMacro (computer science)Data managementAssociative propertyInversion (music)CodeModul <Datentyp>Independence (probability theory)Assembly languageSource codeSoftware developerEndliche ModelltheorieMobile appFormal languageCodeControl flowForm (programming)Software testingOrder (biology)Software frameworkRevision controlGame controllerWorkstation <Musikinstrument>Right angleAbstractionComputer clusterCartesian coordinate systemMultiplication signClient (computing)MereologySuite (music)Software bugNumberWeb browserPower (physics)Product (business)Self-organizationResolvent formalismNamespaceQuicksortModule (mathematics)Goodness of fitInjektivitätWritingBitInversion (music)
10:20
AbstractionKolmogorov complexitySuite (music)Stability theoryShared memoryComputer clusterConstraint (mathematics)QuicksortLastteilungSoftware development kitMobile appSuite (music)Multiplication signClient (computing)Projective planeLine (geometry)Template (C++)Computer fileSoftware bugFood energyDependent and independent variablesPhysical systemTask (computing)Process (computing)Software testingCore dumpRight angleOrder (biology)Module (mathematics)Library (computing)Point (geometry)Fiber bundleMultiplicationCodeHeegaard splittingGroup actionRevision controlData miningEndliche ModelltheorieControl flowSpacetimePattern languagePoisson-KlammerAreaCartesian coordinate systemCausalityBitSlide ruleAbstractionStability theoryBlogBuildingTracing (software)Complex (psychology)Different (Kate Ryan album)Entire functionInformation privacyInsertion lossMathematicsError messageComputer animation
17:28
Group actionSoftware testingTraffic reportingBranch (computer science)MathematicsParameter (computer programming)QuicksortSelf-organizationGoodness of fitCore dumpSign (mathematics)Cartesian coordinate systemPrimitive (album)Strategy gameOnline helpFingerprintPerfect groupSheaf (mathematics)Product (business)Structural loadUniform resource locatorFocus (optics)Line (geometry)System callProjective planeSoftware bugTrailCommon Language InfrastructureInformationPattern languageMultiplication signComputer configurationLibrary (computing)Moving averageTheory of relativitySoftwareNumberUtility softwareAnalytic setBuildingDifferent (Kate Ryan album)ResultantConfidence intervalFood energyStability theoryOptical disc driveWhiteboardTheoryControl flowField (computer science)Form (programming)WebsiteFile formatDefault (computer science)Web browserParticle systemCASE <Informatik>Crash (computing)Source code
24:15
Physical systemCodeElectric generatorProxy serverElectric generatorCodeElectronic program guidePoisson-KlammerMassProcess (computing)Real numberState of matterQuicksortCellular automatonStatement (computer science)Programming paradigmCASE <Informatik>Web browserEndliche ModelltheorieBitSource codeCartesian coordinate systemAreaUser interfaceVideo game consoleMultiplication signOperator (mathematics)Resolvent formalismClient (computing)Patch (Unix)Group actionGoodness of fitRule of inferenceFigurate numberPoint (geometry)Web applicationRoutingServer (computing)Router (computing)Right angleConnectivity (graph theory)Service (economics)Cycle (graph theory)Plug-in (computing)Video gameProjective planeGame theoryParity (mathematics)1 (number)FrequencyTask (computing)Mobile appSoftware testingComputer fileSubject indexingLie groupDirectory serviceContext awarenessStapeldateiPower (physics)Online helpArrow of timeFunctional (mathematics)MappingLink (knot theory)NumberSoftware developerUtility softwareLevel (video gaming)2 (number)View (database)Uniform resource locatorFront and back endsDebuggerCommon Language InfrastructureModule (mathematics)Computer clusterDifferent (Kate Ryan album)Interrupt <Informatik>Software development kitFrustrationFocus (optics)Shared memoryOcean currentAbstractionUML
33:00
ResultantPhysical lawXMLUML
Transcript: English(auto-generated)
00:19
the core team, one of the TJ for most commits.
00:27
Yeah, most. I beat TJ on a number of events on GitHub. OK, that's insane. Which? Most prolific, like the Ernest Hemingway of JavaScript. For better or for worse. For better or for worse. Well, he was an alcoholic, wasn't he?
00:41
So this is actually going to be an appropriate talk. OK, anyway, step in, everyone. So I'm Steph, and I'm an addict.
01:04
Yeah. You guys supposed to say, hi Steph. Thanks, I need the support. So I was pretty cool. I saw this number, and I was like, cool, I found a few people, and I was like, I'm catching up to them, it's pretty neat. But then all of a sudden, everyone I saw had surpassed,
01:21
and I was a little bit worried, like this is now a problem maybe. But luckily, I found this guy. So 50% more GitHub events than me. I am just a hobbyist, so there's no problem.
01:40
So I'm also a husband with a very patient wife, as you can imagine. We're crazy bird people. So for those of you that have remote paired with me once in a while, one of my birds will join the pairing session, and we're much more productive then, I think.
02:02
Also, we build a lot of cool stuff, some of which is some pretty cool Ember stuff. I get to work with Luke and Chris and Ray, and we do a combination of product work, sort of full stack work that involves a lot of Ember, and consulting work.
02:21
Because we were early adopters and early adopters on the mobile platform, we had to do a lot of performance work and a lot of bug fixes to get it in. And because of this, we have gained a little bit of knowledge in this domain. So if we can help you guys out, find me, Chris, or Luke afterwards, we would love to help you guys out. Anyways, also, I like talks that are a little bit more like a dialogue.
02:42
A little bit of feedback from the audience is lovely. So speak out, but be mindful. We have a really short window, and I'm going to try to finish a little bit early so we can answer questions. And a little random tidbit about me. In elementary school, my mother was the teacher at my
03:03
elementary school, and so that meant two-hour detention, basically, every day for six years. Luckily, though, I didn't have a computer at home, but luckily, I had a computer labs of computer labs. Basically, computers everywhere. And ultimately, this turns into the child maintaining the school's website.
03:22
I wrote JavaScript. And I was like, you know, someday, when I grow up, it'd be pretty cool to learn a real language and build really awesome things. So apparently I didn't grow up, because I'm back to that. Anyway, so this Ember thing doesn't really need that much
03:41
of an introduction. But basically, our goal and motivation, the reason why we're all here is we want to build apps that are awesome, we want to build apps where we're productive and continue to be productive into the future. It's fancy, it's neat. Abstraction is safe time, abstraction is high complexity. I'm basically iterating all the past talks that we've
04:01
had, abstractions guide learning and collaboration, abstractions enable cost sharing. I really like this one. This is my favorite one. We can basically load balance the cost of some of these hard things onto an entire community, rather than every single company doing the same thing, spending the same resources, yada, yada, yada, yada.
04:22
So but ultimately, no matter how awesome and how productive Ember makes you, software is software. Them productivity sinkholes. So when you start a new app, you're going to be productive. When you start a new Ember app, you're going to be productive. Everything is new.
04:41
Everything is fancy and fantastic, and you haven't made any bad choices yet. Pretty quickly, your Ember app might turn into something like this. So why does this happen? No matter how hard you try, all of a sudden, there's those parts of the code base.
05:01
You're like, well, I don't want to look there anymore. Just throw it away. So basically, every line of code you write is actually a liability. You have to weigh the cost-benefit ratio. I'm going to write some code, but it's going to be around for a while. The life of the project might not just be a spike. It might be months, years.
05:20
The code you write, be careful with what you write. It can cost a lot later on. But Steph, I'm a programmer. I write code every day. That's what I get paid for. My employee won't pay me if I don't write code. But you can probably write better code. Or what code can we kill? What code is basically just ripe for the picking?
05:44
So basically, what is the most brittle code, the most error-prone code, the most pointless code? We can just throw it, hide behind an abstraction, or just remove altogether. Let's pick on those things and kill them so we can focus on our domain. So one of those places is just blue code, code that
06:02
wires this up with that, assembles this, your app boot, the way your apps booted. So a few years ago, before we had Ember application, for those of you that remember this, you were responsible for putting things in the right places, wiring them up. Some people had dependency injection, some people didn't, but it was always your responsibility to do so.
06:20
This is crazy. And why is this crazy? They're often implemented haphazardly. Often they make testing hard, make refactoring hard, adding new features hard, because every time you're basically scenario solving, I need this to work today. And this just turns into a mess. Now, you also onboard new employees. They might have Ember experience.
06:41
And they'll look at your app, they're like, yeah, I know Ember, I know what this is, but what is this app, this is entirely different from every other Ember application. And that's a big cost. Another cost is scaffolding. It has basically nothing to do with your actual project. It's the stuff that ultimately lets you build
07:00
your project and once you're ready, you don't need it anymore. Or it needs to be there, but it really isn't the primary part of your application. It turns out the support tooling is also immensely costly. Because, well, to go from development to production, you need to do all these things. And Major Breakfast, who's an active contributor as well,
07:22
that's his drawing, so credit to him. And by the way, it has to also work really well. No bugs, it has to be fast and stable, and your features do on Tuesday. So it turns out these two problems, they're actually
07:41
very related. We can probably solve one with the other, or together, solving both of them, we're just going to solve the opposite problem, or the complementing problem. So one of the first problems is just general coupling. Obviously, remember, our solution to this is inversion of control. We have a container, we have a dependency injection framework that most of the time you don't even have to
08:01
think about. It just kind of works. And when you do need to, sort of peel away, it's there, and it's very powerful. The two main parts of this are the container and the resolver. The container basically abstracts the coupling, and the resolver finds code for your container to use.
08:24
I even labeled it, this is intentionally put here. I don't know why, but I did it. Another problem, it's globals. To have coupling in your application that merely depends on the order that you load code is totally crazy.
08:40
Now, you have a namespace, your namespace has a namespace, and you're trying to organize your code. And all of a sudden, you can only start up your app in a very specific order. Otherwise, stuff's going to break. This makes testing insanely hard. And again, it's a form of coupling. The solution? Use modules. And what modules should we use? Well, let's not join the module war and just use what the language is going to have in the future, ES6 modules.
09:04
And interestingly, combining these two things, a lot of that glue code just disappears, because we can actually allow our apps to assemble themselves based on what's being imported, what's being required. As it turns out, we have this cool feature called the resolver that Luke wrote.
09:22
I don't think he realized how much mileage we would get out of this little bit of code, but it really powers some of our new code organization ideas. But basically, rather than you writing the glue code, your app builds itself as it's needed. Pretty cool. Code you don't have to write is not your liability.
09:42
I originally had the GIF from yesterday, and I decided I shouldn't also have that GIF, so I found another one. So there's another problem, the whole tooling thing. We actually got to ship these things to the browser. It's very different how we develop and how we have to ship to our clients.
10:00
So I already enumerated all of the million things we have to do to get tooling working. But obviously, the solution is we need good quality tooling, but what do we build? We have to acquire some requirements. So what we do in Ember often is we find a cow path, and we try to pave it.
10:21
So rather than going straight to the Autobahn, can we like, can we create a cow path that everyone shares so we can turn it into a, or at least not everyone, but a critical mass of people, enough people share so we can learn all the constraints and also load balance some of the problem solving. Sort of an artificial way of us getting to
10:41
the Autobahn quicker. So the idea with this was, I need to ship real things. The node people are angry at us for using Ruby tools, but I need to ship things. So Ember App Kit kind of happened. I was doing a project for McGraw-Hill. And one of the requirements was this is supposed to be
11:01
consumed by the JavaScript community. So node build tools was the thing to do. So Ember App Kit happened. Since then, that was about nine months ago, we've had 572 commits, 71 contributors, and 519 closed issues. That's not bad. Clearly, we have created a cow path. People are using this, being successful, being frustrated.
11:22
I want to apologize to all the people that are frustrated. I assure you, I am just as much frustrated, if not more, than the rest of you. So what's the problem with this? Upgrade nightmares. Who here uses Ember App Kit? OK, so we have enough. There's a good number of people. Who here has upgraded an Ember App Kit app?
11:43
Who here has tried to upgrade an Ember App Kit? And OK, there we go. That's the nightmare. And I feel very guilty because I knew that this was going to be terrible. But the point of Ember App Kit was just to figure out what all the constraints were. What do we actually need? And while doing so, what does Ember need to do to
12:01
actually live in this no global space? So Ember App Kit might look like a lot of work, but 90% of the work that Ember App Kit has was actually in Ember, just supporting both the global's path and the module's path. This gave us a place to share the ideas, to collaborate. So what's the solution for the upgrade nightmares?
12:20
Let's hide more things behind a library. Let's hide the complexity. Well, copious bugs. Basically, using App Kit, you add one new pipeline and all the other things breaks, or just core problems that happen. Well, the solution to this is a thorough test suite. Unfortunately, when your entire API is all of Grunt,
12:41
this test suite is very, very difficult to solve. Grunt is, I think, a pretty cool task runner. We sort of shoehorned it into having more responsibilities than likely should have happened. But it kind of worked. Some people were productive with it. Another thing is build stability.
13:02
And the solution to this is basically using the right tool for the job. Doing a one-time build makes sense with a task runner. Doing repeated incremental builds that are efficient and not prone to errors, not prone to phantom files or not detecting changes. This is the responsibility of a pipeline, a tool that's
13:20
specially crafted only to solve these problems. And for this, I think Broccoli's a very good candidate. Thank you, Joe. So Joe's done some awesome work on Broccoli.
13:41
And I remember in November, I was playing with an early version of Broccoli. And she's like, try to break it. So I was like, I can totally break it. I have like five or six different scenarios I know totally screw with most build systems. Even a rake pipeline has problems with them. And I threw all of them at it. And there was not a single problem.
14:00
I was like, all right, but now let's try with 20,000 files. And even then, I still had fast builds. At that time, a build with 20,000 files was taking about a second. And Joe traced it down to a problem in node glob, not her stuff, so it's pretty cool. Even back then, it was very stable for this build thing.
14:20
And it sounds fantastic. So Ember CLI tries to solve these problems by giving us a single place to focus our energy, by using hopefully the right tools, by thoroughly testing itself, and trying to
14:46
use the right abstractions. Whenever we find something in Ember AppKit that seemed to work OK, but clearly didn't work for everyone, taking the time and energy to take this and apply it to Ember CLI,
15:00
it's very important. So interestingly, although if we go back to the previous slide, Ember AppKit had about 500 or 600 commits, 70 contributors, 500 closed issues in nine months, Ember CLI has, people are eager for this, it already has 273 commits, probably more by now.
15:20
28 committers, contributors, and 131 closed issues in the past month. I think that's pretty cool that people are using it already. So another question here. James Rosen, I'm going to bug you for a little bit. How big is your application?
15:40
How big is Zendesk in file size? I would love an answer now. ActAt. How many lines of code? Lots. The quick question is, do you ship all of this to your
16:01
clients all at once? Oh, 70,000 lines of code, not 70 kilobytes. So 70,000 lines of code turns into much JavaScript and assets and templates and stuff. So can you ship all of this to your clients all at once?
16:32
So to summarize, because I'm assuming his voice might not be caught up on Mike, Zendesk has 70,000 lines of code. That is many hundreds, if not thousands, of kilobytes.
16:44
And it is not practical for them to ship their entire app to their users every time. So he has a group of people working on splitting this app into multiple bundles, shipping these bundles. Well, who else here has a similar problem, where they can't actually ship their entire app all at once?
17:02
One hand? OK, there we go. There's a few more hands. This is actually a problem. And if you don't have that problem today, you're going to have that problem probably pretty soon. Or you're going to want to solve it, and then you think about all of the constraints. Like, ah, I'm just not going to bother, because my business can't afford me to spend a week, a month, refactoring my code, building the right tooling in
17:22
order to ship these things lazily. I know Yahoo has similar constraints for some of their projects they want to take. And well, wouldn't it be cool if we could kind of focus in one place to come up with a convention to make this not only simple to do, but to just make this work
17:41
by default, work by convention? If you had this as just a thing that just worked, kind of like how URLs just work in the browser, you could lazy load your slash admin section. Who here wouldn't do that? Either you're putting up your hands, or not putting up your hands, because you're not going to anyways. You wouldn't do that?
18:00
You would do that? OK, perfect. So I gave a very bad question. I think it's obvious. If these things were free, if these things were supported and worked well, and there was a happy path to doing it, more people would definitely do it. I know I would use it a lot. So if you guys want to try it out, you have internet today.
18:20
If you npm dash g install ember dash cli, and then wait for npm to download on our dependencies to download on our conference Wi-Fi, you will eventually be prompted with something like this. So you have an ember command line utility, inspired a lot
18:41
by the project Ryan Florence worked on, ember tools. Ember help gives you sort of the basic primitives of what you will likely need to build an ember application. New scaffold's a very basic application for you to use. You jump in, and hopefully you can be productive right away. So Edward Faulkner did his talk with it, and he seemed
19:02
to be happy, so that's a very good sign. It was greenfield euphoria. So it's very important for us to make sure we can continue to pull that greenfield euphoria with us for as long as we possibly can before we end up ultimately ending up with legacy software of some kind.
19:21
An interesting thing that we want to do here, and I would love to get a show of hands as well, is we want an easy way for you to upgrade to Ember when we push releases. So we've been working very hard as the core team and the community on making sure that we don't break changes. We try very hard not to have any breaking changes. So one sort of experimental feature we want to add to the Ember CLI is just your ability to subscribe to the
19:42
branch or the channel of Ember that you're most comfortable with. So for example, if you're more comfortable with stable releases, you can subscribe to stable releases. And if you happen to start up Ember CLI that day and we push a new release, it'll ask you, hey, yes or no? Do you want to try to upgrade today? Yes.
20:00
And if our SemVer stuff is all working, your upgrade, followed by running your test suite, should give you some confidence. And if there's a problem, report the problem, roll back, and hopefully that was five minutes of your morning. We'll get all the issues in quickly, sort them out, and move on. If you are, like myself, always on the bleeding edge of
20:21
things, I'll just subscribe to Canary and basically every commit, I'll have the option to pull it down and utilize it. So who here thinks this is a thing that they would like to use in their projects? That's awesome.
20:41
So some crazier ideas that have been cropping up is, what if Bower and Yeoman have a really cool library that they use called Insight, which actually lets us track analytics, usage patterns inside of
21:01
command line utilities? So as an experimental thing, we've added this to the Ember CLI. Now obviously some people work in places where this is not an option. So the first time you use a CLI project, it prompts you, hey, would you like to submit anonymous information to help us understand your usage patterns? So this is in there today. I want to feel for who thinks this is a good idea,
21:22
who feels comfortable with this, and who would feel comfortable with this if their employer felt comfortable with this. Awesome. Another step onto that is, I would love to treat Ember CLI like a actual project that I deploy, which means bug tracking. So if Ember CLI crashes, the core team wants to see a bug
21:43
report of this. I'm assuming this goes along the same lines. You guys would be fine with this. People nodded. Awesome. That's awesome. I was really hoping that that would be the case, because this lets us catch problems quickly. And maybe even before you report your bug, we might already know what happened, and we'll be eagerly waiting
22:03
for your issue to be submitted. Awesome. That's pretty cool. So a call to action. Ember CLI is working for some people already. There's some pretty important features that we're still lacking. We added test support early this morning.
22:20
I'm not quite sure if we merged it in due to internet issues. But now we can run tests and stuff. This is very important for production applications. We're still missing a good fingerprinting strategy. But that's hopefully going to be coming shortly. But I would really encourage people to try it out. Find bugs. Anything that sucks, report it as a bug. If there's formatting that's screwed up,
22:41
report it as a bug. If there's something that's confusing, report it as a bug. Because we want to pave these roads so that it's good for you guys and good for when you onboard new team members. Or if you're in an organization where you're fighting the Ember fight, please use Ember in the organization. The better and cleaner this path can be, the easier it is for your arguments.
23:02
I would also like to thank, so apparently all of the Ember CLI contributors are called Joe. Or Broccoli people. As it turns out, maybe not all of them, but a good number of them. So Joe Liz works on Broccoli. Joe Fiorini has been amazing helping out
23:20
with the Ember CLI project. It probably wouldn't be useful today if it wasn't for him. And it turns out Major Breakfast's actual name is Joseph. So once I realized that, I was like, so apparently Joe's are good to work with. So if your name is Joe, you absolutely have to join because we can make a leaderboard of the number of Joes that are helping out.
23:41
But even if your name isn't Joe, I would maybe more reluctantly accept some help. Best ways to help? Like I said, install it. Try your hardest to break it. Look at the issues. See if there's an issue that's related. Add your story to it. And if you have some spare time, find an issue and see if you can improve it. I know Ed talked to me about a layered build deployment
24:03
approach. I think that's awesome. Fantastic idea. Works well, I think, with being able to deploy different segments of your application. Hopefully we can continue to iterate upon it. So if you can, give this a try and hopefully it works.
24:24
And Ember CLI is definitely not the, I didn't set out and decide, hey, I'm going to write the awesomest CLI ever. I actually don't want to do this at all. I just want to build my app and be productive. I want to go bower import tom huda fast select.
24:42
And then in my application, I want to have a fast select component. I don't want to think about the wiring. I don't want to write code that is a liability to me. I also want us to share our components in a way that's easily digestible and easy to consume across different projects, across different teams. Why?
25:01
There's a room of like 430 people who are smarter than me here who can build cool shit and we can share it. This is the point of the CLI, is to not have to think about the CLI ever again. So for the future, I think Rails did something really neat later on in its life cycle.
25:21
The first plugin story for Rails was kind of SVN checkout into a vendor file and it got them a long way. I kind of feel like that's what we're at right now. We can SVN checkout, we can bower install to your vendor, your bower components folder. But wouldn't it be cool if you installed bower install ember off and it added generators
25:43
to the CLI, it added extra routes to your router, added some test helpers, and then also added code that you can use in your application and assets in CSS. Well, I think this is possible. It's gonna take a lot of work just to iron out all of the various creases and stuff,
26:01
but I think we can do it. And once we have that, hopefully we can just start sharing these components and these utilities and these add-ons and again, focus on our own app development rather than doing all this code that is actually just a liability to us. Something I mentioned earlier was lazy loading of app segments.
26:23
I think this is actually very important for web applications. Absolutely something we want to work on. And a very important aspect of lazy loading that people don't think about is we have to be able to lazy link. You have to be able to link into things that don't actually exist yet. Something that we need to fix in ember first
26:40
before we can really use it here. But me and Alex sat down and figured out that there's no really big hurdles. We just gotta put in some time and effort to make it work. Also, finally, I wanna start using cool ES6 features in my apps today. So we can use modules today. We can use arrow functions today. I wanna start using generators today. For those that don't know what a generator, what it will, basically it'll help you,
27:02
one of the features of generators is it will help you hide asynchrony from your application, which is quite nice. Asynchrony in state is always hard to deal with. If we can hide it even more, that's fantastic. There's a whole bunch of other cool ES6 features that we want to use as soon as the transpilers and stuff are ready. Well, it'd be great if we could just add this to the same CLI so everyone can start utilizing
27:20
these cool features. Anyways, so hopefully that provides some context as to how we ended up with what we have today. And hopefully it paves the road for what's next. Can I answer some questions? What happens in the ember app kit? So the ember app kit, everything that's in your app directory
27:41
basically ports instantly. It just works. Things that don't work today that will likely work with a little bit of massaging is the index file. Oh, sorry, the question was what happens with ember app kit? Lots of those conventions, but how your app assembles itself, everything in app and everything in test, that should just continue to work, period. Unfortunately, stuff in your grunt tasks,
28:02
custom configurations, those might be more difficult to port but hopefully as people share some of their concerns or share some of their issues, we can either have feature parity for some of those things or provide the correct upgrade path. Some of the features just aren't needed in ember CLI anymore and other ones are definitely still needed. Answer your question?
28:21
Awesome. Any other questions? So the question is do you have a preferred way to integrate with your server code? I think there are multiple approaches to this but the easiest approach, one that I find works probably the best is to keep your projects a little bit separate and have a proxy either on your server side or on your client side via the app kit or via the CLI that proxies those requests
28:42
to your backend. Lots of people have their backend actually installed as deployed things, some people run it locally. I think this works fantastic. So the question was, I believe, correct me if I'm wrong, the question was what about globals? Most people here probably have applications that use globals.
29:01
So we were very careful when making all the upgrades to ember to support non-globals to also support globals. So ember itself will continue to support globals just fine. Unfortunately lots of the things that we just get for free in ember app kit or in ember CLI is because we don't have globals, we don't have this coupling.
29:21
I don't know if there's a good path for people other than to make a transition. Now one thing that has worked and we've helped a few clients upgrade this way as well as our own code is using the resolver. Remember the resolver is the abstraction between the container which needs code and where it finds the code. We were able to write resolvers that satisfied
29:42
both the global story and also the module story. So we were able to incrementally upgrade our application. We basically just added a warning every time a global was referenced and then we knew what the next thing was for us to upgrade. So my personal thing would be an upgrade path would probably yield the best later outcomes,
30:01
although that's definitely not practical for massive applications. So hopefully that answers your questions. Any other? So just to kind of follow up to the question about sharing or finding it back in code, I'm actually sharing a whole bunch of modules. I'm using browserify today.
30:26
So the question I believe is can I pull from node modules? Going from my server side node stuff to load these same modules to share them. I would love there to be. I definitely need some.
30:43
The question was, can I pull from node modules? Currently using browserify, sharing JavaScript code between the back end and the front end is very simple. Is there a good story for this today? I would say there is not a good story for this today. It is a little bit frustrating. I would love there to be actually a really good story for this.
31:01
The browserify approach is definitely interesting. We like the ES6 module stuff. We've got to figure out an interrupt that makes people happy or something different that makes people happy. I don't want to ever throw away things that work really well and I acknowledge that it's a really common use case. So the important thing is to figure out what that next step is.
31:20
Any other questions? It's just a hobby for you and you obviously have code use through time. What are the problems with having a DOM here itself?
31:41
So the statement, followed by a question, was when people are learning Ember, they're learning a whole new paradigm. They're learning many things. Often they're coming from spaghetti code, cell front ends, or just not used to building real user interfaces that have URLs and lots of state.
32:01
That's already complicated. Ember has a massive code base. There's a lot of stuff there and now there's tooling. Well, is there a way for us to accelerate the learning process and a screencast? I would say hopefully with the CLI, the scope of the tooling has reduced dramatically
32:21
to specifically this. You can hopefully digest a good amount of this. I would like to port a lot of the guide that we have for Ember AppKit, remove the stuff that is no longer needed, and doing a screencast would be awesome if I have the time to do it. I would love to do a screencast. If someone else has the time to do a screencast
32:41
and has a much better stage presence voice thing going on, maybe like a Barry White style screencast, that would be awesome. But ping me afterwards. Any other questions? We've got 18 seconds. Oh no, you're right, we're going the other way. 20 seconds, 21.
33:02
That was awesome.