Nathan Gregory

  • HOME

  • WRITINGS

  • BIO

  • CONTACT

  • More

    Wordpress Blog
    Wordpress Blog
    Wordpress Blog
    Book Website
    Book Website
    Book Website

    Black James Bond?

    December 24, 2014

    If Dr. Seuss were a technical writer

    September 17, 2014

    Communications

    August 3, 2014

    Lost Cell Phone Redux

    June 5, 2014

    Lost Cell Phone

    April 20, 2014

    So You're Still Using Windows XP?

    April 5, 2014

    Canned Perl - Using and enjoying Perl Modules

    November 19, 2013

    Who is Snooping?

    August 7, 2013

    Wither Privacy?

    August 5, 2013

    Carrying Your Data

    September 1, 2012

    Please reload

    Recent Posts

    Texting is a form of the spoken word, not writing. If you look at it in terms of how it is used, etc. The spoken word is generally ephemeral, for comm...

    Communications

    August 3, 2014

    Childhood Memories, Coincidences and a Dog named for a Monkee

    May 6, 2012

    The twitterverse erupted today when a popular talk show host expressed his disdain at the prospect of Idris Elba, a black actor of modest following, w...

    Black James Bond?

    December 24, 2014

    1/7
    Please reload

    Featured Posts

    Canned Perl - Using and enjoying Perl Modules

    November 19, 2013

    A simple guide to creating your own simple Perl modules.

     

    In the early unix days, a popular Unix tool was called the “Swiss Army Knife” because of it's extreme flexibility and usefulness. Sometime later another well-known Unix person extended the metaphor to the Perl language by calling it the “Swiss Army Chainsaw”, implying that it was extremely powerful, but noisy, ugly and tended to belch noxious fumes. Perl fans immediately adopted the epithet as a badge of pride.

    Perl is extremely powerful. Many aspects of Perl contribute to that power. One of the most important aspects is the Comprehensive Perl Archive Network (CPAN) where Perl fans can contribute bits of code to be reused by others. Many thousands of contributions are in the archive. Almost any complex function one can desire may be found there, enabling building complex programs in record time by simply incorporating a few modules.

    In the demonstration program “MusicL.pl” we incorporate a number of such modules. The module Tk gives us the graphical toolkit for GUI widgets. The module Balloon lets us place tooltips in the GUI. The module MP3::TAG let's us easily manipulate MP3 tags. Finally, File::copy::Vigilant let's us easily perform file copies and moves.

    Many of these functions are simple bits of code we could easily write ourselves. How hard could it be, for example, to copy a file? That said, there are many good reasons for using other people's modules.

    First, it saves time. Even as simple a function as copying a file takes a little time to write and probably more time to debug. Second, it encapsulates functions and processes away from the mainstream of the program, simplifying our overall logic. Thirdly, it makes for easier debugging. Whenever contemplating any new function in a program, one should always give the CPAN a scan for useful modules. Never write any code you can find already written.

    Modularity is an important concept in large programs. Keeping variables local, avoiding use of globals wherever possible and so on are important factors in writing code that is readable and maintainable.

    One can always abstract bits of code into subroutines. For example, in MusicL, we place the logic that splits a long filename into MP3 tags into a subroutine we call “Song_Split”. There are numerous such subroutines, from drawing dialog boxes to validating fields. Such subroutines are, in a sense, tiny Perl modules that serve to encapsulate functionality. Understanding and using subroutines is important to writing maintainable Perl.

    An experienced programmer will naturally build a “library” of favorite subroutines that will be reused in many different programs. Pasting these into a program, and then tweaking each instance for that program works, but one soon finds dozens of slightly different versions of the same program.

    One way to avoid this is to build a collection of subroutines into a common text file and include that text file into many different programs, generalizing each subroutine to work across all programs. A better way is to write your own custom modules. If a module proves really useful, it can be contributed to the CPAN for others to use, “giving something back” to the Perl community.

    At first glance, the inexperienced programmer might think perl modules are a bit of a “black art”. That is not really true, and we will show you how to make your own in just a few steps.

    We're going to create a sample module. We will call it zModule, and place it in a file named zModule.PM. Our module has five parts, or steps.

    The first step is defining the name space. This occurs in the package name, Package zModule. The namespace must be unique.

     

    package zModule;

     

    use strict;

    use Exporter;

     

    our $VERSION = 0.01;

    our @ISA = qw(Exporter);

    our @EXPORT = (); # Export Nothing by default

     

    # Export functions on demand

    our @EXPORT_OK = qw(rev1 map1);

    our %EXPORT_TAGS = ( DEFAULT => [qw(&rev1)],

    Both => [qw(&rev1 &map1)]);

     

    # This subroutine just reverses things

    sub rev1 { return reverse @_ }

     

    # This one Uppercases things

    sub map1 { return map{ uc }@_ }

     

    1; # Return a TRUE value so loader

    # knows load was successful

     

    Part two involves strict error checking and variable declarations. While Perl will allow for sloppy “quick and dirty” code, anything more than a throw-away program really must be more tightly defined, or you quickly build something that is a bug-ridden, unmaintainable mess. Strict is your friend! An annoying friend, but a good one. It can be tempting to disable strict when it becomes annoying, but trust me, you do not want to define yourself debugging a 1000 line program that was written without strict. Each variable used is defined using the “our” alias declaration.

    Part four, the Exporter simply invokes the logic necessary to use our module in another program. Note that we set things up so we export nothing by default, but rather only export our functions on demand.

    Part five is the actual code we want in the module, written as subroutines. In our example, we create two very simple subroutines, one reverses the order of any text passed to it, the other converts it to uppercase.

    The module is closed out with a True return value. This is provided simply so that the loader knows a load was successful.

     

    #!/usr/bin/perl -w

    use strict;

    my @list = qw (P e r l – M o d u l e s – R u l e !);

    use zModule qw(:Both);

    print rev1(@list),"\n";

    print map1(@list),"\n";

     

    Having built our test module, let us now build a program to use it. Our demonstration program also uses strict (of course) and invokes our zModule to call two functions. Our data consists of a space delimited array of letters. We save our program as zTest.pl, and when we run it, we see the first subroutine call returns the text in reverse order, and the second call returns it as all caps.

     

    $ perl zTest.pl

    !eluR-seludoM-lrPe

    PERL-MODULES-RULE!

    $

     

    Simple, huh? With nothing more than this simple example, even a relative neophyte programmer can write and use Perl Modules. This paper barely scratches the surface of the topic, and the user is urged to experiment and explore the subtleties of the process. But more importantly, the user is urged to use modules to keep your code, well, modular.

    Please reload

    Follow Us

    bond hero canon race

    circus boy

    corky

    internet

    letters

    pet

    text

    writing

    Please reload

    Search By Tags

    December 2014 (1)

    September 2014 (1)

    August 2014 (1)

    June 2014 (1)

    April 2014 (2)

    November 2013 (1)

    August 2013 (2)

    September 2012 (1)

    August 2012 (4)

    June 2012 (4)

    May 2012 (5)

    Please reload

    Archive
    • Facebook Basic Square
    • Twitter Basic Square
    • Google+ Basic Square