 Hello everyone, we are already five minutes ahead behind. So I think let's just go ahead and get started. There's some flickering and I think we'll just, I guess we can manage, let's just get started. I know it's just, this is the last session of the day and I'm guessing how many of you are here planning to hit the beach right after this? Is this fine by the way? This flickering, I'm guessing it's not hurting anyone, is that okay? Yeah, let's go ahead. So thank you all for coming and thank you for waiting. We are about, like I said, about four minutes late but I think this is going to be not an hour anyway. We should be done fairly quick and I mean, I'm of course hoping that this would be more of a discussion as well but let's see where this goes. So I'm Hussain Abbas, I come here from Bangalore, India. I work as a technical architect for Accelerant. It's a company based mostly in India. We are a remote working team. I love photography, traveling, well, that's why I'm here. This is my second Drupalcon, by the way, it feels, I'm really excited to speak here, be here with all of you. And I'm also a Drupalite co-contributor. I try to contribute the best I can. I was planning to tell my own story over here, how I started exploring programming in general. PHP in particular, I've had about 15 years of experience with PHP now. And let's see, I'm hoping I can drop the history of PHP and why that is relevant to PHP fake and particularly to Drupal today. I'm hoping to move along that story and hopefully that explains things better. So I started, like I said, I started programming in around 97 with PHP around 2001. And mostly it was small websites as a volunteer. I was what, 15, I guess 16 then, I don't remember. But yeah, I started with small websites. I wrote a simple website for my community which where the content was stored in a file, I mean a bunch of files, not a database even. So it was, you could say it was a content system. There was no management built into it. It was just a bunch of files and you would go edit the files and it would be reflect on the website. The point I'm making here is that I have always tried to do things in a reusable way. Okay, I did not want to, I could have written a bunch of HTML files. I knew HTML since five years before then. But that was not what I wanted to do. I wanted to make that, the template reusable. Basically now when we talk about separating the theme from your database, this is something like what I did over then, except for database, I had files. And I tried my best to separate with what knowledge I had then. And well, given the history of, well history is not the correct word, but given the situation in India, there were not a lot of open source communities over there. So I didn't even really bother with open source at that time. I mean, 2001, there were not a lot of CMSs out there. I mean of course Drupal was there but you won't hear of it back there in India. And in the components I wrote, I did not bother with open sourcing them either. Just a second. Yeah, so there was, I guess I could say that there was never a framework to open source this components. PHP has always had a reputation of being a hacky language. Easy to learn, fine. But write a script and you're done, okay? And you don't bother about clean code. I mean, you don't have to bother about clean code. That's what makes PHP easy to learn, right? You just get into it. You don't focus on how somebody else might use this component. You don't really think about that. You would think that fine, I'm going to be maintaining this, I'll know. And six months later, you realize that you don't. Of course, I couldn't keep that up, right? About five years down when I started freelancing, I recognize these limitations, that it is not possible to keep writing my own components. It got tricky. I wrote a bunch of active record components. I'm guessing everyone has done this over here, writing active record components, writing our own CMSs. I built maybe tens of different CMSs for different purposes. It would have been a no-brainer to reuse them, but they just didn't exist a mechanism over there. I never came across one such. Anyway, around 2006, 2007, I started exploring around what could I do better and found, I came across Drupal, and well, I didn't really notice it all that much yet. At that time, I still had an attitude that whatever a framework or a CMS can do, I can do that myself. Why bother using something? It was, I guess, mostly a trust issue that I'd rather build something on my own rather than use something with something else as written. I can't even imagine how those days were. Anyway, I jumped into a bunch of different frameworks and CMSs then, you know, Code Igniter, Kohana, WordPress, Magento, Drupal. Drupal at the end, really, and once I started working with Drupal, I kind of stuck there. I mean, as long as I was freelancing, I was still focused on WordPress, Drupal, Code Igniter, Kohana, all these frameworks, these were my strengths back then, but I could never get something which I wrote for Drupal, get it to work in WordPress. That still is the situation today. You can't write in a Drupal module, can you put it in WordPress? No, you can't. Same goes for Code Igniter, Kohana. Kohana is, by the way, a fork from Code Igniter, but still, they're different now. And that situation prompted me to kind of give it all up, you know, move on, you know, move away from the PHP, and I was looking at Python, Ruby, maybe, you know, any of these. And then, they came an assignment for building a site in Drupal. It was a fairly simple site, but I struggled with it back then. I think it was Drupal 5, and eventually I built that site in Drupal 6, and then immediately I fell in love with it. I realized everything we talk about in the clean code, and how Drupal can be extended, how nicely modules are separated from each other, you know, you don't even have to hack code. You can almost always find a way to maintain your workflow without going into the core. Okay, even if you have to, you know, I mean, we still use a patch-based workflow, so that's fine, it's not, it was not critically bad. I mean, it was totally a code which I could get on board with. And later, you know, in more of my exploration, I just came across hooks, but that's more of a side note here, you know, hooks. I didn't really relish the idea of hooks, you know, magic naming methods, all that. But fine, you know, I mean, I just took this as another Drupalism. You know, we have a lot of Drupalisms in Drupal 6, 7. Fine, you know, I lived with it, moved on. Well, at the same time, I mean, while all this happened, PHP 5 came out. And it had better object-oriented programming support. There were really subtle changes, but most of those changes meant that you could not, you had to change your PHP 4 application. And the major changes came in the form of namespaces with PHP 5.3. Now, your code could actually organize your code better. How many of you remember, you know, writing prefixes to your class names or function names? We still do that in Drupal, by the way, right? You know, I'm writing a custom module, example module, example underscore init. That's very, we are so used to it now that we don't even probably notice it. But namespaces was designed to solve this very particular problem. At the same time, the overall attitude of the PHP community started changing in terms of its reusing capabilities. You know, earlier, reuse was encouraged, of course. You know, when nobody ever said reuse is bad, but the attitude was always that, okay, you know, I mean, okay, I found a snippet of code somewhere, I'll pull it into my project somehow. Maybe copy paste, you know, or maybe just bring the bunch of files and, you know, hope that it works. You know, if the classes are prefixed and there are no class name collisions, you know what I'm talking about, right? Suppose if you have a class called Database, you're using a third-party library with a class called Database, you're done for. You can't have any of the class called Database in your application anymore. Well, of course, nobody did all this back then. And then the attitude started changing. People started to actively encourage using third-party libraries, third-party code. And with that came support for tools, tools such as Composer that helps you bring components from third-party components into your code, makes it very, very simple, makes it that simple. You know, you just write Composer, require the component name, and you're done. So I guess what we, you know, I mean, we could all call this a phase of PHP Renaissance. And this was basically made possible with the introduction of PHP FAKE. So FAKE stands for framework interoperability group. These are basically a group of developers, you know, framework developers, the big frameworks, symphonies, and those kind of developers. Developers, I'm sorry, the developers on those projects. And many other PHP developers, they got together and they started figuring out how do we make code, maybe, you know, something which was written for Zen framework, I'm sorry. How can we make that work with symphony? Right, so this happened about, what, six years back? And they came up with a mechanism of standards. I mean, it's a simple solution, right? So define standards. The first problem everyone faced was reusing classes. Of course, you know, by that time, everyone was onboard object-oriented programming. So that was the first problem to tackle autoloading. So I think, yeah. So autoloading, forgive me if you already know what autoloading is, but I'll just give a brief overview. So say you have it, you're dividing your code into different files. Of course, you know, Drupal has a bunch of files already. You have hundreds of files in Drupal 7, thousands in Drupal 8. So at any point in your code, you're going to request a particular class. How is it going to find where the class is? PHP has to load that particular file. Now, of course, the traditional solution was to require each and every file that you needed. You just call require once in the beginning of your file and everyone did that. But as your code base keeps getting larger, it's not practical to do that anymore. You would have hundreds of lines just with require once. So of course, the solution was autoloading and this has been around for a long time in form of SPL autoloader. How many of you are aware of SPL autoloader? SPL autoload register, right? Yeah, so basically the standard works on top of this, on top of this SPL autoloader and it just defines that the naming conventions you need to follow if you want your classes to be autoload-able. So they came up with PSS0 at first, which basically said, there are a lot of nitty-gritty details, but basically said that your namespace would be converted into directory structure. So if you're, like you've seen that image over there, if your directory structure is modules slash books slash SRC slash book manager, so your namespace would be modules, backslash, book, backslash source, SRC, backslash book manager. Well, of course, that's not the case here and that is where PSR0 comes in. PSR0 basically translates a path of this. So actually, yeah, this is actually a wrong image. This is more of PSR4, but PSR0 is deprecated anyway. PSR0 had very minute problems apart from DX developer experience problems. So if you have been working with Drupal since over a year or so, you'd probably recognize the image on the left side, which where each module would have a lib directory and under that, you would have to have a directory called Drupal and again, under Drupal, you would have a directory with the same name as your module. That was the convention and these directors do not have anything else except, I mean, you would always follow the structure. Lib would only have one directory called Drupal and Drupal directory would have only one directory called with the name of module. Under that, you would have your classes and with this, you would be able to follow your outloading, the PSR outloader. So anything under this class would, anything, I'm sorry, anything under this directory would fall under Drupal, backslash, book, namespace. PSR 4 made it a little simpler and it basically translated the directory parts into what you see on the right side. Now, instead of having lib slash Drupal slash book, you just have an SRC directory under that, you would place all your PHP files and they're still mapped to the namespace Drupal backslash book. So you would have code like this in all of your classes. This is basically how every class in Drupal 8 looks right now. So you would start with the namespace declaration, of course, that's Drupal backslash module name and then the class name. And you can keep on nesting these directories, nesting these namespaces and the PSR 4 outloader does that, takes care of outloading these classes from the proper location. And that's where Composer comes in. Composer is a dependency manager which also contains an outloader. It contains a PSR 0 outloader, which like I said is deprecated and also a PSR 4 outloader which we use basically. In Drupal, it's completely PSR 4. I don't think we use PSR 0 anymore at all. I'm guessing some of the third party components we use are continuing to use PSR 0. I'm not very sure of that. But that's the beauty of it. The third party components are completely isolated from the system. We don't have to worry about that anymore. They work in their own directory structure, they're in the vendor. And you would just worry about your own code. We also, Drupal also uses another standard recommendation called PSR 3. This basically defines a logger implementation. So it's a typical use case. An application needs to log events. Of course, in Drupal you have the dblog, you have syslog. And whenever if you're writing a module and you want to log something, you would call the watchdog method and it does the job. It's a very, very typical requirement. And in Drupal the most common ones like I said are dblog and syslog. But of course there are lots and lots of loggers out there. Suppose you want to write log to New Relic or something, I can't think of any of the names right now. That's funny. But basically now with this common logger interface your code does not have to worry about which logging implementation is relevant. So in Drupal model development you would call watchdog. And you wouldn't worry if it's going to dblog or syslog or both. Whichever module is enabled, that takes over and logs in the appropriate place. But of course, suppose you want to write a New Relic logger, you would now have to write a module for New Relic. And of course that's possible. But the PHP community is larger than Drupal community obviously, right? So why not directly take components from there? So if someone has contributed a New Relic logger, you would just be able to pull that in with Composer and your application does not change a bit. Maybe the services, you just have to configure that instead of using the dblogger or the syslog, I'm going to use the New Relic logger and all the calls remain the same. You're programming into the interface, the logger interface you see on the top. Like you see both syslog and dblog inherit from that. So you don't worry about if you're using syslog or dblog, you're just going to target logger interface and it can be any logging implementation. So yeah, let's see what, of course, I think the slides order has been messed up, I'm not sure, I guess that's my mistake. Yeah, but a lot of other PSRs, and some of them are in work, I think six are published, PSR 0, 1, 2, 3, 4, and seven. And there are many others which are in works right now. We have PSR 5, if I'm not wrong, that's the caching implementation and six, okay, yeah, thank you. So PSR 6 is the caching implementation that's close to being reviewed, yeah. And that's another target for Drupal, I believe that once that comes through, we'll use it for our own classes. I don't know, is it a target for Drupal 8 anymore? I'm not really sure, not at this point, right? Okay, yeah, so, well, but the option is always open, once the PSR 6 is finalized, we just have to use it and we are open to a much more bigger world of caching interfaces. Seven, PSR 7 deals with HTTP messages, which was I think the most recently published PSR, and that basically makes all your HTTP requests, HTTP request, response, although handling, it makes it uniform, so you remember Drupal HTTP request? I hope I'm saying the function name right. It's such a long time I've used it, I forgot the name, but that was replaced by with Guzzle long time back and we have since upgraded to Guzzle 6, which is a PSR 7 compliant tool, and we also have the same PSR 7 bridge with symphony, which basically makes all of our HTTP handling uniform across the code. So if there's another HTTP 7 compatible library you want to use, you just have to bring it in, that's it, and your code does not have to change anymore. Yeah, and we, like I said, PSR 6, and I guess I'm not sure how many PSRs are being worked upon, Larry might know. Yeah, dog walks here, that's right. Okay. Yeah, so yeah, to PSR 12, and of course the numbers, I guess that's the first impression everyone has that numbers carry a special meaning, they don't, they just a sequence of standards that came out, the next standard that gets proposed and reviewed gets the PSR 13, that's right. Okay, so let's talk about the benefits. We already, of course, spoke about all the benefits that this is going to carry in, so just to summarize, we can talk to any of the loggers that are out there with implementing PSR 3, any of the HTTP clients out there that implement PSR 7, so we basically increase of basically collaborating and reusing components from other developers. What that means to Drupal is that we are not maintaining this code anymore, this function which I spoke about earlier, the one which we, which was, which did the same thing as it basically, Drupal HTTP request, that particular function had a reputation of being the most untested function possible, it was around 300 plus lines and it had the highest cyclomatic complexity in the entire code base, that's completely gone with introduction of Gazel, so this and many other such examples, you know, for example, dependency injection we are using symphony, even dispatch of using symphonies, we are using RSS capabilities from Zen and so many other such components where the code is already out there, we don't have to maintain that anymore, we don't have to reinvent the wheel, that's one of the benefits, then there is very another interesting technology, well component called stack, which allows you to basically introduce middlewares into your HTTP request processing, I guess it'll probably be a little out of scope to discuss that further here, but you can look it up, we are using that as well to introduce middlewares, middleware approach and this basically helps performance, bottom line is that we, with this, we are maintaining less and less of code and we are, at the same time, we are, the application that we build is much more tested, much more reliable because of the simple fact that it has been tested by many more eyes than just the Drupal community, it's a bigger PHP community out there, all these components, all these libraries are much more heavily tested everywhere else and you can be sure of that, we don't have to worry about that anymore and the Drupal community can focus on being what makes Drupal Drupal, we just focus on business logic of our parts and we don't have to worry about others, of course and it translates, all these benefits translate to you, the sites that you build, the sites that you maintain, you don't have to worry about as much code as you had to, the modules you would write for Drupal 8, for example, would, by this, would by extension be much more clean, cleaner, it would be more testable, more maintainable, the benefits are driven to you. Any questions at this point? That was it, thank you. If you have any questions you can, of course you can find me, you can tweet to me at that handle and please do provide feedback for this session and any other, all other sessions at DrupalCon, you can directly access it with mode ID 2446 or you can just do a search. Thank you, thank you everyone.