On #Racket, samth linked to Exercism, a wonderful analog to $LANG Koans. Each exercise is a basic, small program which you code by satisfying the unit tests. Unlike, say, Clojure Koans, the Clojure Track of Exercism has you create 58 programs of various degrees of complexity, rather than a running through individual test assertions.

You code enough to pass the tests, then submit. You can keep tweaking your solution, and keep submitting it. On your dashboard, you’ll be able to see how your solution has evolved over time. You can also look at how other people solved the problem, discuss solutions, etc.

Exercism, with its emphasis on creating programs and then discussing them, is an even better way to introduce a language than a standard koan runner. Especially considering that if you already know the language, instead of solving the exercises you can easily submit new ones for others to solve.

Git Koans don’t really exist. I can’t be arsed to make it, though. There are some anecdotes called Git Koans, but as far as I can tell there is nothing similar to Clojure/Ruby Koans where you get hands-on experience fixing things incrementally, from tiny mistakes all the way up the ladder.

Basically: “Here’s broken shit. Fix it.” “Yay, you fixed it. Here’s more broken shit. Fix it.” Turn on continuous integration and use post-commit hooks as the koan runner. Eventually, you fix all the problems in the broken repo.

It actually wouldn’t be very hard. You can pretty much use any kind of make system to build a repo then fuck it up per order. The result would be hands-on experience fixing fuckups in git, from small to huge. Hell: a joker shell script that takes all the commands used to evolve a repo, and randomly inserts typos and wrong commands to fuck it up (Maybe just swap the entered command with one which is often accidentally typed instead). “Here’s a fork of Foo that’s been utterly fucked. Walk through its history and unfuck it.”

You could also do local/remote fuckups pretty easily too. Have a shell script that purposely messes up upstream/downstream relations, purposely screws up a merge, etc. Nightmare mode: multiple remotes are created, each randomly screwed up to simulate others trying, unsuccessfully, to fix their own messed up repos.

As far as I can tell, this doesn’t exist. The only time you’re ever fixing a fuckup is in actual goddamn repos during your job. The only time you will ever unfuck an arbitrarily broken repo is when your ass depends on it.

This means that for most people, git is a cargo cult. You don’t know how to unfuck things, you’re doing shit like cp -R repo repo.old. Imagine if you wrote code this way: the only time you ever fix bugs is in production code. The only time you ever fix a bug is when your ass is on the line. You’d also do cargo cult bullshit. You’d be that happy asshole sloppily commenting out lines of code to see what’s wrong. In $Lang the Hard Way style tutorials, it’s heavily emphasized that you should break stuff in order to learn what happens, and how to fix it when you do inevitably do it by accident. Yet, I would put money on the bet that the vast majority of git users have never purposely broken a repo in order to learn how to fix it. How many purposely messed up a commit or 3 in order to get hands-on experience with git reflog? How many intentionally committed to the wrong branch so they could learn how to stash pop. How many purposely introduced a painful merge conflict in order to learn the right (painless) way to resolve it? Purposely broke the build in order to learn how to use bisect?

In code, it’s unthinkable that you would have no experience of fixing bugs outside of “we need this fixed yesterday” situations. Yet with git, that’s the case. No experience, at all, of unfucking repos that you don’t depend on for rent or whatever. The average git user has no idea how to fix mistakes they make, and every mistake they do have to fix is only ever on a real repo.

Look at Oh Shit Git. It lists very common mistakes, in plain English, and explains how to fix them. I guarantee that the vast majority of git users have never purposely made those mistakes in order to see how to fix them. For many, the first time they have to fix a mistake, that mistake is new to them and they end up on ohshitgit or stackoverflow typing commands that may as well be mystic incantations.

I made a Frog branch, init’d a frog instance, and am now configuring it a bit before attempting to push it to the main site. Dunno exactly how the switch will go, but I can tell it’s already a lot nicer than Jekyll.

So, I’ve set up a blog. Creating it was the easy part. Configuring it turned out to be more difficult. Switching from an existing Jekyll layout Turns out to be a pain in the ass. So, I’m just not gonna switch.

Then, I broke permalinks, made pages load weird by duplicating the _layouts which the default theme doesn’t require (Ah, there’s that annoying ruby magic), and then broke more shit. Repeatedly broke shit for a while, seeing what’s hidden in the ruby magic. More annoyingly, the localhost preview doesn’t indicate some things are broken, you only discover them after pushing to the server. I will probably end up changing from Jekyll, and then building my own static site generator (this seems to be the main sequence of using github pages).

Now I just have to figure out what to write. Years of using twitter have left me unable to write in long chunks. In threads, you still get accustomed to chunking thoughts into small enough pieces to fit into tweets. The luxurious space afforded to a blogpost is overwhelming.

What to write? Well, the question is really what not to write. I write constantly, but in tweets and toots. I need to make writing twitter threads more annoying than writing here.

This is a wonderful opportunity to streamline my workflow, on every level: from editing to git. So many things that can be automated away, so much grudgework eliminated. I have a feeling many of my first posts will just be me discovering new ways to break shit, intentionally or by accident.

After so long on twitter, I’m unused to longform writing, despite all my threads. I’m used to expressing things 140 characters at a time, as this paragraph indicates.

This will be my first foray into longform writing in a while. I’ll probably end up parasitizing off my twitter threads.

About this site: I figured I wanted to blog, but I never want to leave vim/emacs to do it. Setting up a github static page with Jekyll was the laziest possible way to accomplish this. Literally took 5 minutes.

Edit: Immediately switched to Frog, which is a static site generator written in Racket which works on Google Pages. Spinning that up was a little more work, as GP doesn’t let you simply branch, install an alternate generator, and set that second branch as the display. Still, took only a few minutes.