 Should I just get started? All right, hi. Welcome to Navigating the PHP Community, Oscar Merida, gonna hopefully enlighten you about the landscape of the PHP community and get you out of here in time for dinner. If you're here for the API talk, that we swapped with Chris Holt yesterday, so kind of missed it, but you'll have to see it on the video. Just a quick intro to who I am. Currently, the editor of PHP Architect Magazine, I've been doing PHP since September of 2000 when PHP 4 had just come out. Did a lot of bespoke PHP development and my first Drupal project was in 4.7, in around 2007, I think, a lot of fun times. Then I got to work with Brandon, who's in the back there. We did a DC United site and Major League Soccer, a bunch of other Drupal sites since then. When I started preparing this talk, I was like, well, what do I want people to get out of this talk? There are some three key takeaways that I hope you leave the room with today. First, an understanding of PHP's history. What is PHP as a language? How did it get to where it is? How did it grow and evolve? A lay of the land for current projects. So what are the major frameworks, CMSs, tools out there that are enabling what a lot of folks refer to as a PHP Renaissance. PHP's gotten a lot of steam and energy back in the last couple of years, which has been fun to be a part of and has been brought back into Drupal. And the last thing that you should get is where to find help. I'll hopefully give you some resources where to go if you're stuck on something, if you need to look for a library, if you wanna improve your understanding of PHP programming. So we'll start with a brief history lesson. Won't dwell on it too much, but the first version of PHP was PHP slash FI. It's been around for a long time now. 1994 was when it was released. It was basically just a collection of CGI programs in C so that Brazmus Lerdorf could manage his homepage and do some formant input, take that in. From the beginning, PHP was never a designed language, right? There wasn't a formal spec first, like with some of the other languages that are popular now, Python, Ruby. Grew organically based on need. If someone needed to do X, they would add some functions, build a light integration layer with some C functions. So it was deliberately designed to just do what was needed at the time and to look like C. It's a very C-like language, very familiar if you've done C. Really quickly after that, PHP 3 was released in 1998. This is when Zeve and Andy got involved. They rewrote the parser as part of a college project that they did. This was the first version that introduced extensions. Extensions were really important to the PHP language because then it allowed anybody who knew how to write them to integrate with MySQL or Postgres or Redis, which wasn't around at the time, but that sort of extensibility was really useful. And helped PHP grow. PHP 4 was released in 2000. That's about when I started learning it. Basically, they bolted on some object-oriented programming paradigms. Basically, they were really ugly arrays with methods, if you look inside the code. They also did a lot to improve the performance between PHP 3 and 4. And what was released as PHP 4 was driven by the Zend engine, the first version. The name Zend comes from Zeve and Andy's names. They took the first two letters and the last two letters of their names and put it together. It's important to note PHP 4 was end of life in 2008. Hopefully no one's running any PHP 4 code or servers in production, though. You never know. That's kind of scary. And PHP 7 deprecates some PHP 4 functions. So if you have a really old code base, you'll need to do some work. PHP 5 was now released in July 2004. So that's going on 12 years using the Zend engine 2.0. This improved the object model, added private public, protected keywords, added interfaces. That's a lot of stuff that was heavily influenced by Java's object model. And then each dot point release after that added more useful stuff. PDO, daytime class was in 5.1. If you're still using string to time, look into the daytime class. It's really awesome for doing daytime calculations and intervals and all that sort of stuff. 5.3 introduced namespaces, late static binding and a whole bunch of other features that were beginning to plant the seeds of helping code be more componentized. Auto-loading was a lot easier with namespaces. You wouldn't have to have clashes, which was really important. 5.4 added really big performance improvements, short array syntax, which as a Drupal developer, I love, traits were added. They did a lot of work to improve the out-of-the-box security, so register globals was removed, so you didn't have stuff magically become a variable just because it came from your posts or your get requests or cookies or any of that sort of stuff. I think like the magic quote runtime stuff was removed so you wouldn't get slashes added into input unexpectedly, that little stuff. The latest version of 5 is now 5.7. 5.6 will be end of life this summer when I last looked. So if you're still running one of those versions, it's time to upgrade to a newer branch. Basically, the PHP project supports three versions, so the latest one, which is PHP 7 and the previous two, 5.7 and 5.6. Last year in November 2015, Core released PHP 7, which was a huge performance improvement. Basically, they did a lot of work to reduce memory usage, so you'll see much lower memory usage and performance just about doubled. A lot of that performance improvements comes from not having to do a lot of memory allocation and deallocation and all that sort of stuff. They added static type hints, which are huge if you wanna write code that's much more expressive and easier to test. The compiler can give you, or your ID can give you some hints about whether you're inputting stuff correctly or not, or do that translation for you. If your function expects an integer, they'll do that sort of stuff. It's largely backwards compatible. I don't wanna spend too much time going into this. I'm gonna assume, hopefully, you went and saw Larry's talk about the new PHP, or you're gonna watch it online later. There's a lot of cool stuff in PHP 7 beyond just the performance improvements. There's also no PHP 6 slide, because there was no PHP 6. When 7 was gonna come out, the community voted like what should the next number be. PHP 6 was gonna be a thing years ago, and the big undertaking in 6 was to add Unicode support for strings, but that turned out to be pretty like Big Hairy Beast. A lot of the improvements, besides that, that were worked on became PHP 5, 3, 5, 4, 5, 6 features that were back ported. That's PHP as a language. Another important thing to know about the history of PHP was Pair, the PHP extension and application repository. This was a very early effort, like early 2000s, effort to promote good classes that were well designed that could be reused to do stuff like work with databases, forms, HTTP requests, talk to LDAP servers. So some very broad applications, so very specific stuff. But it was clunky, it was hard to become a Pair contributor, but the PHP community has always been trying to encourage code reuse, encourage good coding practices from the beginning, and Pair is where a lot of that started. They also provided a Pair installer, which was kinda like Drush, kinda like Composer, where it would talk to their repositories and install packages and their dependencies for you. Pair also, not just handle PHP user land classes, but also extensions, so a lot of extensions for working with like OAuth and other databases began on their repository and could be installed through their tools. A lot of those then became bundled part of PHP's core download. My quick opinion, where do we see PHP heading here? Programming paradigms were shifting a bit more. Early PHP code was very procedural, even copy and paste code. You'd find how someone did something, you just copy and paste what they did into your script. A lot of times, very junior devs might do that, not knowing the security implications of what they were doing. Nowadays, a lot of PHP packages are very object oriented. You can download a class, a set of objects that do a set of tasks. A lot of the packages will have testing baked in, unit testing, that you can run a test suite and ensure that there's no regressions. There's no, everything works the way it was designed. Much bigger focus on security. A lot of early criticisms about PHP, even though it was so easy to build something, put a form up, get it to email your coworkers, there wasn't a lot of knowledge about how they could be attacked. Some of the early design features of the language made it easy, promoted bad security practices like register globals, the mail function, was very easy to inject mail headers and hijack a form, SQL injection by building queries out of raw strings instead of prepared statements. But those practices are not kind of in the past. And the big one part of this PHP Renaissance that I had mentioned is reuse someone else's code, let them maintain a library that you depend on, write the unit tests and all that sort of stuff, make sure it works on different versions of PHP. So you can just pull in their code, focus on your business requirements, what you're building, what you need to solve. And we've seen that with Drupal, how it's pulled in components from frame, from symphony, from Zen framework, there's some stuff in there too. It uses Guzzle to do HTTP requests and all that stuff. But that's let Drupal core focus on building a good Drupal, someone else to worry about how HTTP requests should work, fail and all that sort of good stuff. The language is also adopting new capabilities. So we saw it moved from procedural to object oriented. There's work going on to add asynchronous coding. So there's projects like React, PHP and Icicle, which let you do more event loop type stuff in PHP. They've added features for functional programming so you can create anonymous functions, use constructors to loop through collections of things. There's been a new standard added to promote usage of middleware, which is a way of handling HTTP requests and letting like a bunch of different libraries or code touch that request to turn it into a response. So very early you might have something that checks to make sure that a user is logged in and later it will decorate it to wrap a page around it and that sort of stuff. And at the end maybe convert it to JSON because that's what the client requested. All that done through middleware, which is a slightly different way of doing it than just give it a big giant PHP script or a bunch of classes to work on. A little more event oriented in a sense. And the next part of PHP's evolution is also becoming much more backend oriented. Natural progression, JavaScript is taking over the front end, everyone wants to do clients on page apps or you're doing web application or handheld mobile devices are doing native apps. But PHP can still be providing the core that can be Drupal behind it, handling data input and output via APIs and services. A lot of PHP powered, restful APIs out there and literature on how to write and design a good one. And as a result, we've seen Drupal has brought that into Drupal 8 as a native feature, rest services in core, which is huge and makes it a lot easier to handle those different clients that could be using your data. And PHP's still very strongly suited to handling web requests with session support, reading the request to the web server and then giving it some sort of response. Where have we seen PHP applications go along with this evolution of PHP as a language? There's been a divergence and it happened over the last 10 years. There was a rise of like PHP frameworks for PHP developers, writing bespoke PHP applications. There's a bunch of guys who see themselves as PHP developers, but they use a framework to help them out. Along parallel to that, there was a bunch of applications written in PHP for content managing like Drupal WordPress, Joomla, and blogging and e-commerce with Magento and there's others. If you've been around long enough, you remember PHP's Fulton Boards, PHPVB, that stuff. There were Nuke sites for a while. There'd be applications for sharing image galleries before we got Flickr and Facebook and all that sort of stuff where you could share it with stuff, with people. Content management was a very early use case for PHP. Anyone build your own CMS before, edit an employer? And it was no fun to maintain it or get traction until there was a big one. But it was real easy to build one, reuse templates for display, allow clients to log in and edit pages through some forms, put some public forms on the website for people to contact you or do some Q&A kind of stuff, whatever, with forms. There's a lot of fun with browsers because PHP was very coupled to the front end at that time. You could test an IE678, that was always a blast, right? There's still a lot of content management systems written in PHP, the top three open source ones. Drupal WordPress and Jumla, still out there going strong. WordPress is always iterating, famous for their backward compatibility, right? You can upgrade a WordPress 2.0 site all the way up to 4.2 and it should just work. That's the core goal. Jumla's done a lot of work to move a lot of their code into their own framework that they use internally and promote. And there's also a lot of other CMSs coming out of the PHP space, more newer ones, I wouldn't say modern, that try to use more object-oriented techniques from core in their core. And a lot of them are honestly kind of like, I'm gonna write something better than WordPress using object-oriented. ProcessWire is one that I've heard of. If you ever need to do static sites like Jekyll, you can do that with PHP. Sculpin is a cool tool. It'll take markdown and produce a bunch of HTML pages for you. October CMS is another one that's built with Laravel. So this is still thriving part of the PHP community and landscape and it's not really going away anytime soon, obviously. I forgot to say, if you have questions or comments, feel free to raise your hand. I don't wanna just drone on for 45 minutes. Along with the need for applications to solve very specific business cases, there was a need for frameworks. Early on development teams found they were using the same components from one project to the next so you started to build this in-house framework that you would reuse on multiple projects. And a lot of this stands from the DRY drive principle. Anyone not familiar with it? Don't repeat yourself, right? So very reduced repetition of code by bundling it into reusable functions, classes, modules. Drupal has many qualities that make it framework-like in this space, right? You can find modules that will do XYZ for you, sometimes more than one, that you have to evaluate which one might work. The first iteration of frameworks were all in one frameworks. They would do everything for you. You just use their components for handling common and uncommon application tasks. A lot of them tried to offer and mimic the rapid application development offered by Ruby on Rails, so you use Active Riker to make it really easy to write to your database. Make it real easy to write templates for your view layer and make routing easy so that this URL maps so this function in a controller, that kind of stuff. The early ones were that were popular. And if I omitted it here, it's not out of malice or anything, it's just these are the ones that I know. A lot of, had a lot of users. And some of them still do CakePHP is on version three. It's going strong. Code Igniter was another early one. Zen Framework, the first version, was this all in one thing where you would download their whole code base and learn how to write a Zen Framework app, a CakePHP app kind of stuff. Kind of as a backlash to this, there was a micro frameworks became, the pendulum swung towards that. Or there was a group of developers that moved towards this way. A lot of this was codified by Ed Finckler, if you know him, in the MicroPHP manifesto. I'm not a Zen Framework developer or Symphony or CakePHP developer. You can see echoes of this in my hopes. I'm not a Drupal developer. I know how to develop with Drupal, but I can use other PHP tools and that's part of the whole getting off the island thing. So the basic points of the manifesto is that there's a preference for writing agnostic code libraries, so they're not tied to a specific framework, which means you're not tied into how they talk to a database, how they route incoming traffic requests to a particular function. And you want to curate libraries and communities from a wider pool with fewer dependencies. I don't want to depend on what Zen thinks is the great way to read an RSS feed or ParsexML. Let me pull in the one I like working with from a wider community. Of course, this means your application is going to have less code to manage support. If you keep it slim, it's going to be easier to understand what all the components do and what's going on under the hood. Today, PHP has what I call modern frameworks, not frameworks. And as a result of the micro framework kind of pushed back, a lot of them went back and retooled as components that are well designed, tested, they can be used independently. So the routing layer from symphony could be pulled out and used in Drupal because of their abstractions, but you could use something else to talk to the database. You don't have to use symphony's database component. Some popular frameworks that do this are symphony 2, I'm sure you've heard of it, or Zen Framework 2 did a lot of work to make their components. I mean, not just decoupled, they went and looked and said, okay, why are we maintaining a library for parsing RSS feeds if there's something else out there that does it better? Why are we maintaining our own library for doing database stuff if doctrine ORM does it better? The newest framework from Zen is called Zen Express. It uses that middleware layer and you can totally pick your components. So when you actually set up a Zen Express application, they'll say, you know, what dependency injection container do you want? And they'll give you some choices. What templating library do you want to use? What database layer do you want to use? Which is really cool if you're familiar with different things, you can just pick and choose exactly what you want to work on. A lot of these also provide a skeleton app. So there's a symphony skeleton app, there's a Zen Framework 2 skeleton app where you can download the whole thing and it's got the routing, the dependency injection configuration, all that stuff for you to bake for you using all their components. So modern frameworks have trended to using the best of both worlds in that sense. All their components can be used independently or you can get an all in one bundle. Kind of bucking the trend is Laravel. Has everyone heard of Laravel? It's pretty cool. Instead of focusing on that technical kind of design issues. In my experience, from what I've seen, focus is more on making the developers productive and making it real easy to do stuff with a minimal amount of code and the framework just takes care of all of that. As a result, it's a little more coupled to its own components though you can use like Blade as its templating library, you could pull it out and use it separately. Eloquent ORM is its database access tool and you could pull it out and use it but it's really much more baked together. It's got a very impressive ecosystem around it. It's real easy to put up a Laravel app. They've got Homestead to automate Vagrant and putting up a dev site and a live site for testing sites, all that sort of stuff. There's even a service called Laravel Shift which will take your four two site and make all the pull requests to bring it up to a five five one site automatically for you. Any questions so far? Bit late on. A lot of this was made possible by some standard tooling that's come into Vogue and the PHP community that everyone agreed to use and support and was mature enough that the whole community could depend on it. The one you're most familiar with that you've heard of is Composer. Composer is a great tool to manage dependencies for a PHP project coupled with Packagist. Packagist is an online directory of Composer Packages. So if you need to install something, the Composer tool will look there first when you give it the name of a package to download it and resolve the dependencies. One of, well it says it up there. That's really weird. Sorry. Part of this trend has been that different groups making their packages available on Packagist. One that you should check out is the League of Extraordinary Packages. My updated slides, when I post them to the website, will have it. It's here on my screen. I don't know why it's not up there. And they provide really specialized, high quality packages for image manipulation, file system abstraction, working with OAuth. That's just the three I know off the top of my head. But if you're writing a module that needs to do something real specialized, instead of writing that kind of code yourself, look on Packagist, look on the League of Extraordinary packages. If someone's already in the library and you just need to hook it into Drupal, it'll save you a lot of time and effort that way. Has everyone played with Composer yet? Composer's pretty cool. It sets up the auto loader for you, which is always a bonus. PHP unit, and there's a growing set of testing tools in the PHP community. PHP unit is the facto standard for unit testing now. So you can test your code. Does this method do exactly what I need? What happens if I give it bad data? Is it going to fail in an expected way? On top of PHP unit, or there are some other tools, Behat is a BDD tool. It uses PHP unit under the hood. BDD is great for integration testing. It implements GERCAN, so you can write very simple features and test cases. When I go to the homepage, I'm going to see the search input in this region. When I click on this button, I'm going to go to this page or something will pop up. That's great. Codeception is a newer testing tool. It'll do unit testing. It'll do BDD testing for integration testing. It's main differentiators that you write to test in PHP, so if you're really comfortable, it's a PHP developer, the syntax. You don't have to learn a different syntax. You just write it in PHP. Very readable PHP, too. Another cool tool if you're doing testing, you have a big test suite. You want to make sure it's a good test suite. It's Humbug, which does mutation testing. Mutation testing is kind of cool in an evil way. Because what it'll do is it'll go through your tests, and it'll do stuff like if you're adding numbers, it'll do, well, what happens if I have a test where I subtract them? Is it going to fail in an expected? Is it going to fail? Because if it mutates your tests and it passes, that's not so good. And it'll highlight those places where it mutated a test and it still came up green. So those are tests you have to pay attention to, maybe rethink them, break them down, re-evaluate how they're implemented. So along with testing, there's also QA tools. These are tools not to test if your code works, but if your code base is kind of like high quality code. If you go to the PHP QA tool chain site link there, you'll see there's more than those four. But there are tools like PHP, LOC, they'll measure the lines of code that's a useful metric for comparison. PHP Mess Detector is kind of neat, it'll identify potential problem areas. It'll give you a different metrics, and it'll highlight functions like, this function has a really high cyclomatic complexity, which is a way to measure like how many branches there are in a path of code. And if it's really high, it usually indicates that that method or function is doing too much work. You should break it up in the separate functions classes. So it can give you a good sense of like, I should go rethink how this is implemented, just to refactor it and not change how it works just the way it's been coded. PHP Code Sniffer is a good tool for enforcing a coding standard. So if you're gonna follow PSR 2 or the Drupal coding standard, I know there's a sniff for it. It'll go through your file and say, oh, you know, on this line, you use six spaces to indent instead of four, or you put your braces on the wrong line, that level of inspection, which is perfect for a tool to do, instead of relying on human review. And everyone should just pick a coding standard. Drupal has one, follow it. If you're working on a PHP project, just adopt, I think it's PSR 2 and have a tool to detect that. PHP CPD is a really cool tool. It'll detect duplicated code. It's CPD stands for Copy Paste Detector. So it'll actually tokenize and look like, you know, this function over here, or these lines in this function, look a lot like these eight other places where those lines are. Maybe that should be a function instead of cargo-culted across a code base. These are very useful for refactoring and improving the quality of your code to make it more readable, less error-prone, that sort of stuff. Now I'm gonna talk about some community resources where you can go to find help with PHP, find packages, that sort of stuff. One of the big resources, and I know there's a talk on this, is the PHP FIG, which takes this, it's called as the MOOP-HP Core through collaboration and standards. It stands for the Framework Interop Group. And basically a lot of the core devs from different frameworks and projects got together at Tech 2009, is when this was founded. Realized they were all solving kind of the same problems, logging, handling an HTTP requests, coding standards, and if they could come up with some common standards for how they worked, it would make it easier for them to share code. So they're meant to promote standards for member projects, so the FIG has like 90 member projects. Drupal is one of them, Larry Garfield is a representative, Symphony has a representative, WordPress has one. Once you get to a certain size, you can apply to be a member. So these are recommendations technically for the member projects, not for the PHP community. That's usually the backlash against this, like, ah, why is FIG telling me what coding standard I should follow? They're not unless you remember a project. But a lot of the community has adopted their standards because they make sense and they make life easier. These recommendations are called PSRs. PHP standard recommendation. So their naming kind of led to that weird, we're not, it's only for our projects, it's not for everybody, but we're naming them PHP standards. That's just a legacy thing now. Some of the common PSRs, these are the ones that have been approved. If you go to the link at the bottom, you'll see the ones that are, have been proposed, which ones are under voting, which ones have been rejected. You can see that Larry has a PSR, I think it's eight is for hugs. So that's a fun one to read. One and two deal with coding styles. And the main point of that one is just like across projects make it easier to understand each project's code. You don't have to mentally think, oh, you know, Symphony likes to use tabs, but Zen Framework likes to use spaces. All that kind of nonsense that can get really blown up goes away. PSR three is a really cool one, logger interface. So if you wanna write a logger, that other projects can just drop in or pick a logger that, a standard that for use in your project, if you pick PSR three, you can pick any one that's compliant, drop it in, your code will just work, it doesn't matter, the actual implementation. Drupal uses monologue, or Drupal Lake does, which is the reference, essentially PSR three logger, it's great. PSR four handles auto-loading. So the naming conventions, how you name your class, your namespaces, how they translate to paths and file names for an auto-loader to work, makes it a lot easier on your PHP code not having to litter it with required, include statements and making sure you do that before you call a class, try to instantiate a class, that sort of stuff. And auto-loading was huge for making sure that it's so easy to just have composer pull everything in, write the auto-loader, you load composer's auto-loader, that sounded odd. And you just go, I need to do a new monologue and the PHP engine calls auto-loader, how do I find the monologue class and files and load them and all its dependencies in. So you don't have to worry about that, it's a lifesaver. PSR six is a caching interface, so how should we work with caching layers? That one is pretty new. So if you use a PSR six compliant caching library, you can drop in a new one that comes out that's better or swap one that talks to Redis or something that talks from Memcache without having to change your actual code anywhere. You just change the object that gets created and injected early. PSR seven is HTTP message interface. That's for how do you model and handle HTTP requests, get posts, that sort of stuff and turn them into responses. I believe the symphony kernel uses that. The middleware stuff in Zen expressive is heavily based on conforming to PSR seven. And as you can see from all these, these are things that if you're building a framework, you're gonna have to handle these sort of things. Why don't we make it easy to have a standard, write one logging library, write one HTTP request library and kind of all leverage that work instead of duplicating our efforts all over the place there. Another great resource and I know I'm kind of biased because PHP architect organizes conferences but we're also at DrupalCon, so I know you believe in it. There are a packed schedule of PHP conferences around the world along with DrupalCamps and DrupalCons. If you go to PHP net slash conferences, you'll see a schedule of upcoming ones. They're all over Bulgaria, Sunshine PHP's in Florida, PHP South Coast in the UK, there's one in Australia, so wherever you go, you can find a PHP conference. Joinedin is another big site for finding conferences and seeing feedback for talks and speakers. And there's like a tier of national ones, ZenCon, PHP tech, Ben Alex is a big European conference, PHP UK as well. There's a whole family of regional ones, kind of like the regional DrupalCamps, Sunshine PHP's in Florida, Lone Stars in Texas, and then there's ones in the Northeast around Boston, Pacific Northwest. There's even framework specific ones, so like Laravel has LaraCon, Symphony Live, they do a bunch of them throughout the year. Cake is still going on, they have cake fest every year. So if you wanna try something out or go improve your PHP knowledge, these are great places to do that. Along with that, if you're a budding speaker or have spoken at a DrupalCon before, there's no reason you shouldn't be speaking at a PHP conference as well. There's a lot of overlap. You can share lessons from what you've built, maintain, if you maintain Drupal modules, that sort of stuff. It's also a cool place to meet maintainers of other projects. A lot of times, you don't get to collaborate with people who are solving similar problems, but if you're at a PHP conference, you'll run into folks who manage, you know, big projects like Symphony down to like libraries on packages that you can do. Some resources to get into speaking. The CFP report is a mailing list and I think once a week, it'll send you, you know, here are all the open CFPs that you can apply to and tell you if the conference pays for speaker travel, when it is, that kind of stuff. Calling all papers is another aggregator like that. It looks unjoined in and sees who's got an open CFP that's accepting speakers. And then if you need help writing a proposal for a talk, there's Help Me Abstract and you can, you know, find someone on there to help you review your abstract. They'll give you tips on like, you know, are you describing what your goal is, your presentation, that kind of thing. Another great resource in the PHP community is your local user group. They're basically the heart and soul of the PHP community. A lot of people get started speaking there, meet other local developers. It's a great place to network, find work, find help on a project if you need it. Oh, I can just go hire someone so that I'm at, you know, they know WordPress or they do a lot of Drupal. If you need to find your local one, PHP user group has got a map, this first link, where you can see what your nearest one is. There's also a saying, if there isn't one near you, congratulations. You're the leader of your local PHP user group, you should start it. But seriously, another good resource, Nomad PHP is a virtual user group, so if you don't have one locally or it's, you know, hard to attend to, it's pretty cheap to pay 20 bucks, I think, if that, and you'll see a talk once a month or watch the recorded talk later. PHP Women is another good resource for user groups. They help with bringing in new speakers, mentoring our folks in the community and support for them. They're not, despite their name, they're not just limited to women. But anyone who wants, is new to the community and wants resources and help can get it through them. And there's a lot of resources for learning PHP. Of course, the knock on PHP is that there's a lot of bad resources for learning bad PHP online and there's really still old stuff showing you how to do queries to MySQL using the old deprecated MySQL underscore functions and building queries with strings that are gonna be SQL injection gateways. The best place to start is this community resource called PHP The Right Way. There are many online for doing X with PHP. Start here at PHPTheRightWay.com. They've got, you know, sections for coding practices, how to work with databases so that you're doing it securely in a modern way, how to do templating, other security considerations. And there's more, they even take their website and package it as a book on Lean Pub. So if you wanna have a local reference, that's a great place to start. Lots of training resources. I know I've heard good things about LaraCasts, even though they're specific to Laravel, they do have now some object oriented videos you can watch. They have jQuery or JavaScript stuff you can watch. So they've branched out and they're one of those self-paced. You watch a video, you can learn. Jeffrey Wade has a lot, everyone that I've talked to who uses them has nothing but good things to say. If you're looking for live training, Zend is the company that Andy and Zeve founded. They do a lot of training courses. So does mine, PHP Architect, where you have an instructor. You can work through some exercises together for a couple hours a day. Along with that, if you wanna find a mentor or be a mentor to someone in the PHP community, there's PHP Mentoring as a site where you can sign up and say, I wanna mentor or I wanna be a mentee and get paired that way. Mentoring, there's a big push in the core PHP community to give back by mentoring and also find a mentor to help you in your career. Because they've gone through a lot of experiences that you'll probably do or will know who you should reach out to to ask for help, whether it's soft stuff like finding work, issues at a job, or more technical stuff. The last resource, there's a lot of publications, not just my company's books and monthly magazine, which I have copies of if you're interested and you haven't been on our booth. A lot of community members who speak have gone on Lean Pub and written really good books. If you're stuck with a legacy code base that is just a big ball of spaghetti, you should get the P.M. Jones, Paul Jones's book, Modernizing Legacy Applications. He's got a very nice step-by-step way. First you do this, then you can do this, then you can do this, and at the end, you have a nice object-oriented auto-loading code base that's easy to test. Chris Harches is kinda known in the PHP community for promoting unit or testing, building testable code. He's got a book there, the Guide to Building Testable PHP Applications. As I said before, PHP, the right way, they took the mark down that generates their website, turned it into a book, and if you buy it, you're supporting their efforts, hosting the site and that sort of stuff. If you wanna know how to deal with security in PHP, Chris Cornutt, he's at Enigma on Twitter, has a series of books securing PHP. There's core concepts and there's two more. So these are all great references. And that's just the four that I can personally vouch for on Lean Pub. There's a lot more that are really, I'm sure, good resources. Thanks. That's it. I'll take questions. That's me on Twitter. Please follow me and heckle me. That link is all, you can go to the session schedule and please leave me feedback. Speakers love feedback. I'd love to know what I missed, how I could have done it better, what I did well to improve this talk for next time. And I'm contractually obligated to show this slide as well. There's sprints happening Friday. If you're looking to help get involved in it, these are the times and places. Any questions? What's PSR-0 and why does JetBrains keep? PSR-0 was the first standard for auto-loading, I believe, and it was superseded by PSR-2. Yeah, it was a first stab at doing auto-loading and it had some deficiencies, but you should follow PSR-2 instead. JetBrains, did the PHV soren bug you about it? Yeah, every time I start a project, it says, hey, sources. Okay, it might be a shorthand for PSR-2 as well. As long as you're PSR-2 compliant, I think if not, you can yell at JetBrains, they're down there. That was good stuff. I love PHP Storm, I didn't want to show. I should have had a tooling thing for them. But they integrate with a lot of those QA tools and have their own in there too. So if you want PHP mess detector to run and analyze your code, or code sniffered automatically format your code for you, they can hook right in easily. Anything else? Bueller. Please come and get a magazine. I don't want to cart them all the way home. So if you have to come by or booth, if you have not come by or booth, come on up and get one. Thanks.