The Board Game Remix Kit

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

New rules for old games! The Board Game Remix Kit is a collection of tips, tweaks, reimaginings and completely new games that you can play with the board and pieces from games you might already own: MonopolyCluedo, Scrabble and Trivial Pursuit.

The 26 rule tweaks and new games include:

  • Full Houses: poker, but played with Monopoly properties
  • Citygrid: a single-player city-building game
  • Use Your WordsScrabble with storytelling
  • Them’s Fightin’ Words: a game of making anagrams, and arguing about which one would win in a fight
  • Hunt the Lead Piping: hiding and searching for the Cluedo pieces in your actual house
  • Guess Who Done It: A series of yes/no questions to identify the murderer (contributed by Meg Pickard)
  • Zombie Mansion: use the lead piping to defend the Cluedo mansion
  • Judy Garland on the Moon with a Bassoon: a drawing game that uses the answers to trivia questions as prompts

The Board Game Remix Kit was originally released in 2010 by the company Hide&Seek (which closed in 2014). We are releasing it here as a pdf (for phones/computers) and an epub (for ereaders) under a CC-BY-SA license.

If you enjoy the Kit and can afford it, please consider a donation to the World Health Organisation’s COVID-19 Response Fund.

Confined to your house? What a great opportunity to play board games with your fellow confinees.

Only got old family classics like Monopoly, Cluedo and Scrabble? Here’s a guide to mixing-them-up into new, fun, and highly-playable alternatives. Monopoly certainly needs it.

Pass The Pepper: Social Distancing is Nothing to Sneeze At

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

You’ve seen a few Rube Goldberg-style machines before. You watched that OK Go music video twice. But this… this is something else.

(Everything else on his channel is gold, of course, too: if you’re looking for a jumping-off point, try his dinner-productivity machine.)

Fox In Sox

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

This is the best rap music-related thing to happen to Dr. Seuss since Wubble Down, over 10 years ago. And understand that there have been a lot of strong candidates.

(I maintain that I’m not that “into” rap music. But somehow I keep proving myself wrong. Loving this song right now, for example.)

Giving a Damn at Scale

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

How many more developers have to point out how bloated we’ve made the web with our frameworks, tracking scripts, and other 3rd party solutions before we take things seriously? We’ve been banging on about this for ages. It’s like a plague!

This is just what I was thinking when I wrote about that terribly bloated digital climate activism website the other day. I hadn’t meant to single them out specifically because the problem’s… well, it’s a pandemic!

And as Bridget goes on to say, it’s especially important at this unusual time, with many people confined to home and using the Internet to try to get accurate and up-to-date information and resources (and sometimes overwhelming major websites), that performance, accessibility, and availability matters most.

There’ll be many lessons to learn from the coronavirus crisis. But these lessons aren’t just related to healthcare, or work, or supermarket logistics. No field will be left untouched. And one of the things that I hope my field learns, when this is over, is the importance of things working even when things get tough. Test the sad paths, test your site under heavy load, test your site with the CDNs simulated “down”, and develop accordingly. Because this isn’t the worst kind of crisis we could face, and we have to be ready for the worse ones that could come.

Getting Hired at Automattic

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

I started at Automattic on November 20, 2019, and it’s an incredible place to work. I’m constantly impressed by my coworkers kindness, intelligence, and compassion. If you’re looking for a rewarding remote job that you can work from anywhere in the world, definitely apply.

I’m still overjoyed and amazed I was hired. While going through the hiring process, I devoured the blog posts from people describing their journeys. Here’s my contribution to the catalog. I hope it helps someone.

I’ve written about my own experience of Automattic’s hiring process and how awesome it is, but if you’re looking for a more-concise summary of what to expect from applying to and interviewing for a position, this is pretty great.

Dungeon Drawers

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Drawers with a dungeon inside

The BEST THING I’ve seen on Twitter this week (month?) is Justin Alexander’s thread documenting “The Dungeon of Drezzar,” Peter Heeringa and Troy Wilhelmson’s spectacular multilevel dungeon built into a series of dresser drawers.

Well now I feel like my DM isn’t trying hard enough. Move aside, Roll20!

Happy Birthday, You’re Fired

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

I walked the dog, bought myself a wax jacket from a local garden centre – so I could feel more ‘Country’ – and in the late afternoon my boss called me to say… you’re fired.

So begins Robin‘s latest blog (you may remember I’ve shared, talked about, and contributed to the success of his previous blogging adventure, 52 Reflect). This time around, it sort-of reads like a contemporaneously-written “what I did on my holidays” report, except that it’s pretty-much about the opposite of a holiday: it chronicles Robin’s adventures in the North of England during these strange times.

I’ve no doubt that this represents the start of another riotous series of posts and perhaps exactly what you need to lift your spirits in these trying times. A second chapter is already online.

How to not make a résumé in React

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

I’ve seen a fair share of tutorial links floating around in newsletters and Twitter and the like recently. They all promise the same thing, namely how to use React to create a résumé.

I mean, I get it. It’s important to have something to build towards when learning a new skill, especially with development.

At first blush a résumé seems like a good thing to build towards: They are relatively small in terms of complexity and can probably use content that already exists on your LinkedIn profile. If you’re looking for a job, it’s also a handy way to double-dip on a skill that is in high demand.

I checked out a few of these tutorials, and after noticing some patterns, I’d like to mention a few things you could do to your résumé instead. I’m not going to link to the ones I tested because I don’t want to give bad advice more exposure than it is already getting.

I can’t even begin to conceive of the kind of mind that, when faced with the question of how to put their résumé/CV online, start by installing a Javascript framework. My CV‘s online (and hey, it got me my current job so that’s awesome) and I think it’s perfectly fabulous. Simple, human-readable, semantic HTML with microformats support. Perfectly readable on anything from lynx upwards and you’d probably get by in telnet. Total size including all images, fonts, style and script is under 140kb, and can all be inlined with a quick command so I can have a single-file version that looks just as great (I use this version to email to people, but I’m thinking I ought to just inline everything, all the time). Under 1kb of my payload is JavaScript, and it’s all progressive enhancement: using an IntersectionObserver (which I’ve written about before) to highlight the current “section” of the document in the menu. Print CSS so it looks right when you put it onto dead trees. Etc. etc.

My entire CV requires a quarter of the bandwidth of just the JavaScript of any of the handful of React-based ones I looked up. The mind boggles. I tried disabling JavaScript on a few of them (even if you believe “nobody uses the Web without JavaScript” – and you’re wrong – then you have to admit that sometimes JavaScript fails) and they did horrific things like not loading images or links not working, as if <img> and <a> tags were something that requires you to npm install html@0.9 before they work..

A simpler, faster, more-accessible, more-secure Web is possible. It’s not even particularly hard. It just requires a little thought. Don’t take a sledgehammer to a walnut: the best developers are the ones who choose the right tool for the job. Your résumé/CV is not a real-time backendless application on a post-relational-backed microservices architecture, or whatever’s “hip” this week. It’s a page that you want to be as easy as possible to read by the widest number of people. Why make life harder for you, and for them?

Coronavirus: what the hell do we do now?!

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Andrew provides an excellent summary of the current status of the coronavirus crisis with a focus on the endgame goals. As I watched this, his latest video, I kept writing half-finished comments about the deeper caveats of say vaccine development and the limitations of herd immunity if reinfection is possible… and right before I finished each, he answered them anyway. Sooo… I guess I have no comments. You should just go watch this.

Ted Chiang Explains the Disaster Novel We All Suddenly Live In

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

While there has been plenty of fiction written about pandemics, I think the biggest difference between those scenarios and our reality is how poorly our government has handled it. If your goal is to dramatize the threat posed by an unknown virus, there’s no advantage in depicting the officials responding as incompetent, because that minimizes the threat; it leads the reader to conclude that the virus wouldn’t be dangerous if competent people were on the job. A pandemic story like that would be similar to what’s known as an “idiot plot,” a plot that would be resolved very quickly if your protagonist weren’t an idiot. What we’re living through is only partly a disaster novel; it’s also—and perhaps mostly—a grotesque political satire.

What will “normal” look like after the coronavirus crisis has passed? Will it be the same normal as we’re used to? Or could we actually learn some lessons from this and progress towards something better?

I love Ted Chiang’s writing; enough to reshare this interview even though I’m only lukewarm about it!

Third-party libraries and security issues

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Earlier this week, I wrote about why you should still use vanilla JS when so many amazing third-party libraries exist.

A few folks wrote to me to mention something I missed: security.

When you use code you didn’t author, you’re taking a risk. You’re trusting that the third-party code does not have security issues, that the author has good intent.

Chris makes a very good point, especially for those developers of the npm install every-damn-thing persuasion: getting an enormous framework that you don’t completely understand just because you need  a small portion of its features is bad security practice. And the target is a juicy one: a bad actor who finds (or introduces) a vulnerability in a big and widely-used library has a whole lot of power. Security concerns are a major part of why I go vanilla/stdlib where possible.

But as always with security the answer isn’t so clear-cut and simple, and I’d argue that it’s dangerous to encourage people to write their own solutions as a matter of course, for security reasons. For a start, you should never roll your own cryptographic libraries because you’re almost certainly going to fuck it up: an undetectable and easy-to-make mistake in your crypto implementation can lead to a catastrophic cascade and completely undermine the value of your cryptography. If you’re smart enough about crypto to implement crypto properly, you should contribute towards one of the major libraries. And if you’re not smart enough about crypto (and if you’re not sure, then you’re not), you should use one of those libraries. And even then you should take care to integrate and use it properly: people have been tripped over before by badly initialised keys or the use of the wrong kind of cipher for their use-case. Crypto is hard enough that even experts fuck it up and important enough that you can’t afford to get it wrong.

The same rule applies to a much lesser extent to other parts of your application, and especially for beginner developers. Implementing an authentication/authorisation system isn’t hard, but it’s another thing where getting it wrong can have disastrous consequences. Beginner (and even intermediate) developers routinely make mistakes with this kind of feature: unhashed, reversibly-encrypted, or incorrectly-hashed (wrong algorithm, no salt, etc.) passwords, badly-thought-out password reset strategies, incompletely applied access controls, etc. I’m confident that Chris and I would be in agreement that the best approach is for a developer to learn to implement these things properly and then do so. But if having to learn to implement them properly is a barrier to getting started, I’d rather than a beginner developer instead use a tried-and-tested off-the-shelf like Devise/Warden.

Other examples of things that beginner/intermediate developers sometimes get wrong might be XSS protection and SQL parameter escaping. And again, for languages that don’t have safety features built in, a framework can fill the gap. Rolling your own DOM whitelisting code for a social application is possible, but using a solution like DOMPurify is almost-certainly going to be more-secure for most developers because, you guessed it, this is another area where it’s easy to make a mess of things.

My inclination is to adapt Chris’s advice on this issue, to instead say that for the best security:

  1. Ideally: understand what all your code does, for example because you wrote it yourself.
  2. However: if you’re not confident in your ability to implement something securely (and especially with cryptography), use an off-the-shelf library.
  3. If you use a library: use the usual rules (popularity, maintenance cycle, etc.) to filter the list, but be sure to use the library with the smallest possible footprint – the best library should (a) do only the one specific task you need done, and no more, and (b) be written in a way that lends itself to you learning from it, understanding it, and hopefully being able to maintain it yourself.

Just my tuppence worth.

idTech 4 WebAssembly port – Doom 3 Demo

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Doom 3 running in Dan's web browser

Back in 2011, some folks cross-compiled Doom (the original, not the reboot, obviously) to JavaScript, leveraging the capabilities of the then-relatively-young <canvas> element and APIs. I was really impressed to see that JavaScript had come so far and that performance on desktop devices was so slick. Sure, this was an 18-year-old video game, but it was playable in a browser, which was a long way from the environment for which it was originally developed.

Now Doom 3‘s playable in a browser, and my mind’s blown all over again. This follows almost the same curve – Doom 3’s 16 years old – but it still goes to show that there’s little limit to the power of client-side browser programming. They’ve done this magic with WebAssembly; while WebAssembly goes slightly against my ideas about the open-source nature of the Web, I still respect the power it commands to do heavyweight crunching tasks like this one.

How long until AAA developers start developing with the Web as an additional platform?