As a follow up to his previous post about using DocBlock commenting and phpDocumentor for automatic project documentation generation, Michelangelo van Dam has posted a deeper look at DocBlox, one of his previously mentioned alternatives.

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).

Brian Swan is asking for user feedback about the future of the Microsoft's SQL Server driver for PHP based on a post in the team's blog.

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.

Bradley Holt has a new post to his blog today talking about the experience he's had with testing the PHP 5.4 alpha1 release, just posted from the PHP development group.

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.

Padraic Brady has a new post to his blog asking you, the reader, for your suggestions on how to architect a distribution system for the PEAR2/Pyrus components.

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.

If you're still interested in contributing your ideas and feature requests for a PEAR channel aggregator, Stuart Herbert wants to know (last call before the development starts).

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.

Lorna Mitchell has posted the last of three articles with tips for those hosting tech events out there from her past experiences with conferences like the Dutch PHP Conference.

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.

In a new post to the Symfony blog, Fabien Potencier talks about the Symfony2 documentation and requests feedback from the developers and users out there on the quality and correctness of things so far.

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.

In a recent post to her blog, Lorna Mitchell looks at giving feedback for errors on a web service.

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.

Francois Zaninotto has a recent post looking at something every developer should consider when creating their applications - especially the libraries that might be used by other developers: code usability.

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.

Stefan Koopmanschap has posted about static methods and comparing "static public" to "public static" (including a popularity graph).

Ever since starting with PHP 5 object oriented development, all documentation I read on the topic seemed to suggest that the only way to write the method keywords is "public static". I've been following along those lines, and for a while I really thought any other order would trigger errors. Only recently I found out the other way round is actually nicer.

In his opinion, the "static public" keyword combination (versus "public static") is "more beautiful" than its inverse counterpart. He even asked about it in a twitpoll and got these results - "public static" winning out as the popular choice. If you want to voice your opinion, you can still get in on the poll.