In a recent post to his blog Mark Hamlin talks about some of his difficulties in getting XDebug and Netbeans working together from an OSX machine hitting a Ubuntu server.

For the past 18 months working with PHP, i've primarily used alternatives, not out of preference, but because netbeans xdebug integration consistently failed me. It would (might) work with a remote apache, but would not play with scripts executed remotely from the command line. I could be fairly sure my xdebug config was sound as I no problems with MacGDB and PHPStorm whatsoever.

With a little more investigation, he discovered that it was the OSX firewall causing issues. He found that, with a new incoming connection came a confirmation box to approve the connection. This, of course, wasn't passed along to Netbeans so he never saw it. In the end, he set up a reverse SSH tunnel to bypass the firewall completely (command included).

Kevin Schroeder has a suggestion for developers out there - you should hit F5 more often:

The best developers hit "Refresh"? No. Well, yes, but that's not what I was referring to. F5 is what you hit in Zend Studio/PDT to "Step Into" during a debug session. A LOT of developers just look at an API, or code completion, write to it, commit, deploy and they're done. I have found that the best developers not only build to the API, whatever it is, but also watch the API at work.

In his opinion, he's never met "the smartest PHP developer", someone who couldn't learn something from stepping through someone else's code. You don't even need to fully know what's going on to catch helpful bits of code or new ideas you may not have thought of along the way. He also suggests conferences (like ZendCon) are an excellent place to pick these same things up, just in person.

Having been asked what people can do to become better programmers, I would respond by saying that hitting F5 would be pretty high on my list.

Robert Basic has posted a quick hint for Netbeans users on how they can debug two (interlinked) projects at the same time in the same debugger instance.

I'm currently working on some Symfony2 bundles and I have one Netbeans project for the main Symfony2 app and one project for the bundle. [...] The debugger starts for the "main" project, which is the Symfony2 app, but setting breakpoints with Netbeans (y'know, by clicking the line number) for the bundle doesn't really work, as those are in the other project and not in the debugged one, rendering the whole debugging useless.

The fix is pretty simple, if a bit manual - simply place xdebug_break calls in your code anywhere to tell the debugger to stop there. It's not as friendly and automatic as just clicking in the IDE, but it gets the job done. For more information on Xdebug, see their site.

Rafael Dohms has, in a recent post to his blog, shown how to set up NetBeans to use PHPUnit tests with XDebug. This allows him to run his unit test and track down problems with the handy XDebug extension right from his IDE.

Every now and then you run into this weird situation in your code, where something that was supposed to zig is now zagging and it makes no sense whatsoever. For me this ends up happening in my unit tests since i'm not running everything in the browser everytime and since my tests usually run more scenarios then a regular browser run, that's where the weird stuff happens.

He shows you how to configure NetBeans with the path to your local PHP installation, configure the xdebug settings in your php.ini and how to coordinate the PHPUnit install to send its output to your NetBeans instance. Then it's as simple as clicking "Debug" on the project and running "phpunit-debug" from the command line.

In a new post to his blog today Chris Shiflett takes a look at something a lot of PHP developers take for granted, the language's session handling, and some things you can do to help debug them when things go wrong.

For many PHP developers, calling session_start() and using $_SESSION for stuff you want to persist from page to page is all there is to know about sessions. This is understandable, because PHP's native session support is so simple and reliable. But, what if something goes wrong?

He points to two older articles he's written about some more advanced session handling and includes sample code acting as a walk-through for locating your problem spot. He focuses in on the read() handler method and shows how to debug the data flowing in and out (and some of the information he commonly logs from it).

Sebastian Bergmann has a recent post about how you can use git and PHPUnit to debug your application and find out when the offending code was added.

git bisect can be used to find the change that introduced a bug. It does so by performing a binary search on the list of commits between a known good and a known bad state of the repository. A tool such as PHPUnit can be invoked at each step of the binary search to check whether or not the current state is broken.

He gives an example of some failing tests where the return value isn't equal to what it should be. Finding the hash of the initial commit, he compares that with the "git bisect" command to point to the "good" and "bad" points in the timeline. Command line examples are also included in the post.

Derick Rethans has a new post to his blog today looking at a way you can dig inside of a variable that might be causing you trouble with the help of the debug_zval_dump method - a PHP function that dumps a string representation of an internal zend value directly to the standard output method (usually an "echo").

The internal representation of a PHP variable container (called zval), contains the type and value of a variable, but also whether it is a reference and what its refcount is. Due to PHP's copy-on-write policy, one specific zval container can be used by multiple variables at the same time as we will see in a bit.

He talks about what the "refcount" field of a variable means and some simple examples showing a single reference, more than one symbols and how PHP handles a "split upon assignment". He also mentions Xdebug's method xdebug_debug_zval that takes in a variable name rather than the variable itself.

Brandon Savage has a new post to his blog today with a list of five tools he can't live without in his day-to-day development work. These range from the physical hardware under his fingertips down to software that helps get the job done.

Every developer has a toolkit of favorite tools and applications that help them develop more effectively. Being individuals, developers often differ (and in some cases, argue) about the tools they use. One of the most frequent questions I'm asked is "what are the tools you use?" and that was the genesis of this blog post. While there are many tools that I would feel lost without, I have listed the five that I see as most crucial to my ability to effectively develop software.

His list includes the physical - a fast machine with dual monitors - and less physical - bug tracking software, an IDE he feels comfortable with and a few Firefox plugins to make debugging simpler. There's a few comments on the post from other developers sharing their "must haves" in their development too.

Tony Lukasavage has a new post to his blog about debugging your PHP applications with IntelliJ and XDebug on a WAMP install.

If you are a serious PHP developer and have not given debugging a fair chance, or a chance at all, you are killing yourself. So let's do this thing from the ground up. WAMP, XDebug, IntelliJ, and magic. Follow these steps (for Windows) to reach my recent state of elightenment and PHP debugging bliss.

It's a sixteen step process, but don't let that scare you off - it's made up of lots of little steps like "make a phpinfo() page" and "download IntelliJ IDEA". The rest is actually setting up a new PHP project, dropping in a breakpoint and mapping the scripts to run on your local machine's WAMP install.

Christoph Dorn has a new post today showing how to get the FirePHP tool to work together with Zend Server on an AWS instance to help make your debugging even simpler.

FirePHP can nicely complement the built-in tools available when using Zend Server and can be easily made available to all provisioned sites. This tutorial illustrates how to setup FirePHP 1.0 for all virtual hosts on a Zend Server AMI on Amazon EC2.

He steps you through the process of getting FirePHP installed and working in your browser as well as pulling the "firephp.phar" file in on the Zend Server side. Configuration is pretty simple - the lines for the Apache config are included and the JSON needed to make the credentials for FirePHP are too. A simple test script is created and an auth key is set and you should be up and running.