Ovid

So, I've been awfully quiet lately. There are a number of reasons for that, not the least of which is being the proud parent of a delightful little girl. Another reason has been simple: I'm writing a book.

I've signed a contract with Wrox to write a new Beginning Perl book and I'm sad to say that they've already rejected my subtitle. Apparently, "Get a job, hippy" was a wee bit provocative.

In writing up marketing materials for them, I've included a few other points which I suspect may be rejected:

• Development professionals, hobbyists, and alcoholics have abused Perl for over 20 years.
• Unlike other beginning Perl books, this one is new!
• Perl is the official programming language of R'lyeh.

Sadly, while I have lots of fun with this and try to slip in a few things like this into the text, it's hard work always coming up with "fun" things to write. If I had the time, I'd write "Ovid's Pungent Guide to Perl", but rather than have people ask "Why?", I simply confess that I don't have the time and the book won't always have the level of WTF that I like to have in my favorite writing.

The theme of the book, beyond "Beginning Perl", really is "get a job, hippy". It's not "Modern Perl", "Learning Perl", or anything like that. It's focusing on my decade+ level of experience working with Perl in a variety of shops and focusing very, very heavily on making sure that you have the basic skills shops are actually looking for. This means, for example, that while I'll touch on Catalyst, DBIx::Class and other great modules, I'll focus more heavily on ubiquitous tools like DBI, Template Toolkit and other modules which I find to be far more common. The only major exception is a full introductory chapter on Moose as that's rapidly become the de facto standard for Perl.

I'll ignore things like formats, pack, unpack, etc. (though a constant theme of the book is "here's where to look this up in the Perl documentation") because while I see these in Perl code in the wild, I don't see them often enough to warrant them squeezing aside testing, working with the Web, or a variety of other things that you're far more likely to encounter. In short, I want people to understand code in the wild and to look up the obscure bits.

And that brings us to the controversial issue. I mean the really controversial issue. The book is for the developer who wants to learn new skills to increase job opportunities, or the dev who is saddled with maintaining a legacy system. It is not aimed at the sort of people who hang out on P5P or go to conferences with me. More to the point, it's not "modern Perl".

I will be primarily focusing on 5.10.x and 5.8.x releases, with a few forays into 5.12 and above (though they'll largely be covered in a perldelta appendix). The reasoning here is simple: I've never worked with 5.10 or above in a production environment. Ever. Perl survey results, while already a touch out of date, seemed to support my contention that most Perl code in production is 5.10.x or lower. I've also found repeatedly, in interviewing people, keeping abreast of the market or just talking with other devs that everyone agrees on one thing: if you have good basic skills, you can learn the rest on the job. I had never worked with Catalyst before the BBC. They didn't care and this is common. Learn the basic well and employers will (usually) be happy to let you learn about 5.12 on company time.

I think it's entirely possible that by the time this book goes to the printer (in about a year or so), that 5.12.x might be more widely used, but I'm not seeing this now. Personally I'd like to write a 5.16 book. In fairness to the "get a job, hippy" theme, I can't. Fortunately, Wrox has been very supportive of this decision and they've already done a good job of helping me find my way in the "Wrox way" of publishing.

In other news, chromatic has been foolish enough to agree to be the technical editor for this work. I'm very grateful for this. He has far, far more experience than I do. If there are any serious omissions in this book, they'll be his fault (just kidding!) I've also assembled a crack team of reviewers, of which at least two have no Perl experience. They're my fallback in case Perl gurus have blind spots.

My only fear is the amount of time it's going to take away from my wife and daughter but my wife was insistent that I take this opportunity because it was simply too good to pass up. I'm a very lucky man.