All the Perl that's Practical to Extract and Report
use Perl Log In
ChrisDolan (2855)
Journal of ChrisDolan (2855)
dev vs. live
In any web app, it seems that there's always something that you want to be different on the live site versus the dev site: a different database name, verbose logging on, performance metrics enabled, etc. I find myself implementing the live vs. dev switch a little differently every time, though. What do other people do? Do you trigger dev behavior via hostname? Via a config file? Via an URL substring? Manually?
In my current Catalyst project, I wrote this little hack. It's inelegant, but simple to understand.
# If we aren't running on my development computer, refuse to load the dev features
if (! -d '/Users/chris') {
# trick Perl into thinking this file is already loaded
$INC{'MyApp/Controller/Dev.pm'} = 1;
}
where Dev.pm adds a few special features and flags. This works because my main dev box is a Mac and the servers are all Linux or FreeBSD, which use
an endless discussion thread about what features to include.
-- Jarkko Hietaniemi
Via a configuration class (Score:1)
I centralize all the platform-specific stuff into a
Then there's a config class which has the task of loading it and thoroughly checking everything in it (file permissions, paths existing, initializing the database connection pool etc). It takes a fail-early approach, and then various configuration values and objects are provided via the static methods for the config class.
All the rest of the application looks to this class for information, s
I use the Apache conf (Score:2)
If I'm deploying on mod_perl, I tend to set this sort of thing up using PerlSetVar in the Apache config rather than create an application-specific config file.
That Way Lies Madness (Score:1)
I've done things like that in the past (or sniffing version numbers of various programs/libraries, and guessing environment therefrom), but I suspect that way lies madness, ultimately -- at least, pick one thing and stick with it, or you will inevitably forget what the decider is for any given app.
I tend to prefer the config file method -- it also allows a slightly wider matrix (development vs. production is common, but many leave off staging, or laptop, or home machine). Ideally, there would be two axes:
dev vs live (Score:1)
okay for dev+prod (Score:1)
If you have a "dev -> stage -> prod" setup, where stage is ideally as close as possible to prod, then what you have won't work. You need a more general way to get the configuration, like a config layer that parts of the application can call through (database, etc. goes through this layer).
Dealing with different configurations sucks, blech. Like when you want to sync your dev from prod, you always end up changing something: a server name in a database table, in a config file, etc. I guess ideally you