[TYPO3-templavoila] OT: Support my debug sessions?

[Joerg Wagner]

Hi all,

as a NuSphere customer I just received a newsletter including an interview 
with Dmitri Dmitrienko, the developer of the debugger that NuSphere's PhpED 
uses. I thought it might be interesting to post here.
Couldn't the mentioned remote debugging feature be a great way to solve 
Typo3 problems that only occur on some servers? I have installed the 
debugger only on Windows, but there it is extremely easy - just a PHP 
extension to load and some lines of config in php.ini. I would, for example, 
be willing to open one of my production servers for remote debugging to core 
developers of T3.

BTW:  I am also not an affiliate or anything else beside a customer of that 
product...  ;)
Maybe Zend Studio also provides such a feature?

--
Jörg Wagner
DigiLog multimedia
----------------------------------------------

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.