in reply to Re (tilly) 1: Auto prepare code for production
in thread Auto prepare code for production

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:
  1. 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.

  2. 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.

  3. Production: Duh.
Properly, a script such as mine should only be applied in the migration from development to staging. For example, I often have this at the top of my code: 
#/*
use warnings;
use CGI::Carp qw( fatalsToBrowser );
use CGI::DebugVars;
my $debug = CGI::DebugVars->new;
#*/

[download]
Later on, I'll have individual lines like this: 
print $debug->table( ORDEROBJECT => $order ); #//

[download]
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.

Your turn :)

Cheers,
Ovid

Update: Both dws and tilly are right. I did miss the point of tilly's post. Sigh.

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
    I think you entirely missed my point. I was suggesting that you produce a small module or two that either differs between development and production, or automatically detects that, then behaves appropriately. So you would do: 
    use My::Configurable::Debugging;
my $debug = My::Configurable::Debugging->new();

    [download]
    and then later do: 
    $debug->print_table{ ORDEROBJECT => $order );

    [download]
    which calls a method that might or might not actually do anything useful.

    Now through the bulk of your scripts there is no change betweeen production and development. You don't litter your code with tags where if a developer forgets the tags somewhere they could let debug code slip into production. Or where they can put the tag in and forget that the line does something non-trivial and important. Relying on people to not make mistakes when there is no way they can get feedback that it is a mistake is a Bad Idea. Better yet since the shipped code has all of the debugging support present (though not active), you can easily turn that into a logging option in production if something works as not expected...

    What is key is to arrange to be sure that your development environment will (except for minimal necessary details) appear identical to production. Making this process take little to no care on the part of developers removes a significant cause of error. In fact this is the old mantra of centralizing your logic in one place rather than scattering it through your code, whether it is scattered through if conditions, preprocessor statements, etc.

    If you write a complicated standard and say, OK. If we all manage to follow this carefully, never making mistakes, everything will work fine! you are guaranteeing that it won't actually happen. If you write a simple standard and say, Here is the API. As long as we only use this API the process should not mess up! you at least have a fighting chance...

[reply]
[d/l]
[select]
      And then to think here at work they even hardcode the stuff, copy it to production and then change the environment specific stuff :)

      Tried to explain it's better your way, but they say this is faster...


      --
      My opinions may have changed,<BR but not the fact that I am right

[reply]
Re: (Ovid - devel vs. production) Re(2) Auto prepare code for production
by dws (Chancellor) on Jan 26, 2001 at 00:31 UTC
    The value of favoring something like print $debug->table( ORDEROBJECT => $order ) if $DEBUG{ORDER}; over print $debug->table( ORDEROBJECT => $order ); #// is that there may be times when you get backed into debugging in a production environment.

    If you're hosting your production environment (and have direct access to the database servers), it may be practical to replicate an environment that's failing. But if you're shipping a system that customers will be running within their own firewall, you may need to fall back on enabling some level of debug code in situ. Having the ability to turn on debug code remotely has saved my projects' butts many times over the past decade, and saved us from spending megabucks on last-minute airline tickets.

[reply]
[d/l]
[select]

In Section Code Catacombs