Daily Archives: February 11, 2008

2600, latest issue

I am somewhat a regular listener to Off the wall and Off the hook I mentioned this to a Perl monger at some point and he recommended me to buy all of the back-issues of 2600 magazine.

So late 2007 I did.

The actual reception of the box with the issues is quite a story involving, but anyway. I got the latest issue in a separate envelope and carried that single issue with me. So whenever I had some time I would read a bit.

A funny thing struck me and I am really going to pay attention as I go back through the issues.

But all of the hacks and code examples are written in Perl.

Not the most beautiful Perl, but it is Perl.

I fell over an article on Expert Exchange, you know the site, which always fill your search results list when you <i>google</i> for something perl tech question like.

And the worst thing is, you have to pay to see the results.

Well anyway this guy found out that the answers where right there under his nose, but encrypted, so he attempted to decrypt them and succeeded, the answers from Experts Exchange where apparently encrypted by a ROT-13 algorithm.

I hope the remaining back issues will contain as many amusing articles.

I can only recommend getting some copies if not all issues of the 2600 magazine.

Anyway the <i>experts</i> at Experts Exchange, exchanged the algorithm.

3 Packages 1 Uniform $VERSION #Perlmonks++

I have had a problem for quite sometime with some code. We refer to the code as the poor mans configuration management system. (the code snippets below have been shortened to not reflect the name space of the client in question).

All in all it is a CPAN like distribution of files.

Configuration_DEV.pm
Configuration_TEST.pm
Configuration_PROD.pm

The 3 files contain several package definitions, one per application and so forth.

The configurations then vary according to their environments. DEV, TEST and PROD.

So I have subclassed Module::Build and implemented my own install action.

This action reacts to a mandatory command line argument, so the user has to decide on what environment he/she wants to install.

So if the user specifies test, the installation creates a symlink called Configuration.pm in the install directory pointing to the designated environment specific file.

And everybody is happy.

Or?

My problem is that we constantly add a lot of configurable parameters in these files and new package definitions.

So in order to control this I normally specify what version my new or improved application requires as a minimum in my application’s Build.PL.

But the $VERSION has to be defined in all 3 files and even the distributions Build.PL wants it. So I added a VERSION.pm file, which only contained the version.

This works ok, apart from the fact that Module::Build would not recognize and parse the line where I included it in the $VERSION = $VERSION:VERSION;

I have addressed this problem of mine with many fellow Perl mongers, but without any resolution.

I have never been really active on Perlmonks, but yesterday I thought, hey why don’t I ask there?

The next day I had two responses to my inquiry (http://www.perlmonks.org/?node_id=667080)

None of these was quite what I was looking for at first, but one of them got me thinking.

So I added yet another action to my Module::Build subclass, so now the version of the distribution is controlled in the Build.PL and the ./Build dist action puts the proper version into all of the environment files in the distribution.

The solution has some minor cosmetic problems, such as the code is changed prior to shipping and does therefor not reflect the code in CVS completely.

But my problem went away and to quote, or I cannot remember the exact quote, but Damian Conway once said that the Perl community was a… lucky/rich something community to have something like Perlmonks.

I can only agree.

Perhaps I should boil my whole poor mans configuration management system down to a writeup on Perlmonks, perhaps somebody else can use it.