For those who pay attention to the workings of the PHP community you might have heard about the "PHP Standards Recommendations" that have been coming out of the PHP Framwork Interop Group. [...] More recently this group has been working on a standard for logging interfaces called PSR-3. I spoke about this on Twitter, and I will repeat it here: I think PHP programmers should get behind PSR-0 and efforts like PSR-3. I feel that PSR-1 and PSR-2 are solutions looking for a problem and seem, to me anyway, to me out of place with the solutions offered by PSR-0 and PSR-3.

He likens the PHP PSRs to the Python enhancement proposals (PEPs) and, more specifically, to the PEP-8 - their own version of "coding standards" that was highly championed by Guido van Rossum and put into wide practice.

Any programming language community that does not work as hard as possible to make it easier to integrate other's libraries of code together [by standardizing their formatting] is asking for irrelevancy.

The question, however, has always been "how useful is this feature really and does it bring more harm than good?". It's not that easy to answer since there are so many notes submitted by a wide range of users and some will likely go unnoticed while others seem to get undue attention due to their positioning near the top of the user-notes section of a particularly trafficked page.

The poster proposes a few things that could help make them a bit more effective (and useful overall) including voting on the note contents, flagging potential issues and sorting the notes based on popularity/age. He's put together a proof of concept as seen here with some of the new features.

Coding is an art. There are many ways to paint an apple, but which is better? Most of the code we write everyday can be written in better ways to achieve different objectives. Sometimes all it takes is a fresh pair of eyes. Code quality can be observed through various identifying markers. Perhaps you're not aware of them, don't have time to look for them or are too caught up in the moment to notice? That's where FixThatCode.com steps in!

There's a few different categories you can ask for help in including "Make this code better", "Make this code faster" and "Give me feedback". So far there's some interesting examples to look at - mostly in the "Feedback" category as developers look to further their skills by learning from others. The site's still just starting out, but I could see it becoming a good resource to any community - not just PHP!

If you attended this year's event, please be sure to give the speakers some feedback (on Joind.in) and, if you weren't able to, check out the "Slides" section for the presentations.

Topics at this year's event included:

• Easing in to HTML5 and CSS3 (Brian Moon)
• Web Security and You (Eli White)
• (Re)discovering the SPL (Joshua Thijssen)
• Slim Your PHP, Fatten Your JS (Ed Finkler)

PHP tends to get a lot of flak, but mostly it is for something that isn't really the fault of PHP. Things like "there is so much bad PHP code out there" may be true but you can write bad code in any language. You shouldn't be mixing PHP, SQL and HTML, and you should be escaping/parameterizing variables for queries. (Thankfully this is less prevalent nowadays.) So do many PHP criticisms actually hold true today, now we have namespaces and we have buried crap like magic quotes at the bottom of the ocean?

Other comments cover things like

• PHP's namespace implementation
• poor web services support
• Less code audits, more "roll-your-own fever"
• Function naming and parameter order
• weak OOP functionality

Check out the full post for lots more opinions and add yours too!

First of all, thank you all for the enormous feedback I got on my latest article on documentation of code. I got a lot of comments on the usage of PHPDocumentor. [...] I have to agree that [there are reasons] valid enough to step away from PHPDocumentor as a tool for documentation purposes and look for a better alternative. So I've investigated one tool most people have commented on or tweet-ed/facebook-ed/g+-ed on: DocBlox.

He touches on the installation of the tool and mentions this tutorial from Matthew Weier O'Phinney that guided him through the setup and use of DocBlox. He rand a few tests comparing phpDocumentor and DocBlox for the documentation generate and DocBlox came out on top when it came to runtime (and memory usage).

I want to make sure that his request gets in front of lots of eyes, so I'm re-posting his request here (below). Jonathan included some links in his post so you can learn more about what the team is considering for the next release of the driver, but he didn't elaborate on "Buffered Queries".

They suggest a few features and ask for choices on which would be the most important to you as a developer - Always On support, SQL Server Serverless Express support, Buffered queries and LOB streaming support in PDO_SQLSRV. To give feedback, send an email to the address mentioned in the post or on twitter/their forums.

Rasmus Lerdorf today posted instructions for testing the upcoming PHP 5.4 release. Running the PHP tests and submitting the associated report will help the PHP team get PHP 5.4 ready faster as it gives them reports of failed tests from a variety of platforms. I just did this today for the first time and can tell you that it is very easy. Following are the steps that Rasmus outlined, in a bit more detail.

He lists a few things you'll need before you get started and where to grab this latest code from. He describes the make/make test process and what you might see if one of the tests fail. You can find the results of the failed test submissions on the Test Reports page.

With the idea of PEAR2 and Pyrus, I had hoped to see a renewal - the advancement of a PEAR architecture for the 21st Century. Instead, and this is just my opinion, PEAR2/Pyrus were a relatively simple iteration on a very old theme. [...] If the PEAR ecosystem has a failing, it is one of staggered evolution. Over time it has picked up additional features tacked on top of a base model.

He breaks up his thoughts on the future of PEAR2/Pyrus distribution into a few different topics - the issues he sees surrounding packaging (like static packaging definitions), suggestions for a dynamic channel aggregation system and overall usage of the PEAR system.

There's already been a sizeable response so far, but if you haven't had your say yet, please head on over and leave a comment soon. I'll write up a summary of the suggested requirements on Monday.

The idea behind the aggregator is to provide a single place for developers to look (besides the PEAR site, of course) for PEAR packages they might find useful. The key here is that the aggregator would be bringing together the independent channels out there and making them simpler to find. Feature suggestions so far include: showing where the library lives (like github or bitbucket), creating a proxy channel for a "single install" location and customized lists of a user's "in use" and "tracked" packages.