Okay. Background: I've programmed in C, shell, awk, tcl, etc. for
years. Over the years I've read Learning Perl (and parts of
Programming Perl 3rd edition) and a few other perl books), as well
as various articles published in magazines and webforums, as well as
postings here and elsewhere.
Now I'm faced with the opportunity/challenge/
{pick your politically correct term} with maintaining a
rather complex and critical perl application written by someone else
(no longer available for guidance, etc.), with this minimal background in perl.
I'm trying to figure out what steps I can take to bring my skills up. Of
course, the first thing will be to read Programming Perl again.
But what else would help someone get become comfortable in Perl code,
particularly perl code using lots of objects and references?
Any other books, online articles, tutorials or training?
--
<URL:
http://wiki.tcl.tk/ > In God we trust.
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:
[email protected] > <URL:
http://www.purl.org/NET/lvirden/ >
I work on Perl & Mod Perl scripts on a ecommerce system critical server.
Very high volume/demand, very low tolerance for screw-ups/mistakes... The
server is comprised of hundreds of various Perl & Mod Perl scripts that
perform nearly every function/feature of the site. Besides the usual system
safeguards (tape backups, redundant servers/connections, raided storage
arrays, etc...) Here are my recommendations for a newbie/novice user on a
mission critical server running very important perl scripts.
1 - Backup any scripts that you are going to work on before you make any
changes! This makes it easy to roll back to a known working copy in case of
a problem. This saved my butt more then once! ;-) At the very minimum, I
recommend you at least follow this step...
2 - It may also be a good idea to create roll back file of each revision of
your more important scripts. (done in conjunction with #1) We have backup
folders above the public web root on those servers, where we backup all of
the critical perl scripts that we work on. We use a dating system as the
extension (in YYYYMMDD format). This lets us keep several revisions of each
file with the original file name & lets us have several different successive
revisions to roll back on. For example, if I applied an update today on
'myfile.pl'; I would create a backup called 'myfile.pl.20030108' in the
necessary backup folder.
3 - Where ever possible, never work on any script that is live. Instead
make a copy and work on that. You can run all of your syntax checks and
test runs on that copy. The helps safeguard your system from problems &
keeps the original online while you apply your updates & fix syntax errors
&/or bugs.
4 - Comment your code. I comment my code every few lines (nothing fancy,
just short and to the point statements), so I have a general idea what each
section does and how it works in generic terms. This makes reworking the
script months/years later much easier; as you can simply read only the short
comments and get a good feel how things are laid out & how they work...
5 - Keep a script history log where ever necessary. (similar to #4, but we
find is really required when dealing with more complex scripts &/or have
multiple programmers working of the files on a constant basis). We
generally use this for most complex scripts that are installed on client's
servers (we can tell what ours & outside programmer's change) & when working
on our large library modules (that the backbone of the scripts on our
servers) it lets us figure out who broke things & where they broke it. For
the largest most complex scripts, we always sign & time/date stamp the
script at the top of the script to show who & when it was last updated
(since we have several people working on the same files/scripts during the
same day). For stand alone programs published on clients servers, we keep
version numbers of each script revision we offer to our clients; as well a
history file of script updates/changes/etc... This makes knowing about
updates & back tracking a broken feature easier.
6 - If the script is really huge, very complex &/or is changed on a very
frequent basis, I recommend you setup a copy on a separate development
server. This way, your beta/development script can be messed with and
tested; where neither the live server or it's data is affected by changes;
until you are sure the beta is working correctly. This is of course the
most extreme case, but you get the point.
I hope this helps..
