 So the first thing I wanted to mention, and I won't try and demo it because we've not really got the bandwidth, is Heroku recently put out, it's in beta at the moment, but this is and will be an officially supported Ember build pack for the Heroku platform. So this means that you can hook up your Heroku pipeline to your Ember CLI-powered project and when your CI passes Heroku will pull in the latest code base, perform the build for you, put it on the right dyno, all the rest of it you can make and so I think what it does, it's composed of three build packs, one of which is a no build pack and then the Ember CLI build pack, which does a bit more, has a bit more intelligence around Ember apps and then Heroku build pack static by Terence Lee is basically stands up engine X on a dyno to serve the static assets. I've tried this, I've been trying this a lot at work and it's worked wonderfully for review apps. So when your team make a pull request to your Ember CLI application, Heroku will notice that automatically stand it up on a temporary sub-domain, everyone can review what's going on with it. It's pretty fast because because Heroku is able to cache basically the node modules and power components, directories between builds, each build winds up taking around 15 seconds, 30 seconds, that kind of thing depending on the size of your project. Really powerful stuff, keep your eyes on this for Ember Conf next month and keep eyes on Heroku and fastboot as well, I hear there's stuff going on there. So that's the first thing. The second thing, has anyone ever used an animation library called Greensock? Okay, so it's an old animation library, it comes from the Flash days and it got ported to JavaScript and it's still alive and kicking. I remember in the start of my career I was, yeah, so let's I've not really, I think the last thing that their main target was Greensock, they were trying to bring it open source equivalent and then Google brought the guy who basically created it into Google and I think that's kind of lost, he has lost, it's lost. So what I want to show, see how long it takes me to do it, it's not really about Greensock specifically, it's more about interoperating with libraries like it and I think the same things apply to D3 and to things like the A-Seditor, but what I wanted to try and do was let's make a new roots, let's call this demo and eventually, let's pump the font size a bit and let's make a new component, I'm going to call it cool component, let me just remove that button from my main layout there and let's use cool component in here. So let's try and think of a simple application of this, what I want to do basically is animate in some shapes on a Greensock timeline, but then allow Ember to control that timeline and this is something I've been playing with at work, it was a client requirement that we use Greensock and it just impressed me how straightforward it was. There was a licensee in other words, that actually made it in terms of expression. But basically, they gave a compiled version of certain projects, but not really commercial ones, so they should buy it at night. So that's another thing about this, I've spent this week using Greensock with LiquidFire and Intropp is absolutely fine, it means that you end up not using the animate stop, it's animating helper functions that LiquidFire provides, but it's broadly speaking no problem at all, so let's make these in my box. Do you see a difference in performance between the two though? I wasn't doing anything heavy enough really to notice, maybe on mobile it would have shown up, but all right, so let's say we want these to drop in one after the other, so I'm going to import, let's go for the one thing that using Greensock really reminds me of the flash days, I've got to say. It's not terrifically well packaged for importing into WEMBA, but RUNSPIRED, Crystalburn has created an add-on to allow you to use it. So I want this to come in, let's say, I did insert element, let's make a timeline and let's get hold of those objects in here, these rectangles I've made, it really frustrates me to have to switch to each rather than for each when working with the jQuery object, so I'll turn it into a ray first and we'll say timeline, so Greensock has two things, it has tweens, which should be familiar to everyone, and timeline, which is a way of scheduling a load of tweens in, and once you've got a timeline, you can schedule other timelines into it as well, once you've got a timeline you have complete control over its playhead, so let's say obj, and this is the duration of this transition, let's make it a little quicker, and let's transform it from let's say just minus 300 pixels to that, okay, so there's a very simple animation, it's got the ability to schedule exactly, to determine exactly where in the timeline this thing comes, and I'll say it'll be a quarter second before the previous one's finished, you see what I mean, so it's slightly more staggered, anyway, this isn't the point necessarily, the point is how to hook this up to ember, so let's make a button, and when I click that button, in fact, I tell you what, let's say this timeline is paused to begin with, paused at the outset, and I'm just going to actually make the timeline available, that'll probably punish me for re-renders, but for triggering a re-render, so let's make timeline, yeah, could do that, but then the DOM won't be available at that point, so let's say timeline is a computer property that just returns, and you timeline and caches it, and now we can, now we will have a stable timeline instance around, and that seems better, okay, so on click of this button, oops, I was really hoping with closure actions I'd be able to do something like that, but unfortunately you can't, the scoping doesn't work quite as you'd expect it to, this.get, let's see how that's all worked out, what is that, yeah, it depends, depends how you address the action, so if you address it like that, a named action, it will look it up in the actions hash, if you address it like that, it's just going to find the property, yeah, fine, who can see what I've done wrong here, see what thing here is component default, I expected that to work, let's see, but then again, there is no this for it to have to deal with, I'm surprised about that, well, in that case, I'm going to do what I've suggested, I'll waste any time, that's a good warning, take heed everybody, yeah, it does seem new, okay, cool, so I've got play, let's add in pause button, it's probably a little too quick for me to work with at this point, so let's make this thing a little bit slower, okay, let's have a reverse, that will complain because there's no, there's actually nothing to talk to, okay, now it'd be nice to have a slider, so this is going to see, we'll bind it to something I'm going to call progress, which is what green sock, green sock, it's a number between north and one, as to how far along the timeline you are, we'll define that computer property in a second, min is zero, max is one, step, we'll say is, actually I don't know if you can say a fairly small increment, and on input, we will meet progress, okay, so that's saying when the on input event is triggered, we're creating a closure action, we're creating a mutation function around this progress property, and we're going to pluck target dot value off of the event, which will be whatever the value currently is of this progress input, I'm going to create a progress computed function, now hopefully let's just see, I'm going to, just in case it's the import that's messed things up, this doesn't really depend upon anything, I mean, technically it depends upon the timeline, but we won't worry about that for now, so to get this, what we're returning is this dot get, timeline dot progress, in green stop the getters and setters tend to be this way, a function with no arguments gets the value, a function with arguments sets it, I do not expect this to work first time, but we'll see, let's see, oh, so the thing I need to do in order to fully wire this up, it wouldn't just work automatically, is this timeline, let's just break this out a little bit, needs to tell our wrapping component when things are changing, so there is, where's my typo, no, Tim line, I've typed that about 300 times this week, so on update, we're just going to notify property, property change of progress, and in fact, let's just, I'm going to tempt fate with that, you maybe saw a little bit of a glitch there, I'm not quite sure what that is, I think it's a rounding thing, so this input is trying to adhere correctly to its steps, you'll notice also that it's still, it's still busy playing, so you, you, it's trying to fight you as you drag it, but that's really easy to fix, action, pause. So, I found the same thing with D3, it's not that you need to like, create an element and then just go right D3, you do what you want with that and I'll just trust that you're going to do the right thing. With these third party libraries, you can always hook into HTML bars really nicely, with D3 it works great, because with D3 you could effectively take one of their layout functions, take the raw values that it produces and plug them into your HTML bar of templates, and then you've got this direct declarative correspondence between the data you're producing and where it's wired into the DOM, you know, you can, you can see exactly the DOM you'll be getting, effectively. So, Green Sock is a nice library, I love the fact that it's survived since the action script days, and I love even more how easy it is to plug it into Ember. Any questions about all that? On D3U, is there any kind of reference code that you think it's a good way to kind of see Ember D3 integration? I mean, I looked at the add-on and I didn't see anything that looked particularly... I would suggest, conferences, yeah. EmberConf 2015, there is an absolutely wonderful talk from this... I remember that there's a younger guy, yeah, Chris Henn, Dynamic Graphic Composition with Ember, off the back of this talk, he ended up working with Tilda for a while, and this is, this is just perfect, this is like Miguel level of component composition. So, yeah, check this one out, this is really great. It's going to go through a major release, which is going to be a pretty significant change. Oh, really? Oh, I know that. It's meant to work with SBAs more... Sounds good. I mean, I think with D3, all of the functions it's composed of, all of the different built-ins, you can always pluck them out fairly easily, and you know, if what you want to do is interpolating between one scale and another, there's a function for that, you can just use that on its own, if it's a certain, you know, type of, what was they called, chloroplast, layout, or whatever it is that you're after, there's always the function standing by itself, feed it some data, get some new data back and you can plug that in. And especially now in the glimmer days where we can have maximal DOM reuse, it's a really nice integration. OK, so, pub time. I remember something that everyone should know. Did you do it? This thing, finding value of an input and using an input to update value, is something that used to not, used to fail with regular inputs because you lose the crucial position when you update the value. Ember, yes, to pull requests, Mr. Ember? A pull request by Narsian, right? Yes. And that's one, the Ember, the HTM about same, the 14.14. Oh, here we go, yeah. The thing is, now there is really no reason to use the input hever hever, you know, the angle of reference, angle of reference input. This happens to be around 40 to 60 times faster. I consume like 20% of the memory. So, don't use the other one, hever, there's no reason. Unless you want to hook into the, into when this thing is added and make perhaps an input text area out of rows of data, that's something you cannot do with the raw HTML input. It's interesting, it's a relatively small change. Yes, before setting the value of an input, you check if the value of the input is already the same thing and if the same thing will do nothing. So, that prevents you to lose the crucial position because you are setting the value to something that is already there. Yeah, so curly inputs are a thing of the past. OK, let me, one last bit of.