February 2008 Archives

When developing and deploying Perl code that relies heavily on CPAN modules (and if yours doesn't, it's either really simple, or you are not using Perl to its full potential), I find myself asking the same set of questions over and over again.

• Do I have ${ModuleX} installed on this machine?
• What version of ${ModuleX} is installed?
• There might be more than one copy of ${ModuleX}. Which one is my code using?
• ${ModuleX} is not behaving. I want to have a look at its source.

A handy (and free) tool to help answer these questions is available from CPAN in the Module::Info distribution. In addition to the library, this distribution also includes the module_info command line script. Run it to find out the version and location of the module in question. For example:

vince@Vince-Laptop:~$ module_info Module::Info

Name:        Module::Info
Version:     0.310
Directory:   /Library/Perl/5.8.6
File:        /Library/Perl/5.8.6/Module/Info.pm
Core module: no

You can quickly find out what version of the module is installed, where it lives, and even whether it is a part of the Perl core distribution. Sadly, Module::Info itself is not in the Perl core, so you'll have to install it and its dependencies from CPAN.

If you can't install the CPAN module for some reason, I hacked together a little script I call qmod that I could carry around on a thumb drive with my dot-files and such. Being just a quick hack, it's not as functional as module_info, but it gets the job done. Here it is in its entirety (less documentation).

#!/usr/bin/perl
use strict;
my $max = 0;
my @list;
for (@ARGV) {
    $max = length($_) > $max ? length($_) : $max;
    eval  "require $_;" ;
    if ( $@ ) {
        push @list, [$_, 'Not Found', ''];
    } else {
        my ($version,$file,$which);
        ($file = "$_.pm") =~ s{::}{/}g; 
        my $varname = $_ . "::VERSION";
        eval "\$version = \$$varname;";
        push @list, [$_, $version, $INC{$file}];
    }#END if
}#END for
printf "%-${max}s  %6s  %s \n", @{$_} for @list;

If you just need to know the location of a module file, here's a nice tip from brian d foy's Mastering Perl: perldoc -l Module::Info.

Pop quiz, hotshot. Your team has undertaken a project to completely redesign your web site. Fancy-pants designers are hard at work generating not one but three new designs. The designs will be put through a battery of usability tests, after which the best parts will be combined into the final design. They need you to create server-side logic that will populate content areas, navigation, and various design elements according to how the user manipulates the site. But the HTML is nowhere near finished, and the designers will be tweaking it right up to the day of the test. What do you do?

Your normal workflow is shot. Typically you receive finished HTML from the designers, break it down into reusable components, add template tags to represent program objects and logic, and prepare the whole thing to be run through a template processor to generate output. That's out. Any attempt to mess with their HTML will be counter-productive. The priority here is to perfect the design for usability testing, and that means rapid iteration in visual design tools. Template tags will get in the way.

The time crunch is serious. They need a functional prototype to test with, but you can't embed the functionality into the template. They're holding your templates hostage.

My solution: Shoot the hostage.

Speaking of templates, I was just catching up on my mailing list deluge, and found this announcement for the latest release of HTML::Mason:

1.39 Jan 30, 2008

[ ENHANCEMENTS ]

CHI may now be used as the backend for $m->cache as an updated alternative to Cache::Cache. Among other things, this facilitates easy use of Cache::FastMmap and memcached for data caching. Cache::Cache is still the default for now, and is still listed as a prereq for Mason.

-dave

Memcached support puts a smile on my face! I need to test that out soon! Read the docs.