 All right, so the format is called dialing it in. And the three things I'm going to go through are, what does this format actually look like? How can one contribute to it? And then we'll go through an example. So we'll have some people who have dialed it in already, and we'll go through what that means. So starting with what it is, it's meant to be a very user-driven model where people offline when you're working at home, working at the office, if you have ideas, questions that you're running into, just make a quick little video of the question you have and send it in. In the format today, what we're going to do is, for a lot of people, by the way, standing up here in front of an audience, regardless of the size of the audience, is not the easiest thing to do. Some people don't want to do that at all. And actually, a lot of times it's just, it's in the moment that you have these ideas, these questions. It's just hopefully a different way of capturing things. And potentially, we'll see, I guess, if this plays out, it's a way to ask a visual question in a way that's different than an audience just auditorily asking questions. I think there's going to be more detail showing by example here is some code that I'm having a problem with. Maybe that'll engage people in a different way. So that's the idea. I think that there'll probably be one to three minutes. So we'll take the kind of Twitter approach to duration. We can't have people going on and on about their problem. But three minutes, this should be enough time, hopefully, for you guys to kind of encapsulate what the problem or idea you have is. And then how many questions we do will really come down to how many questions you send in. Sending the questions in is just a matter of sending it to an email address, either dial it in at emberlondon.com or dial it in with dashes in between. Both of them will work. So just send that in. What we're looking for is your name. I guess you can do it anonymously if you thought this question may be quite silly. So I'm just going to put it anonymously. That's fine as well. A title for it and a link to the video. You can choose whatever site. I think I'm mildly right now prefer YouTube, but it doesn't really matter, whatever one you're most comfortable with. Also, if you want to put your Twitter handle, a JS bin, or whatever it is that you think is relevant to this, throw that in there as well. We'll include it, but you don't have to. So we're going to go into some dialed in. We have some anonymous people who have dialed in some questions just to try out the format. But before we do, let me just ask the audience. Does the format make sense? Any questions about the format? Pretty straightforward. When you say create to be asking a question, what does that mean? Does that mean editing together something? Or is that just you showing yourself tapping or talking? Well, I think I don't want to necessarily constrain that too much right now. I think it probably is open to your imagination. You'll see in the format that these anonymous users chose this time. It's fairly similar, where it's more about looking at the browser at the terminal and seeing as a little screencast. But it could be you as a person just sitting there showing your face and asking the question. That's fine, too. It loses some of the advantages you might have, but it doesn't really matter. It's too early to say no to any of these ideas. Any other questions? Any other suggestions? Again, suggestions are fine offline, too. Let me know afterwards if you think there's some ways that this could be done differently or better. So what time is it? It's time to dial it in. So the first question comes from John Smith. And John is asking the question, when you're using Ember CLI, how does the testing vary between the command from the terminal and from the browser? And I'm just going to click on his question. Hopefully, oh, I clicked on the wrong thing. Jamie, which one do I try to click on this video link? But it doesn't seem to be working. It's a subarctic slide for links in Basecamp, I think. I think you can probably also just click on that, too. Yeah, that's a different one. Let's see if you go to question one. Yeah. Link for now. Yeah. OK, it's a question one. I just wanted to ask a quick question to the group about testing. And specifically, what I'm looking for is an understanding for what is different when you run testing in the browser versus from the command line. I've got here a simple app. It's got almost nothing really in terms of code. There's quite a few routes and so on. But basically, the tests that exist are those tests that kind of come out of the box when you use Ember CLI. So if I go to the browser and I reload it, and what you'll see is that it runs 115 tests and 115 pass. I'd expect when I go to the Ember CLI that I get the same sort of result. So if I say Ember test, you see that actually it isn't the same. First of all, there's two things that are different. One is there's only 109 tests, not 115. So what happened to the missing six tests? And lastly, there was a failure. So you can see that a lot of tests are the same. And I'll go up to the failure. So here's the case of the failure. And it's about a component being rendered. Other components are rendering fine. So again, it's not so much about this specific error, which I'm sure I can figure out. It's more about the process that Ember CLI has set up for me and how is the testing process different when I run the test from the command line versus from the browser. OK, so that's question one. Now unfortunately, part of this format, what it means is that there's effectively work for you guys to do. You can't dial it in, it's not being in the audience ever. I didn't come with the answers. John asked that question. I thought it about it a little bit as well. But if anyone experienced this before where they're seeing variation between the tests that are taking place in the browser versus the tests that are taking place in the command line, does anyone have any idea why that variation might exist? So can you force it on the failure? Yeah, I think so. Different when I run the test from the command line. Yeah, so there's a hint in there, isn't there, I think, in terms of what is going on. It's small print, so maybe hard for people to read. But down here, if you look at the small print, it's talking about a problem with the bind function. And for those of you who are aware of it, there's a problem with Fenton JS being able to attach to bind that's not implemented in Fenton JS. So that particular error that I was pointing to is actually a result, probably, of just that. So there are some ways to get around that. But that explains the failure. I still actually don't know what the answer is to the variation and the number of scripts that are run. So 115 versus 109, I don't have a clue as to why that is different. So Fenton JS doesn't support function.bind out of the box. You've got to polyfill it. And I actually think that's a feature rather than a bug, because it keeps you honest. Because IEA doesn't support function.prototype.bind. And there are various other browsers that don't. So I've had this error a few times, and it's really useful. It means Fenton is quite a good canary in the coal mine for all the browsers. And it won't stay that way, unfortunately. But I hope that people will start using IEA as well. We're not very well controlled. Has anyone seen the problem of a different number of tests being run headlessly than in the browser? So maybe we'll retitle this mystery science theory to the thousands. But it is, I'd be interested in hearing, and I'm sure that John would be interested as well, in hearing if anyone does come up with this problem and is able to determine why there is a variation there. I mean, it does say there are 150 assertions of 150 pumps. Is that the same as tests? Or can you just say one assertive test at this point? Well, that's a good point. And it's possible that maybe some of the assertions were blocked because of this failure. Can we see the end of the test output? Yeah. I think you do show it. Do you like it? I think you're actually about one time. Yeah. Command line versus from the browser. It was earlier, wasn't it? So I think nomenclature on my guess is that tests and assertions do match up. I mean, they seem too similar and numbered to not be meant to be the same sort of thing. But if it's assertions, then is it possible that some assertions were not run because it ran into the line problem? That was it. It seems possible. I don't know if that answers the problem. But I'll ask John to look into that and you can come back to us and have a look. Do you know if the back bootstrap component, do you know if it was one that John had installed from Bauer or was it one who read it himself? It was indeed one that he had written himself. So yeah, this was wrapping a jQuery widget. And I don't actually remember if John had talked about this, but I think that he was saying that he had taken the code from Amber Add-ons, but I'm not sure. In any event, it is likely that it's basically, in the central wrap, a jQuery product that we've used blind and has caused the problem, especially, or certainly if people are using supporting IEA. OK, so let's move on to question number two. So we've got a relatively simple Ember project, which is using Ember data. And when I first started using Ember data, everything I was doing was pretty much looking like this. I was basically setting an attribute, but I was giving it a string or maybe a number or possibly a Boolean attribute. But that was it. Obviously, the next step up is to start to define relationships between entities. So in this case, what we see here is that there's three properties, and they all have belongs to or one to many relationship with the user's table. And really, my question is not how to use the belongs to relationship, but more that there is a particular case I'm running into where a get request to user might fail. I don't actually have permissions to see a different user's profile effectively. So this belongs to, would immediately, without automatically, go and make a get to the user table, and it would come back unsuccessfully. I don't know if there's any benefit at all to using a belongs to relationship in this situation. I mean, I could obviously just change this to the attribute string, in which case the owned by property would still be a foreign key reference for lack of better term to the user table, but emmer data wouldn't go out and try to make the get request, which would ultimately fail. So I'm just new enough now to not understand exactly what I'm getting out of all these relationships. There's some obvious things. But is there a reason why I should still hang on to using this belongs to in this use case? And if so, how would I do that so that I'm not negatively impacted by the unsuccessful gets that would come out of the box? I forgot to mention this. This was Alan from Jane Weiss. Jane wanted to apologize. Normally, she heard voices in solo, but actually had a cold. So I think the question could be maybe raised up a little bit of a level and just be about when you're using emmer data, there is the basic semantics of defining the model, but then there's also the relationships. A lot of the power comes from the ability to have those relationships in place. But are there use cases? Are there scenarios in which you might want to move away from the relationship and just kind of dumb it down a little bit, change a foreign key relationship or what have you to be just a string or a number, I guess, for using the numeric system? So that's the question. Has anyone come into a situation similar to James? I don't know the purpose of that value, but what are you trying to resolve by having the owned by or the? Well, so it's in other use cases where there's a useful relationship where, in this case, we're talking about an activity. The activity has an ownership by a user. But in some of the use cases, you may have a user who doesn't have permissions to see the underlying user. But in terms of the presentation or the interactions or the actions around that relationship, is it a trivial type of relationship where all you want is the name of the individual versus something where there's a great degree of complexity where you need to be able to act upon some sort of action related to that individual? So in other cases, what you get out of the box by having that relationship there is you have a whole user profile to come back with that. So if I wanted to go to a screen in which I was able to talk about the user and their name and other attributes about that user, that would all be made available to me out of the box. And that would be some of the benefit I'd take away from it. But in this case, obviously, I'm not doing that. So I think initially, when I first started using Ember data, it was in a pretty rough format, much more refined now, getting close to being a 1.0 release. And I think that there was some caution in my part, initially, or in Jane's part in this case, that maybe using the base functionality, just that basically the modeling and not the relationships seemed like that's where all the problems were coming in. I just stay away from that. I'm now taking the opposite approach and trying to use it in its full capacity. But I'm just wondering, again, if there are cases that people are running through, they just feel like for whatever reason they want to work around Ember data. So in this case, you ask the model for owner. That goes to make it get request for the ID that it sees. And the server comes back with a 401 or a 404 or something like that? It would be a 403, right? I don't know about the rest, right? Yeah, right. So yes, the question is then, I assume that Ember data at that point throws an error into the console and things sort of like jam up. What would you like to happen just for that owned by to resolve to just null? Well, so in the case, if I set this as string as I have here, what would happen is I would pull back the record, he would have it, let's say the user who owned this particular activity was user one. That would be, I'd be able to see that user one was the owner of this activity, and that's fine. But it would not actually go out and reflexively go and request the user profile for one, getting this error. So I'd basically be able to have this model defined once, ignore this in this case, and in this use case. I'd be using the other attributes, which I do care about, and do have access to. Right, so in that case, back to Tom's question of how do you actually display that value in the UI? The owned by? Yeah. Well, so that's what I was saying. I think that in the case of having it set to a string and what I'm trying to avoid in this use case, you wouldn't be displaying it. The point is you're actually not displaying owned by. And the reason you still have it in the model is because in other use cases, with someone with a different set of permissions, through a different use case, may very well have access to, let's say you're the owner of the activity. You'll be able to use that owned by link to basically navigate and see all the user profile information as well. It seems like there should be some option to repeat that. Well, so you're right. There is actually something. I wasn't sure if someone would mention this, but there's this idea, at least, of being able to load these relationships asynchronously. So as part of the configuration, you can specify that this relationship is an asynchronous one. And therefore, when I make a request for this, it doesn't actually automatically go out and do anything. So it's only when I start to ask for this directly or ask for attributes off of the object that it points to, does it go out and make the get request. So that's probably the easiest answer to the question, is just setting it to asynchronous. And in fact, if it's not async when you request this model, does it do the other requests as well? It does. And apparently it's like they're going away, they're changing the default. How do they get rid of the flag? No, I don't think they can rid of the flag, though. But the default was to have it asynchronous, and now they're changing around. I think that belongs to, I'm not sure whether this is already the case or not, but I think that belongs to, when it's not async true, assumes that you have already loaded, that you already have that other user that it refers to in memory, that you have to manually go on and got that model loaded in as well. And if it's async true, then when, and only when you request that property, then it will go before the AJAX request. Did you basically get a promise model that you can say if it's failed, succeeded, and I like that stuff? Yeah. My brain was fuzzy, I don't do that. But I think there is an interesting question of, even if it was just inconsistency and you didn't mind, so say you wanted to show the owner, but it's possible the owner had been deletion, and in that case you didn't want the app to just fail. You would want it to just fail silently and just go, I don't have an owner. It's not a big deal. So at that point, I'd imagine you could adjust the adapter, perhaps, and override find belongs to, to just do something a bit different in the rejects case. Just swallow the error. I would just report it to on-site. Overwrite belongs to. Yeah, find belongs to. I think it's the book. It seems to be crying out for you guys talking about having some sort of promise or behavior where if it's not got access to the object, you can have it default. Yes. Register value. Yeah. Yeah. This is even a problem in the embedded order. We should be talking about embedded data. So it seems the problem is that the server has given you an ID or a user that you're not able to access. And you need to think carefully about what you want the behavior of the app to be in that case. Maybe if you're not authorized to see that person, the server should not have returned their ID to you. And if it is that you want to see their name, but not the whole thing, maybe the server should actually just be sending back the name. So I think it's more like a whole problem. Like you'd have this issue, even if you weren't using it, but if you've got any JavaScript application where this thing could be related to something else, but you can't don't have permission to see that. Yeah, I think that's fair. What behavior should the app have in that case, I think that's really what we should be talking about rather than like, I don't know. So I think when Jane asked this question, she was thinking about things in a different way than she is now. I feel comfortable saying that. And I would say that what I'd like to do in this question area, and again, I don't actually know in the audience how many people are actually using Ember data, but raise it up a level and not have it be too specific about this use case and be more about in their people's use of Ember data, are you finding situations where what it's giving you, you actually want to work around at times? Are there exception cases that you've run into? Or is the framework solid enough now at this point that you feel confident in using it? I think a bit more flexibility does make a lot of sense. If you could, yeah, if it's return to promise, that the right handlers would success in our app. If these did return promises in the right handlers, success in our app, like, say, the belongs to relationships, how do you provide, yeah. I'm just going to bring up the docs. Yeah, sure. When you've got async true on, you get back a promise object? I think you do in both cases, don't you? No, I think with the synchronous version, you either get no or something. With the async version, you get back a promise. So synchronous is basically saying you're expecting the data to come back sideloaded, and so therefore the master record will come back with all those practices. Either it will be sideloaded or a root up in the hierarchy will have already loaded in all the relevant user records. So you get, let's see where is it, promise objects. I was thinking about this in relation to how the data originally was with the white hydrated models, at this point, it's the same thing. So it's a promise, so then you can chain down to increase it like any other promise. But when it resolves, it proxies all the proxies of the objects that it resolves to, so you can take this promise object, glue it into your template, and access properties off it directly, so you can treat it both as a model and as a promise, and it will work in both ways. So this is something that's worth knowing about, and there's a sibling to it called, well, it's a promise array and promise many array, but this is what you get when you've got an asynchronous has many, so when you've got either a bunch of embedded IDs to related records or when you've got one of those link properties, you'll get one of these promise arrays back, and it looks like an array when you want it to look like an array and it looks like a promise when you want to chain the bin on to the end of it and deal with this old project. Yeah, it has a bunch of properties, like it's pending, it has failed or failed or whatever, so in your template you can say if people has resolved, then display them. Yeah, actually I've got a little example of something I did today where I needed to work around Ember data, and I was really pleasantly surprised by how easy it was. So, this is sort of related, it's like a similar problem of space, so I'll just show you the code I ended up with, it's not necessarily complete. So the problem I had was I've got a bunch of favorites in an application, and the way you deal with them is you get edit favorites and you toggle on and off various different things, and then in the end you get done, and so I wanted to batch up the saving of all those favorites into one API request, and Ember data doesn't provide that behavior out of the box, it does provide the batching up of fetching records, but not assisting them, so I was like how do I do this, how can I accommodate this, so I created a favorite adapter so you can see the file name is app adapter's favorite, is this bigger that for everyone by the way? So, it's a favorite adapter which extends the application adapter, and what it does is just, and I wanted to make this change for any sort of operation, so creating new favorites, updating existing ones, and deleting old ones as well, where in order to delete a favorite you just set it's deleting flag to true, and then send it over the wire, and the server takes care of getting rid of it. So, these are three hooks that you can override, create record, update record, and delete record, and they'll have to return a promise, and so what I'm doing is just for any of those operations I'm just scheduling one of these batch updates, and scheduling the record into it, so when it happens I either create a new batch or use the batch I've already got, and this batch has like, this is a, I'll show you what this looks like in a sec, so you've got this notion of a batch, which is a bunch of stuff which is gonna happen like next, and then just add this record that we wanna change onto it, into that batch, and then return the promise off the end of the batch, and then what batch looks like, it's a really tiny little class, it's just an array of records, and then this callback for when you're allowed to go and actually do the work, and it just uses ember run next to stick this operation into the queue of the next run loop, and it's just gonna call back to whatever it's processed callback was with those records, so really all this object does is keep track of this array, and then give it back at the right time, and then batch update is just like a little bit of custom serialization of those records into the payload I want that I know my API expects, and then returning the promise of that Ajax operation there, and so this for Ajax, that's the Ajax method, and it's given to me by the adapter, so that's an ember data thing, so when we build URL, it's an ember data thing serialized, those are all given to me by ember data. So you're not available, connect to the internet. I said Siri, oh hey Siri, or something like that. Build your, so most of this is provided by ember data, and I was really delighted that ember.run.net is just giving exactly what I wanted, because if you imagine why I'm ending up having to do in sort of further up in the application, is a bunch of favorites have changed when the user hits done, and it's gonna call save on every model in that array, and then I don't want to have to worry about it anymore, and then down in the application adapter, it's doing this job of like, tidying them all together into this one batch update. So this is my example of how flexible ember data is now, like how easy it is to hook in, and note that this is just for favorites every other type of modeling system, using regular kind of REST calls. This one just happens to be different and weird. By the way, what Jamie just did here, running up and demoing stuff in either looking at websites or we're looking at the command line, command line might be a little harder for people who don't have laptops, but if people want to do that, that's open game. Feel free to. Thanks. If anyone wants to. Okay, so let's move on to the last question. Okay, I think most of you are probably familiar already with MomentJS, and my question isn't about MomentJS by itself, but it's more about how to use MomentJS effectively within an ember and specifically an ember data environment. What I'd like to be able to do is be able to specify in some of my ember data models that a particular attribute is either a date or a date time type, and when it is, it will, when brought into the ember universe, it will immediately be wrapped as a moment object so I can work with it as a moment object while I'm working with it. And then at the end, I can save it and it'll go back out to the RESTful API as just a string format. So that's actually, that part of things is pretty straightforward to start out with and I'll show you what I mean. So here is a transform object. So in this case, what I've done is I've taken the date and I'm saying if you choose date, it will come in, it will wrap the string that's coming in as a moment object, it will then bring it to beginning of the day so that all the time information is effectively lost. And then at the end, when I'm saving it, it will deserialize it by putting it back into a string format. And that works, there's no problem with that. The problem, however, is that now this property in the ember data model is a moment object and if I change that moment object, I will no longer be observable. So my question is, is there a way that's relatively straightforward to maintain observability so that I can work with it as a moment object but if it changes things like the isDirty flag, so on and so forth, get changed as they would if it was just this string. So just as an example, I'm looking at the ember inspector, I've got a model up here and I'm going to go ahead and assign the E variable to the model. So if I go over here and I can just check quickly, I can just get isDirty, which is a way for checking if this record has been changed and in fact it has not. Let's change something simple like I'm going to say E set type to Fubar and we can see that isDirty is in fact true right now. If I save the record, ignore those messages, we can now get ourselves back to a false isDirty state because we've saved it and it's back to normal. Everyone's happy. Okay, so we want that same behavior that I set type to Fubar. I want to be able to set start time to some other time than it is right now and have the same sort of effect take place. So here I can say get start time and I'll see it's a moment object. I can kind of look into it and see, oh yeah, well, so it was December 18th at 4 p.m. What if I wanted to change that to say Christmas? So I'll just go ahead and say set start time to, let's get, okay, well, we set it to first of January. The end result is we have changed it. So let's go and take a look and see if after all that, our flag is already in the answers. No, it's not. And that's because start time, we changed attributes within the object, but the object itself is not observable by the Ember system. So therefore, Ember and then Ember data are unaware that anything has happened or anything has changed. Okay, so that was from Jack. Does anyone have a view on, I think we can talk first of all, if anyone has a view on whether Ember moment jazz is an appropriate form to transform into, but I am more interested in the observable thing because it's more broadly applicable. I mean, whether you have some sort of a nested object that you want to maintain its observability, that also would apply moment, just an example of that. But people run into this, people come up with a solution they think is, I think in this specific case, you just call clone on the date before you then set it, and then it's a different instance. I don't imagine that's what Ember data is checking. I don't use Ember data, but in the ORMI use that works, I think. That makes, when you call set, it just, what will that make sense, right? Because the reference has changed and that initial reference is observable. Yeah, because Ember data is more clever when you set to check, because it's the same as it was before. Right. But if you close the moment before you stop. So it's more about the internal state of an object, being able to change, manipulate the properties within that and still have the observation that things have changed. Yeah, you're interested in sort of that, yeah. Perhaps if we were helpful if we could define a mental and trust form to compare to instances of the object, because as you can see, we're preparing for those part of the season that's helpful here. So we have to compare, we just have to get out of cases as well. Like if you have more components, help compare. So maybe have an add-in or something like that that is able to be used instead of just the Ember, just more, when you plug that into the Ember system. Yeah. I think there's a related open pull request to use is equal to compare to objects when you call set, remember, so when you call set, it'll check with, I think, triple equals whether it's the same as the part that was previously there. If it is, it won't bother calling the notifications. Whereas in this case, that would match it to the same instance where the data itself has changed. Whereas there's a pull request to use as equal instead and then you can enter when your own is equal to check the two versions. And then that might help it, I don't know. But there's performance concerns whether or not it'll get merged. Any other thoughts on the question? There's a way to capture that through the set of itself. And then sort of be able to fly through the set of those two versions. So kind of have a different flow about it. Well, I don't know how unique that you could override sets. So I think one approach you could take would be to wrap the moment objects in another object, which is kind of Emberate, something that can notify property changes and kind of like translates the moment API to something that's a bit more Emberate and can notify all the right objects of mutations. But yeah, it's a... In this case, it feels a little bit silly with the moment JS object. But actually, Jack did something similar to that in that, not for this particular problem, but actually where there was a dictionary of attributes that were basically showing up. In the model, you had a property called markers. And markers was really just a whole bunch of name value pairs that were existing off of that. So in the transform objects, what Jack started to do was just to go through and in the transformation process, make sure that all those objects were Ember objects that were inside the object and make them observable. So I think that's similar to what you're talking about with one of the JS, right? Yeah, and it's like, I've done... I've needed to do something like that for taking something like the local storage API and treating that as if it were just any other Ember object in that you can plug it into a template and have it be observable and have it... It's all about the spatial, isn't it? It's all about it triggering changes when you expect it to. And I found the easiest way to do that was just to wrap the local storage object up inside a class and just do special things on Gaten set and then call notify property change at the right times. And then that allowed me to talk into... There's a top-level DOM event for when local storage changes from another town or around the window and that allowed me to sort of capture that and just turn it into a change notification. Okay, so if there are any more comments about question number three, which is quickly reflected on the format. I mean, obviously I was very lucky to be out drinking with Jack, Jane, and John. And they all volunteered to do this before we even had the format in place. But is this something that you guys could... I mean, just to show of hands, would you consider putting your own question into a format like this? Okay, that's good. Right, and is there anything about the way that the format is run that you think would make it better? Is there something that would make the ability for Jamie or someone else to run up here and start typing it to keyboard or is there anything you'd want to have available? Supplying code samples with the video would be useful, so you can actually... Because the first one is very difficult to comment on without seeing code samples. Yeah, almost like a JSP, with the recreation of the problem. That's possible to do so. And would that be then? I guess we'd print that out. Well, we can figure that out. Or even just as people are talking, you can refer to it and flip to that window. You can refer to it and maybe make your mind change in a sense of doing a mind-pack session. Okay, well... I think the question around the conversation together with the forum says quite... So it's great to see you can see the question. It's a good deal, the conversation with the people. Yeah, I think that's a good idea. In fact, yeah, we should post all three of these to the forum afterwards and the answers that came up in this session as well. So for those of you who raised your hand, dial it in at emeraldondon.com. That's the email address. And we'll look forward to seeing more questions as you have them. What did Jack, Jane, and John use to record better questions? Well, I only talked to Jane about this, actually, so I can only speak for her in this case. But she used Camtasia, but Screamflow or Camtasia, the two big ones, and then I'm sure there's a million other ones, but those ones work really well. You can use QuickTime on your Mac as well. Okay, great, thank you. All right, let's hear it to dial in.