Posts tagged coding

Lifescripts: Stochastic routines

:: flipism, racket, coding, fitness

By: Pookleblinky

Since November I’ve been doing a form of intermittent fasting I created based on coinflips, that I call coinfasting. Every morning flip a coin. Heads, you eat, tails you fast. The expected value of heads over 7 days is 3.5, so it’s identical in effect to a scheduled alternate day fast.

(As an aside: since August I’ve lost about 22kg, or about 24% of my bodyweight.)

The introduction of randomness makes things interesting: you can’t just binge on heads days, because you may get a bunch in a row. And you can’t restrict too much on fast days, because you may get a bunch of fast days in a row. This makes it easier to dial in on the right amount of calories, and lets the meals be a bit less absurd than on a normal ADF.

After doing this a while, I love it. It feels fun and sustainable, and is easily modifiable. When I hit maintenance, I can such as switch heads to TDEE+15%, tails to TDEE–15% easily. The only actual daily habit that needs to be engrained is one cointoss.

I decided to embrace more flipism.

Each morning I do 20 minutes of cycling. On heads days I add another 30 minute afternoon cycling session. This gives a baseline of 140 minutes, which is the minimum recommended dose of cardio, and averages over time to another 105 minutes for a total of 245 minutes a week. Maximum: 350 minutes a week. This is a good amount of cardio, as the maximum effective dose of cardio is about 450 minutes a week The Right Dose of Exercise for a Longer Life.

So that’s both calories and LISS out of the way, with one coinflip.

I then based my kettlebell on dice. After flipping the coin, roll 2d6 and multiply by a number to get the number of swings that day. I chose a multiplier of 10. On average, 70 swings a day, maximum 120. This is because any more swings right now would bite into my deficit too much. Later, I can toggle the amount based on the coinflip: heads 25, tails 10. This’d bring me to a maximum of 300 swings a day, and an average of 210.

So that’s what I’d been doing for a while. Some days I’d physically flip a coin and roll dice, other days I’d just ask my phone to do so.

I decided to automate this.

I created a git repo called Lifescripts, and began making small racket programs to at first simply do what I’m already doing.

Now I can simultaneously flip and roll for the day with one command.

The git repo is here: pookleblinky/lifescripts

I then added a script to decide whether to engage in argument, a script to decide whether to cuss. One to decide the music of the day, one to decide which topic to boost for the day. A script to decide whether to refactor or write new code. One to assign a random small task like doing kettlebell swings or clean something.

Git koans

:: git, coding, rant

By: Pookleblinky

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.