Hancorp Technologies

I think the wise kilt wearing Ben Hammersley has it right that developers spend too much time worrying about details that simply don’t matter to non-geeks.

Is my site better because it validates?
Do you seriously come back here because the blog software I wrote is built upon a MVC framework and uses a nice, coherent, and flexible database schema? Would you like me more if I had used some REST interfaces? If you do… you really need to get a life.

If you don’t like my content, topics, writing style, or me personally would it help if my permanent URLs were /blog/archive/some_story_frank_wrote instead of /blog/archive/37 ????
Would you become my reader if I rewrote all of this in Ruby On Rails instead of using my beloved mod_perl? I really doubt it.

I think this syndrome, I’m going to call it CSD for Compulsive Standards Disorder, is a cousin of the common ED syndrome. No not erectile dysfunction, I’m talking about Efficiency Disorder. The disorder that causes developers to prematurely optimize their software.

I’m as bad about this as the next developer, but sometimes stuff just needs to ship. Holding it back until it is perfect is essentially putting it on hold forever. Just face it, it is NEVER going to be perfect. There is always going to be a slightly better way, a newer standard, a new best practice, etc. What you should be asking yourself is this “Is this perfect enough for the user?”. If the answer is even close to yes, ship it.

The first step is admitting you have a problem.

I remember back when I first got into computers reading John C. Dvorak’s columns in PC Magazine. But seriously, has this guy lost his mind or what? In a recent opinion piece he posits that Apple has been secretly moving towards adopting Windows in favor of OS X.  Maybe I keep missing it, but I’m still waiting for this guy to be right about something. 

He goes on to bring Linux on the desktop into the mix saying " Linux on the desktop never caught on because too many devices don’t run on that OS.".  First off, I think it’s safe to say that Linux on the Desktop is far from "done", so it’s…. I dunno… several years too early to say it "never caught" on.  Hasn’t caught on yet, sure.

No one disagrees that, especially in the early days, getting random hardware to run on Linux was difficult at best.  But those days are gone.  It used to be "I need a X that runs on Linux" and now it’s closer to "Are there any Xs that don’t run on Linux?".  And just in case Mr. Dvorak ends up reading this, "John, all three of my different DVD burners work just fine on my Linux desktops, just plugged them in and started burning. Thanks for your concern!".

I signed myself up to write application configuration management into the soon to be released $SUPER_SECRET_OSS_PROJECT. The goal is to have a single default configuration file located on the system (with conf.d/* style includes ) that would define each instance of a particular application.

An instance is simply a name and an easy way for the programmers and admins to talk about each install of a particular application. By simply knowing the instance’s name the web application, whether it is a standard Perl CGI or uses FastCGI, mod_perl 1.x, or mod_perl 2.x, can essentially automatically configure itself based on the configuration method preferred by the admin. That’s right the admin.

Often there exists a complete disconnect between the programmers and the system administrators responsible for actually making the app run. Programmers want a configuration setup and style that is easy to parse , while sysadmins want a system that is flexible and easy to use.

The configuration infrastructure that I’m building into $SUPER_SECRET_OSS_PROJECT should give everyone the best of several worlds. Here is the idea in a nutshell:

• You have a central config file let’s call it /etc/myconf.conf that will contain a entry for each instance of each application.
• The instance information will contain either the entire configuration or enough configuration information to bootstrap the config engine enough to gather the rest of the config.
• The application and any programs or associated cron jobs only need to be given ( via environment variables, command line options, or eek hard coding ) the name of the instance they are a part of to configure themselves.

This is probably best explain with a short example, here is a mock up of the central config file /etc/myconf.conf:

<instance foo>
ConfigViaFlatFile Config::Tiny /etc/apps/foo/foo.cfg
</instance>

<instance bar>
ConfigViaParamBuilder Apps::Foo::Params
</instance>

The first instance foo wants to configure itself using the Config::Tiny module and the config information is in /etc/apps/foo/food.cfg

The second instance bar is saying that it wants to configure itself using ModPerl::ParamBuilder
and to use the Apps::Foo::Params module to do so.

So far this is all pretty boring. The real exciting piece is that these two instances could very well be the same code base. One where the admin wants to configure it via custom Apache directives in the httpd.conf and the other using a simple flat text file for configuration. It doesn’t matter to the application. You might be asking yourself how that could be. Time for another example:

use SSOP::Conf;   # For Super Secret OSS Project 
my $conf = SSOP::Conf->retrieve( $instance );
my $template = $conf->template;
my $dbuser = $conf->dbuser;

# Or by using a hash reference 
my $conf_ref = SSOP::Conf->retrieve_hashref( $instance );
my $template = $$conf_ref{template};
my $dbuser = $$conf_ref{dbuser}; 

That is all the application needs to know about, the “instance” name,
to configure itself via several methods. Right now the plan is support Config::General, Config::Tiny, PerlSetVars in mod_perl 1 and 2, and ModPerl::ParamBuilder in mod_perl 2.x.

The infrastructure is written so that it doesn’t matter to the application how the configuration is gathered and parsed, just so long as it has it. This frees the admin to use whatever configuration method makes the most sense for not only each particular application, but each particular instance of that application.

I think the most exciting aspect is that, provided you use a separately included httpd.conf for each of your instances, your behind the scenes programs, scripts, and cron jobs can share their configuration information. If you like PerlSetVars or ModPerl::ParamBuilder and want all of your app’s config to live in your httpd.conf, you don’t have to have a separate configuration scheme for your cron jobs.

You’re probably saying to yourself, “Why the hell is he telling us this when we can’t see the code yet.” Well the whole purpose of this entry was to ask all of my readers which configuration file syntaxes they prefer to use, Apache style, .INI style, etc. so we know what to support out of the box. There are plans for a generic SQL backend and LDAP support. The system is built so you can expand on it yourself if there is something we don’t support.

Comments, suggestions, rants, death threats, etc. are most welcome. Send them to blog@revsys.com. We want this system to be as useful to as many developers and admins as possible.

NewsForge recently published an article discussing the new trend of opening up commercial database products. PostgreSQL’s own Josh Berkus is quoted in the article.

I agree with Robert Treat’s blog What the free non-free databases signal that in the end the commercial database vendors are going to loose out in the same manner web server vendors have lost out to Apache, lighttpd, tux, etc.

But I think there is another aspect of this that helps the Open Source database community more than anything. Providing these free installs tranishes all of the mystique of their products.

I remember when I was starting out as a programmer and had my first opportunity to work with a big name commercial database product. I felt I had finally arrived. I was one of the Big Dogs&trade now. Able to leap tall data structures in a single bound!

Little did I know that I would be quickly disappointed and spend the rest of my tenure at that company lobbying to replace the commercial package with PostgreSQL. Not only to reduce costs and improve performance, but to simply make my life/job easier.

If I had not been previously exposed to a product like PostgreSQL, I would have probably thought that insert commercial vendor here was the best thing available, based on advertising and hype. I probably would not even have investigated any further.

Having these free/non-free installations of the propular commercial databases will allow the next generation of geeks to evaluate both the commercial and truly Open on equal footing. And in this fair fight, we are sure to win!