I hate Git. I really, really, really, really, really hate Git.

Know why?

Because the way it interacts with users ia absolutely fucking *appalling*.

So I close a repo. Make some changes, commit, push. No upstream set, I set it.

Not allowed – and it’s trying to use my *liblfds* account, which I didn’t want.

Okay – my mistake. I change the user name and email address, wipe the checkout (it’s probably got a bunch of stuff relating to liblfds in it, I’d guess) and do it all again.

Problem is…

…exactly the same problem.

Still using my old account.

WTF.

So now I’m Goolging for 15 minutes and I *think* what’s happening is that Github is recognizing the SSH key in use and deciding which account it is based on that.

THIS IS NOT OBVIOUS TO THE FUCKING USER, JESUS.

This is my experience with Git all over.

Unless you know, a priori, what’s going, it is *baffling*.

It is the least friendly source control system I have seen.

I’ve been trying to make a *one character* change to the Light’s Hope WoW server code. So far, it’s taken THREE HOURS. I’ve just fucked it up AGAIN, because I forgot to branch my own fork. You understand that after a few hours of problems, you become progressively less diligent, and a development process with a large number of separate, detailed steps inherently promotes the frequency of mistakes.

Mailing list

I’ve been working a lot on a mailing list.

A list has an email address, a user has an email address, a user can subscribe to a mailing list.

A subscribed user can email to that list, and all subscribers will get that email.

To subscribe, you give your email address, you receive a confirmation email, you click on the link to confirm.

Same to unsubscribe.

Simple, right?

Well it’s been a voyage of discovery 🙂

So it’s CGIs in Python with an SQL database for the back-end. No need for anything more than this – this is a simple, lightweight mailing list. We’re not talking ongoing background processes here.

Obviously, I used a state machine to control the flow of execution, and on an impulse I decided to try implementing the state machine in the database – which is to say, there’s a table of states, of events, and the state -> event -> state combinations.

I then after some time realised I would need to implement my usual approach to error handling – Python just throws a wobbly when something goes wrong, and actually want to build up a sane and user-readable call stack and ensure I always emit something sane to the HTTP server (otherwise it just thinks the CGI has fallen over and prints a 5xx).

Having done all this, what I’ve realised is that I’ve not thought properly about what happens when the database goes down.

The state machine steps through states (no kidding right) and there are resting states (like subscribed, or waiting for a confirmation link to be clicked on) and there are sequences of states, where you start the sequence and it moves through a sequence of states (which states depends on the outcomes of each state) and then reaches a resting state.

So what happens if the database dies during a sequence of states?

Well, what has to happen is *something picks up where we stopped*.

Uh. Ain’t nothing doing that… all the scripts are CGIs, they run when the user makes them run.

So really we need something like a background task which applies the state machine as necessary to every email address subscribed to every list.

Well, okay…

…but in fact, all this state machine checking, you know why you need it? it’s for and only for handling the subscription and unsubscription work – sending out the email asking for confirmation.

Hmm.

So, those confirmations – they are good practise. In fact, on a list with any significant readership, they are necessary, to prevent abuse.

But are they necessary, *now*, for my list? my tiny list?

…no.

Not at all.

I could just have a subscribe / unsubscribe button, which directly issues the necessary single-statement SQL.

So in fact what we have here is an example – which has cost me many days of work – of writing *unnecessary code*.

This is in fact one of the key problems of software engineering – making sure you only write that which is *actually needed*.

Thunderbird

…has been updated by apt-get, and has completely lost all configuration information.

*facepalm*

Now I see also a bunch of new preferences – like “enable/disable cookies”…!

I don’t want a web-browser, I want a *text based email client*.

I don’t like being spied on normally.

I like it even less when it’s in email.

BBC news just fell off the list

I am never going to visit the BBC news web-site again.

I idly went over to the site, while munching a little food, before going out.

There’s a story about a US police officer who repeatedly shoots and kills someone totally helpless and unarmed and (as ever) is found not guilty of murder or manslaughter.

The BBC page for the story has at the top the bodycam footage, on automatic play, of the victim begging not to be shot, and the police officer shooting him five times, as he crawls towards the police, screaming and dying.

Okay, BBC. Srsly. Such footage is profoundly traumatic. I DO NOT WANT YOU AUTOPLAYING SUCH FOOTAGE IN MY BROWSER WHEN I OPEN A NEWS STORY. ARE YOU COMPELTELY CRAZY?