It difficult to make an informed judgement on the basis of the description you provide, but from what you've said, I would warn you to be careful. As an 'external' who has been charged with 'bringing the internal guys up to scratch on X', I have met with some fairly hostile reactions to training that was perceived as being 'trivial', 'academic', 'theoretical' or as one guy put it, 'teaching your grandmother to suck eggs!.

I had more success with a technique passed on by one of my mentors. Get them involved in the process from the start and make sure that they can see the relevance and benefit of the training.

In this case, I would ask them individually or collectively depending on your judgement of which would be viewed in the best light, to nominate the "worst" piece of code in their daily/weekly routine.

Ask them to provide you with a copy (minus any authorship info to save faces), along with sets of input and output data where applicable. Take this away, spend a weekend or week or whatever it takes to re-work it utilising the skills you wish to demonstrate. If you have time and the chosen piece lends itself to the task, do and retain multiple passes, concentrating on one aspect of your list at a time. Make sure that your final revision will operate as a replacement for what you started with, even if this stops short of best practice because achieving that requires modifications to stuff before and/or after in the processing chain.

Your aim should be to show them how the concepts on your list can be used to real effect to improve their daily/weekly lot, and how they can be used to effect beneficial change within their operating environment. This is much less likely to provoke the kind of reactions that I listed earlier.

If you can lay your hands on a good display projector, and make the changes to the chosen piece of code IRT, in front of them, rather than doing it as a set of slides or a PowerPoint (or unix eqiv.) presentation, so much the better. That also gives you the opportunity to impress the hell out of them with your power use of emacs/vim. Pick on a common example of code that can easily be improved using idiomatic constructs. Something like changing C-style for(;;)'s to foreach(@array) or map{..}@array. Make the first change manually explaining the reasons and benefits, then let loose a macro to convert the rest of them in the file, (even if you have to write the macro specially beforehand), and continue to discuss the benefits whilst the macro operates on screen.

If you can find a good example of where a substantial piece of code can be easily and quickly replaced with a CPAN module, do it. If possible, do the installation of the module "before their very eyes". Crop the lump of code you are replacing and implement the replacement. Demonstrate that it works.

If there is one thing I personally hate on training courses, and especially mandatory ones, is contrived examples that I cannot see how to apply to my real-life problems. I remember an OO course that was based around Yet Another Cutesy Animal Evolution Problem as a demonstration of Inheritance. Don't do it! If your audience cannot see the benefit of your examples to their real lives, it likely that your instruction will fall on deaf ears. Be really careful not to patronise or talk down to them, and I would avoid 'homework' tasks.

On the other hand, if they see you reduce a large monolithic piece of their own code that they have already identified as a problem, to a set of nicely decoupled, potentially re-usable, easily maintainable and modifiable functions and/or modules, they are much more likely to accept their need for the instruction in the first place.

Good luck. I do not envy you your task.