Stories
Slash Boxes
Comments
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 ]

gnat (29)

gnat
  (email not shown publicly)

Journal of gnat (29)

Monday March 24, 2003
07:10 AM

Easy updates

[ #11195 ]
I'm really impressed with Apple's Software Update. For those of you without Macs, it gathers signatures of various pieces of software and compares them to a list downloaded from the Apple mothership website. From there it can tell you "hey, you have an old version of xyz and you need this update".

I've got programs on my laptop that are also on my colocated machine and on my basement server. I'm positive I've hacked in new features on one machine or another, but synchronizing them has been a nightmare. Perhaps I should develop my code on one machine. Give a unique ID to each released program, embedding it as POD or just a comment. Then with a master list of versions and upgrade paths from the development server, it's simple to extract IDs from everything in ~gnat/bin and see what needs to be updated.

Is there a Truer Perl way to do this? I do not want to make every program into a module with a $VERSION and unique package name. That is the True Java way. Any Truer Perl way works on programs qua programs, not "a program is an instance of an Application object that has been subclassed to override the Run method ..." nonsense.

Hmm, I guess this epitomizes the Unix and Perl philosophy for me. If there's a More Perl way to do it than I described, then it does so by removing one layer of complexity by reusing an existing feature. For example, MD5ing $VERSION and the first comment in the source instead of assigning a unique identifier, or hooking into CPAN.pm/CPANPLUS to register, install, and upgrade programs.

How many times have you seen a nasty solution to a problem, wondered "what the hell are they doing?", and then proceeded to strip away unnecessary obfuscation after meaningless cargo-cult programming artifact until finally you arrive at a simple elegant expression of what it was you wanted to do all along? Ok, maybe not that often, but it's an experience I recognize from several times in my life as a programmer. I guess one of the pleasures of going through hell several times is that you begin to learn the landmarks. "Ah yes, I remember this bubbling lake of sulphur, so that must be Sisyphus's rock rolling down that hill ..." and so on.

--Nat

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • by ziggy (25) on 2003.03.24 10:31 (#18249) Journal
    I've got programs on my laptop that are also on my colocated machine and on my basement server. I'm positive I've hacked in new features on one machine or another, but synchronizing them has been a nightmare. [...]
    Sounds like (1) you want to keep your little hacks in CVS (or svn, or ....) and (2) cvs up on your various servers periodically. Software distribution problem solved, and no mucking around with $VERSION or other cargo-cult features. :-)
    • Yeah, but I don't want CVS crap laying around in my binary directories, do I? And I don't necessarily want to install every program on every machine.

      --Nat

      • If you don't want CVS directories hanging around, there's always svn or p4. But I don't see what the problem is...

        And you're not forced to check out entire directories. You can check out individual files, or check out random files from all over the repository into the same directory. cvs co -d . module/filename. :-)