Recently Dominus posted a lovely horror story from his programming past and I couldn't help but think about my time as a mainframe programmer and the team lead who hated me. She once got upset at another developer for increasing the space allocation for jobs. Why was the other developer increasing that allocation? Because our nightly batch jobs were running out of space and we'd get woken up with calls telling us the jobs were failing and we'd tell them to increase the disk space and restart the job. The team lead was upset because if the operators didn't have to call us, "why would they need us?".

However, I was the person who really upset her and I never quite figured out why. I was told it was because, unlike her, I could actually program (allegedly she was an operator who simply rose through the trenches), but I don't know this for certain. All I know is that she did not like me and one day she managed to exact her revenge against me for whatever I had done to offend her.

While I know I'm in the minority, I use the Perl debugger quite a bit. In fact, I've hacked on perl5db.pl more than I can to admit and it's a mess. However, on a day-to-day basis, I use it constantly and have it bound to ,d in my vim setup. Unfortunately, I also write a lot of Moose code and that's when I invariably hit things like this:

Class::MOP::Method::Wrapped::CODE(0x62b0250)(/usr/local/lib/perl/5.10.1/Class/MOP/Method/Wrapped.pm:91):
91:             sub { $modifier_table->{cache}->(@_) },
auto(-1)  DB<2> v
88          };
89:         $_build_wrapped_method->($modifier_table);
90          return $class->SUPER::wrap(
91==>           sub { $modifier_table->{cache}->(@_) },
92              # get these from the original
93              # unless explicitly overridden
94:             package_name   => $params{package_name} || $code->package_name,
95              name           => $params{name}         || $code->name,
96              original_method => $code,
97

That's not code I've written; that's code that you get when you use Moose and it makes debugging much harder than it needs to be.

Today I decided to do something about that, but I was very pleased to see that Christian Walde already did it for me. Now debugging Moose is a breeze.

Er, an earlier version of this said the software bug was 20 years old. It's 30! Thanks, Sidhekin

Today, in reading some data, I processed 36,916 potential dates. Two of those 36,916 failed to validate. I wasn't terribly concerned as these dates come from client-supplied data and this data is often, um, surprising. However, when I inspected the raw data, it turns out that those dates were January 1^st, 2011 and January 1^st, 2007. I had a bug in software I wrote about a month ago, but it turns out that this bug is actually 30 years old.

For anyone who doesn't really understand the software ecosystem, this may sound mystifying, but it makes sense. Because of a decision taken a long time ago to make another company money, my $client lost money in paying me to fix a bug that one company accidentally introduced and another company deliberately introduced. But to explain it I need to talk about a third company that introduced a feature that eventually became a bug, and a few other historical tidbits that nonetheless contributed to the obscure bug I fixed today.

If there is one thing about testing in Perl which bugs me, it's that most testing in Perl is what cgi-lib.pl is to Plack. The following is mostly a rant and I'm also guilty of many of these sins.

Yes, we have a beautiful testing infrastructure around our tests. For example, if I want to know which operating systems and versions of Perl my Code::CutNPaste module fails on, I just go take a look. Or I can quickly see almost 3,000 passing test reports for aliased (woo hoo!). The Perl community is proud of tools like this and we should be. Just reading about Perl's test-infected culture is fantastic and other language which claim to be test-infected often come in a poor second.

Er, sort of.