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 ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Wednesday December 15, 2004
11:23 AM

When to go it alone.

[ #22321 ]

It was Joel Spolsky who once penned the following heresy:

Pick your core business competencies and goals, and do those in house. If you're a software company, writing excellent code is how you're going to succeed. Go ahead and outsource the company cafeteria and the CD-ROM duplication. If you're a pharmaceutical company, write software for drug research, but don't write your own accounting package. If you're a web accounting service, write your own accounting package, but don't try to create your own magazine ads. If you have customers, never outsource customer service.

The new build system for Bricolage is complex. It has to be. Bricolage is complex and frankly, many CPAN modules aren't that easy to install. Now when you throw into the mix our dependencies on Apache, mod_perl, PostgreSQL and a few other things, the build process gets very difficult. This is the major complaint with Bricolage. We're trying to eliminate the complaint for the next version, but trying to write code to manage those dependencies is a nightmare, so the switch to a state machine to track the rules seemed like a good idea.

The we discovered the limited support for state machines in Perl.

If something is a widely used, well-supported module, we'll cheerfully reuse it. It makes our life easier. If something isn't widely used (and state machines fall in the category) but it's well tested, there's still a good chance we'll use it. Heck, if it's not well-tested but it's too simple to fail or would be a quick rewrite, we'll still use it. But when something is complicated, not widely used, poorly documented, central to our business needs and the test suite consists solely of one test that ensures the module loaded, I'm hard-pressed to justify using something from the CPAN.

Because of the problems we were having with state machines from the CPAN, Theory decided to write a rules module to allow us to arbitrarily parse rules. Hopefully it will be on the CPAN soon. It's actually documented and has gobs of tests. There will probably be a few changes before it's ready, but I feel much more comfortable about this code than the alternatives. Too much is riding on it.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I helped out with the build process for Krang, which we are now trying to generalize for a new project called "Matchstick." You bundle the source for apache, mod_perl, and all the modules you need, and then it does an automated build of them. You can create a binary distribution for a specific platform from one of these builds. If you're interested, take a look at the krang_build script in the source distribution. It works much better than trying to download things from CPAN and avoids getting into mess
  • I read your quote from Joel, and I read Joel's original article. I don't see any heresy, or contradiction of your chosen course of attack.

    You are developing a product that must be installed and reinstalled all over the place. That adds GOOBE (good out-of-box experience) to your list of things that should be your core competencies. Whether that means you need someone who knows Ant or Make like the back of their hand, manage brittle shell scripts or you write your own FSM module, that's your call.