Skip navigation

Monthly Archives: September 2008

stackoverflow.com

I was planning on coming into the office early this morning, but just before I was going to leave, I read Spolsky’s post and in under a minute found a Perl::Critic related question I felt needed a good answer.

Dang, writing good answers takes time.

Managing perl

(The lowercase “p” perl is what I mean in the title.)

There’s a great new page on the Perl 5 wiki about administering your perl installation. It includes quite a number of things I believe in. Some of the more significant bits:

First and foremost thing I can say is if you depend heavily on Perl (or any single piece of technology) build it yourself. This will allow you finer control and faster upgrades than your OS vendor can. Windows is the exception, Strawberry Perl does a much better job packaging Perl and tweaking it for Windows than you can (and if you think you can better, please contribute to Strawberry).

This is especially true on Red Hat. Ignoring general management issues, you really ought to have a threaded and a non-threaded perl so that single-threaded code doesn’t pay the overhead for threads.

Fourth, keep up to date. This means keeping CPAN modules and perl itself at or near the latest versions. This will incur the occasional breakage as you encounter either intermittent bugs in new versions of CPAN modules, or API changes, or project code that accidentally depends on certain versions of CPAN modules. But it’s worth it, because the farther you fall behind the harder it becomes to catch up. As your perl gets older and older, fewer and fewer CPAN modules will work requiring more and more patching to get them working. As your CPAN modules get older, it will require a greater leap to bring them up to date, and more upgrades simultaneously. The sudden upgrade will cause many bugs to happen simultaneously making them take far more time and effort to track down then if they could be dealt with individually. Large upgrades require large effort, time and risks. Small upgrades require small effort, time and risks. The looming risk of a large upgrade will make developers settle for an older, buggier, less capable version and write a work around rather than risk the upgrade. This creates a hidden drag on your project and creates more and more complex code to maintain.

Another point: when you discover a bug in a CPAN module, there may be a fix for it, but if you’re very out of date with it, it may cause significant problems with other modules, making your upgrade of that one module really painful.

At Barclay’s, it took me 7 months to upgrade them from perl 5.6 to 5.8 and the latest version of other modules. Way too long.

If you’ve got good test coverage, you should be able to easily find any problems with upgrades.

Names

A topic anyone who’s known my programming style for a while knows that this is one of my pet peeves. Why can’t people use understandable variable names?

I just got though producing a set of constants for FIX message types and fields. I hate abbreviations that come from outside the problem domain, i.e. that an end user wouldn’t understand. I hate abbreviations in general, but specifically for “number” because there’s three different common ones in use. FIX uses two of them, with no clear reason for the difference.

In the world of finance, “FX” is a reasonable abbreviation to use in names, because the end users understand what it means. In FIX, there’s a field called “DKReason”; care to guess what “DK” stands for? If you said you “don’t know”, you’re correct. Yes, it literally stands for “don’t know”. The description for the field is “Reason for execution rejection.”, but if you’re reading through unfamiliar code and see “DKReason”, how the hell are you expected to understand the significance without hours of digging?

Crud. CPAN::Site is unfixably broken.

I’m setting up a DarkPAN at work.

CPAN::Site does most of what I want with maintaining it. Unfortunately, it has some bugs with parsing module versions (in particular Test::Object, which is a blocker for PPI); in particular, it can’t distinguish between namespace declarations in actual code and in code examples in documentation. I thought that it could be worked around, but in reading source, it’s doing some pretty incredible stuff.

It’s reading perl code straight out of raw tar files. It ungzips the tarballs, but doesn’t untar them. It simply tries to find perl code in the middle of the tar stream and grab the versions out that. Yech.

So, looks like I’m going to be forced to go back to CPAN::Mini::Inject, taking advantage of parse_version() in ExtUtils::MakeMaker. I’m going to have to have a look at brian d foy’s MyCPAN::Indexer work.