Learning perl when in the frying pan...

Discussion in 'Perl Misc' started by lvirden@yahoo.com, Jan 9, 2004.

  1. Guest

    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: > <URL: http://www.purl.org/NET/lvirden/ >
     
    , Jan 9, 2004
    #1
    1. Advertising

  2. Uri Guttman Guest

    >>>>> "l" == lvirden <> writes:

    l> Now I'm faced with the opportunity/challenge/ {pick your
    l> politically correct term} with maintaining a rather complex and
    l> critical perl application written by someone else (no longer
    l> available for guidance, etc.), with this minimal background in
    l> perl.

    l> I'm trying to figure out what steps I can take to bring my skills up. Of
    l> course, the first thing will be to read Programming Perl again.

    l> But what else would help someone get become comfortable in Perl code,
    l> particularly perl code using lots of objects and references?
    l> Any other books, online articles, tutorials or training?

    the new book 'perl objects, references and modules' by randal schwartz
    sounds like the ticket. it is the follow up to learning perl.

    also hiring someone (HINT!!! see .sig below) for this project would be
    another good solution, even if just to help decipher the code. also a
    refactoring (incremental rewriting but not changing behavior of the
    program) project is a possibility. this depends on how well/badly the
    code was written and how much you have to understand it all to maintain
    it.

    uri

    --
    Uri Guttman ------ -------- http://www.stemsystems.com
    --Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
    Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
     
    Uri Guttman, Jan 9, 2004
    #2
    1. Advertising

  3. James Guest

    <> wrote in message news:btmuj4$a89$...
    >
    >
    > 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: > <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..
    --
    James

    (Remove NOSPAM When Emailing)
     
    James, Jan 10, 2004
    #3
  4. gnari Guest

    "James" <> wrote in message
    news:ksLLb.118624$...

    > ... Here are my recommendations for a newbie/novice user on a
    > mission critical server running very important perl scripts.


    this is a scary sentence.

    >
    > 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...


    in fact, use an automatic process to backup regularly.

    use a version control system, such as CVS

    >
    > 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) ...


    use a version control system, such as CVS

    > 3 - Where ever possible, never work on any script that is live.


    what do you mean where ever possible?
    just NEVER work on live stuff.

    keep your source tree separate, and create test suites
    use Makefiles:
    make
    make test
    make install
    make test should at minimum do perl -w -c *.pl

    > 5 - Keep a script history log where ever necessary. (similar to #4, but

    we

    CVS

    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.


    do this allways. at the very least, have a separate test instance of the
    application
    for testing. if your work includes modules, or your changes involve module
    upgrades,
    it is tricky to make sure the changes do not afect the production system, so
    use a development server.

    use CVS to keep track of differences between production and test servers.


    gnari
     
    gnari, Jan 10, 2004
    #4
  5. pkent Guest

    In article <ksLLb.118624$>,
    "James" <> wrote:

    > 1 - Backup any scripts that you are going to work on before you make any

    ....
    > 2 - It may also be a good idea to create roll back file of each revision of

    ....
    > 3 - Where ever possible, never work on any script that is live. Instead

    ....
    > 5 - Keep a script history log where ever necessary. (similar to #4, but we

    ....

    [To the original poster, mainly, even though I'm replying to your post]

    Which is all made easier by using a revision control system such as CVS
    (there are others). The first thing I do with code that we get copies of
    is to stick it in cvs. You get a full version history, you work on
    non-live copies, you get the ability to tag files, you get a log... for
    free. And it's easy to back up a CVS repository because it's all under
    one folder (in general).

    P

    --
    pkent 77 at yahoo dot, er... what's the last bit, oh yes, com
    Remove the tea to reply
     
    pkent, Jan 13, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kurt

    Pan/Zoom Image class?

    Kurt, Oct 22, 2003, in forum: Python
    Replies:
    1
    Views:
    455
    Diez B. Roggisch
    Oct 22, 2003
  2. alex23
    Replies:
    0
    Views:
    412
    alex23
    Apr 2, 2008
  3. Czenek

    Pan/Zoom with Matplotlib

    Czenek, Oct 18, 2008, in forum: Python
    Replies:
    1
    Views:
    345
    Czenek
    Oct 18, 2008
  4. Replies:
    3
    Views:
    640
    edexter
    May 24, 2009
  5. Patrick Doyle
    Replies:
    9
    Views:
    120
    Charles Oliver Nutter
    Aug 18, 2008
Loading...

Share This Page