From time to time I see bugs in the code and I start thinking "really? is it possible that no one noticed that bug before? am i the first person to see this code?". I thought it might be worth writing a little post on what helps me to deal with bugs and software quality in general and what are the common pitfalls in developer's thought process. Although it is not a very extensive post i hope it may inspire some developers to try new approaches.

Other topics he offers for consideration involve the fact that bugs will never fix themselves (they might disappear in a refactor though), that the bug is almost never in the language/data source's code and how automated (unit) testing can help to find new bugs before they're released to the users.

Troels Knak-Nielsen, father of pearhub, wrote to the pear-dev mailing list: "Unfortunately I have absolutely no time at hand for this project and probably won't for a foreseeable time. I still think it fills a need, so I'd be happy to hand over the keys to anyone who will take it upon them to move the project forward. I'll try to assist as best as I can, but probably won't have much time to spare. But the project is fairly simple anyway, so it should be relatively easy to get the main idea."

If you're interested in hosting or helping out with the project, let Troels know. Pearhub lets any project with a publicly facing repository be installed via a PEAR channel quickly and easily. For more information, see the project's FAQ.

The goal of this blog post is to number one serve me as a todo list of stuff that I personally think needs to be fixed before Symfony2 can be released. Hopefully it will also entice some people to help out with these tasks. I am focusing on the medium to large tasks. There are of course still a fair number of smaller fixes that need to be applied.

Items on the list include:

• switch Security/Validation components to using message key's rather than full sentences
• Assetic documentation
• Adding a DIC aware Serializer
• Better support for SSL'ed urls and assets
• ttempt to automatically determine service scopes

A question that seems to be popping up more and more these days is, "When will PHP 6 be released?" It's especially annoying because the people that enjoy an exercise in futility ask this question are the same people that simply refuse to take WIR [When it's ready] for an answer. Or maybe they just read into the hype generated by trigger-happy publishers who want to preempt a stable release, I don't really know.

He points out some of the current stats - PHP 5.3's beta release date as coming to the original date, that PHP 6 code hasn't even been moved outside of CVS and the amount of work left to be done on it before its even close to being ready. This is where you come in - the internals folks contribute their time (off-hours usually) to developing the language and can only do so much:

So respect them and their time and stop asking when it's going to be ready, because they don't really know much better [about PHP6] than you do.

He also suggests two other things that you can do to keep up with the current state of development - keep your version updated and track the RFCs to see what features are being added and any bugs that might still be open for pre-release. You have to be proactive about keeping up with the current status - otherwise, you have no room to ask, over and over, "when will it be done?"

Last thursday was the begin of the feature freeze phase. Well its not really a hard feature freeze in the sense that we still have plans for a few new features and tweaks, but it means the end of the "maintainers freedom" that usually rules PHP development more or less.

New features will have to go through either him or Johannes to be included and they are doing their best to get the alpha 1 release of this new version out by July 31st.

Lukas is also trying a more unconventional approach to bug fixes to try to get the major ones knocked out first - posting them as a comment to this blog post. So far, no comments on bugs have been added, but there are a good number to get through. To help narrow it down he's also put out a plea to developers out there to help validate current bugs to potentially knock off a few of the ones that can be marked bogus.

I've been using Zend Studio for Eclipse (beta) for several weeks in a rewrite of a framework and numerous sites at work and overall I really like the IDE. Its got some great features and being based on the eclipse project makes it really extensible and customizable.

He happy overall with the IDE but has come across some bugs in his time developing in it (nine of them) with issues ranging from the SVN functionality and samba out to small syntax sorts of things (like the auto-formatting).

I just released Xdebug 2.0.0RC3 through the web site and also through PECL. This hopefully last release candidate of Xdebug 2.0.0 addresses a number of segfaults and other small bugs that crept in in Xdebug 2.0.0RC2.

The Xdebug extension helps you debugging your script by providing a lot of valuable debug information. The debug information that Xdebug can provide includes the following: stack and function traces in error messages, memory allocation, protection for infinite recursions.

While it is true that many PHP applications are written by people with no clue about security it is absolutely not true that PHP is a secure programming language. I think it is necessary to make ALL people aware of this.

No word yet on when this month will start, but we will keep you posted as soon as it's out. If you'd like to check out the community's response to this effort, check out some of the comments already posted to this announcement on the PHP Security Blog.

I've written about using Google to find security flaws in the past. However, thanks to Google Code Search, it is now easier to scan publicly available source code for potential security issues. The idea is query Google Code Search using techniques previously reserved for local static code analysis.

The examples he gives include a search for SQL injection in a Java application, a SQL injection in a PHP application, and a cross-site scripting problem in a PHP app blindly echoing out the user's input.

He also includes a few links to some code analysis tools that can be used to help prevent some of these issues - Flawfinder, RATS, and SWAAT

This is the first release of PHP-GTK 2. PHP-GTK 2 is a PHP extension that combines the power and flexibility of both PHP 5 and GTK+ 2 to allow developers to create stand-alone desktop GUI applications using PHP.

Scott reminds all potential users of this release out there that this is most definitely aplha and shouldn't be used in production due to some bugs and feature changes that will need to be resolved.

If you're still interested, you can grab the download from the PHP-GTK site and check out the new manual or subscribe to the mailing list for a little help.