So you have a bunch of Perl scripts and modules you’ve written over time, and you’d like to quickly determine what non-core Perl modules are required to make them run. Devel::Modlist to the rescue.

$ perl -d:Modlist=nocore some-funky-script
Module::ExtractUse 0.27
Module::ExtractUse::Grammar 0.25
Parse::RecDescent 1.967009
Pod::Strip 1.02
version::vxs 0.95
$

Unfortunately Devel::Modlist is not itself a core module, but it’s an easy install since it doesn’t have any dependencies of its own. The way it works is pretty clever. Rather than trying to parse the Perl scripts and modules, looking for “use” statements, it loads the code into the Perl debugger. This is a smart approach since the common wisdom is only perl can parse Perl.

But this is not a perfect solution. For one, this only works for code that already runs on your system, so you can’t use it to quickly list what modules are needed for some bit of Perl you just downloaded. It also cannot find and report on modules that get loaded dynamically, as would happen if you do something like:

if ($magicRequired) { require Magic; castSpell(); }

And finally this module is not designed to be used from inside of a Perl script since it would cause the dependency reporting every time that script is executed. The shell command line example shown above is the normal usage model for this module.

But even with those caveats, this is still a handy little tool to have in your Perl toolbox.

Many of you know the adage; but learning it anew can still be fun.

I had to trim leading and trailing whitespace in Perl. So:

# strip any leading or trailing whitespace
$string =~ s/^\s+//;
$string =~ s/\s+$//;

No prob.

Then I made the mistake I often make, and started thinking. Two lines for that? Please. That can be done in one line, especially in Perl. So I found this:

$string =~ s/^\s*(\S*(?:\s+\S+)*)\s*$/$1/;

Yuck! Oh well, at least it probably runs faster.

Think again.

Or better yet, Marcus, just stop thinking altogether. This one-liner idea would have made the routine both slower and less readable for the next person (notice I forgot the #comment the second time).

Bruce Schneier has a recent post about a new research paper that seems to throw a little bit of cold water on the obvious superiority of passphrases over passwords. Schneier has a pointer to the paper and a less-formal blog summary. The bottom line seems to be: users can choose poor “easily guessed” passphrases, and left to their own devices, they probably will. As usual with Schneier’s blog, many of the comments to the post are insightful and worth reading.

It seems that it might also be much more difficult to check the “quality” of a passphrase than a password. You’d like to be able to say things like: “Maybe you shouldn’t use Psalm 23:1 (King James Version) as a passphrase.”

Here’s a cute joke my stepfather sent me; I’m not sure where to credit it, so if you know, please comment. It’s an anecdote, reminding us how great engineering looks so effortless that others suspect the engineer of being lazy. Or maybe it’s reminding us how to extort our former employer. But no need to quibble.

There was an engineer who had an exceptional gift for fixing all things mechanical. After serving his company loyally for over 30 years, he happily retired.

Several years later the company contacted him regarding a seemingly impossible problem they were having with one of their multimillion dollar machines.

They had tried everything and everyone else to get the machine to work but to no avail. In desperation, they called on the retired engineer who had solved so many of their problems in the past.

The engineer reluctantly took the challenge. He spent a day studying the huge machine. At the end of the day, he marked a small “x” in chalk on a particular component of the machine and stated, “This is where your problem is.”

The part was replaced and the machine worked perfectly again.

The company received a bill for $50,000 from the engineer for his service.

They demanded an itemized accounting of his charges.

The engineer responded briefly:

“One chalk mark $1. Knowing where to put it $49,999″

The death of Flash is pretty much official now.

There was a period of a few years on the internet where it looked to many of us like Flash could be the future. I invested some time in becoming a moderately proficient Flash developer, in the earliest years of the new millennium. I even drove to Boston in a suit (a rare and loathed activity for me) to win a Flash contract once.

It seemed to solve so many problems. The weighty tyranny of the bitmap (vector graphics! wow…). The video codec problem (which is still a problem). The Javascript implementations problem (which, thanks to libraries like jQuery, is no longer much of a problem).

Flash looked like the solution to all these things and more, and customers loved sites that were, well, flashy. If they could afford them.

I abandoned Flash a number of years ago for a couple of reasons, neither of which is the actual reason Flash is dying. I was never comfortable getting my development tools and runtime environment from a single vendor. And development time was simply too great in Flash. Sure, you got a shiny object at the end, but polishing that object ad nauseam was for designers, not all-purpose geeks like myself. Most of the projects I get focus on function more than form.

So Flash, I bid you adieu. Yes, I know you still enable the charting rendering a couple of my apps, but not for long, my friend. I’m getting in iPad soon and I’d like to see those charts on that, too… so it’s back to HTML (HTML5? Canvas?) and Javascript solutions. Luckily those have come a long way this past decade.

It was fun while it lasted, Flash.
———

UPDATE: if your biggest aspiration was to be the new Flash? You’re also dead.

I’ve used way too many different documentation systems in my time including RUNOFF, nroff, DECdocument, Interleaf, TeX/LaTex, and PageMaker, just to name some of the older ones. These days my documentation tends to be either just plain old text, org-mode (emacs), HTML, or Perl POD. I find myself, however, once again looking for the ultimate solution for my document formatting needs in anticipation of having to create a lot of documentation for a major project.

At first I was thinking of standardizing on org-mode since that is what I tend to use by default now. Its table editor rocks and the syntax is very readable like Markdown, and other similar lightweight markup languages, with very easy export (for an emacs user) to HTML or LaTex. But I’m concerned about picking an Emacs-centric choice in deference to other maintainers, and the fact that org-mode’s own manual is formatted using GNU’s Textinfo gives me pause.

After casting about, including looking at Texinfo, DocBook, Muse (emacs), and reStructuredText, I find myself gravitating to Markdown and most likely the eventual adoption of Pandoc.

Here’s an article that I found particularly helpful. My current thinking is that the learning curve for Markdown is very shallow so I’m not making an unreasonable assumption for other maintainers, and I can start generating documentation now and worry about pretty formatting, structure and presentation later. I’m also trying to avoid this problem out of the gate…

I’m not happy about putting off the overall document architecture till later, but I’m burning daylight.

I change my passwords every 3 months, but my passphrases are getting kind of stale. The arugment for changing your passphrases is about the same as changing your password. Being lazy (but curious), I went looking for a passphrase generator similar in philosophy to the apg password generator that I’ve been using for a long time.

I didn’t find anything comparable to apg, but I came across a blog post by Curtis Copley describing his algorithm for generating grammatically-correct random passphrases, a neat idea. He provided source code in PL/SQL and Java. Both painful languages for me. How about a Perl translation? Looking at the code, I was discouraged: “This is impossible.”

But then, looking closer at the algorithm: “Hey, maybe not that bad.”

So I coded up a Perl implementation. As far as I can tall, it’s accurate. If you’d like to look, more information and the code is here.

Still haven’t changed my passphrases, though.

I’ve been looking at Perl based web application frameworks again. About 4-5 years ago I needed to create a report card application for my spouse. I looked at Catalyst and CGI-Application, and decided on CGI-App because it was lighter weight and did not require a persistent process module like mod_perl or FastCGI. I liked CGI-App and found it easy to use and logical.  But recently I’ve been thinking that I needed to adopt an application framework for work projects, so I thought I’d look at Catalyst again for the first time.

To kick the tires on Catalyst, i.e. to try some of the examples found in ‘the book’, we’ll need to install the development version plus some ‘optional’ modules as they are introduced. For your entertainment and enjoyment, I’ve outlined below what it took to get the basics of Catalyst installed on my Mac laptop (OS X, version 10.6.8 aka Snow Leopard).  The prerequisite for these instructions is having MacPorts installed. MacPorts is the best way I’ve found for installing Unix/Linux goodies on my Mac. Be aware that MacPorts wants to install and maintain its own Perl in /opt/local/bin/perl which is a good idea. Your Mac depends on Perl for various miscellaneous system functions, so it is best not to mess with your system’s stock distribution of Perl.

1. First off we need to know which version of Perl we’ll be installing Catalyst against.

   $ which perl
   /opt/local/bin/perl
   $ perl -v
   This is perl 5, version 12, subversion 3 (v5.12.3)...
   $
   

   This confirms that that the version of Perl in my search path is indeed the one maintained by MacPorts, and reveals its current rev. So in MacPorts, the distributions we’ll be interested in will be labeled with “p5.12″.

2. Next we fire up the MacPorts utility in interactive mode and search for the exact name of the packages we’ll need. I’ll tell you right now — don’t search just for “catalyst”, it will be a long and overwhelming list!

   $ sudo port
   Password: *******************
   MacPorts 2.0.2
   Entering interactive mode... ("help" for help, "quit" to quit)
   [Users/wfc] > search catalyst-dev
   p5-catalyst-devel @1.310.0 (perl)
       Catalyst Development Tools
   
   p5.8-catalyst-devel @1.310.0 (perl)
       Catalyst Development Tools
   
   p5.10-catalyst-devel @1.310.0 (perl)
       Catalyst Development Tools
   
   p5.12-catalyst-devel @1.310.0 (perl)
       Catalyst Development Tools
   
   p5.14-catalyst-devel @1.310.0 (perl)
       Catalyst Development Tools
   
   Found 5 ports.
   [Users/wfc] >
   

3. Now that we know the spelling, install the right one for our version of Perl.

   [Users/wfc] > install p5.12-catalyst-devel
        :
        :
   (many dependancies installed)
        :
        :
   [Users/wfc] > quit
   $
   

4. Looks like it worked, let’s see if it will talk to us.

   $ catalyst.pl
   Usage: catalyst.pl [options] application-name ...
   $
   

That’s pretty much it. As you progress with learning Catalyst you’ll discover that you’ll need to start installing ‘optional’ modules, such as your choice of a templater. The drill is pretty much the same, search for the package to get the exact spelling and install it.

On a Red Hat EL5 server, the ethernet interfaces (IP addresses the box’ll respond to) are defined in files in /etc/sysconfig/network-scripts/. So…

cd /etc/sysconfig/network-scripts/

The IP addresses are nice in those ifcfg-eth* files, but I still haven’t memorized what they are for, especially on a host like the one I am working on. This server does a lot. Here is a one-liner to do nslookups on all those IPs:

for i in `ls ifcfg-e*`; do echo $i; cat $i | grep IP | cut -d '=' -f2 | nslookup | grep name | cut -d '=' -f2; done

Let me know in the comments if this does or does not work for you. I have not thought very long about this but am willing to update this post with your improvements.

Unrelated: please listen to Elvis Costello’s “Punch The Clock” album twenty times and thank me later.

Related: would love to see some more sys admin tricks on this blog. I’m not much of a sysadmin and I’d love to learn.

It seems like every other day I notice a bit of software parlance spreading into other walks of life; such is the new ubiquity of geekdom.

For instance, in this political/financial article that has nothing to do with software, we find this sentence: “Despite a lot of rhetoric about compromise this past week, it is a feature, not a bug, of the American system of government.”

Continuing on this theme, one might further speculate that the American system of government is barely beta, or, at a minimum, not fully implemented.