Often times developers only think about tracking the bugs in the code for their "real jobs" and don't worry about issues that might pop up in their personal projects. Brandon Savage suggests that they should both be important and that not tracking bugs on your personal projects can be a bad thing for the quality of your code.

Too often, it seems like these development practices are abandoned, especially with regards to the use of a bug tracker. I know I have personally been guilty of failing to use a bug tracker, even though I use things like Subversion and develop specifications. It's easy to forget, but important to remember.

He lists five reasons why you should use a bug tracker for your personal development:

• Our minds are imperfect repositories of information.
• Bad development practices can form.
• It makes it harder to force ourselves to use bug trackers for private paying clients.
• Predicting time to completion becomes more difficult.
• Seeing progress being made is that much more difficult.

PHPBuilder.com has posted the second part of their series on creating a sample application - a time tracking app - with PHP and Adobe Air.

Welcome back. In part 1 of this series, you created some PHP remote services and the Clocked! widget application. Part 2 covers PHP administration and completion of the timer widget.

They're developing a Flex-based application (rather than the HTML/Javascript combo that can also be used with Air) so they'll be doing their work in Flex Builder. They set up a few placeholder functions like getClients, getProjects and getProjectsResult as well as support for the ticket and timer objects. Add in a few interface items like dropdowns for client and project selection and a start/stop button and you have the basic app laid out. The PHP interface to all of this Flex code comes in the next article of the series.

On PHPBuilder.com today there's a new tutorial by Richard Bates that will walk you through the creation of a simple time tracking application that combines the Adobe Air and PHP technologies to make a simple desktop client.

The scenario calls for a lightweight, cross-platform desktop application that does its job and stays out of the users' way. It also needs a powerful management interface that can be accessed from anywhere. To address both needs, you first create a desktop application for AIR that leverages PHP back-end services for persistent storage and extra horsepower. Then, you create a simple and quick PHP/Hypertext Markup Language (HTML) browser-based interface for management and output applications.

The Air client is really just a frontend to the PHP backend located on the server (so there's no need to install PHP locally too). The system is based around a few objects - the Client, a Project, a time-tracking Ticket and an Invoice for the time spent. To make things simpler, he uses an instance of the Zend Framework to do most of the heavy lifting on the backend.

The rest of this article sets up the backend scripts - creating the service interface and making some of the initial methods (like getClients and logIn). The next part in the series will get into the actual Air application.

On DevShed today the latest article in their XDebug series has been posted, a look at tracking the function call stack with help from functionality the extension provides.

Despite this inconvenience [pf not being able to get more in-depth], in this final part of the series, I'm going to show you how to work with a function of the library called "xdebug_get_function_stack()." This function can be used to keep track of the stack of function calls generated by a PHP script, in this manner completing this starting guide on this helpful extension.

After reviewing the script from the previous part (using xdebug_time_index) they get into this new function and what sort of output it provides. The stack is the trace of what functions and values were passed around in the script including information like the function name, parameters and the file it was in.

This recent post from i>Lior Messinger looks at five frameworks he considers absolutely necessary for every software developer out there:

If you are an architect with a team of developers, or one developer with a team of managers, here's a list of a set of modules, frameworks and strategies you should have in mind. Not all of them would necessarily apply to you, but if I were you, I would at least think about each one. So if you are starting a new project - lucky you - from scratch, or coming to an old project with a mandate for change, here's a small checklist.

The five types are:

• a good ORM (Object Relational Mapping) layer
• a tiered framework (splitting out interface, business and database logic layers)
• a event-based framework
• a caching framework (or some form of easy-to-use caching)
• an error/tracing framework

Some frameworks, like the Zend Framework, come with most of these already built in, reducing the need for more than one sort of technology stack.

Tobias Schlitt has posted about this year's FrOSCon conference happening August 23rd and 24th near Bonn.

One of the most amazing German OS events is right in front of the door. Since the organizers of the FrOSCon expect a massive ammount of visitors, they ask everyone kindly to register on their website. If you did not do so, yet, take your heels and do so!

He mentions some of the "PHP VIP" that'll be there including Marcus Boerger, Derick Rethans and Rasmus Lerdorf as well as the dedicated PHP track they'll have this year. You can find out more information about the conference from the PHP@FrOSCon website.

New on the Developer Tutorials blog today is this look at handling background processes from your PHP script:

You've checked and double checked the integrity of user input, and you're doing some serious processing. There's only one problem: it's too slow. There's a simple solution: forking your processing script, and running the code as a background process asynchronously. It can email your user when it's done: they'll wait. In this tutorial, I'll show you how to get started with background processes in PHP.

Akash gives examples of the three keys to background processes - starting the script via an exec, talking to the process by passing additional parameters and including code to monitor the state of the background process via something like a MySQL "sessions" table that the script writes to.

Devshed continues their series looking at the use of destructors in PHP5 applications with part three, a method for keeping track of objects you've created during execution.

In this third part of the series, I'm going to show you how to retrieve some useful information about a specific object, including its properties and methods, prior to its being destroyed by the PHP parser via the implementation of a simple destructor.

Their new user class extracts the details about each of the objects right before they're destroyed via a call to get_object_vars and a loop to display the property and its value.

The admins over on the PHP-GTK Community site have announced a new resource PHP-GTK ircers can take advantage of - a new bot that hangs out in the #php-gtk channel over on the Freenode IRC network with an aim to be as helpful as possible.

The PHP-GTK.eu community site is now host to an IRC bot named Gataka (for "GTK"), helping users on the Freenode IRC channel for PHP-GTK, at irc://irc.freenode.net/php-gtk.

Currently is has an API interface (for PHP-GTK elements), user tracking and the ability to learn factoids. They're even starting to look for input regarding new features (log publication, in this case).

Greg Beaver points out the numerous releases that were made in the PEAR community today - including an update to the PEAR website itself.

OK, today's release party wins. I've just uploaded the 8th package for release, and it's a very significant day of releases.

The three updates made today are:

• An update to the PEAR website that allows for patch tracking in the bug tracker
• The latest version of PHP_ParserGenerator - version 0.1.5
• and the release of the first, full-featured parser for PHP - PHP_Parser along with a "companion", PHP_Parser_DocblockParser