 So, about a year ago, I think it was in April last year, we came along. We had two teams running a British Gas. We just started using Ember for five months. And the site at that time was a lot of legacy care. It was all server-side, JSP, Java, JavaScript. And just at that time, we spawned up, spawned up. Five teams, they're all doing iJob, different types of iJob, whatever the team wants to do, they'll do whatever they want. We have five running apps at the moment. So, we've got the online application management app. We've got the energy sales app, the services sales app, the home move app. We've also built, this is the static content page that we have running on AM6, which is a CMS system run by Adobe. And we've built the header and the footer. Those are actually Ember applications that we're actually dropping on to the site. Anything functional on a static page is an Ember application. We're looking at actually migrating all this stuff into Ember islands at the moment. So that'll be another set of Ember applications that we're actually going to be deploying on to the site. It's been fairly well received. Speed of deployment, bills, releases, beta journeys, all done through the Ember application. 300-odd releases over a year. In the old days, it was one a month, if you're lucky. So we worked from 12 to 300. Any site change, as you've seen, we've actually put our prices down like everyone else has done. So not that we're still cheap, if you see what I mean. So the actual Ember application was also bootstrap. Anything that we actually can get out of the Ember community we're using, we're actually running a bit behind the main Ember application itself on 1.13. Ember data, anything that we can get out of the community we're using and we're trying to feed back into the community as well. As much as we can. It's a bit difficult in a corporate environment to actually send anything back because our masters above us say, sure you don't want to try and sell that as a separate thing, maybe get some money out of those poor people that are trying to actually do some work. So this is our OAM application, the front-end into the website. Uses OAuth 2. We've iterated multiple times over this. We're back to go 100% in about a couple of weeks on this. It was a beta application, as you can see on the top of my right hand side there. It's a beta application and we've been running against the current main site for, it feels like a long time, but about six months. Trying to convince the business that what we've actually created is good, is all to do with measurement, monitoring, giving you the stats. We use Omnichir for our stuff, or SiteCatList as it used to be called. And it's the speed of response of the teams that actually, the way that we're operating now is a lot faster than the other teams in the company. So they're always catching up with us and it doesn't help to actually push the journeys forward, making better, especially the beta stuff. We're using a lot of technology that we never used to use. We used to use ClickTail. If anyone's tried to use ClickTail with an SPA like these, Total Nightmare. So we've purchased another product, Inspectlet, if you ever want to look at that. Brilliant tool. SPA is straight out of the box. And videos, heat maps, scrolled stuff, all sorts of interesting things that are very useful when you're actually trying to improve a journey for a customer. Because the amount of stuff that you don't envisage when you actually do the custom comes onto the site is pretty impressive. Is the six months period, is that a reflection of just kind of the conservative culture? Very, very conservative. Are there any particular things that they're like holding out on? It's saying like, ooh, we don't know. Maybe you want to have web chat in the main journey. Maybe you want to have this. Maybe you want to have that. Maybe you want to be able to allow our agents to actually potentially mimic a customer. We've got this functionality called impersonate user. That functionality doesn't work with the way that we built this stuff at the moment. There's a way around it, but they don't want to give that to the agents, the way around, the work around, because it's too complex for them. So until we build that, they don't want to go to the 100%. So it's a bit annoying, especially because these journeys, especially the registration journey, which I'll show in a bit, is a lot faster, a lot better. We're discovering a lot of stuff when we're actually going, I'm just trying to remember the password now. Yeah, that's good. That's all right. So the application itself is we've used a lot of stuff that we, as we've been going along, we've been iterating along. The first iteration that we did about, it must have been a year ago now, was a single fuel customer. It was just gas. And every so a couple of months, we drop in new function, new customer, new segments. It's all using the data in the backend. So when we actually move across from one application to the other, it's all moving around. Because we're tying into the old site at the same time, we've still got to maintain functionality that goes back to the old site. So this is our old site in effect. Trying to convince the business that this was okay, there's another nightmare. As they see the uplift of actually some of the journeys that were built, that slowly disappears. So for us, as we've been going through our life with Ember and client-side applications and all the other bits and pieces that we've been doing, it's a total different culture that we're trying to build in the site and with the company. We still get a lot of pushback. We're still trying to improve the culture of everyone else around us. But we are a small team. There's only 100 of us, sorry, in the team. In each team, we've got five scrum teams. So we've got two developers, front-end developers, a BA, a solution architect, business people. And if you get a good product owner, you can see the difference in the actual way that the team works. And the actual mentality, we're going on a minimal viable product. So that entire culture that we're trying to change to use Ember in a production environment under, well, customer load. So we've only got a couple of million of customers. This is running at 50% at the moment on the site. And as I said, we're moving up to 100% very, very soon. I'm just going to go through. We've got, as I said, five applications on the site that we've actually got. And I think we came here, I think we had two right at the beginning. So it was just quote and sale, quote and home move. So let's have a quick, home move journey. And those times, we've actually rewritten and re-styled a journey multiple times. It's been going through the site as well. So we've had a total UI change since the last time we were here. So that has also been going along at the same time. We've had the stylesheets have all changed the actual feel and look and feel of the site. Because it's all client-side stylesheets, it's very easy to migrate away from one to another. We ran the two sites A and B together to see if any customers were actually dropping out because of our new VI. We saw that it was better to switch the one off. That would have taken a project six months a year in the old days. In fact, we've still got a project that's still running that is a migration project from five years ago that never completed. Do you have problems with browser support at all? Yes, because we have to support IE9 still. So we did have a bit of a period where with the front end, it was actually dropping out. We actually lost a lot of support. But the only people we've got 1% of customers that use it, proper customers. Most of those customers are actually our corporate customers as in our company because we've still not upgraded up to Windows 11. So Windows 10, sorry, and IE11. So that is our biggest challenge is not real customers, internal customers. And you can't say, oh, we can't support them because they are the pain in the ass that actually says sign stuff off. So because we built it so that it can actually cope with, we've actually back ported it so it actually will work with IE9. So we have to because there's no way else that we could actually do it because a lot of the people just use IE9 internally. Does InverDrop support for IE9? They have drop support, yes. Are they dropping IE9? IE8, IE9 is supported. Just. Noise to make sure that stays around? No, supposedly we're migrating off IE9 this year sometime, maybe if we're lucky. So this is our home move journey. Again, we've migrated across from, we're still using a few bits and pieces from our old site in here. But the corporate service and then we got this home services stuff. So as we're going along, it said, oh, there we go. We can carry on. But generally it's that we've got multiple applications all running at separate times. And we're all using ABs testing all the time. The fact that we can actually put fingerprints on the Ember applications, Ember CLI deployments, the speed of deployment. It's all good. There's nothing bad about the way that this stuff works. So as a corporate entity and actually people actually using this stuff, it's a lot better than what we used to use. Obviously we still got the old bits of pieces of the site. They're on there. The changes for us to actually use the Ember application are initial issues, recruitment. We've got Angular guides now doing Ember. Every so often the Angular stuff does creep in. And the conversations that I can still build is quicker if it was Angular. It can still keep coming up. But those are slowly fading away. The more support that you get, the more applications, the speed of actually changing. The actual summer stuff like Ember islands, because there's such a big community, all people developing other ideas out there, it's so much quicker to actually develop stuff, especially the static things. Because not having fast boot, this is the discussion I was going to have. I actually have a quick word with you about fast boot and how your experiences with fast boot. I've got this problem with fast boot because it just harks me back to the old days, which is server side rendering of sites in effect. And the power that you get with client side is that it's pretty instantaneous and you don't have to have a huge amount of kit to actually run all this stuff and sessions and maintaining sessions and things like that. I may have to have a word with Stefan and those guys about this. That's my personal problem. The way that we split it up, we split the site up into small applications that are pretty quick to load, pretty self-contained. And if they need to log in, you actually log in using the old stuff to actually cope with that, so implicit flows and things like that. So you can cope with switching between applications. And if the application's got the token, obviously you get the data. The data's there. It pulls it in. So generally, all of our stuff that we're going through at the moment is being pretty, pretty good, darn good in American-type things. The API and the data's fitting. Are you going to open that up? The bot can fit the API. What's my gas bill today? You see, that's one of our goals. It's one of my goals this year is to actually expose the API so we can monetize it. Or if it's monetized, bits of it can be monetized, bits of it can be open totally. So as an identity provider, that's your first step to get your authentic identity. Then you pull the data in that you can actually give away for free. There's bits and pieces we can't give away for free. But most of it, I can't see why we can't expose the APIs out. We're actually going through a process at the moment if anyone's interested. We're moving away from all of our back-end code was all written on a legacy system, so we're trying to get off that at the moment. So we've got a project this year, if anyone's Java developers. We're moving away from OSGI built into our old core system, and we're moving to Spring Boot and Netflix, OSS, Spring Cloud, OSS, to actually make it so that the microservices running on top of Kubernetes is our goal on top of that. So actually because microservices, fully scalable, resilient. On top of Docker, yeah. Is it part of CoreOS or related to CoreOS? It's Google, so it's not related, but they use it on top of the together. So we're actually, that's this year's mission. So last year's mission was front-end, UI, get that out, get that easy to develop, deploy separately from the data. Now next year's mission, along with everything else that we're doing, is actually get the data in a system that's actually fully resilient and extensible. As with everything with British Gas, it's money and time and effort and politics. We can get coins on. I have coins on thing, yeah. If there were real bitcoins in that, that would be useful. I'm curious. I mean, you said, I think, five applications. Yes. Do you share components between them? Yes. So we have a common component library that sits behind that, and we pull those into each of the actual applications that are actually deployed. Another one that comes later in your common component. Yes. I think if you look back to the talk from April. Yes. There is, I think, deeply presented a segment about that, about the shared component library. And I think it shares the component to get compiled into a file, which, literally, the file is shared between the apps as well as after it. Yeah. And that was one of the things I think they were quite interesting in releasing. Yes. How's that journey going? I'll have to remind them. Actually, what I'll do is, after this, if there's something recording, what I'll do is I'll ping him. Because he's supposed to be in here today as well, but he's coming down to London tomorrow, so he can't do both days. Family commitments, as they say. So yeah, that's it. So I think we exposed something, forms. I think we've got it put out there. I don't know how many people use it, but it's out there as well, which we are using, because we are using forms everywhere on the site, because that's what we do. We take data and put it into our, ingest it into our back-end systems. I haven't used it about the energy industry, because I've worked at it. I'll take it off the line. Yeah, if you go down the pub afterwards, I'll definitely talk about that, especially with our great pricing structure that we have for that. Do you think, eventually, all the British gas front-end will be perhaps amber? Yes. Like a single application? So our biggest issue is the amount of static data, static content that we have on the site is quite big. And what we don't want to do is create a monolith, because we had a massive monolith beforehand. And the beauty of having separate little applications that can actually be deployed out separately means that the different teams can all travel at different speeds using different techniques and different deployments. If we then built one massive application that just piled everything together and deployed it all in one go, it would potentially, we have this... In a corporate thing, it's just getting the people together to actually deploy it all in one go. And that's what we used to have. And it was a horrible mess of testing to actually get anything released. So the beauty of this is you're only testing one set of functionality, you're only testing, quote, you're only testing services, you're only testing HomeMove, you're only testing OAM. And you can test the front-end away from the back-end separately. So we use Mirage a lot for the testing. A lot of the mock stuff that we do is we put a lot of mocking into the actual front-end. So the front-end and the back-end are so separate, it helps out. If you have taken a look to engines because precisely they ask the question, do you can pretty much build independent applications and mount them together? All right, okay. So I'm actually using... Ember engines. Ember engines, yes. So just to give you the idea, your main application is basically a shell, a shell with holes. You feed the application and these applications can be deployed independently. So the big thing is you don't, since the application is the same, you don't use the session, the session is common to a lot of them. And that can be helpful. Well, that's when you stop thinking about Ember engines fast boot and you're starting to tie them slightly together when you stop thinking together, if you think about it. But they're different. Yeah, I know, but it's... They're both different. Yeah, yeah. What's your potential look at it? I said we're always rewriting. That's the thing is with this and the front end, because it's front end, you can rewrite quite a lot. We've just got to convince five teams that we're actually going to rewrite altogether. We just need to figure out the message out in the corporate community. I think to the comment, I mean, time made earlier, kind of trying to get a reaction out of the crowd, but like, you know, what I would love to see is, right, and Angular is saying because it's got... Lots of... Exactly. So, maybe that doesn't... Ember doesn't ever have to hit the corporate sector. I mean, that's possible, but it'd be nice if it did, because I think that kind of sponsorship has... So the last... I think we did... we sponsored Ember camp last year. Right. So... that was actually quite easy to do. I was quite amazed that our corporate supporters, I said, oh, that's fine, yeah, we'll support that. It's not that much money. In comparison to the amount of money we do spend on stuff. No, no, but it's... It was a part of the sponsorship, you know. So... I think we became platinum. I can't remember which one we went for. So... that support is fine. It's getting out into the community to tell other people what we're doing, because it's... it's fine, but we are actually... it's limited to what we can do that's actually far out on the innovative. Because we still have to do the actual stuff that actually gives us the money to actually run the site. So you have... can now say... I'll use Ember. Yeah, so British Gas do. The other team that uses it is another part of British Gas which is Connected Homes, which is the hive heating stuff if you ever heard the adverts on TV and everything. But they've gone for Angular because they had a... it was a recruiting thing. They said, right, how can I get people in now to do this work? I know you're using Ember. I can't be asked about that. I'm going to go for Angular because I can get people now. And that's the main thing. And the more people that use Ember I think the corporates will stop paying people in. Even though the guys that are using Angular or have used Angular switched quite quickly to Ember. I just saw something on Twitter about someone actually doing an Ember Angular to Ember training course from someone... I think it was Tom Dale, I think, posted that on Twitter at the moment. So that would be... stuff like that would help. Equally, something that we really benefit from is employers encouraging their people on their teams to come out and give talks about the things they've been working on and the techniques they've discovered how they found onboarding to Ember and how they convinced their company to make the best on it. For anyone working in a bigger organisation with deep things to say at all as we always say five minutes is a fantastic way to talk. And I think I think yourselves in deep have been talking about getting corporates out to come out to us because you can come out if you want to come out to stains. That's where we are. So if you want to come out to stains and have a look at what we're doing I think we can organise something. That's the thing. So if it's a corporate thinking about trying to use Ember if you come out to stains you can see the way that we've actually implemented it. We've been using it now for a year and a half. In anger. That's it.