Category: Geekery

Gallery migration done, party done, all is right with the world

I finished migrating my image gallery this afternoon. It wasn’t easy – it kept getting hung up at the same pictures. Upgrading from 1.4.4 to 1.5.1 and deleting the aborted albums out of the G2 album area helped, but some pictures just refused to migrate for some reason, including one whole album. In each case I had to copy the files to /tmp, delete the problematic ones, migrate the album, and import the picture from /tmp. I guess there were about 25 pictures I had to do that way. Not bad out of 2500+, I guess, but it was a pain. But the gallery looks a lot better now.

This afternoon/evening was our annual Christmas Carolling Party. I’m sure Vicki will blog about it in huge detail, but it was a rousing success. One of the things I like best about the party is that we invite people from church, people from work, and people from the neighbourhood, and I keep looking around to make sure that they’re not breaking up into homogeneous groups. Especially this year when we’re in a new neighbourhood. And it worked well. I think everybody got along with each other.

I love this house, and I love this neighbourhood.

Migrating image gallery

I’m in the process of migrating my image galleries from Gallery 1.4.4 to Gallery 2.0.2. Some of the 1.x albums aren’t moving properly, so there will be a slight delay while some of your pictures won’t be available. This includes the “Piper Pictures”, the pictures posted by the members of the Piper chat mailing list. In the mean time, the ones that aren’t available in http://xcski.com/gallery/[whatever] will be at http://xcski.com/g1/[whatever].

Sorry for the inconvenience.

Wiki!

While I liked Michael Greb’s suggestion of trac, it seemed like an awful lot of work to set up, since I don’t currently use subversion and I have no idea how to set that up. So I went for an easier solution and installed TWiki. It seemed easy enough, except for the fact that it’s got two “Webs” devoted mostly to settings, tutorials and the like, Main and TWiki. It would make more sense to me if all that stuff was in one place and the main Web was free for you to edit as the main purpose of the site.

Maybe if I’d seen Jen’s comment earlier I would have tried DokuWiki instead. It seems to compare favourably if you look on WikiMatrix.

So anyway, the NavData Wiki is now set up here. So far one person has already found it and started to contribute, much to my surprise because it hadn’t been announced yet.

Wikis?

My NavData project is in serious danger of overwhelming my blog, and just having a comment section doesn’t seem like the best way to collaborate on the design (assuming I get any actual collaborators). I’m wondering if I should set up a Wiki for the design. Does anybody have any experience with Wikis? Can they suggest a good one for doing software design collaboration, and give me pointers on how to use it for that purpose?

How to do this?

Update: I’ve moved this discussion to the Wiki where Douglas Robertson started a conversation on a few other approaches.

One of the things I’d really like to do in this project is provide the capability for people to leverage the previous editors, but not allow them to accidentally or on purpose ruin the data. Thus I don’t want some random stranger to delete a DAFIF waypoint, or move KJFK to Timbuktu. So I was thinking that each editor would have a “dataset” of their own, but it’s based on previous datasets. There would be a heirarchy of datasets, with of course FAA and DAFIF data as the base, then an editor or end user could decide to include or exclude the other datasets based on whether that dataset intersects their area of interest, their perception of the dataset owner’s credentials, the recency of updates, or other criteria. Not sure exactly how to accomplish that. Maybe a rating system or a public comment area where another editor or an end user can say “Hey, this guy’s points are really inaccurate” or the editor himself could say “I didn’t type in the lat/longs from a publication, I just took my GPS to the airport fence”?

I don’t want an editor to be able to delete another person’s waypoint, but I also recognize that waypoints disappear or change names. So I think there needs to be a way in dataset “a” to indicate that waypoint “FOO” no longer exists. That way if you’re using dataset “a”, you won’t get waypoint “FOO”, but if you don’t trust “a” and so exclude it, you’ll still get “FOO”.