I’ve been doing a lot of work on Test::Class::Moose recently and I’ve released a trial distro with my changes.

The highlights in this release are:

  • Support for parameterized test classes – instantiate a class more than once with different parameters
  • Separated the test runner from Test::Class::Moose itself – there is now a new Test::Class::Moose::Runner class so your test classes themselves are not also runners
  • Integrated the parallel runner code into this new runner so you can just pass jobs => 2 to the Runner class and get parallel testing

These changes are (obviously) backwards incompatible so Ovid and I would love to get your feedback on these changes before enshrining them in a stable release. Please comment in the form of RT issues or GitHub pull requests.

The sign up for classes at this year’s YAPC is a little different than before. You sign up by pledging to a crowdfunding campaign on Crowdtilt. If enough people pledge then the class will happen (and you will be charged). So if you’re interested in taking my Introduction to Moose class, please sign up now!

This class is a one day, interactive introduction to Moose. The class will take place on Sunday, June 22, the day before the conference proper begins. The cost of the class is a mere $130 for a full day!

Here’s what one past student said about the class:

Great class. I especially liked your problem sets. You gave out problems you expected your class to actually solve, and you allowed class time for solving them. This should be a basic expectation for any class, but it’s amazing how often teachers don’t do this.

You can find more details about the class content on the class’s crowdtilt page.

I’ve been in Taiwan for about four weeks now. Most of the time I was working remotely (more remotely than usual), but for the last few days I’ve been on a real vacation in Taipei. I’ve had time to kill while my wife talks to her relatives (my Mandarin is not good enough for extended conversations) so I’ve been trying to work through my all too large rt.cpan and GH PR backlogs.

The past year or two I haven’t had as much time or energy for my free software projects as in the past. Part of this is that my current job at MaxMind is generally engaging and interesting. I actually get to work on some neat projects there, including the recently released Stepford. Between work, family health issues, and the time I spend planning events like Twin Cities Veg Fest, I haven’t had much time for FS/OSS work.

But I realized that if I could just allocate a few hours per month I could probably get a lot done, at least in terms of addressing small bugs and patches for my CPAN modules. To that end, I’ve added a new recurring 3 hour block to my calendar every other Sunday labelled “Free Software Sunday”. I’ve given myself permission to ignore that event when it pops up, but it will still be a good reminder.

My apologies to all of you who’ve submitted bug reports and patches in the past and haven’t received a response. If there’s something in particular you want me to look at, please comment on the rt.cpan ticket or GH PR again to remind me.

For many years now I’ve flirted with the idea of finally learning C programming. I’d make attempts which usually consisted of re-reading the Kernighan and Ritchie book The C Programming Language, trying to hack on some C code, and then giving up in frustration. I really have no idea why that book is so widely lauded. It teaches the basic syntax of C, but does almost nothing to teach you the core concepts. It basically assumes that you understand the underlying memory model of the system and how C exposes it. That may have been fine in 1978 but for anyone who’s coming to C from something like Perl or Java, as opposed to assembly, it’s wildly unhelpful.

For years I’d wanted to find a book that would clearly explain pointers and memory management, but nothing seemed to exist. Recently at my day job I was trying to refactor some bits of a C library we created for reading a binary data format (that we also created). As usual, I struggled with my poor C knowledge. I have a free Safari subscription from days as an O’Reilly author so I figured I’d take a look at the C books.

I saw Understanding and Using C Pointers and hoped against hope that this was the book I’d been waiting ten years or so for. It was. This is a book length examination of C pointers, arrays, memory management, structs, and all that stuff that the K&R book glosses over in a few pages. It even has pretty pictures that help make sense of pointers and their relationship to arrays, the stack, the heap, and so on.

I truly and deeply ♥ this book. If you’ve had the same struggles I’ve had with this aspect of C, I can’t recommend it strongly enough.

After reading it, I can actually debug a segfault with knowledge as opposed to my previous strategy of flailing at it until it goes away. That’s the most powerful endorsement I can think of.

Michael Schwern has withdrawn as a speaker from YAPC::NA 2013 because he does not believe that the conference organizers will enforce the conference’s published Code of Conduct. This is based in part on a discussion (fight? spat? brawl?) that happened on the irc.perl.org #yapc IRC channel recently. The transcript of said discussion is probably worth reading before going further. Don’t worry, I’ll wait.

Okay, now that you read that particular piece of unpleasantness, I’ll offer my take on this mess. People have asked me about this because I’ve been a vocal advocate of having a Code of Conduct. I still stand by my earlier position that I will not attend a conference without one.

So what’s going on here? My reading of the IRC transcript is that everyone involved acted pretty badly. Capnleela’s tone was completely unhelpful. Giving summary orders to volunteers is just going to piss people off, and lo and behold, it sure did. How about opening with something like this …

Hey, toddr, I’m really concerned about having game night near this Bikini Sports Bar. That place seems really creepy and inappropriate for a YAPC. Is the venue you’re looking at part of the same building? Will people coming to game night have to see a big sign for Austin’s “breastaurant”?

Apeiron missed a great opportunity to take the higher ground and try to defuse a situation. Instead, he responded to obnioxiousness with more obnoxiousness. This is made worse by the fact that he’s an IRC op, so he has a position of power. With great power … blah blah blah. How about something like this …

Hi, capnleela, I understand you’re upset, and I get that this is a tense issue. However, I feel like you’re giving orders rather than asking for a discussion, and that’s a bit off-putting. Maybe you could rephrase things differently and just state your concerns first?

Kyriel should have been kicked from the channel pretty much immediately. She was trolling and doing everything in her power to make a tense situation worse. I have no alternate wording for kyriel.

That all said, capnleela’s concern about the game night venue was legitimate, but apparently misplaced, since from what I can tell, the issue had already been resolved by the time this IRC fight broke out.

But does any of this rise to the level of a CoC-violating offense? Maybe, maybe not. Not all arguments, even heated ones, are CoC violations. Should the CoC be enforced on the #yapc channel a few weeks before the conference? Well, I wish everyone on IRC would be nicer all the time, and IRC is often a cesspool of nastiness, but the #yapc channel is not really an official part of the conference, and it’s not controlled by the YAPC::NA admins. What about TPF’s role in this? They don’t run the channel either, so I don’t see what they can do.

Will the CoC be enforced this year? Here’s an IRC exchange I had with Todd Rinaldo, one of this year’s YAPC::NA organizers, on the topic:

I’m satisfied that the conference organizers take the CoC seriously and intend to enforce it at the conference.

Personally, I think the community has made good progress over the past two years towards adopting and living up to higher standards of behavior. The past three YAPCs have had clear, well-written Codes of Conduct. I also see people stepping up and moderating flame wars on the IRC channels more often. I submitted a patch to the YAPC Code of Conduct repo for next year’s YAPC to add a report handling procedure for YAPC staff which I hope to see published along with the CoC next year.

I still think we can do better, but social change requires incremental progress, and we’ll never satisfy everyone, me included.

MaxMind, Inc., the company I work for, is hiring a Senior QA Engineer. This position is a development position, but your job will focus on writing tests, especially on automating functional testing, helping us build test tools, and working with support and customers to understand and document bugs. You won’t really be developing end products, nor do we expect you to spend a lot of time doing manual testing except when that’s necessary for reproducing bugs or building a test suite.

We’d really like to find someone with a strong interest and background in QA, not just a developer looking for any development job. We have a growing body of unit tests, but there are still many aspects of our products that need better testing and would benefit from functional tests that focus on how users interact with our products.

Perl experience would be helpful since our system is written in Perl, and we expect new tools to be written in Perl unless there’s an existing tool in another language that does the job.

Gabor Szabo of Perl Maven recently interviewed me about my work in Perl and other random things. In retrospect, I clearly should have sat up and found some smaller headphones. I look like a very, very lazy nerd. Well, I guess that’s not so far off the mark.

Gabor is doing a series of interviews with folks offering Master Classes at YAPC::NA 2013. I’ll be offering my Intro to Moose class again this year, and it’s not too late to sign up. The class will be on the Thursday after YAPC, June 6.

This class introduces you to all the basic Moose features and gets you to write some real code using those features. The class alternates lectures with hands-on coding. The way the coding works is that I’ve written some tests, and you need to write modules with Moose that make those tests pass. This gives you very immediate feedback, as you can run the test suite at any time to see what is passing so far.

I’ve given this class a number of times and it’s consistently gotten great reviews from students. Here’s Chris Fedde’s feedback:

I thought Dave’s class was outstanding. Well prepared and highly valuable content. This course was one of the best organized I’ve had the opportunity to take.

There’s still time to sign up for this class before YAPC. It’s a steal at just $125. Typically a course like this would run much more than that, but for YAPC we trainers all reduce our prices.

Also, check out Stevan Little’s Advanced Moose class on Friday, June 7. Our two classes go quite well together. Stevan will take you further in depth with various Moose features, and also cover best practices for various Moose features. This is the first YAPC where both of these classes have been available.

The recent discussion that started with Ovid’s Perl 7 blog post has me thinking about the future of Perl, and Perl 5 in particular. We hear that Perl is dying on a regular basis, and while I take that with a grain of salt, the fact that so many non-Perl people seem to believe this is worrisome. If Perl is to have a future, it will need to attract new users.

Perl 5, as it stands, has a lot of problems. One of them is that people outside the community don’t want to learn a language that’s soon going to be replaced by Perl 6. While Larry has said repeatedly that Perl 5 and 6 are two different languages in the same family, and that Perl 6 is not intended to replace Perl 5, very few people outside the echo chamber have heard this message.

Another problem is that Perl 5 has a lot of baggage. It drags that baggage around in the name of backwards compatibility. Perl 5’s dogged commitment to backwards compatibility is, on the whole, a good thing. However, when combined with Larry’s proclamation that there will never be a successor to Perl 5, we have a truly serious issue.

If it’s true that Perl 5 and 6 are really two separate languages, then we need to be able to evolve Perl 5 and 6 separately. But how can Perl 5 evolve when there’s no way to develop a successor to Perl 5? Perl 6 is not the successor, it’s just a sibling.

Perl 5 is stuck with an increasingly crufty core implementation tied to an increasingly crufty set of no-longer-correct decisions. Some of those decisions include smartmatch, half-assed overloading, no strict by default, indirect method call syntax, -> instead of . for method calls, half-assed exceptions, and many more.

It’s unlikely that there will ever be a Perl 5 release which fixes all of these problems, because there’s no way to fix them without breaking back-compat. Without the option of bumping the major version number, how can we signal that any new version is substantially different than the last release?

Realistically, the only way to evolve Perl 5 is going to be to create a new core that implements a Perl 5-like language. Stevan Little’s Moe is one stab at a possible successor, though don’t get too excited, for now it’s just an experiment.

The future of Perl 5 is, sadly, not going to be called Perl. So if you’re interested in seeing a future for Perl 5, the discussion about Perl 7 (and 6) is a distraction. Instead, figure out how to create a new Perl 5-like language. Maybe you can contribute to Moe. Maybe you can start your own Perl5++ prototype project. But you can’t convince p5p to call perl 5.20 Perl 7, and you can’t rename Perl 6.

I’m sad that it’s come to this. Perl 6 should have been renamed years ago to preserve the health of the Perl 5 community. I’ve seen many people say that this is solely Larry’s decision, but that’s just wrong. A lot of people have invested a lot of time and effort in Perl 5, and those people count too. I don’t think their interests have been taken into account.

Of course, I look forward to being proved entirely wrong when a production-ready Perl 6 is released this Christmas and the entire Perl community moves as one to embrace it.

I’m creating a new account at Simple.com and it’s time for me to choose a password. I’m quite impressed with their password strength checker.

First of all, the get big points for recommending a pass-phrase, not a pass-word. In their words:

Passphrase? Yes. Passphrases are easier to remember and more secure than traditional passwords. For example, try a group of words with spaces in between, or a sentence you know you’ll remember. Correct horse battery staple is a better passphrase than r0b0tz26.

Damn straight! I’m so sick of idiotic websites requiring me to use a capital letter and a number but disallowing spaces. So now I have a not terribly secure password I can never remember. Of course, I just let Chrome remember all my passwords anyway, but still, it’s lame.

I also greatly appreciated the XKCD reference. For bonus points, their Javascript for password strength explicitly disallows correct horse battery staple and r0b0tz26. I haven’t analyzed their entire strength determination algorithm but it seems to be pretty good, as phrases of many short words rank lower than phrases with fewer, longer words.

They also have some sort of blacklist. The phrase “yo dawg, i heard you like passphrases” gets a very low score. The blacklist could be a bit better as “to be or not to be” gets a “B”.

But overall, I’m impressed. It’s incredibly rare to see a site recommend a passphrase at all, much less really help guide you to something both secure and memorable.

Great job, Simple!