Trying to figure out what's broken when someone reports a bug can sometimes be one of the biggest pains for a software developer. Helpful information can be few and far between and it could be a lot better. Ralph Schindler has a new post to his blog today to show how you can create a good, helpful reproduction script that can make the live of the project's developers much simpler.

"There is a problem with component Fooey-Bar-Bazzy, I think it's related to Nanny-Nanny-Neener. Please Fix Now." If you've written a bug/issue report like that in the past with no other details - shame on you! This may come as a shock, but as great as some developers might be, they cannot read minds.

He recommends a few things that can help make your report clearer - listing out your assumptions, creating a short use case, documentation on expected and actual results and how to make the script as generic as possible. To further illustrate, he also includes a sample reproduction script for a Zend Framework bug based on this issue with plenty of commenting, reproduction code and setup/assertion methods to show where the problem lies.

Using this method does not only make it easier for the developers to find the bug, but it also means that the person finding the bug doesn't have to know the internals of the application to point out where the issue lies.

As Danne Lundqvist mentions in a new post, there's a new post on the Gartner.com site about the past, present and future of the PHP language.

From the Gartner post:

I just published a research note on PHP. Clients can find it here. The research note goes into *much* more detail but the overview is [in the rest of the post]. Keep in mind that this content is targeted at mainstream IT organizations. PHP has been a cornerstone technology on the Web for more than a decade. While its adoption among mainstream IT organizations has been limited in the past, many corporate application development (AD) projects are discovering the unique benefits of PHP.

Danne highlights two quotes that were of particular interest in the report - one from the quote above about PHP being a cornerstone of many corporate web application development and the other talking about PHP's role not just in backend application development but also it being useful in front-end toolsets too.

According to this post (by Cal Evans) on the Ibuildings blog (and this report from the EDC), PHP has come out as one of the top scripting languages on the web today.

In their recently released report "Users' Choice: Scripting Language Ratings", Evans Data Corporation (no relation to the author of this article) gave PHP the highest overall ranking of the languages they included in their survey. [...] Given the wide variety of topics, there is no way PHP will ever score first place across the board, however, that is not a bad thing.

Categories the languages were rated on included ease of use, extensibility, community, availability of tools and memory management. PHP got high marks on most with a few (like client-side scripting) lagging behind. Cal sees it from two angles, though - one to celebrate how far PHP has come and the other to look forward to see what things the language needs to improve on.

On the Blue Parabola site Matthew Turland has started a series looking at a "new kid on the block" when it comes to PHP e-commerce applications - Magento.

Magento, has gotten a good amount of attention leading up to and since its initial release. I was recently entasked with doing an analysis of its features and thought it might make for an interesting series of blog posts. This first one will cover the Analytics and Reporting feature set.

He mentions the Administrator Action logging, the Google Analytics integration, the Admin Dashboard for reporting overview, included RSS feeds, Accounting Reports and Feedback reporting.

Antony Dovgal has announced a tool that can help you find out where issues are in your code - specifically places where too much work is being done and gumming up the works. The Pinba statistics server for PHP that gathers UDP data from the PHP processes and makes it available for parsing/graphing.

What is it? It's a daemon gathering information sent by PHP processes by UDP. In the same time Pinba acts as a read-only storage engine for MySQL, so you can use good ol' SQL to access the data. [...] There is no need to store that information for further analysis, therefore Pinba doesn't actually store the data - it keeps it only for 15 minutes (you can change that, of course), which is more than enough to update graphs.

You can find out more about the project on its (wiki) site including links to the latest downloads (version 0.0.3 at the time of this post).

Marco Tabini has taken a different tack on error handling in his latest post. He suggests that developers need to spend a little less time trying to prevent so many errors and a little more time handling the ones that do happen.

When an error occurs, the vast majority of the web-based application code that I see during my reviews performs the software equivalent of running around with its head cut off: the developer spends an inordinate amount of time and resources trying to make the software look like what was essentially a catastrophic failure was nothing more than a small temporary hiccup.

[...] In reality, by the time an error has occurred, there are only two possible outcomes: either you expected the error to occur, in which case you have already written code to handle the failure, or you didn't, in which case your main focus should be to use the error as a learning opportunity.

Marco suggests alternatives to this usual worry and hysteria - spend more time ensuring that (if something does fail) there won't be any more damage, let the IT team know as soon as you find the issue and testing before you fix (reproduce the error before you dig in to try to fix it).

Greg Beaver has a new post reporting on his latest efforts to improve the Pyrus PEAR installer and to make it a more strong, stable and robust end result.

One of the problems I found when designing the new code for PEAR 1.4.0 (back in the day) was that it was very difficult to determine whether changes would break things. The main problem revolves around the colossal size of the test suite. [...] This is a real problem when trying to develop with any kind of flow. If, after every change, one needs to sit through 35 minutes of tests, one will never develop anything of substance.

What he wanted was an application that could detect only the files modified and tests those with the results put into the code coverage report. To fill the need, he created test-modified.php to run just the phpt tests needed.

Lukas Smith asks developers a question in his latest blog post: "Is your chosen framework on the PHP primary tester mailing list?"

This is a question you should be asking the developers of the framework you are using. Same of course goes for any PHP application you care about. [...] We announce all PHP releases on this list (actually until now we have only announced RC's, but we are expanding this to also cover alpha and beta releases).

He suggests that subscribing to this list simplifies the process of keeping up with the latest releases of PHP and gives them a chance to report back with any issues they might find with them.

Every release runs the risk of BC breaks, intentional or not. Projects that want to make life easy for their users participate actively in the process of testing PHP releases. It makes the life of the PHP developers a lot easier .. and who doesn't want to make their life's easier?

Most of the bugs that get reported to the PHP project are pretty useful. They help developers track down those small, random issues that might slip through the cracks otherwise. There are, however, some of them that make you wonder a bit about the person that submitted them Scott MacVicar takes a look at a few of them in a new blog post.

Recently the PHP project has been receiving an increasing number of rather silly reports, these vary from simply not reading the manual, searching the internet or a fundamental lack of understanding how the internet works.

He points out three in particular (from the same person, no less) about things that shown an almost complete lack of understand of what PHP does. One was a request to make PHP use less CPU and another asking to make PHP censorship free and, finally, a request to make PHP more secure...by doing away with support for cookies.

Scott also suggests a few constructive things you can do before submitting a good (useful) bug report:

• Gather together as much relevant information as you can (generalizations are bad)
• Run performance checks against older PHP versions to try to pin down when the bug was added
• And, finally: "don't get aggressive or be an asshole when your bug reports get closed".

Padraic Brady has made a post about the upcoming Zend Framework book (and website) he'll be releasing in January:

In January, the new book will commence its long awaited publishing process online. The book has been a long time coming since I started posting my now infamous tutorial series which focused on the practical side of creating an application more so than acting as a reference book. The book is being made available free of charge online funded by donations and some advertising.

The book will include the ability to comment on chapters (with changes to be included in possible revisions) via a jQuery-powered commenting system that allows for thoughts to be added to each paragraph. You can see the website in this screenshot.