 So, who am I? You've heard a brief introduction, but my name is Michael Cullen. That's my Twitter handle. I am on the management team of a forum software called PHP v, which I imagine quite a few of you have heard of. I also founded a PHP user group, and I am the secretary of the PHP fig. I'm a Brit, and I'm sure most of you have heard we have had quite a few problems recently with this thing called Brexit. And as such, I have a book called Very British Problems. My Twitter handle, if you want to tweet any feedback and stuff like that, that would be great. I'm going to be up here, so I'll be defenseless for the next half an hour, 40 minutes or so, so if you have any unconstructive feedback, then now is definitely the time. But you don't care about any of that, except for maybe this bit, because you're here for me to talk about the fig, right? But first I'm going to talk about a little bit of history. 1994, not much happened, actually. It was a pretty boring year. I looked through Wikipedia, and I looked at different things that happened in 1994, and there were three things of note that I could find. One is quite a big deal. Nelson Mandela was inaugurated as the president of South Africa. China got the internet, obviously not in the kind of form that we might have in the Western world, and it's still subject to censorship, but it gained the internet. And Harry Styles and Justin Bieber were born. That was literally all I could find in this year, and I wanted to make my slide look symmetrical and find a third thing. Something else happened in 1994, though, something that has affected every single person in this room. Does anyone know who this gentleman here is? It's not Justin Bieber. His name is Rasmus Ladoff, and he wanted a way to be able to track the number of visitors to his CV, so he created what would later become known as PHP. Little did he know the kind of effect that it would have on his CV, not just being able to track visitors, but in terms of creating a huge, what has become PHP today. In 1998, these two people, Steve and Andy, they were at uni, and they were trying to write me commerce solution, not Magento. Magento is not quite that old. And they discovered bugs in PHP itself. And as a result, they said to their university professor, if we fix some bugs in PHP core, could we get some credit for that? And they said yes. So they started working on PHP core, and PHP 3 was released in June of 1998. This was kind of around the same time that PHP lib became a thing. Does anyone in here use PHP lib? Nobody. Fantastic. This was basically the first PHP framework. It wasn't quite a framework in the way we think of symphonies and framework today. And the last time I did this talk, I think there was one gentleman in the, about 300 people that had used it. So it's not quite as common, but essentially it was a symphony of its day, I guess. In 1999, symphony went from having 100,000 PHP installs to 350,000 PHP installs. That was seen as breathtaking. That was seen as an amazing number. And that kind of growth was unseen in this kind of thing. And people were like, PHP, this could be a big deal. The web could be a big deal. So people started doing things like writing books about it. This is the first ever published PHP book. There was another book that was released very around similar time, but this is widely regarded as first. There was the first PHP conference, PHP Congress, which I believe held in Germany. This is not the American Congress I might add, because it has a PHP flag. Also, there's a little PHP thing here, and it says, you can't read this, but it says in PHP we trust, instead of in God we trust. Credit to Frank Dijon for some lovely image editing there. Pear, who's used Pear? Awesome, a lot more of you. Pear is also something as a relic of this time. It's slightly less commonly used now. This is a tweet by someone you might have met this morning. It's slightly less well used now. But this was a big thing back then. This was their main package repository for PHP. And they also helped define a whole lot of things like coding standards and that kind of thing. Going forward into 2000, the Zend engine was created. We were really impressed that PHP 7 had a 2.4 speed increase. When PHP 4 came out with the Zend engine, it could be recorded having up to 100 times speed increase. Let me let that sink in 100 times faster. That's just ridiculous. PHP 4 is a big deal. The Zend engine was a creation of Zend, the name of the company. I mentioned Andy and Zeve earlier. It's actually their names put together. Zeddy from Zeve and Andy from the end of Andy's name. They created this company and therefore the Zend engine. If we move to 1999, 2000, we're also starting to see big PHP projects come about. PHP Nuke. Who's used PHP Nuke? Quite a few of you. It's not so much of a thing now, but it was like 10 years ago, I guess. PHP is still a thing now and I'm going to hold to that. Lots and lots of projects were starting to come about. Drupal came back in 2000, WordPress in 2003, Symphony 2005 along with Joomla, and Zend Framework came back in 2006. And that's great, like all of these projects bringing up in the PHP ecosystem, bringing it to where we are today. But we ended up with all of these little mini ecosystems. So Symphony had its own ecosystem with Twig, Swift-Maila, Doctrine, and associated with those projects were a series of companies like KNP Labs and Sensio Labs. In the same way, the WordPress had its own ecosystem form around it with companies like Automatic and Human Made. They took in other companies like Gravitar. Around Laravel, you've got a whole series of projects like Blade and Lumen, I think, is their micro framework. Drupal, Zend Framework, exactly the same kind of thing. And you have these little ecosystems sort of splintering off from each other. Meanwhile, PHP user groups and conferences were starting to also become a lot more popular as a lot more PHP developers did it professionally. Companies would pay for them to go to conferences and like this one here. And you would end up with all of these little mini ecosystems related to a particular location. So the PHP Singapore community, which seems to be a thriving community and it's fun to see so many of you. But you know, community in London, community in New York, or the states if you want to think of it as a wider area. And there was a lack of centralization. There was no central PHP community body. Some of these ecosystems do have their own centralizations, like WordPress has its own centralized community ecosystem where they handle things and organize work camps, et cetera. We also didn't really have much dependency management. Dependency management wasn't really a thing in PHP properly until other things which I'll talk about in a minute. There was no primary package repository. And yes, there were parent PHP classes, but I'll talk about them in a minute. But they didn't really make your life easy. They went easy to use in the way you might want. And this made it hard to include libraries. You would have conflicts without classes and namespaces. So for example, Joomla and PHP both have a global called user. So you couldn't actually integrate them and share any of the same code because this user global would cause problems in the same way that you might have a function called session start or the like. I mentioned PHP classes. PHP classes was a great way for people to be able to share their code, but it had a quality problem and it had a distribution problem. I'm not going to talk too much about PHP classes because I don't want to accidentally advertise them. Basically, you don't really touch PHP classes anymore. But I mean, the aim was good. People could put their code on there and other people could reuse it. So try not to reinvent the wheel. So we had all of these different packages that had their own ecosystems, our own conferences, and all of this just led to a divided community. And a friend of mine, Larry Garfield, came up with this phrase, or he reused it, I'm not sure, of getting off the island. And the idea of this is that each different project, each different ecosystem community is its own island. So word process is an island. By the way, can I just say this? It's like a really nice island and I wouldn't mind being this island. PHP to me is its own island. Joomla, Symphony, even companies like Google, and you. You're your own island. All of those scripts that you've created that you then use every time you create a new application. If you created your own little micro framework, which a lot of us used to do back in PHP 4 days, it would be the sort of starter set of files that we'd use when we went to start a new application. But that's okay. Like, it's cool being your own island. People liked rolling their own and the PHP ecosystem supported this because the PHP was all about you can do your thing. It's a language built on need and we have a lot of hobbyist developers. Put your hand up, actually, if you consider yourself more of a hobbyist than a professional PHP developer, just out of curiosity. Okay, it's quite a few of you, including some of you who do it professionally as well. So people like rolling their own and the thing is that that low barrier to entry meant it actually essentially brought the PHP community to where it is today. Being able to roll your own and being able to have this very individualistic language was really important to PHP's development. But recently, we've been breaking the mold. One mind on its own can be absolutely amazing. Fabien Potentier, who is a man who I admire greatly, he's brought, for example, a whole load of stuff from other languages into PHP and made them popular, for lack of a better word. Dependency injection containers, event dispatches. These kinds of things weren't very well used in the PHP ecosystem until Fabien, as a main person, started bringing these things to PHP, which is really awesome. So he had lots of awesome ideas. But with two people, you can come up with even more awesome ideas, right? Because you have double the amount of ideas, except for I disagree with that. I think you get more than just those two people's ideas. I think you have all of these extra ideas that can come from that back and forth between people and those people working together. You can produce more than either of them could, both on their own. If you've got PHP to be working on an authentication system and you have WordPress working on an authentication system, then together, then each individually, they have great ideas about their own authentication systems. But if they're working together, then they can share that knowledge. And instead of just having the combined knowledge of the two authentication systems, they can produce something that's a lot more reusable, something that would apply to more use cases than just PHP or WordPress. Or perhaps find better ways of doing things that they're doing already. We started stopping reinventing the wheel. Who's heard of this term before? It's quite common. Reinventing the wheel is essentially not writing your own database abstraction layer for every single project, essentially. And PHP has come a lot better at this. And this is a variety of different ways. As David mentioned earlier, introducing object-oriented programming to PHP has been a huge step in this. It has made being able to have reusable code so much easier, particularly with namespaces in 5.3, autoloaders, et cetera. Composer and also hand-in-hand with Composer Packagist has solved the dependency problem. It's allowed us to really easily include libraries and handle dependency resolution, which is something we've not really had before. So whilst you could get a package from PHP classes, it wasn't really easy. It wasn't easy to stay up to date. Composer solves this problem for us. And Packagist provides a really great way for people to be able to share their code and then make it available to Composer. And finally, what I'm here to really talk about, the thick. At PHP tech, and this is a 2016 logo because the 2009 logo is really awful. And this is the only version of it I can find. A bunch of people came together and they sat round a table. This was a couple of months before PHP 5.3. And they sat down, representative from different frameworks, so KPHP, ZEM framework, Aura, Symphony. And they said, how can we standardize autoloading with namespaces? This would be a cool thing to standardize. So this autoloader then came out, which is then turned into PSR zero. So who's heard of PSR zero? Most of you, fantastic. So this was about May, April time. And it was fantastic. The PHP community probably for the first time had come together to standardize something across a huge variety of different projects. And look at where we end up now, like almost all of you raised your hands. From this, they then said, hey, could this work for other things, too? So they created a PHP standards mailing list on PHP.net. And then later on moved to Google groups as they became the PHP framework interoperability group. So what other things could this work for? Like coding guidelines, Pear, Symphony, Laravel, Aura, all of these projects came together. All member projects were surveyed to see what they were doing at the time. And that was then produced into PSR one and PSR two, which are common coding guidelines that you can use and it allows coding style fixes or automated scripts in your continuous integration static analysis to detect any problems with that. Ideas can now have it built in, which is wonderful. Then there was PSR three, logging. So this simply allows a whole load of different log levels on the interface, critical and exceptional exception occurred. Or we might have an emergency, like someone merging the PHP 7.1 and 7.0 and it allows for a second argument, which is context. So in this case, the user was Davey. What a shame. This allowed libraries to stop relying on monologue or specific logging libraries, but to abstract it a little bit. Doc blocks. Who uses Doc blocks? Who hates Doc blocks? Oh, wow. I'm quite surprised. Most people hate using Doc blocks, write while writing Doc blocks. They're very useful. They're not very nice to write. It takes time. So there was a PSR five, PR for request recently, which I merged and it had 34 contributors. So a huge number of people from all different kinds of projects discussing about how to do this. The work was being led by Mike van Riel, who is the lead developer of PHP documenter. He stepped down and looked at someone to take up the reins on this at the moment. PSR six, caching. So the way PSR six works is you have a cache pool, which might be redis for example, and you get cache items from it. So on the cache pool we can see if it has an item called Trump presidency, unfortunately enough. We do not have a Trump presidency, so it responded with false. You can also get an item from the cache pool. So we're going to get Paul draconis status. So we then get the item. We can then get the value of that particular thing, which in this case happens to be that he's working on his slides. As he's still working on his slides and his talk is tomorrow morning, we're going to set his status to panicking. Makes sense, right? Set the expiry date for in 24 hours time because hopefully he will not be panicking after he's done his talk. And then we can save that to the cache pool. PSR seven, HTTP messages. This is all about how HTTP messages. Requests and response objects are probably the most important things, both of which extend the message interface. So the message interface is any kind of HTTP message response and request are the most common two types. And there are a whole load of methods on this. This allows for things like middle wares to interact nicely. Could I, is Michael Hebron? Mike Heep. I think he's sleeping. In which case, Davey, do you want to come up on the stage and join me? We're just going to give a little demonstration of this latest PSR, which is the most important PSR in my opinion. It's a PSR eight. So PSR eight is the huggable interface, and it's all about how to hug people. So, Davey, I, Adam, could you please inform me to hug Davey? So he's doing this correctly. You now need to ask Davey to hug me back. There we go. And now we can form a hug. Thank you very much, Davey. So in case you hadn't worked out by now, this was an April Fools' joke. PSR eight is a slightly jokey PSR. But it is still a PSR, so it's worth mentioning. The odd thing is trying to deal with mutually hugging people, because obviously, that's what the dog block says. So I had to hug Davey, and then he immediately had to hug me back, but he had to be huggable to be for me to hug him. That's very complicated. Security. PSR nine, PSR ten, cover security different things. So PSR nine is about security advisories, so things like Sensei Lab's security checker. It's a way of organisations to publish their security advisories in a specific format, so that it can be detected by automatic checkers. And then security, PSR ten, is about security disclosure. So this is kind of designed to be an agreement between security researchers and projects to say, look, if you report a security vulnerability to us, responsible disclosure, it's kind of like guidelines setting out what responsible disclosure should mean. So if you disclose a security vulnerability to us, and then we don't do anything about it for 60 days, then you are entirely within your rights to go and tell the world about it, and you'll have followed responsible disclosure, and sort of it would also include things like we will patch this within a certain time. So neither of these two actually relate to code at all, but they do relate to the PHP ecosystem. That's being led by Michael Hess, who is the Drupal security lead. He's currently forming a new working group and reaching out to people at various different large projects. The lead was formerly Lukas Smith from Symphony, but he's had to step down due to lack of time. PSR 11, this is really simple. This is a container interface, contains two methods. Get and has. Get gets the service and has checks if whether or not the container has the service. The point of this PSR is more related to micro frameworks, where it is potential that you could have multiple containers operating around the same kind of place. I've not specifically had this problem. Apparently it does occur though. You'd have to read the PSR to find out more about the use cases. Hyperlink to PSR 13. This is quite a specific niche problem that it solves. Things with DAV projects. It's more relating to APIs and stuff. If this relates to you, then you probably know about it. If it doesn't, then you probably won't. It's not something that most of us have to worry about. I don't really, if I'm honest. Event management. I don't mean this kind of event management. He's not paying any attention. No, it's actually about the event dispatcher. Being able to dispatch events, etc. Without actually caring about what event dispatcher happens to be around. Just caring that there is one. Middleware. Who's used Middlewares to suffer for? I've had quite a few of you. Middlewares are quite a recent thing in PHP. They are a lot easier to do now that we have PSR 7 and we have a standardised object that a request or response might be. Essentially it's where an initial response object, for example, is generated and being able to interact with that and modify it before it then gets sent to the client and vice versa for a request. Whilst we were working, whilst people were working on the HTTP middleware PSR, PSR 17, HTTP factories, people discovered that actually it's kind of hard to make a PSR 7 object. So we should probably standardise a way of doing that as well. So that's PSR 17. So basically all the things. I've talked about quite a few things we're doing already. We're also looking at doing container service definitions, like your services.yaml file, things like that, but a way of actually being able to transfer that so you can have multiple different framework agnostic libraries but still being able to register services. A console component, console PSR, which would essentially be the equivalent of PSR 7 for console applications. Promises event loop. This sounds really interesting. Async is slowly becoming a much bigger thing in PHP right now. Something really exciting. Something we can hopefully sink our teeth into a bit more in the coming years. So a lot of async people, so icicle, react PHP, are currently working on an event loop PSR to then follow on to things like an event loop PSR. Hasn't gone for an entrance vote yet, but they're saying that they're working on, they're just waiting for some internal changes in the fig to happen before they look into doing that for sure. Template engines. So Zend framework, when they were actually working on an expressive, they found a common interface between plates, Zend frameworks templating engine, which I can't remember the name of, and twig, so that they could be used agnosticly, which is really cool. This is something that Matthew was looking to introduce to the fig quite soon, which is really awesome. And similarly with routing, which is routing because I'm a brick not mounting. But yeah, so a very similar thing. But it's not necessarily just about PSRs for code. Who's heard of Go PHP 5? A couple of you. Go PHP 5 was an initiative to try and get projects and hosts a like to try and upgrade to PHP 5, PHP 5 altogether. And there was some discussion about the fig, seeing if we could do a Go PHP 7 kind of thing. That seems to have fallen a little bit by the wayside. I'm not sure if it will be revived. But the fact is it's not just about PSRs. It also updates to PSRs, PSR 12, coding style with PHP 7 functionality, PSR 4, which improved auto loading. PSR 15 and 17 are kind of extensions of PSR 7. And alternatives. So PSR 16, of which the editor is Portriconis, who I think is not in the room at the moment. He'll be doing a talk tomorrow morning. So that's an alternative simple cache PSR. There's also talk of potentially like an asynchronous compatible PSR 7, which will be cool. So what actually is the fig? I've kind of talked a lot about what it's done, but I haven't actually said what it is. And because it's a really cool image, I'm going to use it twice. It's a bit like the PHP Congress. It's a bunch of representatives from different projects, member projects, coming together to discuss things. Sometimes it's likened to the United Nations of PHP. But whatever comparisons you wish to draw up between other organizations, it's essentially a bunch of people coming together to work together. It stands for the PHP framework interoperability group. There's a lot of discussion as to whether or not this title is really accurate because it's turned into more of a standards group. We have a lot more than just frameworks as members. We have packages like Joomla, PHP v, Drupal. We also have libraries like monologue and jackalope, in addition to frameworks, obviously. And we produce PHP standards recommendations. I just want to draw your attention to this last word recommendation. We're not telling you what to do. We're not telling you that you must do your caching libraries like this. We're saying this is a standard which you can follow if you like, and then you can be interoperable with other libraries that also will use a standard. You don't have to use it. That's not something we require. It's not dictating to the PHP community what to do. It's offering a standard that has been produced by a bunch of people that have expertise or projects that have relevance in that area. And the ultimate goal is interoperability, but it's not our only concern. PSR 2, PSR 9, PSR 10, and PSR 12 don't really concern interoperability. But then PSR, and I'm going to read this off my slides because it's a long list of numbers, PSR 0, 3, 4, 5, 6, 7, 11, 13, 14, 15, 16, 17 all do concern interoperability. So that's a primary concern, but it's not our only concern. But it only works if people use it, right? So PSR 3, who uses that? It's a logger interface, so monologue uses it, analog, and a project called K-logger. PSR 6 is used by a lot, now becoming quite popular project called PHP Cache. It's used by Symphony, their cache component, and Slash. And PSR 7. PSR 7, even if it's not implemented natively, it's used in a lot of framework. So Slim, same framework too, Laravel, Symphony, Drupal. I could list lots of projects that use PSR 7. It's becoming quite a big deal, and as said, not every project supports it natively, but most have a bridge for it at least. And PSR 1 and PSR 2, coding style. When I was writing my slides, I turned around to a bunch of friends and I said, can you do me a favor and just list a bunch of PHP projects? And I put them on this list until I had roughly enough to sort of even it all out. There are so many more projects that use PSR 1 and PSR 2. One of the differences between PSR 1 and PSR 2 is that PSR 1, basically everyone is using it without realizing it. One of the main things in PSR 1 is that it's actually things that affect interoperability. So for example, don't include side effects such as any set or an echo in the same file as you would include your business logic like a class. So there are actually things that affect interoperability. PSR 2 is things that don't matter, but we wanted to provide a guide for people. So one is called the basic coding standard. PSR 2 is called the coding style guide, and those words are very particular. PSR 0, basically any project on, almost every project on package issues is PSR 0, PSR 4, and as of 6 minutes past 3 today, that's 107,000 packages. So quite, quite a few. This was just, I did a reach out on Twitter and I said, guys, could you help me fill in this table of projects and add some other projects of your own with who supports PSRs? So every white space is one that's just not being filled in yet. Everything that's red is someone who doesn't support something, and everything that's green is where they do support a PSR. So basically, it looks quite green, which is my point. A lot of projects are using and adopting PSRs. And a lot of projects are part of the fake. This is just a small sample of some of the projects. You know, you've got symphony, PHP, Drupal, Buzz. Buzz don't have a logo, so I just used Buzz Lightyear. Zed Framework, symphony, composer. But it's not just about the people. This is just a small selection of people who are involved with the fake. And you don't have to just be a voting member. You can be a secretary. There's Samantha up there who will be doing keynote tomorrow, who unfortunately isn't here today. But there's a whole load of other people. Most of these up here are voting members, but some of these people aren't. I, we've got, who have we got up there? It's not a voting member. Woody Gilk, who is the editor of PSR 15 and 17, the middleware and factories, PSRs. We've also got Brian Chuck Reeves, who is editing, I believe, PSR 14 off the top of my head. So a whole load of people, and you don't have to be a member project or a lead developer of a member project to be involved. In the fixed history, we've had 58 projects as members. We've had over 70 people representing those projects. We've had four secretaries, potentially more at the end of this month for the Secretary of Elections End. We've had 16 different PSR editors. Some people have doubled up and some people have switched. We've had 35 people working on working groups of PSRs, 1,374 pull requests on various repositories, over 15,000 mailing list posts, and as of three, six minutes past three today, we have 3,198 mailing list members, which is 90 more than we had this talk two weeks ago, so I had to update the number. We get about 12 posts of the mailing list every day, and about 50 topics a month. And whilst that sounds like, and whilst when you look at it, it kind of looks like there's a lot of drama going on, I did some number crunching, and 97% of posts of the mailing list are technical, actually about PSRs, not about internal bickering or bylaws or anything like that. 97% of posts are technical, and there's a lot of work going on, but when you consider the kind of reputation that the PHP has, PHP FIG has, if you look on reddit, 350,000 PHP installs, that's what we were proud of back in 1999. That's something that everyone was like, wow, we've taken off, we've made it, 350,000 installs. That's more than a quarter of a million. Now we have millions, millions of posts. Power about 15% of the internet. 15% of the internet, that's quite large. I mean WordPress is slightly larger than that, but the fact is 15% of the internet is still a huge deal, and the fact that we can all work together is really awesome. So this is Lord Kitchener, who is from the, your country needs you posters in the UK. And I want you all to stand up from it. I'm sorry if you've got a laptop on your lap, you're very welcome to not stand up. Because everyone else stand up for a minute. This is your exercise workout for the week. So I now want you to sit down if you are the maintainer of a library that you know uses a PSR. If you're a maintainer of a library that uses a PSR, then you can sit down. Awesome. Can you now sit down if you have contributed to Symphony or Zen Framework or any one of the many projects I've mentioned if you've contributed. If you've contributed any kind of code or if you've worked with code on any of those projects. Okay. Drupal, Joomla, Laravel, anything like that? Okay. Now sit down if you have used Composer on your projects and you've had an auto loader which is PSR 0, PSR 4. The only one standing? Right. So every, you can sit down. Everyone in this room except for two people has been impacted by the PHP fig. Every single one of you, whether or not you've heard of it or done much of it, you're very welcome to go around the floor. But the fact is that a bunch of people came together with a very small but noble aim and that was to try and communicate to work a bit more. You can put your laptops back when you're not going to ask you to stand up again. Because together you can do better. I kind of like the way that phrase rolls. Ultimately, that's what the fig is kind of about. Sometimes there is drama. I'm not going to say that there isn't, but that's not what this talk is about. It's not about internal processes. Ultimately, the fig is just a bunch of people sitting around a table working out how they can work better together and how we can make PHP as a whole ecosystem a lot better and together with the fact that almost everyone in the room was sitting down and has been impacted by the fig, an organisation that was only set up six years ago, seven years ago. It's huge, I think. It's making development easier. It's helping minimise friction when you're switching between libraries or if you're trying to make multiple frameworks and applications work together. It encourages good practices, which we try and promote in the PSRs. It allows projects to communicate about other things, or collaborating on those security practices I mentioned with 9 and 10. It's not always easy, but I always say that nothing worth having ever really is. We'll keep going under one roof, bringing people from every PHP split ecosystem together for mutual benefit, because ultimately that's the way the fig works in that everyone puts in a little and everyone gets out something. PHP Fig does great work because it brings projects together, ecosystems collide, and it promotes interoperability, collaboration and good standards. And finally I'd just like to end on a quote by Henry Ford. Coming together is a beginning, keeping together is progress, and working together is success. Thank you very much. Thank you, Michael. Am I the only one in the room that doesn't have questions? If you just shout it out I can repeat it. It's fine. Hi. So from a business perspective as when you have complete interoperability between all frameworks and in general PHP what would it wouldn't make any business sense because there's a lack of differentiation. What's your take on this? So the that's the difference between being able to work work agnostic of your individual framework and the difference between the actual implementation of it. So the implementation could work very differently. It could be built to a different a different kind of performance. It could be built to sets. It could ultimately have different preferences as an end developer. We're not trying to make everything the same. We're not trying to have one common PHP framework. We're trying to be able to have it so that you can create framework agnostic widgets. So I should be able to create a logging library and I shouldn't have to care which framework I'm going to be interacting with in the same way I should be able to create a caching library that's going to be used with a specific logger. Or I should be able to create an HTTP object and be able to pass it between Joomla, WordPress and PHP v, for example, and manipulate it at different points. So it's about being able to have those frameworks work together. It's not about making them the same. It's about making some of the interfaces the same so that you can go towards a world where we have those framework agnostic widgets. All right. Thank you. Any other questions? No? Yes? I guess not. No more? Awesome. Thank you very much. If you want to chat about fixed stuff or pitch review stuff or whatever, then feel free to come find me. I will be loitering around for the rest of the conference. All right. Thank you, Michael.