How I waste my time while writing

I’ve been keeping track of how I spend my time working on Mastering Perl. Most of that time is tracking down bugs in CPAN modules. For instance, to write two paragraphs about TryCatch for the Detecting and Reporting Errors” chapter, I’ve spent about seven hours trying to figure out why this seemingly trivial example doesn’t work (RT #87128 ):

use v5.10.1;
use TryCatch;

try {
	die "This died"
catch {
	say "Caught [$@]";  # $@ is always blank

As usual, I should have started with the RT queue to see if someone had already reported the bug. I found that it was reportedly as part of RT #49072.

This is not a huge problem. If you are using TryCatch, you probably want the advanced features to catch errors by type or you want to specify your own variable:

use v5.10.1;
use TryCatch;

try {
	die bless {}, 'Local::Foo';
catch (Local::Foo $err) {
	say "Caught Local::Foo [$err]";
catch ($err) {
	say "Caught [$err]";

I first tried this on v5.18 and I had trouble installing it as Package::Stash and Package::Stash::XS seemed to have an unmet circular dependency such that I had to force install one of them to get the dependency-heavy TryCatch to install. Since I wanted to test several versions, I had to handle this five times and wait close to an hour for it to install in all versions on my puny laptop. All of that got me no further than reporting the bug to RT.

When I embark on these explorations, I don’t think I’m setting out for an adventure and an answer always seems right around the corner. The solution is always right around the corner and I want to try one more thing; every thing I try makes it more elusive.

I’ve also starting patching some distributions, then realizing they use Dist::Zilla, which means many things aren’t where they will finally show up and I’d have to install a very heavy tool to do very basic things. I’m really sad that people are cutting off so many people from submitting patches; the casual user who isn’t a module maintainer isn’t going to suffer the installation of tools and learning where to find things just to make a quick patch. It’s a couple times a week that I abandon a patch for this reason. I don’t even bother to send the problem to RT because I figure I’ve already wasted enough time, and if I can’t make the patch, I’m disinclined to bother with a report. If I were going to use the module for work, things might be different, but I’m just writing about them.

Mastering Perl is available for pre-order

Mastering Perl is available on for advance orders. It’s $1 less than the previous edition, too. You can also pre-order it directly from, which gets you access to the in progress digital version of book as an “Early Release”.

I still think it’s roughly four months from actually showing up at your door though; I have a couple of chapters to finish.

Looking for technical reviewers

I’m looking for technical reviewers for Mastering Perl. I’ve updated most of the book now, so the next part of the process is the technical review where people find all my lies and omissions. If you are interested, please send me email and I’ll give you the details. For your troubles, I’ll at least get you a free copy.

Mastering Perl 2e draft in O’Reilly Atlas

O’Reilly Media has been moving to a new publishing platform that’s making things much easier for everyone I think. Mastering Perl, Second Edition is my first experience with this.

Besides moving from Subversion to Git (yay!), my intermediate draft sources are available in real time through O’Reilly Atlas. You can read what I’ve got so far for free, sponsored by OSCON. Mostly what you’ll see there right now is the first edition since I’ve been slow to move over what I was doing in the old process to the new process.

This is your chance to influence what happens in the second edition. The structure and topics mostly stay the same, but everything will be updated.

Pondering the second edition of Mastering Perl

I’m putting together the proposal for Mastering Perl, 2nd Edition. O’Reilly would like it published by next summer.

I wrote the first edition in 2005 and O’Reilly published it in 2006. Now it’s seven years after I wrote the original. What do I need to update? Many of Perl’s new features have already shown up in Learning Perl and Intermediate Perl, but Mastering Perl has never really been about listing Perl features.

Some things I already have on my mind:

  • Beefing up the logging chapter
  • A better example for the Tie chapter, using NOAA’s Hourly Surface data instead of the made up DNA example
  • Adding JSON to the data persistence chapter
  • Various updates to the Advanced Regex chapter
  • __SUB__ examples
  • Some fancier examples for the modulinos chapter
  • Devel::NYTProf in the benchmarking chapter

I don’t know if I need to add any major topics. What do you think?