Ya know, for all the conceptual elegance of the idea of branching/merging in software revision control, it sure can be a pain in practice. Just in the last while, I’ve run across the following situations:

• someone mismerged my code because they merged based on files rather than revisions
• had to decide whether to merge someone else’s code because mine was dependent on it, but they hadn’t merged theirs
• had to decide when to merge my code, which was part of a larger feature and was not a complete feature in itself: do it now and possibly introduce instability, do it later and possibly have it get delayed in the shuffle
• stuff I’d merged disappeared because the branch was remade after I merged
• conflict while merging my code because the branch was based on a way older revision than I was informed (so other changes I’d made previously were not there to merge against)
• not knowing whether my changes were to be merged because it wasn’t decided when the feature was to be released
• a special case of the previous situation, when it was first decided the feature was for later, then it was moved earlier
• work for a future feature ended up causing a conflict when trying to merge a current feature because the two changes were made in the other order on the same code

I wonder what the current status of Java < -> .Net Web Services interop is. A year-n-somethin’ ago, it was a bit of a mess, and for the project I was working on we had to create a proxy running on a Windows box to make the calls. Ugh.

Actually, I don’t really wonder. I don’t care, because I’m not having to deal with such right now. Java/Python/Flex interop, yeah. Passin’ them AMF packets around like a wild man…

Here’s a simple thing I did today that will save me some annoyance when dealing with new mail.

I manage my mail in Thunderbird by the simple rule of: if it’s something I need to respond to or reread soon, it stays in the inbox. If it’s junk, junk it, if it’s totally ephemeral, trash it, otherwise it goes to the ‘old’ folder. There are already keyboard shortcuts for junk and trash, but I was still dragging and dropping to put stuff in the old folder. Until I installed keyconfig (and yeah, that link is as close as there is to a project page for the thing, unless you count the author’s homepage). I then installed a script on O that says
MsgMoveMessage(“mailbox://nobody@Local%20Folders/old”)

No more drag-n-drop to manage my email. Nice.

(Update: now Thunderbird has that nice ‘A’-for-Archive button, so I use that instead. Had to archive everything from my ‘old’ folder to make that happen, but that wasn’t too bad. I did have one problem, though: I had stuff in my ‘old’ folder addressed to, for example, acct at ourada.org, which was an alias I used to use. Thunderbird got confused and tried to archive that to my gmail account. I just set the archive folder for all my accounts to a Local Folders one, and that problem went away.)

It’s fascinating to me sometimes to describe a problem that comes up in software development, outside its full context, just to remind myself of how weird and deep it sounds in isolation. Makes me feel a little better about how long it takes me to solve said problem, maybe.

In this case, in the full context we just call it the ‘slicer’, but that one word hides a lot of complexity. What the slicer does is: given a document in XML format A and a set of start points and offsets of selected regions of formatted text (both specified by character counts as the user sees the document), extract the given regions from the document in XML format C, rebuilding any necessary start/end tags and preserving internal formatting. Another process does the translation from format A to B to C. (These translation layers can add extra characters that are not part of the document as the user sees it.)

One thing I’ve been learning over the last few months is that if your app is pretty beefy, you might well need more than one cloud provider to deploy it. With the major differences in approach between Amazon EC2 and Google AppEngine, they each have a variety of strengths and weaknesses with respect to a given application, and the weaknesses are such that you can’t really just live with them. So you partition the app into pieces and spread ’em around…

I’d like to be able to claim that that gives you a more robust solution, but of course, if you require two clouds to be operational in order for your app to work, you’re less robust. Both EC2 and GAE have been OK, but not great, in terms of uptime. I expect both to get better over time, though.