 Thank you guys. Thank you. So our presentation is called the startup. Why ember? It's not a typical ember Presentation like you're used to it's not that much about the code It's more about how we transition to use ember before we didn't use ember and we think it's awesome. So so This is me. I'm Nora. I'm French. So pardon my English my French dish be nice It's my first talk in English. Yeah, so I've joined the company in last October I've been there in show my homework for almost six months and Basically when I joined the company, I didn't know anything about ember I was kind of a senior developer in France but like a full-stack Ruby on Rails developer and when I came to London like it was a whole new word for me like Okay, you can have to stack and that's just in Ruby like ember and Ruby and I just discovered ember But and with the help of Sam and Miguel that is actually in the audience today. So, yeah, that's me So my name is Sam. I'm from Belgium. I joined the company about I think next week. I will be there for one year I was there from the kind of the beginning when we did we did the transition and it was quite a journey So we work for show my homework Just want to give you a small introduction. What's what is show my homework that was showing my homework? It doesn't have to be we save you time so you can focus yours where it matters Set reuse and edit homework in a click provide your students with instant feedback and save time marking with our Autograded quizzes and spelling. So basically what is show my homework? So show my homework what set up by a former teacher and it's basically to help students parent teacher to Set up homework and so just big platform where you can share Everything resources for the school and assign homework submit your assignment a submission. Sorry a sign assess and great. So, yeah So the previous tech before I arrived was a old Ruby stack with Ruby on Wales and jQuery. So really basic Performance issue, but we'll talk about that later So a big question why switch it was a working product It was a good product. There was a pretty much sold product, but there was a big issue in my Experience anyway for a new design. The design was really old really 2009ish and so that was one of the biggest things The scalability we were growing quite fast and I think the previous tech could not really keep up It was getting slow. It was getting hard And obviously we were a startup. So we need to keep up up to date with the latest technologies, which obviously is ember so So why why ember so I samsaid Before the company was just dealing with this code kind of old-fashioned app in Ruby on Wales and There was this performance issue and actually they were digging into how we can switch and what we should actually adopt As a new front end. So they were digging into that and Ruby on because we were using Ruby on rails ember where structure. I think like Ruby on rails am I wrong Miguel because you're you were you were there as a Yes Yeah, yeah Okay, so I'm questioning I'm questioning Miguel because Miguel helps a lot in switching from old-fashioned stack to this new stack and Obviously participating participated in taking the decision to switch to ember So ember is good for scalability as some say we do both the user base in one year performance. That's amazing and Actually easy to maintain because now we have the core in Ruby and we have the front end So it's really too dedicated The API and the front end so really you can have two team or full-stack developer working on that Yeah So we work with Miguel which is who is a Contributor to ember so it's really really help a lot because we really have like the cutting-edge front-end Structure we can ever dream off. So yeah, that is really cool to work with that and Yeah, I'm boss here lie again really good easy deployment. You cannot be as fast at that We just a run a common on slack and no not on slack. That's right. Yes On the deploy and just yeah mind blowing So then was a big question how are we gonna do this from a really old framework, which was not updated in a long time big question rewrite the whole thing from scratch or implement try to implement it in a working website and obviously, I think there was a lot of thought about it to actually do it in the current website and just start gradually implementing it because it was It was a working product. So you cannot just take it offline and start over So there was this kind of transition They were hoping to gradually do it which they said no some people just said no, let's not do it We start from scratch. We just said build a new product use the old API because all the information is there Try to make it in Fairly small amount of time. We only had three months kind of three months to do the first product which we Basically almost finished and then started all the because we still had to Maintain the old API. It was not easy to maintain all the API and the new way to to write new endpoints for for the new ember But eventually after a lot of struggling we did get through it So we started from scratch to a whole new working product with the latest technologies ember We did of course use Mirage and acceptance tests in the beginning Mirage is one of the most awesome tools just to build your application And then just or you just mimic whatever was the old API and then just after a while Just switch over see if it's working with the new with the old API and then at the same time Updating that API without breaking the old the old website who? There was only one expert Miguel and two JavaScript experts all the way in the beginning Which actually one of them is a regular guy who comes here Mario? He was one of our first JavaScript developers there so The question is so what we didn't really point out is like then the switch between the old and new Stack occurred last year May around May And actually the team was really really tiny just three people and they really have to hire But has he may know how you're hiring process is just take really long So how do we grow up to handle such a revamp because actually the the management team gave them Three months to build the walls to revamp everything which was nearly impossible So arriving in September because this is the beginning of the school year The product wasn't really stable really stable actually in the front end, but not in the API So they hire a lot of new people. So now we have a big new team So seven full stack developer to freelance to DevOps to product manager one QA guy Which is really get a really young but really really I just say efficient one designer in the house so if you join you will be in this team and To make it more How do you say efficient on a daily basis now because we are 11 people we have I do say we have Split the the big team into two teams. So you have the core team and the future team So the future team is basically working on the new feature and caught him is just maintaining the whole stack Front-end driver. Maybe when you want to explain that so yeah, we have front-end driven development So that means well we both of us are in the in the feature team So we are building new features and as it was kind of hard Building the existing features because you you already have the back end and it's quite hard to I mean We did do it and in Mirage everything was working But then we switched to a real API which was existing which you cannot just change and it was just a weird way of thinking to first start from an API and then work to Mimic everything in Mirage So now at this point we are working with Mirage so we built the whole feature or The most of the feature especially the endpoints in Mirage and when it's working when it's working How we expected how we wanted to work then we're starting working on the back end Yeah, that's what we do Actually currently it's really hard actually to have two team I mean to kind of developer and really working together front-end back-end and just say you know what back-end just wait Until we really implement that into the front-end and that is a big new thing for us and we are still working on that So now we have two weeks print Basically, it's pretty new for us because we have been growing so fast. So we try to tend to as you say what was too to explain but sometimes Just extend for some reason because we are always I just say overbooked Feature flags so this is a really cool new thing we have implemented lately so Basically, you just release in production as soon as possible You are not waiting like few months before releasing and you just hide that from the teacher student And whatever just for your deaf team So yeah Travis is running on Github. I mean As normal as it should be So As I mentioned we are or we were at least a really small startup we are growing It was not the experience I hope for when I arrived in the sense of we did make a lot of mistakes Just gonna sum up some of the mistakes in the hope you guys if you ever try it or you know work with Ember Keep these points in mind Try to be up-to-date with Ember Jazz Because we had this problem that a certain point as in all frameworks It will update at a point and we were getting behind and then our good friend Miguel had to jump in and do every single Update one by one and then release it and then go up to the next one So now we are trying to maintain it as good as we can we are getting behind again But we are trying to get it get it right Then we had a lot lack of testing Which is actually a bit of a shame because there are such a good testing environments in these days We are using Q unit on the front end, which is really really nice Obviously all the Q unit will be tested by Travis Only when travel Travis passes then we can move on to the next stage or release it We recently started with testing our components as well because before we only tested our Acceptance test which was actually nice because you actually do the whole process as a teacher a student or a parent Which is pretty nice, but we didn't extend it enough There are a lot of things that were just ignored like some tests were Really small and some tests were really big checking if there was a Question mark in a sentence or like really stupid things is something that actually I regret that we didn't start from the beginning Because now I've started rewriting all our tests and it just takes so much time Document everything you do There is we had this problem that I was doing a code review and I was saying to the guys like we already have this whole Component the guy just rewritten a component exactly almost exactly as we had it before it was working We did write it in a proper way that it is reusable for multiple things to use for and The guy was just it's just a waste of time if you don't document your your things new people coming to your company If they go on your github page on your gift on your wiki page They can read all the documentation and that's how it should be when I started there. There was nothing. There was just one deployment command and I Don't even use this this command actually what help below is our code review Process I've really really changed over the past few months so before we were like reviewing each other code but without really being enthusiastic about that and We were basically searching for the small tiny styling issue like just code mistake and gs in but now we have cut climate we have For Ruby Ruby we have Rubik and stuff So in Travis so it's really nice because now when you are reviewing codes you review the logic and the strategy So you can actually detect if someone has just copy duplicating components. So yeah, it's participating in really improving our our code basically The next one is not a mistake. It's actually something really nice Which we have been looking for for a really long time We were we have this platform where you have a lot of options to choose from Creating a homework selecting classes selecting students Selecting dates all of these things which we used select two for which was a Plug-in an ember plug-in which was actually just a rep around jQuery Which was working fine until a certain extent and then if you go if there were some things You just couldn't do and then a really nice guy just said, you know what I'm just gonna write my own native ember Power select and that was it was a bit of a pain to update everything But once it was done it was so nice and it was really cool to have kind of Priority release for us because we were just liking basically Miguel saying, you know what this doesn't work for us He said, you know what just update the latest version of on the poor select and it was live It was really cool Updating Mirage, which we are still doing Mirage is an amazing tool. I recommend to everybody who's gonna make a big product It mimics whatever you want, which is eventually gonna come from your API. So We are still outdated with Mirage, but that's the the next thing next thing on the list So that's one thing we shouldn't really keep up and then we have our internet explorer our best friend of course and Rendering our mobile devices, which is not fun, but we'll have to deal with it Yeah, because as you may know in some school, they are still dealing with IE 6. No, I'm joking but really late version early version sorry of IE and it's just awful awful So yeah, we are hiring. We're always looking for talent developers. This is our amazing team So they are really overbooked. That is why we are just two of us, but just you know what? We are hosting this umber how do you say project nice and it will be really cool because actually the office is really cool They will be really nice food drinks. I guess so and yeah, so if you want to join You are free to come to us So, yeah, that's about it if there are any questions, hopefully not the heart Yeah, I don't know if you can so basically what what happened before The team grew that fast. They were just a few people and the best engineer was kind of the CTO if it makes sense so Our CTO is Michael. He's a genius to be honest He's kind of a DevOps full stack guy But now we have two different team and we have kind of two head of I don't know hide of Engineering like do the head of engineering core team and head of engineering feature team. So, yeah We're basically to answer a question. We don't have a real CD. Oh, no Yes So how dynamic is that so I think Until now it was The API that was driving say we will build in the API and then we'll say to the front and a you know what designer Just do that and copy it in Mirage But now so it was dynamic But maybe not that dynamic because we were not asking as the right question about loading side loading you go loading and stuff So now we are doing that the other way building in Mirage and really adapting And improving our code and an API So basically if the front end guys come to us and say, you know what it doesn't work So can you just can we just see them and we view as a decent response to payload and stuff? So we'll definitely adapt it as we go and as we learn about like yeah page loading and stuff So we try to do that to be really dynamic the the old API the really old one is still in use They did update it but not enough and this is still a work in progress So they are still updating the old API, but in a better way Even though they are still behind on the version of Ruby it is a work in progress and it will be almost the same as That's If you have an existing API it is quite hard, but like we said if you have the opportunity to to Create a new feature which will have new endpoints My advice is just do it in in a in Mirage because sometimes it's just gonna make it easier to write rewrite Change small things and when it's done when you have the proper result you want then try to I don't know What's the back-end framework you're working with? Yeah, but then just try to replicate whatever you're doing in rails because whatever you can do in JavaScript for sure You can do in rails Mm-hmm What Miguel want to talk now Yeah You And I have the feeling that it's really hard actually to switch our mind and say you know what we are the front end We will be drive driving because it's kind of all I mean we are still old-fashioned in a way because we still consider really Developer as back-end developer and this is not true like I'm I'm a Ruby on rails developer And now I'm just doing and on drawing doing JavaScript that that could be funny, right because a Wide ago everybody was like yeah, you know what it's a back-end the most powerful guys and we'll be driving driving Exactly exactly Exactly Yes, exactly to be honest with you We have been working on a feature lately like kind of a book library and I was driving I was the girl from the API driving and I was like really proud of myself But then we have to review the json response so many time We have Lose a lot of time on that and now we are on the new feature which is really cool Sitting planner for for for the classroom, and we are just front-end drive driving and maybe the future will be half the time Of what we spend on the last feature Yeah, exactly exactly You are mocking actually you are mocking in Mirage If you Yeah That what we need more front-end guys Yeah I I from your fix-to-take. Do I adhere? You should be like, work, work, work, work, work. I don't think that's going to be so great to have, perhaps. I mean, I don't know, that would be a waste of API gateway, but it's a bit dodgy in terms of how the interaction is wider right now. But it's been able to just take that one specification out of the mood at every point. It's funny, because last month I was using Slack as an API swagger. Like I was on this feature, I've just lose a lot of time on that. I was just copy-pasting my JSON response and slacking that to Samsung. You have to put that into Mirage. And now, today, this morning, it was the way, the inverse. Like it was, say, you have to do that into your API. And it's mind-blowing. You have no idea how much time we are gaining on that. You mentioned updating, is that updating the version of Ember? Yes, Ember, Ember CLI, which are key points. You really need to keep up, because to upgrade to Ember, you need to follow a few steps. And actually, if you are behind three, four, five versions, you have to do step by step. You cannot just upgrade to the newest version. You have to upgrade step and then again and then again. And for us, it's not just upgrading this one and this one and this one, because it takes a lot of time. It's upgrading this one, releasing it to production, and then go into the next one, which is kind of tricky. I mean, there are some cases that you have to change a lot of things, which is risky. But it's our own fault. Is that easier? Sorry? Is it kind of easier? To me, it feels like the later versions of Ember is easier to upgrade than the latest version. Yeah, I guess. It depends what you're using in your app. There are some things, if there's a new update, we don't touch at all. You have all the steps, do this and this and this, and some steps, we don't have to do anything. But some of the steps we do. I mean, if there is a new version of Ember Power Select, we have to rewrite our whole website, just because we are so intensively using this. You are doing very well. Sometimes things break, but hardly ever it will get to production. So a lot of times, stuff will break and we'll have to fix it. But it's like the transition. You want to upgrade one model, you upgrade it, and then you fix whatever broke, which is not that bad. I mean, sometimes it's a lot of work, and sometimes it's almost nothing. And we didn't talk about Ghost Inspector, which is really, really handy. Do you know Ghost Inspector? We are working on that, like on QA and on production. And we do detect a lot of issues with that. So basically, Ghost Inspector is a tool that goes through your website as a user and takes screenshots and finds things on the page. If something moves, if something isn't there anymore, it will report it to you. Problem we did is we only run it on production, which is already too late. So now we are running it on our QA environment. We just want to keep up. We just want to be on top of the versions, because I mean, I don't know if there is an automatically upgrading system. I don't think so. You have to do it manually, right? No, yes. To be fair, the long 2.4 was the first long-term support release, and that only just landed. Yes. So the idea of a long-term support is that you can safely jump three versions, four versions into the future. And you will sort of know what's in store for you when you make that big jump. There's kind of this guarantee. Yeah. If you could rephrase that question, would you consider taking yourself to the long-term support versions? Yeah, I guess so. The thing is just it's going to be the same than keeping up the date. You just need to know what happened and what's going to change and then do it. I mean, that's, if it's one time a big chunk or four times a small chunk, it's going to be the same in the end. My name's Steve. Yes. I think there's more seats. One more question. We are currently evaluating and using the number at the moment on the flexibility for a new project. So in terms of you guys learning, what were the most tricky things and do you have any advice for me? Honestly, for me, when I started in the company, on my CV, I said, I know Amber. Basically meaning I know Amber. I know what it is. That's it. I did develop some things in Angular before, before that a lot of jQuery and native.js. If you're a good JavaScript developer, I think you will get it pretty fast, the hang of it. Because it's a pretty straightforward framework. Our old application, if I would get the code now for somebody who is pretty confident in Amber, they will for sure know what's going on and how it's working. Because everything has its place. I mean, it is a full framework and everything should work how it should work. If there is a computer property, you know what it's about to do. It's not some name that you define yourself or a function that you define yourself. You can do that as well. But the learning curve was pretty fast, also because we had an experienced Amber contributor working with us side at side. So all I know about Amber, especially the first five, six months, I just learned from seeing Miguel work. And that's the thing. You can actually learn it from seeing somebody else work if you know some JavaScript. For me, my most common mistake, because I didn't know anything about front-end framework, I was just playing with a DOM. So I was asking the guys, hey, how I should grab this element on the DOM and say, yeah, you don't need to actually grab this element from the DOM. And it was quite funny, because I was a jikrary girl. And for me, it was a whole new world. But as Sam said, the learning curve with Amber is pretty cool, because you learn a lot. And maybe because I came from Ruby on Rails, it's helped as well. So yeah. Just for my curiosity, who here is a front-end developer, like mid-level front-end developer, and want to improve front-end Amber developer? It's all seniors, all seniors. So you are all seniors. So the rest of the audience is senior developer, right? No. No? I'm not very big in it. All right, all right. Because we do, I mean, in this company, we do learn a lot. And as I said, I was totally new to Amber, and we have the opportunity to learn. So if you want to have more info. I do think Amber, no. No. That's true. But I do think Amber, especially now at this point, Amber is a really amazing tool. And let's see what Angular 2 is going to do. But I'm still the biggest fan of Amber. I mean, I started working with it, and then I just fell in love with the whole framework. Everything just works, feels so natural for me anyway. And as Jamie say, Polyconf, I think it's really suitable for big app like this. Like really structured, I don't know. So it makes you feel really confident in what you are building to have all this framework. And yeah, it's really, really cool. So. You were not missing the Angular 2? No. No, not at all. I mean, it was the thing that I was used to, but then again, this, for me, it just works so natural. I mean, I guess it's because I've been using Amber so intensively the past year that I mean, I don't do anything else anymore. Oh, sorry, I thought they were talking about NG from Angular. It feels like there's more promise than reality, isn't it? No, it's getting closer to that. On that, I can say that the team at British Gas have 16 Amber applications spread across the British Gas experience. And they are in a position where they want to invest heavily in engines just as soon as they're ready. So they're talking to Dan Gephart. Amber engines, for those who don't know, is available as an add-on that works with Emma Canary at the moment. So if you did want to jump upon it early, you could. But I think for a lot of teams, I think you need the kind of structure that British Gas have, where they have a plethora of different applications that share things in common on it. It needs to be mounted in a common code base. But I think the promise is really cool. And it should, I think, end of the summer. Like, you probably have it at a point where it's useful for most applications. As I know, we are considering it early on the way until embers can be loaded, sorry, engines can be loaded as in company. Because if they can, if you can't load as in company, everything is in the same bundle, there is not that, the advantage is not that complicated. No. I think with that, how about we can? Let's go. Thank you.