 Okay, so first of all thank you all for coming, really great turnout, it's fantastic. This is a talk about BBC Store, which is how that was built on Drupal and why it was built on Drupal and some of the kind of challenges that we had along the way and it's basically a guide to how organisations of the kind of size of the BBC go about making the decision to use something like Drupal, why they use it, what the strengths and weaknesses are for them and hopefully it will give you a bit of an understanding of what Drupal can offer in that kind of enterprise environment. First of all, just a little bit about me, I'm the CTO of Fluxus which is an enterprise Drupal consultancy. I've been a Drupal developer for 10 years, or 10 years and four months according to Drupal.org and this is me when I was starting out as a Drupal developer and I had substantially more hair than I do now, so you can kind of get the idea of this is what 10 years of Drupal developer does to you, it definitely does help. So just a little bit about Fluxus, just so you know who we are and what we do, we work on projects that are mission critical, so these are things that need to be kind of highly reliable, they need to scale, they need to work well under high levels of load, and they need things like disaster recovery and monitoring and so forth, they're integration oriented so this is kind of systems where you've got Drupal but you've got a whole bunch of other components as well, so you might have other services, some of the stuff that for instance Clifton was talking about in the keynote this morning, where you've got Drupal but you've also got a microservice architecture alongside that, you might have APIs provided by those services that Drupal is consuming, or you might have APIs provided out of Drupal that other services can consume, and also high volume transactional, so this is large sites where you're going to see a lot of transactional requests, so by transactional here, this means in two senses, one is financial transactions, people are buying things, and the other sense is that you can't get away with just cashing the entire site, you've actually got to have the ability to serve requests where people are going to expect to see custom responses coming back that are personalized to them. What is BBC Store? So hands up for anybody who's used or seen BBC Store so far. Okay, that's actually really good. I was terrified everyone was going to say they've never heard of it, it was a complete waste of time. So it's a transactional video on demand store, and what that means is you go on and you buy access to videos. It's really, really simple. This is as distinct from something like Netflix where you purchase the subscription and you can then watch pretty much as much as you want. This is transactional, so think of it as being, somebody wants to describe it as digital DVDs, which shows they don't know what the first D in DVD means. That is basically what it is. You can buy individual episodes, you can buy series, you can buy collections, and there's lots and lots of different kinds of products, many different products, many different prices, promotions, coupons, discounts, bundles, all that kind of stuff. It's got a lot in common with a traditional e-commerce store. It's on the web, but it also has mobile applications, so there's iOS and Android mobile applications. There's also Windows 10 application, which runs both on desktop and mobile, and there's also desktop Windows and OS X applications, which you can use to download content to watch offline. It's integrated into iPlayer, so if you have the experience of seeing something on iPlayer and you don't watch it at the time and then you come back a few weeks later, it's not there anymore, you can actually now go through to BBC Store and purchase that. That integration allows you to go through to BBC Store, buy the content you want to watch, and then come back to iPlayer and watch it in iPlayer. It has 50 years of archive content, so the stuff they're going back to the 1960s, very, very early, Dr. Who and things like that, there's a whole bunch of content there that either has never been available before to buy, so it just predates the VHS video cassette, predates DVDs, or it's long-tailed content. No one ever really saw a point in putting Series 4 of Bargain Hunt on a DVD, because frankly, no one's going to buy that. It's not worth taking up the shelf space in an HMV, but on the web, there's no reason not to do that. Just an example of some of the content that you see on there. You've got Dr. Who, and again, one of the big selling points is you've got the complete back catalog, every single series, every single episode. As far as I know, I'm not a Dr. Who expert, so basically, we have no wrong about that, but it's not okay. But it's got most of the content, most of it is there. You've got things like Top Gear as well. The less said about that, the best of these days. There's that anti-trude show, so that's a good example of, again, long-tailed content. This is a show that's been running for, I don't know, 25 years, something like that. It's been running for a very long time anyway. Again, no one's going to go out and buy that on a DVD. It's not worth taking up the shelf space if you're going to take up space in W.H. Smith's or HMV, but on the web, it makes sense. You've got that one episode where your auntie was in it and she brought a clock along and it was worth £10 or something. That kind of thing. You can kind of see that if you really want it. Another interesting example is this. Would anybody be able to tell me what this is from that picture? I appreciate the picture at its distance. It's not correct. Sheffield. So that's actually a show called Threads, which broadcasted in 1984. It was a BAFTA award-winning, kind of short film basically, set in a post-apocalyptic, post-nuclear war in Britain. It's obviously an early alternative. We're worried about nuclear war with the Soviet Union. These days, nobody kind of tends to worry about that very much, but this is like an award-winning content. This is a really, really good film. It's one of the surprise hits in the first week after the site went live. What we discovered was that people actually, there was this pent-up demand. People really, really wanted to watch it and they had been able to get hold of it for years. So it was actually one of the top-selling items, which nobody would have predicted beforehand. Unfortunately not. There isn't very much in the way of sport. There might be the old kind of highlight compilation thing like that, but sports generally, just due to rights, management and so on, is different. You can get that on iPlayer, but I don't believe you can buy it. But in general, it does keep up to date with things that have just broadcasted. So you can go and buy something that was on TV last night. Obviously that stuff will still be available on iPlayer for free in general, but it keeps up to the minute with what's broadcasting. There's a question that probably people here are more interested in is, is why Drupal? Why would you build something like this on Drupal, given the alternatives that exist? A big reason is actually there's a history of doing Drupal at BBC Worldwide. So they've had previous success with your food and with Tokya. And there's quite a few people here who've worked on those sites at various points. They're quite big. Good food is one of the biggest sites in its market in the world. Tokya are also very, very successful. That was re-platformed on Drupal last year and has kind of all the revenue figures and so on have really gone up from that. It's been a very successful re-platforming. So the BBC already knew the platform. They already knew how to host it. They knew the operational side of things. They knew how to how the editorial kind of things worked. And they were confident that they could get a good result from it. The other big selling point is the community. So, you know, people like everybody in this room. This is a picture of Drupalcom Barcelona. I'm in there somewhere. I think I'm over there, but I can't pick myself out. And the community is really, really, you know, it's one of the big selling points of Drupal, the fact that you can come to an event like this. So I think, lastly, a BBC world order actually sponsors a Drupal camp because they know they can come here and they can talk to Drupal developers. They can find out what everybody's up to, what's going on. They can look for people that they might want to hire. They can look for ideas about, you know, new up-and-coming solutions. And they're not tied into, you know, maybe a bender that might go bust or something like that. The Drupal community is not going to go bust. Collectively, individual companies may come and go. Individuals may leave and join the community. But it's a self-refreshing, self-reflection kind of source of people who can do really useful things with Drupal. So it's an amazing talent pool, you know. So for every person like me who's been doing this for 10 years, there's new people coming to this kind of event. It's their first Drupal camp. I think there's always a lot more that we could be doing, and we could be doing a lot more on diversity, on outreach to people who maybe aren't getting the opportunities at the moment. But there's definitely, you know, a really vibrant talent pool already. And that gives you access to many suppliers. So you've got the, you know, massive kind of, you know, venture capital-backed companies that are doing really big things. You've got the systems integrators that kind of cap Geminiers and so on. You've got digital agencies doing Drupal. You've got Drupal-specific agencies. You've got consultancies. And, you know, all the way down to independent contractors, there's a large pool of those, and, you know, niche consultants who just maybe focus on one specific area. So whatever you need, the Drupal community kind of supplies a full range of different options. And it's also open source. So this kind of goes back to one of the points that Cliff then was making in his keynote this morning as well. That you often face this question when you're building, or when you're looking at your software options internally within an organization, which is build versus buy. So if a 99.9% of your decision is going to make, you're going to buy because you're not going to build your own word processor, you're not going to build your own spreadsheet, or you're not going to build your own email solution. But when you're trying to put a product out there in the marketplace, this becomes a really live question. Do we buy an off-the-shelf solution that, you know, supposedly already does video, and it kind of does some of the features that we want, or do you build something? And if you're going to build something, do you build from scratch? And obviously the problem that you would have if you're doing that is building from scratch really involves doing an awful lot of work. You know, an awful lot of things that you need to think about that the Drupal community has basically already thought about. You know, we've already kind of had these, whether it's security issues, whether it's usability issues, whether it's, you know, key features, out there on Drupal Core and Drupal Contra, it's like the embodied efforts of thousands of people over many millions of days of effort to create something that kind of already does a lot of those things. So you get to kind of have a little bit of the best of both worlds. You get all the benefit that you get from buying in a solution, which is that there's a lot of pre-built functionality and features that are ready for you. But you also get the advantages of build, which is that you can customize. You can, you know, you can choose your own user interface. You can integrate it with the services you want to integrate it with. You're not being told, oh no, that's not going to be ready until next February by your vendor. Or if you really want that, it's going to cost you an absolute fortune in professional services fees, which is generally what tends to happen. And I think where this is important for companies that are looking to launch products is that a lot of the functionality that you need is kind of below the surface. A lot of the stuff that you need is not immediately visible. So to your customers, the bit that they can see is the bit that's above the waterline. They can see the bit that's the top of the iceberg. And that's the bit they're going to interact with. That's what they're going to click on to buy things. They don't really care about where any of this other stuff comes from. So what Drupal does actually that's really, really powerful is it takes away the need to think about, wow, how are we going to build an Editorial UI? Maybe we should try that new JavaScript framework for building an Editorial UI. All of the kind of ways in which you could probably end up spending years and years, you know, iterating on a particular way of doing things. Drupal kind of, by being opinionated, it gives you a lot of that stuff that's the bottom half, well, the bottom 80% of the iceberg. Kind of already there, and you can focus as a product manager, as a business, whatever it might be, on the stuff that kind of really matters to your customers, which is the front-end user experience, the business model, the pricing, getting the right content out there. You know, people aren't going to go to buy something from BBC Store because it's built on Drupal. They're going to go because it's got really great content. And what Drupal does is it just enables you to get that out there so much quicker. So just a very, very quick kind of summary of some of the things that we've benefited from as a result of Drupal. You know, this is probably way too small for anybody to read, so apologies for that. So you get the ability to view and browse content, you know, you get taxonomy, you get views, you want to categorize stuff, you know, that stuff is almost, it's out of the box. The ability to search content, again, Soldiers is really well supported. There's a whole bunch of stuff they search API and so on that makes it really easy to do. You want to edit the content? Okay, well, you've got an editorial UI straight away, you've got the permissions and roles, you can create users. With some really basic contrib stuff, you can actually have a proper controlled workflow with permissions and so on. You want to create content or curate content. You've got things like entity references, you can link different bits of content together, you want to put together a custom home page or a custom landing page. It's really easy to pull in different bits of content from across the site to do that. One of the things I think is really, really important is actually the ability to model the data. So when you think about what something like a BBC Store has, they have this concept of a brand, something like Doctor Who, and then under the brand they have series and each series can contain episodes and the brand might also contain collections and the collections might contain some of the series and some of the episodes and it gets quite complicated. But what Drupal gives you is this kind of ability to really plug things together. Okay, so I want a brand that contains a series. Well, so that's an entity reference from the brand to each of the series that's contained within it. And it just speeds up that process of being able to work out what those relations are and put them into the system compared to I don't know, going away and doing massive database diagrams and all this kind of stuff, which is very, very practical and pragmatic. Also gives you tools to help migrate the data. So getting the data into Drupal, the stuff that appears on BBC Store doesn't come from someone sitting there typing it all in. This comes out of a backend data store and is migrated into Drupal on a regular basis. And this ties in with the data modeling, you know, maybe you need to take the data in the backend and change it a little bit. One particular example was with BBC Store was that they had this concept in the backend of something called a miniseries. And this is basically who were, you might have a six episode series, broadcast three years ago. And what they did at the time is they put three episodes out in the spring and three episodes out in the autumn. And so as far as the backend is concerned, this is like, you know, separate miniseries. But if I wanted to come along and buy that now, I'd want to buy that as a single series. So the migration kind of functionality gives you that opportunity to do some data transformation and kind of bridge the gap between the data model at your backend as the data model you actually want to show to your customers and kind of manage that process of keeping everything in sync. What modules do you use for migration? They're custom migration modules. You'd probably be better off speaking to this gentleman here because he actually wrote them. But yeah, the gist is basically we migrate everything into staging tables in the database first. And then from those database tables, we actually then do the sort of normal Drupal migrate. So the actual Drupal migrate bit is incredibly straightforward because it's just from database tables into nodes. And then the, yeah, I'd say this guy here. No worries. Drupal also gives you tools for serving APIs, which is really, really useful, particularly when you've got mobile clients or you've got other backend systems that need to talk to your systems. So for instance, I mentioned the iPlayer integration. One of the things that iPlayer needs to do is it needs to know, I've got this piece of content. Is this actually available for sale on BBC Store? So that calls out to BBC Store to find out, is this piece of content actually available? And that ultimately goes through to Drupal to kind of say like what is the status of this piece of content right now? Is it available for sale or not? And then I think a big thing that people kind of underestimate the importance of, in particular under a script, what Drupal gives you is security. So just the things like cross-site scripting, cross-site request forgery, form validations, bug protection, all of this kind of stuff that's kind of built into Drupal. If you wanted to build your own front end, you'd have to do all of that kind of legwork yourself. So it's a really powerful kind of option to have that stuff built in. The problem is that when you start to talk about these kinds of things with certain kinds of people, you get an objection that comes up. And I think it's not an unreasonable objection as such. And Clifton again touched on it this morning, which is why is this system doing all of these things? Shouldn't we be breaking this out a bit? Isn't it a bit dangerous to have these things in one place? I would say essentially there is a trade-off. Microservices are great and there are microservices in this architecture that are outside of the scope of what Drupal is doing. But the idea that you should break everything into microservices straightaway, make that your first priority, I think, is in this state. I think you can learn from what needs to be a microservice and what doesn't. And I think one of the things that Drupal is really, really good at is it just gives you this integrated solution. So if you've got APIs going out to the mobile clients that gives them listings of content and then you say, I want to add ratings. I want to allow people to rate that content. I want to allow people to say, out of five, how good did I think this was? In Drupal, that's the voting API module and the five-star module. And almost straightaway, those fields are available to the views. They start appearing in your JSON data. They start, you know, they can appear in your UI really, really easily. And you've done almost no kind of development effort at that point. Whereas if you start to think about doing this as a set of different microservices, you're going to have to do a lot of legwork to get to that point. And I think when you're doing product development, you don't want to put in a lot of that effort if you don't know if people are going to use it. So Drupal makes it really easy to kind of put stuff out there into the product where people can start interacting with it. I'm going to come on to that issue now, actually. This is kind of the timeline of how BBC Store was developed. So began work in late 2014. A couple of months before I came onto the project, I think. And the goal was really to get this to the point, well, we can start the trial. The trial was the bit where you actually start putting it in front of real users. You observe, is anybody going to buy anything? You know, what do they find good? What do they find bad? What do they like? And I could say with a reasonable degree of confidence that there was no way to have hit those dates without using Drupal, because it just gave you so many pieces of the jigsaw all at once that enabled you to stand up something that people could use. And some of the bits that went out in that original version weren't very rough and needed to be refactored later, but it enabled you to get the user experience out there so that people could start interacting with it and you can start learning from it. By June 2015, we moved out of the trial phase into the private beta phase, at which point you start to get real money transactions going through the system. So people are actually buying real stuff, real credit cards. Then I moved onto an applicant beta phase so that people could actually apply to join and take part. And then launch in November of last year. So all told, around about a year from starting development. But if you think about it, probably two-thirds of that time is actually spent with a publicly accessible version of the site running that people could interact with, that people could try out. And that meant that we could do things like re-factoring the purchase flow when we discovered that people were finding that confusing. And that we could optimize some of the stuff like the migration routines that I mentioned before. Originally I think that it could take up to 30 or 40 minutes for something to appear on the site. By the end it was generally two or three minutes, maximum of 10. And most of that time was how long did it take Akamai to purge the cache. By way of technical remarks, I think there were a few areas of the build that I think were particularly interesting. These aren't necessarily the bits that went well or went badly, but just the things that I think were particularly interesting. One was personalization. And this is a really live topic I think for Drupal at the moment. So this is a Drupal 7 site. One of the things that I didn't go to the presentation this morning, but there was a presentation about BigPipe or BankPipe, as it was described. And what BigPipe does is that enables you to serve the non-personalized portion of a page first and then can stream the personalized bits to the browser after that initial page load has taken place. Drupal 7, you don't have that capability. So as you're browsing around the site, you're going to see a whole bunch of things for sale. If you've already bought that, it should say play me, rather than buy me. And the way that we actually achieved this was basically using JavaScript. So the entire site, in terms of the catalog pages, is completely cached. The purchase flow, the account management areas, the playback areas, they're not cached. But the catalog basically is. And we found that was a reasonable compromise between performance and technical elegance and kind of maintaining the cacheability of the content, which was really important. I'm very much looking forward to Drupal 8 and to BigPipe to see what we can do differently there, because I think rather than having to build our own solution for querying the back-end APIs out of JavaScript and updating the bits of the page, it would be really nice if that was actually integrated directly into Drupal. Frontend JavaScript was also an interesting experience. I imagine this is something that a lot of people have been through, but we went through quite a number of significant JavaScript pre-factors before we got to launch. The thing started out as very much an AngularJS project by the end. It was a backbone project with a tiny little bit of AngularJS, I think left somewhere. Meanwhile, I was advocating for React the whole time and nobody listened to me, but this was a really kind of interesting example of, at times, it felt like refactoring for refactoring sake and trying out new technology for trying out new technology sake. But where we got to at the end is we realized we didn't need that much JavaScript. We needed it to do some very specific jobs. Backbone was fine. It's really really simple. It's easy to understand. It doesn't take over your whole approach to how you build your pages and all of those kinds of things. I think that's interesting in the context of the conversation about decoupling Drupal and how we're going to build frontend frameworks that work well with Drupal. What we found was actually keeping it quite minimal and having the frontend framework not make too many assumptions about what Drupal was going to do and not have Drupal make too many assumptions about what the frontend framework needs was actually the right way to go for us. I'd be really interested to talk to anybody who has a different experience and how they maybe had more of an enjoyable experience with something like Angular, which really does try to take over the whole thing. We also had feature plaques, which again, this is something that was mentioned in the keynote early today. Our feature plaques enabled us to do much more of a continuous delivery style deployment. Everybody's familiar with the idea that in Drupal you can turn a module on and off and you can set configuration variables. What we did with feature plaques was we basically kind of, as a principle, we kind of said, just deploying the code should not cause or certainly should not always cause new functionality to become available. If we wanted to add a new payment method, let's say we wanted to add PayPal as a payment method. We want to be able to push that code out. We want to know that that code's there, that all of the kind of deployments that related to that have been done, but we might not want to turn it on on a Friday afternoon. We might want to wait until Monday morning. That might be because there's a marketing activity associated with it. It might be an email needs to go out at that time, whatever it is. By using feature plaques, we were able to decouple the deployment of a feature from the release of a feature. That actually worked really well on several occasions. What we probably should have done, what we didn't do, was release any of that as open source, but I think that's something that should come out in the future really. Finally, the thing that I found really interesting, which almost nobody else will, was the rights management aspect of this. It's such a really, really interesting, really, really complicated data modeling thing that Drupal really helped with. In order to know whether or not a piece of content is available to buy, you need to know its license window, between what dates is this content actually available. You need to know it's an availability window, which is between which types of people are actually allowed to buy it, and does it have any valid products attached to it, and is it available on the CDN, and has anybody revoked this because it contains music that we don't have rights to, or it contains a reference to something that maybe is illegal, or has been a subject of court case, or whatever it might be, how much of a reason why something might need to be removed. Drupal actually really shone with this, because it enables you to manage those interrelations between content, such that a change on this episode ripples all the way up. If you can't buy that episode, you also can't buy the series that contains that episode, and you can't buy the collection that contains that series, so Drupal kind of really helped this out there, and again, I can't quite imagine the pain that would have been involved in trying to build something like that from scratch, so it's, well I can't imagine it, but I don't like it. So I think that hopefully, I'm not sure if I've rushed through this or not, I've been drinking this coffee which is a little faster than I wanted, but that basically gives you, I think, an overview of why we did what we did, why the UC wanted to use Drupal, some of the choices that we made in the course of doing that, and I'm conscious that this is the pre-lunch slot, and that if I overrun on time I'm going to be keeping people away from their lunches, and I was going to leave some time for questions, so I'm going to stop there, and if anybody would like to ask some questions, now is the time, I will take no offense if anybody would rather get to the front of the lunch queue. No, the short answer is, so the question was, is the payment actually done using Drupal commerce, and the brief answer is no. It was a very custom checkout workflow, a lot of the things that Drupal commerce would give you would be things like a shopping cart, which just isn't relevant in the context of one-off digital products, and as it happened, the payment provider that had been selected was not one that had a pre-existing Drupal commerce integration, so it was easier to just build a custom integration at that point. Okay, so the question is, how was the team scaled internally within the BBC? So I was a consultant to this project, so I wasn't running it, so I may be wrong about some of this, but essentially it kind of goes back to what I was talking about in the community slide, that there were actually different kind, different companies involved at different stages, so Hackware were involved very much early on, and they provided the hosting platform, and they're kind of bootstrapping the whole thing, and getting the initial direction set. We were involved kind of shortly afterwards to kind of provide more kind of architecture and a bit more, some more engineering capabilities in there as well, and in particular, my experience is working on similar products in the past, ITV and so on. The way that that scaled was pretty typical, I think you begin, I think with a heavy emphasis on contractors over time, that then transitioned into permanent staff coming on board, so by the end of, by the time it launched, I think there was four permanent developers on the team. A lot of that work was done by Alan McKenzie, actually who's the chief, who was the chief group of architect of BBC Worldwide, and he was here, I'm sure you've been seeing him if you were here last year, he was here very much in recruitment mode, trying to hire the people who eventually did join, so I think that's how they went about kind of scaring that team. There is too hiring, there is too hiring. Well, they are still, they're still hiring, so I think it's not, it's not my, it's not my job to be here as a recruiter for the BBC, but definitely I'm sure there's people here who will be able to point you in the direction. Yeah. You touched on the rights mentioned, was that a module again or how it helps you with that? So that was a module, it was a custom module, which basically would, on modification of a node, so using node hooks, it would basically look at what data had changed on that node if it was relevant to the rights management aspect, so if the is revoked flag had been set on an episode, that means something's changed, and it would then work out which products are affected and update, essentially update all of the affected products for that change, so it's kind of really using Drupal's node system and hook system to manage that. So in terms of contributed modules that were used in this project, did the BBC contribute? There were, there were definitely patches contributed back, I don't think there were any whole modules contributed, but there were definitely patches, I definitely contributed. To be honest, so the question is which of the major contributed modules were used, to be honest it's the ones you would expect, it's views, it's search API, it's work bench, showing all the first kind of things, panels as well, was in the mix. Thank you, thank you. In regards to feature flags, do you have any issues around the creep of that as in where you're getting multiple feature flags going on, or when you want something this late and maybe you want to change the date on you have that in the more states of that sound, around the same feature but slightly more configuration? So the question is, with relation to feature flags, did we find that we had a problem with having too many feature flags or just that kind of creeping into the point where you've got so many different options for configuring how feature works that it becomes difficult to manage? Basically what we did was we would have regular calls of feature flags, so if a feature flag was on in production, you don't need that anymore. At that point, once the feature is on and live in production and maybe you give it a week or so to be sure that you're not going to take it off again, you can pretty safely remove that feature flag, so it's not intended to be a system for configuring the site once it's live, it's to allow you to deploy the code without the feature and automatically activate it. Do you find on the feature flag that you certainly need to have things in sync with the app store because the amount of leads hanging on to the app store, is it useful for that? Not in my experience, so the question is did we have a problem keeping feature flags in sync with the app store, or in sync with the features in the app? I never encountered that. I could imagine how that could be a problem, but again I think part of the things, one of the things you might want to do is actually roll the feature out on the web behind the feature flag, try it out on the web and then find out if anybody really wants to use it, before you go ahead and build the matching mobile app feature and so on and so forth, so I used the example before ratings and reviews, you know if you wanted to push out ratings and reviews, you might be better off just doing that on the web, and if you discover that everybody's giving everything two-star reviews and it's a real disaster and you don't want that, or you discover that nobody uses it at all, then you've actually saved yourself a lot of money because you haven't built the mobile app versions at that point and you can just say, actually it's a bad idea, let's not do it, and turn the feature flag off, and it disappears again. The tool is that the data is coming from the tracking system, they migrate our content to users, the content data to the target and actually using the report for content to be seen. Yeah, so what we had on a given node, there would be a set of fields that would be essentially mastered by this back-end system, this would include images, it might include the synopsis text, certainly include the price, but for some fields we basically had a second field which would come out of the override field, so you'd have the image override fields, so if you had specified an image override in Drupal that image would take precedence over the image that had come out of the back-end system, and we used field formatters, so that was essentially transparent to the theme layer, so it would pick the right image from the node and use that, and again I think we did the same thing in views as well, so it would just pick the right image, use the override image wherever possible. Anyone else? Cool, thank you very much. I don't know if they can help you Ah, I've been here. How do you know? It must be possible. It is. Cutting glasses. It's great to have you here. Thanks for asking me this. We have a good meeting. We're having someone come up here so you can all come talk to me. Hello. Why is that with a fracar with one of those images? I'm retreating like mad. The last one I've said I was a type of speaker. I'm trying to stay away from the fracar. Yeah, I don't know. It was cool in here when I came in and it filled up with people. I mistakenly left my jacket on. Can you believe it? It's been a great deal of meetings. So far. It's been a very long time. That should face me. It's a good system. Hey. Now I'm going to be so hard on the coffee. And you're going to have that. Did you breathe cold when I came in? I left my jacket on because I thought it was cold. It's lovely. And yeah, I don't think it's going to turn up. I don't know. I should remain by myself. Yeah, it'd be much easier for them to remember. Yeah. I probably... I haven't got any cold. No, I haven't got any. I went through in that gear. One, two, three, four, five. Two, three, four, five. Have you... You can't go to the jungle at all. No, I haven't seen that. He's over there. Oh, there it is. I haven't seen it. I haven't seen it. I haven't seen it. I didn't go into the traumatic memories. I haven't seen it. People don't need to know, all right? No. It's like a swamp. You know what I'm saying? A swamp is so serene and peaceful, but under the surface, they're paddling away on my muscles. Yeah. All right, I'll be all right. I'll be right back. I'm sorry. Yeah. Yes. Yeah. I didn't see that. I did see that. I didn't see that. I didn't see that. I did see that. I did see that. I think that was both of ourups. Yeah. So, what's the future? And I thought, shut up, we're talking about... I think the option to go out and do the house of it. I don't know. I don't understand. I don't understand. OK, so you can talk about... You can talk about... We're really... Like, when the point is... Ah! Yeah, yeah. You see, you're really... I didn't see that. I think you have to breathe. You must take a wash. You just can't... You're like, I can't... I'm not going to take that overshoot. It's going to take time. You going to... We know these are all problems. We're going to give us solutions. There's more problems. If we go off, by the BBC's infrastructure, by the BBC's team, by the BBC's work and... We'll be all right, OK. I've been mentioned talking to them a lot. This project has been shot, I didn't have a lot of time to do it, but I did have a bit of a go at it. It was a radical and basic style project. No, it was not a, it was not a, it was a, it was a small, it was a small thing. So, I don't know if it's nice as well. I don't know if it can happen. So, I'll look at all sorts of things. Well, can it go, can it feel like the time has passed or... It might be. I think when you're on a film, you look back on it. Do you want to think? Yes. That's the problem. I can just stop there. Yeah. There was, like, two crazy, like, great try-downs. Yeah. What about you? I don't know. I don't know. The old school has stuck up all the things that were called estimates for entry and there's a solid. There's a solid table. But wait, when you say it out loud, it's just completely insane. We add together all the estimates of stuff that we don't know enough about, and we're not going to do that yet. And then we figure that out. But then it comes out that how many times have you stacked all your estimates together? You actually did all those things that you estimated. And they also, the time that you showed your estimates is there for you to deliver everything on board at full time. And you put out any scope. We asked Kit. He made you wait on it twice. Yeah. Did you do anything like that? I know what I was going to talk about. I'm not doing anything like that. We had a conversation about it. Yeah. It's helpful. I mean, whenever I was into this, it's about how many times have you stacked all your estimates together? It's about how many times have you stacked all your estimates together? It's about how many times have you stacked all your estimates together? I wouldn't want that to come to Alan's. He gets a little bit of that. It's not that he does. And whenever I say this to you, what do you want to touch base on? I might say that conductor. So you're saying you're in exactly the same situation you were last year? I don't remember last time. We asked Alan to do that. I don't know if it's time now. I don't know if it's time now. I don't know if he has the option to do anything like that. Oh, no. The difference this time to the last year is that people might let all these things go. I don't know if you, I don't know if you're going to be able to do that. I don't know if that is the difference. You get to go like junior and junior and junior and junior and junior and junior. It's opposed to this time of year. That's where it's been set the goal of value. And it's like, do you want to progress on it? Right. I was late, and then I was going to go to the area where we were going. I was going to go to the area where we were going. And then I was going to go to the area where we were going. Nothing, nothing more than that. I was going to go to the area where I was going. Nothing worked. You're the first person I met who asked me to work with. Well, it's kind of been this time. It's amazing how they have the best of all the knowledge. I was trying to get it. I was trying to get it. It's good as far as the base. And then I was like, do you deny our project managers? True. Do you know what I'm saying? Do you know what I'm saying? What, yeah. We can't just make it. I can't just go there but not on the front side. I can't just go there. I can't just go there. I can't just go there. I can't just go there. I can't just go there. Do you know what I'm saying? No, I don't. I don't. I don't. So you got a team, and then she's programmed a few things? And then you got somebody that level? We're going to find out all the data we have about the cops. Look, there's two don't believe any QA. The guys who use cops are bloody wonderful. Who ran off from the event meals. Which was? Of course that's something you go by selling on sale. You've got to take each one out of the hell out of them. If he actually gets to very old school, very risk of us, he probably can sell them all.