I’m at chez Brennan for Christmas, and we’re playing Risk again. Which means I’m trying to improve Risk again.
Risk is really, truly awful:
The last twenty or so rounds are everybody’s dwindling forces struggling against the one juggernaut that emerged in maybe round 10. It’s no fun sitting there losing for an hour.
The essentially random initial placement means nobody can even think about strategy until they’ve carved out a slice of territory after a few turns, by which point they’ve spent so long scrapping they’ve got no army left.
The ever-escalating value of trading in cards causes huge swing towards the end of the game, but doesn’t actually end up making any difference because of the massive territorial advantage the winner has, so it just drags the game on for another few dreadful rounds.
But! There’s a core of a good game in there. The territorial reinforcements and dice rolling mechanic are fundamentally okay! So I’d been thinking about what you could minimally change about the non-core aspects of the game.
Separately, I’ve been playing Risk Legacy with a few friends. The game is basically still Risk, but in each game you make changes to the board, to your faction, to cards, that permanently change the game. And it turns out Hasbro had also put some thought into the design of the base game. The core is the same, but there are a few changes to setup, reinforcement, and victory conditions that go a long way to addressing the problems I outlined above, especially the late-game slog.
So I thought I’d borrow a few of them for regular Risk.
And it worked! The game we played was far shorter and more tactical. Mum won, with a sneak attack on my Icelandic headquarters that nobody saw coming.
Modified Risk rules
Follow the original Risk world domination rules, plus the variant Fortifying your position. You’ll need some extra tokens to represent Headquarters and Victory Points; we used buttons.
Everybody rolls a die; highest number places first.
Clockwise from the first player, place a Headquarters and 8 troops in any unoccupied territory that is not adjacent to another player’s HQ.
You may move any number of troops into an unoccupied territory adjacent to one you control. This does not earn you a Risk card at the end of the turn.
Scoring & Winning
First player to reach 4 Victory Points (VP) wins. The game ends as soon as they gain their 4th VP.
Each HQ you control (including your own) is worth 1 VP
At the start of your turn you may trade in any 4 Risk cards for 1 VP
If you take the last Risk card you get 1 VP
If you remove a player’s last troop from the board, they’re knocked out. You get all their Risk cards.
If you’re knocked out, you might be able to rejoin at the start of your next turn. If there is an unoccupied territory, place 4 troops (but no HQ) in it and continue playing. If there’s nowhere you can start you’re eliminated.
During your reinforcement phase you can trade in any number of Risk cards for troops. Ignore the territory and unit on the card. You gain extra troops depending on the number of cards you trade in. Territory cards are worth 1 point, wildcards are worth 2:
In the Apps team at the FT, we quite quickly ended up with 3 separate new Node apps running on Heroku, each with their own deployment pipeline and release schedule. Keeping track of what was released and fixed when was intractable. Manual version numbering was impractical. Gotta go fast.
I hit upon the idea of using something like semantic-release to automatically number our versions. We weren’t releasing npm packages, so not the thing in itself, but something based on the idea of using commit message conventions to guide version numbers. We quickly realised that semver major-minor-release was pretty much meaningless, and the idea got shelved.
A few weeks later I had a thought. A version number is nothing but a monotonically increasing sequence. It needs to increase if and only if there is a change to the code that’s running. It needs to be derivable from nothing but the source code and its Git history. Number of commits to master would fit the bill, but the number would quickly grow and become meaningless: “when was that fix released? In 2497?” “No, it’s in 2506, that’s not in production yet”.
Instead, I played around with the number of merge commits into master. It’s far less granular than gross number of commits. We have automatic deploys from master to our Heroku staging apps, and master is branch-protected on Github. That ensures that every release to staging has an associated merge, and every merge gets released. Or, put another way, the number increases if and only if there is a change to the code that’s running. It’s also comparable across environments. If production has a lower version than staging, you know exactly how many pull requests it’s behind by. If they’re the same, you know production is up to date and running the exact same code as staging.
I’ve encapsulated this in the npm package @quarterto/heroku-version-infer. It’s got a CLI designed to be run at the npm lifecycle script heroku-postbuild. It needs correct repository information in your package.json and it depends on the mostly-undocumented Heroku environment variable SOURCE_VERSION.
On its own, it just updates the version in package.json. I’ve got a suite of other tools to propagate that release version to other things that need to know about it: Github, Sentry, JIRA. They don’t depend on each other, but they do play nicely together.
We’ve been versioning like this for a couple of months now and it’s been pretty useful.
This is the blog post I wish had existed months ago.
If you’ve been using Meteor for a while, chances are you’ve come across the fantastic blog Meteor Capture and, in particular, their two-post series How to Publish Anything. If not, I strongly recommend going and reading them both, because this is the unofficial third post in that series.
This post isn’t my usual fare. Sorry about that. But I am so fucking angry right now.
Up until this afternoon, if you googled “register to vote”, this is what you got:
That is not a link to the voter registration page. That’s an ad, placed by Vote Leave, that took you to a form on their site, with a nice big red “Register to Vote Now!” button that did nothing of the sort.
I’d love to assume this was done in good faith. I really would. I can’t think of any possible world in which this isn’t intentionally misleading. This is a major political campaign intentionally intending to disenfranchise people. This is electoral fraud.
I’d wager the very demographic that’s likely to be googling “register to vote” in the first place is the one most likely to vote “remain”, viz. 18-24-year-olds.
And they would have gotten away with it too, if it wasn’t for you meddling kids. Who knows. They still might.
That page is gone now. Who knows what damage it’s already done.
Let’s say you have a makefile, and you already have a shell script (probably called something like env.sh) that you source before running your app to set environment variables in it. Now you’re writing tests (run by Make), and you need your environment variables there, too. “Aha”, you think, “I’ll source the env script in a makefile variable”:
Well, that doesn’t work. Make runs its commands in a subshell, so the variables exported by source aren’t available to other commands.
It is a truth universally acknowleged that online banking websites are shit. Smile, for example. If you’re so infelicitous as to press the back button, or reload, or open a link in a new tab because that’s how HTTP is supposed to fucking work it logs you out. And apologises (sneeringly). If, on the login screen, you start typing your sort code, it “logs you out”. Because reasons. The less I have to deal with the website, the better my general mental health seems (although I’ll admit there are confounding factors here).