Author of DBG php debugger is talking about remote debugging

For a while now we wanted to pick the brains of Dmitri Dmitrienko, the author of dbg debugger - arguably the best PHP debugger available today. dbg is currently used by Maguma, Waterproof (PhpEDIT), PHPEclipse and many others, so we thought it would be a good idea to ask the guy who wrote it to share his thoughts about PHP debugging. Leading NuSphere development team has proven to be somewhat time consuming for Dmitri and there are only 24 hours in a day, so we simply ambushed the guy when he was just about to have lunch at 4 pm, which I guess is somewhat early for him. Here is what Dmitri told us between a sandwich and a cup of coffee (we brought sugar and cream).

Q: Dmitri, if you look at the postings on NuSphere's Forum you can't help but notice that absolute majority of the people look at the postings related to the debugger. You read every single post on the Forums - I don't know how you do that, but it's a fact - so, what are the people looking for in PHP debugger?

A: Actually, can I plug in the link to NuSphere Forum? It is here: http://support.nusphere.com/index.php - the place is open 24/7! Now, to give a short answer to your question - the people want remote debugging.

Q: Could you explain what does it mean?

A: In today's PHP world it's hard to impress anybody with the ability to set a break point or step through the code in debug mode. Even the profiler is pretty much taken for granted. These features are available in many PHP IDEs and have become pretty much a "must have" to get the script to work. The confusion I think comes from the definition of what people mean by "working script". The fact that the script does what the developer wants it to do in the development environment doesn't mean that the script is all set.

Q: Are you talking about the trials and tribulations of deployment to production?

A: Sure, you got it. PHP script doesn't exist in its own isolated world, there is lots of services that the script uses, such as databases, webservices etc. There is also an environment supplied to the script by the Server. I am talking about well known $_SERVER, $_ENV and other variables that PHP developers know and use.

Q: Know, use and love?

A: They do up to the moment when the script is deployed to production server and then the things change. Chances that fully tested and "working" script will work the first time it is deployed in production are slim to none. You can bet your house on the fact that development and production server provide different environments - even if the servers are running on the same hardware and software platforms.

Q: What would be an example of such difference?

A: The list is endless! You can start by looking at the ways IIS or Apache run php.exe interpreter and Apache loads php4apache.dll. The difference in $_SERVER, $_ENV is a guarantee. However, taking this difference into account during development is not quite feasible. We think that the debugger is there to help with the problem - you just need to make one of the production servers available to the developers to debug their application. This is what we call Remote Debugging.

Q: Our users often hear the term "native debugging" - what is that?

A: Native debugging is another term for pretty much the same thing - we call it native because the developer is debugging the scripts in the exactly the same environment as in production.

Q: Ok, so now we have many developers debugging their scripts on the remote production server or on its clone - what are the challenges of this situation and how would you deal with them?

A: First thing first - you need to provide the developers with the access to source code. Our dbg debugger will let you step through the code and access to all variables even if remote file doesn't have a local copy. Remote debugging has actually become very easy when we introduced NuSphere Debugger Toolbar for Internet Explorer. However, eventually the developer will need to deploy the changes back to production server. This can be done with the help of Samba on Unix or Linux and Shared Directories on Windows. PhpED will also help you use FTP (including FTP/SSL), SFTP, SCP, WEBDAV etc. - we support every major deployment protocol. Second task is to isolate the workspace of each developer on the server. This is especially important on the larger projects - you really don't want to destabilize the entire system by the changes made to one of the modules. Obvious solution is to have multiple test servers available for the development team but as you can guess it is not always possible. However there are many ways to do it even on the single server.

Q: Can you name a couple?

A: Sure - using virtual hosts is a great approach, both Apache and IIS support that. Another trick is to allocate multiple IPs to the server and run multiple webservice daemons each with associated with its own IP.

Q: Great. Now, let me ask the obvious question - shouldn't I be concerned with security of remote debugging? After all we are talking about possibly production server opening itself up for talking to more clients and possible taking and sending the source code over network.

A: 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. In this case we always recommend using SSL (SSH) versions of FTPS (FTP/SSL), SFTP and WEBDAV/SSL for files deployment and SSH tunneling for secure remote debugging. 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.

Q: Dmitri, thank you so much for doing this - I am just about ready to let you finish the sandwich.

A: (Laughing) Oh, thanks, you are really generous - the coffee is now ice cold too.

Q: We'll get you a fresh pot, don't you worry. Just one last parting question: are you happy with the state of dbg?

A: I am never happy with the state of the software - you know that (laughing). But I have to say that since the first release of dbg almost 6 years ago we only had less than 10 major defects reported and all of them in the first couple of years after the release - I think that this is remarkable testimony to the stability of the module. Also, the fact that Waterproof, PhpEclipse, Maguma and many other PHP IDE's vendors use the free version of dbg debugger pretty much testifies to the quality and the functionality of our DbgListener, which is well known to so many PHP developers.

To learn more about Remote Debugging with NuSphere PhpED and for FREE trial go here.

To learn more about Remote Debugging with NuSphere PhpED and for FREE trial go here