I like using Remember the Milk. It’s a to do list tracker. I use it for lots of little one-off tasks (blog ideas, games to try) and for simple projects that don’t have GitHub repositories. It’s got an API (which is kind of weird) and an iOS app (which is very good) and a bunch of other interesting little services.

There’s a file in every CPAN mirror called 03modlist.data that contains the “registered module list.” It’s got no indenting, but if it did, it would look something like this:

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.