This kind of relates to what biohisham said, but I have run a few courses and attended a few more, and the best ones are usually those that work through a problem. This way it can be tailored to what people will do, and gives them the chance to experiment within their own ability and 'learn to teach themselves' - i.e. you can show them the best forums and documentation.

Identifying the best problem(s) is the important part, and others here will have a much better idea of the best resources to get people familiar with. I guess the important point is that the problem should teach them the basics and allow room for allowing people to learn and develop if they already/quickly get the basics.

Hope this helps,

So, if you do more of data/text processing then touching on file/folder management, regular expressions, loops, I/O operations, buffering, different ways to open and read files, data structures and persistence so modules like DB_File, Storable..etc come to mind. If you are on the web programming side, CGI, Socket programming, IPC, DNS resolution are maybe what needs to go under the spotlight. If you are on the Graphical side, Tk and company

But notwithstanding, developing the way to think a situation through is worthwhile, I mean, you may not teach them everything but make them aware of the topics and resources that they can reach to and how they go about it, so perldoc, CPAN, The Monastery and references to interesting books need to be mentioned...

One thing I would definitely include is how to find and select modules appropriate for the task (involving CPAN, checking out the module and asking around on sites like perlmonks). This should be new terrain to the C++ guys at least (AFAIK).

Also there should be a question geared toward showing the advantage of using 'foreach' or 'map' to using 'for (;;)'. While JavaFan got a point about TMTOWTDI, using for(;;) on a fixed array is just not using the power of perl

And you should show them the power of hashes (if they not already know that). Using hashes is what differentiates intermediate perl programmers from beginners

Yes, those are very much elements that I had in mind and good confirmation that my initial ideas aren't too far off the mark.

CPAN will get coverage, but most of these people are accustomed to using the Boost library which provides some inoculation against the "ain't written here" syndrome that often mitigates against using resources like CPAN. Probably I'll use Getopt::Long as an example module - something that's pretty much immediately useful and easy to understand and use.

Using for in for (;;), for (x .. y) and for (@array) variants to compare and contrast the different usage modes for for loops was definitely one item on the list of topics to cover.

The power of hashes is indeed another "must cover" topic.

True laziness is hard work

I agree with the suggestions above. Hashes, especially, change the way you think about data.

Regex in Perl is pure gold too, and could take months to teach if you went into any amount of detail.

One thing I'd do is teach how to get information in Perl. Not just CPAN (though that's a great suggestion cuz there's so much to do), but perldoc, and just how simple it is to formulate a quickie test program. I'd think that perltut would be a decent place to start.

For me, I use Perl most often, not to build a massive production piece of software, but just to automate the environment and the data generated by the legacy systems I'm consigned to maintain. So getting text/arguments/pipes/sockets/data into my program and doing something quick with it, etc... is very useful to me. Perl's so nice in that way. I also love how Perl handles References--the hash of hash (of etc.) is a beautiful thing.

So the question is: what should I feed them?

It is interesting to note that the Cish Perl programmer is the one who suggested the training day and largely because he was very impressed with the way I managed to tidy some of the Cish code he'd written and wasn't happy with.

Sure you can write any old crap that works most of the time in pretty much any old language, but by knowing a little more of what's possible with whatever tool you are using you are likely to get better use out of the tool. The purpose of the training day is to show some of what's possible. The reason for asking here is to get a broarder idea of the things people think important so I can make a better informed decision about what to include and to what depth.

True laziness is hard work

It will surprise you how little of the material you might prepare will actually be used, so take care not to allocate too much of it.   I strongly recommend that you consider the following:

1. Plan for four sessions of one hour’s duration with plenty of discussion and down-time between.   The second and third sessions will be the most productive.
2. Insist that the event be catered, at least to some degree, and not just with sugary sweets.   Insist also that the mid-day be occupied by a lunch that all participants can go to, privately.
3. Set a list of no more than five “training objectives” for each session.   Each objective should be expressed as a single sentence.   Review the objectives at the beginning and at the end of the session, and present each objective in this way:
   • “This is what we are going to cover.”   If you have questions as we proceed, note them and we will cover them at the end of this section.
   • Cover it, at an even pace.
   • “This is what we have just covered.”
   • Kill time for about thirty seconds.   “Now may I take the first question, please?”   (If you ask, “any questions?”, the answer will be, “No.”)   Be inviting, and patient, and scan the entire room for questions.
4. At the end of the presentation, repeat once again the call for questions.   Be about five minutes early for the next session and repeat the call for questions – call for “the first question about” anything up to that point.
5. Wait until anyone completely finishes speaking, restate the question as you understood it (but in your own words), pause, and ask unhurriedly if you were correct.   If so, then answer the question, using the terminology that the asker used or carefully and clearly substituting the more appropriate terms.   If you do not have an immediate answer, carefully write it down and say that you will get an answer at the next break.   (It is helpful to have a “research assistant” in the room who can Google things for you and furnish you with the information sought while you continue.)
6. In a training session of this kind, terminology is the biggest potential boulder-in-the-road, especially since some folks will be coming to the seminar with different meanings for some of those words.   Therefore, the beginning of your first session might be to present a glossary of the most important terms.   Actually distribute this, go over it point by point, and remember to use 16-point type or larger.   Use ordinary vernacular, and take care that you do not merely substitute one “loaded word” for another.   Take care that your glossary is complete.   People will have it out on their desktops all day.   Notice if someone abruptly stops listening to you and starts looking at that piece of paper.   (Printing it on slightly beige colored stock helps you to see from a distance when they are studying that paper:   you know that you have briefly “lost them.”   Slow down.   Reconsider, on-the-fly, your most recent point, but do not call-out that person.   Do not negatively reinforce the behavior of people using the resource that you yourself have given them for that purpose.
7. Even if you are a co-worker with these people every single day, do not under-estimate your power as an instructor, nor the unacknowledged vulnerability inherent in being in a classroom setting, even “among friends.”   Don’t try to be a comic to relieve the tension.   Speak slowly and clearly.   Have water, but in a bottle that you can seal.   (Heh.)
8. Expect butterflies.   They will fly.   (Become worried only if you do not feel them.)

If you know who is going to be participating, try to spend a little time with each of them a couple of days ahead, show them your proposed outline and ask them about things they would particularly seek to know.   Note each person’s name next to the item on your outline, and when you begin and end this point, make a general gesture in their general direction without calling them out by name, and ask the wind ... “is that helpful?”

In a professional-training setting, do not quiz.   Unless you have been tasked to assure a particular competency that they are required to demonstrate (which is not the case here), do not put anyone on the spot.

(Ummm, yes.   I have been.   For many years.   Still am.)

I would structure the training in five parts

1. why is it beneficial to learn perl?
   • here I would mention features that make things different, e.g.hashes and regexes
   • at the end of this part the audience should want to code in perl
2. perl basic syntax
   • e.g. structure of a program, defining variables, creating subs, opening files etc.
   • after that block the audience should be able to copy&paste small programs (which might look very c-ish/php-ish)
3. how to use perl
   • enabeling the audience to write and execute a small script - this includes the IDE you use, possible testing environment
4. perl enhanced syntax
   • hashes and regexes
   • nested hashes/arrays
   • special variables (e.g. $_)
   • special kinds of loops (foreach, map ...)
   • at the end of this block the audience should be able to get an idea what happens in scripts they get to read
   • ... however tell them it is fine to use constructs they are used from c++/php-experience
5. example programs from your domain
   • show them some small fragments they will likely be using when they start programming in perl

perltrap - Perl traps for the unwary

If I were to take a training day on $newlanguage, I would want to know the domains it should be used in, what it excels at, what it has a hard time doing, syntax, idioms, libraries and tools at my disposal, and where to go for more help and information. Finding out what I don't know about the language would be useful. It sounds like your audience has coding experience, so you aren't teaching them how to code, just the proper use of this particular tool.

If your participants have experience in other languages, perhaps it would be worth exploring some tasks where the solution in the language of experience and Perl are different - for loops going over an array for example. Usage of (and when not to use) grep, map, and so on I could see being useful as well.

Disclaimer: my co-workers and I are not programmers; we are hardware (chip) designers. However, many of us use Perl regularly to make our lives easier in a unix setting.

From memory, here is the condensed list:

• Every Perl script must have this exact shebang line: #!/usr/bin/env perl
• Every Perl file (script and module) must have use warnings; use strict; near the top
• Perl documentation is available online at Perl documentation and at the command prompt, for example perldoc -f split
• A link to CPAN.
• To get help, use google, and for a more focussed search use PerlMonks' Super Search
• Debug with print and Data::Dumper
• To help understand someone else's ugly code, run it through perltidy
• Check your code for potential issues using: perlcritic -1 my_script.pl
• You can test your Perl code using Perl: Test::More

... four people with various previous Perl experience ranging from none through "can write nice PHP web apps in Perl" to "can write useful tools in Cish Perl". Most of them have extensive experience with other languages ...

I haven't much choice over the composition of the group. It's a fairly major coup to have been asked to do this at all. We have been mainly a Windows/C++ shop developing what amounts to a single large data acquisition and analysis package that has been used exclusively with the signal conditioning and data collection hardware our company sells. Perl has been a tool relegated to behind the scenes stuff that I've mostly been involved in. But we are growing and are becoming involved in managing Linux boxes for web based systems so Perl tools are becoming more important.

True laziness is hard work

There have been mentions of the power of hashes and Ratazong specifically mentions nested hashes/arrays. I would expand that slightly and suggest that, if you have the time, you show how you might construct a simple data structure, e.g.HoA, from information in a file. You could then use Data::Dumper->Dump() or ->Dumpxs() to show your colleagues how easy it is to verify the data structures you have built. I think that seeing the compilable Perl code produced as Data::Dumper output would be very instructive.

I would suggest using at least half an hour of that time to show your workmates how to use Perl::Critic (or Test::Perl::Critic).

Set P::C on a quite high verbose level and provide each workmate with a copy of Perl Best Practices.

Since a single day is a rather short time for training, with P::C you will them a valuable tool with which they further their knowledge on their own as well as check their code for common mistakes and problems.

Just my 2 cents...

I like ratazong's outline as a straw man. Do you have something like this in mind? Could we see what you're already planning?

I might start with a simple "hello world" with vi/notepad and execute at the command prompt. Use this to get their feet wet quick and show them the basic environment before moving to your IDE / advanced environment. Build up from HelloWorld to show the importance of strictures (and diagnostics) and how to 'use' a module (you could come back to this later to discuss CPAN). I consider this a small improvement on ratazong's outline. At some point early, point them to perldoc and online reference material.

In addition, I've got many good style suggestions from you through my years reading at perlmonks. I would think you could easily add a section on simple testing, style and why certain things are better than others (e.g. for vs. map in void context). This might be a section between ratzong's 4th and 5th; after all the generic and before the particular.

At the end point them again to reference materials. I've got a lot from perlrun, perltoot, perlreftut, perldsc and perlre(.*). OK, and many more.

Oh, and encourage them to join PerlMonks! That's where I got most of my perl learning.

1. Get 'em hooked
   • The introduction is the hardest part. A lasting impression is going to keep them future-engaged.
   • This goes back to what JavaFan pointed out. First, you have to understand what your participants need. Then, you need to convey how Perl can solve their problems effectively and easily. Think CPAN synopses -- show short, real-world applicable, snippets of code.
   • Oh, and you need to keep this part terse too. Drag it long and you lose the initial bang!
   
   
2. Get 'em started right away
   • Craft a basic program (readline loop, hash, regexp), and show how you'd run it.
   • Explain the basic syntax. Refer to what Ratazong mentioned.
   • Have the participants code hands-on (after presentation). Help them overcome their initial "awkwardness". Help them past their first mistakes and have fun.
   • Live demo, if you're up to it.
   
   
3. Lay 'em some simple rules
   • Rules cultivate habit that would help when they're initially on their own.
   • I really like the list from toolic and what it represents. It's practical, it's simple, it serves as a base guideline. Also, it has passed by hardware designers (and trust me, they're one the pickiest, most paranoid bunch of people ;-)
   
   
4. Show 'em where to get help
   • Show them the M in RTFM, and how to look it up.
   • perldoc and on the web.
   • PerlMonks, of course.
   • perltrap, what AnonyMonk said.
   
   
5. Show 'em CPAN
   • Explain the reasons why one would leverage CPAN code.
   • Explain how to grab and use a CPAN module.
   • Yes, even you can use CPAN
   • Show off the cool stuff.

Well, the Perl Training Day finally happened. We covered about half the material I prepared, but it was a great success. I had aimed for the day to be fun, for each person to finish the day feeling they had learned worthwhile stuff, to introduce interesting and important corners of Perl and to get people comfortable with using a variety of Perl resources. So far as I can tell I succeeded on each point despite a large disparity in the backgrounds and skills of the participants.

So, how did I structure it? Well, the fun element was the lollipop element (think node rep and XP). The material was structured as a series of exercises where the participant did some guided research, then a coding exercise, then a group discussion that examined the code generated by individuals in the group and some reference code that I provided. This structure worked very well with those quicker on the uptake or with a more appropriate background getting the core task completed first, but then going on to play with their solution, or helping others in the group.

The following is the day plan we followed, although time slipped and not all the material was covered:

I'll follow up with the reference solutions next week - I forgot to email them home for formatting clean up before uploading here.

Somewhat more than a week later! However, here are the reference "answers":

Session 1

Code: Hello World x 10
perl -e "print qq{Hello World\n} x 10"


Code: Reverse stuff
perl -e "print join ' ', reverse 1 .. 20"
perl -e "print scalar reverse join '', 'a' .. 'z'"


Code: Reverse less stuff
perl -e "@array = 1 .. 20; @array[5 .. 10] = reverse @array[5 .. 10]; 
+print qq{@array}"


Code: Reverse less stuff – string version
my $str = join '', 'a' .. 'z';

substr $str, 6, 7, reverse substr $str, 6, 7;
say "$str";


Code: Hashy uniqueness
Case sensitive version
my $name = "Peter Jaquiery";
my %letters;

++$letters{$_} for grep {/[a-z]/i} split '', $name;
say join '', sort keys %letters;

Case insensitive version
my $name = "Peter Jaquiery";
my %letters;

$letters{lc $_} //= $_ for grep {/[a-z]/i} split '', $name;
say join '', map {$letters{$_}} sort keys %letters;


Code: sub – optimal defaults
#!/usr/bin/perl
use strict;
use warnings;
use 5.010;

test('a');
test('b', 0);
test('c', 2, 0);
test('peter ', 2, 3);

sub test {
    my ($str, $lines, $reps) = @_;
    die "No string provided" if ! defined $str;

    $reps ||= 1;
    $lines //= 1;
    say $str x $reps for 1 .. $lines;
}


Session 2

Code: Go loopy
#!/usr/bin/perl
use strict;
use warnings;
use 5.010;

my $count = 0;
my $bailed;

say "Enter 0 to bail.";

while (my $target = int rand 11 and say "I have a number from 1 to 10.
+") {
    print "What is your guess: ";
    my $guess = <>;

    chomp $guess;

    if (!$guess) {
        $bailed = 1;
        last;
    }

    if ($guess == $target) {
        say "You got it.";
        next;
    }
    
    say "Your guess is too ", $guess < $target ? "low" : "high";
    redo;
} continue {
    ++$count;
}

say "I'm sick of playing now." if ! $bailed;
say "You guessed $count numbers.";


Code: An odd hash
#!/usr/bin/perl
use strict;
use warnings;
use 5.010;

my @array = map {int rand 100} 1 .. 20;
my %numbers;

push @{$numbers{$_ % 2 ? 'odd' : 'even'}}, $_ for @array;
say "@{$numbers{odd}}";
say "@{$numbers{even}}";


Code: Passing Arrays
#!/usr/bin/perl
use strict;
use warnings;
use 5.010;

my @array = map {int rand 100} 1 .. 20;
my %numbers;

push @{$numbers{$_ % 2 ? 'odd' : 'even'}}, $_ for sortList (@array);
say "@{$numbers{odd}}";
say "@{$numbers{even}}";


sub sortList {
    return sort {$a <=> $b} @_;
}


Code: Passing Arrays by reference
#!/usr/bin/perl
use strict;
use warnings;
use 5.010;

my @array = map {int rand 100} 1 .. 20;
my %numbers;

push @{$numbers{$_ % 2 ? 'odd' : 'even'}}, $_ for @array;
$_ = sortList ($_) for @numbers{'odd', 'even'};
say "@{$numbers{odd}}";
say "@{$numbers{even}}";


sub sortList {
    return [sort {$a <=> $b} @{$_[0]}];
}


Code: What the hash!
my %hash = (1 .. 20);
say join ' ', theSub(%hash);
sub theSub {return @_;}


Code: Hash sorted
my %hash = (1 .. 20);
say join ' ', theSub(%hash);

sub theSub {
    my %hash = @_;
    return map {$_, $hash{$_}} sort {$a <=> $b} keys %hash;
}


Code: Reversing old school
my @array = 1 .. 20;
my @reversed;

unshift @reversed, shift @array while @array;
say "@reversed";


Session 3

Code: Normalise a file path
(my $path = 'c:\This\That\something\else') =~ s!\\!/!g;
say $path;


Code: More normalise a file path
(my $path = 'This:That\something/else') =~ s![:\\]!/!g;
say $path;


Code: Lines of numbers
my @lines = split '\n', `perldoc perlrequick`;
say for grep {/\d/} @lines;


Code: This or that
my @lines = split '\n', `perldoc perlrequick`;
say for grep {/(or|not)\s+more\b/} @lines;


Code: Just this or that
my @lines = split '\n', `perldoc perlrequick`;
say for map {/(or|not)\s+more\b/; $1} grep {/(or|not)\s+more\b/} @line
+s;


Code: play it again Sam
my @lines = split '\n', `perldoc perlrequick`;
say for grep {/\b(\w+)\s+\1/} @lines;


Code: you wear that in public?
my @apparel;

while (defined(my $line = <DATA>)) {
    chomp $line;

    my ($name, @items) = split /\s*,\s*/, $line;

    while (@items >= 3) {
        my %row;

        @row{qw{name item colour material}} = ($name, splice @items, 0
+, 3);
        push @apparel, \%row;
    }
}

for my $row (grep {$_->{colour} eq 'blue'} @apparel) {
    printf "%-10s %-10s %-10s\n", @{$row}{'name', 'item', 'material'};
}

__DATA__
Peter,shirt,white,cotton,trousers,black,cotton,shoes,black,leather,bum
+ bag,black,synthetic
Ina,shirt,grey,cotton,jeans,blue,denim,shoes,light grey,leather
Phil,T-shirt,blue,synthetic,jeans,blue,denim,sneakers,blue,synthetic


Code: Nasty sentences
#!/usr/bin/perl
use strict;
use warnings;
use 5.010;
use Lingua::EN::Sentence;

my $para = <<PARA;
Sentences can be hard to parse. Take the following for example:
"Mr. Jones works for I.B.M. ... or maybe not.". (Not so easy eh?)
So, did this get it right?
PARA
my $sentences = Lingua::EN::Sentence::get_sentences ($para);

say "$_\n" for map {s/\n+/ /g; $_} @$sentences;


Session 4

Code: Create a password
perl -e "@chrs = ('a'..'z', 'A'..'Z', 0 .. 9); print ((map {$chrs[rand
+ @chrs]} 1 .. 10), qq{\n})"


Code: reprise - you wear that in public?
use DBI;

my $dbh = DBI->connect ("dbi:SQLite:Test.sqlite");
die "connect failed: $DBI::errstr" if ! $dbh;
$dbh->{AutoCommit} = 0;
$dbh->{RaiseError} = 1;
$dbh->{PrintError} = 0;

my $sql = qq{CREATE TABLE People
    (
    name VARCHAR(100),
    item VARCHAR(30),
    colour VARCHAR(30),
    material VARCHAR(50)
    )
};

eval {
    $dbh->do ($sql);
    $dbh->commit ();
    return 1;
} or do {
    $dbh->rollback ();
    die "Failed to create table: $@\n";
};


$sql = qq{INSERT INTO People (name, item, colour, material) VALUES (?,
+ ?, ?, ?)};

my $entries = 0;

eval {
    my $sth = $dbh->prepare ($sql);

    while (defined (my $line = <DATA>)) {
        chomp $line;
        
        my ($name, @items) = split /\s*,\s*/, $line;
        
        $sth->execute ($name, splice @items, 0, 3) while @items >= 3;
    }

    $dbh->commit ();
    return 1;
} or do {
    my $err = $@ || "Unknown error inserting data";
    
    eval {$dbh->rollback ()} or $err .= "\n   Rollback processing fail
+ed!";
    die $err;
};

__DATA__
Peter,shirt,white,cotton,trousers,black,cotton,shoes,black,leather,bum
+ bag,black,synthetic
Ina,shirt,grey,cotton,jeans,blue,denim,shoes,light grey,leather
Phil,T-shirt,blue,synthetic,jeans,blue,denim,sneakers,blue,synthetic


Code: mix and match
use DBI;

my $dbh = DBI->connect ("dbi:SQLite:Test.sqlite");
die "connect failed: $DBI::errstr" if ! $dbh;
$dbh->{AutoCommit} = 0;
$dbh->{RaiseError} = 1;
$dbh->{PrintError} = 0;

my $sql = qq{SELECT name, item, material FROM People WHERE colour LIKE
+ ? order by name};

eval {
    my $sth = $dbh->prepare ($sql);

    $sth->execute ('blue');

    while (my $row = $sth->fetchrow_hashref ()) {
        printf "%-10s %-10s %-10s\n", @{$row}{'name', 'item', 'materia
+l'};
    }
};


Code: dir, ls or something else
my $secPerDay = 60 * 60 * 24;
opendir my ($scan), '.' or die "opendir failed: $!\n";

while (defined(my $entry = readdir $scan)) {
    next if !-f $entry;

    printf "%-20s %10d bytes  %s\n", $entry, -s $entry,
        scalar localtime($^T + $secPerDay * -M $entry);
}


Code: Simple calculator
#!/usr/bin/perl
use strict;
use warnings;
use 5.010;

my %kOps = (
    '*' => sub {return $_[0] * $_[1];},
    '+' => sub {return $_[0] + $_[1];},
    '-' => sub {return $_[0] - $_[1];},
    '/' => \&div,
    );


while ((print "Expression: ") and defined(my $line = <>)) {
    chomp $line;

    my @parts = grep {/\S/} split / |\b/, $line;

    last if !@parts;

    eval {
        unshift @parts, process(\@parts) while @parts > 1;
        return 1;
    } or do {
        print $@;
        next;
    };

    if (!@parts) {
        say "No result calculated for: $line";
        next;
    }

    say "$line = $parts[0]";
}


sub process {
    my ($parts) = @_;
    my ($lhs, $op, $rhs) = splice @$parts, 0, 3;

    die "Bad expression syntax.\n"
        if !defined $rhs || $lhs !~ /^\d+$/ || $rhs !~ /^\d+$/;
    die "Not an operator: $op\n" if !exists $kOps{$op};
    return $kOps{$op}->($lhs, $rhs);
}


sub div {
    my ($lhs, $rhs) = @_;

    die "Divide by zero\n" if !$rhs;
    return $lhs / $rhs;
}
[download]

True laziness is hard work

One thing that comes to mind though is that if I'm being pulled into a training session on a new technology, whether there's a mandate that it be used or not, I generally need to be sold on it.

For example: As a C++ weenie it took a LONG time for me to reach for perl as a preferred tool for certain tasks. What finally did it was regular expressions.

If I'd understood something of the power of regexes early on it would have been a much quicker transition ;)

This would mean they are already familiar with the specific problem the code needs to solve. They also return with some physical evidence of that they did in that day not "only" with what they have in their head.