Over on his blog, Eric Hogue has written an interesting article on the tools available to you for profiling your application. Click on in, the link is around here somewhere.

For those who haven’t put the reoccurring event in their calendar, this announcement is for you: Zend Framework Monthly Bug-hunt is here again! This Thursday, Friday and Saturday of November (the 18th, 19th and 20th 2010), we’ll be hosting our monthly bug hunt. For those of you unfamiliar with the event, each month, we organize the community to help reduce the number of open issues reported against the framework.

Debugging is an invaluable part of software development. I find it very useful in a variety of situations, for instance when I want to understand how a routine works or I need to get rid of a bug that is not exactly easy to fix just by reading the code.

My main goal in this post is to show you how to set your debugging environment with Eclipse PDT and Xdebug.

Continuing with the tutorial series, we will see how to debug the application we created in the #1 series of the tutorials.

In case you missed it, in our first tutorial, we have seen how to structure and code a brand new ZF application to use modules (you can also view that article here)

Debugging include easy to use methods of printing data on the screen, including ZFDebug Toolbar in order to manage all errors and queries, using the logger to log messages to Firebug, using a simple debug function that will place debug messages in your ZFDebug Toolbar, in a special Debug panel, using a redirect debug function in order to see what is happening during your requests, using redirect in a Controller plugin.

From Mihai Corlan’s blog:

bq. As your projects grow in size and more people get involved you’ll find yourself fixing more and more bugs. When this happens, one of the best friends a developer has is the debugger. In this paper, I’ll talk about some of the workflows and tools you can use to debug Flex and PHP projects.

bq. If you want to try the steps outlined here for yourself, you’ll need Flash Builder 4, a PHP and MySQL server (MAMP or WAMP will do just fine), Eclipse PDT, and XDebug.

Zend has published a new white paper covering Zend Server 5 root cause analysis capabilities via code tracing. Code tracing captures PHP application execution both in production and in test lab environments. This allows developers to replay reported problems instead of trying to re-create them. As a result, there is a dramatic decrease in time consumed by root cause analysis.

Dennis sent in a submission about a toolbar he’s created to work with the Zend Debugger (in an extension) for the Chrome Browser:

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.

On the Affinity Bridge blog today there’s a great post looking at the use of Xdebug and KCachegrind to pinpoint bottlenecks and possible refectoring points in your code in a bit more visual way. They use an example from their own development – a script that took around twenty minutes to run.

If you are not familiar with Xdebug it is an extension that allows you to profile your application for various things like performance and memory usage. One of its more usefull features is the ability to profile your application to find out what method are taking the longest so you can clean up those bottlenecks in your application.