Drupal, meet PHP FIG: PSR What? 2016 with Lorna Mitchell

1
DrupalCon Mumbai image banner

Listen to the podcast:

Download podcast (29.63 MB)

PHP FIG? PSR Standards ... What are they? What are they important? This conversation with Lorna Mitchell is another in a series of interviews Campbell Vertesi (@CampbellVertesi) and I carried out in preparation for DrupalCon Asia in Mumbai. We are building the world’s longest DrupalCon session and packing all 6+ hours of it with information and personalities you won’t want to miss! So actually ... For our one hour in the spotlight in Mumbai, we’ve been doing a lot of preparation. Our “session” will include a lot of additional materials like podcasts and blog posts about what we’ve learned along the way.

Our session, Meet PHP-FIG: Your community just got a whole lot bigger, Drupal is about Drupal 8’s membership in the new, interoperable PHP community. We’re covering the basics of what the PHP Framework Interoperability Group (PHP-FIG) is, what the various PSRs are and do, talk about testing and dependency management, and what it means to be a part of the new PHP community — including having better architecture, cleaner code, and more interoperability. All of this adds up to a big move to get projects “off their islands,” saving developers a lot of code, and companies a lot of money, among other benefits.

Also in this series

“Hi Drupal, I'm Lorna. I’m a really enthusiastic PHP user and I'm super excited to see Drupal as being just so much part of PHP these days. I've been to some DrupalCons and seeing the recent release of Drupal 8 has made me very, very, very happy. So have a great DrupalCon. I will see you around at an event or in the issue queues.” - Lorna Mitchell

What are PHP FIG and the PSRs?

Q: Can you give us a rough outline of what PHP-FIG--the PHP Framework Interoperability Group--is and why it's important?

Lorna: Sure. So PHP-FIG is - well, it’s kind of a group of people but actually it's a movement around standardizing our best practices in PHP. It's formed by some very smart and committed—mostly project leads—so it’s framework project leads who really have a sense of what the community needs. It formalizes the best practices. So we can all agree, "Hey, we're going to do it this way.” It allows us to all do our own thing and still play nicely together, so like framework interoperability - literally allows us just to play nicely together.

Q: I would contend that this is one of the biggest enablers for this huge convergence. Its huge coming together that we've seen in PHP over the last - in recent years and I would also contend it to essentially what made it possible for Drupal 8 to even exist in its current form. What would you say to that?

Lorna: I would absolutely agree. Shortly before we really started with this FIG thing which initially was just autoloading, it was PHP 5.3, has namespaces. So now we can pull components and start to make a mix. We don't all need to write our own date class. We don't all need to write our own logo class. Literally, everybody was siloed. If you wrote a framework, you had to write all of it yourself. Now we have standard best practices. Drupal 8 is a really great example of composing something even greater than some of its parts. If we’d had to ship that by writing every line ourselves, it would just never have happened or it wouldn't happen as good.

PSR standards - What is what?

Q: So let's test your PHP-FIG knowledge, Lorna.

Lorna: Oh dear.

Q: PSR-0. Go.

Lorna: Autoloading but we don't use it anymore right? Yes, PSR-0, autoloading. PSR-4 - now we’ve had many places for a while and we know how to play nicely. This is how we really wanted to do autoloading.

Q: What is autoloading? Why is it important?

Lorna: Autoloading in PHP made in the last decade, we don't include files. We just say, “Hey, we’re in this class and we write autoloading rules,” which is PHP knows how to go and look for the code. Before PHP 5.3, every framework kind of had its own rules on naming of classes and ways to find them. Some of them called their classes “.class” – whatever. The autoload means that we can set up the rules for each framework. I don't think anyone really intended that Composer was in our future when we designed the PSR-0 standard. It turned out to be an amazing enabler and now everybody can say if you load all of that code even if you have a class called date and I have one, too. It's gone beyond how should we avoid requiring files and coming to how do we do modern dependency management.

Q: As we all know Lorna, PSR-1 and PSR-2 pretty much come together. We have your basic coding standard and your coding style guide. What are they? Why are they important?

Lorna: They are really important because they allow us to just create a coding standard. Every change should have a coding standard but life is too short to argue about spaces and brackets and new lines and things. So just use PSR-1, PSR-2, they are really good tools for enforcing them. It's important because it makes your code consistently readable. I am expecting layout to look like this. My brain does not have to work hard to read your code where it’s well laid out. PSR-1 describes things like function naming, variable naming, that kind of thing. PSR-2 is a little bit more stylistic. It covers more like white space and bracket layout. PHP is obviously white space agnostic so they split them into the two hubs. I would always recommend that people use both.

Q: Cool. So moving right along - PSR-3 logger interface. What is it? Why is it important?

Lorna: So the logger interface. The idea is that you could use other logging tools and if you needed to extend or implement your own, you can just swap out whatever logging solution you have and put in your own. You could wrap an existing one, you could build your own but the logging interface describes how behavior should work. So in our own applications we can just change them out. That’s the crux of the object oriented programming idea.

Q: Now, talk about our newest approved PSR, PSR 5, the Caching Interface.

Lorna: Yes. This is really the same as the logging story. There is a standard way of having a caching interface. I can write my own caching tools and then realize that yours is a way better. So as long as we’ve implemented the standard, then I can swap early in or maybe I want to cache to a new platform and I may choose different library for that. They'll all use the same interface. So it's super easy, just change your caching mechanism if you need to - performance reasons, different platform like you say technology evolution, it's all out there. We’re not writing websites and shipping them, we're building applications that will live and evolve.

Q: So PSR-7, the HTTP message interface, talk about that.

Lorna: That is super interesting. PHP solves their web problem. So fundamentally, it's a request and it’s a response. We haven’t traditionally written our code like that but it’s a pattern that’s really common in other programming languages that do deal with HTTP messaging. I am super excited to see this one come in and also super excited to see already we have tools that are building on it out in the wild, getting actual stable releases in the community. This is going to be a big paradigm shift about the way that we build things that respond to an HTTP request. Publishing the PSR-7 standard feels like much like PSR-0, which is just the beginning of something - I think PSR-7 is as well.

Building living, evolving applications

Q: When we were touching on PSR-7 you were talking about building applications and iterating and improving them over time, right? Actually, it's a general meta-concept that this swap-ability, these standards allow us to work more efficiently because we’re not reinventing the wheels. Can you talk about the architectural implications of having the PSRs in place and people following them?

Lorna: Okay. There are a few different strengths here. One is I'm a consultant and a trainer as well as a developer. So I'm often asked for my advice. PHP-FIG has helped us to know what the good advice is and know what best practices to follow. So even for people who are on their island, building an application on their own, there is a resource that they can go to and it will help them to make useful decisions. Beyond that, I think once upon a time we would have shipped to website when we were tired of it. In two years we would have shipped to another website and maybe those in concept management but it was a website. PHP now is much more about applications. I barely work on any websites which is good because I barely write HTML. Everything that I do is very application-driven, it's very functional, it's very much software development. Our applications have a future in two senses. One, the technology moves on and we might want to switch things out or update, move from one queuing system to another, introduce a queuing system, realize that we need caching, move to a cloud platform. I think our applications now—given these best practices and given the wide adaption of the object-oriented approach—are able to do that. The other way that they move on is the reasons for them to exist move on, the businesses that they support grow and pivot and become successful and expand and we want to offer more things online. I think good design practices, modern applications allow us to evolve our applications in both those directions. We don’t ship a new one in two years. That's cost-effective and it's also smart.

Q: Right. So it gives us cheaper maintenance. It gives us cheaper innovation. It makes our application future friendly. There is some element of risk mitigation around new technologies coming in as well.

Lorna: Yes, definitely. It means that we are interested in changing things. We don't have to turn off feature development and start afresh. We don't really rebuild. I mean there are cases where you’d like to. We don’t have the option to rebuild portions and everything is unit tested, everything is modular. So we've got those options to start – we really need to change this and to do that kind of by degrees because we can switch things in and out. We are not writing big balls of code.

  • Name: Lorna Jane Mitchell
  • Twitter: @lornajane
  • Website: http://lornajane.net
  • Acquia.com guest author profile
  • Work affiliation: Freelance, "I work where there are people who need me."
  • Drupal/FOSS role: Project lead on joind.in, PHP writer and speaker, "I don’t know any Drupal but I keep finding excuses to hang out with the community."
  • Current projects: Joind.in mainly, but I just had some contributions accepted to XHGui.
  • When/which PHP you started with: PHP 4.2 in 2002
  • About: Lorna is a web development consultant and author based in Leeds, UK. Her books include "PHP Master", "PHP Web Services" and "N Ways To Be A Better Developer", and she loves to write for other outlets such as netmagazine and her own blog http://www.lornajane.net. When she's not writing either code or words for a living, Lorna leads the Joind.In open source project; a tool to enable communities to give real-time, public feedback to speakers and organizers of events. Lorna has spoken at events around the world giving both keynotes and technical talks and is available for hire on interesting projects.

Add comment

By submitting this form, you accept the Mollom privacy policy.