Reading over the BitTorrent code makes me think Bram Cohen not only (indirectly) disregards the first technique he mentions in How to Write Maintainable Code, but also forgot to mention the, in my opinion, most important one: documentation. The only comments I can find are the license agreement on top of every file, and an occasional explanation of a dirty hack. There’s also a grand total of 9 docstrings, which were not written by Bram himself.

Isn’t maintainability all about being able to pick up an old piece of code (possibly even someone else’s), saying “I want this application to support this and this feature, how am I going to implement it?”, glancing over the code, and actually implement it, all in hopefully just a couple of hours? Maybe I’m wrong, but I don’t think the BitTorrent code ever died off long enough for anyone to realize this either.

It’s not only in the interest of maintainability either, also code reuse. If someone wanted to “use less code” for his Whatever-BitTorrent-utility, he’d obviously want to reuse the BitTorrent library, which is nicely available in Python’s site-packages directory. But you’d have to wade through this code, and possibly learn half of BitTorrent’s internals, before you get anywhere. If you’re writing just another client, you’re slightly more lucky: the console clients are reasonably easy to follow.

In my case, I was trying to write a ‘simple’ script to check whatever list of torrents I threw at it, and spew out the percentage that was already downloaded for each. It wasn’t pretty. I’m not sure, but I think I can use the Storage class, but pretty much everything in BitTorrent needs a dictionary containing configuration options I don’t care about. Storage happened to use just the “bad_libc_workaround” option, so I could probably pass in a dummy. But is this the BitTorrent API?

I’m almost done just writing this from scratch (except for the bdecode stuff). I still need to figure out a couple of small things in the way BitTorrent stores content. (Pieces seem to overlap files?) The protocol documentation is not very thorough either (and describes more than just the protocol).

Sorry if I sound a bit cynical on all this. Feel free to point me in the right direction if I’m wrong.

P.S.: Why is there a libc workaround in Python code? I can’t tell what the code is trying to fix either.

They’re here!
Some pictures:

The order was slightly different than what I got just now. I ordered 75 PC cds, but got only 50, and 10 instead of 15 64-bit CDs. I did get the 10 Mac CDs I ordered though, so it’s probably rounded off when packaging or something. I can’t blame them, they’re probably doing alot of sorting there for free CDs. And it doesn’t really matter in my case; I was worried 75 might’ve been too much.

I’m actually not sure if I’m going to need more or less. These are for distribution at my university, and right now they’re strongly geared towards Windows. I don’t think I can convince the university itself to even set up a Linux lab, but I’ve already met teachers and students who’ve shown personal interest.

I’m going to see if I can make this school rumble for Dapper, though.

I’ve starting switching Meld over to Cairo. Meld is an awesome application for visually diffing files, that I have found more that useful over time.

I’ve just finished converting over the standard two/three-way file diff view. Here’s a shot showing my own changes:

I guess you will have to magnify this to see the changes though. Maybe if I slap on a gradient or two?

(The empty line bug you see there seems to be in the release aswell.. wasn’t me.)

Michiel Sikkes mentioned a taskdriven actions menu in his blog. I’ve had the idea of a taskdriven interface for a while, but I’m probably more radical: use the entire desktop for it.

If you were to add an actions menu, you’d be replacing everything. Pretty much everything you do on your computer can be described in it anyways.

So that was my idea, ditch menus, ditch launchers, ditch the desktop directory. You don’t want files on your desktop anyways! They’re not organised. It’s a temporary folder of some sort to most people, and thus it gets cluttered fast. Real fast. People can still do that with their home directory if they really want to. Looking in your home directory is an action too, by the way.

Display actions based on applications, ‘active’ devices and media, etc. on the desktop. You can still use icons for that if it looks more familiar to users. Or sort it according to the amount of use, or importance (media was just inserted, display it somewhere in front, where it’s noticable for example). Lots of ways you can tweak an idea like that.

It’s a bit more radical, I just felt like blogging about it.