tilly: you raise a good point. This script is something that I was assigned to write and thought I would offer to others in the event that they were called upon to perform a similar task. I can see a valid reason for such a script if one has a proper development environment set up:
- Development area: Here's where geeks like myself play around and create marvelous works of art. Here, we can experiment and do what we will.
- Staging: Here's where the development scripts get rigourously tested. QA occurs here (and that should be Quality Verification, not Quality Assessment, but that's a personal rant). The environment here should be an exact duplicate of what's in production.
- Production: Duh.
Later on, I'll have individual lines like this:#/* use warnings; use CGI::Carp qw( fatalsToBrowser ); use CGI::DebugVars; my $debug = CGI::DebugVars->new; #*/
If I am copying over twenty programs, this script will automatically comment out those lines (amongst others) while simultaneously copying the code to the proper area. The problem with my code, IMHO, is not the code itself, but our lack of a proper staging area that perfectly mimics production. If, however, such an area exists and one is copying 73 programs to it, going through those programs and commenting out "use warnings" or "fatalsToBrowser" statements all over the place is a sure recipe for missing a few. With a tag-based system, they are much easier to catch.print $debug->table( ORDEROBJECT => $order ); #//
Your turn :)
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.
|Replies are listed 'Best First'.|
Re (tilly) : (Ovid - devel vs. production) Re(2) Auto prepare code for production
by tilly (Archbishop) on Jan 26, 2001 at 01:21 UTC
by toadi (Chaplain) on Jun 26, 2001 at 18:30 UTC
Re: (Ovid - devel vs. production) Re(2) Auto prepare code for production
by dws (Chancellor) on Jan 26, 2001 at 00:31 UTC