I hate being sick


I had to take Friday off work because I was just too wiped out to function. Then took today off too, after waking up at 5:30 to throw up. Whee.

I just got home from the doctor, who diagnosed me with my Regularly Scheduled Winter Sinus Infection. I’m about to go back to Walgreen’s to pick up my antibiotic and decongestant.

I’m sick of being sick. I’ve been sick (but getting better, I thought) since last Friday, longer if you count the runny-nose prelude. Don’t want to keep lying around. All antsy. I want to be doing something, but I don’t have the energy to focus on anything mental like reading or coding, and I certainly don’t have the energy for anything physical like moving boxes (or coding, for that matter — it’s cold in this basement).

Looks like another exciting day of napping and Playstation. Woot.


Bathrooms, toilet paper, and thread synchronization

I was working on my coroutine library this afternoon, and found myself reading (not for the first time) the docs for System.Threading.Monitor.Pulse and System.Threading.Monitor.Wait, and not understanding them at all.

So I went in search of some more info, and ran across a post by Mike Woodring called “Of bathrooms, toilet paper, and thread synchronization“. He comes up with a pretty good (and amusing) analogy, which does a good job of explaining things. (He actually uses PulseAll instead of Pulse, but once you understand one, the other is easy.)

I would extend the analogy a little further, though, because it took me a while to figure out the difference between the two different wait states. I think naming those two states, instead of just saying “you’re in a different line now”, would help a little:

  • If you want to go to the bathroom, and you find out someone already has the bathroom pass, then you stand in the Hallway and wait.
  • If you get the bathroom pass and go into the bathroom, and discover there’s no toilet paper, then you return the pass and go wait in the Lounge.
  • When the maintenance guy replaces the toilet paper, he dials the P.A. system in the lounge, and announces that he’s refilled the toilet paper. Hearing this, everyone leaves the Lounge and returns to the Hallway. (Then the usual precedence takes over: everyone waits for the maintenance guy to leave the bathroom; then one person grabs the pass and goes into the bathroom; everyone else waits for them to leave; etc.)

In any case, though, Mike’s post does quite well at explaining Thread.Pulse, Thread.PulseAll, and Thread.Wait (a helluva lot better than the example in the documentation, which is such a pitiful attempt at producer/consumer that it has to rely on a thread timeout (!) to tell that the other side is done producing).

World Tour

I was listening to the radio in the car this morning, on the way back from the gym. The Radio Personalities were telling us about the news that they were going to tell us about After This Important Message From Our Sponsor. One of the items was an update on President Bush’s “world tour”.

That just so reminded me of this.

Liberal morality is doing just fine, thank you

Our minister came across a list of UU blogs. I was looking through some of them, and came across a very thought-provoking post on Pericles‘ blog.

Here are a few excerpts:

Despite how it looks, when the conservative rank-and-file talk about moral values, they aren’t being hypocrites.

I know. I know. Rush Limbaugh is a recovering drug addict. Bill O’Reilly settled rather than face those nasty charges about phone sex. … But conservatives have an absolutely genuine reason to be concerned about moral breakdown: Conservative morality is breaking down.

The just-say-no, rules-are-absolute model of morality used to work reasonably well in real villages, where everyone believed more-or-less the same thing and the rules were never seriously questioned. But no matter how villagelike a church community is today, members are inevitably going to come into contact with people who do question the rules. And that’s a situation where liberals, who have been trained since childhood to question the rules until they find answers that satisfy them, are in much better shape.

The stats bear this out. Right after the election, the media gave some play to the fact that Massachusetts has the lowest divorce rate in the nation. What didn’t get as much play is the fact that this is typical: If you pick at random a red state, a blue state, and an index of moral decay — drop-out rate, divorce, teen pregnancy, murder, whatever — odds are that the blue state is doing significantly better than the red state.

We can’t pull those people away from conservatism just by showing them examples of conservative misconduct. Whatever they hear about conservatives will not surprise them; they already know morality is breaking down. It will just convince them that liberals must be doing even worse things.

Instead, we need to tell the good news of liberal morality. We need to publicize how liberal sex education is succeeding at limiting teen pregnancy where conservative abstinence-training is failing. We need to publicize how well liberal marriages are doing — so much so that even homosexuals are now making lasting commitments and forming community-building households. We need to publicize stories of young people being inspired by their parents’ liberal values to fight poverty and end racism.

Here’s the full article. It’s definitely worth the read.

Extreme ping-pong

Wow, I’ve been remiss in my blogging duties. We’ve been doing Extreme Programming for something like two weeks now (it’s a little vague because most of us were in training classes for half a week in there), and I haven’t blogged about it since before we started the first iteration.

So far, XP is pretty cool. It’s always a challenge to explain the term to other people, though — people always think of extreme sports.

For those who aren’t familiar with XP, I talked a little about it in my previous XP post. (We wound up going with “beans”, by the way.) More info here and here.

Some of the daily comings and goings:

  • We’re nearing the end of our first iteration, and so far, we seem to have guessed our initial velocity pretty darned well (aside from one or two stories that we (that being me in at least one case) totally botched our estimates on).
  • We’ve started having daily stand-up meetings, where we briefly say what we worked on yesterday, what we plan to work on today, and what (if anything) is holding us up (e.g., if we need to snag some people to discuss an issue, or if we’ll need somebody to pair with later). We’re following Brian Marick‘s advice, and charging people $1 if they’re late (money goes to the Development Donut Fund; tax-deductible status is still being negotiated with the IRS).
  • Most of our development now happens in the bullpen, which has phones now (but just two). No cubicle walls in the bullpen, just open space, so we can overhear each other and pitch in whenever we need to. The build PC and one of our test servers are in there too.
  • The continuous build runs automatically (including the shorter-running unit tests) every time we check something new into VSS, and an e-mail goes out to all the people who just checked stuff in, telling them whether the build succeeded or failed. Longer tests are automatically run overnight. When we add new test units to VSS, they’re automatically detected (via a naming convention) and included into the tests that get run by the build.
  • All production coding is done as pair programming (two programmers at one computer).
  • New code is written test-first whenever possible.
  • Business decisions (what features we should work on, when we should work on them, how those features should behave) are made by people who understand the business needs (this person is called the “customer” in XP parlance), not by the developers. Once Development has put estimates on those features, it’s also the customer that decides whether it’s worth the time it would take, so the customer comes up with features and also makes the go/no-go decisions. This is good news for everybody, because we developers have never wanted to make all those business decisions, we’re not good at it, but we’ve usually wound up doing it (and later getting blamed for deciding wrong) because there were no business people available to ask. With XP, we don’t have to ask the business people — they tell us in the first place.
  • Development decisions (how long the business requirements will take to implement) are made by developers, not by customers (and we’re going to try hard to stick to this — when we say “it’ll take twenty beans”, they’re not allowed to say, “you really meant to say eight beans, didn’t you?“). We trust the customer to make the right business decisions. The customer, in turn, is expected to trust us (a little, at least, and more over time as we prove — hopefully — that XP actually does work better than what we’ve had in the past).
  • XP has short iterations. In the Olden Days, people would spend two months writing specs, and then the programmers would all troop off into our cave for six months and write code. When we came back out, if what we wrote wasn’t what the customer wanted, or if what the customer thought they wanted wasn’t actually quite dead-on, it was usually too late to change the program if we still wanted to ship on time. But with XP, if the customer gives the wrong requirements, or if we misunderstand the requirements, the customer finds out quickly (within two weeks) and can fix it in the next iteration.
  • We’re planning an open house in the near future, to show off the bullpen (and to make sure people actually understand what the heck we’re doing, especially the bit about them writing the specs, and them being responsible for deciding what does and doesn’t go in the program).
  • The lava lamps are, of course, on the way. (This is one of the things that’s holding up the open house.)

Pair programming tends to be driving us toward more-standardized work hours; if I’m pairing with someone who gets in early and leaves early, then I need to get in early and leave early, because otherwise there’ll be large chunks of time where I’m not allowed to do any production coding (or where I need to find someone else to pair with for a while). We started our iteration with semi-assigned pairs — these two people are working on this feature, these two are working on this — but it was only a matter of days before that started to become much more fluid, with people getting pulled in and moved around as needed (this person is in a meeting for the afternoon, this person’s expertise is needed over here, so we’ll juggle people around a little bit and keep going). This juggling is a really good thing, because it spreads the knowledge around even more, which improves our truck number. There tends to be some downtime here and there, when there are an odd number of programmers available and so somebody isn’t pairing, but it gets spread around, so it’s not the same person every time — and there’s always research to be done, to fill in those gaps.

I haven’t spent as much time in the bullpen this week as I did last week, because this week it’s me and Sam on the rotation to be second-line client support, and we don’t want to bug everyone in the bullpen every time we’re answering a support call. So we got some help and spent an afternoon rearranging cubicle furniture, so we could code in a couple of our cubicles instead of the bullpen (those inside-corner desks are great for one programmer, but lousy when two people both need to see the monitors).

I’ve got two mice hooked to my PC right now (works great as long as they’re both USB — don’t even try it if one of them is PS/2), and hoping to get two keyboards in the near future (as soon as we can actually find two USB keyboards). I don’t know how well it would work for each of us to have our own keyboard, but I really do want to give it a shot and see how it works.

We’re not quite hard-core XP yet, because not all our development is test-driven (yet). But that’s only because our current project is a major refactor of legacy code, which for the most part doesn’t yet have unit tests (and, for the most part, isn’t really designed in a way that lends itself to easy testing). We try to introduce tests when we can, and major new code is written test-first, but most of the time, there’s really no good way to write unit tests for our changes. We’ll get there, but it’s slow going sometimes.

Yesterday my pair found a spot in the code where we could do some test-driven development, and he and I spent some time on something Brian Marick suggested to us, called “ping-pong programming“: I wrote a test and made sure it failed, and then pass the keyboard over to my pair. He wrote the code to make the test pass, wrote another failing test, and passed the keyboard back to me. And so on. That was an interesting experience, especially as we tried to hold to the “simplest thing that could possibly work” doctrine (“no, you can’t make that same change to the other branch of the ‘if’ — you don’t have a failing test for that yet!”). The method we were writing was pretty trivial, really (take three parameters and format them into a human-readable string); I’ll be interested to try ping-pong development on something tougher, later down the line.

Just “Spam Lite” please, my hamster’s on a diet

Three weeks ago, I did some hacking on my blog software. Never mind that I don’t have the source code for the version I’m running.

And it’s been pretty darned nice: since that hacking session, not a single spam comment has gotten through.

(And no, I didn’t get that by disabling comments.)

Comment spammers are so unimaginative that a hamster could be trained to block them. And so far, my hamster is doing quite well indeed.

If you ever try to post a comment on my blog, and if the hamster politely asks you to “please go away, you filthy spammer”, and if furthermore you are not a filthy spammer, please click my Contact link and drop me a note, and let me know everything about your comment (Title, Name, URL, and Comments), and the hamster and I will have a little chat. But, with that said, I don’t think it’s too likely to happen. My hamster is pretty smart.

Committee vision

My church had its semi-annual Committee on Committees meeting this morning. It’s mostly a chance for us committee chairs to all get together, and find out what everyone else is doing. It lasted three and a half hours, but it was good. The most interesting part was Reverend Josh’s presentation, which was basically about keeping the committees healthy and vital.

I grew up Methodist, and when you had a question or wanted something done, you talked to the minister. Unitarian churches don’t so much work that way; we’re an anarchic bunch. Almost everything is done by some committee or another, and if one of those committees wants to do something, they usually don’t even need to ask the minister first. This was a bit of a shock to me at first (one of many), but I’ve gotten more used to it over time. There’s just too much for one person to do it all, or even be involved in it all. And our church has a lot of committees. I’m not even sure there’s actually a full list of them anywhere, but one document lists twenty-two committees. (Not counting the Childcare Task Force we just decided to form.)

Reverend Josh drew two continua on the easel (trust a minister to know the proper Greek plural): the “tasks/vision” continuum, and the “work/relationships” continuum.

Actually, though, I think it’s better as a triangle than as two continua. The three points are Tasks, Vision, and Relationships. (The “work” in the second continuum really refers to the entire tasks/vision continuum — Committee Stuff, as opposed to People Stuff.) The idea is to try to balance the three.

Tasks are the details, the stuff you do all the time: sending out newsletters, arranging childcare for events, signing people up to bring refreshments, lining up pianists, arranging the pledge drive, mowing the lawn, and all the million and one other things that have to get done.

Vision is all about the reasons why you do those tasks: why this is meaningful to you, personally. It’s also where you want to go; your dreams for what you want the church to be, for you, for the members, for the larger community.

You’ve got to balance those two. If you spend all your time on tasks (which is far too easy to do), you get burn-out. You’ve got to take some time out, every now and then, to focus on vision, to rekindle people’s passion for what they’re doing. Find some sort of happy medium.

The third point of the triangle is relationships. “Relationships” are about the people in the committee, about personal connections between those people. Community.

Josh said that most of the people who end up being on committees are there because somebody invited them. (I guess I’m atypical in that respect — I got myself into both the Technology Committee and as a helper with the Youth Group. I guess I did get invited to the youth group’s Youth/Adult Committee, though.) The point being, for most people, committee involvement starts with a personal connection… so it’s important not to lose sight of those relationships while doing Committee Stuff.

So how do you do all that?

First, you’ve got to have a vision for your committee. Ask the current members why they’re on the committee, and what their dreams are for what the committee can do. Get people excited again about the possibilities.

For the relationship aspect, he suggested starting each meeting with “check-in”: go around and say how your week has been, what’s been going on. He also suggested getting together not for business every now and then, like having one meeting a year that’s just for socializing (one committee already does this), or having a picnic like the choir does.

He had a handout that talked about recruiting new committee members. Most of it amounts to getting to know new people at church, listening to their stories (who they are, what brought them to the Church, and why they’re excited about Unitarian Universalism) and sharing your own. He admitted that most UUs are introverts, so this isn’t the easiest thing to do, but it not only has potential to grow the committee, it also strengthens the church community. (I may get in touch with Josh and see if I can get an electronic copy of the handout and post it here.)

I’m sure there was a lot of other good stuff that I didn’t write down, but I do think there’s some good stuff here that I can apply. I know it sounds pretty dry, all this talk about committees, but I think it’ll be good. I’m co-chair of Technology Committee, and a lot of the time it’s hard to see how that really helps the church accomplish its mission statement and all that, but it’ll be interesting to get people’s stories and see if we can drive to some of that “why”.

Coroutines in C# and Delphi: Part 1

I’ve been thinking about some of the cool things I could do with coroutines, especially with regards to unit tests. So over the weekend, I wrote a coroutine library in C#.

If you haven’t dealt with coroutines (“generators” for the Python crowd), they’re interesting beasts. You create a coroutine and call it, much like you would call any other routine; and it runs for a while, and then sends a return value back to its caller. But it doesn’t actually return; instead, it just “yields” the value back to the caller. The difference is that after a yield, the coroutine’s state — local variables, etc. — still exists, and later, you can tell the coroutine to resume where it left off, and run a while longer, until it yields again (or, in the end, returns for real).

If you’ve read about C# 2.0 iterators, you’ve got the basic idea. But coroutines are much more powerful. In particular, I believe that a C# iterator is a single routine, and if you have any yield statements, those have to occur inside that single routine. (Correct me if I’m wrong — I don’t actually have Whidbey installed, and haven’t tested this. But based on what I’ve read about them, I believe this is correct.) But if you’re using a coroutine, that yield can come anywhere: when you yield a coroutine, it’s not just the local variables that are saved for later, it’s also the call stack.

Which means, for example, that coroutines can use recursion to their heart’s content. If I had something like this:

public class TreeWalker : Coroutine {
    private TreeNode _tree;
    public TreeWalker(TreeNode tree) { _tree = tree; }
    protected override Execute() {
    private void Walk(TreeNode tree) {
        if (tree != null) {

Here I’m doing a recursive in-order traversal of my binary tree… but the call site doesn’t need to deal with the recursion — or even care that there’s recursion going on. The call site would just look something like this:

foreach (TreeNode node in new TreeWalker(tree)) { ... }

If you’ve read Raymond Chen‘s series of articles on using fibers to simplify enumerations, this should all sound very familiar; he was basically using fibers to implement coroutines. I did the same thing, but avoiding fibers (more on this later, but read the dire warnings at the end of Raymond’s third article).

I’ll post the code a little later, once I’ve got a few more features added (like the ability to deal with exceptions inside the coroutine). I’ll also be doing a Delphi version (probably both Win32 and .NET).

Lament for a toaster

Once upon a time, toasters just worked. My parents had the same toaster for most of my life, and up until it finally died after somewhere over twenty years, it just worked. Put some Pop-Tarts in it? You get hot Pop-Tarts, ready to eat. Put some frozen waffles in it? You get hot waffles, ready to eat. Put some Toaster Strudel in it? You get hot Toaster Strudel, ready to eat. Put some, heaven forbid, bread in it? You get hot toast, ready to eat.

And yet today, after more than twenty years of technological advances, the computer age, toasters with optical sensors to make sure they never burn anything, I’m stuck with the smell of scorched Pop-Tarts in my house. Because I had to adjust the setting last week (from the setting that worked reasonably well for toast most of the time) so it didn’t give me half-frozen waffles.

The toaster companies really need a good QA team that will tell them about regressions like this. I shouldn’t have to adjust my toaster. And I know I shouldn’t have to adjust it, because I’ve used one I didn’t have to adjust. I know it’s possible. So what happened?

Hell, I’d even settle for a toaster with a timer on it. Microwaves have timers. It works. It’s a known paradigm. Toasters have a knob that goes from “sort of raw” to “sort of scorched”, and everything in between is “I feel lucky”. Pity Google doesn’t make toasters.

(Hmm. There’s an idea. http://toaster.google.com/… Nope. Rats.)

In youth group, we’ve been talking about how to deal with death. But how do you deal with toasters that won’t toast?