Re: intro

Right, replying to my own questions...

> How do you advertise/publicise your courses?  

A lot of ours is word of mouth.  We also have a good relationship with 
local user groups (such as the local Linux User Group and the local
chapter of SAGE) who allow us to post advertisements if we offer
discounts to their members.  We're considering putting advertisements in
our weekly computer section of the local paper, but unsure whether this
will achieve much.  I guess we'll have to just try it and see.

We often have difficulty filling our courses... the last two weeks
before any course are usually a mad rush trying to get a few more people
in.  That said, we do usually get the courses very nearly full,
eventually :)

One of the things with our course is that it's modular... people can
attend whatever days they want to and just pay for the bits they need.
Therefore, people with some Perl experience might just want to come to
the CGI and web database days.  This works really well except for the
odd occasions when everyone seems to want to do certain modules and
nobody wants to do others.

We usually offer any leftover spaces to community groups and non-profit
organisations for just the cost of the materials (usually about $30 a
day).

> What requirements/prerequisites do you set for your courses?

We ask that they have some prior programming experience (any language)
and enough Unix knowledge to find their way around their home directory
and edit files (we give them a fairly wide choice of editors).  For our
CGI course, we also suggest that HTML experience is a Good Thing.

Unfortunately, people seem to just ignore the pre-reqs.  For a while,
our enrolment form made them check checkboxes that said they had the
appropriate experience, but then they would just lie.  So now we just
inform them of the pre-reqs and live with the fact that probably 10%-20%
of our trainees are underskilled.  Often this is because their bosses or
their HR departments have done the enrolments, and the actual trainee
hasn't even read the preliminary materials.

One thing we do is provide a "pre-training preparation" web page that
has short quizzes on it to self-test levels of skill in Unix and
Programming.  We give them the URL to this page when they enrol, and
suggest that they go through it.

We're about to start putting all our course materials on the web, so
this means that those who don't have Unix experience (for example) could
work their way through our Unix training course if they wanted to.  Of
course, we're taking a bit of a gamble with that, but we're hoping that
they'll find that training works better when you have someone to get
help from, and just enrol in the course :)

> What sort of course materials do you use?

I use printed course notes of approximately 50 A4 pages a day.  The
trainees are also given an HTML version of this to take with them, which
has hyperlinks to online resources and so on.

I like my training rooms to have an overhead VGA projector thingy and a 
large whiteboard.  I'm a real whiteboard user, with a tendency to stand
there and extemporize while scribbling.  I wave my arms around and jump
around a bit.  I've occasionally considered using a normal OHP but it
just wouldn't feel the same... though it might save me from my marker
allergy.

> What platforms do you teach Perl on?

We have the students on Windows boxes, telnetting to a training server
(usually a linux notebook, sometimes the FreeBSD training server at our
office if the course is (network-wise) close to home).  We're
considering making NT versions of some of our modules (the non-CGI ones,
basically) but since we hire training rooms from third parties, this would
mean ensuring that they install Perl on each of their Windows boxes, as
well as any modules we might need.  At the moment, I'm not sure I trust 
them to do this.

> Do you teach any third-party software with Perl?

We teach MySQL in our "web enabled databases with Perl and DBI" module,
and touch on PostgreSQL as well.  We also teach a number of non-core
modules.

> What do you find hardest to teach about Perl?

I find it really hard to explain to most people, especially those with
little or no programming experience, that "that's just the way it is"
with regard to Perl syntax.  They often seem to want to just make up
syntax and have it work, or not like the syntax as it is.  The only
answer you can give them is "tough luck. that's just the way it is" but
that's not very helpful to them.

Our trainers have a running joke about the most commonly mucked up
things, and if our classes seem pretty cool, we'll sometimes get a tally
going in the corner of the whiteboard for the most common mistake:

missing semicolon
mismatched brackets/braces/etc
mismatched quotes
/n instead of \n
messed up =~ operator
no -w or use strict
lack of indenting causes brace mismatch

This has the added benefit of keeping a reminder of common errors in
plain sight.

Just FYI, the semicolon and mismatched brackets/quotes are the most
common early in the course, then other more obscure ones start to catch
up.

> Do you use analogies and metaphors, anthropomorphisation, puppet shows?

I have this analogy about HTTP servers and how they work.  The "port 80"
concept was causing problems, so I now describe the web server as being
like a big castle with one of those HUGE doors.  And instead of just
having one of those little slidy peepholes, it's got hundreds of them,
all numbered, and a separate wizened little servant guy behind each one.
The servant behind the one marked 80 is the web server.

The analogy can get extended in horrendous directions if I want it to.
I draw pictures on the board and all.

> Do you get your trainees to evaluate your training?  What do you ask?

Yup.  We ask them to rate the following items from 1 (poor) to 5
(excellent):

trainer's communication skills
trainer's knowledge of subject
course materials quality
	also: too detailed, too brief, just right?
exercise/activity quality
	also: too many, too few, just right? too easy, too hard, just right?
overall quality of this course compared to others you've taken
value for money

Also, these comment fields:
where did you hear about us?
what could we improve?
any other comments?

I'm glad to say that our general approval rating is quite good, but we
do find that the sub-questions about the course materials and exercises
tend to get a really wide range of answers.  I think this just means
that our trainees vary.  If they were all saying the materials were too
brief, or that the exercises were too hard, that would at least be 
telling us something we could use :)

K.


-- 
Kirrily Robert <[email protected]>
http://netizen.com.au/ - Internet and Open Source development and consulting
Level 10, 99 Queen St, Melbourne VIC 3000
Phone: +61 3 9602 2452   Fax: +61 3 9642 4955