Being a PHP Lumberjack : Comments
March 23, 2005
Comments
Nice article, looking forward to more in the series.
Also, this article has generated new and unique Google Adwords when compared with those attached to other articles.
Oh my, I just saw that. Certainly not our intent, but pretty comical in general. The ads I am seeing loaded up are: “Affordable Tree Service” and “Handheld Bug Zapper” ....haven help us.
Good, simple article. I would be interested in seeing your more advanced implementation, like from your “substantially abstracted CMS”.
Yeah, I noticed the google ads too. I get similar results when writing about XUL trees. :)
Regarding a more advanced implementation, I don’t have one that’s easily extracted from its code base. This is usually a matter of if-elses all over the place determining what conditions must be met in order to do just what sort of logging/printing.
Although I personally haven’t started using it too (having done hand-debugging for many years now, and being quite good at it), there IS a PHP debugger that’s not entirely out of one’s pocket: DBG. And there is a very affordable, excellent PHP IDE which uses DBG extremely efficiently : PHPEdit. I have been using PHPEdit for a long time now, and, having tried a host of other editors, I can honestly say it is the best IDE out there, and that by a far shot.
DBG/PHPEdit allows you set breakpoints, step into and out of code, watch the evolution of variables, examine the execution stack etc . . . everything you’d expect from a debugger!
Nice simple article, I hope a part II will be available.
I usually print a debug result and the end of all interpreted script while coding big php system applications (and CMS) : var_dump($_GET),var_dump($_POST),var_dump($_SESSION) and some often-used variables, like sql querie, keys, homemade detailed error variables, etc.
I think separating code into many include files simplifies debuging (and helps coding!), when it’s well done.
Actually I was a little disappointed by this article. I was looking for coverage on what the standard logging techniques are for PHP and I guess I got it. However, although the article had what appears to be coverage, and is well written, the actual treatment of logging needs was pretty shallow. For example, compare logging frameworks (even the little ones) that come with or are available for languages like Java, Python, Ruby, etc.
I would have thought logging discussions would start with “well you can always just print stuff out, or to a file, but for more control, we should …”
Thanks anyway.
Christo, good point. If you would have left you email address in the contact form or even your URL we should have contacted you and asked you to write a piece you felt was more detailed.
You can use this
feed to keep up with the comments made on this article.