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?
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 can never remember exactly how Time::Piece works. But that’s ok because I have documentation.
$ perldoc Time::Piece
No documentation found for "Time::Piece".
This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-thread-multi
$ corelist Time::Piece
Time::Piece was first released with perl v5.9.5
$ perl -MTime::Piece -E'say $Time::Piece::VERSION'
Can't locate Time/Piece.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .).
BEGIN failed--compilation aborted.
So Time::Piece has been in the Perl core since 5.9.5. I’m running Perl 5.14.2 but I don’t have Time::Piece installed.
After ten minutes or so of head-scratching it came to me.
$ sudo yum install perl-core
Loaded plugins: langpacks, local, presto, refresh-packagekit
[ stuff snipped ]
---> Package perl-Time-Piece.x86_64 0:1.20.1-212.fc17 will be installed
[ more stuff snipped]
I’m running Fedora. The Fedora packagers have decided that they don’t need to install the whole standard Perl distribution as part of their standard installation. I don’t have a problem with that. I do have a problem with their naming conventions.
The minimal Perl installation that they include by default is in an RPM called “perl”. The full RPM that includes everything that a Perl developer would expect to see is called “perl-core”. Surely it’s obvious that those names are the wrong way round?
Isn’t there some way that the Perl 5 Porters can object to this renaming of Perl?
I know I should be installing my own Perl with perlbrew. But I generally find that the system Perl works for everything that I need. There’s just this one thing that is guaranteed to trip me up every time I work on a new Fedora installation.
This is a public service blog post. Perhaps someone will come across it and be saved a couple of hours of confusion.
I’ve just been involved in a discussion on LinkedIn that I thought deserved a wider audience (I have no idea how well that link works if you’re not a member or or logged in to LinkedIn).
A couple of days ago, someone asked for advice on the best way to include HTML in a Perl program. They got a lot of good advice (basically – don’t do that, use a templating system instead). And then this morning, someone came in and said:
use CGI module, u don’t need to write a single HTML tag..just use CGI Methods…
I did a bit of a double take at that point. I thought we’d all stopped using CGI.pm’s HTML generation methods back in the last millennium. I replied saying that, but this chap was adamant that CGI.pm worked for him. He asked me to explain why I was so against his approach.
This was my reply:
I never said that it didn’t work. I just think that it’s a really limited way to build things and you’d be better off taking a more flexible approach right from the start.
My main objection is the separation of concerns. The logic of your application is separate to the display layer. It’s quite possible that the display of the application will need to change in the future. And that all becomes easier if the HTML is stored separately from code.
This leads to other problems too:
As I hinted at above, CGI.pm only has pretty basic support for HTML. It’s really hard to create a great-looking web application using CGI.pm. In fact, I wouldn’t be surprised if CGI.pm was largely responsible for the terrible web sites that the Perl community has been building for itself for most of the last twenty years.
Even if you’re the only developer on a project (as I often am for my personal projects) there are advantages to separating your work into “front-end task” and “back-end tasks”. I find it really helps me switch my mindset to the appropriate skills if I switch from editing a Perl source file to editing an HTML template.
It makes your Perl code more complicated than it needs to be. Seriously, try moving the HTML out of the code and into a template. See how much simpler your code becomes.
It’s unlikely that your CGI-generated pages will make up all of the web site. There will almost certainly be static pages too. If you use a tool like the Template Toolkit then you can generate static pages from the same set of templates that your CGI programs use. That way it’s easier to maintain a consistent look and feel across all of the pages on the site.
I’m not saying “don’t use CGI.pm” (well, I am a bit – but that’s a different story). The CGI bits of CGI.pm (for example the bits that give you access to the incoming parameters or let you set the outgoing headers) are great. It’s just the HTML generation stuff that I strongly recommend that you don’t use.
I’ve just remembered an article that I wrote in 2001 that might also help. The first half is about cookies, but the second half demonstrates using Templates instead of the HTML generation methods. I hope it shows how much simpler it makes things
Does that help at all?
I think that pretty much sums up my objections. Did I miss anything obvious? Or am I completely wrong and many of you are still using the HTML generation methods in CGI.pm to do this?
The Perl community on LinkedIn is a fascinating place. I should really write a blog post about it.
I wrote an article for Josette called “What is Modern Perl?” In it, I talk about the different things that people might mean when they talk about Modern Perl and why it’s well worth buying a copy of the new edition of the camel book.
After a gap of twelve years, a new edition of Programming Perl (affectionately known as “the Camel book” to its many fans) was published earlier this year. That came as quite a surprise to many people who had given up on seeing a new edition. What has changed in the new edition? Does the book now cover Modern Perl? The answer depends on what you mean by the term “Modern Perl”.
Of course it’s not a complete coincidence that the subject ties in nicely with my forthcoming Modern Perl for Non-Perl Programmers course.
Update: There’s a discussion of the article on Hacker News. It seems to be taking a predictable path.
Six weeks ago I announced that I’d be running a free one-day course called “Modern Perl for Non-Perl Programmers” in August. Places on that course were fully booked in less than a day.
So I’ve decided to run to course again, two months later. It will still be at Google Campus, and the date is Saturday 6th October.
The original course was free, but I can’t afford to do that on a regular basis. I hope you’ll agree that £30 is still a bargain for a day of training.
As last time, most readers of this blog probably aren’t in the target audience for this course, but you might know people who would be interested in the course. Please pass on the link.
You can buy a ticket using at perlschool2.eventbrite.co.uk.
 Programmers of other languages who want to learn Perl.
Back in 2007 the London Perl Mongers ran a free one-day Perl training course at the BBC’s offices in White City. That was five years ago, so for a couple of months I’ve been thinking that it was probably about time that we did another one.
And then suddenly this afternoon a few loose ends came together and all of a sudden it’s been organised.
The course will be on Saturday 4th August at Google Campus in London. It will run from 9am to 5pm. As last time, it will be completely free to attendees.
Last time the course was aimed at intermediate Perl programmers and introduced them to advanced Perl techniques. This time I’m aiming at the opposite of the spectrum. The course is called “Modern Perl for Non-Perl Programmers”. It’s aimed at people who are comfortable programming in languages other than Perl and who are interested in getting up to speed in Perl as quickly as possible.
Obviously most of the readers of this blog won’t be in the target audience for the course, but I’m betting that you all know at least one person who might be interested in the course. So it would be great if you could send the link to the registration page to anyone who you think would find the course useful.
The link is: perltraining.eventbrite.co.uk
Update: All of the places on this course were booked in about 20 hours. In 2007, a similarly sized free course was all booked up in about two days. I guess it’s true that Perl is dying
Those lovely people at O’Reilly have put an advert for the courses in the new issue of Linux Format which hits the shops about now. That’s issue 154 and the advert is on page 54. The advert contains details of a competition where two people can win free places on the two courses – one person on each course.
There are also four runner-up prizes which are copies of the new edition of the Camel book.
All you need to do is… well to find that out you’ll need to buy the magazine. Ok, so entry isn’t 100% free – you’ll need to pay £6.49 for the magazine.