The PHP Town Hall podcast has released the latest episode of their show - Episode #6, "PSR-X and the Mexican Standoff".

PHP-FIG member Paul M. Jones and PHP contributor Anthony Ferrera come on the podcast with Ben, Phil and regular guest Zack Kitzmiller to discuss the new Package Orientated Autoloader Proposal (a.k.a PSR-X), and wether or not PSR's should ever be amended.[...] Nobody wins, but the argument brings up a lot of interesting topics and points of view, and that is mostly what we are here for.

You can listen to this latest episode either through the in-page player by downloading the mp3 or by subscribing to their feed. The post also contains links to several of the groups and technologies mentioned in the episode.

On NetTuts.com today there's a post that talks about applying the PSR formatting to your application's code. If you haven't already read their introduction to the PSRs, it's highly suggested.

In a previous lesson here on Nettuts+, you learn about PSR; however, that article didn't detail the process of integrating that coding style into your projects. Let's fix that!

They briefly recap the main two PSRs (PSR-1 and PSR-2, but no mention of PSR-3 the logging interface) and show code examples of them being applied. They also point to the PHP_CodeSniffer tool that you can use to keep your code in the correct structure. Instructions are included to install it specifically for the Sublime Text 2 editor via package control. It's just a command-line tool, though, so it could be integrated with just about any other editor/IDE out there too.

In this recent post to his site, Phil Bennett shares some thoughts about the PHP-FIG, the standards they're proposing and how the shares interfaces might help reduce dependencies in framework-based applications.

[Frameworks] come in several different flavours that all have huge advantages, but also a few disadvantages. Over engineered (because their popularity demands that they be), updated too often, not updated enough. If you decide for example to update your application from using Zend Framework 1 to using Zend Framework 2, this will more than likely require, at least in part, a re-write of your code. This makes scalability difficult.

He talks some about the PSRs that the PHP-FIG group has proposed including the PSR-3 logging interface structure. He points out that, by having this same structure, it makes injecting dependencies easy while still leaving the actual functionality open to interpretation. He also suggests that maybe a framework isn't the right choice for all applications and that possibly using a collection of libraries, tied together by the PSR standards, could be a better answer.

On the "Riding an Elefant" blog (for the Elefant CMS) there's a new post that looks at some of the "challenges, efficacy and attitude" of the PHP-FIG (Framework Interoperability Group) surrounding their PSRs and general direction.

First, I should state that I'm not a member of PHP-FIG. I applied to be a member representing the Elefant project, but saw projects with similarly-sized communities rejected, so I wasn't surprised at the lack of response to my application. However, I do agree with the general goals of the project and think it has a lot of potential if steered well.

He then spends a good bit of the post talking about the three PSRs (autoloading with PSR-0 and coding standards with PSR-1 & PSR-2) and how he thinks the PHP-FIG has some "public relations" issues they need to overcome as it relates to their reactions.

PHP-FIG has grown rapidly since its inception, and with that comes the need to reevaluate and adapt. The PHP community is huge, and a group hoping to represent even a substantial minority of it will have to practice diplomacy and clearly state its intentions if it doesn't want to be misunderstood or cause alienation amongst the wider community.

There's also some good comments on the post so be sure to check those out too.

On NetTuts.com today they've posted a good primer for those that may have heard about the PSR standards that have been introduced to PHP but aren't quire sure what they are (or what they mean to you as a developer).

If you're an avid PHP developer, it's quite likely that you've come across the abbreviation, PSR, which stands for "PHP Standards Recommendation." At the time of this writing, there are four of them: PSR-0 to PSR-3. Let's take a look at what these are, and why you should care (and participate).

They start with a brief history of the standards, the PHP-FIG (Framework Interoperability Group) and where the idea for the PSRs came from. Then the article gets into the details of each:

• PSR-0: Autoloader Standard
• PSR-1: Basic Coding Standard
• PSR-2: Coding Style Guide
• PSR-3: Logger Interface

They also do a good job mentioning some of the criticism that's come with the standards and what sort of future there is including the creation of a standard for a HTTP messaging package.

On PHPMaster.com today there's new tutorial showing how you can enforce compliance with the PSR standards in your application's code with the help of the Jenkins continuous integration tool.

Though it's still early to guarantee that the PSRs will be widely adopted as the de facto standard for writing serious PHP applications, it is interesting to note that a code sniffer and fixer that looks for code deviations was developed by nobody less than Fabien Potencier, the creator of the Symfony framework. (Et bien, ils ne sont pas fous, ces français!) In the rest of the article we shall find out what his PHP-CS-Fixer does and how can it be integrated with a CI tool like Jenkins.

He shows how to install a tool that can help you keep your source in compliance - the "fixer" (created by Fabien Potencier) to help correct the problems found in your code. He includes the command line calls you'll need to run the tool on your code and how to add the step to your build.

Klaus Silveira has created a set of PHP_CodeSniffer rules that can be used to test your code for the recently approved PSR-1 & PSR-2 standards.

This is a PHP_CodeSniffer sniff to check against the PHP Standard Resolutions: PSR-0, PSR-1 and PSR-2. Those standards were approved by the PHP Framework Interoperability Group. You can read more about the PHP FIG and the PSR's on this excellent article by Paul Jones.

The github repository also provides an overview of the standards themselves and how to get these sniffs installed.

Brian Moon has shared some of his thoughts about the recently proposed standards (PSRs) from the PHP-FIG group based on some discussions had at this year's php|tek.

During the /dev/hell podcast at Tek12, someone asked the guys their opinion about PSR. [...] The person asking the question had asked about PSR1 and PSR2. These are the first two standards proposals in the group and they deal with coding standards. [...] There are already coding standards for PHP and any other language out there. Why does anyone need to make a new one? [...] This reminds me a lot of Open Source licenses. There are tons of these things. And in the end, most (GPL has its issues I know) of the open source licenses represent the same idea.

He goes on to talk more about the feedback he's gotten from other PHP community members about the target of the group and his thoughts on the naming of both the group and the standards they're generating.

In the end, cooperation is good. And if these guys want to cooperate I say more power to them. I just hope they get into really good things soon. Like, can we talk about a maximum number of files, functions or classes used for any one single page execution? *That* would be valuable to the PHP community.

In this new post to his blog Anthony Ferrara responds to some of the recent news about PHP standards being up for voting (PSR-1 and PSR-2). He has an issue with how they were created, though, and notes that the current PSR process doesn't encourage open standards.

There has been a lot of traction lately on the topic of the PSR "PHP Framework Interoperability Group". They are introducing two new proposed standards: PSR-1and PSR-2, both dealing with code formatting standards. [...] I have read both, and actually agree and think they are quite good. However, there's a deeper problem. Open Standards is something that the internet was built upon. From HTTP, E-Mail and HTML to ECMA Script (JavaScript), OAuth and JSON, open standards are everywhere. The problem with the entire PSR process is that it is not designed to produce open standards.

He describes an "open standard" and points to this RFC as an example of the open process they should result from. He talks about the importance of the process and how having more people reviewing and contributing their ideas could help find issues in the proposal. He issues a "call to the PSR team" to adopt this practice, allowing a more open flow to the ideas that are being proposed.

Note that I'm not asking to open the vote to anyone else. I'm not saying that standards should be approved by everyone in the community. There should still be a standards body that makes the final decision. But they should make that decision based on community input. They should actively look for and encourage open discussion prior to voting.