As a computer programmer and user, my productivity depends primarily on my fluency with a handful of complex, powerful tools that flexibly suit many contexts alone or in combination: a family of operating systems, a package manager, a revision control system, a programming language, and a web content management system. Each of these tools has a very long learning curve, but the price is worth paying, because I expect to continue using Unix systems at work and at home indefinitely. I’m heavily invested in maximizing my efficiency on these systems over the long term.
Most of the time, though, the gains are opportunistic and incremental. And some of the time the river runs backward and it takes effort just to stand still. This weekend, for example.
In the great crash of 2008, I lost my rss2email configuration and the mail server it lived on. I’ve been “temporarily” using Google Reader ever since. Never liked it; never did anything about it. By retiring the service in a few weeks, Google is doing me a favor: I’ll finally go back to reading feeds the way I like best. In the meantime, rss2email has found a new upstream maintainer who’s actively developing it. The pkgsrc package, which I maintain, trails reality by one major and several minor versions. I prepared an updated package by whacking on it with a piece of wood (I don’t know Python or its conventions) until it worked, realized I couldn’t commit it because the new configuration and cache are incompatible with the old, and set a plan in motion to smoothly ferry users through the upgrade. If everything goes to plan, the latest version of rss2email will arrive in pkgsrc within days of the demise of Google Reader.
I hadn’t updated pkgsrc on my Mac Pro in a while. Many of the outdated packages proceeded to update without incident, but I had to exclude a few because they would produce locking errors in an infinite loop. I couldn’t reproduce the problem on my MacBook Air with the same Mac OS X and Xcode. It turned out to be a libtool bug that manifests only on OS X under certain multiple-filesystem configurations. After filing the bug and applying my workaround, libtool did its job and my software upgrades completed.
pkgsrc-current recently got Perl 5.18.0, so I figured I’d try a full package rebuild. Everything went fine until the last package, ikiwiki, hung indefinitely while building its documentation. It almost certainly had to be the new lang/perl5’s fault. I ran out of weekend to keep digging, so I posted my findings for discussion.
Unless I patch it, libtool still works wrong on my desktop. Unless I roll back to an older Perl, ikiwiki still doesn’t build on my server. And I haven’t stopped using Google Reader quite yet. But I could. (Maybe I should.)
When this sort of effort is required, why bother? The question is worth considering. I could read feeds with some other web service or native application. I could stop upgrading software from source, or stop having multiple filesystems, or maybe switch to some other package manager or operating system. I could wait for others to fix the fallout from a Perl upgrade.
But each of those options, in its own way, constitutes greater total long-term effort. If I can treat feeds like mailing lists in the tools I’ve already got, why should I bother with a dedicated feed reader? If I can keep my system as is and get software to build the way it used to, why should I merge my partitions? If I’m invested in pkgsrc and Perl, why should I wait for someone else to deal with them?
Sometimes computing means building cool new things, or extending existing things in fun ways, and sometimes it means this crap. But every small battle against local entropy is an obstacle removed, every obstacle removed is efficiency gained, and every bit of efficiency gained adds up over time.
As a person who makes and uses software, on this Memorial Day I want to commemorate the software that brings you these words, for I shall soon retire it from service. (I’ll keep writing, naturally, using different software.)
This site has run on Textpattern for eight years. It was, at the time, the web publishing software most to Nathan’s taste, and by extension mine. Textpattern made it easy for me to publish, so I wrote about my travels home and abroad and travails in college. Combined with rss2email and ezmlm, it made it easy for my family and friends to read along, so they did. Every time I wrote, someone I cared for would write back. Quite simply, Textpattern kept me in contact with my favorite far-flung people. And with Nathan’s help, it lifted my voice off the page and into your ears. When I finally settled the score on becoming a composer, Textpattern is why you were able to hear my music and know how I felt.
For all this I’m thankful, but also uneasy. I’ve been uneasy for eight years because Textpattern takes my precious words and memories and stores them in a database. Databases are essential tools for solving certain kinds of problems, but also complex tools that demand effort and skill to maintain, and therefore a problem-solving tradeoff that merits careful consideration. “Database administrator” is a job, smart people who specialize in it make a good living, and I am not one of them. Remember how the server hosting this site crashed during 2008 fall finals and the site stayed offline for three years? I was lazy, and I was busy, and then I was lazy again, but mainly I was loath to deal with restoring a database. That experience was caused by, and reaffirmed, my unease. I’m extremely uncomfortable putting my most valuable data in a place even slightly beyond my ken.
Nothing forces web content management systems to rely on databases. When I started my online journal in 1999, I wrote a wee bit of PHP to assemble web pages from text files in a YYYY/MM/DD hierarchy. (HTML was generated on the fly, but there’s no reason it couldn’t have been precomputed.) Since my content consisted of ordinary documents in an ordinary filesystem, all the usual Unix tools were available to write, process, back up, etc. Granted, my needs were extraordinarily simple. But when I switched to Textpattern in 2005, despite getting a bunch of features I wanted, I felt I was giving up something extraordinarily important. I did it anyway because the CMS I wanted didn’t exist yet and I wasn’t in a position to build it.
It’s existed for a while now. I’ve used ikiwiki to build sites for The Philolexian Society of Columbia University and The NetBSD Project under constraints I don’t believe any other web publishing system came close to meeting. In both cases ikiwiki already very nearly did; in both cases I was able to easily extend it to finish the job. I came away with a deep appreciation for its architecture and flexibility. It’s the Unix of web CMSes (orthogonal and composable, with the concomitant learning curve) and a web CMS for Unix (files in the filesystem, real revision control). The server doesn’t need a relational database installed. It doesn’t even need ikiwiki installed! Any HTTP daemon can serve up static HTML files.
I’m very comfortable with ikiwiki. It has become my default solution to any web publishing problem that doesn’t require a traditional dynamic CMS. The more sites I move to ikiwiki, the better I feel. So it’s inevitable that I want this site, above all others, to move. As usual, I first need to extend ikiwiki a bit. Once my podcast enhancements are merged, migrating schmonz.com from Textpattern to ikiwiki can be straightforward and seamless. You probably won’t notice when it happens — except that since I’ll be a lot happier about how my site works, you might notice me writing more.
My first recorded weigh-in was four months ago yesterday. Quantitative data is actionable data, and I’ve been doing plenty of quantitating. I’m solidly 1/3 of the way to my target weight, still right on schedule. But how I feel is important data, too. Recent readings:
I no longer feel like a complete mess, just a person who’s out of shape. Since I’m over the exercise hump, perhaps my conditioning will now improve faster.
I noticed that my progress, as measured by the weights I’m controlling for between 4 and 7 super-slow repetitions, had slowed. This was expected: as the weights increase, effort and intensity also increase, and so should recovery time. Strength gain isn’t my primary goal this year; jettisoning 30 more pounds is. But since raising my resting metabolic rate via efficiently induced muscular hypertrophy is — thus far — my primary change of strategy for reaching my primary goal, and since my weight loss has been slow lately, I needed to change my strength-training routine.
Rather than go to the gym less frequently, I’ve been continuing to go twice a week, alternating between my original workout routine (largest muscle groups) and a second one (smaller and/or complementary muscle groups).
After 10 more workouts:
One more slow, controlled crunch and I’ll start holding a 5-pound plate during that exercise. Two more slow, controlled reps on the leg press and I’ll have to go even slower and controllier.
After the first 5 workouts:
I’ve actually been going slightly more often than twice per week: every three days, like clockwork, to mesh the gears of my workout and travel schedules. I’m operating on the theory that the recovery interval to be concerned with is the one between identical workouts, in which case 6 days’ rest is plenty more than the 3.5 I’d been getting before, and so it’s worth it (for now) to squeeze in trips to the gym reasonably tightly.
Having just completed routine #2, I’m off to Boulder for a week in a rented house with parents, sister, and niece. (It’s a regular work week for me. Too much going on right now to take vacation.) Then the parents and I will road-trip to Las Vegas, where I’ll be attending the Scrum Gathering.
Aside from the numbers on my workout sheets, there’s also the number on my scale. After holding steady for a couple months in the low 230s, I finally reached my first sub-230 weigh-in on Friday morning. According to the burndown chart, I’m still on pace to reach 200 pounds by January 1, but only because I got off to such a quick start. To stay on pace, I’ll need to consistently drop a few pounds each month. If May goes by and that hasn’t started happening, it will again be time to change my routine.
Ignoring the numbers entirely, I’m enjoying what I’m doing, I feel good while doing it and for days afterward, and I’m continuing to notice improvements to my weight distribution and overall shape. The only reason I would consider stopping is if it were somehow at odds with my 2013 weight loss goal. Based on my reasoning and observations, high-intensity strength training alone may perhaps be insufficient exercise to deliver the goal on schedule, but the only way it could be an impediment is if the hypothetical other exercise that does suffice is also of fairly high intensity and has to happen daily. In which case I’d still lift, just less often.
Schmonzcast #14: Last week I returned from Berlin, where I gave a talk at pkgsrcCon 2013. As a pkgsrc developer since 2002, and a member of its steering committee since 2005, I’ve attended every pkgsrcCon but one (Paris 2006, as the spring semester of my freshman year at Columbia was ending). pkgsrcCon is a self-organized, purpose-specific conference for people interested in pkgsrc; it’s short, sweet, and low-key; and thus far it’s always been held in a European city well worth visiting. At this year’s conference I spoke about applying ‘Test-Eventually Development’ to pkglint (a tool for package maintainers), and how all of us volunteer developers ought to team up to slowly but surely apply the same techniques to pkgsrc’s unique and valuable internals. Even if you don’t know much about pkgsrc, a passing familiarity with TDD suffices to follow my line of reasoning. And if you know and love pkgsrc, we’d love to have your help.
