Andrew and I seem to constitute a test of software design in almost everything we do, because we share so much stuff. Not just computers, which is already sort of an edge case for desktop Linux these days (or so I gather from how likely it is that the friendly ‘Switch User’ functionality will freeze most laptops; users must be assumed not to share them). We share data. Scads of it. Not just code. All kinds of data.
We share cameras to the point of not always being sure who took which photo. Does f-spot want us to maintain two separate databases, descriptions and tagsets over our 14GB collection of digital photos? Does it want us to each have a copy of the collection on our laptops? Yes it does! (We get around this with sshfs which has many downsides, but at least we can share data and won’t lose everything the next time Andrew’s laptop gets stolen at work.) We share music collections and one good set of speakers. MPD is actually designed for that use case and some day the clients for it will vaguely approximate sensible user interfaces per Rhythmbox and Quod Libet and whatever Apple application they’re based on, instead of assuming that we’d like to browse the filesystem tree rather than, say, by artist or similar.
Today’s unsharable piece of data is, alas, jMemorize flash card decks. We’re both learning Spanish and would like to build a joint flash card deck. It took me a few weeks to give jMemorize a go at all because it was recommended to Andrew on the basis of having lots of cards ready for language learning
and turned out to have lots of cards ready for learning Hebrew and New Testament Greek, so we have to do our own cards, contra the sales pitch. I was kind of cross about that.
Naturally though, we’d prefer to share the cards. I initially thought that, well, if the save format is text, I’d put it in version control and we’d both add to the deck. So I tried, and here are the options:
- Share the full XML jMemorize data files, which means that the
number of times you’ve seen this card
and number of times you got the answer right
statistics would, instead of being modelled to each of us, be modelled on the sum of our performance (in fact this is the ideal case, in actual fact the presence of this data in the file looks like it would result in a stupendous number of conflicts). Entirely unhelpful, since we’re learning exactly the same materials but can’t be assumed to be equally bad at every question. (This is all important because jMemorize adapts how many times you see a card based on how many times you get it right.)
- Export to CSV. This basically doesn’t work at all for a repeated
add some more cards, import some cards Andrew designed, export my cards to him, around we go
exercise, because it doesn’t merge. If I export my cards to CSV, and then re-import them, they’re assumed to be all new, so I get a duplicate of any card I happened to have in the deck already.
Andrew points out that I could hand roll some kind of more easily mergeable file format that doesn’t include the user-specific how well am I, Mary, learning this fact?
data, then have some kind of commit scripts that converts the XML to that format and commits that to the version control and then when I update, takes that format and stuffs it back into the XML (creating new cards only when it needs to). It’s not even a hard problem, unless I’m missing something crucial, but it’s, as usual, more time than I wanted to spend on this, given that I need to actually learn Spanish and I’m pretty much up to scratch on how that kind of hideous data munging is done.
