Most of the last few employers I’ve worked for have been somewhat leery of the concept of pair programming. After all, you have two (or perhaps more) programmers working on a single bit of code, obviously you’re getting half as much work done, right? Some of them (including, I think, my current one) are somewhat tolerant of it, because they see that stuff actually gets done. But I certainly understand the wariness that they feel when they see two programmers crouched around one screen yelling at each other. 😉

Well, for the last week – almost two weeks, in fact – I’ve been wrestling with the same bit of code, trying to implement the same feature. I knew it couldn’t possibly be that hard, but everything felt just wrong.

Today Chris and I worked through some of these issues, argued about implementations, brainstormed about various solutions, and ended up ripping out a piece of the code that, while it kinda looked ok, had been making me feel gradually more uncomfortable for the last few weeks, and turned out to be squarely in the way of what we were trying to accomplish.

And, as a result, we now have a simple, elegant solution to what I was trying to do all along, and, into the bargain, make a number of other things a bunch easier, and more secure. As well as being a lot easier to read in the code, and clearer to document.

I haven’t always been sold on the idea of pair programming. But there are some situations in which it works amazingly well. Having a new perspective on something, and attacking a problem from different sides, often leads to innovative solutions that neither programmer would have arrived at independently. And, at least in my case, it is almost always the very best way to break through a brain cramp, particular one that I’ve been fighting for an extended period of time.

If you’ve never attempted pair programming, it will feel weird the first few times you do it. But you owe it to yourself to try it the next time you get stuck on a particular problem. Or just when you’re trying to solve a particularly sticky issue, and your solution doesn’t feel quite right.

Each time I’ve written a book, I’ve avoided looking at the end result. I’m rather afraid of two things. One, that what I wrote was drivel. And two, that the editors did something to it to make it drivel.

I spent the evening looking through ‘Apache Cookbook’, and I’m less than thrilled with the *SIGNIFICANT* differences between the last version in cvs and the version on paper. Every recipe is changed in style, and most recipes are changed in content. I hate that editors feel the need to edit personality out of the text. It seems that people that know me from IRC will buy the book looking for my personality. All sarcasm has been removed. All humor has been removed. All colloquialisms have been removed. What’s left is pretty sterile. I’m not happy.

Of course, I suppose I can’t publish this post, at least until the second edition comes out. And even then, only if the second edition fixes these problems.

*sigh*

Dandelions! (I love spring!)

Apart from the time wasted tinkering with Drupal (it appears very probable that Drupal auth breaks under https, according to several rather unclear postings I found) it has been a very full weekend.

On Friday night, we went to the Good Friday service, and it was, as always, very sobering. I had agreed to read something, and didn’t understand that I was to select the thing that I was going to read. Fortunately, John had picked two things, and gave one of them to me. Having rather insufficient time to prepare for it, I found the reading to be rather more moving that I was really prepared for. It was, however, a very good reading, and I’m glad it worked out that way.

We went to the Aviation Museum on Saturday morning with Sarah and Ben, who were visiting for the weekend, and had been camping at the Horse Park. Then they went off to a tour at Maker’s Mark, and my Sarah and I went to the kite festival at Jacobson. Didn’t actually get any pictures, which is a shame, as there were dozens of very interesting kites, as well as hundreds of more mundane ones. I didn’t actually want to fly my kite, because there were so many kites up and so many of them were getting tangled. Sarah got a dragon, and we flew that briefly.

Then we went looking for a motorcycle. It seems that neither Sarah nor I are prepared to part with the Jeep, but I’ve got to find a way to spend less on gas. And I *really* don’t want to pick up a new car payment, as the Jeep is paid for. So it seems that perhaps getting a motorcycle to run back and forth to work might be a possible solution. However, with the weather being so gorgeous, everone’s inventory is very low, and the price range of what I liked was rather higher than I expected or can afford. I guess I’ll just have to keep looking.

I’ve spend an inordinate amount of time this evening tinkering with Drupal. I’m impressed with the thought that went into the database design, with flexibility and extensibility always the obvious priority. However, when you make something extensible, people extend it. And it seems that half of the modules out there have, as documentation, a README file that says “Install as normal”, and offer very little else in the way of help.

When I asked a question on #drupal, I was apparently a little too frustrated, and the tenor of my question sparked a lecture on the nature of open source documentation. It was the fairly standard bit about how one is supposed to fix the documentation (or software) rather than complaining about it. All true, and completely worthless and time-wasting. There are times when open source people can be very tiresome. When stuff is good, it’s because we’re brilliant. When it’s bad, it’s because you don’t contribute enough.

I’ve been trying to drag useful data out of MS Excel files without having to actually install Windows somewhere – and preferably without having to work with Excel. I discovered that Excel will export files as XML. The schema is painful, but, after a bit of working with XML::Simple, I was able to get the data into a more useable format.

This isn’t a finished product by any means, but I thought it might be useful to someone as a starting point, so that you don’t have to plough through the XML schema yourself:

#!/usr/bin/perl
use XML::Simple;

my @cols;
my $x = XMLin('AcademicTables.xml'); # Name of file
my $w = $x->{'Worksheet'};
foreach my $worksheet (@{$x->{'Worksheet'}}) {
    next unless $worksheet->{'ss:Name'} eq 'Academics_Depts'; # Name of worksheet
    @rows = @{$worksheet->{'Table'}->{'Row'}};
# First row - Get the column names
    $firstrow = shift(@rows);
    foreach my $cell (@{$firstrow->{'Cell'}}) {
        push @cols, $cell->{'Data'}->{'content'};
    }
# The the rest of the rows
    foreach my $row (@rows) {
        @values = @{$row->{'Cell'}};
        foreach $col (@cols) {
            $c = shift @values;
            $val = $c->{'Data'}->{'content'};
            $val =~ s/n{2,}/<br />/g; # Remove multiple newlines
            print $col . " -> " . $val . "n";
        }
    }
}

Joe, over at AdminSpotting, says nice things about the book. Thanks, Joe.

superbowl.com is STILL running Server: Apache/1.3.28 (Unix) mod_perl/1.26.

I work at a college. I’ve been gently advocating introducing podcasting to our intranet website, and talking with various people – faculty and students, as well as staff – about the possibilities of using podcasting as a way to enhance in-class lectures. The reaction that I get, almost universally, is that this is just a high-tech way to skip class. I feel that folks are completely missing the point. What follows is a response that I wrote this morning on the intranet discussion forum. I thought I’d share it here because I’ve talked with a few of you, my constant readers, about this topic.

======

I’m interested, as I have this conversation with various people, that everyone seems to assume that listening to a podcast is an alternative to attending class. This strikes me as a fascinating conclusion to draw, but also strikes me as a rather fundamental misunderstanding of the value of this tool. There are two different uses that I’d suggest. However, the exciting thing about this technology, and the ways that it’s being used on campuses around the world, is specifically that it’s being used in unexpected ways, not that it’s being used in boring ways, like just skipping class. So here’s two very simple ways that it can be used – one fairly obvious, and the other more interesting.

First, there’s the obvious one. Lots of students take recorders to class. These might be microcasette recorders, or some variety of digital recorders. Then, on their own time, they re-listen to the lecture. Often, they will play the recordings while they exercise, or do laundry. They do this so that they can drum into their minds the things lectured on. It lets them replay the bits that they had trouble understanding, or bits during which their minds were wandering. When I was in graduate school, I did this, and I’d usually listen to the lecture at double speed, so that I could get the entire lecture reviewed in 15 or 20 minutes.

The problem with this is that the recordings are *always* poor quality, marred by the whispers and sneezes of the person next to me, subject to my batteries running out, and most importantly, they were lost when I needed to use that tape to record another lecture.

By recording podcasts, we have the same resource, but the quality is far better, and it is permanently archived. It also allows the professor to review what they covered on a particular day. The same resource is available to the entire class. And the students have something tangible that they can take away with them from the class – a CD of all the lectures that they attended, to which they can refer years later.

Yes, obviously, some slackers will use this as an opportunity to skip class. I took *very* few courses at Asbury where a mere recording could really substitute for actually attending class. If we have any professors who have that little interaction with their students, then perhaps the problem is the professor, not the technology. And, furthermore, if attendance is a requirement of the class, then it’s up to the professor to enforce that in some meaningful way other than simply depriving the student of knowledge.

Ok, idea two. This one is far more exciting and interesting to me. I’ll illustrate by a particular example, but I’m sure you can extend it to other ideas. Consider an art appreciation class where various paintings are being discussed. Simplistically, a slide show. As each painting is shown, a brief description is given, perhaps something about the artist, the history, and critical notes on the painting.

As it happens, the m4b format (which many podcasts use) allows for “chapters” with an image associated with each chapter. This would be ideal for such a presentation. It would also be great for a “how-to” style podcast that was presented to accompany a physics lab, with a photograph of each step of the experiment. I’m planning to do just such a podcast to accompany my daughter’s science fair experiment, with a photo illustrating each step of the experiment. Fortunately, the software for producing this is very easy to use, as you might know if you watched Steve Jobs’ keynote during the recent Apple conference – you record the audio, and then drag the images to the appropriate time during the recording.

So, I’ve droned on for quite a while. I tend to do that when I’m excited about a particular topic. I just really feel that most folks are totally missing the point of this exciting technology, and seeing it as nothing more than a high-tech way to justify missing class. Rather like the folks that stay in bed and watch church on TV. It’s so much more than that.