A few weeks ago, I mentioned that I had two days of public training coming up in Manchester in April. I’ve just heard that the organisers have decided to cancel this training as they have had no bookings for the classes. I’m sorry if anyone was planning to book closer to the date and has been inconvenienced by this.
I’ve spent a lot of the last seven days running training courses. It might be interesting to share some thoughts about how they went.
Last Saturday was Perl School 4. A week before the course I was a little worried about ticket sales, but I did a bit of marketing early last week and managed to more than double sales in a few days. In the end I had 27 people signed up.
Perl School is always enjoyable. I think that people often turn up with quite low expectations as it’s so cheap. So it’s fun to overturn those expectations and give them a day of high quality training. People obviously recognise that as I’m getting a lot of repeat business – at least one person has come along to three of the four courses so far.
Many of the courses I give are overviews of Perl at various levels. This one was just about DBIx::Class so it was great to be able to go into a lot more depth on a single topic. Of course, DBIx::Class is a great subject to cover and it was fun explaining its more powerful corners to a room of people who don’t know much about it.
I thought it went well. But don’t just take my word for it. I’ve been asking attendees to fill in feedback forms about all the Perl School courses and I’ve published a page summarising that feedback.
Then this week has been two two-day courses for flossUK. Two day courses give us time to include practical sessions so that people go home having actually tried out the techniques that I’ve taught – which nicely reinforces the lessons. I really enjoy those sessions as you really see lightbulb moments as people see how easy it is to use these tools. This afternoon, for example, it was great to see people getting a simple Catalyst application up and running in less than an hour. An hour later people were really impressed as I introduced them to Plack::Middleware::Debug and showed them how I could get detailed DBIC_TRACE output on the web page by making tiny changes to the application code. At least one person went away determined to reimplement a number of key applications in Catalyst as soon as possible.
And that, to me, is the joy of running training courses. It’s great to open people’s eyes to the possibilities that these new tools give them. I love to see them leave filled with renewed enthusiasm for the language.
The Perl community on LinkedIn is fascinating. It’s a great way to see how Perl is perceived and used outside of the echo chamber. And that’s a real eye-opener.
Here’s an example. Every few weeks (it seems) someone asks for advice on Perl books.At that point a few people will jump in with sensible suggestions. But for every reasonable suggestion, you’ll get three or four people suggesting something from this list:
- Something horribly out of date. A lot of publishers stopped updating their Perl books about ten years ago. The most recent version of Perl Black Book that I can find is from 2001. Teach Yourself Perl in 21 Days was last updated in 2002. Perl By Example dates from 2007. I haven’t read any of these books, so I can’t comment on their quality, but I’d be really wary of suggesting that someone learns Perl from a book that is so out of date. Before the days of Amazon, these books would quietly disappear from bookshops, but now they always seem to be available.
- Something out of date, but that used to be great. There are plenty of books that I would have recommended when they were current, but that I wouldn’t really want to recommend now. A lot of these are O’Reilly books that haven’t been updated recently – Advanced Perl Programming and The Perl Cookbook, for example. I’m sure there’s lots of good stuff in those books. But I really wouldn’t want anyone to read them if they didn’t already have enough experience to update the Perl to current best practices. I sometimes recommend these books myself, but only in specific circumstances. Whenever I run a course on OO Perl I mention Damian’s book. But I also point out that there have been a lot of advances in the area since the book was published. And, I have to confess, my own Data Munging with Perl fits firmly in this category.
- Something of dubious provenance. Most of these discussions will, at some point, attract a link to some dubious web site in Eastern Europe that contains the full text of O’Reilly’s various CD bookshelves. I know that these sites exist and I know that there’s nothing that O’Reilly can do about them, But I’d rather not see them mentioned on a professional site like LinkedIn. And quite apart from the copyright issues, there’s the fact that most of the books on these sites fall firmly into the first category above. They’re all over ten years old.
- Some great tutorial on the internet. I’ve talked about the problems of old and dodgy tutorials before. And things definitely seem to be looking up. We are getting more good tutorials out there. But people still insist on sharing links to the tutorial that they learned from. Even if it’s appalling.
In a recent discussion someone said (and I’m paraphrasing) “just go to Amazon and look for the highest rated books”. I think there are two problems with that:
- The people who are rating beginner’s programming books on Amazon are usually the least qualified people to do that. Sure, they can tell how easy the book was to read and how well they picked up what the author taught them. But they have noway of knowing whether what they learned was accurate or useful.
- Amazon ratings last forever. But, as noted above, the quality of a technical book in fast-moving subject like programming falls over time. Perhaps Amazon ratings on programming books should have a half-life.
Here are some examples of things that you’re going to miss out on by using outdated Perl references.
- say – We all love say, don’t we?
- Lexical filehandles – Storing filehandles in lexical variables is great. I no longer have to worry about bareword filehandles being reused elsewhere in the code.
- Defined or operator – There’s now no excuse for the $val ||= $default bug.
- given/when – Perl has a switch statement. And it’s better than anyone else’s
- Unicode support – Perl’s Unicode support is second to none. Except, if you’re using an old version of Perl in which case it’s a bit rubbish. And if you’re reading about Perl in an old book, then you won’t know about it.
- State variables – Ok, I don’t use those every day. But when I need them, they make my code cleaner.
And then there are all the great CPAN modules that aren’t covered in books that were written before they were released. Would you really want to introduce someone to OO Perl without mentioning Moose?
My rules for recommending books are pretty simple. They should be books that I’ve found useful and they should have been published in the last few years. And given the falling numbers of Perl books that are published each year, that’s now a rather small number of books. Perhaps a dozen or so.
Am I being too harsh? Can beginners get something useful out of older Perl books? How do you decide whether to recommend a book to a colleague?
Ever since MetaCPAN launched I’ve been getting increasingly irritated with people who still use links to search.cpan.org. Isn’t it obvious that MetaCPAN is better? Why do people still insist on sharing links to the older site?
Of course they do it for various reasons. Perhaps they aren’t as in touch with the modern Perl world as I am. Perhaps they are wary about changing to use the new shiny toys because they know that a newer shinier one will be along soon. Perhaps I’m reading a web page from five years ago and they can be forgiven for not linking to a site that didn’t exist at the time.
Eventually I realised that there was no point in getting annoyed. I had a computer. Surely I could do something that would fix this problem.
So I asked on the #metacpan IRC channel. Surely I couldn’t be the first person to have this problem. And someone there introduced me to mcpan.org. There’s no point in clicking on that link. You’ll just end up on MetaCPAN. Because that’s what mcpan does. It’s a URL rewriting service. You give it a CPAN URL (with the cpan.org changed to mcpan.org) and it redirects you to the equivalent page on MetaCPAN.
That’s the hard bit of the problem. The bit I didn’t want to write. And someone else has already written it. But they seem to have kept it very quiet. This deserves more publicity. I wish I could remember who wrote it. If you know, please leave a comment.
So we’re now most of the way there. Now if I click on a CPAN link, I can just edit the location bar to add an ‘m’ and I’ll be redirected to the right place. But we can do better than that. I’d like to be automatically redirected. That’s when I discovered the Redirector extension for Firefox. Once it’s installed you can configure it to redirect certain URLs to other ones. I have it configured so that http://search.cpan.org* redirects to http://mcpan.org$1. See how you can use wildcards to match URLs and then use whatever they matched in the replacement URL. It’s a lot like regexes in Perl.
And we’re done. Now whenever I click on an old-style CPAN link, I’m automatically redirected to mcpan, And that, in turn, redirects me to MetaCPAN. And, best of all, I didn’t have to write any code. It was just a case of putting together tools that already existed.
But having alternative solutions to the problem is good, right?
Update: I’ve just been talking about this on the #metacpan IRC channel and it seems that I was rather misunderstanding what was going on here. Here are the details.
Firstly, it was dpetrov who told me about mcpan.org. It’s his domain. I asked him for the code, and he pointed out that there is no code. mcpan.org just redirects everything to a domain called sco.metacpan.org which is where the magic happens. He just got tired of editing search.cpan.org to sco.metacpan.org so he registered another, simpler, domain.
So the actual cleverness happens over on sco.metacpan.org. And that’s really just a list of rewrite rules (the code is on github). I say “just”, but I still wouldn’t want to write them myself.
All this means that mcpan,org is only a convenient tool for when you’re manually editing your location bar. When you’re using the Redirector extension for Firefox you can miss out the middle man and redirect straight to sco.metacpan.org. So I’ve updated my Redirector rule appropriately.
It’s a new year, so it’s probably a good time to remind you about some training sessions that I have coming up.
- Perl School 4 is on 9th February. The subject this time is Database Programming with Perl and DBIx::Class. As always, a full day of training costs just £30 and the class will be held at Google Campus in London.
- For the last few years I’ve always run a series of public training courses in conjunction with flossUK (formerly UKUUG) and O’Reilly. This year we’re running two two-courses at the Ambassadors Hotel in Central London. There’s a two-day Intermediate Perl course on 12/13 February and an Advanced Perl course on 14/15 February. You can book for these courses on the flossUK web site.
- The London courses have been going so well that flossUK and O’Reilly have asked me to try running some courses elsewhere in the country. The first location is Manchester where I’ll be running a two-day Advanced Perl course on 17/18 April. Once again, you can book for the course on the flossUK web site.
I hope to see some of you at one or more of these courses.
Yesterday was the third Perl School. Twenty-one students converged on Google Campus in London and spend a day learning about Moose.
The day seemed to go well. People asked intelligent questions and seemed to understand what I was telling them. Hopefully the feedback forms will tell a similar story.
No more training now for a couple of months. But once Christmas is over, I’ll need to start thinking about Perl School 4 – which will be about DBIx::Class. Hope to see some of you there.
This is a reprint of an old blog post.
A few years ago I was writing blog posts (semi-)regularly for O’Reilly. This is the one that probably got the most feedback. I’m reprinting it now because a) it’s pretty hard to find on the O’Reilly site and b) it’s relevant to a couple of conversations that I’ve had over the last few days.
Last week I was in Copenhagen for YAPC::Europe. One of the announcements at the conference was the location of next year’s conference which will be in Lisbon. The theme of next year’s conference will be “Corporate Perl”. And that (along with a couple of conversations last night) got me thinking about a talk that I’ll submit to next year’s conference which might well be entitled “Why Corporates Hate Perl”.
It’s not true, of course. There are a still large number of large companies who love Perl. I could probably work through to my retirement enhancing and extending systems that are written in Perl at many of the big banks in the City of London. There are, however, also many companies who are moving away from Perl for a number of reasons. Here’s one of the reasons that will be included in my talk.
I was talking to people from one such company last night. The Powers That Be at this company have announced that Perl is no longer their language of choice for web systems and that over time (probably a lot of time) systems will be rewritten in a combination of Java and PHP. Management have started to refer to Perl-based systems as “legacy” and to generally disparage it. This attitude has seeped through to non-technical business users who have started to worry if developers mention a system that is written in Perl. Business users, of course, don’t want nasty old, broken Perl code. They want the shiny new technologies.
And so, in a matter of months, the technical managers at this company have created a business environment where Perl is seen as the cause of most of the problems with the current systems. It’s an impressive piece of social engineering.
It’s also, of course, completely unfair. I don’t deny at all that this company (like many others) has a large amount of badly written and hard to maintain Perl code. But I maintain that this isn’t directly due to the code being written in Perl. It’s because the Perl code has developed piecemeal over the last ten or so years in an environment where there was no design authority which encouraged developers to think beyond getting their immediate task done. Many of these systems date back to this company’s first steps onto the internet and were made by separate departments who had no interaction with each other. It’s not really a surprise that the systems don’t interact well and a lot of the code is hard to maintain.
There are, on the other hand, a number of newer systems which are also written in Perl which follow current best practices in Perl development and are far easier to to maintain and enhance – as easy, I would contend, as anything written in the new approved languages.
It’s certainly true that this company has a large number of systems that need to be rewritten over the next few years. But throwing away all of the company’s accumulated Perl expertise and moving to new languages seems to be a step too far. Management are blaming Perl for the problems when really they should be blaming the management and design procedures that were in place (or, more likely, weren’t in place) when the code was originally written.
Many organisations are in the same situation, with large amounts of unwieldy Perl code. Ten or twelve years ago everyone was writing web systems in Perl and we were all making mistakes. We all have to deal with those mistakes but we’ve hopefully, learned from them and can rewrite our systems to take account of everything that we’ve learned in the last ten years.
It’s too late for the company I’ve been talking about in this article. The anti-Perl social engineering has probably insinuated itself too deeply into the culture. It’s unlikely that Perl’s reputation can be rescued.
But if you have similar problems in your own company, then please try to ensure that blame is apportioned correctly and that you don’t use Perl as a scapegoat.
A couple of updates to the post. I did propose the talk to the next YAPC, but the proposal wasn’t accepted. And the company I talk about in the article is still employing a lot of Perl programmers – four years after this post was written.
I gave three talks at the London Perl Workshop yesterday. That wasn’t the original plan, but I kept coming up with talks that seemed to be good ideas.
The last one was on 25 Years of Perl was a bit of a failure as I broke the second rule of presenting (always plug in your laptop) and the battery died just as I got to 2012. Which meant that no-one saw my big finish where I pulled out to give an overview of all 25 years and thanked everyone who had ever been involved with Perl.
Thanks (as ever) to all of the organisers, volunteers and speakers at the LPW. The workshop just gets better and better each year.
See you in 2013 – which will be the 10th LPW!
 And also spoke on a panel about the state of the jobs market.
(You wait weeks for a blog post and then two come along practically together. But this is just another short one.)
Currently, the highest number I can see on the schedule is 26. There are just under 300 people registered for the workshop. That means that a lot of people haven’t marked the talks that they are interested in.
Marking the talks that you’re interested is useful for a few reasons. Firstly, there’s a page on the site which will show you your personalised schedule which just includes the talks you’ve said you want to see. You could print it out and bring it with you on Saturday (or have that page open on your tablet).
Secondly, it’s useful for the organisers. They have a rough idea of which talks are going to be well-attended, but they can occasionally misjudge it. If they find out that 150 people want to see a talk that they have put in a tiny classroom then they can take appropriate measures (like moving the talk).
And finally, it’s useful for the speakers to have an idea of how many people are interested in their talk.
It’s not hard to register your interest in a talk. Just log in to the workshop web site and go to the schedule page. Every talk will have a star in the top left corner. Clicking that star will register your interest. You’re not actually registering for the talk. No-one is going to do anything if you change your mind on the day and go to a different talk on that day. It’s just so we can all get an idea of the approximate levels of interest in the various talks.
Why not pop over to the schedule page and mark some talks now?
See you on Saturday.