Last night was the first session of my otherwise long-running tabletop RPG game in over a year. Our old venue had become unavailable, last year, then other complications came up, and finally when things seemed like we could get things moving, there was just a lot of inertia to overcome. Finally, I sent out a grumpy, “Should we just call things off forever, or what?” Fortunately, I got quick responses from everyone: no, the previously mentioned date is good. Unfortunately, the date was in just a few days, and I only had the next session planned in broad strokes.

In 2005 or so, I started running a science fiction role-playing game, and it ran for a little under five years. I had a lot of fun, and I think the game had some merit, but I got frustrated with a lot of its failures and wrote a post mortem in which I put most of the blame on myself for a lot of problems that I brought down on my own. Below, I reproduce most of my report to the players:

Yesterday, I tweeted this:

My first ebook reader was a Sony PRS-300, which I bought just about a year ago. There was a lot to like about it, and I never felt particularly tempted to replace it with a Kindle. It really all comes down to one thing: the size. If you compare the Kindle and the Sony Reader sizes, you can see just how much bigger the Kindle 3 is than the PRS-300. The Sony reader fit much better in my pockets, so I could take it anywhere. I’d take it on walks to 7-11, to the playground with Martha, on short car trips, or anything. The Kindle is just a little too big for that to be as comfortable.

In my last entry, I wrote about how role composition and advice and BUILD interact. A number of times, I’ve wanted to get behavior that was like BUILD, but without needing the stub method hacks that are needed to get roles to participate in the method call. A very simple example came when I was writing Throwable::X, which had a mechanism for all of its contituent parts to contribute tags. The idea was that any class or role that was part of your class hierarchy could implement an x_tags method that would return a list of tag strings. These methods would all get called and the resulting set of tags would be uniqued and returned.

A very common complaint on #moose is, “BUILD is broken. I put BUILD methods in my code and they never got called.” There are a lot of variations on this. They tend to come from the fact that BUILD is not called like almost any other method. Imagine the following class hierarchy:

Right now, the most popular Perl library for testing code that throws exceptions is probably Test::Exception. It works like this:

I was happy to learn about this bizarre flag in Perl, even though it took a lot of aggravation to learn it.

Ages ago, I got a lot of requests for a way to let Dist::Zilla create new dists. Creating a useful command for doing that became part of the TPF grant work that I did, and dzil new started to work in May. By June, it reached the state it’s been in for months now, which seemed pretty good – but I didn’t really know, because I wasn’t using it.

When I first wrote about Test::Routine, I said it was a way of building a replacement for Test::Class that relied on Moose for all of its class composition. I compared it to replacing Exception::Class with Throwable, which let me get rid of a lot of features that were oriented toward building classes, and which were different from and inferior to those provided by Moose.