On Thu, 9 Jan 2003, Jim Martinez wrote:
> Do you develop with an xterm tailing the logs, an emacs window ...
Yep.
> print "option:" . $option{$foo . "<br>" if $debug;
> Fairly low tech, huh.
We used to do this. Along with the move from registry to full mod_perl,
We changed the way that we did this. We created a module called CEDebug.
It stands for Cross Environment Debug(ging). We used the apache log
levels for ours to make it easy since for the bulk of our usage, the code
runs in a mod_perl environment.
Debugging of the applications now looks like:
$ced->log('warn',"No price for this product")
The first argument being the level and the second being the debugging
message.
The most obvious advantage comes from being able to set certain things to
be just debugging messages that dont' show up in our production logs and
have other things that throw crit errors. Especially for finding random
bugs, being able to change the configuration to print info messages, or
debug messages if needed is very usefully.
The less obvious advantage (but very very helpfull) comes from using this
in our objects. There are a number of different modudles to do the
debugging that all use the same format. So in our utility scripts, we use
CEDebug::Local instead of CEDebug::Apache. This prints out the message to
the console instead of sending them to the error_log that apache is
generating. For our daemons, we use CEDebug::LogFile. This creates a
nicely formatted log of everything the daemon has done.
Since Most of our objects get passed a CEDebug object durring creation, we
don't have to worry inside the object about If we should send debugging to
standard error, or find some file handle that is already open to write
to(I've seen this approach).
> At apachecon, a speaker (who neither bragged nor rambled) mentioned lwp
> use instead of (or to complement) the web browser portion.
> Will the use of lwp instead of a browser improve my coding ability (either
> in terms of speed or just improving my perl coding)? Seems like I'd have
> to spend too much time with the lwp script (tell it to first request the
> page then choose option A and B then hit the "submit" button ... )
We use LWP for testing. For things like cookies and argument parsing, LWP
is great for regression testing. For content, it is much harder to come
up with a pass/fail situation since the content can change, but still
possible.
> Is there some way to improve this cycle : edit code -> refresh browser ->
> possibly look at the error log -> edit code -> ...
I haven't found a better way to do web development testing durring
development. Possibly writing the test first would provide some
improvement since you know when you have completed the change(see XP
docs).
Scott
