I don’t like getting into the occasional arguments about whether Dist::Zilla is a bad thing or not. Tempers often seem to run strangly high around this point, and my position should, at least along some axes, be implicitly clear. I wrote it and I still use it and I still find it to have been worth the relatively limited time I spent doing it. Nonetheless, as David Golden said, “Dist::Zilla seems to rub some people wrong way.” These people complain, either politely or not, and that rubs people who are using Dist::Zilla the wrong way, and as people get irritated with one another, their arguments become oversimplified. “What you’re doing shows that you don’t care about users!” or “Users aren’t inconvenienced at all because there are instructions in the repo!” or some other bad over-distillation.

brian d foy wrote a few times lately about potential annoyances distributed across various parties through the use of Dist::Zilla. I agree that Dist::Zilla can shuffle around the usual distribution of annoyances, and am happy with the trade offs that I think I’m making, and other people want different trade offs. What I don’t like, though, is adding annoyance for no gain, or when it can be easily eliminated. Most of the time, if I write software that does something annoying and leave it that way for a long time, it’s actually a sign that it doesn’t annoy me. That’s been the case, basically forever, with the fact that my Dist::Zilla configuration builds distributions where the .pm files’ line numbers don’t match the line numbers in my git repo. That means that when someone says “I get a warning from line 10,” I have to compare the released version to the version in git. Sometimes, that someone is me. Either way, it’s a cost I decided was worth the convenience.

Quick refresher: when you’ve got a unix process and it forks, the new fork can share memory with its parent, unless it starts making changes. Lots of stuff is in memory, including your program’s code. This means that if you’re going to require a lot of Perl modules, you should strongly consider loading them early, rather than later. Although a runtime require statement can make program start faster, it’s often a big loss for a forking daemon: the module gets re-compiled for every forked child, multiplying both the time and memory cost.

Huh. It looks like I haven’t written a todo list for the year since 2008. I don’t know whether I wish I had, but I’m a bit surprised. I’m going to list some things from my lists 2005-2008 that I did not accomplish and start there.

For Christmas, Gloria gave me an Arduino Starter Kit! It’s got an Arduino Uni, a bunch of wires, some resistors and LEDs and stuff, a motor, and I don’t know what else yet. I hadn’t been very intereted in Arduino until Rob Blackwell was giving a pretty neat demo at the “Quack and Hack” at DuckDuckGo last year. Still, I knew it would just be another thing to eat up my time, and I decided to stay away. Finally, though, I started having ideas of things that might be fun, but not too ambitious. I put the starter kit on my Christmas wish list and I got the Arduino Workshop book for cheap from O’Reilly.

At YAPC::NA in Austin this year, I ran a sorta-D&D game on game night. I have been meaning to write it up nicely, but I think it’s just not going to happen, so I’m going to write it up badly. Here we go…

Last week, I was thinking about how sometimes I do something I have to do and then feel great, and sometimes I do something I have to do and then feel lousy. I decided I should keep track of what I do and how it makes me feel. (I have some dark predictions, but am trying to hold off until I have more recorded.) To do this, I needed a way to record the facts, and it needed to be really, really easy to use. I’d never take the time to say “I did something” if it was a hassle.

At OSCON this past year, I was a just little surprised by the still-shrinking Perl track. What really surprised me, though, was the entirely absent Ruby track. I tried to figure out what it meant, and whether it meant anything, but I didn’t come to any conclusions. Even if I’d more carefully collected actual data, I’m not sure I could’ve made any really useful conclusions.

Over the last few weeks, I’ve done a bit of pair programming across the Internet, which I haven’t done in years. It was great! Most of this was with Ingy döt Net and Frew Schmidt.

I picked up DEFCON a few months ago on Steam. It’s a game inspired by the “big nuclear war boards” we saw in movies like Dr. Strangelove or, closer to the mark, WarGames. Each player controls a section of the world. The game starts with a few very short bits of placing units and quickly turns into a shooting war. Players launch fighters, deploy fleets, and eventually sound out bombers, subs, and ICBMs. The game looks gorgeous.