 talk style, except instead of people signing up I harass people and now they're gonna talk or more likely other people harass me. So we've got a mix of some people that I guilted into being here and some people who guilted me into letting them be here and I think it's going to be really fantastic. So there's gonna be a little bit of transition time just while they swap their laptops in between but everybody's gonna be up here for somewhere in the neighborhood of four and a half minutes. They've got a bunch of different topics to talk to us about. We're gonna start by hearing from Bill Heaton and he's gonna talk to us a little bit about some performance stuff. He is from LA and in a previous life, come on up, in a previous life was a tattoo artist. I learned some very interesting things about all of these people when conversing about talking here. So let's hear what Bill has to say. I don't think it has anything to do with his past life as a tattoo artist. I just like that about him. Point it at you and you're good to go. Hey everyone. Nice to see you guys. So yeah, I'm from Los Angeles area and today I want to talk to you about majoring performance with the user timing API which you know works in Chrome, which we like as that works. And there's polyfills for other browsers if you want to do that in other places if you will. So this is more of like a quick story about my tinkering and experimentation. And so I blog about these things at pixelhandler.com. And so you can actually see the gist of what I like to share today already posted over there. So I'm going to kind of just jam through some information that I've already shared at our local meetup. So my curiosity about performance kind of is combined with a conviction that performance matters like so I should start majoring things and possibly take some observations and make decisions about what I'm measuring. And I'm not very scientific about it yet. I've learned that I can get better. So this is also kind of a demonstration of you know learning from yourself and how you can improve. And I've had some support from the people that are staying with us at our Airbnb house. But I wanted to compare handlebars 1.3 and HTML bars and see if there was any gains in the application that I tinker with my evenings and weekends. And in case you missed it, we have HTML bars now. Thank you guys who did that for us. I really appreciate it. So that was my curiosity like let's see what this thing can do for me. So where should I begin to measure the performance metrics for rendering a template? So we've been talking about you know embers primitives and we have a router that has this great hook for rendering the template. And apparently everything's done and ready to go when you enter this hook. So right there I can just mark the time, measure it. And but what about after like when is it done? So it has to be done at some point. Well, great, the run queue kind of tells me as I've entered the after render queue, that stuff's done. So I can just capture that measurement and know that that timing should be useful. So should I just use a timestamp or is there something better and that's why I started searching and I found the user timing API which has this like high resolution timing and multi I'm sorry sub millisecond resolution. I was like, that's probably faster than I can think like let's go with that. So later I realized as I was capturing these things that I could just send them to Google Analytics and they can do nice reporting and charts for me. So I'm going to send some of that data there as well as capture my own database. So I created a mix in and I like to share that with you real quick because it's really easy. You may want to try it. But it's super simple, right? I need to mark the beginning in the end. And there's two points when I enter this this hook, and then in the after render queue, and I just need to capture this measurement. So I also have a utility, I'm sorry let me just skip ahead real quick so I'm going a little bit too slow. So there's these utilities, right? Like does window performance exist so I can fail silently if it doesn't exist and if it does, I can use that API to mark and measure. So you can learn more about that just by looking in, you know, searching online, right? I have some links for it I'll share with you after. And then when I wanted to report it, you know, I'm just going to like post it to my API, send the measurement as a JSON document, also send it to Google Analytics for tracking purposes. Again, I'm not going to go through all this code now because it's available online on my website. And again, you'll find the links for, you know, these performance APIs as well and some great tutorials from HTML5 Rocks and that's kind of where I started as well. I decided to capture a few extra things too that sound very analytical like when the application was ready. And, you know, maybe that would be useful sometimes as I dig into these metrics a little bit more. But this is just a gist of kind of what I'm capturing. What was important for me was this duration value. And then that gave me something that I can compare. So right away you might ask, well, what did I find? And honestly, I can't really tell you because all I did was observe the findings. And I didn't really study on proper benchmarks. So Crissel then helped me realize that yesterday as I was talking to him about it, that there's probably a better way to, like, come up and summarize this data by using, you know, normalized data and actually a geometric mean. All I did was kind of look at, like, what was fast and what was slow and kind of show me some averages and, you know, that might help me look a little bit deeper. So I'm going to do that next, right? But for now I'm going to just, like, jam through a couple of quick measurements just to highlight you, like, hey, this is what I saw. And not even talk about them because, like I said, at this point they're just observations and not necessary conclusions. But either way, like, now I have something in my app that matters to my users that I can at least observe and, um, at some point do something about. So I think I'm at time. Is it five? Okay. All right, there's more on the blog so you can read the rest of it. Thank you guys. Appreciate your time. My name is Mitch Lloyd. I want to talk to you about a library I just recently made. It's not that technologically amazing but I just kind of want to put some code around an idea that I was having for a way to bring Ember to a server rendered application. So first thing I'm going to do is plug something. I made a training, a set of training videos recently and you can get those from Tilda's website or you can buy them from my company's website which is at teamgaslight.com slash training. All right, so that's plugging. All right, so I work at a consultancy and I don't get to use Ember as often as I would like and that's because we always start every project and tell ourselves this is just a simple X like a simple blog, simple CMS, simple e-commerce platform and there's no way we're ever going to want a JavaScript framework for this and then three weeks later you know we find that we're looking at different kinds of like react patterns and people are dropping an angular and the fact of the matter is that you know everything seems simple at first but nobody wants web pages mapped to crud actions anymore like clients don't want it and we don't even want to build it. So yeah, React and Angular will give people a quick win and refactoring to Ember seems really daunting. I think that's because people usually approach it thinking you know I want the entire Ember framework in my application. Let's do like a big vertical slice. I'm going to serialize my models, make API endpoints. I'm going to use Ember data, start using the router and finally I'll get to the components which is kind of the end goal if you think about it. And along the way you'll be like oh man how am I going to get these translations over to the front end. Oh I forgot I need the user data over there. How am I going to bridge my URLs between the server part of the application, the client part of the application. And that refactor step is just too big, right? The developer had to make a paradigm shift from server rendered applications to client rendered applications and that's like a big step. And there's no progress until the very end. So you don't want to tell your client well you know we're going to work on this for a week and when we come back it'll be a little faster. This is not something we can tell them. So I'm kind of advocating approach where we kind of think more top down and do a horizontal slice. Let's just grab the component layer first and use that in our refactoring. And you could probably stay there pretty long. I mean components are getting pretty awesome. You could extract data models from there. You could have services that are shared between those components and you could probably get pretty far before you actually want to bring in other parts of the Ember ecosystem. So this is okay so this gives you like some wins really fast or server code doesn't need to change very much and Ember is helping right away instead of kind of slowing you down. So here's how this library works. You just make a element. You give a data component attribute with the name of your component. You give it data adders which is just JSON for that component to be rendered. And I dropped a Rails helper in the readme which will tell you how to make a very small Rails helper to do the same thing. So here is a quick super quick demo. What I've got here is I just have like static content rendered in the index and here's my data component called top-level component and passing it a title. If I actually enable, okay so JavaScript is enabled now and if I refresh the page you can see that I get all this glorious, I mean I'm not actually a designer although you might think so if I'm looking at this, but you can expand like components work nested, you can use services and it's just, it's like a good way to start. So people ask me how this works. It's really not anything weird at all. Ember still initializes on the body. It just doesn't render anything so you can just blank out your application HBS or just delete it. If I, you know, using jQuery it goes, finds those data component elements, renders those components using the container and gives them their attributes and calls a pen too on it. And I've noticed this worked in like Ember 1.8.1 and last night I tried it out in Canary and it continues to work so that's good for now. We'll see if it's delimited compliant but I'm not sure. And the good thing is all those components are connected to one Ember application which is kind of nice over some other approaches that might use multiple Ember apps. So check it out. It's there at GitHub and I'm too much on Twitter. Thank you very much. So this talk is not so much about what I know. It's more about what I don't know. And it is called Ember testing with chemistry dog. I'm chemistry dog. I've only been messing around with code for about a year and I only kind of really started to learn to program in a serious way last summer when I attended the Flatiron Schools immersive web development program. If you don't know what that's about it's a three month long program where at the time they mainly taught Ruby on Rails and maybe like a week of JavaScript if you're lucky. But now I think they actually teach Ember which is cool. Honestly I didn't learn that much JavaScript there and a little I did learn I found pretty confusing. After the program was over I started interviewing for jobs. One of the places I interviewed was simple reach. During my interview I literally was like I don't know JavaScript. I know this is a JavaScript job. I don't know JavaScript. I mean I know a little. I want to learn. I'm trying to get better. But I really don't know it yet. So luckily they took a chance on me and I've been working there quite happily for the past four months. And now a lot of you probably even most of you have been developers for a while and you may have forgotten what it's like to be so new at this. So in case you've forgotten what that feeling is like a lot of the first month or two at work I felt much like our friend chemistry dog. I actually you know a lot of my like text to my friend when I first started the job I was like just just this gift that's that's it. How's work. Chemistry dog. Anyway when I told my friends from Flatiron who were also new developers that I would be working in Ember they were like why Ember. It's so hard to learn the documentation is terrible it's why wouldn't we do Angular. And I was like well first of all it's not up to me. This is I got this job doing Ember so I'm going to learn Ember and that's just how it is. And besides hamsters are really cute. So anyway I started working at simple reach and learning Ember and everything was going great. And I started working on an application that we were migrating from straight up Ruby on Rails to Ember with a Rails API. And I quickly developed a love of testing. Tests are great. Here I am a new developer navigating this massive application with a bunch of moving parts that I have no idea what to do with. But there were a ton of RSpec tests on the Rails side so I could use those to help me figure it out. That was great. It was easy enough for me to write those tests in RSpec for anything I wanted to understand. So on the Rails side tests were solid. However once I started working on the newly developed Ember side I was like, hey guys, so Ember tests. How do we write those? Are there any tests? Are there any Ember tests that are already written? Are those a thing? Not really. I mean we just, you know, had just migrated over. So I didn't know how to write Ember tests. And unlike when I was navigating the Rails side I didn't really have that many examples to look at within the app. And I was very excited when we migrated to Ember's CLI and I noticed that when I generated my models I also got these free little unit tests automatically generated. And I was like, cool. It's just like Rails. Maybe this will help. No, it's not really, it's not really helpful. I know it exists. So yeah, so I started to feel a little bit more like this joke that I, you know, so anyway. I love tests. I love tests. I get really excited about tests and seeing our test coverage increase. Seeing that little number go up is great. And so my co-worker, Nick, who taught me everything I know about Ember, basically, was like, man, you really love tests. How about you learn to test Ember and then teach all of us. This is from like a week ago. So, you know, just so you have some context. So I was like, you know, what the hell? I love tests. YOLO. Just like this little pug. So I started looking at the Ember and the Ember CLI documentation and just like Googling the hell out of anything I could find on the topic of testing in Ember. There's a lot out there. But I found very little that was approachable for someone like me who hasn't been programming very long, let alone in Ember. I found a lot of documentation on testing specifically, like kind of confusing. I would write tests that didn't even run, let alone pass or fail, even though I felt like I was following the guides. I wrote tests that shouldn't have passed, but did. I was pretty confused by it all. Just like these guys. So you seasoned Ember developers out there always asking, what can we do to make this more approachable for beginners? I mean, you're doing a pretty good job for the most part. I feel pretty welcomed and, you know, everyone's really friendly. But if you're trying to learn about testing specifically, like I am, sometimes it can feel a little more like an afterthought. So my thoughts are, first of all, the talk yesterday on testing was amazing, and I can't wait to go home and watch it 10 times. So thank you to, I think, I hope I'm saying your name right, Toran. Yeah, so that was great. And thank you for that. Eventually, I would love to be able to contribute to the community and I would love to help make documentation more approachable for beginners the way that I would like it. I would love to create useful tutorials for others, all that great stuff, but I have to learn it first. So it would be great if there were more beginner friendly resources on testing, similar to, like the to-do list tutorial and the Ember guys, but with like testing included or something, maybe some like best practices somewhere. So I know what I'm doing, maybe. In the meantime, I'm going to keep digging and googling as much as I can. And hopefully next year, I'm going to come back to EmberConf, feeling a little more like graduation dog. So that's the end. If you have any sweet links to any resources on testing in Ember, please don't hesitate to tweet them at me. Also, Simple Reach is hiring. If you find any of these cool people in the picture and you want to talk to us about Simple Reach, we totally want to talk to you. So come up and say hi. Thank you. My name is Michael. I work for Moveable Inc. We are building an email marketing platform using Ember. We're hiring. Come join us. So today, I want to talk to you. Well, first I want to show you. This is a project called Cross Filter. It was built by Mike Bostock, the author of D3. It's a really cool project. What it's actually doing is it's pulling down millions of data points in a CSV into the browser and you can actually filter them in real time and cut different dimensions. It's pretty neat. The only downside of this is that this browser tab right here is using 500 megs of memory. So if your laptop doesn't have a lot of memory, it's probably not going to work. And also when you load the page, there is a pause as the entire browser is trying to filter and sort all of these elements when it starts. So that's kind of the backstory of what I'm going to talk about. But first I want to talk about a little bit more, a simpler example. Most of you probably know what Fibonacci is. It's a sequence 1, 1, 2, 3, 5, 8, 13. Every number is the sum of the two previous numbers. If you had a first programming interview question, it might have included this. So this app right here just takes. It asks for a sequence number and then will tell you the Fibonacci number at that value. So this is the code right here. It's extremely simple. Here's our application controller. We're just binding this input to sequence number and then we're going to compute the value and then just spit it back out in the result. So we import our Fibonacci from Fibonacci and then we call Fibonacci.fib. So here is our Fib. You can implement Fibonacci two different ways or at least two ways. One is recursive. The other is iterative. I chose recursive. It's a little bit easier. Here are the first two base cases, zero and one. And then we call Fib A minus one plus Fib A minus two. Pretty simple, right? So then you've got this here and you can hit up and you can see that it's calculating the Fibonacci number. But wait a second. This is not JavaScript. This is actually C++. So we have injected some C++ into our app and actually imported it via ES6 requires. So so how do you do this? You probably shouldn't. But if you did, how would you do it? So there's this pretty cool project called M-scripten. M-scripten is actually going to take C or C++ code, convert it into LLVM byte code and then eventually convert that into JavaScript using a very cool project called asm.js. Asm is actually it's fully valid JavaScript. It's a subset of JavaScript that is a little bit easier for the browser to understand. This actually ties in nicely with what Steph was talking about yesterday. If only we kind of restrict what we're doing in the browser, it's actually much easier to kind of compile that into faster code. So it's actually JavaScript, but it would look more like byte code to you. And so why, assuming that we did want to do this, why would we do it? Things like algorithms. Let's play this. Things like algorithms could be good. You can, people have written all kinds of things in C++ or C and then converted them into JavaScript. Somebody ported Doom into the browser, just a straight port. So there's, it's not quite ready. It'd probably never be ready, but it's not quite ready for use yet. One of the things is that it's actually loading a 400K M-script in runtime for every single file that you do. So this is actually implemented as an Ember CLI add-on. So it actually, so it's actually part of the compile chain. So you just drop a, so I just dropped this Fibonacci.cpp in lib. It picked it up. It automatically figured out that I can require it like this. M-script in includes this nice M-script in bindings where I say, my fib function, we're going to export that as fib. I wrapped that in the ES6 binding so that it can pick it up and then you can call it the C++ function straight from Ember. You're absolutely crazy and want to try it out. You can MPM install it right here. Thanks. So yesterday, my husband and I actually launched this thing called, we called Ember Observer. It's a, I don't know if anybody knows of Ruby Toolbox. Met to categorize and rate Ember add-ons. And so here it is. And so it's our first pass. So the categorization might be a bit rough. And so I'm just gonna talk a little bit about what it is, why we built it and how we built it. To start off, so if you look, you come here, you can see a number of different categories. Components has a number of subcategories. And the goal is that you'd be able to go to one of these categories and compare what's available to you within those type, that type of add-ons. So if I went to autocomplete, I can see all the many different type of heads and autocomplete add-ons available and they each have a score. And the same thing is true. Something that's interesting, if you look at select, there's many different select options for Ember CLI add-ons. And so on the site, there's also a link to where we explain a little bit about why we built this. And so the score is interesting. The, sorry, I can step back. There's two components. So there's the reviews, which I'm calling reviews, they're really kind of evaluations and it asks five questions. Is the source accessible? Cause I found some add-ons that don't have any way to find the source. Is it more than an empty add-on? Is it more than the base-generated Ember CLI add-on? Are there meaningful tests? And I took that to mean if it's any tests beyond the base-generated add-ons, base-generated tests from Ember CLI. Is the read-me filled out? Does it tell you how to use it? And does the add-on have a build? And that's applicable only if there are meaningful tests. And so the score is composed of a point for each yes to those questions. And then a point for a release within the last three months. A point for one commit within the last three months. For more than one commit within the last three months. A point for more than one contributor. I didn't make this bigger. There, now you all can see it. A point for having a download count in the last 30 days that is in the top 10% for all add-ons. And a point for having a GitHub star count in the top 10% of all add-ons. And the total score is out of 10. And so in the course of doing this, I went through every single Ember CLI add-on. And I found some very interesting things. A lot of add-ons. I opened full 52 pull requests to update or fix the repository URL in package.json. So, yeah, if you're an add-on maintainer, fill out your package.json files, please. And if you set the description, it'll show up nicely on an individual add-ons page, which I realized I should show. So let me go to one of my favorite add-ons. I can't spell, but there we go. So there's this nice auto-complete drop-down with all of the add-ons, and also the categories show up there as well. And so if you look on an add-on, you see the description that comes from the package that.json, the score that is calculated from the review and from live GitHub data. And a lot of info from MPM as well. It's similar to Ember add-ons and one of the goals for the recent future will be to collaborate with Ember add-ons. And you can see the review here as well. And let's see. So it pulls data hourly from MPM and GitHub and the reviews in the categorization are manual. And we made it in a month of time. We started on February 1st, not intending for this just because that was the day which I got annoyed and couldn't find an add-on I needed. And it is an Ember app and it is open source. It's under emberobserver slash client on GitHub. And it is of course an Ember app. And so that can be examined there as well. And so in the course of doing this, I actually looked at the contribution graph and so we've done almost 30 commits a day for about a month to the client. And then on top of that, there's the server. So I was surprised at how much work we put in. To finish up, yesterday when I tweeted about this, Matt Beall responded and put it much more eloquently. So what score does your add-on have? That's all I have. So this talk is titled CSS is Hard because I didn't have much time to think of anything more clever than that. But so how many of you are building ambitious applications? Okay, so most of you, that's good. Which is great because Embers helped us build these great ambitious applications. And it's helped us tame what was our spaghetti JavaScript into this beautiful orchestration of components. We're all working together. But we have yet to help you tame the spaghetti monster in CSS land, haven't we? And one of the big problems with CSS is that it's global. So it's very easy to define styles in one place. Maybe you're organizing your styles very effectively, but it's very easy to make a mistake and now all of a sudden a style you've defined somewhere is now leaking elsewhere. And so there's technologies that are on the standards track to help us with this. Things like ShadowDom. And in prior, previous to ShadowDom, there was the idea of style scoped. And there's some other cool things happening on the standards track as well. But those things are still being proposed. There's some polyfills, but those may or may not be usable by you in production. So really what we've learned to do in CSS is to build up a set of conventions. And that's not unlike the things that we've done in JavaScript land, right? We've built up a set of conventions. This is what Ember gives you, a set of conventions to build your JavaScript applications. Well, what about bringing conventions to CSS? And with Ember 2.0, we're componentizing all of the things, right? And one of the things that's gonna shake out, I suspect, and that we've been talking about is that we're going to want to move to a pods-based structure for your application. And what that means is, effectively, in Ember 2.0, you're writing all components, your app slash components folder is gonna get very full, right? And so pods are gonna allow us to have top-level folders for our components, and potentially groupings of components, perhaps, by route. So what can we do? How can Ember help us with our CSS? Let's see if I can pull off a quick demo. So, here we are in a terminal. I'll hide my desktop. Such shame. All right, so, well, so here we are inside of an Ember application, and it just so happens, right before I got up here, I just published a new add-on to MPM, called Ember Component CSS. So I'm going to pretend to install that in here. And so now we've magically got our add-on installed, all right, and then we can open up Sublime, and we can start building our first component inside of our application. So we'll jump to our application HBS file, and we'll get rid of this out and replace it with a handy-dandy My Component. And so, what is this, how are we gonna build this component? Well, we're gonna use pod structure, and effectively, at the simplest level, what that means is we're just going to create a directory called My Component. And inside this, we'll put our template.hbs file, and we'll say hello from My Component. And if I bring up Ember CLI here, oh, I gotta start it. Those fast boot times really come in handy. All right, so here we go, right? This should be nothing controversial, this is Hello World in Ember Land. But we've built this component, and now we wanna style it, right? And so what do we do? Well, what you've probably done is you've opened up this styles directory, and now you've mirrored all of your component structure or your file structure that lives inside of the application directory. Inside of this styles directory, and you're using something like SAS or less, and you're importing and bringing everything around, you've got a nice organized file structure. But in Podsland, we already have these folders, so what should we do? Well, we should be able to just drop in a styles.css file here, right? And so now if I go ahead and define a CSS rule here, I should be able to go use it from inside of my template. Oh, God, things are breaking in the background. Um, should be able to go use it, and hopefully our component will turn blue, right? So, this is very cool, right? But Eric, you say, foo is a very generic name. That's going to leak, and you're gonna have foos and other components. What about add-ons and third party components, yada, yada, yada? Well, my friend, have I got something for you? In the background, our add-on has actually got our back, oh no, and it has gone and added a magical namespaced class for us in our components. And so if we go and look at our usage of foo here inside of our component, you're gonna see here, it's automatically namespaced for us. This is very cool, right? Now, to finish off the demo, the one missing piece is, you're gonna ask, well, I wanna style my component myself, not just style things inside of my component, so how do I do that? Well, I borrowed a little bit of syntax, you can ampersand, and you can do something to this component, and now we are styling, hopefully our component as well. So, this is what I've been hacking on if you have been trying to get my attention or have a conversation with me for the last several hours, this is what I've been doing. So let's see, where did my other window go? So, basically you can try this yourself right now. It's already up on MPM, give it an install, there's probably bugs, it's demo-worthy quality. I had Robert Jackson review it for me, and he said it did not make him wanna vomit, so that was good. So yeah, give it a try, let me know. I think we really have a great story to bring to Ember around conventions and CSS land as well, so please file issues and give me some feedback on it. And yes, I'm planning to support SAS and LAS and all that stuff, everybody's been asking me that. So, give me a shout on Twitter if you have any thoughts. Thanks.