Ember application that I've worked on. SimpleReach is an analytics company that helps publishers track how their content is

doing around the internet, and especially social, and then helps them predict which of their content could possibly go viral. And then helps them predict which content could go viral and help them actually take

the actions that would make that happen. Before I go further, because I know it distracts some people, my accent is I'm South African originally, had a bunch of Canadian mixed in there, and some Kiwi at some point. So when you hear me say things in a funny way, that's why.

South Korean. Hi guys, I'm Haejin, Ember Princess, as you may know. I'm the Ember Princess. And I work... Thank you. I work with Andrea S. and Paris in New York. In my day job, I use Ember every day. You jealous of me?

And I love Ember, I love Ember community, and I'm so glad to see you guys all in person today. So, our talk really is almost like a 2.0 of what Tom and Yehuda were saying. We're looking at using Ember to make the seemingly impossible easy.

So when Tom was talking about productivity in your day-to-day work, we're looking at... We're remembering stories of times when we had massive gains in productivity, because we tried to implement a feature that was really, really hard and seemed like it would

take forever, and it seemed like we couldn't do it within the time frame that we were given to do that. But because of the nature of Ember, the nature of having a front-side JavaScript app, the nature of having Ember data around, as it is, allowed us to get orders of magnitude more productivity and deliver the features on time, whether it required hacks to do it

or not. Sometimes it is, sometimes it isn't. But the point was that we delivered the features because of the nature of this new kind of paradigm of computing. And so as we're going through pieces, some of them might not be relevant at all, but the hope is to help you guys figure out in your own applications where you're avoiding doing something that's really hard, because you've got your years of developer training

of being like, let's not touch this because it's really, really difficult, and let you take another look at that in the light of Ember and see if maybe there's something else that can make it easy. So we'll go through just four different examples of what we had. So the first one is migration, which, as everybody knows, is not a fun process at all.

And so to set the story to the stage, I was working at a startup that was a social network for universities. The company decided to pivot, as startups tend to do, and became a knowledge management

company for the enterprise. So completely different, and we had to rewrite the way the app looked and felt and worked. And so we had this massive four-year-old code base that had a bunch of jQuery soup, Rails 2 code, built by developers from over 10 different countries that were outsourced to, and it was going to be impossible for us to do that.

So we decided to build the new front end for the new pivot in Ember. And so we did that, leaving the back end the same, used the same database, and then just kind of had things go in between there. Eight months later, we decided we're really, really, really tired of the Rails 2 app and we need to get into something more modern. So we decided to switch over and put all of our new clients on a new Rails 3 app.

And because the Ember router had just changed and come out new, we rebuilt the whole Ember app as well. And so now we had this new thing, this Ember app, but because we hadn't reached feature parity yet, we were just getting new clients on that one, we left the old clients on the old app saying we'd migrate them when everything was the same. Eight months later, it's time to migrate these users.

And they were itching to get going, and they really wanted new features, the new stuff that we're showing with the cool stuff we built in the new Ember. And this was going to be hard, moving things from a MySQL Rails 2 stuff that was living in Hadoop all over the place into our nice little clean Ember postgres-y world.

So we hired a consultant, and after a month of installing different database mapping tools and trying to pull the one database into the other and pull things from Hadoop down into something that could be mangled right, he threw his hands up and gave up, and just left with three days before we promised all of our clients they'd be on

the new thing. So that left me with a migration to do in three days, which somebody wasn't able to complete in a month, and terrified. So while pondering through that throughout the entire day, swearing liberally in my own head, trying to figure it out, I think it was in the shower when it actually came to me that

there was actually a really easy solution to this. Both apps were Ember apps, and they were both Ember data backed. So if you look at the two different models for what the old one was an item, and the new one was a post, they kind of mapped. The words just had to be changed in the serializers, but essentially I had this

common interface already. Active model serializer could actually turn what was that old Hadoop stuff into a bit of JSON that looked almost exactly the same way that my new app was expecting JSON in. So the only thing that I really had to do was go and write a script that pretended I was a user of the Ember app. So this is the production create method, which just takes the Ember app parameters,

parses it to a creator object that just builds up the object really nicely in the day-to-day app. And so my script just had to pretend it was Ember data, basically doing a store.find on those items, and then pass them all and doing the kind of store.createrecord.save and

just loop through that. And so by writing this code, adding a little bit of legacy ID things to help them map over, I was able to do the entire migration within three or four hours completely, just because having Ember data provide this natural interface that was the same in both apps. And again, most people aren't going from Ember app to Ember app yet, but you get that

point where that data can actually move really nicely and easily, and it made the migration an actual cinch. And thinking of where data could go from this, because your app is now built in a way that it has to be able to send data in a nice way back and forth, you can send it to other places. So another thing that we did often was we would have multiple Ember apps.

The company continued to pivot many times, and as such, we're able to just still use the same backend, spit out a new Ember app quickly, and all the code that would create these objects and items that we wanted to was right there and could just be sent to a different Ember app. Same thing with search. When we wanted full text search, we just use a serializer, sent it all up to an elastic

search hosted instance, and we had that. Caching and mobile is a thing. So thinking now that your data doesn't live in Hadoop or Cassandra or the other places, we have mechanisms now to pull them out and put them in a nice format. You can push them to different places. Hi, again. So I'm going to be talking about data visualization with D3 and Ember.

Simply, she is an analyst company to help publishers to understand the story behind their data. So as you can see the screen, we have many visualizations, like donut chart and area chart.

So D3 was our choice of tools to use for data visualization, and it worked pretty well, but D3 is a JavaScript library. So as your application grows, it turns out spaghetti code is very well.

It's like Angular. So another problem is that you have to learn a lot about D3 to be able to make great visualization. So for Andre, he doesn't want to touch any D3 code at all.

So D3 means just Diablo 3 for him. New expansion comes out today, by the way, if anybody is interested. So how we solve the problems? The answer is Ember component. So as you can see in the box, Ember component, there is D3 code, which is encapsulated in

Ember component. So Andre or our designer, they don't have to care about, they don't have to learn about D3 at all, because it is encapsulated. So that makes save their time to focus on more their job.

Like for designer, they can more focus on like make chart pretty, and for Andre, he can play more Diablo 3. So this is an example of D3 donut chart with Ember component. If you want, feel free to visit the JS Bin.

So all you can do is on the right side, there is JavaScript code, all you can do is define a component and add D3 code into component. And left side, there is handlebars, which is template. You can just add one line of code, it will draw a donut chart.

So if you want to add more donut chart, you can just copy one line of code in template and just paste, it will draw another donut chart.

So why we should use D3 with Ember? Because it is very easy to add any functionality to Ember component like D3, and Ember architecture helps me to think of the separation concern of like data and DOM that makes me to focus

on data and more about its history, which is the main goal of their visualization. This is one of my favorite code by Yuhuda and Tom at offline conference. Frameworks are designed to nudge you in the right direction. So I think Ember is a framework with D3 for data visualization is that D3 is a library

not a framework. So we use Ember to nudge our D3 code in the right direction. And that's true.

I've been working at Simple Reach for close to six months now, and I still can't make a straight line in D3 at all. And I've just been able to entirely refactor around all the other code without touching it. And then just ask Hyejin to help win. So the next piece is one that Tom and Yuhuda have actually already introduced.

It's the Vine app. And so this is, the story is courtesy of the amazing Janessa Det over at Vine. She had, I think it was three months to build the front end Vine app. And because Vine was a mobile first application, it didn't have a web app at all, she was almost entirely responsible for coming up with it from scratch.

And she decided to do it in Ember without having known Ember before. So three months she's learning Ember, she has to create this application. And Tom and Yuhuda were saying it looks like a simple app. It's quite complicated with other pieces. But the most complicated part of the app, actually, is that it's got to be an infinitely scrolling list of video elements.

And browsers really don't like video elements at all. You put a couple of video tags into any window with Chrome and it gets brought to its knees. So Janessa now had to come up with this way of making this thing that is relatively impossible in even modern browsers. So at first she started with banging her head against the wall trying to optimize a bunch.

Matt will talk about some ways that we can optimize, but this was just kind of an order of magnitude past optimization. She was filing bugs with a Chrome team, trying to get them to fix things, but that wasn't going to work. So instead she was able to use Ember and decide to not actually play that game at all

and only ever just render one video. So if you look at the Vine app and it works, and I encourage you guys to actually go through it, you can scroll through and everything feels smooth as part of the entire time. You would never think that it was trying to play that much video. And the way she does it, she has a Vine controller that has reference to this Vine view that contains the video, and this is some arbitrary video.

Then when the post views are created, and these are just images, they're not the posters for the video because, again, even the posters without video playing will kill Chrome quite quickly. They're just pictures, and they tell the Vine controller that, hey, I'm here. As they scroll and go to the top thing, they then tell the Vine controller, hey,

I'm near the top of the page, give me a video. At which point the Vine controller, which is also doing other crazy things, like because it has the list of the post views, it's buffering the ones before and after, so by the time it actually gets there, they're ready to play and buffered and loaded, and just switches out that post view for its Vine view, which is a video with

the right video, and it's playing. And you can scroll up and down and back and forth, and it's just maintained all of the state that would be normally DOM heavy back in the controller and just switching out the DOM parts that it needs when that needs to happen. Thinking forward, if we think of, so looking at the way that that actually

works, when the, let's see if I can gesticulate wildly over here, at the top we have the item controller, which is the really dumb object with the optimized image, and then when those get inserted, they say, hey, Mr. Vine controller, I'm here, take care of me, and then when they get to the top, it just sends that one to play,

and the Vine controller there has the play function, which it's got this pre-buffered image, this pre-buffered video that it just spits back into the application and plays it. And then when it's supposed to stop playing, the Vine controller pulls it back out and replaces it with the image. So you only ever have that one video on the screen at any point in time.

So this idea of swapping out DOM from heavyweight to lightweight objects is something that we get to use actually a lot in Ember. The Ember list view, for me, is a great example where it's only rendering the things that you see on the page, and as you scroll, it kind of garbage

collects the ones from the top and just renders the new ones. So you can actually have an infinitely scrolling list. Not the Pinterest-style, just a very, very, very long page that then gets paginated when the browser starts to cry actually becomes infinite, because you just clear out the DOM. And so when we're putting our entire front-end application into your browser,

we need to be aware that we actually have these tools available to us to just remove things and put them back in when we need to. And the architecture of Ember actually provides us with those tools quite easily and comfortably. So the last one that I want to go into is this idea of two applications in one.

So SimpleReach has a report section where publishers can go in, and they can look at their data, they can filter it by date, the categories, the tags, come up with these kind of insane reports that they might need to give to other people in the organization to show them how this content's doing.

However, they want to be maybe sending to people in the organization that do not have access to SimpleReach at all. They don't want to be able to deal with these logins for all these other users. So they want to create a public report that they can just share a URL with, which would have been all fine and great, except our app didn't handle authentication at all. Authentication is handled by device before people get into the app. This was strategic, because we actually used that authentication layer for

multiple different applications. So we really didn't feel like we were unable to come up with a way of somebody to go to the app, suddenly be public, or suddenly be private. We had to redirect them when they got to that URL. So the two ways that we first thought of solving this, in a kind of naive

way, was, well, we could just make a new app. That would work, put it on a different route with very similar code, and that would show the reports. But again, if you look at how similar the public and the private report pages are, they're close to identical. And that would have just been a massive amount of code duplication, which makes everybody sad, and bugs, and all sorts of things.

The other one was biting the bullet and actually moving authentication into the Ember app itself, which I know a lot of people here are probably like, yeah, do that one. But for this feature, it really was way too heavy of a lift. And again, it would have had serious impacts on other parts of our infrastructure. So we really didn't have that option available.

So the option that I ended up taking was just hacking it. So what we ended up doing was, OK, we just had another Rails route that wasn't authenticated, and put our same Ember app up there, and then just included another JavaScript file with a new router. So this new router just had that shared report page.

The second piece of the Ember application that just literally got stuck underneath the bottom of the other Ember code was a new application template to get that gray instead of the black. Just the controller needed for this one piece, and a new application controller.

And that was it. And so we were able to create this public app with just this code that you see on the screen, and zero effort. I know my developer senses were tingling, being like, no, you shouldn't do this. It's a terrible way to go about things. And I agree, but it works, and we have a public app. Yes, we're sending the public people way more

JavaScript than they actually need. But they have it, and it didn't take long to do. And as Steph goes into talking about Ember CLI tomorrow, the build tools are coming that will actually allow us to do this for real and without hacks.

Thinking of, in this world, we are sending our entire application to a browser. We can send different types of people, different applications entirely. Back when your applications were all server side, to do that, you had to literally be spinning up different machines, and copying things over between them, and doing the DNS routing for this. For this, we just decide what route are you on?

What kind of user are you? We will send you this compiled piece of JavaScript. If you're a manager, you get the setting screens, et cetera, et cetera. If you're not a manager, we just don't compile those screens into the JavaScript that gets sent to you. So your code no longer has these if current user dot is manager do blah. It's just this user isn't a manager, of course, because

this is the JavaScript code that they have. Same thing with premium or paid clients. If you have people who have access to free stuff, don't give them the paid stuff by just not sending it up to the browser. And certainly, the build tools aren't there yet, but I'm able to lean very heavily on Steph in New York City, and we'll make sure that when that is available,

we can get rid of the hack. But at the moment, again, it's this idea of how can you split your app up now that it is a lightweight thing that you can just put places. Where could you actually be pushing other pieces around the code? So that's kind of four different pieces. We had a few that we can talk about if

you want afterwards. But essentially, again, the thing is these are tasks that seemed really hard to us. Maybe they aren't tasks that you would want to accomplish, but they seemed close to impossible. And by thinking through this new different paradigm, we were able to actually fix them and come up with a way to

deliver the features on time, and features that were actually more awesome by the end of the day than they would have been doing the traditional way, because we had the ability to do new things with Ember. And with that, thank you. I'd like to say thank you again to Janessa for her awesome examples and talking us through how our app worked. I'm really sorry if I butchered how it actually works, but I think I got there.

And then thanks again to Andy at Pants for helping us make these slides look really great. Thank you. Thank you.