 Thank you very much. Ember has been a brilliant find that we've had for British Gas. It's helped us nowhere to actually deliver what British Gas has been trying to do for years, which has actually helped the customer really. I know it's a bit of a corporate spily type thing, but that's what we've always purported to do. It's also quite an interesting application that was actually a framework that we've really found to speed our development process that we've been hampered with for years and years. So, who are we? We are the core tech team for British Gas. It's called Web Transformation. That's what we do. We do British Gas Residential Energy, so it's gas electricity. We also do services. There's a BGB channel as well, and we also do a white label, Saint Bruce Energy. We've got 300-plus static content pages. It's running out of CQ 5.4, if anyone knows it. It's a Java stack running on Sling and JCR repository. We've got 60-plus user journeys on the website. Now, a user journey for the business side is a single-page contact form that will be classified as a user journey for the business. We have 3.3 million registered customers of which 80% are active. They come back to do your meter reads. You do your payments. So, we've had 20,000 meter reads a day, 6,000 payments a day, around, and about 100,000 log-ins a day. Now, you can do all sorts of stuff with your OAM account, and 140,000 visits, so like static content pages, help and advice, how to put loft conversion, not loft conversion, loft insulation, that type of stuff. So, there's a lot of help and advice, that type of stuff. It's a big site. A lot of people use it. In our old development process, we used to use a Java stack. In 2014, right at the beginning of the year, a couple of us decided to actually start looking at what our current technology stack is. We've got an old Java stack that's been developed for five, six years. On CQ5.4, again, 5.4. Now, if you look at CQ5.4 Adobe product, it's actually running at 6.0 at the moment. We've not upgraded that for the last eight years. 5.4 has now actually run out. It's not supported by Adobe. So, we thought, it's time to actually spruce up the website. Let's have a look at the current technology. We've built everything in Sling. We've put all of our functional journeys in Sling, running on CQ. It's been a total nightmare to maintain. It's slow, but product isn't slow. It's our development process is slow, and we are very, very traditionally conservative. So, for change and risk, we are way down there. We want no risk whatsoever for any of this type of stuff. So, what was the actual challenge? That challenge was to actually move our people, our development process into the new age, into client side, into APIs. And to actually deliver faster, because customers don't hang around. Developers don't hang around. The actual technology doesn't hang around. It keeps moving forward. Because of our conservative approach, we didn't actually upgrade CQ at all. We didn't even look at upgrading. It was too much of a problem to actually look at that. It's a project. £2 million is not going to do that. We'll just leave it on 5.4. Don't want the risk. We're going to invest our bosses that we need to go forward. APIs, client side. Get the customer to run the browser. Let the browser take the load. Move it off our servers. Reduce the server stack. Save his money. So, all these type of things that we've actually looking at, for CQ, that we were doing in CQ, we're now scrapping. We're putting a thin layer of APIs on top of that. Jason, it's REST. And we started that journey last year in October. It took us about a year, a year and a half to actually convince anyone in our business to actually take this up. Luckily, my boss actually listened to me and actually went forward. Not that I'm saying it's my idea. Bye now. So, CQ 5.4 is running on JavaJSP's on Sling. We've actually got an older stack on there as well, running in Spring. Spring 2, I believe it is. So, you know, that's how conservative we are. Stagnant. Over 2 million lines of code. It's easier to cut and paste a chunk of code than it is to actually write something that's actually going to run on a class that has already existed. It's a pain in the ass to maintain. Let's leave the CMS for what CMS is at CMS. Content management, that's what it's going to be. Functional pages, Ember, APIs. A bit of lipstick on that pig that we have. It's an API layer. It's using Apache CXF. We're using OAuth to actually do the authentication authorization. Sorry, authentication authorization. We're building a caching layer on the ETHAT, running on Macroota. Macroota and Mencash. So, we're looking at new technologies that are out there now that are going to help us to actually deliver the challenges that API that the client-side framework gives us. We're going to move off CQ54. We're going to upgrade to AM6, the latest version of CQ. Let the CMS be a CMS. That's what it's going to be. Rich client, API-based technology, JSON. We're even taking on JSON structures for the responses to make sure that it's actually readable and actually usable and easy to transfer. And it's for our developers to make it more interesting. Quick to turn around. See the results. Ask for actually what the business want and we actually deliver it. It's taken us about two weeks, three weeks to actually deliver a journey now. Previously, if you had a journey that was delivered within six months, we were all happy. Obviously a million pounds, but that's a different kettle of fish. So that's the end of our architecture bit. I'll go and hand over to a developer now. Why we chose EMBA and not Angular? I'm Deepan. I'm the lead front-end solutions architect working for the digital team. So my first job in this project was the most enviable of all is to choose a framework for us to use. I think going back to what Andy was saying earlier is like BG previously we had a really dreadful developer culture. As in there was no real developer culture. So we had a stack that was based on Java. There was no real motivation sitting around in the developers. There was a lack of communication between the developers and the actual guys who are the business. So it didn't that any culture was non-existent basically. So part of a job as mentioned in the previous slide was to make sure you can choose all the right tools, you can choose all the frameworks but then if you don't have a happy group of developers developing for you then you're not going to make much progress with it. So when we decided to move to the new architecture which is basically a rich client architecture backed up by RESTful APIs obviously the first question that comes into our mind is to choose the right framework for you. 14 is probably a good time to be involved in the framework was because you probably have a framework coming out every night these days. So dipping our feet into the framework was it was a very interesting face as we sat down to choose what framework we would use for British Gas. We did an objective evaluation of the three most popular options Backbone, Angular and Ember. Backbone we already had some experience because although BG was super conservative we somehow managed to snake in a few backbone apps in there without the guys knowing that it was backbone but that's alright. So we did have some experience on what backbone was and what its positives were, what its limitations were and things like that. Angular and Ember were on a completely different boat because it's the first real time we wanted we were evaluating this framework for actual protection use. We did take opinions we looked at the usual parameters made sure it was a proper objective evaluation as opposed to being swayed away by things like popularity things like that. But what we did find is that although the process can be quite complicated in terms of which framework you choose selecting the right framework is actually made easy when you know what you want the framework to do because if you approach selecting one of these frameworks and trying to see what each of these frameworks offer and then try to make your mind up on which one to use you're probably going to find it a tough task. But then if you have a clear idea of what you want the framework to do for you in the short term what do you want to do for you in the long term then it makes that task slightly more easier. One of the things that influenced the decision was the mistakes we or the lessons really we learned from the past. What we introduced on the Java stack was really a very a custom framework is what we introduced on the Java stack. Now the problem with that framework was that it had it left a lot of decisions for the developers to make. So lots of trivial decisions here and there were made by developers the decisions made were not consistent basically the framework left a lot for interpretation basically and what eventually happened over a period of 2-3 years is that we found ourselves with a code base and design that was highly fragmented because the framework itself did not define how something should be done people said one developer thought ok maybe this is the right way of doing it let's do it like that, another person same problem different solution and then eventually what happens is you end up with a design an architecture that's really fragmented you end up with obviously a fragmented code base we strongly believe that the framework a team uses highly influences the culture within the team now this was something we still firmly believe because I think if a framework is promoting best practices if a framework is promoting good principles then you start to use those principles outside of your use of the framework so if your framework is promoting convention, if your framework is promoting consistency so then you get to think along those angles in whatever thing you do it's not just when you're building an app using that framework it is when you make the decisions for the team then you start thinking about those best practices those principles that the framework is actually helping you to do with so in an area of constant churn embers stability without stagnation approach really stood out for us now I think stability without stagnation is a brilliant principle that Ember adopts it's basically the ability to say that the framework is not going to stagnate it's not like you're not going to be able to use any of the new features that come with the browser runtime so you're going to be able to get to use those new features but you're not going to have to change your code base every time or do a drastic rewrite of your code base every time you want to use a new feature so stability without stagnation the roadmap that Ember had sees that Ember implemented for making changes the community around it now all these things were what eventually made us choose Ember over Angular in that particular framework work really so why we chose Ember conventions baked into a solid MVVM model ignore convention and consistency advantages at your own peril now this is something we learnt the hard way with our previous stack as in it is always easy to take things like consistency conventions and all this and say alright you know what we do this pull requests so the developers can review whether people are naming things the right way we could do all that and then you find over a period of time that is actually not true because you would rather be spending your time doing proper development of your apps rather than bothering about what a particular controller is called what a root is called so conventions baked into a solid MVVM model one of the best things we liked about Ember stability without stagnation again I think what we have seen in the recent months has further reinforced a belief in that principle especially around on the Ember conf this year when they announced Glimmer which is quite a radical change to the Ember rendering model but then it works on the 1.x apps so you don't actually have to do anything to update your app to work with Glimmer so now those are the kind of things where we find Ember that always challenging itself always wanting to improve but also taking care of the developers who have massive apps built on the framework so I'm always having that developer taking care of its developers basically HTML boss again when we had handlebars originally handlebars I think I do like Ember but I didn't really like handlebars when I started with it I found it I found it too restrictive but I was fine with that but I couldn't live with bind ATTR and all those things they did not seem they did not seem natural to use it always felt like you were having code in your templates basically just so that the framework can do certain things so they did put us off initially but then came HTML bars where you don't have to do it especially with 1.11 rid of your bind ATTR tags if you have any so again introduced without radical changes on the templates always backward compatible easy to upgrade you can upgrade incrementally as opposed to being scared of a green field full-fledged rewrite coming in five months six months whatever so as a risky business as a risk cover business I think these were things that that really helped us convince our bosses whatever Andy was saying seriously I'm sure a lot of British gas is still highly conservative and they would say you know what are you using this technology do you have to rewrite it next month well no because it allows the string to change incrementally write balance of capability sensible opinions defaults based on best practices I think a lot of people find or feel that having a strong for a framework to have a strong opinion is a wrong thing but actually we feel the other way I think it is always good a framework has a sensible set of defaults so which basically means that whatever you're trying to do with the framework you always have a starting point as opposed to you having to try and figure out what the starting point for is and Ember is really good in that regard it always has a default way to help you with that starting point and then if you want to customize it or change that behavior it gives you the flexibility to do it so there's nothing wrong with having strong opinions as long as they're based on best practices write balance of capability and sensible opinions which means Ember would probably make a good politician reactive programming model well reactive programming model with computed properties and observers obviously Ember object it uses the observable mixing and it provides you computed properties and observes out of the box which is really good if you're building reactive applications it helps you to get away from things like monitoring the change event of something and then trying to do something once that event is triggered it helps you to have a reactive implementation and really build reactive apps very easily using the concept of computed properties Ember CLI Ember data obvious reasons but I should still say Ember CLI is really a game changer for Ember I think the features you get with Ember CLI obviously it looks like a version is released every week so I don't think Stephen Penner ever sleeps but I think the kind of evolution the rapid evolution and the way they listen to the community the users of Ember CLI is brilliant clear roadmap, outstanding community I think we looked at the process of how Ember actually goes about change to its features so whether the reason one was support for IE8 and IE9 which is currently something that Yehuda started recently to say whether should Ember support drop support for IE8 and IE9 really good approach to drop push it to the community and find out what the community thinks about it and then see what is the best way for the framework to evolve instead of just saying this version is just going to drop support for IE9 let's listen to the users, let's listen to the developers and then figure out what the best way of doing it is clear roadmap outstanding community no questions about that what we've done with Ember so far we made seriously good progress in the 6 months we've been using Ember traditionally our applications we usually try to make our customers life as hard as possible but I think with the new transformation process we've re-evaluated those processes, we have a shiny new framework that allows us to realise the dreams so we built three apps in the course of four months one of those apps is actually a better better apps which is the ability for a customer to get a code for an energy product and buy the product all in the same app built using Ember since we released that app we've seen a 25% increase in code to sale conversion for our energy products which is good news, keeps the bosses happy we've seen an 80% conversion in our homo conversion rates well homo retention has just gone up by 100% I think previously customers were trying we were trying to retain them but just customers did not know how to retain themselves so we made it absolutely clear in the new world that the UX process the frameworks, they all go hand in hand and we can actually deliver a better experience for our customers so sleek a quicker and reactive web applications for our customers which is what they're getting now we love add-ons I think add-ons are one of the best things about MBCLI you have an impressive selection of add-ons available online create a custom comments add-on that holds modules common to all our apps this one was born out of the requirement that now basically we have multiple apps at the moment so our plan is not to develop one app that serves all our functionality so we want to have multiple apps basically so one app for a customer getting a coat and a checkout one app for a customer wanting to do a homo one because I think it helps keep the development and the maintenance of those apps easy as opposed to multiple project streams trying to change one big massive app so but what happens when you build all those apps with MBCLI obviously is that MBCLI builds in all the core dependencies into each of those apps so for example things like the actual Ember framework itself Ember data all these frameworks gets built into individual apps and then if you go to that page if you go to the code app first and then if you go to the homo app next then what you're going to end up doing is actually download Ember twice really because Ember has been built into each of those apps now we want to stop that and say okay we wanted the core dependencies and the common modules to actually be served in one file in one disk file that could sit on a CDN somewhere and then all apps could just reference that single file so in order to do that what we had to do was so this is where I think really the concept of Ember add-ons than the API that the Ember add-ons expose came into play now really we had to do three things one is we wanted to stop the app from actually building the build process for the app from building the core dependencies into the app two we wanted to build we wanted to stop add-ons the common add-ons file the common add-ons which we developed we wanted to stop the add-on tree from being built into each app and three we wanted to insert a script tag that would actually allow the app to reference the common file which we host on a CDN so the three these three hooks that we've used here actually makes doing that pretty simple for example the content for hook which as you might know is linked to the app's index.html file so you have multiple helpers basically multiple hooks that sit on index.html file so in this case what we do is if the environment is protection and if the hook's name is body you just insert a script tag there which will have the name of the file and it will also have the version of the file the tree for hook again it's a hook that allows you to customize what tree is being merged into the including app so in this case what we wanted to do was to stop the common add-ons from being merged into every apps and vendor.js so that's what this does so it basically checks for if the environment is protection then it basically returns a null tree for the add-on what this would do is basically stop your add-on tree from being built into each individual app because if they're common modules you don't want them to be built into every app the common file which you deploy to your CDN and then finally the included hook really to stop building the core dependencies so in that case we've specified an assets to exclude which lists all the dependencies which we want the build process to exclude basically so with that with that approach we were able to stop we were able to basically do what we want and actually host all the common dependencies in a single file that's hosted on the CDN and then all apps could now include that file. I want to show you a quick demo basically of what we've done so far with so this is our code app that we built, we launched I think about a month and a half back so single page application that allows you to get a code product online uses ember data so you put in your postcode, put in your telephone number select all your your fuel type, your payment type if you do not know your energy you get asked a set of questions if you do know your energy consumption you put in your values and you do get a code and then you get the code table now this process previously for a customer to do this took about 2 minutes on the site to give the customer a code the experience took 2 minutes and with this new application we were able to bring it down to just over 10 to 15 seconds on average really so we gave the customer really what they came to the site to look for and then once you got your code you can click the buy now button and optionally send an email of the code results again all these things built using different routes in ember routes really or one of the strong points of the ember framework got a really good router for you to work with so once you click buy now you then get to choose your fill in your details and you do also have you have a widget on the right hand side that actually tells you which sections you've completed and which ones are valid and if you choose to change any of that information you can actually click on edit and that's not my real bang details so that's fine so yeah so you click on small print don't read the terms and conditions and then if you want to edit you go back to personal details you click place order and then it helps you to get it done basically so previously this step to getting from code and actually to completing the sale it would take a customer on an average of 3.5 minutes to do and with the new one we were able to take time by more than a half by building it as a single page application basically so yeah so the add-on API provides great flexibility for authors I think it allows you to do some really good low level customization on the add-on front challenges pitfalls we encountered early on we also have built a couple of custom add-ons BG deploy and CLI test tracker which one of you will actually take you to later challenges pitfalls we encountered early on now this is something we really want to say because we've explored the good bits so far we found a lot of things that work really really well for us but we really wanted to also tell you what we found challenging when we started using Ember the learning curve early on and the documentation I think the learning curve early on is still a problem but there are different ways you can approach it we've seen developers take different approaches to learning the framework and each one with different levels of difficulty really but I think personally the best way to learn Ember is to really get rid of your biases and look at it with a fresh set of eyes understand the principles understand its core concepts do not try and replicate something from another framework into Ember as a starter and then you will start understanding the core features so once you understand the core features the rest of it hangs together really well but now we have version guides out on the Ember website you can go choose the documents you want to see for 1.10 you can choose the documents you want to see for 1.11 good progress being made on that front and we are happy with that lack of a pattern library this is something we found early on where we were trying to say this to us seems like a very familiar problem is that a solution that someone else already has found for this particular problem so it is a pattern tested solution library basically where you can go and say this is a problem you have these are the ways you can actually approach solving that problem those solutions have been tested by the community they have been used in production so you can confidently use it that way lack of a pattern library we did find it a bit hard at the start not anymore with tools of the trade.docure.com I think they should have this again announced at the Ember Conf they have announced this pattern library basically we should hopefully solve that controller types and potential for fat controllers so the first controller we wrote in Ember probably came to around 1000 lines so I think the potential for fat controllers is that if you do not understand how to compose the elements of your application then you can easily end up with fat controllers so it is important you break down your app into proper components were required into proper helpers were required and then keep your composition really good but we have done a few things from our side to make sure that certain mistakes that we made on that front do not happen again controller types having controller object controller array controller item controller not good easily confuses the hell out of people who are trying to understand what they are trying to do good they are going with later versions of Ember happy about that so those are some of the challenges and pitfalls we encountered early on now I just pass on to Olivier to complete give you some more information about what we had with polymorphism and forms and then yeah hello guys I'm actually Olivier hey thank you for the welcome so so much of challenges that we've actually experienced with Ember early on was like polymorphism in Ember data I don't know if any of you actually looked at polymorphism in Ember but you can only establish it when you have a relationship so you have a parent model that has a child model and you can only establish polymorphism for the child model when we wanted it for the parent model so again Ember community is really really good so we had to google it and then we found someone who had exactly the same issue and were able to copy paste this code and put it in ours and now it works great but it's something that maybe would have liked to see implemented from the beginning another issue is actually single page application design because what does single page application truly means us as developers as Ember gurus we understand what it means but the wider team doesn't always understand what a single page application is but then if you tell them single page application well they put the whole website on one page and the customer just have to scroll which is not good enough how does Ember and the Ember community and the Ember documentation helps other people that are not like as tech savvy as we are well I'm not that tech savvy but I bet you are to sort of understand what a single page application truly is because yeah leading to that we can for example forms is a true true and good example of this whatever we say whatever we think form are still really important to the way we design website in big enterprise because most enterprises will try to collect some data from the customers and then have the customers submit that data which is really like HTML2.0 you have this form element which we are not using that much anymore but we still rely on that design principles of having multiple inputs and then at the end of it one button that said submit or save or whatever and then some kind of validation I know some people don't like Angular in there but what Angular has is actually the form directive so they have nice form validation and what we've been trying to do here is actually say hey we're umbrella developers we don't take a loss for an answer we want to win the war against Angular so let's make a better solution than what they have and that's why we started building some components around forms which I think you might be interested to have a look at so Gabor to join me maybe and take him through our implementation of forms Hello I'm Gabor as you thought I'm a front-end developer at British Gas and can we have it please ok so as Dipan mentioned and Ollibir mentioned we work a lot with add-ons and because we have several applications we have to use add-ons it means we want to share all of the services all of the all of the add-ons between the applications and we had we faced a problem with the forms in Ember it's a nice library the Ember validations which is really good for determine if if any of a property fails on a validation rule it's really easy to set up a validation rule you can create your own ones et cetera et cetera what Ollibir mentioned well we had an idea and we started to implement it from Angular so we separated the concerns and we are developing currently a service a proper service and a component which helps you one of them helps you in the form validation it is a lightweight validation which based on the Ember validation library and the second one the component it just helps you to set up your display rules in a form what I mean as you saw in the previous application the get-goat application we use bootstrap and as we follow the bootstrap conventions we using the arrow messages and we have the control icons at the inputs the problem is and maybe you found the situation so the business sometimes not consistent so it means that the rules how to show and when these arrow messages it is different so in one application you have to show the arrow messages on key updom event on another application you have to show your messages on blur to find another another problem only when it is on error sorry okay and the goal was to create a service and a component which can be shared between the applications and you can set up the the rules on the application level what it means first of all I'd like to introduce you it is an experimental so it is not published yet but we are planning to publish it to the community because obviously this two service and this component will have our life in the future because we have to work a lot with forms and what I want to show you okay the form validation here I set up two different forms the reason is why I make this demo with two forms because these two forms has the same properties it has the first name and the last name so just to be sure that these are different instances so as you see on the left side it is the first form what I want to show you this object, the user one object comes from the controller and on the left side you have the form we have the validation rules it is the proper amber validation rule currently we have just the presence validating and what it does as you see here on the right side after we use this service on the user one object we'll be decorated by new properties which is the user one the status first name valid and of course the invalid user the status last name valid and we have a user one dot valid which represents that the whole form is valid or not why it is good why we want to use it we want it to have a portable object it means that we have this user object and it's sitting on the first controller and in the journey when we are transitioning to the next route maybe on the next controller we want to fetch this object and on that point we want to know that it is valid not why it already want to do anything else with that because we want to reuse this this object but we don't want to persist it so it is just in the memory it is really good way because from other controller you can reach this property from the previous controller nice the really good here that this properties helps you in the template to manipulate for example as everybody knows in the form group class div which is a wrapper for the input you can specify that you want to add the hazard or not depending on this property it is available on your template but how it works because the presence is the only rule here if I delete my name as it so automatically updates the the first name validation and the whole form is invalid the second object it is really similar to the first one the only difference is that the last name is not specified when the page was loaded so I just created it to check that validation process runs or not and as we see here it works properly and as you see in the left side at the first name we have the minimum three character length rule which works properly so it is the first one it is a service it comes from an amber add-on so if you create the MPM package and this will work just to have a look at the current implementation yeah so it is experimental as I told you you have to inject the service twice the reason is because we want to have two different instances it is really important otherwise you will overwrite with the same property so we have two forms both of them have the first name and the last name and if you have only one instance we will overwrite the first one in the init section in the init event we create our object we set up the user one property dynamically and the module helper has a create method it is not the amber object create method it is our custom one it is just for the conventions and currently you specify properties and now the validations this way but of course this will come out and we will solve it another way why it is good this service automatically generates you all of the rules of what you paused and these properties will be available on your template or anywhere you want as you see here one of the validation rules is imported from another file it is really good because if you have a big form for example you can hide it from your controller so you can keep it clean it is really good in the second object I just paused it directly so it is the service any questions about this service yes no the second one it is the second one is a component as I mentioned the goal of this component to help you to specify when you want to show this icon when you want to show the arrow message for example now this arrow message is shown only when you have a blur event it was the requirement but in other application we have to use a different one previously in the template we created our form validation helper and on every application we had to find out what is the rule when you use the if condition in the template and that condition must be calculated on the controller so in your controller you had a lot of unnecessary code after this that is unnecessary because what it does this idea came from Angular what it does exactly that so the DOM is based on bootstrap conventions as you see here we have a form group class inside that as a wrapper you have the label you have your input you have anything you want it doesn't matter this div it is the component I will show you what it does as you see automatically it added these classes now it is BG prefix so as I told you experimental and we use the same name as in Angular the reason is because a lot of developer come from Angular word if you know what it does you will know here as well and we came from Angular word so inside this wrapper inside this component we use the component to replace the HTML what you passed into that so we use the block convention and what it does if you have any of the DOM event it creates new classes maybe it is icon ok so so now we have two classes the pristine and the untouched it means that the user didn't had any key up event if it is a select it is not changed the untouched mean it was not blurred yet what's happening if the user click on this it has the in focus it is not from Angular it is our idea it can be helpful to describe other rules if you start to change the value it gets the value change class and the service store the initial value so if you set it up back it removes that it is really good because you can identify that the value in your changed or not and if you leave this input it gets the touched and because I changed already the value it is dirty now why it is good because after these classes are existing on the wrapper to specify the elements to be displayed only on CSS level on your application so as you see here the form control feedback icon it is these are the rules when it is dirty or in focus or touched the alert message is only when it has an error and it is touched already and if you want to change this rule feel free so it is just in your application and I like to show you the template because the template is cleaner now okay so we have currently we use this name but we will find out another name bg form form group this is the component which creates this for you you can add any other classes you want and as you see here the has error it is added when the user status first name is invalid and it is a way that how you can use the bootstrap convention because the has error is a bootstrap class after that you don't have to find out when you want to show this icon or the alert message previously we used if conditions and that was calculated on controller now in the controller nothing is there only in the css so that's why I'm pretty sure that this small component will help us in the next implementations so in outlines it is the oh yes and one more thing as you see here the user one errors first name on the ember validation so if you want to overwrite it, if you want to specify your own error message you can do it in the ember validation way so that's it so we are planning to publish it in the next few weeks now this this demo application is available in the github our group is called connected homes so I don't know somehow we can we can I don't know just let the guys know because now yeah something similar please so on the connected homes this application is available and if somebody interested on that just raise an issue just to know that you want to be notified when it is done so hopefully in the next week or in 2-3 weeks this will be available I guess so that's it thank you any questions I think we are just going to wind this up really is that this is just really to demonstrate what we have done with the ember so far the add-ons we plan to finish the add-ons we've done what we what we found over at ember where we would like ember to improve as a framework so those were the slides that really we wanted to tell the community on what we've done with ember so far but now we have understood the nuances of the framework really we are going to flow the throttle now basically and build more apps in the next few months I'm not going to go with slides anymore so so I think we are going to build a fully interactive online account management app that allows our customers to come and manage their accounts online submit a read, make a payment so it's going to be probably one of the biggest apps that we built so we are excited and looking forward to that and really the last thing was what Andy said earlier on so if you looking to join the transformation that we are doing at British Gas you are welcome to join us there are more details on the slide pack which we will share anyways later on on who you want who you have to contact if you want to be part of the transformation thank you is that something that is hard coded at the back end or do you have some possible steps as a generic object down to the UI and then the UI gets the steps from here so the UI itself is the actual workflow so the actual for example that the get quote and sale it is a single page application so all the work flow is actually done in the app the way we actually move the API so for example there is data that needs to go because it's all restful we need the data to actually go into the back end and we can't allow someone to actually do a bind without actually getting a quote first it's a legal requirement and the data that you put in the front needs to then get passed to the actual order so we create when you do the quote it actually comes back with a payload so we use the payload then we pass it through to the bind part of the journey so the workload the actual management of the data is still restful and we're passing the information back on between the APIs we do need to know a bit of the actual information how the flow goes from one page to another page at the moment there are APIs we're not monetising them so we know what needs to go from one ear to another but we've actually got wikis we still create wikis we still create APIs with documentation of the APIs so yes there is a workflow the workflow is based on the APIs so data front-end is the main control of that actual way to get one step to another step so that's a hard coding flow rather than an object that represents a flow that is something generic no we don't do any of that there are some I think connected homes do a lot of which is the high product they do a lot of that and they also do a product called smart energy report which is also embedded into bridge gas it was a handcrafted framework someone built and they were saying the guys were saying it's a top nightmare to maintain and I looked at their code and it pulls back the actual it makes a call the API returns back a load of information of how the events work and what the next step is and how the pages work so we don't do that we actually let the ender guys build that we don't want to have some generic tool that does everything for you the how to go about building that shared bundle of dependencies that's both guys so the common stuff you mean share bundle of dependencies so what we did was created an add-on basically so show you on that so we created an add-on called ember commons basically ember commons is basically to hold common modules that are common between different applications now as you can see here things like an application adapter helpers initializers models that are common to ember data models which are common to all of our apps or which are used by most of our apps they all sit within this add-on called ember commons basically and then each of our apps is if I ember commons as a dependency and then all these modules get built into the individual apps so we basically made use of an add-on basically to share common modules and common files between different apps now the only problem I as I mentioned earlier was that is that it gets built into every app so although they are common that code actually gets built into every app which is what we are trying to avoid with this solution where these things are actually built the add-on basically is deployed out the output of the add-on is deployed out to a CDN and then all apps actually have a reference to the distribution script file that's to stop every app from downloading the same common modules and common dependencies repeatedly as customers move between different apps we've actually the use of the common add-on we've actually used it on static pages as well so the header and the photo on our website at the moment for the beta website is a and there's a bit of content, it's actually the header and photo or ember apps with ember add-ons and we just plug them into the static page on the website so we're building up a way that in the old days it would have been a CQ component which is server side and it rend it up server side and each that's the way it works and then you ended up with a page that is anything that's functional because it changes depending on whether you're logged in or not that became a nightmare to maintain because in fact your entire side became dynamic, no caching the beauty of this client side, you can cache the JS jobs are good just deploy it once it's in the browser, you change functions, you change from logging to from logged out to logged in you don't have to download a new page it's there in the app, it's in the actual header and we've created functional pages and functional journeys as well so we've actually got a functional add-on that just plugs into a static page that does quoting in a static page so we've done everything that's not a JS it's actually scanned around the website and if you're working on one of these apps and you realise you want to make a change to one of those shared models what's the workflow there, how do you feed that change back into that add-on at the moment because we don't have versioning on the comments add-on basically we found that early on we found that it was a problem but now what we do is we version we version the comments add-on basically and we create a release every time somebody makes a changes so we make sure that creating a new release ensures that apps that are not yet ready to use the new features that are now being introduced into comments can still work of old release while apps that are now using the features that we introduced new into the comments model can actually use the latest release so we basically use the concept of releases to manage different versions that gives apps the flexibility to update or to use a specific release of the comments plugin going forward when we are going to introduce this version where comments is just deployed as a distribution to a CDN we will probably re-look at that process and see what's the best way of doing that for that solution Are you planning to open-source comments as well or the pan's behind it? Well, at the moment the objects that sit within comments are probably not useful anywhere outside of British Gas we have a code model and a path model probably not as exciting outside but what we plan to do is components that we use that can actually be re-used outside of the British Gas website as an on any website that we think is going to be useful to the community we will package them as separate add-ons and then share those add-ons with the community like what we plan to do with the form the form group and the form components which probably have much wider use outside of the Central Gas website Cool Any more? You have to say a few different things to create that first page of the add-ons that makes it a separate JS file that is really useful I think it's the add-on API we've done lots of research exploration into it I think a lot of Jackson is available probably all the time to talk to any question he asks I think I actually beat that record of what someone said 27 seconds I think I got a response back from him in about 15 seconds but he's always available if they help I think the API is like I said earlier really do low level customisation so you can customise every bit of your app during the build process which is what we really like about add-ons so yeah we will share any add-ons any components we think are reusable any patterns that we extract out of building these apps we will make sure we share them Alright give it up