I gave a talk on XML & Perl to our XSLT SIG at work this afternoon. I covered the usual stuff: plenty of modules to choose from, TIMTOWTDI, ways to solve different problems, different modules, etc. As the group mostly cares about XSLT, I mentioned XML::LibXSLT and Template::Plugin::XML::LibXML which I really like because it has the powerful bits of XSLT (XPath) without the complication. Besides, the more I think about templating, the more I like Template Toolkit, but that's another story for another day.
Roughly 10 people attended, which is a comfortable number for an informal presentation. Most of my colleagues prefer Java, but they largely seemed interested in how Perl can work with XML and asked some good questions afterwards. I didn't directly ask anyone what they thought of my talk, and nobody directly told their opinion, but I think it went well. At least, they seemed keen for me to give a talk on RSS in January.
On reflection, I realised I've given quite a few talks lately, so I decided I should try to draw some conclusions.
I've talked about Web templating at YAPC::Europe and Birmingham.pm, teaching Perl at London.pm, XML & Perl at work, and I've been involved in a couple of best practice groups at work, where I've been vocal and had to present my ideas in much the same way as giving a talk: describing things without the details, but with enough explanation as to make sense. I've also been teaching Perl to a beginner (hence the London.pm talk) which reinforces this.
The main thing I've learned is something I already knew: there's no substitute for experience. I always observe the audience as I talk, whether I'm giving a talk or involved in a discussion. It's important to let the audience guide you, but not too much. I think I've been guilty of inadvertantly rushing talks or prolonging them depending on how people respond. It's important to react to your audience, but you need to remember each audience differs. If you talk to London.pm in a pub, you know you'll have more audience involvement and feedback than if you talk to a quieter group of people. So, it's important to gauge each group's response relative to its normal behaviour.
I know I'm neither a great Perl programmer, nor a great communicator, but discovering that I'm good enough at both to deal with presenting programming in various ways is satisfying. Interestingly, I hadn't planned to teach, speak or advocate best practice - all this just happened.
I'm wary of concluding anything meaningful from all this, so I'll keep my conclusion simple: it's been fun.
At last night's London.pm birthday party, I somehow ended up discussing Acme::Current with 2shortplanks.
Mark mentioned an uncommitted patch he submitted Acme::Current that means the code to the module doesn't need updating daily, but still requires daily installation. Of course, you should never patch an Acme module to behave sensibly, in this case just report today's date.
We then got onto silly ideas about subclassing the module, to do things such as report tomorrow's date, and something sick involving $0 that I don't remember properly.
It fascinates me that people in close communities often come up with similar ideas at roughly the same time: zeitgeists and all that...
A while ago, I tried explaining the idea of Acme modules to non-Perl people, including non-programmers. I don't think anyone quite understood, including me.