frantically trying to catch other player characters when they started falling!
dropping an giant bird on a glacier causing a massive avalanche!
Jorg nearly dying an ignomious death under a million tons of ice and rock!
the players found a dragon lair which is definitely going to go well for them!
saturday night was our monthly movie night. the idea is it’s everybody’s “10” (my list has about 25) movies they think everyone should see before they die. each night we randomly pick a person and they pick a movie, randomly or otherwise.
because i’m me, i’ve written an app to manage our group, and maybe yours as well? it’s called filmbucket.club, as in “film bucket list”, and it is extremely unpolished
the random choice of movie picker is weighted towards the people there that have picked less movies. so when a new person joins it’s overwhelmingly likely it’ll be their choice. my friend Jose (that’s Jose, not José, it’s pronounced like it’s spelt) came along for the first time; she picked The Big Short, about the financial crisis, vvv good and funny and self aware
the ongoing saga of kitchen:
filled and sanded and painted the scrappier bits of wall
sanded and oiled the oak worktops
still need to do phases two and three of both of those things
season 3 episode 4 of my D&D game, the broken crown, went much much better than episode three
players need agency and choice turns out
i broke everybody in ft.com’s builds for an hour, which was entertaining. how about let’s not release big changes to build tools used by the entire team of sixty and all the CI builds without publishing it as a prerelease first
doctor who is a woman now which is very good
Doctor: Why do you keep calling me madam?
Yasmin: Because… you’re a woman?
Doctor: Am I? Does it suit me?
i visited the FT’s future offices, New Bracken House. it feels like a modern office building with natural light and stuff rather than a concrete and glass bomb shelter
i ran a workshop for my current/soon-to-be-former team at work on x-dash, our new frontend component architecture that’s pretty neat if i say so myself which i do
oh yeah i’ve got another song. it’s driven by the drums which are nice and crunchy and it moves unlike anything i’ve written before, and it does that thing where it high-passes for half a bar and then everything happens. vvv good if i say so myself which i do
this afternoon it’s attempt number two at september in Pandemic Legacy Season 1: this time it’s gonna be even harder
was gonna start doing this, didn’t, hello from the future
our kitchen still isn’t done. it will be on wednesday. there’s still bits of it in the dining room and it occupies my every waking thought
i finished another song. that’s on average one song a week since mid-july. i’m close to putting together an actual album that i’ll put on actual spotify because you can apparently do that for twenty actual quid a year
i ran episode 3 of season 2 of my ongoing D&D campaign. it went okay. i need to step up my game at running these things
playtest 7 of Five-Year Plan included a couple of changes i’ve wanted to make for a while which sort of worked
playtest 8 of Five-Year Plan highlighted the fact that it’s not immune to people being a dick. which in some games works and is fun but if you can be a dick and it grinds the game to a halt then no
i played September of Pandemic Legacy Season 1. no spoilers here. jesus christ, Fenton,
Okay, but what is a makefile. Actually what is it.
Make is for running tasks
Here’s a simple makefile, as barebones as possible without it literally being an empty file:
do-a-thing:echo “did the thing”
Save that as makefile, and in the directory, run make do-a-thing:
⟩ make do-a-thing
echo “did the thing”
did the thing
Tell Make what to run and it runs it. Each line like do-a-thing: specifies a target, and the indented lines (which need to be indented with actual tabs, sorry space-lovers) after the name are the shell commands to run for that target.
I’m at AMPConf in NYC, and yesterday’s panel, “AMP & The Web Platform” raised some interesting questions around AMP’s place within the web ecosystem. Watch the recording, it’s fastastic stuff, and Tim Kaldec has a great summary of the concerns raised about AMP.
But the framing of some of the questions, both in the panel and the Q&A later that afternoon, highlighted to me that some people are looking at AMP from entirely the wrong angle. I think taking a step back and looking again might help reconcile how Google and the developer community are approaching AMP.
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.