 All right, trying not to trip on my way over here. Thank you so much for having me here, and I'm so excited to be in London. I just happened to be visiting from San Francisco, so this is a really nice experience to have, and I'm really happy to see so many smiling faces in the crowd. Today, I'd like to share with you our story of redesigning and rewriting our application in Ember. But first, let me introduce myself. My name is Jade Applegate. Here's a picture of me recently making a friend with an owl in an owl cafe in Tokyo. And I only held the owls that had gone to the bathroom on the other people. So if they said, oh my god, on me, I would say, oh, which owl? And then I would go get that one and hold it. But if you want to find me online, it's at jadeapplegate on Twitter, GitHub, things like that. So I work for Fastly, which is a real-time content delivery network. And I'm a software engineer on the UX team there. And Fastly is a global CDN. We have caches all around the world. And although this is pretty small, I can let you know that we have caches either planned or in place on almost every continent. And this translates into many customers and many users. So as I mentioned, I'm on the UX team. And I work on the customer-facing UI at Fastly. And this is one UI for all customers where they can do basic things like manage their account or user provisioning, billing, real-time analytics and stats on the dashboard. But the complication in what I want to talk to you about building is we put a lot of functionality in the hands of our users through advanced configurations for managing their cash services. So that's a little bit of what we'll talk about. Oops, sorry, I forgot I had these. So since this is Project Night, I'd like to share with you the project that my team and I have been working on for the past year. And this is a quick overview, so you know what to expect that we'll talk about. We'll talk about the rationale for why we chose to migrate to Ember and the approach that we took. And the results of our work and the many, many lessons we learned along the way. And then finally, I'll discuss what's next for our project and team. So it's just a little highlights of what we'll do. So let's get started. You may be wondering, why would we do a rewrite? And generally, those are kind of bad, maybe a bad idea or a lot of sunk costs. So what were we thinking when we decided to do this? Originally, the project was only a tech rewrite. It was a port from a deprecated backbone coffee script app to an Ember app. And of course, like any good software project, the scope changed. And the rewrite led to changes in design and that led to architecture changes. So what started off as a very small project eventually turned into a very big undertaking. But regardless of the scope of the project, there were a lot of things that were not possible with our existing legacy app. So it was really hard to make changes quickly in the application. And we lacked test coverage. So we didn't have a lot of confidence in any of the changes that we did make. And there was lack of code consistency, for example. There are five different ways to implement a modal. So if you're going to look for one way, you might find other ways of doing something so there wasn't any consistency. So deprecated app, hard to quickly make changes, no code coverage. And we lacked a lot of rich features or interactions in the app. And a lot of the design decisions were made on things like feelings, rather than hard UX evidence. So we also had a lack of modern architecture. Our app was deprecated, so we really wanted to use something shiny and fancy and new. So we thought about using Ember or React. We lacked rich interactions. And then we also had no real ownership of the application. Like many startups, it starts out with just anybody who knows little JavaScript adds to the app. There's no real front end team or band of people that really want to work on something. It's just people casually adding features here and there. So that was something that we suffered from as well. And we had a lot of dependencies on other systems. An example of this is that our deployment process took around an hour, which is rough. And it was a very, very manual process. It involved a lot of messing around with Chef and Jenkins builds and a lot of things that you really want to automate and get out of the way. So we wanted to make sure, regardless of what we changed or did, that we improved all these things in the process. And an important point I want to make here is that all of those problems that I mentioned can be fixed without changing to another framework. You can change all those things and fix them without Ember. But we wanted to add in a few additional things like Ember CLI was something that was really important to us. And we already had some in-house knowledge of Ember. So we thought we might take advantage of that. And we didn't even dev environment to get things up and running. So we didn't need to worry about the dependencies and other systems that we had before. So it was really helpful for new team members because they could get up and running on day one. And it also helped because we had brought in some consultants to work with us on the project. And they were able to easily just proxy to a remote server and get up and going, which is nice. So with all of those things in mind, we decided to take a more modern approach. And we decided that this rewrite was best for us rather than a resurrection of our current app. And we decided to use Ember over other frameworks. And so we began our rewrite. So can you, so pure rewrite or refactor at all? Great question. So the question was, was it just a rewrite or was it also a refactor? At first it was just a port of features, but since we were using new ways of doing things, the code didn't stay the same. We tried to, and I'll get to this in a little bit, but we tried to reuse a lot of code so that we didn't have to repeat ourselves in a lot of places. So it was not only just a port of the existing functionality, but doing it in a better way. But old code survived or now? No. Not in. I think there might be like a little bit of legacy CSS hanging around, but for the most part, no. So the first step in doing this was to learn Ember since we only had one person on our team that was really familiar with Ember at all and it changes really fast. So we wanted to get up to speed very quickly. We did that really by going through docs and online tutorials and in-person workshops that we attended in San Francisco and as I mentioned, we had in-house consultants that came in and worked with us to get us up to speed. So in about mid-2015, we got started with porting over what we considered the easy sections of our app, which were the account and billing sections. We didn't really have a sense of pod structure or how to best use components at this time and we really didn't have a strong understanding of Ember data at all. So because of that, I would say these sections still need a little bit of a refactor. Since they're the first pieces that we touched, they work but they're not elegant solutions, but we chose them to start with because they're the most separate parts of our app and they didn't share models and they had really simple interactions. So that's where we kind of started out. Another part of our more modern approach was a focus on testing and the importance of test coverage. So we used Ember QUnit and Mirage to get this done and having every feature tested helped us have that confidence in our code that we didn't have before. As I mentioned, we had zero tests in code base that had survived for four years. So it was really important for us to have a focus on code coverage and a confidence in our code and we developed a lot of custom test helpers to help us more quickly write tests and the confidence that it gave us in writing tests was very beneficial for us as we're kind of learning Ember and getting up to speed and it was a really big upgrade from our old app. And another piece that we used quite frequently was components and if you've been in Ember at all, you know that it's all about components and I'd like to think of our mantra as always be componentizing rather than always be closing. So I'll show you later how components helped us develop features more quickly but it was something that was really important to us as we moved forward. Another thing that came in handy was modern tooling and choosing modern tools in Ember really helps you make good tooling choices generally. So doing things like adopting code style preferences using SWAP or a JS hint led to us developing more specific editor tooling like Adam packages so that we had a really well configured set of tools that we were using and which ultimately just helped us develop more quickly. A big feature of using Ember was the community around it and it's really, really a good idea to rely on these community solutions when you can rather than building something in-house and I know that something that a lot of startups can fall into is only building things in-house because they think that they themselves can only build the best version of some feature that they need but we were able to really rely on community solutions which helped us to move forward and also stay current in Ember land. The more that you do that, the more that you leverage the community and everything moves so quickly and people are developing all the time so it's a really good idea to look into what people are building for other people to use and it's also important to note that every team and every app has to find their own pace and as we all know Ember moves really, really, really fast and not everyone has to or has the ability to keep up with that rapid development so just make sure that you kind of pick your upgrade schedule based on what your team needs and what your app needs and don't feel too bad if you feel like you're falling behind and you're not on the latest version. So as I mentioned, we relied on many, many community solutions and we're currently using things like Docker at Swab, Ember CLI Mirage, Ember Feature Flags, IATN, Ember Validations and SVG for everybody. I'm sure there are others that I forgot but those were the big ones that came to mind and I'd like to point out that there are some other libraries that we're not using yet but we'd like to be so as we're working on this we're kind of building them in and incorporating them and those are things like Ember Power Select, Ember Concurrency and many others that we kind of find out about or learn about along the way. So now that you know kind of the approach that we took let's look at the results of the rewrite and what happened. And we, you know, this rewrite was hard but Ember made it a lot easier for us and it allowed us to write the ambitious web applications that they promised and I'd like to share a couple pieces of that functionality and code with you guys. So in general we were able to develop more rapidly and have rich interactions, write reusable components and rely on tested reliable code which is really important to us. So let's look at a few examples of how the conventions that Ember comes with helped us in our migration. This code here, which is probably very small for you to see, was code from our modal component and it's used throughout our application to manage the state and functionality of our modals and it's not super impressive on its own but when you think about this just handful of lines of code being reused over and over in our application it's a good example of components and how far things have come for us and let me show you a gif of one of our modals in action and I'll show you that in a moment. So in our app there's a configure section and that's where users can manage things like headers and responses, health checks, gzip and other things related to their caching strategy and things like that. And in this example we were able to use one modal component for attaching a condition and you can see that option next to my cursor right here. We were able to then extend the conditions functionality in the modals across the app with just three other components which was very nice. These were called add condition, remove condition and edit condition and although this is small it's kind of indicated here with the arrows and we were able to develop quite rapidly and test things very easily because we had these predictable patterns in place and if we made a change to one we were able to have those changes propagate easily to the rest of the app. So this is the gif that I talked about. It's a gif of the add-on functionality and since you can add a condition in every section of the configuration in the app it's nice that we only had to rely on this one modal component and one add condition component to do this in many places across the app. This is an example from our disclosure component which hides and shows particular parts of the app and since it's a reusable component we use it in multiple places just like the other things and it's used mostly to hide and show advanced settings in the application depending on the type of user that you are. This is that disclosure component and action here. So we also use it to display inline tips for users so that we don't have to have so much text on the page. So besides components and reusable components in particular we were using Ember IATN and we were able to set ourselves up really well for internationalization. This is an example from our translations file and in particular it's the errors hash and it shows the interpolation of the specific errors that would take place and we focused as we were adding functionality on adding translations in English as we worked on things so that when the time came to internationalize the app we had everything in place and in terms of the foundation. So it didn't matter whether we were going to go to Japanese or Spanish next we had everything in place to make that decision and make it much easier on ourselves in the future. And since Ember development made things so much easier on us we were able to focus on those sort of feature rich interactions that were lacking in our old application and we went through a user experience research and testing phase and one of the things that it surfaced was that we should be teaching users terminology related to caching and security and things that have a direct correlation with a CDN. So an example of this is our TLS form which you can see here and we worked with the Fastly security team in order to come up with the best practices that we should have in the application. So an example of this is that if someone wants to not verify our certificate when they set that setting easily surfaces a warning so that they know right then and there that this is not a best practice in terms of security. So it was a nice way to kind of leverage knowledge outside of our own user experience domain and give users the best experience that would be possible. So how do we measure a successful rewrite? One of the things I'd love to be able to tell you right now was that we had metrics on the old app and we have metrics on the new app and one was better than the other and everything was great. But unfortunately since it was such a deprecated application none of those measurements were really even in place but we did improve in some key places which were measurable specifically around deployment. I mentioned that it took around an hour and sometimes even two if something went wrong. So the process now takes about one minute or less and it's one command and most of that time is really related to PCI tasks in terms of protected data. So it's a really fast process and it's something that we really improved throughout the process and it was an important thing for us to fix even though we had many things on our plate. So we used varnish, Ember, Google Cloud Storage and Fastly to deploy and now there are no manual chef bills, no data bag updates, it's just one command and helps us release code on a really reliable scale and reliable timeframe. Another metric I'd like to share and another major improvement to our code is our test coverage. So this is a graph of lines of code in our app compared to lines of code in tests. So if you just kind of break it down the app directory and the test directory to compare those. I was able to write a script to do this comparison and this is the result of that script week by week as we worked on it. As you can see, this is a dramatic improvement because it's not zero and also because we have at least a one to one ratio of tests to code at any time. So metrics aside, what else did we learn in this migration process? So here are a few highlights that I'd like to share. It's a really bad idea to ignore deprecation warnings or let your version stagnate or not upgrade to the latest version. And we learned that it's best to pay down tech debt as we went working on a mix of kind of feature, infrastructure and tech debt stories rather than just kind of waiting until the very end and saying, well, we'll get to that later. We'll get to that later. And this meant that keeping up with the latest version of Ember was more manageable and our app was more stable. We also learned to be selective with external libraries. I know I talked before about how great it is to rely on community solutions, but you really want to investigate those community solutions before you just throw it in your code and start using it. You probably want to evaluate how fully featured are they? What features do you need now and what features will you need that library to support in the future? As well as how well maintained is it and how commonly used is the library. And also you want to ask yourself, is this the community standard for Ember? And maybe go with that one rather than just the first one that you search for. We also focused on test coverage from the first day rather than something that we would get to later. So every time we submitted a pull request for a feature it needed to have subsequent tests backing that feature up. And that was because we knew that it was not something that we ever were going to catch up on or do later because you just know you never will. There's always gonna be something else. Testing was a really important focus for us as we wrote the app and it was pretty easy to do with the combination of out of the box configurations the custom test helpers that we wrote. Those made it a much easier time writing test so it wasn't such a chore every single time. Components, so components make things really easy to build upon later and you need to think ahead and know that you or someone like you will be adding to the app in the future. And I don't want to go too far into like evangelism for components but it was incredibly helpful as we developed our application and it made working with our design team a lot easier because we could kind of capitalize on existing infrastructure as we prototyped features. We also learned that it was really important to internationalize as we went and it saved us a lot of work later on. One of my least favorite things to do in the app is to go back and internationalize code that other people have written. It just seems like such a chore and we do have plans to internationalize the text in our app because we have users all over the world so now that we have that in place it'll make it a lot easier and like with tests and components you'll thank yourself later for kind of putting this foundation in place. So what happens now? We're continuing to work on features and bugs and design updates and also focus on how to maintain an app while we're adding new features which is a new and exciting phase for our team. We're also working on a responsive strategy and working in additional support for different devices but we're basing that on user research rather than just gut feelings on what we think people are using and we also want to make sure that we understand the types of features that people will be accessing from what type of device. So are they going on their mobile phone to make a payment on a bill or make a configuration change or just to see data and analytics? Are they using a giant dashboard and screen for things in their office to display statistics? So we want to know that sort of information upfront rather than just guessing so that we can really provide the experience that the users want. We also need to think about browser support. So a variety of our users are on Chrome but we want to support most browsers including IE10 and because some of our customers are from enterprise software we need to support a wide range of those browsers in order to kind of have a seamless experience for everybody. So right now in terms of releases we're in a private beta we have about 25 customers using our app day in and day out and they're feeding us support tickets and bug tickets and telling us things they like and do not like, things they'd like to see. So with that information we'll go to a general availability later in the year and we're hoping that by going through the beta experience with a small set of customers it will help us improve the overall experience for everybody. And then finally our plan is to open source the entire project so that we have a good example of a moderate ember application and so that customers can then take and fork that project and build their own customizations based on their own needs. So it's been really fun to share with you tonight just a little bit about what we've been doing for the last year and I hope that some of this work may be resonated with you as you're working on your own projects and thanks to Zapnido and to Jamie for having me here and of course I'm happy to answer any questions at this time. Question? So when did the rewrite start? When did the rewrite start? Yeah. We started probably seriously about a year ago. So did you see the rewrite? We did. One of the reasons we didn't go with it was that one of the team members as I mentioned already had some working knowledge of ember and we wanted to capitalize on that but it is something that we considered and I know it's kind of a dichotomy in the front end world to either use ever or react or whatever else. Okay, so the right choice is somebody was in the team who knew things like this. I mean there was not a person on the team that knew React so naturally we kind of gravitated towards what we knew. Yeah, the judge like people in front of technology, people more important than technology and other. Thank you. And how many people on team? We started out with two about a year ago. Now we're at seven. So now that it's a bit more complex, how have you found the onboarding in the sequence there? It's a lot easier than it used to be. If you think about how complex the deployment process was like multiply that by like the whole dev environment to get set up, it was really challenging to get up and running when I started but now that we're using ember and we aren't relying on a dev environment at all, people are able to commit code on their first day. So it's been really nice and since we're relying on things like community standards, they may already be familiar with the libraries that we're using. So again, they can just kind of jump in with some familiarity and we're not kind of building things from scratch where we don't need to be. And is it, sorry to monopolize the question, when you've brought new people into the team, have they all been people who have already had a working knowledge of ember or have some of them in generalistic to be somehow scripted? Mostly the second. It's really hard to find ember developers. Yeah. Our latest hires have been people that had a Rails background and some knowledge of ember or a strong JavaScript background but not a lot of knowledge of ember but were kind of open to letting people learn as they go as we were when I first started and knew nothing about ember. So it's been a varying level of skills but everybody's really focused on learning, getting up to speed and getting in tune with the community. So it's been kind of a nice experience. Which things did you sort of come up against where the ember's opinion was most wrong or where you most had to fight against ember? We most had to fight against ember. So I would say the most embery problems we've had are with ember data. We've had a lot of, you know, we're trying to move this project forward. We're also constantly trying to stay on top of the latest versions and the latest embery ways to do things. So that can be a little overwhelming, I think. I'm trying to think. There was kind of a move from getting things out of components and into services that kind of caught us right at the time that we had just kind of finished getting everything into components. So we rewrote all that and started to use services because we knew that it was only going to benefit us in the future but at the same time it felt really bad that we had just finished something and now we had to completely redo it. So that's never fun. Yeah, that churn is something that people felt around 1.0 days. And it has happened now. And I think it's a general message for the community of the fact that Yehuda and the others are expressly saying that controllers aren't going to disappear just yet if you're using them. It's a bit like the web itself. It's like the old patterns and the new patterns can coexist. You don't have to rewrite everything as soon as it happens. But it does depend upon patterns stabilizing as you go. But we're trying. The idea is to make sure the old patterns aren't whipped down from underneath and they should still work and still be as good as they were when you initially used them. Other questions? You mentioned open sourcing hallway. Yeah. It's somehow your core application in a sense or not? It's not the core application of how our caching works. It's the core application of our user experience. Right. We've had this in mind as we started the rewrite to release it as an open source example because we see a lot of value of that in the community. Of course, our security team are culling through it and making sure that everything is fine and we're not releasing any secret sauce. But I don't think we are. But it's been important to us to be an example in the community of a large company or however whatever size you consider of a company that's using Ember for their day-to-day work. And it's been nice to... I think there's a site like Made by Ember where you can go and see other companies that are using Ember for their things. So it's been important to us. And we're also at the same time releasing this accompanying style guide that we use as a living style guide as we worked on it. So hopefully that will be helpful to other people in the community. What are you going to do with licensing? What are we going to do with licensing? Can you be more specific? Do you have a particular choice of license? Oh. Again, the security team is just now getting to looking through it and deciding that decision doesn't come from me. But I couldn't tell you right now which one they were going to use. Thank you again. Yeah, thank you.