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.

This is the final post in a short series about hosting events, based purely on my own experience and no specific expertise, in the hope that they will be useful to others doing similar things. If you are interested, you can read the first two posts, about preparing for the event and what to do on the day. This post is about some of the additional things about an event; sharing the content afterwards, getting feedback from attendees, and the most important bit - the social event.

She talks about the importance of getting slides (and recordings, if possible) from each of the sessions as this can add to the post-event experience, especially for those that weren't able to attend. She notes that feedback during and after the conference is key and has a few tips for the social events that might happen in the evenings for the attendees.

As you might have noticed, the Symfony2 documentation grows every single day. Since the Symfony2 Live Conference, I regularly publish new documents for Symfony2, like the best practices to follow for Symfony2 bundles. I think it's now time for the community to provide feedback on the Symfony2 documentation.

They're looking for input on the documentation strategy (small chapters vs one large book), the current format and the actual content of the pages and how well they communicate the details. You can find this documentation here.

Today we'll look at another really important aspect of authoring web services, and one feature that will definitely get used - error handling and feedback! Having clear and robust error handling in your service will help those trying to consume it immeasurably. Nothing is more annoying that impenetrable errors, unclear responses, or a service which accepts your input but then turns out not to have done what you expected. And I say that from experience.

She suggests that, instead of having one single error after another a more useful (and less frustrating) method is to have a "stack" of errors. Her code examples show how to added the errors to a $messages array and, at the end of the request, spit them back out in an easy to parse method.

Usability guidelines can sometimes be of use in awkward places. I try to apply them to source code. [...] Of course, coding guidelines are there to make the code easy to read by everyone. But code usability goes somehow beyond. Let's see some of the differences.

He compares good versus bad code in a few different areas:

• Bad Code Comments
• Split Up Code
• Cleanliness
• New Conventions
• Listen To User Feedback

Each item is described, some including code examples to help make them more clear. Be sure to check out the comments for more good suggestions.