Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

cbrooks (3267)

  (email not shown publicly)

Journal of cbrooks (3267)

Tuesday November 19, 2002
11:57 AM

Perhaps it's time to upgrade my servers....

Hmmm. Looks like Red Hat may not support version 6.2 much longer. I noticed because the latest Red Hat Advisory does not include information for versions earlier than 7.1.

Red Hat's Errata page (which lists Security Alerts and Bug Fixes) still claims support for version 6.2, but the stated policy is to support the "two most recent major product releases" -- 7 and 8.

I called customer support, and they said that Red Hat Network (the up2date utility) and Errata support for 6.2 will go away "very, very soon".

So, if you're running version 6.2, and the possibility of running an OS for which security patches are no longer released scares you, you might want to upgrade.
Wednesday November 13, 2002
10:34 AM

Stale mirrors in CPAN

This might be helpful to someone else -- the last few times that I've tried to install modules using, the installation has hung as LWP tried to retrieve the source files across FTP. It turns out that the problem is with stale CPAN mirrors -- a simple lynx showed that over half of the mirrors in my $CPAN::Config->{ 'urllist' } were not accessible. Once I removed the non-responding URLs, I was able to install modules again.
Monday September 16, 2002
07:17 AM

Best Practices: Software Configuration Management

Perforce Software has released an interesting white paper on "Best Practices" for software configuration management. Since Perforce is in the business of selling SCM software there is a (small) marketing component. But it is an interesting (and quick) read if you are interested in issues of automated releases, source code versioning and nightly builds.

One of the points that I found interesting was a possible approach to the "stability" issue that I have mentioned before. (i.e. How do you determine (in an automated fashion) whether or not a particular script is "stable" and ready to be released into production.) The authors recommend different "codelines":

Development codeline: interim code changes may be checked in; affected components must be buildable. Release codeline: software must build and pass regression tests before check-in; check-ins limited to bug fixes; no new features or functionality may be checked in; after check-in, branch is frozen until entire QA cycle is completed. Mainline: all components must compile and link, and pass regression tests; completed, tested new features may be checked in.
Wednesday August 28, 2002
10:44 AM

Perl and Daily Builds

I've been reading a few articles on integrating daily builds into the software development process:

It sounds like many folks see substantial benefits, especially on teams.

So, I was wondering what a nightly build process might look like to a team using Perl.
Here are a few thoughts:

  • Do a complete checkout from cvs of html pages and scripts
  • Run a link checker for static html pages
  • Run all unit tests
  • Run all regression tests
  • Any errors break the build
  • tar / gzip everything, and save with a datestamp / build number

The nightly build then becomes the tool for syncing the staging and production servers, rather than using cvs update to sync the servers. The benefit of this is that you can cvs commit files that are not 100% functional / stable, and not worry that they will be released into production on a nightly update, while still maintaining a record of each night's build and smoke test.

Is anyone working on a Perl project and doing nightly builds? Do you find it useful?

Friday July 19, 2002
07:56 AM

The Factory Pattern

I am trying to find an elegant method of solving the following (recurring) problem: I have a class ( that represents eldercare facilities that is used in the following way:

my $facility = new Facility( unique_id, facility_type );
print $facility->get_name;

The constructor for this class can accept either:
  • a unique id and the type of facility to be instantiated (in which case the constructor knows how to pull the relevant information from a database)
  • a hash ref with the data used to instantiate the object

The class is quite useful when dealing with a single facility, but I would like to make it more useful. Rather than having to know a unique id, or the actual values that will be used by the object, I'd like to be able to pass in (for example) a city and a state, and get an arrayref of Facility objects for every facility in that city and state.

Now, I have noticed that the class names for many classes in Java match the pattern <Classname>Factory, and I thought "Aha! I could create a FacilityFactory class, which might have the following usage:"

my $factory = new FacilityFactory(
    facility_type => 'NursingHome',
    city => 'Birmingham',
    state => 'AL'

foreach my $facility ( @$factory ) {
    print $facility->get_name;

FacilityFactory would know how to translate its parameters into valid SQL, query the database, and return an arrayref of instantiated Facility objects.

Well, okay that would work, but then I decided to go see if this was actually consistent with the <Classname>Factory pattern that I have seen used in Java. And wouldn't you know, it isn't. The Factory pattern is used when you can't know until runtime which type of class you need to instantiate. The Factory class encapsulates the logic for selecting one of these child clases, is implemented as an abstract base class. Kind of a different beast than what I was attempting.

So here's my question. What is the best way to crack this nut? Here are my options as I see them:

  • Ignore the formal definition of the Factory pattern because hey, this does what I need;
  • Essentially ignore the formal definition, rename my class FacilitySet and move on
  • Make the Facility class more flexible, so that it represents one or more facilities, rather than just one;
  • Punt, and hope that one of you will pick up the ball....

Thanks for any comments.

Monday July 15, 2002
01:48 PM

Perl jobs

<disclaimer>I'm not actually looking for a job right now.</disclaimer>

But, why are there so few Perl jobs out there?

Here's a stat that might illuminate the point: Sr. Software Engineer finds 103 hits on Sr. software engineer perl returns 3. (Java and C++ return 12 and 11 respectively). Of those Perl positions, two expect Java / C++ as well. The third is actually a technical writer position.

Perhaps the lesson is that you have to have solid experience in multiple languages to be marketable today. Perl isn't a bad language to have, as long as you have Java or C++ as well. (For example, 48 positions on mention Perl in some context -- but compare that with 130 that mention Java and 89 that mention C++.)
Saturday July 13, 2002
05:55 PM

Automating the release of new functionality

I would like to automate our company's process of releasing new web functionality into production.

Here's a brief description of our architecture:
  • RH Linux
  • MySQL database on the back end.
  • All HTML and Perl source code is stored in a CVS repository. Images are not stored under CVS.
  • Each developer has their own local source tree with an Apache server listening to a high-numbered port.
  • We also have a staging server that we use for testing
  • We have a separate production server visible to the outside world.
  • HTML pages are static files.
  • We write mod_perl handlers and cgi scripts that run under Apache::Registry.

At its simplest, you could imagine a release process scheduled to run every night at 1:00 am that looked something like this:
cvs update
/usr/local/apache/bin/apachectl stop
/usr/local/apache/bin/apachectl start

However, this approach is likely to prove unsatisfactory for several reasons:

  • Since images are not stored under CVS, new images might not get loaded when needed.
  • Some development involves creating new database tables, altering existing tables, or populating existing configuration tables with new data.
  • New modules should be tested before stopping the web server. Should a module fail some of its tests during installation, the update should be rolled back so that the server can start successfully.
  • Some files get committed to the repository before they are stable and/or approved. Only stable, approved files should get released.
  • A related (but distinct) issue is that stable files should not necessarily be released as soon as they are stable. A simple example of such a case is a (stable) HTML file which includes a link for another HTML file which is not yet ready to be launched.

Given this description, it is possible to rough out a simple spec for The Release System (TRS):

  • TRS needs to interact with CVS. This will allow releases to be customized by directory hierarchy, CVS module, and / or tag. This will also ensure that master copies will be released, rather than local copies.
  • TRS needs to be able to execute simple scripts. This will allow TRS to run tests, execute arbitrary SQL, log results, etc.
  • TRS needs to be able to perform a rollback should unit tests fail during release. It should only stop and start the web server if all tests pass.
  • TRS needs to interact with some system that knows (1) whether a particular file is stable; and (2) whether a particular file is approved for release.
  • TRS should have logging facilities that keep a record of when all changes were made, error messages and warnings that were encountered, etc.
  • Although a fully automated and regularly scheduled system is nice, it is not necessary. However, a release should be possible with very little interaction on the part of the system administrator.
  • TRS should be able to run the regression testing suite after release.

A few questions:

  • Who has cracked this nut before?
  • Can anyone recommend pointers to good articles that tackle part or all of this?
  • make is certainly a candidate for some of the logic -- would anyone recommend a different installation utility?
  • Parts of this sound like a Content Management System -- does anyone care to comment on the applicability of Bricolage or a similar open source CMS product?
  • CVS does not seem to have as robust a system for tracking stability as I would like -- i.e. you can set tags on groups of files, as in "STABLE-06012002", but you can't flip a bit per file. (Unless you set a tag per file -- which isn't necessarily good since a file might go through various iterations of stability / instability.) Can anyone venture an opinion as to whether the per-file "stable" flag is a good idea or a cluster-f*ck?

Thanks for any and all help.

Wednesday July 10, 2002
01:51 PM

Yet Another YAPC entry

I've been thinking back over the presentations that I saw at YAPC this year. Here are two techincal insights that will stay with me:
1. Inline::C isn't really a replacement for XS. It's a replacement for h2xs.
2. Two actual uses for closures: memoize (uses closures internally) and strong object encapsulation.

And my personal YAPC Awards:
1. Best argument for why we need Perl 6: Adam Turoff -- Perl 6 has re-energized the Perl community.
2. Rudest YAPC attendee: perhaps I shall refrain from naming names, but STOP INTERUPTING PEOPLE just because they're criticizing the usability of CPAN.
3. Coolest hair: easy one. Michael Schwern.
4. Best presenter: hmmm. Tie between Dominus (Secrets of the Wizards) and Kevin Lenzo's (the auction).
5. Most entertaining session: Lightning talks
6. Most eloquent explanation of the power of Perl 6: Allison Randal, if Dr. Seuss were a Perl 6 hacker
Wednesday July 03, 2002
01:21 PM

Thoughts on YAPC

This was my first YAPC. Quite an interesting time. What I enjoyed most was putting faces / personalities to names. Larry, Damian, Mark Jason Dominus, Simon, Nat, Schwern, Abigail. The whole bunch.

What I don't quite understand, though, is how these people make a living. Or, more to the point, what kind of living can you make it if you get into the high Perl Priesthood?

Here's my best guess as to where their income comes from: (And hey, no offense to these folks -- maybe they don't want their incomes discussed. I don't mean it personally, I'm just curious about what the income possibilities are for our most lauded wizards.)

Perl Foundation Grants:
  • Larry, Damian and Dan Sugalski are all on 2002 Perl Foundation grants. Those pay a $60,000 stipend and a $20,000 travel allowance (but they are only 52% funded to date, and I believe Dan and Damian's expire at the end of July.)

Book Royalties:

  • Larry, Damian and Nat presumably have ongoing royalties from their books.
  • Simon has a book out next month (
  • Mark Jason Dominus seems to be perennially working on a book due out next year some time (

Day Jobs:

  • Schwern works as a contractor.
  • Nat and mjd work as trainers for the Tom Christianson Perl Consultancy.

Presentation Fees:

  • Let's see, YAPC-NA offered free conference attendance to presenters. There's a whopping $85 value.
  • mjd asks for $25 and a plane ticket to give a talk in any city.

And I can't seem to figure out what Abigail does.

So, is that it? Is that what getting to the top of your profession looks like? Book deals and Perl training? Do you get a 401k with that?