Jeremy Cook sent in a new tip about a new debugging extension for Google Chrome that hooks into the DBG debugger to help you test your PHP applications - a DBG Debugger Helper (currently in version 0.0.0.1).

For those using the DBG debugger for PHP development, this minimal extension provides a convenient way to initiate debugging and profiling sessions. The most likely users will be anyone using Nusphere's PhpED. This commercial PHP IDE includes a robust, up-to-date, and full-featured DBG debugger. [...] Installation, configuration, and use is quick and simple. While you can configure the clienthost, port, and session ID entries of the Options dialog, this is not required.

The extension makes it as simple as one click to start and stop the debugging process that will watch round trip requests and catch errors to allow DBG to provide things like backtraces, work through the script step by step.

Douglas Clifton has the next part of his "PHP Specificity" series posted today - a brief look at debugging in PHP applications.

In this fourth installment of the PHP Specificity series I'm going to break from the theme of content management packages momentarily and get into a topic that is not so dear to the programmer's heart. Debugging is a necessary evil and can be painful at times. But the reward, when it happens, is that eureka moment when you find the bug and squash it.

He mentions two helpful tools - DBG (though dead?) and the very popular XDebug that includes a profiler with Cachegrind output.

In the HEDIR (Human Edited Directory) today, there's a post of an interview with Dmitri Dmitrienko, the author of the DBG Debugger, a popular PHP debugging option.

They talk a bit about the debugger and about what developers are really looking for when it comes to debugging (remote debugging). Dmitri mentions some of the "trials and tribulations" of testing and moving code around to get it out to production. He also gives his opinion on the interviewer's concerns about remote debugging:

It goes without saying that the access to the server should be given only to authorized personnel, especially if the test server is located outside of local intranet. You should also make sure that remote debugging is done by qualified developers only. The person, who started remote debugging session has a great power - he or she can run SQL statements, make calls to fopen or fwrite or other equally dangerous functions. That is why we never get tired of saying - use SSH tunneling for remote debugging.

In the HEDIR (Human Edited Directory) today, there's a post of an interview with Dmitri Dmitrienko, the author of the DBG Debugger, a popular PHP debugging option.

They talk a bit about the debugger and about what developers are really looking for when it comes to debugging (remote debugging). Dmitri mentions some of the "trials and tribulations" of testing and moving code around to get it out to production. He also gives his opinion on the interviewer's concerns about remote debugging:

It goes without saying that the access to the server should be given only to authorized personnel, especially if the test server is located outside of local intranet. You should also make sure that remote debugging is done by qualified developers only. The person, who started remote debugging session has a great power - he or she can run SQL statements, make calls to fopen or fwrite or other equally dangerous functions. That is why we never get tired of saying - use SSH tunneling for remote debugging.