> Do you develop with an xterm tailing the logs, an emacs window (or other
> editor) to edit the script and/or the packages (and on some occassions
> httpd.conf), and a web browser (on an alternate virtual desktop)? Do you
> pepper code with :
>
> print "option:" . $option{$foo . "<br>" if $debug;
>
> Fairly low tech, huh.
>
HI Jim,
I do this all the time ... but have tried to extend the tracing
technique.
I use a Tracer object that:
* captures a small amount of meta-info like the caller()
* prints out an object's internal state - all objects inherit a toString()
method which prints out a DataDumper-like snapshot
This is during development ... when something moves to production
I try *not* to use traditional logging ... mainly because bugs can be
missed, and I can't rely on trawling through the logs to find a
bug, instead - all major Exceptions turn into an email which is seen by at
least two people.
This means bugs don't go undetected for long - the idea is, the
more a bug is 'seen/tangible' the better the chance of stopping it
(http://london.pm.org/tech_talks/21_nov_2002/nigel/).
Finally for testing during development each major object has a
test script. For example:
testwebbrowser.pl -> WebBrowser.pm
testtrawler.pl -> Trawler.pm
The script acts as a test harness for the Object. This has reduced
the amount of time spent looking for bugs. The 'test first' methodology,
borrowed from XP, seems to be working - the next step will be to put the
individual test scripts into a Unit testing framework (e.g., Junit) and
run a daily battery of tests ...
NIge
--
Nigel Hamilton
Turbo10 Metasearch Engine
email: [EMAIL PROTECTED]
tel: +44 (0) 207 987 5460
fax: +44 (0) 207 987 5468
________________________________________________________________________________
http://turbo10.com Search Deeper. Browse Faster.
