Re: development techniques
On Friday, January 10, 2003, at 12:07 pm, Mark Fowler wrote: On Thu, 9 Jan 2003, Jim Martinez wrote: Is there some way to improve this cycle : edit code - refresh browser - possibly look at the error log - edit code - ... No one seems to have mentioned WWW::Mechanize (or if they have I've missed it.) It's a simple module that allows you to interact with LWP like it's a web browser (i.e. click on that link, enter these values into the form, etc) abstracting away the actual parsing of the HTML. [snip] I second that suggestion. Very useful module. Especially since it's a subclass of LWP::UserAgent - giving it added power (e.g. set different user agents to test sites that server different things to different browsers). Adrian
Re: development techniques
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.
Re: development techniques
On Thu, 9 Jan 2003, Jim Martinez wrote:
Is there some way to improve this cycle : edit code - refresh browser -
possibly look at the error log - edit code - ...
No one seems to have mentioned WWW::Mechanize (or if they have I've missed
it.) It's a simple module that allows you to interact with LWP like it's
a web browser (i.e. click on that link, enter these values into the form,
etc) abstracting away the actual parsing of the HTML.
Links:
http://www.perladvent.org/2002/16th/
http://search.cpan.org/author/PETDANCE/WWW-Mechanize/lib/WWW/Mechanize.pm
It's quite easy to integrate this with a test suite. You can start doing
things like:
#!/usr/bin/perl
# turn on the safety features
use strict;
use warnings;
# declare three tests
use Test::More tests = 3;
# create a new web browser
use WWW::Mechanize;
my $browser = WWW::Mechanize-new();
# see if we can get the front page of search.cpan.org
$browser-get(http://search.cpan.org/;);
ok($browser-{res}-is_success, search.cpan.org);
# see if we can get a search page back
$browser-form(1);
$browser-field(query,Acme::Buffy);
$browser-click();
ok($browser-{res}-is_success, module listing back);
# something that will fail
$browser-get(http://2shortplanks.com/nosuchurl;);
ok($browser-{res}-is_success, no such url);
This prints out:
1..3
ok 1 - search.cpan.org
ok 2 - module listing back
not ok 3 - no such url
# Failed test (test.pl at line 26)
# Looks like you failed 1 tests of 3.
Hope that helps.
Mark.
--
#!/usr/bin/perl -T
use strict;
use warnings;
print q{Mark Fowler, [EMAIL PROTECTED], http://twoshortplanks.com/};
development techniques
The start of a new year has me thinking of how I can improve things.
Like the way I develop, debug and test code.
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.
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 ... )
Is there some way to improve this cycle : edit code - refresh browser -
possibly look at the error log - edit code - ...
Or maybe you use another approach that's better?
Happy new near (9 days late),
Big big Jim
RE: development techniques
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)?
Bingo. :-)
Do you
pepper code with :
print option: . $option{$foo . br if $debug;
If it's a longer-term debugging option that I might want again later then I
might make a debug() method where I'll do
debug('this worked ok') and the debug() method might examine a flag to see
whether it should do anything with that message.
Or a log() method that recognizes various levels of messages and obeys a
debug_level setting or something. I once used a Java package (the name
escapes me but it was probably something simple like jLog) that worked sort
of this way, though it also had some xml config files and such... anyways,
I'm sure there are plenty of perl modules to do something similar, but the
debug() is a fairly effective 2 minute alternative. If's it just a quick
one-time debug, I'll typically just use a warn or similar.
Fairly low tech, huh.
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 ... )
This sounds more like a testing suite than regular old
debugging-while-you-go. Probably a place for both.
Is there some way to improve this cycle : edit code -
refresh browser -
possibly look at the error log - edit code - ...
Honestly, this method has always been very efficient for us and most of the
time we don't need anything more sophisticated for devel/debug. Now for
more formal testing, that gets trickier for us and we're currently looking
for a good way to build some automated tests of our code and our web
interface without it getting too unwieldy. This will probably be where we
spend a lot of time in the first part of the year. Maybe LWP will be handy
here.
-Fran
RE: development techniques - specifically debug methods
There is a good technique in the mod_perl cookbock that talks about using
a Debug module with exported constants. If you program to the API where
all of your code is compiled into bytecode at server startup into
discrete packages then this means that all of your debug if() sections
sprinkled throughout the code are not included as part of the run time
footprint. This can be quite nice if you have largish chunks of code that
should run only in debug mode.
I guess this might work for registry scripts too, the 1st time the are
compiled.
On Thu, 9 Jan 2003 [EMAIL PROTECTED] wrote:
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)?
Bingo. :-)
Do you
pepper code with :
print option: . $option{$foo . br if $debug;
If it's a longer-term debugging option that I might want again later then I
might make a debug() method where I'll do
debug('this worked ok') and the debug() method might examine a flag to see
whether it should do anything with that message.
Or a log() method that recognizes various levels of messages and obeys a
debug_level setting or something. I once used a Java package (the name
escapes me but it was probably something simple like jLog) that worked sort
of this way, though it also had some xml config files and such... anyways,
I'm sure there are plenty of perl modules to do something similar, but the
debug() is a fairly effective 2 minute alternative. If's it just a quick
one-time debug, I'll typically just use a warn or similar.
Fairly low tech, huh.
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 ... )
This sounds more like a testing suite than regular old
debugging-while-you-go. Probably a place for both.
Is there some way to improve this cycle : edit code -
refresh browser -
possibly look at the error log - edit code - ...
Honestly, this method has always been very efficient for us and most of the
time we don't need anything more sophisticated for devel/debug. Now for
more formal testing, that gets trickier for us and we're currently looking
for a good way to build some automated tests of our code and our web
interface without it getting too unwieldy. This will probably be where we
spend a lot of time in the first part of the year. Maybe LWP will be handy
here.
-Fran
--
+ Jon Larsen; Chief Technology Officer, Richweb.com
+ GnuPG Public Key http://richweb.com/jlarsen.gpg
+ Richweb.com: Providing Internet-Based Business Solutions since 1995
+ Business Telephone: (804) 359.2220
+ Jon Larsen Cell Phone: (804) 307.6939
Re: development techniques
On Thu, 09 Jan 2003, Jim Martinez wrote:
The start of a new year has me thinking of how I can improve things.
Like the way I develop, debug and test code.
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;
print option: . $option{$foo} . br if $debug;
Fairly low tech, huh.
yepi, I do that.
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 ... )
I think the advantage of using LWP for testing is that you could write a
large series of tests which could be run frequently. So, if you make some
little change way down in the guts of your code, you can then run all your
tests to make sure everything is still working without having to worry
about missing something along the way. So, it may seem like a lot of
work up front, but in the long run you are better off.
There is other stuff out there that you can use for testing. Test::Unit
come to mind, and there is a test framework I read about called puffin
(http://www.puffinhome.org/) which sounds like it could be useful.
andrew
Is there some way to improve this cycle : edit code - refresh browser -
possibly look at the error log - edit code - ...
Or maybe you use another approach that's better?
Happy new near (9 days late),
Big big Jim
RE: development techniques
--
I find ab to be very quick to type
ab('processing...');ab(\%whats_in_here);
use Data::Dumper;
sub ab {
return if exists $ENV{SERVER} $ENV{SERVER} eq 'PRODUCTION';
my $msg=shift;
if (ref $msg) {
print STDERR scriptname: . Data::Dumper-Dumper($msg) . \n;
} else {
print STDERR scriptname: $msg\n;
}
}
---
This is pretty easy to use...
use Time::HiRes qw(gettimeofday tv_interval);
our($start_time,$last_time);
sub handler {
$start_time = $last_time = [gettimeofday];
timer(subname.1);
timer(subname.2);
timer(subname.2a);
}
sub timer {
return if exists $ENV{SERVER} $ENV{SERVER} eq 'PRODUCTION';
my $msg=shift;
my $new_time = [gettimeofday];
ab(join
':','Split',substr(tv_interval($last_time,$new_time),0,6),$msg);
ab(join
':','Total',substr(tv_interval($start_time,$new_time),0,6),$msg);
$last_time = $new_time;
}
---
I have these in my ~/.vimrc
:ab timtim sub timer {#{{{CRreturn if exists $ENV{SERVER}
$ENV{SERVER} eq 'PRODUCTION';CRmy $msg=shift;CRmy $new_time =
[gettimeofday];CRab(join
':','Split',substr(tv_interval($last_time,$new_time),0,6),$msg);CR
ab(join
':','Total',substr(tv_interval($start_time,$new_time),0,6),$msg);CR
$last_time = $new_time;CR}CR#}}}CR
:ab abbb sub ab {#{{{CRreturn if exists $ENV{SERVER} $ENV{SERVER}
eq 'PRODUCTION';CRmy $msg=shift;CRif (ref $msg) {CR
print STDERR scriptname: . Data::Dumper-Dumper($msg) . \n;CR}
else {CRprint STDERR scriptname: $msg\n;CR
}CR}CR#}}}CR
The funny {{{ and }}} are for vim's foldmethod=marker
---
Yes, lwp-request for testing.
I make sure my output is XHTML, so I can use XPath to do things like [[look
up all href= of a]], and try running lwp-request on them, too
(non-recursively, of course, but it's all Intranet, regardless)
---
--
This message is intended only for the personal and confidential use of the designated
recipient(s) named above. If you are not the intended recipient of this message you
are hereby notified that any review, dissemination, distribution or copying of this
message is strictly prohibited. This communication is for information purposes only
and should not be regarded as an offer to sell or as a solicitation of an offer to buy
any financial product, an official confirmation of any transaction, or as an official
statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or
error-free. Therefore, we do not represent that this information is complete or
accurate and it should not be relied upon as such. All information is subject to
change without notice.
Re: development techniques
I use HTTP::WebTest for that sort of regression testing, just to make sure nothing breaks along the way. I also use LWP and HTML::LinkExtor to check some dynamically generated pages to make sure it's still generating valid links. (It broke once, so after fixing I added a test for it... ) For debug messages I generally just use warn statements temporarily, then remove them when done. I've toyed with Log::Log4perl a little bit, and will probably use that if I ever decide it's worth the setup time. I think it's based on a Java logging tool called Log4J or Log4Java or the like. Wes Andrew Wyllie [EMAIL PROTECTED] on 01/09/2003 04:22:43 PM Please respond to [EMAIL PROTECTED] To:Jim Martinez [EMAIL PROTECTED] cc:mod_perl list [EMAIL PROTECTED] Subject:Re: development techniques On Thu, 09 Jan 2003, Jim Martinez wrote: (snip) 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 ... ) I think the advantage of using LWP for testing is that you could write a large series of tests which could be run frequently. So, if you make some little change way down in the guts of your code, you can then run all your tests to make sure everything is still working without having to worry about missing something along the way. So, it may seem like a lot of work up front, but in the long run you are better off. There is other stuff out there that you can use for testing. Test::Unit come to mind, and there is a test framework I read about called puffin (http://www.puffinhome.org/) which sounds like it could be useful. andrew
Re: development techniques
mpm writes:
Debugging of the applications now looks like:
$ced-log('warn',No price for this product)
Here's an an alternative that we've evolved from Modula-2 to C to Java
to Perl :-) Firstly, I try to distinguish between stuff I always
want to see and debugging messages. The former we call logging, and
wrap it in a class Bivio::IO::Alert which also outputs the source line
of the caller, time, etc. configurably. This is very handy for
figuring out what's complaining.
The latter we call trace messages which is presented by
Bivio::IO::Alert, but is defined as follows:
_trace('No price for this product') if $_TRACE;
The if $_TRACE is an optimization, which can be left out but avoids
the overhead of argument evaluation.
The _trace() subroutine and $_TRACE variable is dynamically generated
by our Trace module, which any package can register with as follows:
use vars ('$_TRACE');
Bivio::IO::Trace-register;
You can then configure tracing with two configuration values, which
also can be passed on the command line. Here's an example:
'Bivio::IO::Trace' = {
package_filter = '/Bivio/ !/PDF/',
call_filter = '$sub ne Bivio::Die::_new',
},
Here I want to see tracing from all packages with the word Bivio in
their names but not PDF, and I want to ignore individual calls from
the subroutine Bivio::Die::_new. In practice, we rarely use the
call_filter, so from any bOP command line utility, you can say, e.g.,
b-release install my-package --TRACE=/Release/
which translates to:
'Bivio::IO::Trace' = {
package_filter = '/Release/',
},
You can set the call filter or any other configuration value from the
command line with --Bivio::IO::Trace.call_filter='$sub ne foo'
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.
You might want to check out Bivio::Test::Language::HTTP. It parses
the incoming HTML, and allows you to write scripts like:
test_setup('PetShop');
home_page();
follow_link('Dogs');
follow_link('Corgi');
follow_link('Female Puppy Corgi');
add_to_cart();
checkout_as_demo();
This particular code does a number of things including validating that
animals are getting in the cart. Additional script language is defined in
Bivio::PetShop::Test::PetShop, which subclasses
Bivio::Test::Language::HTTP, which provides follow_link and home_page
generically.
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).
I agree. A very important practice is unit testing, especially with
large applications. For an alternative to Test::More and xUnit, have
a look at Bivio::Test, which allows you to write tests that look like:
Bivio::Test-unit([
'Bivio::Type::DateTime' = [
from_literal = [
[undef] = [undef],
['2378497 9'] = ['2378497 9'],
['-9'] = [undef, Bivio::TypeError-DATE_TIME],
['Feb 29 0:0:0 MST 1972'] = ['2441377 0'],
['Feb 29 13:13:13 XXX 2000'] = ['2451604 47593'],
['1972/2/29 0:0:0'] = ['2441377 0'],
['2000/2/29 13:13:13'] = ['2451604 47593'],
['Sun Dec 16 13:47:35 GMT 2001'] = ['2452260 49655'],
],
from_local_literal = [
[undef] = [undef, undef],
['2378497 9'] = ['2378497 7209'],
['-9'] = [undef, Bivio::TypeError-DATE_TIME],
['Feb 29 0:0:0 MST 1972'] = ['2441377 7200'],
['Feb 29 13:13:13 XXX 2000'] = ['2451604 54793'],
['1972/2/29 0:0:0'] = ['2441377 7200'],
['2000/2/29 13:13:13'] = ['2451604 54793'],
],
],
]);
We can write a lot of tests very quickly with this module. We don't
always do this, but every time we don't, we regret it and end up
writing a test anyway after figuring out that we still aren't
perfect coders. :-)
Yet another trick we use is executing a task from within emacs or on
the command line. A task in bOP is what the controller executes
when a URI is requested. For example,
b-test task login
There are two advantages to this: 1) you don't have to restart Apache
and go to another program (browser or crawler) and 2) you get the
stack trace when something goes wrong and you can type C-c C-e (in
emacs) to go right to the error. We added this facility recently,
because we got tired of the internal server error restart loops.
They slow things down tremendously, and anyway, you often want to look
at the HTML to see if some thing has changed. The output of 'b-test
task' is the resultant HTML and any mail messages that would be sent,
which you can then search on immediately directly in emacs without
first having to say Tools - View Source and get
Re: development techniques
I use my debugging module
(http://cpan.perl.org/authors/id/T/TB/TBOLIOLI/Log-AndError-0.99.tar.gz)
which prints to stderr (hence I got bit by the mod_cgi issues with
read/write deadlocks on pipes) while tailing the logs, etc. I am looking
to include a syslog and other output drivers to my mod which should
allow for more fancy versions of the tail -f method.
The key to the print xxx if $debug method is to use stderr, categorize
diag msgs, have multiple levels and lastly to have many lines of code
marked to send diag info to the debugger. By using the module I have
eliminated the if statements and simply pass diag info to the debugger
which in turn determines if the msg is of importance given current
debugging levels. This is more of a performance drag but it cleans up
the code plenty.
Tom
Jim Martinez wrote:
The start of a new year has me thinking of how I can improve things.
Like the way I develop, debug and test code.
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.
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 ... )
Is there some way to improve this cycle : edit code - refresh browser -
possibly look at the error log - edit code - ...
Or maybe you use another approach that's better?
Happy new near (9 days late),
Big big Jim
--
-
Terra Novum Research
[EMAIL PROTECTED]
www.terranovum.com
(617) 923-4132
PO Box 362
Watertown, MA 02471-0362
Never meant half the things I said to you,
so you know,
there's a half that might be true.
- Glenn Philips
Re: development techniques
On Thu, 9 Jan 2003, Thomas Bolioli wrote: I use my debugging module (http://cpan.perl.org/authors/id/T/TB/TBOLIOLI/Log-AndError-0.99.tar.gz) which prints to stderr (hence I got bit by the mod_cgi issues with read/write deadlocks on pipes) while tailing the logs, etc. I am looking to include a syslog and other output drivers to my mod which should allow for more fancy versions of the tail -f method. Rather than re-inventing that wheel why not take a look at Log::Dispatch and Log4Perl. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: development techniques
Jim Martinez wrote: [...] 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 ... ) There are many benefits to using command line tools (which can be anything, but LWP::UserAgent and other packages in libwww-perl are a gift from god). Here are some of them off the top of my head: 1. You get the results as they come in (browsers tend to cash things). 2. You can program things: - make a sequence of request/response cycles based on a response - you can choose to display only certain bits of the response: e.g., show me only headers, only the body, only the size of the body, only certain keywords, etc. 3. You can easily reproduce sequences or specific inputs, especially when there is a sequence of request/response pairs to get to some state. 4. you can involve someone else in debugging the problem, without needing to come down (fly?) to his cubicle to explain how a certain anomaly is reached. So you can educate your users to create test scripts that reproduce the problem. 5. We (mod_perl programmers) very often use the single server mode (httpd -X) to test things. If you have a page with embedded images, it's going to take a while before you get the output, because you have only one server (this is documented in the guide). 6. Filling in forms. - You can prefill forms programmatically (saving you a lot of time and protecting from mistyping things) - You can provide inputs which with normal manual typing won't be possible (so you can test your program's behavior when a 10MB core file is submitted as a fname form's field). ... I guess there are many more things that could be added here, you get the idea. Apache::Test is one of the new tools that work with both versions of Apache (and mod_perl and other mod_*). If you are a 3rd party mod_perl module developer (CPAN or in-house) you definitely should use it to test your module. See: http://perl.apache.org/docs/general/testing/testing.html The only major drawback to command line tools I can see is when you need to observe the html as is (e.g. you can't use some logic/parser to verify correctness), here the browser is definitely more useful. So knowing when to use what technique is important. Both have an application. (I've also noticed that lwp-get sometimes have a significant delay because it tries to resolve IPs, even though the request is made to localhost. So many times I end up using just 'lynx --source') Is there some way to improve this cycle : edit code - refresh browser - possibly look at the error log - edit code - ... Or maybe you use another approach that's better? Inject mod_perl into your brain ;0) Seriously, I don't think that the core of this cycle can be any different, other than the 'refresh browser' part. Talking about the 'refresh browser' part. In one of the companies I've worked for, there was this girl who did some perl coding and who was very inefficient, because she didn't know she could do a refresh. Many times she needed to debug a form to which you get after a sequence of several forms, all requiring a lot of things to type in. So every time she would change a bit of code (1 sec), she would go to the first form and start filling in a form, then submit, get to the next form, fill it in, submit, and so on, till she gets to the stage she is debugging, see that her fix didn't work and start all again from scratch. On the way she would enter different data by mistake which would lead her to the wrong stage and she would need to start from scratch again. I'm sure that you all have seen someone in your office do that. Do them and your company a favor, explain to them that you can do a refresh to resubmit just the last stage. Or even better, show them the light by pointing them to libwww-perl. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: development techniques
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
