Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Matts (1087)

  (email not shown publicly)

I work for MessageLabs [] in Toronto, ON, Canada. I write spam filters, MTA software, high performance network software, string matching algorithms, and other cool stuff mostly in Perl and C.

Journal of Matts (1087)

Thursday March 28, 2002
08:56 AM

Teaching and CPANPLUS

[ #3823 ]

I really enjoy teaching. I think it's quite a rewarding thing to do. And generally quite fun. But *boy* is it hard work. From preparing the slides to going through what you need to teach, and the objectives you aim to reach at the end... lots of work. Every time I give a talk or tutorial I also realise that I just plain need more slides. There's simply no way around that - people grok stuff a lot more if you break it down really carefully into small components, and I'm forever discovering more ways to break down my slides to make these concepts easier to understand.

This is especially significant trying to teach XML stuff to Perl geeks. Last night trying to teach the basics of XSLT in 10 minutes reminded me that there's so much ground to cover before you can even get into XSLT itself - XML namespaces and XPath being the two core things there. But you can't do a tutorial like Hypertext - jumping right off one subject to another. It has to have a natural progression - and AxKit doesn't lead naturally into teaching XPath... So for now I simplify XPath by saying "It's unix directory paths into the XML". Which is how it was designed I guess. Anyway I hope my jumping about pointing to bits of my slides weren't too disjointed last night. I certainly realised one thing last night: you can't just teach one little bit and then expect the audience to grok a huge chunk of code just because it's using similar features... Each little bit needs explaining in detail.

Anyway... On to work. I spent a couple of hours the other day writing - a script which uses to download files from CPAN, build them, pull out pre-reqs, and build a proper LSB/RedHat RPM of the module. It works *really* well, for me. But the code is awful, because doesn't really expose an API, so it only worked in the most recent version of So today I'm having a look at CPANPLUS. I sent a patch to the author as it wouldn't compile on 5.6.1 with the latest Term::ReadLine. It looks nice - I can now basically go fetch(), extract(), do my make bits, built the .spec, copy it to /usr/src/redhat/... and build the RPM. Much easier than my hacky code around Neato.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • by ziggy (25) on 2002.03.28 10:19 (#6451) Journal
    I was reading an article [][*] yesterday that talked about how successful technologies become successful (Palm Pilot, Cellphones), and how unsuccessful technologies fail (pairing FM Radio with cellphones, tablet PCs).

    The long and short of it is that it's quite rare that a technology succeeds simply on it's merits. It is much much more common to produce a product that actually solves an existing problem in a user friendly manner.

    Nothing new here, but it's surprising how often this lesson needs to be learned and the number of contexts to which it applies.

    Teaching anything about XML is notoriously difficult because the people who know enough about it are attracted to the technology, not to the user's problems. (I for one still don't understand the allure of HyTime, except that it provides a nice rat's nest of abstractions that will seed a thousand meaningless PhD theses.)

    Most of the time in XML Club, it's nice and easy to describe what an innovative module like XML::Twig or SAX Machines does in about 45 seconds. Establishing that level of experience from ground zero is very difficult, because the simple process of converting Document A into Document B doesn't naturally lead to the discussion of xml:base, namespaces, pipelines or processing instructions. Ostensibly, that is what students want to learn, but what they really want is a way to see how their transformation from A to B is easier with the appropriate incantations of UDDI, WSDL, SOAP and REST (or Namespaces, XPath, XSLT and RELAX).

    The couple of outlines I've been writing and reviewing for the last few months de-emphasize the technology and re-focus on the problems being solved (and why things like Namespaces are a good thing, instead of offering simple proof of existance through usage). This is somewhat similar to the same approach used by Abelson and Sussman in SICP: start with a common problem (lcm, gcd) and rework it until the underlying concepts are clear, and then move on to passing closures all over the place.

    *: Unfortunately, the teaser is free, and the PDF-you-pay-for is about as much as the entire magazine; it's quite worth reading.

    • Amen. So, so much of technical literature (books, magazines, online articles) start off with "Today we'll be learning about super dooper new technology X. I'll show you how it can be used to convert widgets of type A into type B...".

      Of course I have no idea why anybody would want to do that. Maybe there is no good reason in which case I'd like to be able to skip the whole article. But if there is a good reason knowing it makes it so much easier to learn the technical details.

  • I used to have to teach SGML to developers in my old company.

    That was 6 years ago, so there was no XML at the time, and the web was in its infancy, at least in France, so I could not even rely on students knowing HTML. Heck I did not know HTML!

    So SGML itself was quite hard to explain, without even getting into the intricacies of CONREF and implied mark-up. But think that at the time the cool technologies, the equivalent of XPath and XSLT, were HyTime and DSSSL. And I know HyTime is not equivalent to XPat
  • I really enjoy teaching. I think it's quite a rewarding thing to do. And generally quite fun. But *boy* is it hard work.

    I once thought I should be a teacher, because I liked explaining things.

    But it turns out that I like to explain a thing once.

    So I write instead of teach.