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.

I’ve been trying to learn more about different patterns people use while writing test code, and to make sure that Test::Routine accomodates them all fairly easily. So far, I’m happy with it, but I’ve had a few changes I’ve made. So far, only one is intended to be user visible. From now on, instead of writing:

Test::Routine is a new system for building reusable hunks of tests that can be written quickly as one-offs, broken into modules for reuse, and that can use the large existing set of Test:: libraries from the CPAN. It implements as few features as possible and instead tries to let you use Moose’s extensive and commonly-used object system to get things done.