 era so Drupal 8 is a meta project comprised of a lot of pieces that our friends have helped us out with and we wanted to give you a taste of this paradigm so there's a lot of soft stuff about what PHP figures what the intention is we're sort of focusing this relationship a little bit through the lens of the PHP framework interoperability group and Campbell has a few technical examples of why this ends up making our lives easier and better why we can make more of a difference and so on so the concept of the six-hour session is that we have done up to this point seven or eight interviews with prominent PHP people of project maintainers sort of what would you call Beth Long you know PHP journalists developer person and we've got a bunch more coming so I guess radar session please if you think it's worth anything there's a series of podcasts that I'm releasing so we're thinking of this session as a kind of an ongoing conversation showing you how we learn what we learned what we discovered and it would be great if you could come and listen to those I've got the URL coming up in a second but this is like gonna be an ongoing relationship I guess and you can contact us ask questions we can produce new material and we're definitely submitting this for the next couple triple concept we're gonna let it grow and we're doing newer interviews so that's kind of the ad for the overall concept this is cam I'm jam a damn is doing another session so I have a wonderful title and a really really nice job and I'll be evangelist in developer relations and it's my privilege actually to try and connect you with materials that will help your day as a developer be better I produce podcasts I do interviews I try and find out what's going on I try and you know find the companies that are doing smart things and help them get those ideas surface those my sphere of action I do a lot of a lot of Drupal on there when I get some time I put slides on I'm Campbell Tessie I also have a great title in a really wonderful job with form one actually the second half of my title I think it's probably hiding a picture now as of halfway through last year I'm technical architect comma evangelist you know really yeah yeah so my job in a nutshell and I'm the developer on a bunch of large project teams I specialize in big sites and community sites for positions and then on the evangelism side I come and do conferences and I do talks and like I mentioned on stage the pre-note to me the community aspect of Drupal is one of the USP is one of the really key aspects of this community and that makes our product so you can send me emails directly Campbell form one dot com you can find me on D dot oh that's over the huge vanity but on Twitter some jerk took that name before I got to it so I'm Campbell Tessie and yeah right so as we said all of the interviews that we're doing to prepare this are being posted online there's one with Larry Garfield already up today one is coming out before no Mitchell and in the next few weeks like I said they're going to be at least six more possibly seven or eight or an infinite number of or we'll see how that goes hey so meet the PHP framework interoperability group a few years ago a bunch of people got together in PHP and I said hey so we're incredibly siloed we've got this problem that you know I'm a Drupal developer your PHP BB developer you're a symphony developer your Zen developer and all none of and the community was quite fractured wasn't talking much and we were certainly as we were a big part of this problem and they said hey like so in PHP 5.3 we got namespacing that means I can bring in variables with the same name like I can have a day class you can have a day class and we can still make them play nice together well hey presto why that wasn't in 5.0 Larry you'll have to explain later it's actually wonderful that we have you this we put you on the spot oh yeah periodic but as soon as we get something wrong we're dead in the water so and I'm a vet called PHP tech in 2010 nine see a bunch of people said hey so we've got this next thing what if we can auto load all the stuff that we need in together there was this auto loading standard created and a group they call themselves the PHP standards and everybody hated them and because they say who are you to make a standard whatever they got really quiet for a while but this auto loading turned out to be really useful so today it's a group of several dozen project leads or not only frameworks but also projects like Composer and a bunch of other things who are working together to define the new era that we're in so the interoperability area in PHP the reason that Drupal 8 can use symphony components and external libraries like Guzzle is because of these standards because these efforts to become interoperable and I can also say that the result is in the last few years all of a sudden there are universal PHP events that people coming together in places like PHP world where you have a Drupal track and a June the track and a Magento track and universal interesting topics for everybody and people are really really excited to be in PHP now many more people are saying hey I'm a PHP so that's kind of the headspace that we'd like to migrate you into we are now part of the broadest fraction in PHP and we're incredibly relevant and people are incredibly excited to have you know 37,000 new brains helping out with the hard problems and we get stuff in return like all of the symphony framework taking care of some of our problems for us as a commodity security etc so why should you care as a developer well frankly it makes your day way way way easier with some of the magic some of the external libraries and the things that we've gotten along the way for free while I find the audio cable that we forgot about again say something small all right so I'm gonna make a personal confession way back before PHP fig I had a library of WordPress jokes and Juma jokes did anybody else make fun of the other frameworks like I did so fans who feels a little bit guilty about being a jerk about that thank you because they're the they're not making any moves so we should change into it aggressively so I have some very very quick sound bites to show you as we go through the presentation from different people that we've spoken with when in our going learning about PHP fig and this context that we're in so these are really really short basically sort of saying hi but these are teasers as well for the podcast that are coming out of the next few weeks and the first one is with my great friend Lorna Mitchell who is a great PHP trainer and consultant she writes a lot of materials she and I have done a few things together she was the person who actually introduced me to the PSR standards in a blog post called PSR what and as I said this you will be able to find later today on dev.arquilla.com such a good user and I am super excited to see Drupal in being just so much part of PHP these days I've been to some Drupal cards and seeing the recently Drupal 8 makes me very very very happy so have a great Drupal card and I will see you around that event or as you can see. So I just want to say if you see the name Lorna Mitchell on any piece of media it's worth reading and she has been to a bunch of Drupal cards so look out for her at some community event at some point. What's really exciting for us as developers in this is that all of a sudden our community has grown and we have people who traditionally feel like oh they couldn't really touch Drupal it's too much in its own universe and now they actually care now we call them up and do a web and do a podcast interview with them and they say oh I'm so happy to hear about the release of Drupal 8 you've contributed so much to what I do of course twice per set so the way that actually works right HPFake is more than just a nice looking website and some people that are friendly to talk to they get together and define standards of PSR's and the standard behaviors are all optional just because you're a PHP fake member project doesn't mean you have to do all of them but it means you are encouraged and of course the more you adopt the more interoperable your code will be that is the more benefit your code gets from everybody else out there in the community so Drupal 8 does not adopt all of the PSR's thanks yeah in fact it involves very few but it's probably because we were planning it really early in the PSR lifetime yeah how many PSR's were there five years ago so first of all Jam what PSR's does Drupal 8 adopt I would say on a hunch PSR 3 PSR 4 and PSR 8 that's a very good hunch I typed the so PSR 3 is a logging standard it defines how you should interact with your with your logging my basically to log our interface that's one of the first ones that we got into PSR 4 is the auto loader Jam mentioned that before effectively it's a way to have a single call to load a library that has a ton of dependencies and you don't have to worry about any of it you actually can just write your class quite easily and get all of the components that you need when I was talking about Drupal contributing to the broader PHP world sincerely the proposed PSR 8 standard is is is part of that for me and it's exporting Drupal's culture of hugs as an interface standard so PSR 8 is the huggable interface and I truly I honestly truly believe that our community and our community spirit is the most important and the strongest thing that we have and I think it's incredibly cool that Larry who is Drupal's high representative to the PHP fake group has proposed that and and I want to see it adopted I think it's really awesome so some people think it's a joke but I think it's actually a really really beautiful contribution Larry never jokes about hugs talk about the rest here for a second so what PSR is does Drupal 8 not adopt well you know the really baseline ones that everybody always adopts the coding standard and the coding style somehow we didn't quite get there but I think frankly it comes down to the fact that for us two spaces is the run to one true way right and the PSR's have are completely diluted and have said that it's tab so we're pulling out as somebody said that we should know what do they say force oh my god somebody yeah somebody came over and said that we should switch to four spaces but don't worry we burned the heretic so that's PSR one and two actually we're very close to PSR one there are some details that we don't adopt but fundamentally we already have a really well-written clearly defined coding style guide that actually most community members tend to follow and it's a lot of work to switch coding standards to all of a sudden even let's say without having to retrain 37,000 Drupal developers all over the world to press space four times that just can't do it it's very hard even without the training problem let's just any volunteers to go through the Drupal code base right and reformat the whole thing yeah we too we talked about that with Larry right so we're sticking with our own coding standards and we'll see if that if that ever graduate if that changes in the future it is a bit tricky to have separate settings in your IDE PSR five has not been officially ratified yet and it's a documentation standard so we have really good documentation I think that we could actually look to the symphony community to see how great documentation is done but in the meantime PSR five is not official we don't have it anyway Larry's last bit of work was the caching standard which is PSR six and that was only finished a couple months ago way too late for Drupal eight and since then oh no and just before that PSR seven was adopted which is the HTTP messaging interface and a couple of projects out there are already adopting it and we can use it through symphony and a wrapper but we don't have it in core and PSR seven is actually amazing really interesting and one of the interviews that's going to be coming is with a guy called Beau Simonson who is the maintainer of Sculpin and also the editor so the maintainer the person running the PSR seven initiative I think he just left coordinator I think he just left them but he got that through and basically it's a message response protocol that lets us put that through any number of applications and get it back in one piece in a standardized way so it's it's it's going to be a boon for modular application design and how we big build larger applications going forward it's it's a really neat it's a paradox if it's cool. So Larry Krelva Krab is our official representative to PHP Fib. Sorry for this. I don't want to speak to PHP from Drupal and I want to speak to Drupal from PHP because that implies that those are different things that aren't part of each other or that I'm part of one talking to the other and that's not the point the point is that Drupal and PHP are not separate entities. Drupal is part of the PHP world and the PHP world is part of Drupal and that collaboration has helped us produce Drupal 8 and that collaboration can and should continue to produce not just future versions of Drupal but better practices more robust practices in PHP itself so I would encourage everyone from these two large robust communities don't look them as two large robust communities look them as different pockets of one larger community that we can all learn from that we can all benefit from and together we can build a better PHP for all projects. So what Larry touched on when you start thinking about yourself as a PHP developer as a part of a much larger global community that includes a bunch of different projects you start to realize that PHP Fib is about much more than just standards which specific standards do we adopt what PSRs do we like what we don't it's actually about a different architectural mindset different architectural choices when you're building your projects when you're building your own custom modules the two rules that I really try and keep in mind myself first of all never reinvent the wheel we don't have to do that anymore and the second is make it easy to to use your work in other projects outside of Drupal make your work as much as possible libraries that can be exported and reused. So a great example of this in the new paradigm is the PHP libraries that commerce guys are making for commerce to they're making straight-up PHP libraries and then a Drupal implementation but any other PHP project can go and write their implementation for that as well. Let's see. Bama Shusek is the Symphony framework representative to PHP FIG. We had a knock-down drag-out fantastic conversation with him and kind of forgot to get him to do a proper southern bite but he's a he's a big name in symphony really really interesting guy lives in Austria and we're going to be talking about his project Pooley as well. So this is Bernhardt, it's only a couple seconds. So hello Drupal community, I'm Bernhardt and I'm an architect for Web Mozart on Twitter. Welcome to the day. Sorry, so that's Web Mozart. Let's talk about the work that he's doing, the work that he's built on. Right, well so symphony is a really good example of how we're implementing those two rules that I mentioned. Drupal egg threw out a lot of reinvented wheels and for good reason. While we were on the island we did our own, we had used our, we made everything our own way, our own unique snowflakes and we weren't going to touch how anybody else did it. So my first favorite example of that is I think everybody's favorite function that hit on Drupal HTTP request. Right, can I get a show of hands? Who has ever been frustrated by this function? How many of you people are not coders? Because I don't know if I've ever met a Drupalist who hasn't been frustrated. Yeah, that's all. It's, well, so this is the artist's rendition of Drupal HTTP request. We built it back at 4.6, 2004, I think, five, thank you. At the height of proudly invented here, Mania. So Drupal HTTP request. Not invented elsewhere. Not invented elsewhere. It's 304 lines in one function and it recurses. So enjoy debugging it. For testing, we talk about keeping functions simple nowadays in contemporary code practices. There are actually ways to quantify how complicated your function or your class is. And one of the really common ones is called N-path complexity. And in short, it's a measure of how many unique ways there are to run your function and how many unique outputs it has. So it actually can grow exponentially. So you want to keep this number as low as possible. The guideline that I was taught is that if your N-path complexity is over 200, it's too complicated and it's going to be awful to maintain. Does anybody want to guess what the N-path, not you guys who know this off the top of your head. Does anybody want to guess what the N-path complexity is for Drupal HTTP request? I'm going to start picking people. Pick a number. Higher. 1,000. He said 1,000. Do I hear 2,000? For you bet 4,000 in the back. Way higher, you guys are nowhere near. 10,000. That's a good start. You need more zeros. Who wants to offer more? One lakh. One lakh. That's a big number. I don't remember how to translate that into Western numbers. It's 100,000. One lakh. Way more. Who gives me 10 lakhs? What was that? One million. Good try, sir. Good try. We're still in, we need more zeros. So tell me in Indian numbers, how many is 25 billion? Right. How many crore would lack is that? 250 crore? Okay, that's the N-path complexity of this beautiful thing. So if you wanted to test this to completion and every test of yours takes half a second to run, it will take 400 years to run your tests. That's why it took so long to get Drupal. No. So we replaced this old ridiculously complex and rusty wheel with guzzle. This is like the slickest motorcycle picture I could find. It's awesome. Yeah, so guzzle is the super slick, super futuristic motorcycle of HTTP request libraries. Actually, the HTTP standard is quite a complicated one. There's lots of people that attack this space. Guzzle is the one we chose because it has a lot of features in particular. But what we really care about, it's environment agnostic. It doesn't matter if you have curl. It doesn't matter if you've got PHP streams available or whatever is going on in your environment. You're running on the moon in Windows 95 environment. I bet that guzzle can actually operate. It handles synchronous and asynchronous requests, which actually, I still have never wrapped my mind around asynchronousity in PHP properly. It's a bit of a mind-blower for me, but guzzle does this out of the box. It will handle, for me, the headache with Drupal HTTP request was very often working with cookies. It works with cookies totally transparently, and you can have shared cookies across the whole site, or you can have specific cookies for the one request, and it is so easy. Yeah, so easy my mother could do it. I had to think if she would be offended by that. She considers her a power user of her Windows tablet. But actually, I think the coolest power feature, and I know it's not the only one, but this is the one that I get the most excited about, who here has ever implemented an API integration layer, REST API integration. Yeah, almost all of us. Right, so to do a REST API integration with guzzle, you describe the API in a JSON file. This is the end point. If you're using this path, here are the properties that you can assign. This is what you should expect back in a JSON file, and guzzle creates a class for you. It does the API integration for you. That's like days of work off your shoulders. How many lines of code does that save me for every integration? Like 300, right? 304, many more than 304 lines of code. And of course, we get it for free because open source is awesome like that. So actually, because I'm excited about this, this is an example of the JSON that you use to describe your API integration. If you can write this and say, okay, get products is HTTP get, and this is the URI, and this is the response class that we should get. If you can write that, you can do an API integration. I can't believe I didn't get a hand for that. I'm so stoked. Can we just get a hand for that? Thank you, guzzle. Thank you, guzzle. So the other one that I like is PHP template. Who here has been frustrated by PHP template in the past? Drupal steaming system. Yeah, we have a lot of themers here. So we wrote this in 2004, Adrian Russo. At the time, the whole concept of the templating engine was relatively new. There were a bunch of people taking stabs at it in different projects. It was not unusual that we decided to do it on our own. And it compared really favorably to some of the other things that we saw come up in that time. In some ways, PHP template is too simple, right? You could put any PHP you like into a template file. No problem, right? Has anybody else here ever seen direct SQL queries in a template file? So the best, the best... The camera needs to catch some of these rows of hands. So the best template file that I ever saw was 28,000 lines of code. It contained the entire site logic in the template for the front page of the site. And the client was wondering why the front page took 30 seconds on a code tag. I think a little part of me just died. Right. It's too simple. Template files often have a lot of redundancy, a lot of redundant HTML. If you have three content types that differ in a minor way, you have three template files that are 99% identical. That's nuts. And it's actually really hard to then document what are the actual differences that we care about. In other ways, PHP template is too complicated, right? We split the process of creating HTML between files in modules and files in the theme. I have definitely spent long periods of time trying to figure out where the hook theme implementation is coming from, where this particular HTML is getting built. We also tried to create a DOM, an HTML DOM that would work for every use case. Dom's for all the... or devs for all the people of my kingdom. And every class that you could imagine. Yeah, it's part of why I'm not a themeer anymore. It's pretty horrendous. And even the fact that PHP template required understanding of PHP turned out to be problematic. At the time, we thought, oh, this is good. You have to use... No PHP to use Drupal. Well, it turns out a lot of themeers don't. They use more specialized languages. So we've replaced it with Twig, famously enough. So Twig is a much simpler templating engine to use. And it can handle a lot more complexity at the same time. And it's externally developed to maintain. So template files can extend each other. This is my personal favorite thing. If you have three content types that differ in a minor way, you have one base template that applies to all of your content types. And then you have three other little templates that say extends, base, and this is the only difference that you need to care about. Fewer lines of code to maintain, a lot easier to figure out what's going on. All of the logic involved in rendering HTML can now be contained in the theme. That doesn't mean that we allow you to run absolutely any code in the template, quite the opposite. It's a modern templating language, so you can do things like for loops, you can do things like conditionals. But you sure can't query the database and cannot run arbitrary PHP code. So you can outsource your theming now very, very easily and openly without really worrying about your theme or white-screening your whole site, compromising your server. It's a very, very secure implementation. As long as you leave the database access, right? Unfortunately, it lets you do like, you know, the bad judgment module should make sure that there's a dependency. Yeah, Adam's favorite, our colleague Adam, who is there in the pre-known with us, who is a theme or his favorite part is it always used to be so crazy trying to figure out in PHP template, I have a variable. Is it a string? Is it an object? Is it an array? Who knows? We're going to guess and we're going to white-screen the site while we do it. Right? In Tweet, you can actually traverse arrays and objects and strings without destroying your website. So another interview that we did along the way was with a guy called Jordy Bojano, who is an incredibly compelling, hilarious public speaker. If you ever get the chance to see him do a presentation, do that. Very soft-spoken Belgian guy who is essentially, well in my view, because he's the maintainer of Composer, he's 50% of the reason why we're even able to have Drupal 8 and this whole interoperability era. Composer is a huge big deal. He's also the coordinator of the PSR3 logging standard and he happens to run the most popular PHP login solution, which is called monologue. There is a Drupal 8 integration of that now created by my friends in Italy, Wellnet. Worth checking out if you want more detail, more interesting, more useful logs than what Drupal is giving out in the box right now. So we spoke with Jordy. Okay. All right. Let's do the presidential address. Okay. So, hi. I'm Jordy Bojano. I maintain Composer, monologue and a few other libraries that you might end up using. I want to welcome you in the broader PHP community and hope that you will eventually use some of my projects and contribute back to that. Right. So who here has used Composer before? Okay. So we don't really need to explain what Composer is. I'm just going to skip right over that. I had a real problem with this section of the presentation. I was supposed to demonstrate for you integrating external libraries through Composer and the problem that I have is that it's actually too easy to be worth a demo. I found that the parts that I would be I would be demonstrating were just Drupal API actually, you know, where do you book this particular behavior in? So instead, we're just going to do it through a series of slides. Here's the process. Step one, download and install Composer Manager. There are, well, Composer needs a single list of all the libraries that you use in your project, all the packages you use in your project, not just the ones your module uses, not just the one other modules use, but also the ones that core use, all has core uses, all have to be compiled into one big list. There are very good ways to manage this by hand, but if you are all interested in this slide, it means you should probably be using this module. Composer Manager makes it a lot easier. Installation instructions are easy, enable the module as usual, and run one shell command. You're done. Step two, look for the functionality you want at packages.org. That's the repository for every project that Composer knows about. Looking for which package you want to use feels a lot to me like looking for the Drupal module that I wanted to use in 4, 5, 6, 7. Luckily, they tell you right here up front how many stars it has, how many downloads it has. Again, it's how popular the project is that helps you figure out how supportive it is. Step three, type Composer Require into your terminal. You do it in your module directory, so it creates a composer.json file in your module, and it updates the list of required libraries for your module automatically. One thing that I keep forgetting is to do minus, minus no update. Otherwise, it will actually download the library into your module, and you don't need that. We'll do that globally. Step four is tell Composer to update your installed libraries, and that's it, end of demonstration. Just go ahead and use the library. It doesn't matter how complicated it is, it's all there for you. One of my favorite demos that I tried to make was actually the AWS package that lets you do everything with Amazon web services, from spinning up instances to a stream wrapper for S3. I threw together S3 file system module for Drupal 8. Didn't get finished testing it. It's not worth contributing, but the ease with which I got through that complicated part, how do I actually connect to S3? How do I actually create a stream wrapper that makes sense? It was amazing. Right, and all of packages functionality is now available to you in your site too. So when you code with Composer, you stop spending time writing functionality. You only have to write the Drupal integration steps. For the real mindblower, of course Drupal itself, Drupal 8 itself, can be installed with Composer. So can all of your Drupal modules. We have our own Drupal packages. So a lot of people recommend that you don't commit core or contribute modules. You actually just commit your Composer.JSON and have your continuous deployment or continuous integration service put it all together for you at runtime for a deployment time. So Puli, has anybody here used Puli yet? Okay. So this is Bernhard Schuess' new project. Right. Puli is pretty hot stuff, I think. It's a sort of Composer plus tool that's getting really popular. As Drupalists, we're all familiar with the dilemma of code versus configuration, that there are certain things that are at the very least in a gray area for how you should get them into your repository. How do you actually store them and move them between environments? Puli makes that a bit of a bigger problem to solve and is interested in not just configuration, like YAML files, but also anything that's not non-code. Images, CSS files, what have your translation files is one of their big examples. The deal is, if I maintain a package, there are probably some non-code elements with it that I want to include. If JAN wants to use it in Drupal, Drupal is going to want those non-code elements in probably a different direction, probably a different location, in whatever unique environment JAN has set up. If somebody else wants to use it in, not wordpress, give me another, thank you, if somebody else wants to use it in Zend, their whole architecture is different again. What they want to do with those non-code assets is different. Puli is a way that a package maintainer can write a map for those files so that when you want to use them in Drupal, you can map those to the right locations and the code in the package can figure out where it should be putting those non-code elements. And in June, Bernhard is doing a full Puli demonstration on my podcast. Yeah, heads up. So, keep an eye open. I expect we're going to see Puli used more and more in Drupal because it makes it easier to get at and use some of those packages and projects. So Beth Tucker Long has been doing PHP for a long, long time. She used to work for the PHP architect magazine. She's incredibly smart, incredibly capable. And as a consultant, she ends up working on a lot of legacy projects. And the podcast with her that we're going to release is super, super interesting because she gets this whole other perspective that I wasn't even cognizant of when we were thinking about, hey, build this cool new thing and Puli and Drupal aid and cutting edge and we're all right on time. She's like, I inherit all this old stuff and it's really hard and I have to deal with all the ways that we figured out are now wrong. And I really, really like her perspective on how the PSRs will help her job get easier over time. But as things get standardized, it's really, really worth checking out. Hello, Drupal. My name is Beth Tucker Long and I am so excited that Drupal eight is out way to go. We're very proud of you. And I am really excited about Drupal eight because it represents so much community involvement working together. I'm so excited that we have so many big projects from the PHP side of things and the Drupal side of things working together. And I just can't wait to see with all this brainpower that we have merged into this project where we go from here. So listen. I think part of the reason that I think Beth is interesting is because I think she is an example of what most freelancers and most of us who are PHP developers have to deal with if you actually have to jump between frameworks all the time and somebody comes to you and says, oh, do you know Drupal? Sure, I can figure it out. No problem. Do you know Drupal? Yeah, okay, I can work that out. We wrote this other thing in full stack. Can you integrate it please? You have to be able to jump between frameworks really easily. What Beth talks about is that PHP fake makes it easy to do that. You understand and you know a lot of the tools already and even if you don't know the specific tool, you know the interface that it implements, you know the basic rules of how to work with it. So for example, if you can theme for Drupal eight, you learn twig. Sculpin uses twig. It's a site generator like Jenkins. It just happens to use twig as a templating engine. You can just jump right in. There are lots of other applications that are built on Symphony 2, way too many to mention. Is that the next slide? Well, so let's give it, so to get an idea of, look, if you're a great Drupal 7 developer, for one awesome and you're super employable for another decade at least, but your skills are really, really specialized and a bit hard to transfer to do another work. As a great Drupal 8 developer, knowing Guzzle, knowing the Symphony components that we've got here, knowing the object or entire architecture to spend with dependency injection and so on, actually, you're incredibly enabled to work not just in Drupal, please stay with us, but to do a lot of other things, to help out a lot of other places and to be very, very quickly on board and up to speed with whatever gets thrown at you. So here are just the projects that Symphony lists as the major projects using Symphony framework components. Drupal PHPP, Laravel, Symphony full stack, easy published community startups, Drupal Composable Gender, and so on. B-hat is really, really interesting. Sub-doctrin, really, really, really interesting list, but that's not the full list of the projects using the Symphony framework components. This is enough to start several of your own companies and, like, have a great life. This is cool. And you know, plus, minus, how these work once you're comfortable with Drupal 8. Plus, most of those with a web front-end are going to be using Tweak as their templating engine since it's also maintained by Sensio Labs who maintain Symphony. So, you know, you're really, really in a great place. And... PHPUnit, another one of my favorite things. Yeah. Who here has used PHPUnit? Let's get a round of applause. Only if you've used PHPUnit. Clap for me. Just give me a little bit. Has PHPUnit saved you time? Yes. Yes, I like the applause way. Actually, it's nice. We had a wonderful conversation with Sebastian Bergmann, who is the main trainer of PHPUnit. This is the testing structure, testing system that is used by a lot of PHP projects now, including in especially Drupal 8. We should just jump right to his video clip. Okay. So, hi. I'm Sebastian Bergmann. About 15 years ago, I created PHPUnit to help PHP developers build better software. I'm happy that, well, I would like to congratulate the community on the release of Drupal 8. And as far as I know, PHPUnit played some role in it. Some role. Thank you. Thanks very much. Good. So, testing economically is a huge money saver. And as a developer, we can test before we commit to our main release. And, you know, we do our colleagues a favor. We do ourselves a favor. It's a time saver. It's a work saver. Make sure you and your company are doing testing as part of, you know, your workflows. It's fantastic. And, oh, and once you're familiar with PHPUnit, well, it works in Drupal 8. It works in most every IDE that you'll be using. It's useful for anything that's written in PHP. So, it's an incredibly useful transferable skill again. Okay. Now, so, here we are. Welcome to Drupal 8. Welcome to the new world of PHP. I want to call out a fun little thing that's been going on. This interoperability movement, this idea that Drupal 8 was coming prompted a friend of ours to put out a challenge a few years ago. Who ever read that blog post, Getting off the Island in 2013? No? 2013. Yeah. Getting off the island in 2013. This guy had this crazy idea that because Drupal was in the future going to be more relevant to other parts of PHP, that we should, like, go to a user group meeting or a convention of another. Wait, without making fun of them? Without making, like, respectfully, not to throw them. So, Larry Garfield wrote this post, and it made huge waves across the PHP community. It was picked up, of course, in Drupal a lot. So, you can read that post. It's still great. It's still made this way. So, his first choice was Get off your island. Go see what other people are doing. There's all kinds of amazing stuff going on. In 2015, I believe early in 2015, he made a second challenge which was Build a Bridge. And that was, wait a minute, I'm blanking on what the challenge was. Oh, sorry. Wow. Okay. It's a little hot now. So, the second challenge was Build something with another project. You know, don't do it in Drupal. Go do it with Sculpt and go do it with Symphony full-theco. So, and when we were having our podcast conversation with Larry, like, okay, Larry, what's the third challenge? It's a new year now. And he was like, I know. Give back. Make a difference. So, this year, Larry's challenge to all of us in PHP is to get your name on the contributors list for another project. Please don't neglect to help out with Drupal 8, right? But, go make a difference. Go see what's going on out there. They're incredibly wonderful, interesting people throughout the PHP world. There's a lot of real excitement going on. We are more relevant than ever, and we are making a huge difference to other communities as they are helping us. I'd like you, I believe that's the last interview piece for today, and we're well on time. I'd like you to meet my very good friend, Cal Evans, PHP troublemaker. Hi, Drupal. My name is Cal Evans, and I'm a member of the PHP community, and we are so excited that Drupal is now, the Drupal community is now helping us learn the lessons that you learned in Drupal 8. Okay, one more. Hi, Drupal. My name is Cal Evans, and I am Larry Garfield's nemesis, and I want you to understand that if you see him, please rip off his desk. I've got a $100 reward that I'll give anybody that'll mail me this. Enjoy Drupal. Hi, Drupal. My name is Cal Evans, and as a member of the PHP community, I want to say thank you for all that you've done for the PHP community. The patches that you have submitted as you were creating Drupal 8 have spread far and wide and are helping all of us. So thank you so much for that. And on behalf of all of Drupal, thank you PHP community for all you've done for us, and all of the wonderful technologies that we've been able to integrate into this thing we're calling Drupal 8. So thank you so much for coming and listening to us today. Thank you so much for being here, making a difference, being part of our community. As I said, all of these interviews that we've done so far and a bunch more, Geherme Blanco's coming, the maintainer of Doctrine, Bo Simon's and the maintainer of Sculpin, all these people you saw today. So I'm going to be on my podcast, dev.acme.com side podcast. Please, if you liked our session, rate it here. If you didn't like our session, find another one to rate. Thank you very much. Thank you very much. Did we forget something? Yes. What is the interoperability situation in other languages besides PHP? With Drupal cooperating or other languages doing the same kind of stuff that PHP is doing? I don't think so. There's talk of doing more with the JavaScript, but the JavaScript community is extraordinarily fragmented. I have no idea what's going on there. Beyond that, there are other languages that are doing cool stuff, but since Drupal doesn't use those languages, we're not really paying much attention. The closest thing that I would say to that happening is all of us moving towards standards as a language. So for example, JavaScript interoperability, the biggest thing that we could have done is make sure that everything is restful. We worked very hard to make Drupal, thank you, restful. We've worked very hard to make it easy to use a front-end framework, a JavaScript front-end framework, on top of Drupal. But yeah, as far as I know, there's not a formal movement to make that happen. Yeah, I wanted to get on the same line of interoperability so you can connect Drupal to a lot of things. There's a lot of efforts going into both rest and real X web services and GraphQL and those kind of things where you can make Drupal appear like it's a CouchDB database or make Drupal appear like it's exposing all these data structures similar to how Facebook does. So in terms of interoperability, there's a lot of efforts going on with Drupal, then you can connect it to whatever other technology you want. Any plan to change database at NoSQL? I'm sorry, any plans for changing the database? Because you think of scalability. Yeah, to use things like NoSQL. So actually with Drupal 7, we introduced a reasonably robust database abstraction layer so technically you can put any data source behind it. There are some logistical complexities when you do something that has actually fundamentally different assumptions like NoSQL. So the NoSQL implementations for Drupal 7 tend to be only for specific areas of it. So for example the entity API you can do things with, but big chunks of core you can't, you still need a MySQL database. In Drupal 8 that's supposed to be a lot easier and now I'm going to ask Larry to tell me that I'm right. The database abstraction layer in 7 and 8 is for just SQL databases, please don't try to put a non-SQL database behind it. That said in Drupal 8 you should never be writing your own SQL anyway. You should be using entity API, you should be using the config system, you should be using the key value store, and all of those could be swapped out for other backends. I know that Chex has demoed Drupal 8 running with purely MongoDB already, so it can be done and you can do it piecemeal depending on what part of the system you're talking about and what part it's going to make sense for. That's it, don't discount SQL, it's actually a lot more powerful than people get the credit for and a lot faster than people get the credit for. Other questions? I like that we've had this third speaking partner here. All right, well thank you guys very much for coming. I hope you have a great con, thank you for hosting us here and we'll see you around.