Today is my first full day back in Pennsylvania after the Perl QA Hackathon in Lyon, and I’m feeling remarkably recovered from four long days of hacking and conferring followed by a long day of travel. I can only credit my quick recovery to my significantly increased intake of Chartreuse over the last week.

Everybody knows, I hope, that you have to be really careful when dealing with time in programs. This isn’t a problem only in Perl. Things are bad all over. If you know what you’re doing when you start, you can avoid many, many problems. Unfortunately, not all our code is being bulit anew by our present selves. Quite a lot of it exists already, written by other, less experienced programmers, and often (to our great shame) our younger selves.

Sometimes, the example code in documentation or teaching material is really bad. When the code’s dead wrong, that might not be the worst. The worst may be code that’s misleading without being wrong. The code does just what it says it does, but it doesn’t keep its concepts clear, and students get annoyed and write frustrated blog posts. This code might be good enough for production, but not for pedagogy.

I recently made some changes to Ywar, my personal goal tracker, and I couldn’t be happier! Mostly.

I’ve never been a fan of “freemium,” although I understand that game developers need to get paid. It often feels like the way freemium games are developed goes something like this:

Ywar is a little piece of productivity software that I wrote. I’ve written about Ywar before, so I won’t rehash it much. The idea is that I use The Daily Practice to track whether I’m doing things that I’ve decided to do. I track a lot of these things already, and Ywar connects up my existing tracking with The Daily Practice so that I don’t have to do more work on top of the work I’m already doing. In other words, it’s an attempt to make my data work for me, rather than just sit there.

About a year ago, I told Mark Dominus that I wanted to learn to play bridge, but that it was tough to find friends who were also interested. (I’d rather play with physically-present people whom I know than online with strangers.) He said, “Sackson’s Gamut of Games has a two-player bridge variant.” I had never heard of Sackson, A Gamut of Games, or the two-player variant. I said, “oh, cool,” and went off to look into it all.

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.