|
|
As I work to update the photo browser to something more modern, it occurs to me
that software has reached a new stage in its evolution - that of long-term
maintenance of the personal project. I have software that I wrote in the 90s
that still kicks around and gets my occasional glance, but I don't use it on
any sort of regular basis. Bugs in these things are simply not a concern.
However, the photo browser has had outstanding feature requests for well, years.
I've quietly ignored a few desires of my own for a number of reasons. First and
foremost - uploading data is a process that requires direct access to the
system. You have to copy the files to foodini.org via a secure copy operation,
which requires a username and password. After that, thumbnails are manually
generated by way of a script that hasn't changed since.... wow. July of 2004.
Editing database entries to add keywords is another process, and requires a bit
of specialized knowledge. I also have a specific request from no fewer than
3 sources that has been rotting in the background simply because the database
mechanism I created for this project wouldn't be happy to have it shoehorned in.
I could, of course, go through and make the changes. It would take a lot
less time than the current undertaking - a Ruby On Rails project - but the whole
process has me thinking about what happens 4 more years down the road. If I'm
happy with what I have, I'll ignore it. If I'm not?
RoR is far more complex than the current solution. The current browser simply
uses perl to process forms, hit the database, and generate html. It couldn't be
simpler - barring the 'specific request' listed above that would touch almost
every part of the thing in ways that would most likely break lots of stuff I
don't want broken.
So why RoR? In 4 years, I'll fill you in on the mistake.
-rbarry
|