DBIC Training in Granada

It’s been a while since I’ve run a training course alongside a YAPC. By my calculations, the last time was Riga in 2011. But I’ve been talking to the organisers of this year’s conference and we have plan.

I’m going to be running a one-day introductory course on DBIx::Class before the conference (I think it’ll be on 1st September, but that’s not 100% certain yet). Full details are on the conference web site. There’s an early-bird price of 150 Euro and the full price is 200 Euro. The web site says that the early-bird price finishes today, but I wouldn’t be at all surprised if that gets extended for a few days at least.

Of course, readers of this blog will all already be experts in DBIC and won’t need this course. But I’m sure that most of you will have a colleague who would benefit from… well… a refresher on who DBIC works. Why not see if your company will pay for them to attend the course :-)

The course size is limited. So you might want to think about booking soon.

Hope to see some of you in Granada.

Two updates:

  1. The date has now been confirmed as 1st September.
  2. The early-bird pricing has been extended until 1st June.
Send to Kindle

Subroutines and Ampersands

I’ve had this discussion several times recently, so I thought it was worth writing a blog post so that I have somewhere to point people the next time it comes up.

Using ampersands on subroutine calls (&my_sub or &my_sub(...)) is never necessary and can have potentially surprising side-effects. It should, therefore, never be used and should particularly be avoided in examples aimed at beginners.

Using an ampersand when calling a subroutine has three effects.

  1. It disambiguates the code so the the Perl compiler knows for sure that it has come across a subroutine call.
  2. It turns off prototype checking.
  3. If you use the &my_sub form (i.e. without parentheses) then the current value of @_ is passed on to the called subroutine.

Let’s look at these three effects in a little more detail.

Disambiguating the code is obviously a good idea. But adding the ampersand is not the only way to do it. Adding a pair of parentheses to the end of the call (my_sub()) has exactly the same effect. And, as a bonus, it looks the same as subroutine calls do in pretty much every other programming language ever invented. I can’t think of a single reason why anyone would pick &my_sub over my_sub().

I hope we’re agreed that prototypes are unnecessary in most Perl code (perhaps that needs to be another blog post at some point). Of course there are a few good reasons to use them, but most of us won’t be using them most of the time. If you’re using them, then turning off prototype checking seems to be a bad idea. And if you’re not using them, then it doesn’t matter whether they’re checked or not. There’s no good argument here for  using ampersands.

Then we come to the invisible passing of @_ to the called subroutine. I have no idea why anyone ever thought this was a good idea. The perlsub documentation calls it “an efficiency mechanism” but admits that is it one “that new users may wish to avoid”. If you want @_ to be available to the called subroutine then just pass it in explicitly. Your maintenance programmer (and remember, that could be you in six months time) will be grateful and won’t waste hours trying to work out what is going on.

So, no, there is no good reason to use ampersands when calling subroutines. Please don’t use them.

There is, of course, one case where ampersands are still useful when dealing with subroutines – when you are taking a reference to an existing, named subroutine. But that’s the only case that I can think of.

What do you think? Have I missed something?

It’s unfortunate that a lot of the older documentation on CPAN (and, indeed, some popular beginners’ books) still perpetuate this outdated style. It would be great if we could remove it from all example code.

Send to Kindle

Modern Perl Articles

Back in 2011 I wrote a series of three articles about “Modern Perl” for Linux Format. Although I mentioned all three articles here as they were published, I didn’t post the actual contents of the articles as I wasn’t sure about the copyright situation.

But now I suspect that enough time has passed that copyright is no longer going to be an issue, so I’ve added the full text of the articles to this site. The articles are all about writing a simple web application to track your reading. They use DBIx::Class and Dancer.

Let me know if you find them interesting or useful.

Send to Kindle

Penetration Testing with Perl

I was sent a review copy of Penetration Testing with Perl by Douglas Berdeaux. I really didn’t like it. Here’s the review I’ve been sharing on Amazon and Goodreads.

I’ve been wanting to learn a bit about Penetration Testing for a while and as Perl is my programming language of choice this seemed like a great book to choose. Unfortunately, it wasn’t.

I have no doubt that the author knows what he is talking about when it comes to Penetration Testing, but there were several things that prevented this book from transferring much of that knowledge to me.

Firstly, the typesetting in the book is terrible. I was reading the Amazon eBook edition – it’s possible that the printed version is better. For example, there’s a lot of code in this book and it’s in a proportional font. In order for code to be readable, it needs to be in a fixed-width font. Also, there are two or three places where an equation appears in the text, but it appears in an unreadably small font. I have just checked in the PDF version of the book and neither of these problems appear there. It would seem that this is down to a problem in Packt’s eBook creation process.

Secondly, it’s obvious that English is not the author’s first language. At times this really prevents him from getting his point across clearly. I’m very happy to see non-native speakers publishing books in English. But the publishers need to provide high quality proof-readers to ensure that the language is good enough.

Thirdly, the organisation of the book is a little haphazard. The first couple of chapters are introductions to Perl and Linux, but after that we are dropped immediately into a discussion of network sniffing. Later in the book there are chapters on intelligence gathering, social engineering and password cracking. These are all far simpler topics which could have served as a gentle introduction to the book, getting people up to speed on Perl before delving into the complex internals of network packets. Once again, I think this should be the responsibility of the publisher. There should be a good editor working on the book alongside the author and shaping the manuscript so that the story it tells guides the user through the subject as easily as possible.

Finally, the book falls short in its technical content. I can’t comment on the author’s explanations of Penetration Testing (I was, after all, reading the book to learn about that topic), but the Perl code that he uses throughout the book is really bad. He is obviously someone who only ever learned enough Perl to get his job done and never bothered to learn how Perl really works or to keep his knowledge up to date. As a result, the book is full of the kind of code that gives Perl its reputation as a write-only language. The idioms that he uses are often out of date (using ‘-w’ instead of ‘use warnings’, for example), confusing (predeclaring subroutines unnecessarily, using ampersands on function calls) or just plain wrong (‘my ($x, $y, $z) = 0 x 3’ just doesn’t do what he thinks it does). Actually, it’s worse than that. It’s not just Perl he doesn’t understand, it’s the fundamentals of good software engineering. His code is a confusing mess of global variables and bad design. This is another failure by the publisher. There should have been a competent technical editor checking this stuff.

I’ve read four or five Packt books now. They’re all of this standard. None of them should have been published. But Packt seem to have hit on a good business model. They find unknown authors and produce books as cheaply as possible. Their publishing process omits all of the editing and checking that more reputable publishers use. The books that come out of this process are, of course, terrible. But, for reasons I can’t understand, people still buy them.

Packt books – just say no.

Send to Kindle

London Perl Jobs Mailing List

London.pm is undergoing one of its periodic reorganisations. We’re in the process of moving our web site over to a new server and as part of that move, we’ve decided that we’ll move our mailing list infrastructure to a third party system. Both the main discussion list and the announcements list will be run on Sympa.

But that’s not all the lists we currently have. In particular, we had a London Perl Jobs list, which anyone could use to post details of Perl jobs in London. It’s been decided that this list is too much hassle to keep up. Apparently, it needs a pretty high level of work from moderators. So that list isn’t going to be migrated and it will quietly die.

I thought that was a bit of a shame. I think it’s a useful list. And, in particular, I think it would be easy for outsiders to misread the reasons for the closure – given the current discussions about the death of Perl. Perhaps the list was killed off because there are no longer any Perl jobs in London (you and I both know that’s not true, but not everyone is following the situation as closely as we are).

So I decided to do something about it. I just happened to have a useful-looking domain sitting around not doing very much, so I’ve set up a jobs mailing list over there. Feel free to subscribe if you’re interested in Perl jobs in London. And, more importantly, please encourage people who are looking for Perl programmers in London to post their jobs to jobs@londonperl.co.uk.

Currently, the list is configured like this:

  • Archives are public
  • By default, replies go to the poster rather than the list
  • Posts are accepted from anyone
  • All posts are moderated

I’ll be happy to reconsider any of those settings once the list has been running for a while. I’m also considering setting up an associated jobs discussion list, if people think that would be useful.

See you on the mailing list.

Send to Kindle

Slideshare Stats

For many years (since the end of 2007, apparently) I’ve been uploading the slides from my talks and training courses to Slideshare.

This morning I got an email from them, telling me that they had made their analytics pages freely available. I don’t know if this is a permanent change or a special offer, but the link (which will only work for logged in users) is http://www.slideshare.net/insight.

There’s a lot of information there and I look forward into digging into it in a lot more detail. But I thought it would be interesting to share the list of my top ten most popular slide decks.

Title Views
Introduction to Perl – Day 1 71722
LPW: Beginners Perl 50935
Modern Web Development with Perl 33034
Modern Perl for Non-Perl Programmers 27376
Matt’s PSGI Archive 24341
Introduction to Web Programming with Perl 22544
Introduction to Perl – Day 2 20489
Introduction to Modern Perl 17709
Introducing Modern Perl 13871
Modern Core Perl 11337

A lot of those course are aimed at people who are starting Perl from scratch. I guess it’s true that there are plenty of people out there who still want to learn Perl.

Send to Kindle

Dev Assistant

A couple of days ago, I updated to my laptop to Fedora 21. One of the new features was an application called DevAssistant which claimed that:

It does not matter if you only recently discovered the world of software development, or if you have been coding for two decades, there’s always something DevAssistant can do to make your life easier.

I thought it was worth investigating – particularly when I saw that it had support for Perl.

Starting the GUI and pressing the Perl button gives me two options: “Basic Class” and “Dancer”. I chose the “Basic Class” option. That gave me an dialogue box where I could give my new project a name. I chose “MyClass” (it’s only an example!) This created a directory called MyClass in my home directory and put two files in that directory. Here are the contents of those two files.



It’s great, of course, that the project wants to support Perl. I think that we should do everything we can to help them. But it’s clear to me that they don’t have anyone on the team who knows anything about modern Perl practices.

So who wants to volunteer to help them?

Update: So it turns out that the dev team are really responsive to pull requests :-)

Send to Kindle

Perl Recruitment Thoughts

Not many weeks go by when I don’t hear of another Perl-using company that has been evaluating alternative technologies. In most cases, it’s not because they think that Perl is a bad language to use. The most common reason I hear is that it is becoming harder and harder to find good Perl programmers.

On Quora I recently saw a question asking what job opportunities were like for Perl programmers. This is how I answered:

Right now is a good time to be a Perl programmer. Perl is losing mindshare. Very few new Perl programmers are arriving on the scene and quite a lot of former Perl programmers have moved away from the language to what they see as more lucrative, enjoyable or saleable languages.

But there are still a lot of companies with a lot of Perl code. That all needs to be maintained and enhanced. And many of those companies continue to write new projects in Perl too.

All of which means that it’s a seller’s market for good Perl skills. That won’t last forever, of course. To be honest, I’d be surprised if it lasts for more than five or ten years (well, unless Perl 6 takes off quickly). But it’ll do me for the next few years at least.

I’m putting a positive spin on it, but it’s getting to be a real problem. More programmers abandon Perl, that makes it harder to find good Perl programmers, which makes it more likely that companies will abandon Perl, which leads to fewer Perl jobs and more programmers decide to abandon Perl. It’s a vicious circle.

I’m not sure how we get to the root of that problem, but do have some suggestions for on particular area. A client recently asked my for suggestions on how they can improve their hit rate for recruiting good Perl programmers. My suggestions all revolved about making your company better known in the Perl community (because that’s where many of the better Perl programmers are).

I know that many of the Perl-using companies already know this. But in the interests of levelling the playing field, I thought was worth sharing some of my suggestions.

Perl Mongers Social Meetings

Do you have a local Perl Mongers group? If so, they almost certainly have monthly social meetings. And in many cases they will welcome a company that puts a few quid behind the bar for drinks at one of those meetings. For smaller groups (and there are many smaller groups) you might even offer to buy them dinner.

It’s worth contacting them before doing this. Just turning up and flashing your money around might be seen as rude. And some groups might object to this kind of commercialisation. But it’s always worth asking.

Perl Mongers Technical Meeting

Some Perl Mongers groups have technical meetings (either instead of or as well as social meetings). In this case, instead of meeting in a pub (or bar or restaurant), they’ll meet in the offices of a friendly local company and some of the members will give presentations to the group. Many groups struggle to find venues for these kinds of meetings. Why not offer your office? And perhaps throw in some pizza and beer.

Perl Workshop

The next step up from technical meetings is Perl workshops. Many Perl Mongers groups organise annual one-day workshops. There can be many talks taking place across a number of tracks over the course of (usually) a day. The organisers often like to make these events free (mainly, it seems, because charging for stuff like this adds a whole new layer of complexity). But it’s not free to put on these events so they rely heavily on sponsors. Can you help pay for the venue? Or the printing? Or the catering? Different events will have different opportunities available. Contact the organisers.


Workshops are national and (usually) one-day events. YAPC are international conferences that span many days. They have all the same requirements, but bigger. So they need more money. And, of course, sponsors can be at the conference telling potential employees just how wonderful it is to work for them.

The Perl Foundation

The Perl Foundation are the organisation that promotes Perl, holds various Perl trademarks and hosts many Perl web sites. They issue grants for people to work on various Perl-related projects. They never have enough money. They love companies who donate money to them as thanks for the benefit that Perl brings. How much you donate is up to you, but as a guide, most announcements seem to be in the $10,000 range.

In each of these cases, the idea is really to show the Perl community how much you value Perl by helping various Perl organisations to organise events that raise people’s awareness of Perl. Everyone wins. The sponsors get seen as good people to work for and the events themselves demonstrate that modern Perl is still a great language.

So the next time someone in your company asks how they can find good Perl people, consider a different approach. Can you embed your company in the conciousness of the Perl community and make yourselves look more attractive to some of the best Perl programmers in the world?

Send to Kindle

LPW & Perl Web Book

Last Saturday was the London Perl Workshop. As always, it was a great day with a fabulous selection of talks. As always, I’m desperately waiting for the videos to appear so that I can see the talks that I was forced to miss because of clashes.

I spoke a couple of times. In the morning I ran a two-hour training course entitled “Perl in the Internet of Things”. The slides are up on Slideshare.

And, towards the end of the day I gave a lightning talk called “Return to the Kingdom of the Blind. It was a sequel to the similarly-named lightning talk I gave a couple of times last year. This year I particularly concentrated on the fact that so many people seem to cling to the idea of using CGI to write web applications when there are so many better technologies available.

I decided that part of the problem is that there are no modern Perl web development books and people are still picking up books that are fifteen years old. At the end of the talk I announced that I was planning to put that right and that I was planning to write a new book on Perl web development that would be available in time for the next London Perl Workshop.

The project has a web site, a Github repo and a Twitter feed. I hope that things will start to happen over the next couple of weeks.

Wish me luck.

Send to Kindle

Upcoming Training

I have a few training courses coming up in the next few weeks which I thought you might be interested in.

Firstly, the London Perl Workshop is on 8th November. I’ll be giving a two hour talk on “Perl in the Internet of Things“. As always, the workshop is free, but please register on the site and star my talk if you’re planning on attending.

Then the week after I’m running two two-day courses in conjunction with FLOSS UK. On Tuesday 11th and Wednesday 12th it’s “Intermediate Perl” and on Thursday 13th and Friday 14th it’s “Advanced Perl Techniques”. Full details and a booking for are on the FLOSS UK web site.

Note: If you’re interested in the FLOSS UK courses, then please don’t pay the eye-watering non-member price (£720!) Simply join FLOSS UK (which costs £42) and then pay the member price of £399.

Hope to see you at one of this courses.

Send to Kindle