|
|
The page you're now reading - whether you got here via fingerme.cgi, latest.cgi,
or permalink.cgi - has just suffered a rewrite in preparation for some redesign
of how I manage these pages.
Aside from some minor changes in formatting and the top-of-page header, the only
difference you should see is the addition of facebook thumbs-up doohickeys. The
latter exists ONLY on the permanant link and 'latest' pages, quite simply
because each one triggers a little chat between your browser and facebook. The
time difference between loading the entire blog without vs. with facebook thumbs
is the time difference between wondering what you'll have for lunch and actually
going out to eat. It was unacceptable.
The only reason I mention this at all comes down to the simple problem of long-
term, small-scale software engineering, which I have discussed before. When I
went to start writing the update, I thought that I'd start with a Ruby-on-Rails
project. So why did I write these three utilities out as a single 233-line ruby
.cgi script instead of going with such an exellent web project framework as
Rails?
Simple: Ruby-on-Rails is a swooping, soaring, gliding, rolling, majestic....
...pain in the ass to manage.
The people that handle foodini.org have a nasty habit of suddenly updating the
Rails configuration for the entire collection of customers all at once. Since
Rails does not guarantee that updates will be backward-compatible, there are
two choices; I can go offline for a month like I did the last time, spending a
couple dozen hours trying to fix compatibility with the new version, or I can
'freeze' my project to the current version of Rails. From then on, I have a
suspended animation version of Rails, forever stuck in that moment in time. I
cannot update my libraries without risking a compatibility issue, forcing a
complete update to the current Rails, no matter how much work that would
entail.
Freezing Rails, for a small personal project isn't such a bad thing, but it
does mean that ten years from now, I'm going to be doing a rewrite if I want to
do any significant update. So, if I'm going to run the risk of getting back
up-to-date on such a monumental system as Rails ten years from now, thanks, but
I'll stick with reinventing the wheel.
I should address an apparent contradiction between this position and that of
yet another previous essay, in which I essentially say, don't reinvent and
don't start from scratch. The differences between the essays that justify the
opposing views are that here I'm talking about a small personal project with an
extremely long lifetime, where earlier I addressed projects that involve full-
time programmers and end-of-life on a ship date.
Why does it make a difference? A project that will never take more than a few
hours of my life at a time has a very low threshhold before invested time is
wasted time. If I spend a week or two getting some weird-assed .swf hack to
give me upload progress bars in a Rails app, I'm not going to remember the
nuances of that system ten years from now when I need to change it. Ten years
from now, the odds that a google search for an issue with a ten-year-old
version of that software will not return a useful result.
Here's another way to look at it. The time that I will invest in fingerme.cgi
over the next decade will be microscopic compared to the time that the Rails
community will invest in their system. Rails will evolve so much faster than
my use of it that the majority of my project's maintenance would be in simply
keeping up with Rails. If I were a group of a dozen engineers writing a game
on the Quake engine, I can be certain of a relatively stable development
platform. Even if the engine changed during my development, it would be a
fraction of my team's overall investment of time to adjust to that change.
Given the leg-up that the third-party platform lends a large project, this is
an acceptable trade-off. It does not scale down to the microproject.
--rbarry
|