YAPC::Europe - Day 2 (24 July 2003)

09:00
Debugging Perl - using the available debuggers
I've never used the Perl debugger before, so this talk was one that I'd previously decided to attend. The problem with the Perl debugger is that it has quite a steep learning curve, but this talk was an excellent introduction. Szabo went through some of the basic commands to control the debugger, e.g. how to step through the code, watch variables, and set breakpoints. Finally he looked at some external debuggers, including Devel::ptkdb, a graphical debugger which looks to be easily comparable to the IDEs used by many other languages.

09:45
Writing your own debugger for Perl
While obviously creating a complete debugger or IDE is out of scope for a 20 minute talk, Szabo managed to get through the basics of writing a Perl debugger, with examples showing how to trap subroutines, extract the code that is being executed, and trace the program flow. This was an interesting companion to the previous talk, i.e. after showing us how to use the debuggers, we now see how they work.

10:10
TMTOWTDI - a manager's nightmare
Perl's motto is TMTOWTDI - 'There's more than one way to do it'. Karen Pauley talked about some of the problems with this in the business environment, with the conclusion that maybe the real problem is TIOORWTDIM - 'There is only one right way to do it - mine!'. She gave a number of ways to deal with this, such as coding standards, collective code ownership, refactoring, and knowledge sharing. Of course not all of these will be popular with programmers, but it was good to hear someone from 'the other side' talking about how they deal with these issues. Maybe next year we'll see 'Managers - a programmer's nightmare'... ;-)

11:00
Better Perl code in 65 minutes
Uri Guttman started his talk with a quiz to get people into the mood of what they should be thinking of as good coding practice, with the general theme of making code descriptive and maintainable. He then discussed the different contexts in Perl code, and finally looked at here documents. Personally I didn't agree about when here documents should be used - a lot of the time I think they make code less readable (e.g. when used in indented code blocks), and therefore contradictory to the first part of the talk. However this did give me an idea for a source filter module to handle indentation of here documents transparently.

12:10
All I need to know about Perl programming I learned from fairy tales
I don't really know what to write about this, the title pretty much says it all. Obviously quite light-hearted, Marc Kerr talked about the m// operator representing the story of Cinderella, the moral of Chicken Licken is always to use tests, and Inline.pm becomes 'The Invasion of the Body Snatchers'! Marc's final slide got the most laughs though - the cover of 'Perl6 Essentials' next to 'The Emporer's New Clothes'...!

14:00
Siesta - Richard Clamp
In typical London.pm style, and presumably as a celebration that Siesta was actually released today(!), Richard's talk had the bizarre rule that each time he mentioned the word 'Siesta', buth Richard and the front row of London.pm-ers would have to drink a tequila slammer. This certainally made for an unusual talk, which probably should have been titled 'How to talk about Siesta without mentioning Siesta'. Best question from the audience was "Does it count if we say Siesta?", to which Richard answered "No, only if I say Siesta". D'oh!!

18:00
20 things you may not know about Perl
This was in a similar style to the 'Perl Advent Calendar' talk given by Mark Fowler - a quick run down of lesser known modules or techniques - although this time with a 'Lord of the Rings' theme. I'm a big fan of these sort of talks, as even if you already know about some topics mentioned, these's that much on the CPAN that you can't help but to come away with at least some new ideas. I'll definitely be looking into Config::Auto and Memoize, and on a lighter note I loved hearing about Acme::Code::Police and it's nemesis Acme::Code::FreedomFighter - but probably not to be used on production systems...