localghost

Good links: 18 February 2024

2024-02-18T00:00:00Z

The Midnight Pub - A tiny forum in the form of a virtual pub. It even has a speakeasy.
This website is personal - Frills - I really identify with this post, and the feeling that my posts aren’t worth anything if they’re not useful in some way. In reality there are no rules at all about what you should post on a personal site!
Don’t Disable Form Controls - Stop disabling submit buttons.
the top of the DNS hierarchy - TLD nameservers are well-known, but what about the very top level - the root? An in-depth look at the thirteen root DNS servers.
In Loving Memory of Square Checkbox - How are we supposed to tell the difference now?

Good links: 4 February 2024

2024-02-04T00:00:00Z

Please, don’t force me to log in - It feels like every website or connected device wants you to sign up before you can use it these days…
It feels like React is getting a bit of a kicking recently - Piccalilli - There's a lot of React criticism floating around at the mo, much of it justified. I think people are quick to use it when they don't need to. But as someone working on a very big, very complex project that does benefit from a framework like React, I'm glad Andy is taking a nuanced look at the debate.
A highly configurable switch component using modern CSS techniques - Piccalilli - We’ve all built plenty of switches out of checkboxes, I’m sure, but Andy has updated his technique to use some newer CSS features and produced a rather lovely result.

Listen to this: The Stand-In by Caitlin Rose

2024-01-30T00:00:00Z

At university I worked at Manchester Academy, and would often end up behind the bar at all sorts of gigs from pop, to metal, to folk. Metal gigs were always my favourite because the crowd were very nice to bar staff, whereas sometimes you'd have "POUR OUT CANS" written on the sign in sheet and you knew it was going to be rowdy.

Anyway, one of the gigs I ended up working at was Caitlin Rose, a country singer hailing from Tenessee. A tiny gig in our smallest venue, Academy 3, where I could lean back against the bar and watch quite happily. I'd never considered myself a fan of country (though a few years later I'd get very, very emotionally invested in the TV series Nashville, and in fact a song of hers did feature) but I was really taken by her witty and honest lyrics, and catchy refrains.

A few years later in 2013 she released this absolute dynamite record, The Stand-In, a vintage-flavoured record full of excellent writing, velvety vocals and heartbreak. If you don't like country, don't be put off: it's more kind of alternative country.

She then promptly disappeared for about ten years only to surface with a new album last year (Cazimi). But The Stand-In is still my favourite.

Top track: No One To Call is a short one, but a bittersweet plea from a lonely life on the road.

Good links: 28 January 2024

2024-01-28T00:00:00Z

Old'aVista - Altavista was my first search engine (or should I say altavista+was+my+first+search+engine) and this is a delightful trip down memory lane.
Inside .git - Legendary explainer of things Julia Evans has written a fascinating and understandable guide to what lives inside the .git folder.
CARI | Aesthetics - I shared this on Mastodon a while back but this is just so compelling, and some of these aesthetics come with a heady dose of nostalgia.
Where have all the websites gone? - A heartfelt lamentation for the human web.
Oh Hello Ana - Ana Rodrigues has posted a very comprehensive list of good tech and web-related links.

So you've decided to get into mechanical keyboards

2024-01-27T00:00:00Z

This is a dangerous path you're about to walk down. Is your wallet ready?

Whether you prefer the smooth glide of linear switches, the gentle bump of a tactile switch or the full-on audio assault of a clicky switch, there’s something extremely gratifying about typing on a mechanical keyboard (even if it’s just a reply to someone who is wrong on the internet). And it’s even better if it looks as adorable as this.

I’ll level with you: I got into mechanical keyboards because a) they’re so PRETTY! and b) it was the pandemic, what else was I supposed to do? I had been perfectly happy tapping away on my Apple wireless keyboard for a very long time. But I really do prefer them now, and find that I’m much less prone to wrist strain than I was with the extremely flat profile of the Apple keyboard. Sure, I could have bought a Logitech keyboard that’s a bit fatter and be done with it, but it wouldn’t look like this:

I’ll continue to level with you: it is not a cheap hobby. From the keyboard itself, to the switches for each key, to each keyset (the keys themselves, usually sold separately), the cost adds up quickly. The only positive I can offer is that by the time the keyset you ordered arrives, it’s usually been so long you forgot how much it cost you.

You’ll also need a lot of patience. Since it’s a pretty niche hobby, keyboards and keysets have to go through a few stages before they arrive at your doorstep: garnering interest to see if people want to buy it, presale, production and quality assurance, then delivery and distribution. This can take anywhere between a few months to over a year – in fact, one keyset I ordered back in 2021 has been so beset by production issues and delays that it still hasn’t arrived yet.

How mechanical keyboards work

Your average mechanical keyboard will have:

a case, made out of plastic or aluminium
a PCB (printed circuit board) with a USB connector (or Bluetooth if you’re fancy)
a controller that can translate those keypresses into input instructions for your computer
switches to trigger keypresses
keycaps for you to type on
stabilisers (aka stabs) for the longer keys so they don’t wobble

Keyboard switches complete a circuit in the keyboard which causes a specific keypress to be transmitted via the controller to the computer.

Switches have a plastic shell with a moveable plastic “stem”, the bit that the keycap attaches to and that moves up and down when you press it. There’s a metal spring inside to control that movement, and finally a metal plate with legs that protrude from underneath the switch which you either solder into the keyboard’s PCB, or slot into place on a hot-swap keyboard.

Hot-swap means you can remove and change switches without having to do any soldering, which is great if you want to try a few different kinds; but hot-swap PCBs are a bit less common – and more expensive – than regular ones.

Switches

Mechanical keyboard switches come in three categories: linear (smooth), tactile (bump), and clicky (exactly what it sounds like).

All switches have what’s called an “actuation point”, which is the point at which the keypress is registered. It’s usually when you press the switch about halfway down. While linear switches don’t give any feedback that you’ve reached the actuation point, tactile switches will have a bit of resistance or a “bump” that lets you know you’re there, and clicky switches make the click sound at that point. Some people like this because it means you don’t have to push the keys all the way down.

It’s completely down to personal preference here: I like linear switches, as I actually prefer my keyboards to be as quiet as possible. If you’re intending to bring your keyboard to a place where other people are working, please don’t buy clicky switches unless you want to find your expensive new keyboard mysteriously covered in tea.

Mechanical vs optical switches

Standard mechanical switches trigger when the stem is pushed down, causing the metal leaf at the bottom of the switch to connect, completing the circuit. Optical switches have springs too, but these have a light signal inside them which registers a keypress. There aren’t quite as many optical switches out there but there isn’t a lot of difference between the two types, it’s just a newer technology.

Cherry MX switches and their colours

You’ll hear people talking about red switches, brown switches, blue switches... this relates to the colour of the stem in Cherry MX switches. These are one of the most popular shapes of switch, and lots of manufacturers make them other than Cherry MX – I tend to buy Gateron as they’re a bit cheaper.

The colours tell you what kind of switch it is:

red: linear, light resistance, relatively quiet
black: linear, heavy resistance, relatively quiet
brown: tactile, moderate sound, medium resistance
clear: tactile, moderate sound, heavy resistance
blue: loud, clicky, medium resistance
green: very loud, clicky, heavy resistance

Gateron red and brown switches

There are lots of manufacturers and limited runs of this switch shape with different colours and actions, and it can get quite overwhelming, but you can just stick to the normal colours!

If you’re not sure what colour you want a lot of places sell a switch tester with a few different colours in so you can get a feel for what you like most.

Which colour you buy is entirely up to you, it’s based on personal preference. What does matter is what shape of switch you buy, and this will usually be specified on the keyboard/PCB listing.

There are other types of switches e.g. low profile switches, but the majority of keyboards and keycaps that I’ve seen are made for the Cherry MX profile.

Keyboards

The keyboard itself can come in lots of different shapes and sizes. You didn’t think this would be simple, did you?

You can buy keyboards as kits ready to be assembled (you'll need some tiny screwdrivers and a soldering iron), or prebuilt. Some places offer assembly service for you, though I think assembly is half the fun!

Keyboard size and shape

Your regular rectangular keyboard can have any number of keys, and some limited edition ones have a truly bizarre layout. I recommend the Switch & Click keyboard size guide for an overview of the most common ones.

When it comes to choosing a size, think about what’s important to you. Do you use the numpad? Better get a compact or a full-sized one. Do you need the F-keys (go 75% or larger) or will you be all right with using a function key and the num row (60-65% will do)? Do you like pain (a 40% is for you)?

I have a KBDFans Tofu84 (75%) at work, and an ikki68 (65%) at home. The F2 key gets a lot of use at work when I’m renaming variables!

KBDFans Tofu65 with DSA Magic Girl keycaps

Then there’s the split keyboards, literally split down the middle and connected by a cable. They’re meant to be really great for wrist strain, much better for you posture-wise, though I haven’t tried one myself as I don’t have the energy to re-learn to type. They’re also excellent if you want to look like you come from, or travel regularly to, space.

Photo by Peppy Toad on Unsplash

Joking aside, they are supposed to be much better for you. A popular ergo keyboard is the Ergodox, which is actually open source: you can download the files for the PCB from GitHub and get it printed yourself, sourcing whichever compatible parts you like (or 3D printing them). There are also a lot of kits or pre-made versions if you prefer.

Then there's macropads, tiny and adorable mini keyboards that are a great way to get used to building keyboards if you don't have much experience soldering. I've got a keeb.io BDN9 and a mint-coloured Owlab Voice Mini which is the cutest thing. They both have rotary encoders (knobs) on them which make them 100% more satisfying, but unfortunately I keep forgetting what I've programmed the keys to do so I find I rarely use them.

BDN9 with DSA Milkshake keycaps

Keyboard layouts: ISO, ANSI, JIS, ortholinear

The most common keyboard layout I’ve seen is the ANSI layout, which is the standard keyboard layout in the US. It’s characterised by its flat enter key, longer shift key on the left, and extra key above the enter key.
ISO is generally used in Europe, and has a delightfully chunky enter key that’s two rows high, with a smaller left shift key (two keys where ANSI has one).
JIS is the Japanese International Standard, and has an extra key next to backspace, an ISO-style enter key, and a smaller right shift key.
Mechkeys has an article about these common layouts, including some diagrams.

I know plenty of folks in Europe who use ANSI layout simply because the keyboards are more common, but I much prefer ISO. Generally, keyboard kits and PCBs will say which layouts they support; often they support multiple configurations so you could even mix and match, say, an ISO enter key and a US-style left shift.

Finally we have the ortholinear layout. These are quite amazing looking, a bit like a long Boggle. Unlike regular keyboards which have staggered rows, the keys are all aligned in a grid. Read more about ortho keyboards on Try Ortho Keys.

Typing angle

Perhaps a minor one, but this may make a difference to you; different keyboards are set at different angles, and unlike your 2001 Compaq keyboard most of these mechanical ones don’t have those little fold-out feet that you snapped off while waiting for the dialup to connect. Most keyboard listings will tell you the typing angle.

Dampening sound

If you’re like me, you want to minimise the sound from a keyboard as much as possible, especially in the office. There are a few ways of doing that:

use quieter switches (red, black)
use silent switches (NB these are quieter, not actually silent)
put O-rings on your keycaps (I got some cheap off eBay)
line your case with foam to absorb sound
put a desk mat underneath your keyboard

Keycaps

The most exciting bit, I reckon. The bits with the letters on that are prettier than they have any right to be. You can get retro ones, cute pastel ones, dark ones with light writing... the possibilities are endless.

Some of my favourite keysets of recent years:

DSA Milkshake
ePBT Dreamscape
KAT Space Dust (this has been delayed forever, bah)
Mintlodica Pastel Dreams

Render of Dreamscape keycaps from vala.supply

Kits

Keycaps will usually have different kits on sale, so check the listing carefully to see what each one contains. You'll definitely want to get the base kit (with all the alphanumeric keys and ANSI keys). Sometimes you have to buy the ISO kit separately for the big enter key and some Europe-specific keys like the UK 3 (# and £). Often sets will do a novelties kit: Milkshake had a set of pastel-coloured keys with fruit legends, and Dreamscape has novelties with stars, clouds and meteors. I always enjoy the novelties.

Materials

Keycaps are generally plastic, except for the occasional novelty one. They’re either made of PBT or ABS; PBT is nicer but ABS is cheaper. The sets you get with your off-the-shelf keyboard, or off AliExpress, are probably ABS. It’s more flexible, but the legends can wear off the surface of the keycaps.

Additionally, keycaps may be “double shot” (two layers of plastic, one for the lettering and one for the overlay).

Keycaps can come in a variety of different profiles, and may be flat (all one height) or sculpted (different rows have different heights). Different profiles have different heights. Generally I’m not fussy about profiles, I just accept whatever profile they’ve chosen for the keyset I’m after.

Check out The Keeblog’s article about different keycap profiles for a full overview.

Key sizes

The keys themselves are measured in units (u): your average letter or number key is 1u wide, and everything else is relative to that. Most keysets will come with various different lengths for backspace, shift and caps lock keys which you might use depending on the layout of your keyboard. Some folks like a split spacebar; this is a must if you’ve got a split ergonomic keyboard, as you’ll need one on each side.

Check out Keyboard University’s guide to keycaps.

How to actually buy keyboards and keycaps

You can buy most switches in large enough quantities from wherever (even eBay), but many keyboards or keycaps require a bit more effort.

The group buy process

Since it’s a niche hobby, there isn’t enough demand for all of these things to just be mass-produced. Many keyboards, and most keysets, will go through a process called group buy, where a certain number of sets need to be sold before production can go ahead.

Generally things will go through interest checks (ICs) before this stage, to gauge how much interest there is in the first place. Designers will produce very lifelike renders of the proposed keyset or keyboard, and if there’s enough interest they’ll approach a manufacturer. There will be a minimum order quantity, so they’ll have to guarantee a certain number of sales before production can go ahead. Production generally happens in China, and takes many months (especially if there are lots of sets in the queue in front of it).

This is where the group buy phase begins. Various vendors around the world will agree to be the distributors for the set; this means you buy the set through the vendor, and the vendor in turn places an order for a certain number of sets from the manufacturer. The group buy phase has a limited time period, though usually there are no limits on how many units are available. A warning: generally there are no refunds on group buys because they need to guarantee the order quantity.

Once the group buy is over, production can begin. The factory will produce a sample set which will go back to the designer to see if they’re happy with it, and this can happen a few times until the designer is happy. Finally, it’ll go into full production, and eventually distribution. The sets will be shipped to the vendor and they’ll be in charge of shipping them to their customers.

Vendors should provide updates with how things are progressing, but there are often delays. Group buys generally have a ship date of a particular quarter rather than a specific month (e.g. Q3 2024) but this is subject to change.

Most vendors will have a list of upcoming and current group buys on their website; see “Where to buy” below.

If you missed out on a group buy, don't despair. Sometimes creators will do re-runs or new revisions of popular keysets/keyboards.

What to buy if you want it now

If you genuinely don’t care about group buys and want something right away (fair play), consider checking out a Keychron. It’s a solid choice and readily available. It definitely doesn’t fulfil the “pretty” requirement, but it’s nice to type on and won’t set you back as much as the custom ones. You can swap out the keycaps and many of them are hot-swappable.

A lot of keyboard retailers will have some keyboards and keysets in stock most of the time, including the “extras” that are additional sets they ordered from a group buy to sell on. These tend to go quite quickly, so if you missed a group buy make sure you pay attention to when the extras will be in stock and act fast.

Where to buy

There’s a very comprehensive list of keyboard vendors by Alexotos. My personal (UK) faves are Prototypist (for group buys) and Mechboards for in-stock kits and accessories. I buy switches from Mechboards or eBay.

If you're not sure about a vendor, check out one of the mechanical keyboard discord servers and ask around for reviews. I find people are generally pretty helpful.

As always, prepare to be hit by customs charges when ordering from abroad. That includes ordering from the EU to the UK (sob). Ordering from local vendors doesn't incur customs fees as these are shipped locally, though generally the customs charges will be factored into the group buy price.

Automated weekly links posts with raindrop.io and Eleventy

2024-01-22T00:00:00Z

Edit 04/02/24 to change the comparator date from midnight on previous Saturday to midnight on previous Sunday to prevent duplicate links being published.

A post that’s been getting a lot of traction recently is I miss human curation by Cassidy Williams, in which she laments that we’re so reliant on algorithms to show us new stuff now, instead of having it recommended to us by other humans.

Inspired by that, I decided to start posting weekly collections of posts and links I liked that week. Knowing I wouldn’t keep it up if I had to manually post it every week, I set about finding a way to automate it. How could I mark a link or blog post as “good”, and have it show up in my blog on a Sunday without me having to do anything?

It occurred to me that I’m already paying for raindrop.io, an excellent bookmark manager. It’s a great way of keeping links in sync across multiple platforms... and it has an API! This meant I could add links to a particular raindrop.io collection as I come across them, and then fetch them once a week and turn them into a post.

Collecting the links

I’ve created a separate raindrop.io collection for these links, which I can easily share to from the iOS share sheet, or from the Firefox extension. When I save the bookmark, I also add an accompanying note with a sentence or two about the link.

I generated an API token for raindrop, and wrote a little script to pull the links from the collection using the /raindrops/[collectionID] endpoint.

I made sure to only fetch links from the past week so I didn’t duplicate anything. You can pass specific search parameters in the query, so I restricted the links to any created after midnight on the previous Sunday, and before midnight on the current day - so, Sunday to Saturday. That means any links I clip on the Sunday will appear in the following week’s link post.

const todayDate = new Date();
const lastSunDate = subDays(todayDate, 7); // using date-fns here
const lastSun = format(lastSunDate, "yyyy-MM-dd");
const today = format(todayDate, "yyyy-MM-dd");

async function fetchLinks() {
  // Get content bookmarked between last Sunday and this Saturday inclusive
  const search = new URLSearchParams({
    search: `created:>${lastSun} created:<${today}`,
  });
  const url = new URL(`https://api.raindrop.io/rest/v1/raindrops/${collectionId}`);
  url.search = search;
  const rsp = await fetch(url, {
    headers: {
      Authorization: `Bearer ${token}`,
    },
  });
  return await rsp.json();
}

Creating the post

Once I’ve pulled the links, I need to turn them into an actual markdown post. I’ve created a very simple template that I can inject content into:

---
date: {{date}}
---

{{links}}

Using my method for creating post types, I've added a new link type which has its own shared config. I'm using a couple of custom date filters to get the dates in the right format for titles and URLs.

{
  "layout": "single-post.njk",
  "hasCustomOGImage": true,
  "eleventyComputed": {
    "title": "Good links: {{ date | dateFilter }}"
  },
  "excerptText": "Links to posts and websites I've enjoyed this week, curated and automated.",
  "type": "link",
  "tags": [
    "links"
  ],
  "permalink": "/blog/good-links-{{date | urlDateFilter }}/index.html"
}

I format the links into markdown, defaulting to raindrop’s excerpt if I didn’t write a note:

const formattedLinks = raindrops.map((raindrop) => {
    const { link, title, excerpt, note } = raindrop;

    const description = note === "" ? excerpt : note;
    return `* [${title}](${link}) - ${description}`;
  });

Then I read the template as a string, interpolate the date and links I’ve just formatted, and write them to a file in my blog directory with the date as a filename.

  let postContent = fs.readFileSync("./scripts/link_template.md", "utf8");
  postContent = postContent.replace("{{date}}", formattedToday);
  postContent = postContent.replace("{{links}}", formattedLinks.join("\n"));
  fs.writeFileSync(`./src/blog/links/${formattedToday}.md`, postContent);

Scheduling the script

Running the script is easy enough: I added it into my package.json scripts as yarn generate-links. But I’d like to not even have to think about running it and have something do it for me.

It made sense to use GitHub Actions to run it on a schedule. I already deploy my website twice a day automatically so that new webmentions are fetched regularly.

I randomly entered numbers into crontab.guru until it came out with “every Sunday at 6pm”, and then created a new workflow:

name: "Generate and publish weekly link post"
on:
  schedule:
    - cron: 0 18 * * 0
jobs:
  generate-post:
    name: "Run script to generate post"
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v3
        with:
          node-version: "18"
          cache: "yarn"
      - run: yarn install
      - run: yarn generate-links
        env:
          RAINDROP_TOKEN: ${{ secrets.RAINDROP_TOKEN }}
          RAINDROP_COLLECTION_ID: ${{ secrets.RAINDROP_COLLECTION_ID }}
      - uses: stefanzweifel/git-auto-commit-action@v5
        with:
          commit_message: Generate weekly link post

I'm storing the raindrop.io token and collection ID in the repository secrets.

My script generates a new .md file with the post, so I need it to commit and push the changes. For this I used git-auto-commit-action. It detects changed files during a workflow run and commits and pushes them back to the repo.

My deployment workflow listens for the link creation workflow to complete, so once this workflow finishes running and pushes the changes, the deployment one will kick off and deploy my new blog post. Magic!

# deploy-neocities.yml
name: "Deploy to Neocities"
on:
  [...]
  workflow_run:
      workflows: [Generate and publish weekly link post]
      types:
        - completed

Good links: 21 January 2024

2024-01-21T00:00:00Z

The Internet Is Full of AI Dogshit - Aftermath - How AI-generated content is ruining search engines for everyone.
Exposed RSS - I get sites not having an “RSS” for “Feed” link on their website while actually having an RSS feed. I don’t like it, but I get it. Maybe they picked an off-the-shelf t…
You should blog | keith.is - Keith calls out for folks to make this the year of blogging about whatever the hell you want. He’s suggested some great places to get started!
Layers of context. - Will Larson on the importance of thinking outside of your immediate context: why a change that seems like a great idea may not be so well received elsewhere in the organisation, and how you can get a better radar for these things.
Kind of annoyed at React - Cassidy Williams shares her frustrations about React, echoing some of the things I’ve been feeling recently.
SVG Filter Maker - SVGFM, a node graph builder for SVG filters
Sharing links - Hidde's posted about sharing links on his own blog as well - great minds think alike!

How I deploy my Eleventy site to Neocities

2024-01-20T00:00:00Z

Skip to the bit you care about:

I’ve hosted this website in a few different places since I started it in 2019. It started out on Netlify, but after my post about everything I googled went viral, I exceeded the bandwidth of the free plan. Then I moved it to Vercel, which (at least at the time) had more generous bandwidth on the free tier. I enjoyed very quick deployment speeds, but it gave me big Corporate Web vibes. Now I host localghost.dev on Neocities.

About Neocities

Neocities reminds me of everything I love about the old web. It’s a place for people to create bizarre, oddly specific websites for things they love, or random collections of digital trinkets they’ve found on their online travels.

The manifesto on their about page resonated with me:

We are tired of living in an online world where people are isolated from each other on boring, generic social networks that don't let us truly express ourselves. It's time we took back our personalities from these sterilized, lifeless, monetized, data mined, monitored addiction machines and let our creativity flourish again.

Hosting a static site on Neocities

Neocities offers free static site hosting, and (unlike the free hosts of yore) there are NO ADS. None. It’s been around for years, so it’s not going anywhere any time soon.

You can manually build your site and upload the assets via the web editor, if you want. However, I’d recommend using version control so that you can easily roll back changes, and move your site somewhere else if you need to. There’s a CLI tool and an API that make it much easier to upload new versions of your site.

The supporter plan allows you to use custom domains, gives you loads more storage and bandwidth, and allows as many sites as you want under the same account. It costs $5 a month, which really isn’t very much, and I’m happy to pay for it knowing that it’s supporting people creating websites for free and learning web development the same way I did.

Continuous deployment to Neocities with Github Actions

Like with Netlify and Vercel, I wanted to be able to set up a pipeline to automatically deploy my site when I pushed to the main branch. I’ve used CircleCI in the past, but I wanted to use Github Actions as it’s just... nicer.

I was very excited to discover that there’s a GitHub Action for deploying to Neocities by Bret Comnes! It uses the Neocities API under the hood, so you need to create an API key.

You can do this via the API (this example is from the API docs):

$ curl "https://USER:PASS@neocities.org/api/key"
{
  "result": "success",
  "api_key": "da77c3530c30593663bf7b797323e48c"
}

Or you can create a new key from your site settings page at https://neocities.org/settings/<your username>#api_key.

Once you’ve got the key, store it in your repo’s actions secrets. Head to your repo’s settings page, and open “Secrets and Variables” > “Actions” under the “Security” heading. Create a new repository secret called NEOCITIES_TOKEN and set its value as the key you just created.

If you don’t have any other GH Actions workflows set up, you’ll need to create the .github/workflows directory. In here, I’ve got a workflow called deploy-neocities.yml.

I’ve added some comments to show you what each bit does.

name: "Deploy to Neocities"
on:
  push:
    branches:
      - main # run this job when I push to main
jobs:
  deploy:
    name: "Deploy to Neocities"
    runs-on: ubuntu-latest # the system the runner uses
    steps:
      - uses: actions/checkout@v4 # checkout the repo
      - uses: actions/setup-node@v3 # install node.js
        with:
          node-version: "18"
          cache: "yarn" # I'm using yarn rather than npm
      - run: yarn install # install dependencies
      - run: yarn build # build my project
        env: # the env vars I need to build my site
          WEBMENTION_IO_TOKEN: $ 
      - uses: bcomnes/deploy-to-neocities@v1 # deploy!
        with: # config for the action
          api_token: $
          dist_dir: "_site/" # my build output directory
          cleanup: true # delete anything on neocities that's not in my dist_dir

The workflow runs every time I push commits to the main branch.

The environment variables you need for the yarn build step will vary, and you might not need any at all.

You will need the NEOCITIES_TOKEN for the deploy-to-neocities action, which we pass in here as the api_token param.

The default value of the cleanup param is false, and I had it set to that for ages, but then I realised that if I accidentally published a post and unpublished it by setting it back to draft, it wouldn’t delete the built post on Neocities. So even if it wasn’t linked from the site, the page itself would still be hosted there. I’ve since set cleanup to true so it removes any files from Neocities that aren’t in my newly built site output.

Once you’ve got that workflow file finished, commit it and push it to your repo. GitHub will pick it up, and start running it automatically depending on what you told it to do. I find it goes pretty fast – my site deploys in about 30s.

Scheduling builds

Branch pushes aren’t the only triggers for workflows! You can have time-based triggers as well, using cron, the scheduling tool.

For example, I automatically rebuild my site at 8am and 6pm every day to fetch the latest webmentions (there’s a script that runs every time the site is built).

on:
  schedule:
    - cron: 0 8/9 * * *

I recommend crontab.guru for help with cron syntax.

Sending webmentions from a static site

2024-01-20T00:00:00Z

It occurred to me this week that even though I’ve been using webmentions as comments for a really long time, I hadn’t actually been sending them myself. The shame! Here's how I set it up.

Edit 22/01/23: I've added in some checks to make sure I don't send webmentions for a post if I've already done it before.

Certified good egg Remy Sharp has a tool called webmention.app which will send webmentions for you – you CURL it with the URL of your post, and it’ll search through it for any links and check to see if the owners of those sites have webmentions or pingbacks set up. There’s also an npm package, @remy/webmention, which you give an RSS feed and it does the same thing. That’s the version I’ve used.

You can add it as the postbuild script in package.json, so it’ll run after every yarn build.

"scripts": {
    "postbuild": "webmention _site/feed.xml --limit 1 --send"
},

I was concerned that if my build runs every 12 hours, it’ll keep sending webmentions for the same posts. Remy assures me that duplicate webmentions aren’t an issue, as the accepting server will just respond with a 200 if I send a webmention that it’s already seen. However, if you build your site very often you might be at risk of nearly DOS-ing the websites you're sending mentions to. To get around this, you could:

write a script that runs the webmention CLI but only after checking the post timestamp of the last post to see if it's recent enough
keep a record somehow of the last post you sent webmentions for, e.g. in a text file in the repo
check the message from the last commit and only send the webmentions if you mention "new post" or similar

To be super safe, I've added it as a script in package.json but I'm calling it from within a bash script that checks the commit hash for the last commit, and records whether or not I've sent webmentions for that commit already.

#! /usr/bin/env bash

if ! test -f ./last_webmentions_commit; then
  echo "Last webmention commit file not found, exiting"
  exit 1
fi

# Read the contents of the file
LAST_COMMIT_SENT=$(cat ./last_webmentions_commit)

# Get latest commit hash
LATEST_COMMIT=$(git rev-parse --short HEAD)

# If the last commit hash I sent webmentions for is
# the same as the latest commit hash, exit
if [[ $LAST_COMMIT_SENT == $LATEST_COMMIT ]]; then
  echo "No new commits since we last sent webmentions, nothing to do"
  exit 0
fi

# Get the last commit message
LAST_COMMIT_MESSAGE=$(git log -1 --pretty=%B)

# Does the commit message contain 'post'?
if ! [[ $LAST_COMMIT_MESSAGE == *"post"* ]]; then
  echo "Last commit message does not contain 'post', nothing to do"
  exit 0
fi

# Update the file with the latest commit hash
echo $LATEST_COMMIT > ./last_webmentions_commit

yarn send-webmentions

When I write a new post, I always use the word "post" in the commit message, so this will help distinguish which commits we need to send webmentions for.

Now, every time I build and deploy my site, the script will send webmentions to anyone I’ve mentioned in the last post I wrote, as long as I haven't already sent webmentions for that post and the recipients have the webmention meta tags set up!

Just because you can doesn't mean you should: the element

2024-01-07T00:00:00Z

I came across Sara Joy's (very cool) demo of CSS theming without classes today, and looking through the code spotted a couple of elements I hadn't come across before: <progress> and <meter>. Granted, I've probably seen the <progress> element plenty of times, but I struggled to see what the <meter> was for.

While <progress> is fairly self-explanatory – it shows how far along something is, such as your progress through a form – the <meter> element was less obvious to me, so I had a look at the MDN page to see what they suggested.

This is a prime example of following the letter, not the spirit, of semantic HTML. Yes, technically the cooking temperature is somewhere between the lowest and highest temperature you can set the oven to, but is this actually helping people understand the recipe? Quite the opposite, it's making the recipe less accessible for anyone not using a screen reader.

Now, chances are the person who wrote this article simply couldn't think of a better example, and isn't necessarily proposing that everyone starts using meters instead of numbers in their recipes, but a lot of developers rely on MDN to tell them what is good practice, so I don't think this is particularly useful. (I'm going to try and contribute a better example.)

Inspired by this, and with a burning desire to build something truly terrible, I've created this recipe page using the <meter> element for every numerical value.

See the Pen CodePen Home A recipe, but all the numbers are bars by @sophiekoonin on CodePen.

The spec has a few more sensible examples, though I'm not entirely persuaded that a meter is a good illustration of newsgroup activity.

A more tangible use case for the <meter> element would be to indicate something like available storage space, or percentage of remaining budget on a service where your plan only allows you a certain number of events or entities: an example of this would be Sentry, where your plan has a limit to the number of events/errors it'll accept, depending on how much money you throw at them.

The key UX thing here, though, is that if it's important information it should be accompanied by a numerical value. A meter is good for an at-a-glance sense of how much of something has been used, but you need to present it alongside the actual value for it to be at all useful.

I checked both Dropbox and Google Drive, and both of them have a meter accompanied by a numerical description of how much space I've used; in both cases those meters are, of course, <div>s. Usually I'd complain about using a <div> when there's a semantic element available, but... it's not immediately clear to me what the advantage of using a <meter> would be from an accessibility viewpoint, if you've got the written description right there.

When you're choosing the right element for the job, it's entirely possible to go too far the other way, and overuse semantic elements when actually they hinder more than they help.

As my good pal and accessibility specialist Helen put it:

It’s a really good example of thinking about what you’re trying to communicate and to who and whether your “semantic” choices actually enable that.

Remembering the early 00s teen website scene

2023-12-30T00:00:00Z

localghost.dev has a new theme! In search of a little project over the merrineum that didn’t require me to learn anything and therefore use my brain, I remembered there was a stylesheet hidden in the themes directory of my website that I hadn’t finished. The theme: teenage personal websites in the early 00s. It was a lot of fun to build, and really nostalgic to recreate the websites of my youth. Think impossibly tiny fonts, blocky layouts with a sidebar full of assorted crap, and grungey photoshop brushes. (But this time with CONTAINER QUERIES.)

Try out the new theme by clicking the scribbly heart in the middle of the theme switcher.

I touched on this era of my online past in my talk “This talk is under construction: a love letter to the personal website” from FFConf 2022. Rachel White also wrote an excellent post about this topic back in 2016 called Keep The Internet Weird, and even gave a talk about it at JSConf EU 2017. This quote from her article particularly rings true for me:

I can still remember spending hours on the Internet scouring free resources created by other teenagers for really great grunge brushes to create the best layouts that represented me at that point in my life.

One of Rachel's sites, circa 2003

I've recreated some of this magic in the new theme, complete with the stupidly tiny content box that scrolls, and the font that you have to squint to read.

All of this has me reminisicing about my adventures building websites as part of this early 00s scene, so I thought I'd share some of those memories.

TLD is everything

If you were going to have a domain name, you had to have the right TLD. For some reason .org and .nu domain names were really fashionable. I remember sites with names like partly-cloudy.org and lipsofpink.org.

Of course I never had a domain because my parents wouldn’t pay for it (very reasonably), so I had to do the next best thing: be hosted on someone else's website who was cool enough to have a domain.

Since the webmasters of the early 00s let these domain names lapse a long time ago, there’s very little evidence of this scene on the internet. Google searches for “2000s teenage blog scene” come up with a lot of “Y2K” inspired tumblrs and reminiscences of the actual scene subculture, something entirely different. There’s the occasional Reddit post where someone asks “hey, does anyone remember...” and there will be one person who does, and everyone else just remembers LiveJournal (everyone remembers LJ).

Thank goodness for the Internet Archive and its Wayback Machine, which has snapshots of many of these sites. Sadly a lot of the images aren't there, so you can't experience the full, over-the-top glory of the layouts. Hopefully the new theme on this site will give you a taste of what it was like.

I had three different hosts over a few years, and slices of those sites are still findable on the Wayback Machine, so you can be assured I won't be telling you what those domains were in the interests of self-preservation (translation: it's too embarrassing).

It's been a stark reminder of the importance of digital archiving, finding all of these sites incomplete in some way: content missing, stylesheet missing, images missing. With every site, there’s probably going to be a point where you don’t want to renew the domain name any more, or the host itself disappears. It’s really important that you have some kind of backup of the content, not only in text format but visually as well: the Wayback Machine has only captured snippets of my old sites, and often the images and stylesheets don’t work. I’d give anything to see full screenshots of what some of those sites looked like.

This is my space, but here's something for you

Blog posts – annotated with the music you were listening to while writing, of course – would be little windows into your everyday life. I remember reading some older teenagers' blogs, especially those in the States, and thinking how extremely cool they seemed. Driving! Relationships! Life that didn't revolve around exams!

The homepage would always be the blog (splash screens were passé by this point), but there would always be a page about the site's owner, then a page of things for the visitor such as downloadable graphics, Photoshop brushes or HTML snippets to use on your own site.

Something that was particularly great about this scene was that there was a real sense of community, both literally with the networks you formed with other bloggers, but also through helping other people be a part of it by teaching them HTML skills. We'd all make friends and comment on each other's blogs and link to our friends' and fellow hostees' sites, most of whom were people that we'd never even met.

Most importantly, though: a lot of these websites were run by teenage girls and young women. It was a space on the internet for marginalised people where we could be ourselves, whether under a real name or an alias. Our families wouldn't find it, and IRL friends wouldn't either unless you gave them the URL of your site, so the like-minded audience that you had was very small and controlled as well. It felt like a really safe space to be yourself. None of the carefully curated content feeds that you get on social media these days (or even blogs these days, a lot of the time).

At the time, I was pretty unpopular at school, in part because I was such a computer geek (it was very much Not A Cool Hobby) and I used to spend breaks at school working on my website in the IT room. The group of friends I fell into – who I'm still very close with today – were all like-minded geeky types with our own websites. Seeing and interacting with these older teenagers online with these fancy domains and cool layouts made me feel like I was part of something and that my interests were actually socially acceptable.

Of course, joke's on all the people who thought I was uncool, because now I'm so cool that I have a domain name that I need to explain to everyone who isn't a developer every time I give someone my email address.

Version 17

I’d happily fire up FileZilla and FTP into my server, set up Greymatter or later Wordpress, and spend hours after school building layouts for my website, and my friends’ websites. Later I learned some very basic PHP so that I could include layout headers and footers on separate pages of my website, and even make the footer copyright date dynamic instead of just hard-coded.

We’d change the layouts on our sites very frequently – once a month or even more often – and keep track of which version we were on in our site sidebar. Layouts were usually a main bit and a sidebar, first with tables and later with absolutely positioned divs; every layout featured a large header image composed of a transparent cutout PSD of some band or celebrity with the obligatory grunge photoshop brushes on top. I have a handful of my later header images saved, but most are lost to time.

There were websites offering cutouts of celebrities from magazine scans and photoshoots; I’d make header images in my cracked version of Paint Shop Pro with whatever PSDs I could get my hands on, regardless of how much I actually liked that celebrity. That’s how I ended up with layouts featuring such gems as, er, Paris Hilton or Gwyneth Paltrow.

Over time, tiny scrunched-up scrolling box layouts were replaced by full-page ones, still clamped to the left hand side of the browser, but with even more room in the sidebar for fun things.

Website tsatskes

Another thing I miss from early websites is the random tsatskes you'd accumulate from around the web and display proudly on your homepage, and these websites were no exception. You might have fanlistings for things you love, links to cliques you’d joined, or 88 x 31px buttons linking to other websites.

Those of us on PHP-enabled servers might have some codegrrl scripts like PHPCurrently, a customisable list of what you were doing at any given point in time. I mentioned this in my post about APIs for things and I can only apologise for this absolutely awful example of what I was like as an Evanescence-obsessed teenager in 2004:

Or maybe PHPCalendar with mundane events from your life:

The end of an era

I think it was ultimately LiveJournal that killed off this scene – well, that and Myspace, probably. I moved to LJ in about 2005, and was already a late adopter. It offered a customisable blog linked to infinite user-run communities, so you didn’t have to build your own network of friends, and ultimately the experience was very similar and didn't require paying for a domain. All your friends’ posts appeared on your Friends Page, so you didn’t need RSS and you could comment on everything right there.

Of course, websites don't really carry the same weight as they did back then. The way we experience the internet is very different, not only for those of us who have seen it change, but even more so for the younger generations who've grown up with endless short form video. Perhaps the current Y2K aesthetic trend will lead teens to rediscover the joy of building blogs and learning web dev skills as they trace the digital footsteps of us crusty millennials.

🎵 avril lavigne - don't tell me

A good podcast: Twenty Thousand Hertz

2023-12-24T00:00:00Z

Everything you've ever wanted to know about sound, and things you didn't know you wanted to know but are glad you learned, such as:

why all film trailers sound the same with that deep "booj" noise
how NASA ran live audio from the Moon
how the language in The Sims came about, and the people who voice it
the history of Windows startup sounds
the Loudness Wars, aka the reason so much popular music from the last few decades is just badly mastered

An additional treat is the Mystery Sound competition they run every episode, where they play a snippet of an obscure (or sometimes very familiar) sound, and listeners can submit their guesses. Everything from the Gracie Films tag at the end of the Simpsons, to herring farts. Every year they do a Mystery Sound Game Show episode, and this year's is hilarious. There are some sounds in there that will no doubt trigger Pavlovian reactions for anyone listening.

2023: The year in lists

2023-12-21T00:00:00Z

Last year's roundup post was good fun, so I decided I'd do another one this year! I feel like I blinked in April and suddenly it was December.

Skip to bits you care about:

The year in...

The year in...

...conferences

After a bumper conference year in 2022, I decided to rein it in a bit and did four conferences this year. Four is a good number and a lot more doable than seven. I also attended a few on top of that.

In April, I spoke about personal websites at the incredible Beyond Tellerand in Düsseldorf. I also wrote about the experience. In fact, I loved it so much, I'm speaking at BTConf Berlin in 2024!
In May, I went back to All Day Hey in Leeds. I particularly enjoyed Jack Franklin's talk on Abstractions, complexities and off-ramps.
In June I spent my birthday at CSS Day in Amsterdam where I gave my personal website talk and got completely blown away by all the new features in CSS. Later in the month I attended StaffPlus at the Barbican, a very different experience from the usual kinds of conferences I tend to find myself at, but super useful for things I actually do day-to-day.
In July I found myself in Middlesbrough, in the North East, for Middlesbrough Frontend – where I gave the final form of my Virtual Piano talk (refined and perfected!) and witnessed the absolute joy of a local, supportive community. I also gained a pair of parmo socks.
At the end of August I travelled to Zurich for the first time for Front Conference, which was an absolute joy; onstage I built a website like it's 1999 wearing some very bright orange trousers, and experimented with sort-of live coding using inspire.js. Also a joy: travelling around the lake on a boat in the sunshine.
Back at the Barbican in October, for the glorious State of the Browser 2023. This year, Dave made everyone's conference badges out of floppy disks (you're a legend Dave), and I got a special red one as the backup MC in case he was ill.
It's not a conference season without going down to Brighton for FFConf in November, and it was excellent as always <3

Attending lots of front-of-the-frontend conferences always makes me a little sad that I don't do much of that for a living – my job is a lot more around back-of-the-frontend, leading teams and building at scale. There's been a lot of talk this year about how React and other frameworks have ruined frontend development, and I don't disagree; but it's also something I use daily at work. The best thing I can do is make sure we're using it in a sensible way and defaulting to native browser capabilities where we can. (I've got a post in me somewhere about all of this.)

...travel

My holidays this year took me to Copenhagen with my mum, then later to Norway to visit family. We flew up to Ålesund and drove to Geiranger (our suitcase only made it as far as Oslo, but thankfully joined us the next day) and then flew back down to Oslo for a few days on my cousin's farm. It was wonderful to meet some of my family for the first time!

Geiranger

My annual lads' trip with some of my best friends was in the Cotswolds this year, where we stayed in a gorgeous farmhouse and went to WWT Slimbridge to gawp at some excellent waders. We saw a rare goose that had got blown off course and across the Atlantic during its seasonal migration across North America, but it seemed to be happy enough amongst the local geese.

WWT Slimbridge, looking out over the Severn estuary towards Wales

Excellent duck action at Slimbridge

...books

I continued to make extensive use of my library's ebook service. I tend to only read in bed, which means I often manage about 3 pages before conking out.

Tomorrow, and Tomorrow, and Tomorrow: there probably isn't anyone left who hasn't read this book, but it's really excellent. A story of two children who grow up to build video games together.
Feet of Clay - Terry Pratchett: continuing my Pratchett education with the City Watch series, this one about murders and golems.
There There - Tommy Orange: a stark tale about a community of Native Americans in California, the legacy of oppression and colonialism.
Raven Black - Anne Cleeves: lighter reading perhaps, but not too light, there's plenty of murder; the first of the Shetland series that inspired one of my favourite BBC dramas.
My Year of Rest and Relaxation - Ottessa Moshfegh: a very depressed woman tries to hide from the world and sleep for an entire year.
Mr Penumbra's 24-hour Bookstore - Robin Sloan: An unemployed software developer gets a job at a strange bookshop and discovers a secret society hidden within.
A Woman - Sibilla Aleramo: from 1906, an autobiographical novel of the author's troubled childhood growing up in Italy, her unhappy marriage to her abuser, and her decision to leave.
Soul Music - Terry Pratchett: more Pratchett! It's like a hug for your brain! In this one, Ankh-Morpork discovers rock music.
The Four Winds - Kristin Hannah: poverty and struggles during the Great Depression and Dust Bowl in the Great Plains.
The Anomaly - Hervé le Tellier: I love a good sci-fi mystery. A plane inexplicably duplicates itself during a storm, and every passenger now has an exact double.
Making Money - Terry Pratchett: the second Moist von Lipwig/Ankh-Morpork industrialisation book. Sadly I didn't make it all the way through the third one.
Sea of Tranquility - Emily St.John Mandel: from the author of Station Eleven, a sci-fi story about a rift in time with an unravelling mystery. The ending was rather abrupt, but the story itself was great.
I also read another book of hers called The Glass Hotel, about the aftermath of a Ponzi scheme.
The Bandit Queens - Parini Shroff: a widow in an Indian village helps another woman kill her abusive husband and Events ensue. It's dark but also really charming and quite funny.

...podcasts

New to me in 2023:

If Books Could Kill: Michael Hobbes and Peter Shamshiri take us through some of the biggest "self-help"/pseudoscience books from the last few decades and deservedly tear them apart. I can't recommend this enough.
Dungeons and Daddies: a Dungeons and Dragons-but-also-not podcast. I'm working my way through season one, which is about "four dads from our world flung into a land of high fantasy and magic in a quest to rescue their lost sons". It's one of the funniest things I've ever listened to and I'm completely hooked.

...music

According to my Apple Music Replay (aka Spotify Wrapped ripoff) I actually didn't listen to a lot of music this year. It checks out, as I've been mainlining podcasts on my commute, and I don't listen to much while I work apart from the odd bit of lo-fi. Some good things came out this year, though.

Carly Rae Jepsen - The Loveliest Time: CRJ has a tradition of releasing a companion album for every album she releases, and this is a great one. Standout tracks include the Daft Punk-esque Psychedelic Switch, and Kamikaze.
Speak Now - Taylor's Version: I was honestly surprised how much I liked this album, given that Speak Now was always my second least favourite TS album (least favourite is the self-titled one). The maturity of her voice suits the songs so well, and I love the one she did with Hayley Williams (Castles Crumbling). Haunted is one of my favourite Taylor Swift songs, as well, so it was great to hear the re-record. I had high hopes for the 1989 re-record because that was always my favourite, but I think I actually liked this one more.
GUTS - Olivia Rodrigo: This would have completely passed me by had I not listened to an episode of Switched On Pop where they talked about two tracks from this album, vampire and bad idea right?. Boy, are these fucking great pop songs, and I can't resist a great pop song.
Evanescence - Fallen 20th Anniversary Edition – after spending years embarrassed that I was really into Evanescence as a teenager, I've come out the other side and you know what, this album slaps. It's just excellent. Now I'm at the age where 20th anniversary editions start coming out for some of the albums that shaped my teenage years, which is utterly ridiculous, but the good news is that they sound great because a lot of the mastering was a bit trash in the early 00s.
the record - boygenius: Julien Baker, Lucy Dacus and Phoebe Bridgers come up with some really glorious harmonies which is a sure way to get me on board. I'm not so much of a fan of sad girl music so I don't tend to listen to their solo stuff or anything but I really loved some of the tracks off this album. Not Strong Enough is a standout.

Regretfully (especially after last year's glowing recommendation) I cleared any trace of Rammstein and associated acts out of my music library following some really dreadful accusations. I really enjoyed their music, but I couldn't really justify listening to it any more given how fucking creepy and problematic the singer is. The investigation was dropped due to lack of evidence, but there have been enough stories that came out to make me feel uncomfortable about the whole thing regardless.

...video games

Another great year for games! I also wrote up a list of my favourite games, some of which were new to me this year.

The standout for me and basically everyone else was Baldur's Gate 3. I'm 2/3 through my second playthrough; first run I played a Druid, second time is a Dark Urge playthrough. I thought I'd be evil but it turns out I'm incapable of making questionably moral decisions even in video games. I still got to romance Astarion, though – and it's extra fun as the Dark Urge. I've sunk so many hours into this game and yet I always discover something I missed.

Other highlights from 2023:

Chants of Sennaar: It's a linguist's dream, a puzzle game where you have to decipher the languages of the civilisations around you through context and environmental clues. It's also really beautiful. One of the most unique puzzle games I've played - I actually played this with my husband, solving puzzles together, and it was very wholesome.
Alba: A Wildlife Adventure: you play a young girl visiting her grandparents on a Spanish island, who gets together with her friend to start a campaign to save the island's wildlife. It's so wholesome and the fauna is very accurate — I spent far too long running around the island looking for teals and kestrels. It's a great gateway to real life birdwatching!
Disney Dreamlight Valley. Yes, really. I don't even like Disney that much, it wasn't a huge part of my life growing up and I haven't seen half of the films (not even the Lion King, which always shocks people when I say that) but the game is basically Animal Crossing with more expensive intellectual property, and it's been a lovely way to unwind. I'm currently in bed with sinusitis as I write this and I've absolutely been rinsing the game. Though it's firmly in the category of "games that make you wonder why the residents of this town don't ever fucking contribute". If you have Apple Arcade, it's just become available on there (though no cross save); I have it on Switch and the framerate is not great, so other platforms are probably better.
Pistol Whip. I got a PS VR 2 for my birthday and it's a super fun rhythm game but with shooting.
Horizon: Call Of The Mountain (PS VR 2). I nearly didn't include this because it is bascially just a climbing simulator with a bit of combat, but it's a beautiful game, VR archery is so much fun and the environments you go through are so cool. I struggled a lot with this game at first because I'm actually terrified of heights, so I got quite anxious climbing some of the rusty metal structures hanging over massive drops!
No Man's Sky. Very much new to me, not new game – I got it on offer originally to try out with PS VR, but found I actually preferred playing it normally. I wasn't expecting to enjoy this game as much as I did, but it's a great combination of exploration, crafting and weird little space animals.
Cyberpunk 2077 gets an honourable mention because the DLC was excellent and the new patch balanced a lot of the annoying things about the game. If you've been holding off, give it a go – this game rules.

...learning things

Some of the things I learned this year:

I did some really complex backend work, complained the whole way through, and begrudgingly learned a lot from it.
I was thrown into a new situation at work which required a lot of disambiguation and interviewing lots of people to get enough information to solve a problem and make a decision on how to proceed. It was exhausting, but interesting, and great experience.
I did a couple of painting and drawing courses and discovered that I really liked painting. Unfortunately I don't have a lot of space for the hobby right now, but you can be sure I bought all the things for it and they're in a drawer now.
My work held a Security Awareness Week and ran a Capture the Flag competition which I got completely hooked on (and won!). As a fiend for puzzles, it ticked every box for me. I absolutely loved diving through the problems and trying to reverse engineer things. I'd really like to learn more about that stuff.

I came away from the various frontend conferences this year intending to learn some cool new CSS stuff, but honestly my appetite for building things outside of work was so minimal that I just didn't get around to it. I did play with :has on the way home from CSS Day, though.

...purchases

The best things I bought this year:

a second-hand soda stream. £40 off ebay, and I get sparkling water whenever I want.
a moth-patterned dress from Disturbia. I've enjoyed indulging my ~inner~ outer goth this year.
a Meaco fan, which is wonderfully quiet and has about 954 different speeds, all of which feel like some kind of deity is blowing on your face.
two gorgeous prints of the Barbican Conservatory by Cat Sims
"haha business" t-shirt from dogecore
Beautiful moon earrings from my favourite jewellery designer Rosa Pietsch

...apps and programs

In Your Face means I'll never be late to a meeting again
BetterSnapTool lets you drag windows to the side of the screen and instantly snap them to half or a quarter of the desktop. For work that requires a lot of side-by-side comparison it's a godsend.
Boop is a great little tool for doing a lot of common dev tasks like decoding URI-encoded text, converting CSV to JSON, and so on.
Obsidian: I decided it was time to get organised and put all my notes and docs in one place so I'd actually know where they were. I'm hoping that over time it'll become a really useful reference for my own brain, which is a swirling vortex of smaller, swirlier vortexes.

...blog posts

I did even better than last year and wrote 10 posts, shared 2 recipes and talked about one podcast. Some of my favourite posts from this year:

...the web

Mastodon continued to grow on me. I still miss the old Twitter, and the reach I used to get on there, but I've kind of embraced the slowness of Mastodon now. I don't even check it every day, which seems like a depressing thing to be surprised about, but I was so hooked on Twitter.
I subscribed to the Garbage Day newsletter, and it's very good if you're an Internet Person.
Robin Rendle and Matthias Ott started newsletters, and you should absolutely subscribe (either via RSS or email). Robin's is called The Cascade and it's about CSS; Matthias's is Own Your Web, about designing, building and publishing on the web. They are both Very Good.

And so we're at the end

It's been a whirlwind year and I've ended it pretty shattered, but I'm pleased with what I achieved (and by that I mean saving the world in Baldur's Gate 3, obviously).

I used a fair bit of my time off this year on conferences which, although fun, are not restful in the slightest. That on top of a stressful few months towards the end of the year mean I've ended it a bit burnt out again. Not as bad as last year, but still not great. The plus side: I get a 3-month paid sabbatical next year (!) so I'm going to make sure I get more of a rest. I'm thinking of doing some volunteering/conservation work with a wildlife trust or something similar, and we're hoping to finally go to Japan later in 2024.

Wishing you all a lovely Christmas, a happy new year, and a 2024 that's exactly what you are hoping for!

Engineering progression for humans

2023-12-12T00:00:00Z

As engineers it can be unclear where we’re heading, especially when we’re heads down writing code all the time. It can be hard to think even a few months ahead. What does an engineering career in a larger organisation look like? What even is a staff engineer? How long should you stay at the same company?

Whether you're new to the industry or several years in, there's a good chance you've identified with at least one of these statements at some point:

It seems like there’s a dozen different ways you could progress and you have no idea what’s right for you
There isn’t anyone in your immediate organisation who has a role you see yourself going into
You don’t really know what you want from your career

This is everything I've learned about progression in larger organisations, with some thoughts and opinions on the way. If you're not working in a capital-T capital-C Tech Company, this might not be so applicable to your situation, but never say never!

This isn't going to be a step-by-step guide to how to reach each level of the engineering career path. For one thing, it varies wildly from company to company, so my advice might not be applicable where you work. Instead, by looking at what these levels involve, you might be able to identify where you need more experience or where you're already well on your way.

Know what motivates you

Understanding how you want to progress in your engineering career depends on what motivates you.

It’s completely okay to be motivated by money, for example. Money can be exchanged for goods and services. Houses are expensive. Families are expensive. Dogs are expensive. Maybe you’re saving for your future, or supporting someone back home, or maybe you like having nice things.

Or maybe you want to be in a position where you can influence teams at a higher level. You have thoughts and opinions, and you like being able to help architect systems or decide on the best way forward.

Perhaps you want a role that lets you help others, and grow people. Watching them develop in their own careers thanks to your support. Helping teams achieve their goals and be productive.

You might need a change because your current role is negatively affecting your mental health. For me, mental health trumps everything, and there is no job that is worth doing at the expense of mental health. If it sucks, hit the bricks.

Maybe you want to do work, clock out, and focus on the other things in life. Like extreme ironing, or beekeeping.

You’ll probably fall into a few of these categories. I know I’m definitely motivated by helping people but also taking a high-level view and influencing things. And I have to say, I also like having money. But I've also been careful to choose jobs that allow me to protect my work-life balance.

Your career decisions should reflect what’s best for you. Not your company. Not anyone else. We spend 40 hours a week in our jobs, so it needs to be worth it.

Speaking of which:

Not everybody needs to (or wants to) progress

It's so easy to fall into the trap of thinking you have to follow the same path as everyone else. You could be forgiven for thinking careers are all about progression. But ultimately it's whatever you want it to be, and if you're happy where you are, that's the most important thing. Many folks out there will tell you that you don't have to have a Big Tech job to be a successful engineer, and you should listen to them. Engineering, software development, web design, whatever you want to call it: there are so many versions of this job and only you know which one suits you best.

The way up (or sideways. Or backwards.)

The first few stages of the engineering career path are relatively well-trodden. You come in at an entry-level or so-called “junior” position, you work your way up to a mid-level engineer – often just called “engineer” – and then you might go up to Senior. Here's one such example:

What each of these steps looks like depends on your organisation, but commonly Engineer I is like an intern or apprentice (what you might expect for someone with little to no background in engineering at all), Engineer II is what is often called "junior" (entry-level for someone with a qualification or a bit of training) and Engineer III is a mid-level position. Senior might just be one role, or split out into two levels.

It depends on where you work, but generally speaking there are no set timelines for this progression. Some folks progress faster than others, or have their start at different times in their life: sometimes you’ll work with a 22-year-old senior engineer and feel like you are turning into dust, sometimes you’ll meet folks in their 40s or 50s who are starting out as developers. It’s all good.

A note on promotions: many tech companies these days will only consider a promotion once you've shown that you're already working at the next level up. I don't especially like this, as I think it disadvantages people who aren't extroverted or highly visible in an organisation, and it kind of means you end up doing the job for a while before you get paid for it. In these kinds of organisations, progression is as much about playing the game as it is about doing a good job and being recognised for it. I'll write up another post about that soon.

I also know some bigger orgs have a kind of rule that you have to be in a role for X number of years before you can get promoted, and I particularly don’t agree with that approach because your tenure has no bearing on your ability. I'd agree that it takes time to build up the required experience for higher levels of jobs, but that amount of time differs from person to person and each individual case should be considered.

The first few stages of an engineer's career are a bit more well-defined; let's have a look at them.

Engineer I and II

As Engineer I, you're at the start of your career, learning and asking questions. Not that you won't be learning and asking questions for the rest of your career – you should definitely be doing that regardless of your experience. But you'll be getting to grips with the tools, with the practices, with how things work.

The kind of work you do at this stage should be very well-defined tasks that are curated for you by a more senior engineer as good things to get your teeth into and learn from. You might spend a lot of time pairing on tasks.

At level II, you've got the base knowledge down, you're a solid, trusted contributor to your team and beginning to design solutions on a smaller scale for problems your team is working on. You're more independent now, though you're probably still working with senior engineers to break down the problems and scope the work that you're doing.

Mid-level engineer / Engineer III

Now you're a lot more independent – a good individual contributor (IC). You're happy designing and implementing solutions, suggesting improvements to ways of working and engineering patterns, writing code with a good level of proficiency. You may also start to mentor less experienced engineers. You'll be leading mid-sized projects and are trusted to get the job done. Your PR reviews and pairing sessions help more junior engineers learn the ropes.

It’s totally legit to just stay here and hang out for however long you want. You don’t need to go for senior.

Senior engineer

Senior engineers are experienced ICs who can lead projects or features that have a higher level of technical complexity. You'll be mentoring less experienced engineers, either through formal 1:1s or by leading by example through the code you ship and the feedback you leave on PRs. You'll get good at identifying opportunities for your team and how they relate to the wider goals of your organisation.

The more senior you get, the more ambiguity there is in what you’re working on, and the more high-level you start to operate. My work often finds me looking across teams and even across the organisation.

Senior engineers come in all shapes and sizes!

The senior engineer role isn't the same for everyone. I like how Monzo's engineering progression framework, er, frames it, and I've very much paraphrased here:

You might be a galaxy-brained domain expert, who knows the ins and outs of a particular area or system like the back of your hand. If there's a project involving this system, you're possibly leading it, but you're definitely advising on it.

Or you might be more of a "tech lead"-shaped senior engineer, focussing on enabling your team to build great quality software and fostering a great engineering culture. At Monzo this doesn’t translate to literally being tech lead of a team – it’s a hat you put on, and you might not be senior yet when you're tech-leading.

You can also sit somewhere in the middle, being a great individual contributor and leading projects, helping your team to do great things.

Senior to ???

What comes next?

So, for one thing, maybe you don’t go anywhere.

The long-tenured senior engineers on our teams are indispensable. They’re fountains of knowledge, they’ve seen it all, they are wise beyond their years. Every company needs some great senior engineers who are happy continuing to be great senior engineers. You may choose to reach senior, and stay there.

Senior to staff

If you want to continue down the IC path, generally it'll be to something like Staff Engineer. This is technically a leadership position, but it shouldn’t involve managing people.

What this role looks like varies massively across different organisations and even across different teams in the same organisation.

If you do decide to pursue further progression to Staff and above, this is where things start to get murky. It’s surprisingly not a very well-trodden path.

Thankfully, both Tanya Reilly and Will Larson have done lots of path-treading and word-writing about this very topic: Tanya’s book, The Staff Engineer’s Path, provides a great overview of what you might expect to be doing and what you need to excel in this role. Will Larson is the author of Staff Engineer and also runs the StaffEng website with a lot of helpful stories and guides to staff engineering across organisations.

Notably, he came up with Staff Engineer archetypes that nicely outline what this role might look like:

The Tech Lead guides the approach and execution of a particular team. They partner closely with a single manager, but sometimes they partner with two or three managers within a focused area. Some companies also have a Tech Lead Manager role, which is similar to the Tech Lead archetype but exists on the engineering manager ladder and includes people management responsibilities.

The Architect is responsible for the direction, quality, and approach within a critical area. They combine in-depth knowledge of technical constraints, user needs, and organization level leadership.

The Solver digs deep into arbitrarily complex problems and finds an appropriate path forward. Some focus on a given area for long periods. Others bounce from hotspot to hotspot as guided by organizational leadership.

The Right Hand extends an executive's attention, borrowing their scope and authority to operate particularly complex organizations. They provide additional leadership bandwidth to leaders of large-scale organizations.

I’m working on this path myself, recognising the areas I need to develop. My engineering director framed it as having muscles I need to develop and train to get to staff; for example, I know I’m very technically competent and have formed good relationships across the company, but I need to get better at managing my time and focus, and I'm gaining experience of tackling highly ambiguous problems.

This year we also had the inaugural StaffPlus conference from the same folks that run LeadDev. I found this a really great opportunity to absorb some really useful information for my own progression in a bigger organisation. (Shame about the eye-watering ticket price, though.)

Senior to engineering management

In tech companies these days it’s very common to have dedicated engineering managers (EMs) who look after a group or team of engineers, along with some other responsibilities. At Monzo our EMs also function as delivery leads, making sure the teams are unblocked and productive, and acting as envoys between product teams and leadership.

You might take a step sideways away from the hands-on engineering role, and become an engineering manager. It’s not a promotion as such, more of a role change; generally speaking engineers wanting to make the transition into engineering management will need to get to senior first, before moving laterally.

The most well-known guide in this area is The Manager’s Path by Camille Fournier. I read a good part of it myself some years ago when I was looking into becoming a tech lead, and it has some great advice on what makes an effective technical manager (and of course, how to get there).

I know plenty of engineers who have gone into engineering management and loved it; I also know a handful who have done it for a while and realised it wasn't for them and gone back to being an IC. It doesn't have to be a permanent choice.

Other potential sideways steps

I've outlined some very common paths for engineers, but there are other roles you might choose to explore in the world of engineering that are more of a sideways step, such as:

Developer relations (devrel) – fostering relationships with the developers who use products, showing them the art of the possible, and building a community around that
Sales engineering – combining technical expertise and people skills in a role that could see you travelling all over!
Specialist consultancy roles e.g. accessibility consultancy – laser-focussing your skills in a certain area and helping companies to improve, or even taking on a full-time leadership position as head of your specialism.

(If you know of any others I've missed, do let me know, and I'll add them in.)

So, that's the engineer's path. But it's rare that people spend their entire careers in one company these days. Where might your career take you?

Cross-company career paths illustrated using tenuous playground metaphors

You might recognise these paths from your own career or those of the people around you. They're somewhat simplified for brevity.

The ladder

Photo by Michael Glazier on Unsplash

The “traditional” career ladder model tended to be applied to people within one organisation. At a company I used to work at, it looked a bit like this:

It was a very old company, and people stayed for their whole careers. The more senior you got, the bigger the likelihood was you’d end up managing people. There wasn’t really an IC track in the way there is elsewhere.

With a long career in one place, you get great in-depth familiarity with systems and organisational patterns, and you become a trusted face in the company. Many companies offer bonuses and benefits for long service, like sabbaticals. And if you're happy there, that's great.

Do bear in mind that that tenure might come at a cost of not gaining experience of the outside world: you could end up with tunnel vision, only knowing how things are done where you work. As time goes by you might find yourself more resistant to change, because it’s not the way you’ve always done things (this was a common pattern where I worked). There are ways around this, of course – make sure you keep in touch with folks from other orgs, hire people from outside and trust their opinions, and keep up to date with what’s going on in the wider industry.

The climbing frame

Photo by S. Tsuchiya on Unsplash

A more common pattern these days is to move every few years. You might take a promotion for the new role, or do a sideways step into another company at the same level. You don’t always have to be getting a promotion when you move, though 9 times out of 10 you should be getting a pay rise with that move, unless it’s a conscious decision (e.g. moving to a nonprofit or smaller company).

This might also involve a role change – I’ve known engineers who climbed the ladder and then did a sideways step into a non-engineering role. That engineering background is so powerful when you go into product management, for example.

Monkey bars

Photo by Annie Spratt on Unsplash

Some folks hop from company to company every 1-2 years; there’s nothing inherently wrong with this approach. The old advice goes that lots of short stints at different places will look bad on your CV/résumé, but 1-2 years is a decent amount of time in the industry these days.

One advantage is that you get insight into how different companies work and different tech stacks, and you should hopefully be negotiating pay rises with those moves, even if they’re lateral moves. Some of those roles might involve promotions, as well.

Of course, people working short-term contracts will have lots of different roles in their employment history and that’s to be expected.

The downside is that if you’re more into the leadership side of things, you might not be hanging around long enough to establish yourself as an authority of anything, and being really familiar with your organisation and its systems. So have a think about whether that’s something you value.

Merry-go-round

Photo by Loegunn Lai on Unsplash

This is actually my career history. Also known as the "Grampa Simpson".

I left my job at Monzo to pursue a role I was offered at a startup because I thought it was a great opportunity I shouldn’t pass up. It ended up not working out – our expectations of the role weren’t really aligned, it was nobody's fault – so I ended up coming back to Monzo in a similar role but a different team. At Monzo they call this a “boomerang”, but that doesn’t fit with my ridiculous playground analogy.

I don’t regret leaving to try it out, and I don’t regret coming back. It’s completely fine to make a U-turn as long as it’s the right thing for you. As I wrote at the time: going back doesn’t always mean going backwards.

Like with any merry-go-round, you don’t want to spin too many times or you’ll get dizzy. It’s good to go on some other equipment too.

The rocker

Photo by Shiau Ling on Unsplash

Not everyone wants to climb to the top, and that’s okay. There are any number of reasons why someone might want to stay in the same role.

Maybe they like it. Maybe they’ve got other responsibilities outside of work that take up any extra space in their brain. Maybe they value other things in life. It’s all good.

I’m definitely guilty of feeling like I always need to be moving up to the next level, as if by staying still I’m not good enough; but of course, that’s absolute rubbish.

There's no one right way

Progression can mean so many different things. It can mean going forwards and backwards, moving around trying different things and coming back again, or staying in the same place having a great time. It really depends what suits you. There isn't one "right" path to follow!

I hope this has gone some way to demystify the path your career could take, both role-wise and company-wise. And remember, don't let anyone make you feel like you must pursue one particular path or fit your career into a specific box. Only you can make that decision.

Beautiful musical chaos

2023-12-02T00:00:00Z

When I tell people I’m in a choir, some of them imagine the same thing: churches, robes and choral music. Pious singing faces.

(To be clear, I’ve done that kind of choir before and it’s great in its own way, but that’s very much not what goes on in this one.)

Generally, though, people respond with the question, “what kind of choir is it?”. What indeed.

A post by Phil Hawksworth earlier this year about his newfound love of choir really resonated because I knew exactly how it felt to be completely, unexpectedly sucked in to this hobby.

Daylight Music at the Union Chapel

I’d been in various choirs before, classical ones, but only joined SHE Choir because I’d just moved back to London and didn’t know anyone. The choir started life as a student society in Manchester where I studied, and I’d gone to a few sessions the year before, but now the founders had moved back to London and brought the choir with them. It was chaotic, but I was hooked immediately.

A few months in, I decided I wanted to try arranging something. I remember asking if it was okay for me to have a go, and I put together a three-part arrangement of Don’t Panic by Coldplay. I was too nervous to sing in front of people so I got someone else to teach it. But it sounded good.

A weekend away with both the London and Manchester choirs to a druid camp in a remote part of the Midlands – involving sleeping next to a creepy fur-clad mannequin, lots of singing in yurts, and a bunch of city women completely failing to work a log fire – finally gave me the confidence to start singing on my own in front of people. I realised that choir was a safe space for me to do that, to teach and learn at the same time. After I got back, coasting on the high from the weekend, I arranged Fleetwood Mac’s song Everywhere and that would become the first thing I taught by myself.

From there, the choir became something I could actively contribute to. Not long after that the founders left and, not wanting to see this lovely motley crew disappear, a couple of us took over as organisers. That was a lot of work for two people (you can see why people do it as a full-time job!) so we eventually transitioned to a team-based structure. It’s less rigorous and a bit more anarchic, but it means less responsibility falls on one person’s shoulders. (I’m always and forever the admin queen... and of course I built the website.)

We became an a cappella group solely because none of us could play the piano. I got us on Slack because that was what you did in 2014, and we got organised. We started taking attendance, and the revolving door of people coming and going and never learning the songs became a more reliable core membership of regulars who got better every week. I got fed up of taking attendance very quickly, and built a Slack integration that did it for us.

We met up with another more established women’s choir in London and attended each other’s rehearsals to swap tips. They had been the inspiration for our choir’s existence. I was blown away by them, and imagined that maybe one day we’d be as good as them.

Over the years I’ve arranged and taught songs by Alice Cooper, The Postal Service, Imogen Heap, Bruce Springsteen, Chaka Khan, Wheatus, Regina Spektor, Dolly Parton, and more. Ain’t Nobody is well-known enough to most, and my arrangement simple enough, that for a while it became the first song anyone taught when a new branch of the choir popped up. It’s quite a feeling to stand on a stage in front of a hundred or so people from all over, most of whom you’ve never met, and conduct them all singing a song that you arranged.

Conducting isn’t just waving your hands about and being a human metronome. It's conveying emotion, volume, shape of the sound. For me, the most special part of it is having your arrangement sung back at you with the full weight of the choir behind it – it often makes me emotional to hear those little crunchy chords I put in reflected so beautifully in the choir’s strong voices. I did this.

As time goes by the thing I enjoy the most is watching new conductors get that same joy from standing at the front and hearing their arrangement sung back at them. It can be a very vulnerable thing to put yourself at the front, and I’m so glad we’ve given people the opportunity to try new things out, arrange these songs nobody else knows but that mean so much to them, and learn new skills along the way.

Three years after we attended the other choir’s rehearsal, we were on the same billing as them at a festival in London. I watched their set and realised that we were not only that good, but also so different. Going a cappella had actually forced us to be more creative with our arrangements, being the bass and the instruments as well.

The choir that was once just in Manchester and London is now all over England, Germany and New Zealand. People love it so much that when they move away, they start up a new one wherever they end up. For a while there was one in a remote skiing town somewhere in France. Our London group is changing our name now, to better reflect the diversity of our members: we've called ourselves Mixtape. The perfect name for a weird and wonderful collection of songs, and people.

On Thursday night at our winter gig I stood in front of the choir and waved my arms around to the tune of Dancing In The Dark by Bruce Springsteen, one of the most ambitious arrangements I’ve done – and the choir nailed every note. We’re an amateur choir in every way: no auditions, collectively and chaotically self-organised, and we’re all just making it up as we go along. But we’re so good at it.

I’ve invested a third of my life in this choir and there have been moments when I’ve been overcome with frustration (nobody’s doing anything! I have to do everything!) or worry (why hasn’t anyone learned the song?). But reflecting on how far we’ve come and what we’ve brought to people’s lives makes it all worth it.

Those are the moments I live for: the biggest smile on a new conductor’s face as they conduct their song in public for the first time; the “I’m not sure if this is going to sound good” but it always does; the “okay, sure, I’ll have a go” from a quiet person; the drunken renditions of every song we’ve ever done, fuelled by too much wine, at every single choir retreat (and yes, it really is exactly like Pitch Perfect); and the teary reflections the morning of the last day of retreat as everyone shares what this choir means to them. And ultimately, it’s been a lifeline for me during some of the hardest times of my life.

Of course, I could never convey all of that in one sentence when asked “what kind of choir is it?”. So I just say “it’s a pop choir.” But it’s a lot more than that, really, isn’t it?

Photo: Jessica Jill Photo

A good recipe: The best chocolate brownies

2023-11-23T00:00:00Z

I've been making this "Bonfire Brownies" recipe since it was aired on UK children's TV institution Blue Peter in the early 00s, and I maintain it's still the best brownie recipe. Chewy and delicious. I recommend freezing them and eating them straight out of the freezer (I discovered this when my mum used to put them in the freezer to keep them out of the way of temptation, and I'd nick them when she wasn't looking). There's nothing bonfire-specific about it, they're chocolate brownies and I suppose the episode aired around 5th November, but they're fucking great.

Look, I don't have any photos of this, but you've just got to take my word for it.

Makes 12

Ingredients

100g unsalted butter
225g golden caster sugar (or regular caster sugar)
40g cocoa powder
2 eggs
50g self-raising flour
50g chocolate chips
1/2 tsp vanilla essence (optional)

Method

Preheat the oven to 180°C/350°F. Grease and line a 20cm square brownie tin.

In a large bowl beat the eggs, add the sugar and mix together until smooth.

Melt the butter in a small saucepan over a medium heat. Sift in the cocoa powder and mix. Add this mixture along with the vanilla essence (if using) to the egg and sugar mixture.

Sift the flour into the wet ingredients and mix together until smooth. Fold in the chocolate chips.

Pour into the brownie tin, and put in the oven. Cook for around 20-25 mins, until the top is a darker brown (but watch it doesn't burn!).

Leave to cool in the tin for 5-10 mins, then carefully turn out onto a cooling rack. For best results, wait until they're completely cooled to slice.

How to schedule posts in Eleventy

2023-11-21T00:00:00Z

I scheduled this post, isn't that cute?

I find I have very little energy to write blog posts during the week, but occasionally I sit down on the weekend to write something and have a few ideas that turn into multiple posts. I'd like to be able to publish posts more often, but realistically I won't be writing things more than once every few weeks (which is okay!). I decided I needed to be able to schedule posts so I don't just publish a load at once.

Eleventy's suggested draft post setup has been working nicely for me, and posts with draft: true in the frontmatter don't appear in the production site. However, I miss Hugo's scheduled posts feature, where I'd be able to write a post with a date in the future and it'd only appear on the blog after that date. Thankfully it's pretty straightforward to set up in Eleventy, in a similar way to drafts.

Scheduling website builds

My website already builds twice a day to fetch the latest webmentions. I had a GitHub Actions job to build and deploy my site to Neocities, with a cron schedule that ran every 12 hours:

name: "Deploy to Neocities"
on:
  schedule:
    - cron: 0 */12 * * *
  push:
    branches:
      - main
jobs:
  deploy:
    name: "Deploy to Neocities"
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v3
        with:
          node-version: "18"
          cache: "yarn"
      - run: yarn install
      - run: yarn build
      - uses: bcomnes/deploy-to-neocities@v1
        with:
          api_token: ${{ secrets.SUPER_SECRET_TOKEN }}
          dist_dir: "_site/"
          cleanup: false

I tweaked the cron schedule so that it runs daily at 8am and 5pm, so I wouldn't publish a post at midnight.

name: "Deploy to Neocities"
on:
  schedule:
    - cron: 0 8/9 * * *

Exclude scheduled posts from collections

In my drafts.js plugin, I added a new function to check whether a post's timestamp is in the future:

const now = new Date();

function isScheduledPost(data) {
  return data.date != null && data.date > now;
}

Finally I added this function to the conditions in the eleventyComputedPermalink and eleventyComputedExcludeFromCollections functions which check for draft posts:

function eleventyComputedPermalink() {
  // When using `addGlobalData` and you *want* to return a function, you must nest functions like this.
  // `addGlobalData` acts like a global data file and runs the top level function it receives.
  return (data) => {
    // Always skip during non-watch/serve builds
    if (!process.env.BUILD_DRAFTS && (data.draft || isScheduledPost(data))) {
      return false;
    }

    return data.permalink;
  };
}

That's it! The scheduled posts will always show up when running the site locally, as process.env.BUILD_DRAFTS is always true in the dev server. But they won't show up in the production site until the day comes and the site gets rebuilt. To be extra sure, you can run your site's prod build command and check the output – your scheduled page shouldn't be listed.

Building post types and category RSS feeds in Eleventy

2023-11-19T00:00:00Z

I mentioned recently that I'd built separate RSS feeds for different kinds of posts. Here's how I did it!

I had to do a bit of fiddling to get this working in Eleventy – this is one of the few things I think Hugo actually does in a simpler way, as you can create different rss.xml templates inside specific layout directories. My solution is not especially sophisticated, but it works! (If you know a less complicated way... I'd love to hear it.)

Building post types

Alongside the traditional long-form blog posts, I wanted to be able to publish little "micro" posts of recommendations and things I liked. In order to distinguish them, I added a new frontmatter field called type to all my posts. Right now, there are a few different types: article, podcast, game, book, and recipe.

In my blog post list page, I add the type as a data attribute on the <li> for each "micro" post, so that I can display an appropriate emoji on the list item. (I haven't quite figured out how I want to show filters for post types yet.)

Each post type has a json file which specifies the default frontmatter for all files in that directory. It automatically formats the post title into a consistent format, and tags the post accordingly. Here's podcasts.json:

{
  "layout": "good-podcast.njk",
  "hasCustomOGImage": true,
  "eleventyComputed": {
    "title": "A good podcast: {{ podcast }}"
  },
  "type": "podcast",
  "tags": [
    "podcast"
  ],
  "permalink": "/blog/a-good-podcast-{{ podcast | slugify }}/index.html"
}

The tags and type are identical because I wanted a quick way of accessing post type in things like the layout, but I wanted readers to be able to list all podcasts just like they can any other tag – and post tags might contain more than just "podcast", say. Any tags I set on the post itself will be added to that array, not replace it.

I use the hasCustomOGImage variable to tell a layout whether to find a specific OG image based on the title of the post, or just use the default one.

The post itself has its own frontmatter, with the name of the podcast (or book, or game, etc), the date, an image with alt text, and the URL of the podcast.

---
podcast: If Books Could Kill
url: https://pod.link/1651876897
date: 2023-07-16
image: if-books-could-kill.jpeg
alt: "The cover image for If Books Could Kill, with an illustration of a bleeding book" 
---

Michael Hobbes and Peter Shamshiri take us through some of the biggest "self-help"/pseudoscience books from the last few decades and deservedly tear them apart.

[...]

Separating RSS feeds

If you don't already, you'll need the Eleventy RSS plugin set up. See the plugin docs for instructions.

My RSS feed was previously one single feed, set up with some basic settings – it was pretty much identical to the example in the RSS plugin docs.

I wanted to split up my feeds into the various different types of "micro" posts (the recommendations), and then everything else as one "articles" feed; however, I also wanted to keep the "everything" feed for people who like their posts about Content-Security-Policy headers interspersed with brownie recipes from 2001.

Collections, collections, collections

I've got a few custom collections for my post types. The first one pulls all of the posts in the blog directory, which encompasses all articles and post types:

// eleventy.config.js

eleventyConfig.addCollection("blog", (collection) => {
  return collection.getFilteredByGlob("./src/blog/**/*.md");
});

Then I've got the categoryFeeds collection which contains all of the specific feeds I want for each "micro" post type.

eleventyConfig.addCollection("categoryFeeds", () => ["recipe", "book", "game", "podcast"]);

Finally, I've got one for "articles" - all the posts that aren't micro-categories. These all live in the same directory, so I used getFilteredByGlob again. (I've actually called the directory "posts" but I couldn't be bothered to change it.)

  eleventyConfig.addCollection("articles", (collection) => {
    return collection.getFilteredByGlob("./src/blog/posts/*.md");
  });

Paginating the category feeds

I used Eleventy's excellent pagination feature to generate the RSS feeds themselves. I've got a file called rss-categories.11ty.js which contains info about the data I want to paginate, and that will produce a feed for each of the feed categories in my categoryFeeds collection. Each generated file will have the same template (rss.njk) but a different title, subtitle and feed URL; it'll also have a different value of feed (set to whichever category the feed is for, based on the collection item).

class RSSCategories {
  data() {
    return {
      pagination: {
        data: "collections.categoryFeeds",
        size: 1,
        alias: "feed",
      },
      permalink: ({ feed }) => `/${feed}s.xml`,
      eleventyExcludeFromCollections: true,
      layout: "rss.njk",
      eleventyComputed: {
        title: ({ feed }) => `localghost.dev - posts about ${feed}s`,
        subtitle: ({ feed }) => `A feed of the latest ${feed} recommendations from localghost.dev`,
        feedUrl: ({ feed }) => `https://localghost.dev/${feed}s.xml`,
      },
    };
  }
  render() {
    return null;
  }
}

module.exports = RSSCategories;

One RSS template for all

My RSS feed template lives in _includes/rss.njk alongside all my other layouts. It's pretty much the standard RSS template they suggest in the docs, but with a couple of tweaks to make it a bit more generic, allowing title, subtitle and feedUrl to be optionally passed in as variables.

<?xml version="1.0" encoding="utf-8"?>
{% if not title %}
{% set title = metadata.title %}
{% endif %}
{% if not subtitle %}
{% set subtitle = metadata.description %}
{% endif %}
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>{{ title }}</title>
  <subtitle>{{ subtitle }}</subtitle>
  <link href="{{ feedUrl }}" rel="self"/>
  <link href="{{ metadata.url }}"/>
  <updated>{{ collections[feed] | getNewestCollectionItemDate | dateToRfc3339 }}</updated>
  <id>{{ metadata.url }}</id>
  <author>
    <name>{{metadata.author.name}}</name>
    <email>{{metadata.author.email}}</email>
  </author>
  {%- for post in collections[feed] %}
    {% set absolutePostUrl %}{{ post.url | url | absoluteUrl(metadata.url) }}{% endset %}
    <entry>
      <title>{{ post.data.title }}</title>
      <link href="{{ absolutePostUrl }}"/>
      <updated>{{ post.date | dateToRfc3339 }}</updated>
      <id>{{ absolutePostUrl }}</id>
      <content type="html">{{ post.templateContent | htmlToAbsoluteUrls(absolutePostUrl) }}</content>
    </entry>
  {%- endfor %}
</feed>

Oddly, the variables seem to leave a blank space in the outputted XML, but as long as the <?xml> declaration is at the top it doesn't seem to matter.

The RSS template iterates over a given collection and includes all the posts it finds, so I have to tell it which collection to pull from. This is where the feed variable comes in. It tells the template to iterate over posts tagged with e.g. "recipe" or "game".

A separate articles feed

Unlike my specific category fields, "everything else" isn't a tag, so I can't use the same pagination to generate the "articles" feed. That has to have its own file. Since it hasn't got any fancy variable templating, I can just create a nunjucks file and fill out the frontmatter:

---
  permalink: 'articles.xml'
  eleventyExcludeFromCollections: true
  layout: "rss.njk"
  feed: articles
  title: "localghost.dev - all articles"
  subtitle: "Sophie builds fun things out of HTML, CSS & JavaScript, and writes blog posts about tech and mental health. This feed excludes recommendations about books, games, podcasts, recipes, etc."
  feedUrl: "https://localghost.dev/articles.xml"
---
<!--  rss-articles.njk -->

Because I created the articles category in my Eleventy config, I can pass that in as the feed variable, and then collections[feed] in the RSS layout will translate to collections.articles. The only posts in this feed will be anything that lives in my /blog/posts/ folder.

The primary feed

And finally, the tweak to my "everything" feed to get it to work with this new layout: make sure it also has a feed variable. The blog collection already exists, and contains everything in the blog directory, so we can pass that in and it'll add everything in there to the RSS feed (which is actually what it was doing before, anyway).
The metadata for my primary RSS feed is shared with the meta tags for the <head> of my site, so it lives elsewhere in _data.

---
permalink : "feed.xml"
eleventyExcludeFromCollections : true
feed: "blog"
layout: "rss.njk"
feedUrl: "https://localghost.dev/feed.xml"
---
<!-- rss-all.njk -->

And there you go! Multiple RSS feeds. I changed the RSS link in my footer to point towards a page where I added links to all the feeds.

A good recipe: Smitten Kitchen's apple pie cookies

2023-11-12T00:00:00Z

If I need to impress, or bribe people to like me, I make these cookies. A shortcrust pastry/biscuit dough hybrid case with appley-cinnamony goodness inside, packaged in an adorable pie shape.

The process is a little involved, but they're flaky and delicious (and often gone in an instant). I first made them over a decade ago and it's still one of my go-to recipes.

Introducing separate category RSS feeds

2023-11-12T00:00:00Z

Recently I've been inspired by folks like Michelle Barker and Amy Hupe doing National Blog Posting Month (NaBloPoMo!), and seeing folks writing down little thoughts and things they've encountered. I'm absolutely not doing NaBloPoMo, I am far too tired, but I thought I'd make it easier for myself to write things down a bit more often than once every three to six months.

I've introduced some new categories to my blog, where I can share things like books, games and podcasts I've enjoyed recently, and recipes I love. I figured that having these little bites to post occasionally might spur me to write a bit more often. However, I know people won't necessarily want to read all of those things if they subscribe to my RSS feed. I also have very specific categories in my own RSS reader, so I wanted to make sure people can only subscribe to the things that interest them. So I built separate RSS feeds!

My site's main feed still contains everything, but if you don't want the occasional brownie recipe with your accessibility rants, you can subscribe to my "articles" feed which only has my writings and rantings. If you want to get a podcast recommendation now and then, the "podcasts" feed is for you. The new feeds are a bit quiet at the moment, but will pick up as I post more!

I'm writing up how I built it, but for now you can pick your favourite feeds on the RSS page.

"AI", and the trouble with inaccessible SaaS

2023-09-17T00:00:00Z

I wasn't particularly enthused by the alpha release of Vercel's v0 UI generation tool this week. Provided with a prompt, it produces React code with Tailwind to style it. It's being marketed as a prototyping tool, but was described by Vercel's CEO on Twitter as "production-grade". Well, which one is it?

To be clear, my issue isn't with the concept of large language models (LLMs) in general: I use Copilot in my everyday work, and it's saved me a lot of time when writing tests! My concern is with the source material used to train it, and what people do with the output.

Hidde de Vries wrote a great post on the incredibly problematic dev community response after the accessibility of the UI was called out, so I won't go into that here.

Stop putting inaccessible prototypes into production

Prototyping is one thing. Noodling around with UI ideas? Fantastic. Please don't put it into production.

A pattern I've noticed with a huge number of tech/SaaS startups is:

have idea
build very quick, inaccessible UI "prototype" to test idea
ship prototype to production
prototype becomes the actual product

Inevitably, people will copy existing patterns in the codebase, adding more stuff on top, and time passes. At this point, you have a completely inaccessible SaaS product, and the amount of work needed to go back and fix all the problems is so much, and so costly, that it's never going to be a "business priority". So many of the B2B SaaS tools I've used are terribly inaccessible; companies seem to forget that staff may have access needs, as well as customers, and that those access needs may extend beyond being blind or partially sighted.

In fact, a 2020 study by RNIB (docx) found that "50% of employers thought that there may be additional health and safety risks in the workplace [employing someone blind or partially sighted]; 33% of employers thought that they may not be able to operate a computer/laptop; 33% of employers thought that they may not be able to operate the necessary equipment, excluding computers/laptops". Isn't that just terribly fucking depressing?

I truly wish the founders of SaaS companies worldwide would learn some proper semantic HTML before they build these UIs that are going to form the basis of their entire product for years to come. I'd love to see SaaS accessibility viewed as a competitive advantage rather than an expensive afterthought.

As Ashlee Boyer puts it:

The right time to work on accessibility is before you launch a product into alpha.

Before v0 was announced I was planning on writing a blog post about the inaccessibility of SaaS software, and how it starts at prototypes making it to production, so I guess this is that post. The problem has existed for years, long before generative LLMs came along. LLMs are just making it worse, and faster.

People write inaccessible code, and LLMs copy people

Tools like v0 are destined to become the new "copying and pasting from open-source UI libraries". In the wider community, ChatGPT has already overtaken StackOverflow as the first port of call for coding questions. Developers shouldn't unreservedly trust the output from code-generating LLMs, though. I double-triple-check everything that Copilot produces for me, and generally end up tweaking it about half of the time – and I rarely let it write blocks of code unless I'm writing loads of repetitive tests. It's great for autocompleting variables, repeating things I've already written and finishing lines, but I have found it has a tendency to make up functions that don't exist.

Likewise, ChatGPT and v0 may produce decent enough code, or they might give you <div>s that should be links. At least v0 seems to be adding labels to form inputs, which is more than I can say for a lot of developers on the web. But that's kind of the issue: people don't write accessible code, so why should we be trusting algorithms trained on other people's inaccessible code to write UI code for us? Vercel say it was trained on code written by their team, but considering the UI for v0 wasn't accessible itself, I don't have a huge amount of confidence that the input source material for the LLM was.

This isn't purely a Vercel problem, of course, it's an everyone problem. But we as developers can make it better by learning how to write semantic HTML and proper CSS, and then training the models on that.

I do believe that LLM-backed tools can speed up the development process and make us more productive, but not through developers indiscriminately pasting whatever they generate into our codebases and trusting that it's all fine. Our users deserve a little more diligence than that.

A good podcast: If Books Could Kill

2023-07-16T00:00:00Z

Michael Hobbes and Peter Shamshiri take us through some of the biggest "self-help"/pseudoscience books from the last few decades and deservedly tear them apart.

Some of the worst relationship books are here – Men Are From Mars, Women Are From Venus, The 5 Love Languages, The Rules and The Game (yes, that dreadful pickup artist one) – alongside pop-economics and pop-psychology rubbish such as Freakonomics and Atomic Habits. One of the funniest podcasts I've listened to in a while, and honestly gobsmacking that these books were so well-received in the first place. I feel like this should be called "Citation Needed: The Podcast".

Beyond Tellerrand: beyond amazing

2023-05-01T00:00:00Z

I had the absolute privilege of opening Beyond Tellerrand Düsseldorf recently. Truth be told, I had no idea what to expect, other than a great conference (from what everyone had told me), but it was incredible! (Apologies to anyone who tried to chat to me on the Monday after my talk – if I seemed a bit distant, it was because I was literally struggling to string words together because of adrenaline and tiredness.) It took me a week to recover from the travel, socialising and speaking, and I went straight back to work so I'm only getting around to writing this now!

From the first conversation with Marc I knew this was something special: he and the Beyond Tellerrand team put so much love into this event, and it really shows. The venue is awesome, the production quality is amazing, and the speakers are treated really well. I arrived at the hotel exhausted after a day of travel to find a handwritten letter from Marc, a beautiful book, and a very useful backpack which will be accompanying me to all my future conferences! The team and the speakers had a wonderful meal the night before the conference, and the first talk wasn't until 11am which meant I didn't have to panic-inhale my breakfast and leg it to the venue for an early start. I never sleep well before giving talks, so the extra time was very welcome.

Photo credit: Florian Ziegler

Speaking of the incredible production quality: Marc got dina Amin to do these unbelievably cool stop-motion videos of our names (by the way, she's the loveliest person and I'm so excited to see her speak at All Day Hey next week). Even more impressive: there were posters for each of our talks, and they were AR-enabled! I managed to get my poster home on the plane, and I've framed it by my desk.

A video showing the stop motion animation of my name with household objects.

Between the talks we had DJ sets from the electric Tobi, incorporating snippets of our talks. It was quite surreal hearing my own voice played back at me as I sat down after I'd spoken!

So, that's my speaker review (100/10 would speak again), but I attended the conference too, so here's my attendee review: incredible vibes all the way through. I think it's actually the first multi-day conference where I've watched every single talk - it was that good. Speaking is incredibly exhausting and usually I have to tap out at some point to either go for a walk or chill out somewhere quiet, but the talks were such high quality that I just couldn't miss them. It's quite the honour to have spoken on that roster!

There were art talks: meditation and the art of Japanese calligraphy with Aoi Yamaguchi, psychedelic slogans and incredible murals from Gemma O'Brien, algorithmic art and machine learning with Mario Klingemann, stories of toasters and living as a goat from Thomas Thwaites, and light painting with the charming Hugh Elliott. The last talk by Eike König was more of a career retrospective which perhaps went over my head a little, but it was still something different.

Opening the second day was Dr Emily Anhalt, a clinical psychologist, sharing her tips for being an "emotionally fit" leader - at times what she was talking about resonated so much with me that I got a bit emotional. I'm definitely taking some of her tips away with me to use with my teams.

Emily Anhalt's list of questions that all teams should answer to work together better.

Then we had some excellent typography-related talks from Scott Kellum and Tobias Kunisch, showcasing the importance of dynamic typography on different size screens, and the power of variable fonts. I actually use variable fonts a bit on this site, but I've never really explored their full potential!

Same.

Joining me in the web dev contingent were my pals Cassie Evans and Michelle Barker, with some brilliant talks on UI animation and modern CSS layout respectively. I get so excited when I see talks like theirs because they remind me what the web is capable of (and that it's really fun!). Michelle is speaking about Modern CSS Layout at All Day Hey this week, I'll be there!

Cassie shares a lovely quote from Miriam Suzanne

All in all, I came away feeling so inspired (and so very, very tired). I can't wait to go back next year.

Painting the whole beetle: an adventure in learning to learn

2023-02-18T00:00:00Z

I'm not very good at being bad at things. In fact, I have a track record of giving up on things if I'm not immediately good at it. (So I guess I'm good at giving up on things?)

Case in point: the piano. There's an electric piano gathering dust on a shelf in my house which was until recently gathering dust on a stand in the living room. A few years ago I started having lessons with a view to being able to accompany myself/my choir, but it was such a challenge to work through being bad at it. I'm a very musical person but my tiny hands made it very difficult to reach some of the intervals, and, well, I just didn't put in the practise because it was so frustrating not being automatically good at it. Of course if I'd persevered, I would have been really good by now, but that's not always how it works in reality.

A lot of this comes from my teenage years: I went to a very competitive school where getting a B was tantamount to a failure and I grew up thinking I was average at everything. It wasn't until I left that school and went to a local college for an extra year that I realised that I was actually good at stuff, and my attitude towards education changed considerably (and I worked hard and did well at both college and university).

("Fun" fact: I only went to that college in the first place to study English Language A-Level, because my school didn't offer it – I was told "the kind of universities our girls like to apply to don't see it as a proper subject". ROTATING YIKES EMOJI.)

As a result, I've tended to stick to things I know I'm good at. Singing. Web dev. Cooking and baking. But when something goes wrong – when the cake I'm making for my gran's birthday doesn't rise properly and it's all dense and underbaked true story – I'll have a meltdown and feel like a complete failure.

So instead of doing something I might be bad at and feeling frustrated, I'm much more likely to camp out on the sofa and play video games, which I can control the difficulty of if it gets too hard.

It's been an uphill struggle to try and unlearn this mindset; to allow myself to be shit at something for a while until I'm good at it. I'm always reminded of the quote from Jake the Dog in Adventure Time:

“Dude, suckin’ at something is the first step to being sorta good at something.”

He's not wrong, but also I struggle to internalise that because of the years of schooling that told me if I'm even decent at something, there's 20 other people in my class who are a LOT better than I am, and who win the awards at the end of the year.

In a fit of uncharacteristic optimism I booked myself onto a one-day "How to paint" class. It always struck me as something I'd enjoy doing: the physical act of painting is really relaxing. I turned up to this class with a determination to lower my expectations of myself, and had the best time. We spent the morning on watercolours, which I had basically no experience with, and then in the afternoon moved on to acrylics. The extent of my experience with acrylics had been a cheap paint set I was sent as part of a team social where I painted a creepy looking Monzo card mascot in the same pose as the HA HA! BUSINESS meme, but I do remember it being very satisfying.

I had a good time with the watercolours but when we moved onto the acrylics I was struggling a bit. At the teacher's suggestion I'd picked quite a difficult reference image: a purpley-green iridescent beetle.

I got about 30 minutes in, and was really struggling to get the colours right, and the highlights were looking really muddy. The leg was pointing out at the wrong angle, and the places where I hadn't applied enough paint looked really rough. I said to the teacher that I thought I might have to give up on this and start a new one but she urged me to keep going with it, and see where it took me.

Two hours later, I had finished my beetle, and it was better than anything I'd ever painted before.

For me, painting the whole beetle was the first time in a long time I hadn't given up when things started to get difficult and out of my comfort zone. I persevered. And amazingly, I discovered I was Quite Good. Especially at blending colours together. The finer detail was difficult and I didn't use enough paint, but the technique was there.

And it occurred to me: I've been painting my own face for 20 years, of course I'm quite good at it.

I don't do it nearly as much these days, but in my late teens to my late twenties I'd do the most incredible colourful eyeshadow looks. I even had a makeup blog briefly, though I didn't persevere with that either! But this is it, this is me putting the time in to learn some base skills that have led to me being able to paint a bit.

Me, circa 2012, doing my best Makeup Blogger face. Serious eyeshadow skills though.

I wasn't always good at it. I can think of numerous occasions where I left the house as a teenager looking like someone had put shoe polish on my binoculars. I've made some questionable makeup choices over the years and the execution has not always been on point, shall we say. But all of this is practise and the blending skills I gained from years of doing my makeup in my bedroom when I was bored have clearly stuck with me.

At the time it didn't feel like an active process of learning, much like when I was first building websites around the age of 10/11. It was a fun thing to do and I didn't really care about the outcome. I remember struggling to understand why my pictures weren't showing up on the page I'd made when I put it on GeoCities, even though I'd added a nice <IMG SRC="C:/Sophie/image.jpeg"> tag.

And then 14 years later when I started learning Java I marvelled about how naturally coding came to me. When I'd been building websites for 14 years. I'd put in the time! I just couldn't see it!

Realistically I know there are very few things one can be naturally good at. Singing is one of those things, but also people who "can't sing" can learn, and even if you've got a naturally good voice it's important to learn how to use it properly so as not to strain it, learn breathing techniques, learn how to sing from your diaphragm etc. People talk a lot about how talented some folks are, but is it really talent or is it skill, honed through years and years of hard work?

It's also very possible to have an aptitude for something, but you've still got to put in the time to learn it. I have an aptitude for languages and always did well in German and Spanish at school/uni, but I'm not anywhere near fluent in any languages apart from English, because I haven't put in the time.

I'm certainly not naturally good at makeup, or baking, or web development. All of these took a lot of time and practise to learn. And I still screw up a lot because you never really stop learning. My eyeliner may look great but you should see the pile of cotton buds I needed to tidy it up.

I spent a bit of time this morning trying out the watercolour paints I'd bought and it took a lot of convincing myself to keep going and not quit as soon as a line wasn't neat enough or the paint was blooming (a bit like a tide mark). But I kept going, and I painted an apple, and it's good for a beginner, and I'm happy that I did it.

This post is not a metaphor; I'm not using this painting experience to dish out some life-changing career advice. For me it's literally about painting. But I know some of you out there will have similar experiences to me, so I guess I wanted to dish out a bit of solidarity and tell you that sometimes with enough determination you can paint the whole beetle too.

Everything should have an API: adventures in trying to automate stuff

2023-01-24T00:00:00Z

Inspired by Robb Knight I want to build my own /now page. As a teen I used to use PHPCurrently on my personal website to list what I was listening to, thinking, feeling, even what my MSN display picture was. Here's an objectively terrible screenshot from peak Evanescence phase, circa 2004.

I have grown up a bit since then, thankfully.

And just as Robb did, I want to automate as much of it as I possibly could. No matter how many apps I try for tracking books, games, TV etc., I always forget to actually update them. Everything I do requires a sign-in these days, and it's all internet based, so why shouldn't I be able to automatically generate a page based on the data these companies have on me?
In short: they don't let you access it. Netflix, Nintendo, Kobo, PSN to an extent: there's no simple way of getting your history out of these apps. And most of the third-party apps that let you track your history, like GameTrack, have no way out.

At the time of writing this I haven't cracked it, but I'll share my findings so far because I'm sure I won't be the only one who wants to do this.

If anyone has any suggestions, let me know via Mastodon or email!

Games

Steam has an API because it was historically for nerds (source: am nerd), but I also play a lot of PlayStation and Nintendo Switch.

I tried using rawg.io which connects to your PSN account, but it doesn't have a personalised API (just an IMDB-style one for game info) and scraping didn't work because the whole site is a single-page app so the content isn't there without JavaScript. It also only logs what games you have, not what you've played recently - you have to do that bit manually.

Nintendo has no API at all, and no public profile pages, so there's no way of logging what you've been playing that I can find.

Robb scrapes his latest trophies from psnprofiles.com as a workaround, but I'd really like date-based data.

Music

This bit is actually pretty easy, even being an Apple Music user. I dusted off my old Last.fm account and downloaded Marvis Pro. This is like a layer on top of Apple Music with a better interface and automatic Last.fm scrobbling. (There is an official Last.fm app for iOS which picks up Apple Music plays, but it's got limitations and you have to scrobble semi-manually.)

I can then render that data pretty nicely using Robb's script.

Books

I stopped using Goodreads in 2020 when I de-Amazonified my life as much as I could, so I haven't been tracking what I'm reading. I have a Kobo eReader, sometimes I buy books from their shop, and I borrow a lot of books via Libby/OverDrive. OverDrive does apparently have an API, but I'm not sure how easy it'll be for an individual to get access. So manually tracking it is.

Manually tracking books

Two apps were recommended to me recently: Oku and Library Thing. (Side note: I love the two completely different aesthetics of these sites: Oku looks like someone copied the CSS from Notion, and Library Thing transports me straight back to 2003.)

Oku has an RSS feed for every user collection, which means I can easily grab the feed for "currently reading"! The feed also contains metadata like cover image, so I'll be able to render the books nicely (though quite a few books appear to be missing covers in their database). Its search is pretty bad, but if you feed it an ISBN it gets the book straight away.

LibraryThing has better book data and it does have APIs, but they're disabled right now and it's unclear if they're going to turn them back on again, so that's a dead end (at least for now). So Oku it is. Let's see if I remember to track what I'm reading this time.

Podcasts

My podcast app of choice is Pocket Casts, and there appears to be no official way of getting listening data out of that. But there does seem to be an API somewhere, as some folks have reverse engineered it. Authentication looks a bit dodgy (not about to store username and password anywhere) so I'll have to figure out how long that authorization token lasts.

If anyone knows a better podcast app for gathering this kind of data, let me know!

Recipes

I'd love to log what I've been cooking this week! On the weeks when I have my shit together I plan what we're going to cook using Paprika (where I store all my recipes - about 3000 of them!) - this is ripe for automation. Sadly, the app is pretty much "done" in as much as they don't add new stuff to it any more, and there's no API or anything. I've considered switching to Pestle, but there's no MacOS app yet which is unfortunately a dealbreaker for me. So it might have to be a manual process for the time being.

Paprika does have a calendar export option, where it provides a calendar feed of planned meals. I wonder if there's any way of intercepting that.

TV & films

Again, plenty of apps here for manually tracking what I'm watching, but no way of getting the data out that I could see. However, in my search today I found Trakt which does have a public API!

Part of the fun with such data is making it available for anyone to mash up and use on their own site or app. The Trakt API was made just for this purpose. It is very easy to use, you basically call a URL and get some JSON back.

That's what I'm talking about! Why bother tracking what you're playing/reading/watching if you can't then do fun stuff with that data? Recommendations are useful enough, but this is the good stuff.

The interface is confusing at best, and it's surprisingly fiddly to mark things as watched. It thinks I watched all 9 seasons of Breaking Bad today, as I marked them as watched in one tap.

Again, the biggest downside is I have to track manually, but at least that way I don't accidentally reveal to everyone that I'm three seasons in to Emily in Paris. But ultimately I'm not sure if I'll be able to stick it out (the app, not Emily in Paris).

Conclusion

At this point I can only conclude that I've spent longer investigating how I can automate this than I would have done manually updating the /now page once a week. But it's also a matter of remembering/having the energy to update it. I can guarantee you I'd update it twice and then leave it for several years.

It frustrates me how easy this would be if all these services had APIs that you could just pull your own data from. If our lives are online now, and our data is helping them personalise their services and make more money through recommendations, the least they could do is provide that data in a consumable format. It's not exactly feasible to do a monthly DSAR to get my Netflix viewing history.

I miss Twitter

2023-01-14T00:00:00Z

I'm still sad about Twitter.

I think what has emerged for me since switching to Mastodon is an altogether healthier relationship with social media. I'm not checking it constantly and I'm not obsessing over how my tweets are doing. I can post things without worrying that idiots have saved searches for key words/names and are going to come and shit all over the replies.

And it feels pathetic to be mourning the loss of a social media site. We know social media is Bad and the algorithm is Bad and it's all just late stage capitalism Bad Bad Bad. And there are plenty of people on Mastodon celebrating its demise.

But I miss it. I miss the vibes of tech Twitter, I miss the community feel that I just haven't felt on Mastodon in the same way. I'm worried that not having a Twitter presence is going to affect my speaking career and mean I don't get as many conference invitations. I'm angry that one billionaire man-child was able to take this community away from us.

There are still quite a few people sticking around Twitter as it clings on for dear life but I just can't bring myself to go back to a site that's unbanned some really high-profile transphobes, bigots, misogynists and racists. And a literal human trafficker, it turns out.

Mastodon is fine I guess

While it's been a generally positive experience so far, IMO Mastodon isn't quite the paradise that people have made it out to be: as a platform (decentralised though it may be) that was relatively tiny for a long time before suddenly blowing up recently, I've encountered some users on there who resent that and think that if you're new, you shouldn't have an opinion. In a way I get it: Twitter's demise was the start of Mastodon's Eternal September. But let's not kid ourselves: Mastodon still has mansplainers, it has racists, it has arseholes. It's just harder for them to find your posts.

I saw one post about how people should put politics-related content under content warnings (CWs), and when I disagreed (because politics is people's lived experience) the author told me that I'd only had my account a few weeks and that I should listen to the people who had been there for years. And that anything about Black people being silenced/experiencing racism on Mastodon had been "proven to not be true". They provided no evidence to back this up - I know, I'm as shocked as you are.

Notably, in the two months I've been on Mastodon my feed has remained predominantly male and white, despite trying to diversify my follows. A lot of people I followed initially have returned to Twitter as their other communities (e.g. Black Twitter, trans Twitter) have remained there.

Shouting into the void

I miss the reach I used to have on Twitter. Talking about issues I cared about, like semantic HTML and mental health, and knowing that lots of people would see it (even if generally I got more engagement on the shitposts).

Glad as I am that the personal website is having a renaissance – you know how much I love personal websites – for me that fulfils a different function from sites like Twitter. This site is my own space on the internet, but it's me shouting into the void in a way that Twitter wasn't.

Mostly I'm just sad that we lost the community that we had. And I hope we can rebuild it somehow.

2022: The year in lists

2022-12-30T00:00:00Z

I don't usually do these end-of-year reflection posts, but at a time where I feel like I'm finally starting to hit flat land again after a year of climbing hills, it seems like a nice thing to do, and a way for me to reflect on my own achievements.

I've spent a lot of time mulling over the bad things that happened this year so I want to focus on the good stuff.

For that reason, there won't be much mention of COVID. I want to make it perfectly clear that I see it as very much still a thing, I got it for the first time this autumn and it completely wiped me out. Now that the post-COVID immunity has worn off somewhat, I'll once again be wearing masks in crowded places and on public transport well into 2023.

Skip to bits you care about:

The year in...

The year in...

...career decisions

Last year was the year I left my job at Monzo and joined a startup, and this year I did the opposite. I made some tough decisions and got really burned out, but coming back to Monzo in August was amazing and has been just what I needed to help me understand more about what I want out of my career. Thankfully, I've recovered from the burnout I was suffering from earlier this year.

...conferences

This year I found myself speaking at seven conferences... and attending one!

In March, I showed CityJS London how to build a virtual "piano" with the Web Audio API.
In April, attending All Day Hey in Leeds made me fall in love with the web all over again.
In May I took my virtual piano talk to my first international conference, BeJS in Brussels!
In June I spoke at UX London about the importance of clear writing in product development, based on a blog post I'd written for incident.io.
In July I opened FullStack eXchange in London with a keynote about the history of personal websites. My laptop completely crashed at the beginning of the talk, so I had to restart my computer while everyone watched...!
In October, from the glorious Barbican Centre in London, I showed the lovely folks of State of the Browser 2022 how to build a website like it's 1999.
In November I achieved a career goal of speaking at FFConf in Brighton, delivering a love letter to the personal website. It was everything I'd hoped for, and I'm so proud of it. If you've never been, it's one of the loveliest communities around.
And finally in December – the week before Christmas! – I travelled to Málaga in Spain for the inaugural WeyWeyWeb to play that virtual piano again, this time with added Web MIDI. I very nearly didn't make it thanks to a combination of train strikes and snow, but I'm glad I did!

At times I was a bit overwhelmed with conference prep, but ultimately I had a great time, and I can't wait for the conferences that 2023 will bring. (my inbox is always open!)

...travel

International travel picked up again this year, with trips to Brussels and Spain for conferences, and Scotland, France and Iceland for holidays.

Iceland was absolutely incredible, I really can't recommend it enough. A week of driving around, taking photos and being surrounded by the most incredible landscapes I've ever seen.

Skógafoss, Iceland

Sunset at Akranes

I finally got the Eurostar (to Brussels) for the first time since it's been at St Pancras and honestly I now see why everyone's so obsessed with it. It's SO GOOD.

I also spent some time in Suffolk with friends, and we went birdwatching at RSBP Minsmere, where we saw an amazing murmuration of starlings!

Murmuration at RSPB Minsmere

...books

Last year in an attempt to de-Amazon my life a bit I swapped out my Kindle for a Kobo Libra, which has built-in Overdrive support. So I've been enjoying renting ebooks from various local libraries!

A few of the novels I particularly enjoyed this year:

The Four Winds by Kristin Hannah
The Seven Husbands of Evelyn Hugo by Taylor Jenkins Reid
Going Postal by Terry Pratchett
The Book Thief by Markus Zusak
If I Had Your Face by Frances Cha
The Dictionary of Lost Words by Pip Williams
The Song of Achilles by Madeleine Miller
How Beautiful We Were by Imbolo Mbue
Free Food For Millionaires by Min Jin Lee

In the last month or so I picked up a copy of The Staff Engineer's Path by Tanya Reilly. It's full of really useful advice and scenarios for anyone who's either looking to get to Staff, or understand more about what that role entails. Since it's a work-related book it's not the kind I tend to devour in an evening, so I'm making my way through it VERY slowly, but it's definitely a useful one.

...music

I can't listen to music with lyrics while I work, so it's lo-fi beats to relax and/or debug to all the way, but here are some particularly good albums (new and old) that I enjoyed this year. It seems to be 2003 again with some of the new releases and I'm honestly living for it.

Carly Rae Jepsen – The Loneliest Time Album of the year 1000%. If you still think she only did "Call Me Maybe", do yourself a favour and listen to her last three albums.
Wet Leg – Wet Leg Superb mid-00s style indie.
Maggie Lindemann – SUCKERPUNCH – Evanescence meets Avril Lavigne meets my teenage self. Makes me feel old, but it's a vibe nonetheless.
Editors – EBM
MUNA – MUNA
Caitlin Rose – Cazimi – her 2013 album The Stand-In is one of my all-time faves
Lacuna Coil – Comalies XX – rearranged and re-recorded versions of the original. The new version of Swamped is everything.

...video games

One thing that didn't change this year is that I played a shit-ton of video games. Here are some highlights.

Horizon: Forbidden West – Horizon: Zero Dawn is one of my all-time favourites, and this didn't disappoint! The world-building is incredible, it's absolutely stunning, and I love hunting around for datapoints to discover even more lore.
Tunic – lovely Zelda-esque game with some REALLY creative puzzles. Really loved this one.
Tiny Tina's Wonderlands – based on my favourite Borderlands 2 DLC, Tiny Tina's Assault on Dragon Keep, this was a delightful (and hilarious) D&D-themed action game. Borderlands remains the only FPS-style game I've ever enjoyed. Disappointing DLC that I didn't even bother with, but I got a lot of hours out of this game!
Cult of the Lamb was great fun for a while, but also had some serious bugs that made the game really frustrating (these have been patched now). It also finally got me to like roguelikes, which resulted in me finally playing...
Hades. I'm pretty bad at it, but everything about this game rules.
Deathloop was a lot of fun, even if I did enable a LOT of accessibility settings! Fascinating story, great setting, and very clever puzzles.
TOEM: A photo adventure which was extremely cute and I loved it
Carto – wonderful little indie game
Chicory: A Colorful Tale – a lovely allegory for depression and making the world seem more beautiful again.
Stray – another vote for beautiful world-building and lovely storytelling.
It Takes Two – hooray, finally a couch co-op game! The story was absolute dogshit and we hated everyone in it, but the gameplay was excellent and made up for it all. Really, really creative co-op.
Shamefully I've only just started Return to Monkey Island, but I'm loving it so far obviously, even if the new art style is a little jarring and I miss being able to make Guybrush say "I'm not picking that up."
I've also spent the last few weeks replaying Skyrim – 11 years later! – and it still holds up. Incredible. You could probably run it on an electric screwdriver at this point. (Still buggy as shit though, even on PS5)

I've noticed that game devs have been adding a lot more accessibility settings to games in the last few years. Accessibility isn't just about being able to play games if you're disabled, it's about everyone being able to enjoy the game. I'm... aggressively okay at video games, and so for games like Hades and Deathloop that have really challenging combat, the only way I can get through it without dying over and over and over again at the same place (and inevitably rage-quitting) is to turn the difficulty down. I don't always want to play on easy mode, though. Lots of games now have more granular accessibility settings, so you can turn down the damage you receive, or make it so that you get a little stronger every time you die. This means I don't feel like I'm walking through the game with no challenge at all, I can still enjoy the story, and play it at a level of challenge that suits me.

...learning things

Some of the things I learned this year:

how to create shadow effects with CSS perspective
how to use the Web MIDI API to hook up a MIDI controller to the browser
basic music production – recording, mixing and mastering
about the CSS function clamp()
how to make okonomiyaki and takoyaki

...blog posts

I wrote a whopping SIX posts this year! It may not sound that much, but it's a record since I've had this site. I'm hoping I can keep momentum going into next year.

Start at the beginning: the importance of learning the basics – frustrated with the number of people advocating for skipping learning HTML/CSS and just doing React/Tailwind, I wrote this article about why that's a terrible idea.
Burnout, a cautionary tale (and a plea to take a break) – I'd taken a break from work, as I was in a bad place and completely exhausted.
When going back doesn't mean going backwards – the successor to the previous post. Going back to my old job, and feelings about everything that had happened.
Everything I googled in a week as a senior software engineer – an updated version of the original I wrote in 2019, to show that I still google everything!
Building a website like it's 1999, in 2002 – the written version of the talk I gave at State of the Browser this year. It went pretty viral a few days ago as someone posted it on Hacker News, which was both cool and terrifying.
Preparing for conferences – a summary of my process for preparing to give a conference talk, from talk preparation to delivery.

...the web

I left Twitter for Mastodon, and I'm not actually sure I like it more than Twitter. But I don't want to go back to a platform that's unbanned some of the most detestable people in recent history.
I joined omg.lol, and you should too. Until 1 Jan 2023, it's $5 a year for a pastebin (paste.lol), URL shortener (url.lol), Mastodon instance (social.lol), email forwarder (@omg.lol) and soon a weblog (weblog.lol)! I now have a fancy "web card" I can link people to if they want to get in touch. It's just lovely vibes all round.
It feels like there's been a bit of a personal website resurgence, which is lovely – especially considering the topics of the talks I've given this year! I gave this site a bit of a facelift, with five new themes including some very silly ones. I also moved it to neocities and joined some webrings because WHY NOT.

There you have it

It's been nice to spend some time reflecting on the good things that happened this year despite all the bad. I'm hoping to keep the conference momentum going, so if you know any that are looking for speakers, let me know! Here's hoping 2023 brings new opportunities and more personal website joy.

Preparing for conferences

2022-12-14T00:00:00Z

I've been speaking at conferences and meetups on and off for nearly five years now, and a few people have asked me what the process is for preparing a talk. So I thought I'd share how I approach it.

For me, the talk process is a circle:

It's the circle of talks.

It repeats around and around forever. There is always a point at which I hate my talk and wish I'd never done it, but there is also always a point where I'm having the time of my life. Giving talks is great fun, but it's also hard work.

(As a sort-of aside: that hard work is why you should never speak at a conference that isn't at least paying for your travel/accommodation or taking you to dinner. Your time is worth money.)

I'll break my process down into a set of steps, but the tl;dr is: practise. Your audience deserve to watch a talk that you've rehearsed and aren't just making up on the spot. Not only will it show if you haven't practised, you're much more likely to run over time as well. The practise part isn't optional!

The timelines are super rough, but generally I'd start around 2-2.5 months before the talk. I've done talks in shorter timeframes than that, but I wouldn't recommend it – taking longer means I don't have to dedicate all of my free time to it, I can space the work out a lot more.

Initial planning: about 8-10 weeks before the conference

To begin with: identify the overarching theme(s) of the talk. What are the main points I want to convey? No more than 3 or 4.

I make short-form notes for content ideas – bullet points or post-it notes – jotting down any ideas that come to mind, and sorting them into themes afterwards.

Previously, I've used notecards blue-tacked to the wall with ideas on, so I can shuffle them around and group them.

At this point, I'll also do research. Depending on the topic, I might read blog posts, articles, I even read someone's PhD thesis once. I might pull out some good quotes, or just write down some general ideas from those.

Content: about 6-8 weeks before

Taking my notes, and writing more detail for each point in a Notion doc. What do I have to say about each of these ideas? Sometimes I spot how they flow into each other, or I might find that one of them doesn't fit with the others any more after I've written some blurb.

I treat it a bit like a blog post at this point, writing as if I'm talking to someone. It helps me to solidify my ideas as a talk rather than just random sentences.

Slides: about 4-6 weeks before

Depending on my needs, I'll either use Keynote or Google Slides. I prefer Keynote, but if I need to be able to switch to a browser quickly, Google Slides is better. I used Reveal once which was useful for code and embeds, but it took me ages to build the slides so I probably won't use it very often.

The first version of the slides always has the notes containing the full sentences from the content planning stage, because I'll use these for the first few run-throughs.

If my talk needs any code snippets, I'll screenshot them from VSCode so they look pretty (or, if I'm using Reveal, I'll put them straight in the slides).

This part is also about editing, editing, editing. Especially for shorter talks, it's as much about what you leave out as it is what you put in.

Not gonna lie: at this point I start to hate my talk. I'll come around to it again, but right now I'll be fed up with it and full of regret. It's really hard work, and I find making slides pretty tedious. Prepare to have some moments like this – it will get better, though!

Run-throughs: from 3-4 weeks before

Early on, I'll run my slides through with my husband who's usually pretty good at spotting things that don't fit, or things I can leave out. I always recommend doing a run-through with a partner, friend or colleague!

I sometimes run talks at work as well – we have a weekly slot for engineering talks that anyone can give. If you don't have that, perhaps you could introduce it at your company?

I'll do three or four run-throughs a week, after work, where I shut myself in our little office and just deliver the talk to nobody. When we have a dog staying, it's a bit easier as I can give the talk to him. (He's never particularly interested in what I have to say, though.)

The week of the conference

I don't tend to practise my talk in the days leading up to the conference. Often it's because I'm travelling or busy in the evening with a speakers' dinner. But I also think it'd just stress me out. By the time the conference arrives, I've practised it enough that I feel happy with it.

Delivering the talk

I'm not going to go into a huge amount of detail here – the post I wrote when I was preparing for my first conference in 2018 covers a lot of that ground – but the main thing I've learned is that I get super nervous as I'm waiting to go on stage, and then when I get on stage it just goes away and I have a great time.

If you've practised enough, you shouldn't need to stare at your speaker notes – just glance at them for a prompt. Sometimes you'll find you won't need to look at them at all.

Afterwards, you'll probably feel amazing and want to do more talks, and thus the cycle starts again. (Conference organisers: I'm at my most suggestible in the week after I've just given a talk.)

Building a website like it's 1999... in 2022

2022-10-23T00:00:00Z

Edit May 2023: the Bridgy integration with Twitter no longer works due to Twitter shutting off API access so some functionality won't be working any more!

Note: This is a written version of a talk I gave at State of the Browser 2022 in October 2022!

Motion warning: This page contains quite a few animations, but if you have reduced motion turned on, they won't play.

The web used to be weirder

I'm on a bit of a mission this year to bring back the spirit of the old web. The creativity and flair of the late 90s and early 2000s. Back then, there were no rules – you put whatever you wanted on a webpage, because it was your space to do as you please.

And for a whole generation of internet users, having a website was the cool thing to do. It's just what you did back then. We're talking pre-social media, pre-web 2.0 – the good old fashioned static personal home page.

Sites like Geocities, Angelfire, Tripod and Expage offered free static hosting for all, and the number of personal websites boomed. Some hosts offered drag-and-drop website builders so you didn't even have to learn HTML.

We might look back on these websites now and laugh – they look ridiculous compared to the sleek and minimalist sites we're used to nowadays. But I actually think we've gone too far in the other direction, and now so many websites look the same. These old personal websites were a reflection of yourself.

Some of these websites were for family to share photos and updates...

The Proud Grandparents Page

...while others were full of graphics to share and use on your own site...

Lisa's Graphics

...and some were fansites. Look at those frames! I got this screenshot mid-<marquee>-scroll as well.

Mognet Central

I played a game a couple of years ago called Hypnospace Outlaw, which is a completely bonkers game where you're a moderator of a version of the 90s web that you access in your sleep. The homepages in this game were directly inspired by Geocities websites (there's a really good episode of Noclip about it) and it made me so nostalgic. I really recommend it if you haven't played it already! It really captures the spirit of the time – the personality and weirdness that made these sites so special.

Hypnospace Outlaw

Let's bring back the weird

I'd love to see this spirit return today – the experimental and fun side of the web. My goal is to show you how we can be just as creative today but using modern and accessible methods. Because, as fun as they were, old websites were a nightmare for accessibility. We didn't really use semantic HTML, we used tables for layouts (instead of, y'know, tabular data), everything was constantly flashing and moving. Luckily for us, the modern web allows us to be just as creative while still considering the user at the other end of the browser.

So naturally, I built a 90s-style website, with some of my favourite old web tropes. I used as much modern HTML, CSS and JS as I could. Let's take a look through some of the features and how we might recreate them!

Sophie's Homepage

Animated GIFs

GeoCities sites were absolutely littered with GIFs. Flames, construction workers, dividers, even animated bullet points. Animations were a lot of fun, and almost an art form to squeeze so much into such a tiny filesize.

This is a screenshot from cameronsworld.net, which is a beautiful archive of GeoCities GIFs, and an artwork in itself.

Nowadays it's easier than ever to put animations on our sites, whether that's still the humble GIF (internet is so much faster these days), more modern formats like webm and gifv, or even SVG animation with CSS or libraries like GreenSock. But we can do better still.

The standard code to include an image hasn't changed much since the olden days:

<IMG SRC="flames.gif">

In those days, of course, we wrote all our HTML in capitals because that was what you did for some reason. XHTML, maybe? Anyway, the consequence of this is that everyone sees the GIF whether they like it or not. For people with epilepsy, vestibular disorders, or anything where motion causes sickness, autoplaying GIFs are a big problem. Luckily, wcan fix this today, with something we didn't have back then!

The `prefers-reduced-motion` media query

Using this media query, we can only play the GIF if the user doesn't have reduced motion turned on on their computer – so everyone can enjoy our trash website, regardless of their access needs.

Harnessing media queries with the `picture` element

The HTML5 picture element allows us to specify an image, and then potential alternative sources for it.

	<picture>
    <source srcset="underconstruction.gif" 
    media="(prefers-reduced-motion: no-preference)">
     <img src="underconstruction.png" 
    alt="Under construction" />
  </picture>

In the above code snippet, we've got the img tag as before, but this time it's showing a still version of the GIF, which I made by opening the GIF in Preview, pulling out the first frame and saving it as a PNG. The source tag contains the URL of the GIF, and will only kick in if its media attribute is satisfied. So if you don't have reduced motion enabled, the source of the image will be replaced by the animated GIF version. Magic!

Text effects

Remember <marquee>? It made text scroll across the screen, like ticker tape.

Wheee!

Or those of you with Netscape would have had the infamous <blink> tag, which makes text blink in and out of view...

This is awful

Ultimately, text effects like this don't belong in body text. Even if you don't have any access needs to speak of, it makes reading text really hard. There's a good reason they were both deprecated.

Instead, I thought, why not have fun with headers? In days of yore we'd make cool text-based headers in whatever graphics programs we could get our hands on – or even just MS Word. Text with flames, rainbow fonts, you name it.

These days we can recreate this magic using CSS instead of using an image! And the great news is, because it's normal text with CSS doing the heavy lifting, it's still totally accessible.

For my next trick, I'm drawing inspiration from an OG 90s classic: Microsoft WordArt.

WordArt, but make it CSS

While not strictly from the 90s web, WordArt for me harks back to the aesthetic of 90s maximalism, and definitely fits aesthetically with what I'm trying to do.

I'm going to show you how to recreate two of my classic favourite WordArt styles using modern CSS.

Gradient-fill text with `background-clip`

You can't colour text with a gradient (yet) in CSS, but you can give an element a gradient fill background. Using the background-clip property we can control where the background shows. Specifically, we can set background-clip: text to make the background only show wherever there's text in the element.

Then, if we make the actual text transparent, only the gradient background will show through.

background: linear-gradient(183deg, #6000CA 10%, #CA00CD 70%);
background-clip: text;
-webkit-background-clip: text;
color: transparent;
font-family: 'Impact';

WordArt

Pretty!

Then let's add a transform property to make it look a bit more like the real deal.

transform: skewY(-8deg) scaleY(1.3) scaleX(0.8);

WordArt

Adding the drop shadow

Now we need to add the light purple drop shadow. But if we try to use the text-shadow property, it shows up on top of the text!

WordArt

This is because we're really looking at the background – the actual text is transparent and sitting on top. If I change the colour of the text to the body colour, you'll see what I mean:

WordArt

To get around this, we'll need a wrapper element that contains the shadow, so it appears behind the text-shaped gradient background.

<span class="purple-wordart-wrapper">
	<span class="purple-wordart">WordArt</span>
</span>

We'll add a drop-shadow filter to the wrapper element. This adds a drop-shadow the same shape as the element's children, and because the background is clipped to the text in the child span, the drop-shadow will follow that shape too!

.wordart-wrapper {
	filter: drop-shadow(2px 2px 0px rgba(130, 140, 251, 0.8));
}

The result:

WordArt

Uncanny!

For my second WordArt recreation, I'm bringing back my old childhood favourite – the rainbow one. I remember using this one all over my primary school homework.

We've got another gradient fill here, so we'll use background-clip: text again to get the same effect, and chuck on a transform to get the right shape.

background: linear-gradient(
  90deg,
  #9c00ff,
  #ff0000,
  #ff8800,
  #ffff00,
  #02be02,
  #0000ff,
  #4f00ff,
  #9c00ff
);
background-clip: text;
-webkit-background-clip: text;
color: transparent;
font-family: 'Arial Black', sans-serif;
font-weight: bold;
transform: scaleY(1.5) scaleX(0.6);
transform-origin: left;

WordArt

We'll use a wrapper element to create the shadow again, but this time it's a little different. This has more of a 3D effect, where the shadow kind of flattens and goes to the left, as if we're looking at the WordArt from the front.

CSS can do that!

Getting some perspective

.wrapper {
  font-family: 'Arial Black', sans-serif;
  font-weight: bold;
  display: inline-block;
  position: relative;
  perspective: 150px;
  perspective-origin: bottom center;
}

We can use the perspective property to put us into a kind of "3D mode". It tells the browser, "act as though I'm standing this far away from the element". In our case, 150px.

We then set the perspective-origin property to determine what position we're looking at the element from. I want it to seem like we're in front of it, at the bottom.

What this will do is change the way that transformations apply to the element, taking into account the perspective to manipulate it along the Z-axis as well as X and Y.

To create a shadow effect I'll target the wrapper::before pseudoelement, and set its content to "WordArt" to mirror the text. This will make the "shadow" text appear behind the rainbow gradient. Then I'll apply some transformations to skew the "shadow" – that perspective property on the wrapper element will change the way it rotates and skews.

(This one needs a bit more hacky wrangling when you change the font size, and I use fluid typescales so I'm going to embed a Codepen a bit further down instead of rendering it inline!)

.wrapper::before {
  position: absolute;
  content: 'WordArt';
  color: #000;
  opacity: 0.2;
  bottom: -2rem;
  left:35%;
  transform: rotateX(60deg) skewX(65deg) 
  scaleY(2.8) scaleX(0.9);
  transform-origin: bottom right;
}

Right now, the CSS is hardcoded to have a shadow that says "WordArt". If we want to use this text style for other things too, how can we dynamically set the shadow text content? With the CSS attr() function!

attr() gets the content of a given attribute for an element. I've called mine data-content. So, in our wrapper::before rule, content: 'WordArt' becomes content: attr(data-content):

.wrapper::before {
  position: absolute;
  content: attr(data-content);
  color: #000;
  opacity: 0.2;
  bottom: -1rem;
  transform: rotateX(60deg) skewX(60deg) 
  scaleY(2.8) scaleX(0.8);
  transform-origin: bottom right;
}

And render the HTML with the attribute:

<span class="rainbow-wrapper" data-content="Rainbow">
  <span class="rainbow">Rainbow</span>
</span>

Now we can write different words!

See the Pen Rainbow text by @sophiekoonin on CodePen.

It's not perfect, but I think that looks good enough for a throwback site header!

Music

In 2001, I had a NeoPets shop. As soon as you loaded the page, you'd be greeted with the dulcet tones of Teenage Dirtbag, in MIDI form.

<EMBED SRC="mysong.mid" HIDDEN="true"
    loop="yes" volume="10" autostart="true">

Autoplay, naturally, and looping. Definitely hidden, so the music was just there. But it was super distracting, quite disorientating, and you couldn't turn it off.

Modern browsers block autoplaying audio, for good reason. It's extremely annoying. Thankfully, the HTML5 audio element gives us a bit more control.

  <audio aria-label="Play music" controls 
  src="/soundtrack.webm"></audio>

You can still have audio on your website! Just make it opt-in. If it's part of the experience you want to create, that's totally fine, as long as your viewer is okay with it playing.

Make sure to add a label – whether external or aria-label – to tell the user what it does.

The controls that show up are the browser default – what's rendered above will look different depending on whether you're in Chrome, Firefox, etc. But you can use the Web Audio API to customise the controls, by rendering some pretty buttons and using JavaScript to make them control playing audio.

Cursor trails

Then: Dynamic HTML

Back in the day, a cursor trail was a real flex. It said, "look at what I can do with JavaScript!". (Or in my case, what dynamicdrive.com could do with JavaScript.)

This was known as Dynamic HTML: not necessarily a technology in its own right, but a collection of technologies (a bit like we use the term JAMstack now). HTML, CSS and JavaScript – but a very old version of JavaScript. Everything was client-side at this time, because we didn't have AJAX/client HTTP requests yet. And the implementations differed significantly between the two major browsers of the time, Internet Explorer and Netscape. (This is a period known as the 'Browser Wars', and there's a good summary of it on The History Of The Web.)

It led to stuff like this, from a Dancing Stars animated cursor trail. This cursor adds a trail of seven 3px-wide yellow "stars" (tiny squares) that appear to follow your cursor around. I can't show you a preview, because the script doesn't work any more.

First we had to check whether the script was running in IE, or Netscape, because the implementation would be completely different. In IE, we'd check for the existence of document.all, a function which returned all the elements in the DOM.

If this was present, we'd then call document.write (a function we also shouldn't use any more) to insert several little 3px <div> squares into the DOM.

if (document.all) {
  document.write('<div id="starsDiv" 
  style="position:absolute;top:0px;left:0px">')
  for (xy = 0; xy < 7; xy++)
    document.write('<div style="position:relative;
    width:3px;height:3px;background:#FFFF00;
    font-size:2px;visibility:visible"></div>')
    document.write('</div>')
}

Netscape didn't have divs, it had LAYERs. This is basically the same thing with a different name, because browser creators at the time liked causing pain.

(Side note, this is why some people used to refer to divs as "div layers" – it encompasses both elements.)

<LAYER NAME="a0" 
  LEFT=10 TOP=10 
  VISIBILITY=SHOW 
  BGCOLOR="#FFFF00" 
  CLIP="0,0,3,3">
</LAYER>
}

If document.layers returned something, we knew we were in Netscape, and could do Netscape things. In this case:

if (document.layers) {
  window.captureEvents(Event.MOUSEMOVE);
}

The full script is available at DynamicDrive.com.

Now: Canvas and `requestAnimationFrame`

Tim Holman has done the hard work for us here, and recreated 90s-style cursor effects with modern JavaScript and HTML.

Video of a cursor trail with many small coloured stars following the cursor. Download the video as .webm

Tim's cursors use canvas, which is much more performant than rendering individual elements into the DOM. You also get much more fine-grained control over how elements are positioned. Can you imagine trying to render this many stars into the DOM in the old script? Using the canvas API and requestAnimationFrame – the function that allows us to batch up animations and efficiently update them before the browser's next repaint – we can render lots of little stars, making them fade in and out in lovely ways.

Media queries work in JavaScript, too!

Of course, cursor trails mean animations, and not everyone wants to see those. The good news is, we can use media queries in JS, just like we do in CSS and HTML <source> tags.

const prefersReducedMotionQuery = 
	window.matchMedia('prefers-reduced-motion')
					
if (!prefersReducedMotionQuery.matches) {
	cursor.init()
}

By calling window.matchMedia with the name of the query we're interested in (prefers-reduced-motion), we can check the value of the user's motion settings and only init the cursor if they don't have reduced motion enabled.

You can even add an event listener to the media query, so that when its value changes we can dynamically initialise or destroy the cursor accordingly.

prefersReducedMotionQuery.addEventListener('change', () => {
	if (prefersReducedMotionQuery.matches) {
		cursor.destroy()
	} else {
		cursor.init()
	}
})

Webrings

In the days before search engines were particularly good, how did you find similar websites? Webrings, of course. A webring is a collection of websites based around a shared interest or topic. Webrings offered a sense of belonging to a community, and gave you a fancy plaque to put on your website.

Each site in the webring would have a plaque like this so you could navigate the ring, and there'd be a backend somewhere (probably written in Perl) that did all the hard work of calculating which site came where in the ring.

I built my own webring for State of the Browser 2022 attendees, with a Google Sheets backend (for time-saving/live demo reasons) and a Cloudflare Worker on top of that to work out which site to send people to. It checks the value of request.referrer to see where the call is coming from, looks up that URL in the list of sites, and returns the next or previous one accordingly.

async function handleRequest(request) {
  const { pathname } = new URL(request.url)
  const data = await fetchAndParseCsv()
  const referrer = request.referrer
[...]

For something a little more permanent/professional, I recommend checking out Max Böck's webring kit.

Guestbooks

Last but not least, the humble guestbook! In the days before social media, this was how we showed our appreciation for webmasters. Rather than just building a guestbook I thought I'd do something a little different for the talk. It's a guestbook all right, but it's powered by Twitter!

View the guestbook

Instead, I used a technology called webmentions: a protocol to notify a website when someone else links to them, such as on their own website or on Twitter. Webmentions are collected as a feed (a bit like RSS) and associated with a domain name or host. I put meta tags in the head of my site to indicate that I'm on the lookout for webmentions.

I use webmention.io to collect those webmentions for me, though it's totally possible to set up your own server to do so. On this website (localghost) I collect webmentions at build time and publish them underneath the pages, but on the demo website for this talk I have a client-side script to fetch mentions as I wanted to be able to demo them live.

I use brid.gy to collect mentions from Twitter and send them to webmention.io, and then my site queries webmention.io to get the feed of mentions.

Go forth and build weird stuff!

The web is an amazing platform brimming with opportunities to be creative and experimental. I'd love to see what you build – if you mention this page on your own site or Twitter, the webmentions will appear below, or tag me @type__error!

Everything I googled in a week as a senior software engineer

2022-10-15T00:00:00Z

Three years ago I wrote a post called Everything I googled in a week as a professional software engineer, and it clearly resonated with people, because it went pretty viral. It still gets most of the pageviews on this website.

Well, a lot has changed in three years: I got promoted and I'm now a senior engineer and lead the web engineering discipline at Monzo. But one thing hasn't changed: I still google a lot, every single day. Here's what I googled in a week, 2022 edition.

Obvious disclaimer: this is slightly edited as I've removed most of the non-work-related ones.

Some of these search terms might make you laugh and think "how did you not know that?". Well, there are several reasons you might not know something (choose all that apply):

you've never used it before
you've used it before but can't remember
it's changed since the last time you used it
you're tired
you're distracted
you're human

More than ever, we're constantly surrounded by new information. It's impossible to remember everything all of the time.

I hope this makes you feel a bit better if you ever feel bad that you have to google something "obvious".

Monday

slack channel bookmarks – trying to find some documentation on where to find channel bookmarks on mobile, as my friend couldn't find them.

carbonara – my manager made the very lofty claim in standup that his carbonara was the best, so I googled a picture to make a "carbonara king" emoji of him

directory tree cli - how to render a directory tree in a CLI

react-toastify - a useful notification library

anchor dataset - accessing data attributes in JS

mdn element dataset

waitfornextupdate - trying to remember if this testing-library function was just for hooks. (It is.)

The next few are a direct result of the fact that in JS you still can't automatically download a file in a cross-browser way without creating an anchor element. There's the downloads API, but Safari doesn't support it.

jest how to test detached elements – jest-dom can only see what's in the DOM under test, so if an element is detached from the DOM, it's not going to be able to test it. But this didn't immediately occur to me.

document.createElement('a')

document.createElement('a') detached

react-hook-form - we're trying to add this to some of our web properties, as they don't have any form management and react-hook-form is a really nice abstraction.

spread types may only be created from object types - I kept getting this error and I couldn't work out why, and it turns out we had an old version of react-hook-form installed in a different app (just monorepo things) which had different return types

react-hook-form "spread types may only be created from object types"

Tuesday

slack channel links in API

gilts – they were in the news and I didn't actually know what they were.

js accessing nested object key – I momentarily couldn't remember whether you could access nested object keys like myObj['key1.key2']. (you can't, because the entire string is interpreted as one key)

intensifies emoji maker – I went with MakeEmoji which has a pleasing number of options

modal accessibility – I was having a discussion with someone about why modals aren't accessible. It turns out there is some nuance to it, and that they aren't necessarily completely inaccessible, but they require a fair bit of work to make them accessible.

modal window accessibility

I hope you can feel the frustration in the next few search queries, in which I struggle with Storybook and then find that my problem isn't actually documented. I knew that there was a world in which you can write JSDoc comments above a component, and have them show up in Storybook docs, because we did that at my previous job. The docs don't seem to mention this at all, and it wasn't working for some reason. It turns out that it doesn't work with default export components, for some reason, but this isn't documented anywhere.

storybook docs markdown comments

storybook story description

storybook docs

storybook comments

storybook comment

storybook JSdoc

Wednesday

mark hoppus – I mentioned that I was trying to get blink-182 tickets (I failed) and we were debating how old they are now.

lofi girl – during retro we put music on while people are writing their Retrium tickets, and I thought this was the appropriate vibe.

apollo query oncompleted

useLazyQuery – trying to figure out if this returns the return value, or void. Turns out the latest version returns the return value, and the version we're on doesn't :(

sentry github

'RequestSessionStatus' is not exported from '@sentry/types' – this turned out to not be a problem with the Sentry lib, but actually a yarn.lock mismatch (just monorepo things).

Thursday

document.write – I knew this was deprecated, but I wanted to find something to back up my PR comment.

apollo server request size – Getting 412s from our apollo server and trying to figure out how to bump the max request size.

apollo-server-koa

apollo server request size site:stackoverflow.com - a useful tip for googling is that you can restrict searches to a particular site using the site: param.

mdn element dataset

open new window and set inner html – trying to find a suitable replacement for document.write for the person who requested it. We went for window.open() and myWindow.document.documentElement.innerHTML = myHtml.

mock clock golang – figuring out the best way to mock the time.Now() function in Go. There are various ways of doing it across our codebase, I wasn't sure which one was the most up-to-date way, but I figured it out eventually.

graphql server request entity too large – still trying to fix the apollo server request limit

doggo ipsum – my favourite ipsum generator.

apollo server body parser config

apollo server body parser config koa

koa - I finally realised we need to set the body parser config on the server itself, not the apollo-server wrapper.

koa request size

britney spears albums – trying to find as many Britney track titles as possible to cram into a pun-filled gratitude post for my colleague who helped us out.

ronseal – I like to google pictures of Ronseal and put them in PR descriptions when the title describes exactly what the PR does (i.e. it does what it says on the tin). I think I got this habit from b3ta back in the day.

Friday

read a symbolic link – I'm so shit at symbolic links lolol

npm service status

apollo async oncompleted

window.history – looking for the arguments for history.push.

I think the next few are particularly amusing given that I literally gave a conference talk on redux-saga in 2018, but it's been so long since I touched any code containing sagas that I completely forgot how they work:

saga execute non-saga function

saga execute non-redux function

redux-saga effects

More ipsum generators, because my colleagues enjoyed doggo ipsum:

cupcake ipsum

veggie ipsum – I love that I also googled this in the previous post as well, I promise it's a coincidence

ts-command-line-args - onto some CLI building now!

node.js interactive shell

node.js interactive shell select – I was looking for a CLI library that lets you select different options with the arrow keys. I found inquirer.js!

types/inquirer

ts-command-line-args

should you symlink from destination – I can never remember what order to do symlinks in

TS2464

next-images - checking that some of our plugins are still relevant.

nextjs document

react-hook-form radio buttons - sometimes you just need a good example. Turns out it was easier than I thought, and I just needed to forward a ref to our radio button component.

Looking back

You might say "well, you googled fewer things this week than you did that week in 2019!". For one thing, I have more meetings now than I did back then. I'm in a different team, working on different things.

It also depends from week to week what I'm working on; last week I spent a lot of time building data export in Go, and so my search history was full of frustrated queries like golang readseeker from buffer and create a file from string golang. (I still help out on backend tickets when it's needed.)

Some of the stuff I googled back then I can remember how to do without looking it up now, but some of it I definitely can't (e.g. I still can't get my brain to retain some more complex CSS grid things). For example, I'd 100% still have to google all of these from the last post:

whitespace regex

regex not letter

js date

grid minmax

There you have it – I still google loads of stuff. To finish, I'll leave you with what I said in the post from 2019:

What I'm trying to show with all this is that you can do something 100 times but still not remember how to do it off the top of your head. Never be ashamed of googling, even if it seems like the most basic thing you're looking up.

When going back doesn't mean going backwards

2022-08-27T00:00:00Z

Hey internet! Last time we spoke, I was in a bad place. Burnt out and off work. Well, in May I made the decision to quit my job at the startup after 7 months, and in June I accepted a new job at... my old job. So I'm back at Monzo, working at the bank.

You don't often hear about people going back to jobs they've left. It turns out it's really nice, because you already have friends there and people are happy to see you come back. For me, leaving Monzo was always a pull, not a push: this exciting opportunity came up at incident.io, and I thought I'd give it a go.

Accepting that a job isn't working out can be a difficult pill to swallow. I really wanted to make it work, and I think a lot of the burnout I experienced was because it wasn't the right job for me. Being part of an early-stage startup seemed to be the hot thing to do, and this particular one is run by people I really respect. I had to come to terms with the fact that early-stage startups aren't really my cup of tea: I realised that I work best in bigger organisations, where I can take more of a leadership role and do larger-scale work that improves things for the people around me.

I also realised that I didn't really want to market myself as a full-stack developer any more. The week I got back from my time off, I went to All Day Hey in Leeds and I left with this incredible sense of clarity. It reminded me of everything I love about the web. And it made me finally accept the fact that, well, I don't like backend development very much.

See, I've always had a degree of internalised self-doubt about being web developer, as if it means I'm somehow not a "proper" developer for not being a backend dev. (Never mind that if anyone said that to me, I'd give them an earful.)

I've been building websites for over 20 years, but when I learnt Java during my masters I thought I'd become a backend dev, because that was what Real Programmers do. After my career took me onto a React/Node project at John Lewis, then joining Monzo as a full-stack web engineer, I clung on to the "full-stack" title. Doing backend too meant that I could still consider myself a Serious Dev while still doing the fun web stuff as well.

That "fun web stuff" included teaching people about accessibility, improving testing, architecting and building out brand new web apps, upgrading countless libraries, implementing microfrontends in a large React monolith, architecting and building component libraries. It involved becoming recognised as a conference speaker, and being invited to conferences about web development in the UK and abroad. It involved being promoted to Web Discipline Lead at Monzo, where I could be the "public face" of web internally at Monzo, defining and introducing engineering standards across the organisation. But it's okay because I was still doing backend engineering to make me a Proper Developer...!

Oh dear.

At All Day Hey, when I watched Andy Bell's brilliant talk Be The Browser's Mentor, Not Its Micromanager, I was so excited by what I'd just seen. I hadn't felt that much enthusiasm about what I did for months – sorry, but the introduction of Generics in Go doesn't hold a candle to modern CSS utility functions and what they mean for responsive website design 💅

I realised that I hadn't been doing enough of what I love, and I LOVE THE WEB. Web development is awesome. (And I am a Proper Developer.) Sadly the company's engineering needs didn't really match up with my specialism.

The week after, I handed in my notice. I was sad, but we all agreed it was the right thing, and everyone was super supportive.

Ultimately, the 7 months at the startup were well spent: this experience helped me to understand what I really wanted for my career – and I realised it was pretty much what I was doing before. Plus, I met some excellent people, and learnt a lot from them. (I also built a pretty sweet component library, and I hope they're getting good use out of it.)

This isn't a cautionary tale: it's a reassurance that it's okay to make the wrong decision. The wrong decision is not necessarily a bad decision, and going back to my old job isn't a backwards step – I picked up where I left off and I'm heading in the same direction I was when I left. I don't have any regrets about the past year – I learnt a lot, I have a lot of love for the folks at incident.io, and they're building something amazing. It just wasn't the right thing for me, and that's okay.

Burnout, a cautionary tale (and a plea to take a break)

2022-04-16T00:00:00Z

It's Easter and I'm off work til the end of the month. It was originally just going to be for a few days as I'd used up most of my holiday already, but after I burst into tears at my manager on Wednesday during our 1:1 when he asked me how a project was going, he suggested I might need a bit longer (good manager).

I really love my job, I love what I do and I love my colleagues. Before the pandemic - and even during it - I threw myself at my work and learnt as much as I possibly could. And from my beginnings learning Java at university, I learnt JavaScript, then React, then Kotlin. Then I moved onto Monzo and picked up Go. I was Good At Things.

But for the last few months I've found that nothing goes in any more. I can't absorb new information. People have to explain things several times, and my head feels like it's full of cotton wool. It makes me feel like an idiot. I'd tell myself I was better than this and I needed to just focus and maybe I was just getting too distracted.

When I sit down to do web development, it's like autopilot and I can steam through it, but anything backend seems to be beyond my capability at the moment. Which is frustrating because there's a lot of backend development in my current role. I used to love it, what gives? I'm out of practice, sure, but it's like there's this barrier that stops me from learning anything new.

Weeeelllll, now I can put a name to that barrier: burnout. FFS.

Was it my job, I thought? Was I unhappy in my new role? Well, the thought of going back to my old job didn't make me feel any better. Nor would going anywhere else. Switching to a new job certainly came with the stress of starting from scratch, and working at a startup is a whole other vibe. But ultimately I do like it, and I knew that in any other circumstances I'd be thriving there.

So let's look at everything else.

The last two years have been among the worst of my life. I'm sure they have for many of you, too. I spent so long unable to do some of the things I love, in a lockdown that could have been a lot shorter if our government wasn't equal parts inept and corrupt. The world is permanently on fire. I had to take a hiatus from reading the news because it was all too much. Plus I've had my own depression to contend with and other family things that I won't go into, which have made everything that much more difficult.

Don't be like me, please take a break

I wrote a blog post in 2020 about giving yourself a break, but apparently I didn't take enough of my own advice.

For someone who goes on about work-life balance and mental health, I'm not actually very good at practising what I preach. (Surprise.)

I'd figured that because I never work late or out-of-hours, I'd avoid burnout. But that's just one contributing factor.

And when I take time off I usually feel like I need to fill it with Stuff. Projects, outings, day trips, holidays. Making the most of your time off. I've never been good at doing nothing.

A couple of weeks ago I was ill with a mystery virus that seemed an awful lot like covid but was negative on all the tests, and a few mornings that week I'd woken up feeling loads better and started working. By the afternoon I had to give up and down tools again because I felt so ill.

I thought I'd be making myself useful by working when I felt better, but instead I was being more disruptive than anything else. People didn't know if I was going to finish the thing I was working on, so they didn't pick it up, and stuff kind of stopped and started. If I'd just taken the rest of the week and shoved my laptop in a cupboard, I'd have actually got the rest I needed.

Heed my words, adventurer!

I am not writing this post to garner sympathy, I'm sharing because I want to be transparent about the fact that this doesn't "just happen to other people". I have been running on fumes for months, and it culminated in me crying in a coffee shop in front of my extremely kind and patient manager.

If you are feeling like things are harder these days, that's because they are. If you're not functioning at 100% and find you're pushing yourself even harder because of it, please stop. I want you to take a minute to check on yourself. Are you okay? Do you need to take some time off?

(Also, never be ashamed of crying at work. We've all been there. Normalise crying at work. It's a sign that something is wrong, but the crying itself isn't anything to be ashamed of.)

I believe in working hard, but I do not believe in working hard at the expense of your physical and mental health.

So now I'm on a break until May, and I'm going to go for walks, go birdwatching, do jigsaws, plant some vegetables in the allotment, play video games and make a big fuss of my father-in-law's dog Boris.

If you've got some holiday, please take it.

My plans.

Start at the beginning: the importance of learning the basics

2022-01-02T00:00:00Z

If you're an early-career developer, Twitter is overflowing with people tweeting great tips -- and some absolute rubbish -- about how to improve your skills and become better at your job. I've spoken to more than a few people who've asked me, "how should I start?". And I tell everyone the same thing: learn the basics.

However you learn best -- book, video, interactive tutorial -- you need to learn HTML and CSS before you can call yourself a web developer. I don't think that's a particularly controversial statement.

Once you start getting into interactive website territory, with API calls and fancy stuff, that's where you need JavaScript (JS) knowledge. More specifically, vanilla JS: plain JS with no additional frameworks or plugins. The JS that your browser understands without having to do any pre-processing. It makes working with frameworks a whole lot easier, and it'll help you to know when not to use a framework (and avoid making users download massive JS bundles when all you need is a tiny bit of code). Browsers have come a long way, and a lot of what we might have needed to use Babel to do even just a couple of years ago is now natively supported in the big 4 browsers (Chrome, Firefox, Edge and Safari).

Where I started

I started building websites when I was ten years old. I was lucky enough to grow up with computers in the house, and had a book called "Make Your Own Webpage" which taught me the basics of HTML (as it was in 1999). You can even read it on archive.org.

A few years later, I built my personal website full of webrings and stolen gifs with the help of Lissa Explains It All, the ultimate HTML bible for anyone on the internet in 2002. (It's still online today, but pretty out of date!)

Fast-forward through LiveJournal, Greymatter, Blogger, Wordpress, pretty much any pre-2010 blogging site/CMS framework you can imagine -- and now I'm building websites (or web apps) as my actual job, using React. A fair bit has changed -- but not as much as you'd think.

I'm telling you this because I still use the knowledge I learned when I was ten every day at work. HTML tags are still HTML tags, they're still written much the same way -- HTML5 got rid of some of the ones I used to use (pour one out for marquee) and introduced some new ones, but the fundamentals are still the same. Most of the websites that I built in 1999 would still render today.

My first professional web development experience was a React app. I'd just about heard of React at that point, but I'd recently learned JavaScript and Node.JS which gave me a good foundation to build upon. I brushed up on some newer CSS concepts I hadn't used, but all the HTML and CSS of my past web adventures came right back. The good thing about this stuff is that it's all over the internet, so when you inevitably forget how to do something really simple, you can just google it.

Frameworks serve a purpose, but they don't replace the basics

People might tell you to learn React, because everyone's using React. I write React every day, and a lot of that is just JavaScript and HTML. If you don't know either of those, you're going to have a bad time -- or you'll end up with highly specialised framework-specific knowledge that will bite you later on when you need to use a different framework. Lots of people are using React, sure -- but a lot more people aren't. A far, far larger proportion of the web runs on Wordpress, for example. Lots of sites are built in plain old HTML, CSS and JS, like the emojinator and this very website you're reading.

Besides, in a few years we'll probably using the newest, hottest framework and React will become the butt of jokes in the way that Angular has. Or you'll land a job at your dream company and find they use Vue, or some state management library from 2011 which has no documentation. I'm not saying don't learn React -- I'm saying learn the basics first, so you can apply your knowledge to all manner of other frameworks and tools.

The same goes for CSS. There was a particularly bad take floating around Twitter recently where someone suggested that junior developers should skip CSS and just learn Tailwind. I have used Tailwind, and I dislike it for various reasons, but I can see use cases for it such as quick prototyping and a set of nice defaults in the absence of specialist design. However, it doesn't and shouldn't "replace" CSS. Tailwind is literally just a library of someone else's CSS classes, except you have a separate class for nearly every rule instead of writing all your rules together in reusable classes for each component. Instead of learning hundreds of class names, why not learn the CSS rules they translate to and write one CSS class with multiple selectors? When you go to your next job or project and find they don't use Tailwind, it'll slow you down as you need to learn the selectors all over again.

Recommended resources

I'd recommend going in the order HTML, CSS, JS. That way, you can build something in HTML, add CSS to it as you learn it, and finally soup it up with your new-found JS knowledge.

If you're a backend engineer who only touches the frontend occasionally, you don't need to go too deep -- but you need a decent grasp of which element does what (semantic HTML) so you can make sure you're using the right elements and not creating any accessibiliy problems.

Learning HTML

I usually recommend these tutorials which provide a really nice overview of different types of elements. Try using some of the tags in Codepen, and watch things render before your eyes.

Learn from how other people do it. Web pages are so bloated with scripts and analytics these days that it's hard to just right-click and "View Source" in the same way that I did back in the early 00s -- I learnt a lot of HTML by nicking other people's code! But you can use browser dev tools to look at the structure of the page (the Document Object Model or DOM, as it's known):

Learning CSS

Codepen comes in useful again here to easily write and apply CSS styles to HTML, and have it update instantly.

Again, MDN has a great beginners' guide. CSS Tricks is my favourite place for useful CSS knowledge (I referred back to their Flexbox cheatsheet for YEARS) and really clearly written guides.

Free

CSS basics -- MDN
CSS Almanac -- CSS Tricks -- a guide to nearly every selector and property in CSS
CSS Tricks guides for in-depth info

Paid

CSS fundamentals on egghead.io by Tyler Clark (video)

Learning JavaScript

You want to start with vanilla JS. Having a solid foundation in that will make it easier to use frameworks and libraries in the future.

How in-depth you go is up to you, and depends on how much interactive stuff you want to build on your website. If you just want a plain static site with a bit of markdown, you probably don't need JavaScript. This website has a tiny bit of JS on that controls dark mode; without that, it'd just be HTML and CSS (though I did use a static site generator to build it).

Besides the obligatory MDN article, these resources have been recommended by folks on Twitter - there are more suggestions in the replies.

Free

Paid

Vanilla JS Academy (structured course)

The right tag for the job: why you should use semantic HTML

2021-06-06T00:00:00Z

I've come across a lot of websites in my career (and in daily browsing) that are straight-up inaccessible. If you've ever worked on a project that is riddled with accessibility issues, you'll know that fixing these problems is a mammoth task - it needs time, it needs people, it needs prioritisation... it costs money, basically. As I mentioned in my blog post 7 myths designers and developers believe about web accessibility, retrofitting accessibility is hard.

The key is to start out with the right tools for the job - or rather, the right tags for the job. In every website, underneath the layers of CSS, the bloated frameworks, the 45945 API calls, there's good old HTML, and that's the key to accessible websites. Specifically, semantic HTML.

Semantic HTML conveys meaning

Semantics is the study of meaning, and semantic HTML is exactly that - HTML tags that convey meaning. They tell the browser - and assistive technology such as screenreaders - about the structure of the page, and how it should behave when you interact with those elements. A button should let you click on it. An ordered list should have numbers.

Sighted people rely on visual information to tell them about the structure of a page. Based on our prior knowledge of UI conventions, we can identify where a header is, which parts of the page are buttons or form elements, and what the title of the page is, for example. But if you don't get that visual information, how can you tell what's on the page?

Assistive technology such as screenreaders will take the HTML markup of the page and present it to the user either by reading it out audibly, or sending the output to something like a braille display. They'll use the different types of HTML tags in the document to present structured information to the user, allowing them to navigate by headings, or cycle through the links in the page. So it matters what HTML tags we use, to make sure the screenreaders get the complete picture.

Example: a non-semantic news site

Take this mocked-up news site (as you can see, graphic design is my passion). I've built it using mostly <div> elements, with a couple of <h1>s as I wanted some nice big headings. My menu at the top is a series of <div>s containing links, and the footer at the bottom is the same.

See the Pen Semantic HTML blog post example: no semantics by @sophiekoonin on CodePen.

If you're a sighted user like me, it looks perfectly fine. I can see a menu, a header, some titles and a footer. The byline and image caption is nicely italicised, and there are some nice buttons and fancy SVG checkboxes on the cookie banner.

But let's take a look at this page from the perspective of assistive tech, which relies on the underlying HTML markup to establish the structure of the document. I'm using the screenreader software VoiceOver, which is built into MacOS, but if you're on Windows you can use NVDA which is free to download.

Landmarks

Screenreader software such as VoiceOver, JAWS and NVDA provides a way for users to navigate to different sections on the page based on landmarks. So, you could skip directly to the footer, or directly to the main part of the site. This relies on these landmarks being signposted through semantic tags such as <header>,<main> and <footer>. We haven't used any of these tags in the example, so screen readers wouldn't be able to identify any landmarks.

When I run VoiceOver and press Ctrl+Option+Shift+I to tell me about the page, it says:

Page contains 14 links 2 headings

When I properly mark up the header, footer and main sections of the page, with an <article> around the content of the news article itself, VoiceOver allows me to navigate between them with Ctrl+Option+right/left arrow. It tells me:

Page contains 14 links 2 headings 3 landmarks 1 article

Menus

If a screenreader user is trying to find the menu in this news page, they're going to have to go through all the links on the page to try and find one that seems like it could be a menu link. The <div> wrapping the menu is completely ignored by the screenreader, so all they hear is each individual link. There's nothing to tell them which part is the menu. People shouldn't have to tab through the page incessantly to find out how to navigate to a different part of the website.

Prior to HTML5, the best way to mark up menus with lists of links was an unordered list - <ul>. Now we have the <nav> tag, short for navigation.

<nav>
  <ul class="menu">
    <li><a href="#">News</a></li>
    <li><a href="#">Politics</a></li>
    <li><a href="#">World</a></li>
    <li><a href="#">Sport</a></li>
    <li><a href="#">Tech</a></li>
  </ul>
</nav>

Technically, you don't have to have a list inside the <nav> - you can just put links in. I personally like to keep the list inside - the nice thing about lists is that some screen readers will read out how many items there are, so the user knows how long to keep tabbing through. It's also good for backwards compatibility in case any older screen readers don't understand <nav>.

Lists can be styled easily (including removing bullet points), and <li> (list item) elements can contain links and buttons.

You can add aria-label attributes to your <nav> elements to give even more information about the purpose of the menu.

<nav aria-label="main navigation">

Here's how VoiceOver interprets all of this:

main navigation, navigation

list, 5 items

link, Sport, 4 of 5

Whether you use <nav> or not isn't a hard-and-fast rule. I noted that gov.uk (an example of amazing accessible design) doesn't actually use them at all, sticking with unordered lists. As long as you use one and/or the other, you'll be fine.

As an aside, I recommend using the Dev Tools inspector to look through the source for gov.uk to see how they use ARIA attributes, as they use them very well.

Checkboxes

These checkboxes aren't real checkboxes - they're <div> elements with CSS :before pseudoselectors containing an SVG checkbox icon. VoiceOver reads them out as plain text, leaving you with no idea you can even click them.

Chocolate chip

It's super annoying that you can't style the default checkbox in browsers, but there are ways around it that still let you use <input type="checkbox">. The same goes for radio buttons.

If we put the input back in and visually hide it (leaving the input element in the DOM), we get a much more helpful readout:

 <label for="choc-chip">
  <input id="choc-chip" class="visually-hidden" type="checkbox" />
  <div class="pretty-checkbox" aria-hidden="true"></div> Chocolate chip
</label>

(NB. you could even just have the actual SVG inline here)

Chocolate chip, unticked, checkbox

We hide the "pretty" checkbox from screen readers, because they will pick up the <input>.

The input itself has a CSS class of "visually-hidden", which looks like this:

.visually-hidden {
  display: block;
  height: 1px;
  width: 1px;
  overflow: hidden;
  clip: rect(1px 1px 1px 1px);
  clip: rect(1px, 1px, 1px, 1px);
  clip-path: inset(1px);
  white-space: nowrap;
  position: absolute;
}

We can't simply use visibility: hidden or display: none as these attributes actually apply to screenreaders as well. Anything hidden that way will also be hidden to screenreaders. This visually-hidden class makes sure that elements with this styling are invisible to sighted users, but still visible to assistive tech.

For more information on this approach, check out Sara Soueidan's guide to inclusively hiding & styling checkboxes and radio buttons.

For even more semantic goodness, we can now wrap our checkboxes in a <fieldset>, which groups together related form-fields. We can then attach the "Which of these cookies can we use?" text to the fieldset by making it a <legend>:

<fieldset>
  <legend>Which of these cookies can we use?</legend>
    <label for="choc-chip">
      <input id="choc-chip" type="checkbox" />
      <div class="pretty-checkbox" aria-hidden="true"></div> Chocolate chip
    </label>
    <label for="oatmeal-raisin">
      <input id="oatmeal-raisin" type="checkbox"/>
      <div class="pretty-checkbox"></div> Oatmeal &amp; raisin
    </label>
</fieldset>

VoiceOver:

Which of these cookies can we use?, group

Buttons

The "buttons" - actually <div> elements with added onclick attributes - are recognised as "Clickable" by Voiceover. Not all screenreader software is able to identify clickable elements in this way.

Accept all, clickable

However, if I'm navigating through the page using only the keyboard, I can't select one because the browser doesn't know it's a button.

Sure, we could go adding a tabindex attribute to these buttons to make them tabbable, but then you run the risk of messing up the natural tabbing order of the document. The best solution is to use a <button> element. That's what it's for, and you can style it pretty much any way you like using CSS. You can even make a button look like a link, and vice versa, which is something I do a lot when building a website to a design spec.

  .button {
    cursor: pointer;
    display: flex;
    border: 0;
    box-shadow: none;
    border-radius: 6px;
    font-weight: bold;
    font-size: 1rem;
    margin: auto 0;
    justify-content: center;
    align-items: center;
    padding: 0.8rem 1rem;
    color: white;
    background-color: #420a55;
  }
  .button:hover {
    background: #8d6c99;
  }

Accept all, button

You are currently on a button... to click this button, press Ctrl+Option+Space.

Headings

We've got three H1 elements on the page: the site name, the article headline, and the cookie banner. A site should only ever have one <h1> element - it's the main heading that tells you what the page is about. Any other headings should be nested underneath, or possibly not even headings at all (in the case of "The Woofer Times", this doesn't need to be an actual heading).

There's a subheading within the article which is simply bold text. That should be a lower-level nested heading, in this case an <h2>.

Screenreaders allow users to navigate by headings, so it's important they're in a logical order.

If you want big text, style it with CSS rather than relying on the browser default size of heading elements.

Bold and italic text

The byline and the image caption are displayed in italics using the <em> tag. However, screen readers may actually read this out differently because they expect the <em> tag to signal emphasis - that's what em means. So the tone of voice might change as it's being read out, with additional stress. The italics in the byline and caption are a stylistic choice, so we should italicise it with CSS rather than <em>.

The <i> tag still exists alongside the <em> tag, but represents text that stands out from the rest of the body, such as scientific names, thoughts, technical terms and idiomatic terms from other languages:

The red fox, <i>Vulpes vulpes</i>, is commonly found... 
It was a case of <i lang="fr">déjà vu</i>.
<i>Sure</i>, she thought, <i>that must be it</i>.

I <em>really</em> don't like this book.
Do it <em>now</em>!
No, <em>I'm</em> Spartacus.

The same goes for any bold text - <b> indicates significance or keywords and may also result in the screenreader voice changing when read out, so use CSS if the effect is purely presentational.

Somewhat confusingly, both <strong> and <b> are used in slightly different situations despite both rendering as bold text in browsers - <strong> "indicates that its contents have strong importance, seriousness, or urgency" (MDN), where as <b> is used to draw attention without the urgency (e.g. for relevant terms in a blog post like this one).

I won't tell you again, <strong>do not disconnect the fire alarm</strong>.

This is known as <b>semantic HTML</b>.

NB. Frustratingly, Markdown doesn't seem to distinguish between these elements, so everything is <strong> or <em>. If you want to use <b> or <i> you'll have to add them in as HTML within your Markdown.

Image caption

It's clear to sighted users that the text under the image is a caption, but not to screen readers - there's nothing associating the two at all.

We can fix that by wrapping the image in a <figure> element, then adding a <figcaption> underneath the image.

 <figure class="image">
  <img alt="a lovely fluffy samoyed" src="https://codepen-assets.s3.eu-west-2.amazonaws.com/alex-russell-saw-Dj8cxyi9ink-unsplash-1.jpg" />
    <figcaption class="caption">"The most angery pupper I have ever seen" Photo: <a href="https://unsplash.com/@alexrussellsaw">Alex Russell-Saw</a>
  </figcaption>
</figure>

VoiceOver says:

"The most angery pupper I have ever seen" Photo: Alex Russell-Saw, figure

before then reading out the image information:

a lovely fluffy samoyed, image

You can still use `div`s!

As I demonstrated above, <div> elements can be extremely misused. That's not to say you shouldn't use them at all: on the contrary. But you should only use them for their intended purpose: entirely meaningless containers. I use them to group elements together which I then style with CSS. Or I'll wrap the entire page in a <div> and make it into a flex container for my <header>, <main> and <footer>. <div>s are great, as long as you don't use them in place of more meaningful elements.

You can use the Dev Tools inspector on this very website and see the way I've used <div>s presentationally: for example, all the stars in the header are divs which are totally hidden from screenreaders, because they're entirely decorative.

The same news site, with semantic tags

I've recreated the same site using semantic HTML tags, and it looks pretty much exactly the same (save some different margins here and there that are easy enough to fix).

See the Pen Semantic HTML blog post example: semantic HTML by @sophiekoonin on CodePen.

There is still a lot of room for improvement. ARIA attributes come into play here, to add extra information about the roles of each part of the page. I'm just illustrating the semantic elements in this example.

Here are the main differences:

the page is broken up into <header>, <main> and <footer>, with an <article> round the main page content
there is only one <h1> on the page, because it signifies the main heading that tells you what the page is about
the "Accept all" and "Close" buttons are actual <button> elements
the checkboxes are <input type="checkbox">, with <label>s on each one
- they're also inside a <fieldset> with a <legend> explaining what the checkboxes are for
the menu links are in an unordered list, <ul>, wrapped in a <nav>
the subheadings in the article are now <h2> (the first level of nesting under the main heading)
the byline and caption are styled italic through CSS, rather than <em> tags
I've used a <figure> for the image, with a <figcaption> for the caption to indicate it's a caption for that image

Semantics from the start = accessibility from the start

Using semantic HTML as building blocks for a website will give you a lovely accessible foundation upon which to add your fancy CSS and whizzy JavaScript. You can use semantic elements in JS frameworks, too - I write React every day at work, and always use semantic elements. Your users (and/or your customers) will thank you for it.

Find out more about semantic HTML

MDN: HTML Elements reference - with explanations of each element's purpose
Semantic HTML cheat sheet

A typical day: pandemic edition

2021-01-18T00:00:00Z

This is a series started by Colin Devroe. Some other lovely folks have written their own, including Sara Soueidan and Cassie Evans.

This post would have looked very different prior to March 2020. Before then, I'd be out at events, meetups or social meetings several nights a week, in the office every day seeing people, and commuting to and from work. Needless to say, as someone who gets energy from being around others, the change to working from home full-time and not going out has had a massive impact on my mental health and my depression has got much worse. I don't think I would have been nearly as burnt out as I was in December if all of this hadn't been going on. So this is my "current normal".

My typical day

08:00 - 09:00: wake up, about an hour later than I used to. I'll usually sit in bed for a bit drinking coffee, talking to my husband, and checking the news/Twitter/notifications (it's a habit I'm trying to break, but not doing very well).

At some point during this hour I'll scrape myself out of bed and shower, get dressed (I can't work in PJs!) and find some breakfast. If I'm honest, this is usually about 15 mins before I start work, because my bed is extremely comfortable and it's cold in the house.

09:00: catch up on Slack messages, see if there's anything that needs my attention, say hi to the team.

We usually have a quick standup at 10ish, then I get stuck into whatever I'm working on. My days are often peppered with 1:1s, planning meetings and various other things - PR reviews, answering questions on Slack, triaging bugs. At the moment I find it hard to focus for long periods of time so whatever I'm doing I'll inevitably be distracted by notifications (I need to get into the habit of turning off Slack while I work).

Depending on what I'm working on, I might be doing web work in React or backend work in Go, or I might be writing a proposal for a feature or technical change.

12:00 - 13:00: lunchtime. Quite an early lunch, a relic from when I used to be up at 7, eating breakfast at 7:30 and hungry by 12. I'll often go for a walk in the park and listen to a podcast (Darknet Diaries, Switched On Pop and Strong Songs are my favourites) or chat to my husband. On especially good days, we might go down to our garage where we have a little gym set up - I've been doing some free weights.

I miss buying lunch, which is undisputably the most annoying meal to have to make.

13:00 - 18:00: the rest of my working day - more coding and 1:1s. I block out parts of the day in my calendar so that I have uninterrupted time with no meetings.

At points I'll go downstairs to refill my drink and pester my husband.

18:00: I log off from work. I'm very strict about what time I finish work - never after 6pm.

Once every couple of weeks I have a therapy session via video call, which has been massively helpful this year.

I'm a creative person and I originally imagined I'd spend a lot of the free time I gained from not commuting doing things like making music or building cool things, but in reality I just browse the internet or play a video game.

I've been thinking a lot about spoon theory recently. Originally conceived as an analogy to living with chronic illness, I think it fits perfectly with the way my depression has been manifesting itself this year: I just haven't got enough spoons right now to do all the things I want to do. So often when I feel I should be being productive or doing something creative, all I'll have the energy to do is just sit down and play video games. Over Xmas it was Assassin's Creed: Valhalla, then a lot of Stardew Valley, and I've racked up an embarrassing number of hours on Two Point Hospital over the last few weeks.

19:00: time to make dinner, or continue to veg out while my husband makes dinner. Or we give up and order a takeaway.

We've been making an extra effort to eat at the table over the last few months, which is nice because we actually talk to each other and pay attention to what we're eating instead of just zoning out in front of the TV 🙈

Generally after dinner we'll watch TV, or continue playing video games next to each other because we're adults and make sensible choices. Sometimes I'll pick up whatever embroidery I have in progress and do it while we watch TV - I'm currently embroidering my wedding flowers.

I've started keeping a little journal of good things that happen every day. They can be as minor as "made a really nice pie" or something like "got really positive feedback on the proposal I wrote". I tend to fixate on negative things, so having written evidence that good stuff is still happening should hopefully anchor me a bit and remind me of the positive side. I recommend it! Plus it's an excuse to buy a notebook and some nice pens.

23:00: time for bed. Over the last six years I've been going to bed at 11pm so religiously that I actually get sleepy at 11pm automatically. I try and read a bit before bed (currently making my way through Elena Ferrante's Neapolitan Novels) but usually I only manage a few pages before I conk out.

I feel like this wasn't a particularly exciting or enlightening typical day, but really, how can it be? Like Cassie says: "If you're reading these posts - whatever your day looks like - whether you smashed through a huge to-do list or not. You're doing good, remember to be kind to yourself.".

All we can really do is make it through the day, focus on the tiny things that make us happy, and know that there is a light at the end of the tunnel. At the time of writing, 5.8% of the UK population have received their first dose of the vaccine (including my dad, hey dad!). Good news is out there, it's just not as clickbaity as the bad news, so we see less of it.

Now, if you'll excuse me, I have a fake hospital to run.

Give yourself a break: lessons from burnout

2020-12-16T00:00:00Z

I started writing this post a few days ago, and was so exhausted I couldn't actually be bothered to finish it, which tells you a lot really. And if you're too exhausted to read another blog post, here's a summary: have a rest. Go and do something nice. Tech can wait.

A couple of weeks ago (possibly - I have no concept of time any more) I tweeted this, which seemed to resonate with folks:

Sophie Koonin @type__error
the only coding I've done outside of work in quite a long time is a small bit of JS to apply hats to emoji. I don't know how anyone does tech stuff out of hours, it's exhausting enough doing it IN hours
160 10:04 PM · Dec 5, 2020

(A plug for emojinator, the site in question where you can add hats to emoji)

Twitter is awash with fantastically talented people building incredible stuff and sharing it, as well as those insufferable grifters who tweet things like "15 things you must learn to be a good developer #100daysofcode" and then hawk you their ebook. "Thought leaders" (don't you just hate that term) are churning out article after article of brilliant leadership advice, technical deep-dives, creative things to do in CSS, you name it. I don't know about you, but the article count on my RSS reader has been increasing for months and I just have not been reading anything. I can barely focus at the moment.

I became a tech lead in September, which is something I've been wanting to do for quite a while. One day I'll write about what I've learned as a new tech lead, but now is not the time, because I don't think I've been able to really succeed in my role due to the constant being-on-fire-ness of this entire year. Instead, have some lessons from the trash fire of 2020 that we can take over into the slightly-smaller-but-still-burning trash fire of 2021.

Lesson number 1: give yourself a break

As a new tech lead, I've felt like I'm letting my team down because I don't have the mental capacity to sit and read about the things I need to improve on, like observability and monitoring. I've had a copy of the SRE Workbook on my laptop waiting to be read, which I've barely touched.

Where did all these expectations come from? Myself, mostly. Nobody is peering over my shoulder going "why aren't you reading about Prometheus?". (Actually, my team have been nothing but supportive this entire year, and I love them all.)

The coronavirus pandemic has meant that my choir hasn't been able to meet since March. The choir I've been a part of for seven years, have been co-running for five of those years, and which forms a huge part of my own identity. I'm an extrovert who gets energy from being around people (but not in a Colin Robinson kind of way). Most of us have barely seen our friends and family. This year has been intensely difficult. I'm sure you've all experienced something similar.

On top of that, the political situation is dire. As well as the absolute corrupt shambles of a government who have done such a terrible job of handling the COVID pandemic that we have the highest death rate in Europe, there's a big red countdown timer on the UK government website that counts down to Brexit when I'm looking up just what the hell being in Tier 3 actually means. Many, many people have lost loved ones, there's a whole wave of anti-vaccine "Keep Britain Free" zealots popping up all over the place, and the UK has been nicknamed "TERF island" because of the rampant transphobia being spouted by formerly respectable public figures. And that's just on our doorsteps in the UK.

The SRE Workbook can wait, basically. We have enough on our collective plates.

Lesson number 2: if it benefits your work, it can be done in working hours

Perhaps you used to watch conference talks on the daily commute, or read technical books in bed. I definitely had a copy of The Manager's Path next to the bed that I was chipping away at at one point. But now that commute is gone for many of us, and I don't know about you but the only thing I have the energy for in the evenings is playing video games or idly browsing the internet.

I believe quite strongly that if you are learning something in order to become better at your job, you should be doing that within working hours. In my team, we all know that technically it's encouraged to take time out to learn something - we get a budget to do just that - but we rarely ever do it. To that end, I actually scheduled 2 hours a week in the whole team's calendar on a Friday for "Reading time". They can use that time however they want: they can watch videos, try something out, read a book. They can take more time, or less time. They can do it on a different day, or skip it entirely. All it is is the explicit permission to take some time out of your week to learn something, if you want.

(I don't know if they actually take the time: I haven't asked. I just want them to know they can, in writing.)

Lesson number 3: some things are boring and that's okay

Kubernetes does not interest me. I have the utmost respect for the infra folks on Twitter who seem super intelligent and knowledgeable about it, but I cannot bring myself to be interested in it. For a while I felt like not being into this stuff made me a lesser developer somehow. But my specialism lies elsewhere and there are things I'm good at that people who do Kubernetes for a living aren't (and I have it on good authority that "do Kubernetes" is a technical term). That's how well-functioning teams work.

I know enough kubectl to get a list of pods and SSH into one of them (but mainly because I have the zsh autocomplete plugin and it fills it in for me based on my past commands). That's all I need: most of the actual Kubernetes wizardry is automated or managed by people who specialise in it (in my case, our excellent Infrastructure Platform team). A good developer or tech lead will know when it's the right time to delegate to someone who knows more about it than they do.

Lesson number 4: mental health is more important than KPIs

I'll caveat this section with the fact that I know many people work at companies where mental health is not something to be discussed, or something that people really seem to take into account. And I also know it's not as simple as "find another job" and that should never be the only solution.

Instead, this is an appeal to senior leadership and management. Your employees are not inanimate batteries you plug in to power your company. They are humans, with complicated lives, families they haven't been able to see for months, and children having to stay home from school because someone in their class tested positive for COVID. Their partner might have lost their job this year. They may be struggling with working from home, missing being around people in the office, or they might be finding video calls even more exhausting than real-life meetings. If you've sadly had to make redundancies this year, are you expecting the reduced number of people to do the same amount of work as before?

If you're a team lead, check in on your team. Are they working long hours? Encourage them to sign off earlier. I highly recommend this Twitter thread about why working late a couple of hours a week can lead to completely unrealistic expectations of how long projects take to complete.

Schedule 1:1s with them and ask them how they're feeling about things. Encourage them to share their workload if they have too much: having more on your plate than you can cope with right now is not a sign of failure.

Mental health should be taken as seriously as physical health. We have trained mental health first aiders who can provide a swift response over Slack, an Employee Assistance Program for access to counselling and legal information, and people can take mental health days if they are struggling. I've taken three afternoons off at the last minute in the past three weeks because I was so exhausted with [gestures wildly] everything, and my team were very understanding about it. I know I am privileged in that regard, and I am grateful.

Ultimately, the productivity and success of the company will suffer more if your team burn out. People will start taking extended leave, or they'll quit. It's a choice between delaying a product release by a day and the mental health of a human being.

Sorry folks, I wrote a long article when I promised you you didn't have to read articles. Go and have a cup of tea and look out of the window for a bit.

Sophie Koonin @type__error
I guess what I'm saying is I'm really tired, it's okay if you're really tired, let's all be really tired and accept that the Google SRE Workbook will stay untouched on the shelf for a few more weeks
20 10:15 PM · Dec 5, 2020

7 myths designers and developers believe about web accessibility

2020-10-11T00:00:00Z

In an ideal world, being "good at accessibility" wouldn't make you stand out from the crowd. Companies wouldn't be hiring accessibility experts to help them unpick and untangle the inaccessible products they've been building for years. Speaking about web accessibility at a conference would be as unnecessary as getting up on stage and giving a talk on how to write HTML.

But we don't live in that world, and the web is full of inaccessible websites. Try navigating the Liberty London website with just your keyboard - can you add something to your basket?

I want to bust a few myths that I've come across over the years, in the hope that accessibility will stop being something to "deal with later" and start being something that people think about from the start.

Myth 1: The majority of your users don't have access needs

Repeat after me: there's no such thing as a "typical" or "normal" user.

When we're designing and building websites or apps, it's all too easy to forget that we are coming from a narrow perspective. My own abilities, experiences and knowledge shape how I interact with a website, and my experience may be totally different from yours. So even if you know instinctively that a particular icon means "download", others might not make that connection.

Is this how you see your users?

Microsoft's brilliant Inclusive Design Toolkit warns of the consequences of this selective thinking:

“If we use our own abilities and biases as a starting point, we end up with products designed for people of a specific gender, age, language ability, tech literacy, and physical ability. Those with specific access to money, time, and a social network.”

As a non-disabled, computer-literate developer with a Macbook and fibre internet, I need to make sure I'm not only building apps for people like me. All my users will have different requirements, different technology and different backgrounds. As the Inclusive Design Toolkit puts it:

“When it comes to people, there’s no such thing as “normal.” The interactions we design with technology depend heavily on what we can see, hear, say, and touch. Assuming all those senses and abilities are fully enabled all the time creates the potential to ignore much of the range of humanity."

Myth 2: Accessibility is optional

It's actually the law, in both the UK and the USA (I can't speak for other countries, but I'd be keen to hear from anyone who knows about any legislation in other places).

In the UK, The Equality Act 2010 makes it illegal to discriminate against people with disabilities - and that includes by accident! It doesn’t explicitly refer to websites, but the Equality and Human Rights Commission’s (EHRC) Code of Practice does list websites as one of the services to the public that should be considered covered by the Equality Act.

According to the EHRC, an organisation "is responsible for ensuring that reasonable adjustments have been made where needed, for example by changing the size of the font, to ensure that disabled users are able to get the information, without being placed at a substantial disadvantage (even if the [organization] employs an external organisation to build and maintain its website)."

The EHRC may:

Conduct formal investigations
Serve non-discrimination notices
Act over persistent discrimination
Issue Codes of Practice
Help someone prosecute a company - this requires someone to actually sue the company, which there's no case law for at the moment - but that could change any time.

In the US, there's the Americans with Disabilities Act (ADA). Famously, Domino's Pizza was sued by a blind person who couldn't use the website with a screenreader. According to US law firm Seyfarth, in 2019 there were 2,256 web accessibility lawsuits filed.

Myth 3: Access needs come from permanent disabilities

The truth is, anyone at any time can have access needs, and they can be permanent, temporary or situational. Temporary impairments might be due to a medical condition, and situational impairments may result from the environment around us - a situation we're in.

Some examples of permanent conditions:

partial or full blindness
having a limb amputated
learning difficulties, such as dyslexia

A temporary impairment could be:

visual aura from a migraine
repetitive strain injury making it difficult to use a mouse
cognitive processing difficulties (also known as brain fog) following an illness

Situational impairments might include:

a bright light causing glare on the screen
loud noise, making it difficult to concentrate
slow internet

Even if you consider yourself not to have any form of disability, you could find yourself with a temporary or situational impairment at any point.

Often when developers do think about accessibilty, they think of screen readers and people with visual impairments. That's a start, but there’s a spectrum of what constitutes disability. The important thing to note is that it doesn’t necessarily translate to some kind of personal health condition.

According to the World Health Organisation:

“Disability is not just a health problem. It is a complex phenomenon, reflecting the interaction between features of a person’s body and features of the society in which [they live]."

So much of the world around us can influence whether or not we have, or consider ourselves to have, a disability. Summed up perfectly in this Tweet by Amanda Leduc:

Amanda Leduc ♿️ @AmandaLeduc
If you wear corrective lenses of any kind, you have a disability. And guess what: your disability has already been accommodated, which is part of why you might not see yourself as disabled.
152136 04:48 PM · Aug 30, 2020

Myth 4: Accessibility is a barrier to good design

I've heard this one a lot. And as a web developer I feel like I’m often turning around to designers and saying “Sorry, I can’t do that, because it’s not accessible”. (The best designers will then turn around and say, "okay, let's find something that works better.")

It’s easy to imagine that in order for design to be truly accessible you have to build sites that look like the first-ever web page, but that’s not the case.

Is this... accessible design?

The reality is that accessible design is good design - and vice versa.

When it comes down to it, can we really call a design good if it doesn’t work for everyone? You can build the sleekest, prettiest user interface, but if someone who uses the keyboard to get around the internet can’t see what they’re doing, are we really going to call that good design?

As Jessie Hausler, the Director of Product Accessibility at Salesforce, wrote in his article 7 Things Every Designer Needs to Know about Accessibility:

“Accessibility will not force you to make a product that is ugly, boring, or cluttered. It will introduce a set of constraints to incorporate as you consider your design.”

If we can work within the constraints of the technology we're building for, or the constraints of what's in style, we can work within the constraints of accessible design.

Myth 5: Accessibility is hard to implement

This one has a grain of truth in: accessibility can be difficult to implement retrospectively. If you've built an entire web app without considering accessibility, it can take a lot of time (and cost money) to go back and fix it up so that it's accessible.

But if you consider accessibility from the start, factoring it into your designs and the way you write your code, it doesn't have to be difficult. Accessibility by default is a lot easier than accessibility after the fact.

As web developers, by sticking to some best practices in HTML we're already halfway there:

using semantic HTML elements such as <article> and <nav> to mark up the different parts of the document (I'll write more about this soon!)
using <button> for buttons with onclick attributes, and <a> for links to different pages (and not adding onclick attributes to anything except buttons!)
nesting headings correctly, from h1 through to h6 , with only one h1 on the page
keeping HTML tags for markup, and using CSS for style (rather than, say, using a <h1> tag because you want big text)

Many of the things that will help some groups of users with access needs will also benefit others: for example, good semantic HTML is great for screenreader users, but also helpful for keyboard or adaptive switch users, as with the right tags the browser knows what should be focusable and what shouldn't. Labels on forms make them easier to read and understand for people of all cognitive abilities, and they are good for screenreader users too.

Add an accessibility checklist to your JIRA tickets or pull request templates: make it part of your definition of done. Look out for best practices in your code reviews.

Myth 6: React apps are inherently inaccessible

I seem to follow two camps of people on Twitter: people in the React community, and people who hate the React community. I am by no means a hardcore React stan (and I think the community can be as toxic as any popular programming language/framework community can be) but I use it every day at work and I think it's just as good as some of the alternatives out there.

One of the arguments against React that I hear most frequently is that React produces inaccessible websites which are <div>s all the way down. It doesn't. If React apps are a mess of un-semantic <div>s, it's because the developer put them there. The issue is not with the framework, but the lack of semantic HTML knowledge of the developers who use it: you can write any HTML you like in JSX.

Ultimately, screen readers tend to ignore <div> components, as they're generic containers. If we use semantic HTML elements for the actual content of the page, there shouldn't be a problem at all from a markup perspective.

React components can't return more than one element, so with older versions of React you had to wrap multiple elements in a container <div>. This would have added a few extra containers to the page. But the introduction of React Fragments solved that, and usually doesn't result in any additional elements being added to the DOM.

Another thing to watch out for is screen readers not alerting users when content on the page changes. This isn't a React problem specifically but a single-page application (SPA) problem, and it can be solved with ARIA live regions. You'd still have this problem if you built your app in vanilla JavaScript.

Ideally, your SPA should also work with JavaScript turned off - with React we have tools like Next.js which produce isomorphic (server- and client-side) applications.

Myth 7: Automated testing will catch all accessibility problems

People love to show off their Lighthouse scores, don't they?

Is it though?

Lighthouse is an open-source automated testing tool that you can run as a Node module, from the CLI, from Chrome or as part of your CI checks. It checks for performance, accessibility, progressive web app performance, best practices and SEO. It's a great tool, but unfortunately it's often treated as a silver bullet. A high Lighthouse score is a good thing, but it doesn't mean that you've "done" accessibility - there are always things that Lighthouse won't be able to detect.

The best way to test accessibility is to approach it from all sides. Automated tooling such as Lighthouse or axe) can and should be part of your development process, as it'll provide a quick feedback loop for common accessibility problems in your markup and CSS. But what these tools don't account for are things like the quirks of different screenreader software (and boy, do they have quirks), or the other kinds of assistive technology people will use to access your website. Lighthouse can't tell you whether your site is still legible when it's zoomed in 600%, or whether you can interact with the various parts of the app with a keyboard as you would with a mouse. The Accessibility in Government blog has a great article about what they found when they tested automated tooling on the world's least accessible webpage.

Before you merge your PR, check how your new feature behaves with screenreaders: Macs and iPhones come with VoiceOver, Android has TalkBack, Linux has Orca, and you can download the open-source NVDA screenreader for Windows. Does it read out everything it's supposed to? Is it reading out anything it's not supposed to? Are the headings in the right order?

Ultimately, there’s no substitute for getting people with actual access needs to use the website or app. You can do some user testing, commission a formal audit, and/or make sure you have ways for users to give you feedback. Include disabled users in your UX research upfront, as well, so that you're building something accessible right from the start.

It's your turn

If you encounter any of these myths, you can (and should) challenge them. A lot of the time, these myths stick around because accessibility just isn't being talked about. Be the one to bring it up, and get others on board too. Bake accessibility into your design systems and your ways of working.

Resources & further reading

Microsoft Inclusive Design Toolkit
7 Things Every Designer Needs to Know about Accessibility - Jessie Hausler
Deque - Accessible Design
Deque - Accessible Development
Marcy Sutton - blog posts and talks from an accessibility expert
What we found when we tested tools on the world's least accessible webpage - Accessibility in Government Blog

Defending yourself against cross-site scripting attacks with Content-Security-Policy

2020-05-03T00:00:00Z

I spent an entire day last week wrestling with a PDF-rendering library in React which was refusing to work in production. Locally it ran just fine, but as soon as we built our app in production mode, it wasn't doing anything. Looking at the console, the errors it was spitting out made my heart sink. I'd seen these before.

The dreaded console error

This was an error caused by our Content-Security-Policy (CSP) header, telling our browser that something in the library should be blocked - specifically, an eval() function within one of the dependencies of our PDF-rendering library. I did what any self-respecting developer would do and complained at anyone who would listen - okay, I posted on Twitter - and then discovered that a lot of other developers weren't aware of what CSP was or what it was for. So I thought I'd write a post about it.

The error messages I was getting were protecting me against a common web security vulnerability - cross-site scripting attacks (XSS). As a web developer, it's really important to be aware of what XSS is and how to prevent it.

Cross-site scripting (XSS)

XSS involves someone injecting malicious code into an unsuspecting website, which then executes on the victim's computer.

This injected code can do things like:

copy your cookies and send them to the attacker
get information about your location or data from your webcam etc
grab session tokens from local storage

On websites that store sensitive information, such as banking or shopping websites, XSS vulnerabilities could allow someone to impersonate you by stealing your access token and using it to log in as you - which means gold-plated toilet seats for them, and a nice credit card bill for you.

The Open Web Application Security Project (OWASP) recognises three different methods of XSS: stored, reflected and DOM-based.

Stored XSS

Stored XSS refers to malicious code sent in the server response from something like a database.

Example: on a website allowing people to submit comments to discuss news articles, a user submits the following comment:

Great stuff guys!<script>/* sneaky code */</script>

If the website isn't sanitizing any user input (stripping it of any HTML tags) and is rendering the comment directly into the DOM, that script will execute as soon as you load the page it's on. Before you know it, your browser has posted comments all over the site declaring your support for some deeply unpleasant organisation.

There's a really interesting episode of the podcast Darknet Diaries featuring Samy, the (accidental) creator of a MySpace worm that used XSS to get people's profiles to automatically add him as a friend. This is a great example of stored XSS, because it all started with something he posted on his own profile (which was then stored in MySpace's database).

Reflected XSS

This is where malicious user input in a request is sent back in the immediate server response, executing on the receiving client's browser.

Example: someone posts a link online to a shopping website, with a search term in the URL so it takes you directly to the catalog page. But they've also included some <script> tags in the query string.

https://niche-tshirts.com/shirts?q=extreme+ironing<script>/* sneaky code */</script>

When the server receives the request, it takes the entire query string and uses that as the search parameter. In the HTML that it returns, it renders:

<p>You searched for: amateur paleontology<script>/* sneaky code */</script></p>

Then, your poor unsuspecting browser will execute what's between those script tags, and the attacker will be able to gain access to your access token and anything else they've managed to scrape.

DOM-based XSS

Finally, DOM-based XSS is when JavaScript running on the page uses data from somewhere the attacker can control, such as window.location (the URL of the page). Say we have some JS on our page which takes window.location and then executes some function with it:

https://niche-tshirts.com/shirts?q=spelunking

const params = new URLSearchParams(document.location.search.substring(1))

const searchTerm = params.get("q")
document.getElementById("content").innerHTML = `<p>You searched for: ${searchTerm}</p>`

If our attacker from before sends another link with the <script> tags in the query string, these will be rendered into the DOM when the browser sets the inner HTML content of the #content element.

Unlike the previous two examples, this all happens client-side - the server isn't involved at all.

Preventing XSS

Some of the methods we can use to prevent XSS attacks on our websites include:

sanitizing user input, making sure there are no HTML tags in it
escape certain characters (like <, >, &, and ") with HTML entity encoding (e.g. & for &) to prevent them being executed
not rendering arbitrary content from the server as HTML - render it as plain text
check the Content-Type is correct - only text/html if you are definitely returning HTML
use HttpOnly cookies for sensitive data so that the JavaScript Document.cookie API can't access them
and... set up a Content-Security-Policy header!

Content-Security-Policy is a set of rules about permitted content on a website

Content-Security-Policy is an additional layer of security on a site, preventing things like malicious scripts from being run by defining strict rules about what content you can and can't have on a website. It can be one of the HTTP headers that we can send from the web server to the client (browser), or a meta tag in the <head> of an HTML page. A browser will read the CSP and check whether the scripts, stylesheets and various other resources it's executing or displaying conform to the rules in the policy. If not, it won't load them.

CSP is basically Browser Gandalf.

A CSP meta tag may look a bit like this, for a site with Google Analytics and some Twitter/Facebook embeds, and images from a CDN:

<meta http-equiv="Content-Security-Policy" content="default-src 'none'; manifest-src 'none'; prefetch-src 'none'; worker-src 'none'; object-src 'self'; font-src *; connect-src 'self' https://www.google-analytics.com; img-src 'self' https://some-cdn.com; script-src 'self' https://platform.twitter.com https://www.google-analytics.com https://connect.facebook.net https://staticxx.facebook.com; style-src 'self' https://platform.twitter.com">

An example Content-Security-Policy error from Google

The CSP header or meta tag content is always a string containing a semicolon-separated list of rules.

A policy has a list of directives which are usually suffixed with -src, and refer to different kinds of rules for resources and content on the page.
Some common categories of directive are:

fetch directives: which resource types may be loaded, and where from
document directives: what properties the document or worker may have
navigation directives: where a user on the page can navigate to/submit a form to

Next to each directive we specify one or more permitted sources for each of these directives.

script-src: 'self' https://othersite.com;
<!-- directive: source source; -->

I won't go through every single directive - there are a lot - but I'll outline some of the most common ones, and what rules they might enforce. Plus, the good old caveat that Internet Explorer only supports one directive (sandbox), and that's with the legacy X-Content-Security-Policy header.

While the HTTP header and meta tags are mostly the same, the main differences are that HTTP headers have wider browser support, support all of the directives (meta tags support most of the directives) and may be cached by proxies (meta tags won't be).

As long as you're employing multiple methods of defence against XSS, including CSP, you can protect yourself (yes, even in IE). It's important to emphasise here that CSP is one way of protecting your website against XSS - it's not enough on its own.

Fetch directives

These directives govern which resource types may be loaded, and where from. Things like images, scripts, styles and frames will be defined here.

Any of these directives may also have a wildcard value (*), which basically means "anything goes".

image-src: Permitted sources for any images/favicons on the page.

script-src: Permitted sources for any JavaScript on the page.

style-src: What kind of CSS it's allowed to load, and where from.

font-src: where fonts specified by the CSS @font-face rule may be fetched from (e.g. Google Fonts)

frame-src: where iframes may load content from (e.g. Stripe elements)

connect-src: hosts that your JavaScript may make requests to (e.g. an API, with fetch)

default-src: the fallback if any of the rules don't match the resource

Document directives

Document directives restrict the use of plugins (such as with <embed>) and let us enable sandbox mode.

plugin-types: allows you to define permitted MIME types for embedded media and elements using <embed> tags. These days, you rarely need to use embed, so I don't expect you'll come across this one very much.

sandbox: literally the only directive that IE supports! This allows you to restrict the browser environment on the page, effectively blocking everything - popups, scripts, forms, you name it. It has different sources from the rest of the directives - you can specify exactly what should be enabled in sandbox mode. Take a look at the MDN documentation on sandbox for more information.

form-action: if you're using traditional HTML forms with action attributes, this directive specifies the URIs you're allowed to submit to.

frame-ancestors: specifies which pages or URIs are allowed to embed iframes and other frame/embeddable content.

Sources

Most directives have the same possible list of sources. With the exception of host source and scheme source, they are all specified in single quotes.

'self' - anything from the same host is fine. So a CSP for localghost.dev with image-src: 'self' and script-src: 'self' would be allowed to display images and run scripts from localghost.dev.
a host source : external hosts that the resource can come from.
- For example, style-src: "https://myhost.com" allows you to include a stylesheet from myhost.com, e.g. <link rel="stylesheet" href="https://myhost.com/style.css"/>.
- If you often use content delivery networks (CDNs), you'll need to specify them here. You can also use wildcards for the subdomain of the URL, and restrict things to specific ports as well. The protocol matters, so a host source with https:// will not allow anything from http://.
- e.g. connect-src: 'self' https://*.localghost.dev will allow anything over HTTPS from a subdomain of this site.
a scheme source: what scheme (protocol) it's okay to fetch resources from. Chiefly https: or http:.
'unsafe-inline': whether inline <style>/<script> tags are allowed. I've only really used this for script-src and style-src before. I'll talk more about why inline style and script tags are a security risk later in the article.
'unsafe-eval': whether or not JS is allowed to use the eval() function, which executes arbitrary code from whatever string is passed in. I'll go into more detail about why this is a bad thing in a later section.
nonce - you may specify an unguessable cryptographic nonce (a base-64 encoded string) which you can then pass into inline styles or scripts as an attribute to allow them to load on the page. This means you can use inline <style nonce="mysecretstring"> or <script> tags without indiscriminately allowing all inline styles - effectively marking only a specific set of inline styles as "safe". This must be randomly generated and unguessable, otherwise it's basically pointless as anyone can guess the hash and pop it in their injected scripts.
hashes - e.g. sha256-<your hash value>. This is a base64-encoded representation of your inline styles or scripts, so the browser can check the hash against its own hash of the <style>/<script> to make sure it's the real deal. Anything that doesn't match the hash will be ignored. Hashes are static, while nonces are generated server-side on every page load.
none - no URLs match, no nothing may be loaded at all. For example, I don't use iframes on this site at all, so I'd have frame-src: none.

`unsafe-inline` and the risks of inline styles

But why would we have to explicitly enable unsafe-inline for style-src, and why are inline <style> tags considered "unsafe"?

There are actually a few vulnerabilities that can be triggered using CSS. They're rare and, yes, less harmful than JS-based XSS attacks, but it's still worth protecting yourself against them.

messing up your site's styles - on a big-name website or app, this can cause reputational damage
injecting styles into the page to add unsolicited content or offensive text
disguising user-generated content to look like official content, e.g. a fake login link

All of these can be prevented with unsafe-inline, meaning the browser will only pay attention to the styles from your defined stylesheets.

Ultimately, allowing unsafe-inline is a calculated risk: if you really can't get around it with a nonce or a hash, then you can enable this knowing that you are introducing a slight vulnerability, but it's highly unlikely to be anything super severe.

There's a helpful StackOverflow answer which explains this in more detail.

Scripts, `unsafe-inline` and `unsafe-eval`: why `eval()` is evil

While enabling unsafe-inline for styles is not the end of the world, it's a bad idea to allow it for scripts. A lot of harm can be done with an inline script that's been injected into your code - with a connect-src directive defined as well it would mean that that script couldn't connect to any other sources, but it could still cause havoc, such as pretending to be you and updating user-generated content.

eval(), on the other hand, should be avoided at all costs. It takes a string as a parameter, and blindly executes it as Javascript. There's literally a section in the MDN article about eval() called "Never use eval()!". This opens up a whole host of security vulnerabilities - if unsafe-eval is enabled, anyone can execute arbitrary code in your application. Yikes.

How to create a CSP header

In a static site, you can add a meta tag to your site's <head>:

<meta http-equiv="Content-Security-Policy" content="default-src 'none'; manifest-src 'none'; prefetch-src 'none'; worker-src 'none'; object-src 'self'; font-src *; connect-src 'self' https://www.google-analytics.com; img-src 'self' https://some-cdn.com; script-src 'self' 'sha256-flsjfljlkfjaspdjfsdkgs' https://platform.twitter.com https://www.google-analytics.com https://connect.facebook.net https://staticxx.facebook.com; style-src 'self' 'nonce-adsfasdfasfsadf' https://platform.twitter.com">

If you're running an app with an Express server, you can easily set it as one of the response headers with helmet-csp - check out the Helmet docs for more information.

The safest method is to have the most restrictive CSP possible, and only add new sources if you're completely sure. Include a default-src: 'none' so that if no rule matches a resource, it will be blocked.

Adding to a CSP header

When is it safe to add new sources to a CSP header? Perhaps you've included an image or stylesheet in your code, and your browser is refusing to render it because it violates the CSP. Before adding the URL as a source, consider:

do you trust this site?
how specific can you make the URI? (avoid wildcards unless it's a host you control)
could you host the file on an already approved source?
could you add the CSS file to your repo instead?

styled-components and `unsafe-inline`

If you're using styled-components, which renders <style> tags into the page, rather than enabling unsafe-inline for styles you can define a nonce by setting it as a Webpack global (__webpack_nonce__). The caveats: this is apparently undocumented, and only works with server-side rendered code. So you might have to enable unsafe-inline for that one.

Environment-based CSP

If you run different environments for development and production, you may want to consider serving different CSP headers for different environments. For example, your image-src directive might point to a non-prod CDN if process.env.NODE_ENV !== 'production, but the production CDN otherwise. Similarly, if you use a local server at localhost:6060 as an API for development but your production app points to a hosted API somewhere else, you might want to add localhost:6060 to your CSP only for the development environment.

There are some frameworks, such as Hugo and Next.JS, which rely on inline scripts for hot reloading. In this case, it's fine to add unsafe-inline to your script-src in development.

For example, if you use Hugo and want to enable live reloading with your CSP, as well as scripts imported from the site itself, you can use .Site.IsServer (though this only works if you use server mode for development and not production):

<meta http-equiv="Content-Security-Policy"
    content="default-src 'none'; [...] script-src 'self' {{ if eq .Site.IsServer true }}'unsafe-inline'{{ end}} {{ .Site.BaseURL }};">

The moral of the story

So, how did I get around the unsafe-eval warnings I was seeing in the console?

Unfortunately... the only solution was to chuck out that library and find something else. There are no workarounds for a library that uses eval.

When adding a CSP header to a site, start out with the principle of least privilege: only permit exactly what you need, nothing more. When in doubt, be overly restrictive, and see what console errors you're getting.

If you're working on a site or app that has a CSP header set, don't be tempted to add sources just to make console errors go away. Make sure you know exactly what you're allowing.

And promise me you will never, ever enable unsafe-eval.

References & further reading

Cloudflare - What is Cross-Site Scripting?

MDN - Content-Security-Policy

MDN - Cross-Site Scripting

OWASP - Cross-Site Scripting

OWASP - DOM-based XSS

Google's CSP Evaluator can check how watertight your CSP is (but is not exhaustive).

Google Web Fundamentals - CSP

ffconf 2019: future friends beside the seaside

2019-11-16T00:00:00Z

Now in its 11th year, ffconf is one of the biggest events in the conference calendar for web developers across the UK (and further afield). Yet somehow I've managed to miss every one since I got into tech, because of some reason or another - last year I was at the week-long blockchain sales pitch that is Web Summit - so I was understandably very excited to finally be going. It takes place at the lovely Duke of York's Picturehouse in Brighton - the first conference I've attended that had cupholders in the seats! (Fun fact, I applied for a job there once.)

Photo: Trys Mudford

One of the best things about attending conferences is seeing friendly faces from the community, and this particular subset of the JS community is so lovely. It does give you hope (and a refreshing break from some of the other conferences and meetups I've attended in the past few years which have had 97% more posturing). I spend a lot of time in the London bubble so it's great to meet folks from other tech communities, and going to the Async meetup the night before was a great way to do that.

JS (and real-life) friends! (photo: Trys Mudford)

(I also got to meet Suz Hinton at the afterparty and didn't make a fool of myself, so that is always a plus. She's extremely lovely.)

What made these talks especially good was that they focused more on people and stories. My favourite kind of conference talk is one where people show something amazing they built, and share their experiences of building it (a good example from JSConf EU 2019 is Bringing back dialup: the internet over SMS by Alexandra Sunderland). I don't need to come away with an exact step-by-step guide on how to do the thing (I'll never remember it all anyway), and it might not even be a practical thing for me to ever attempt, but I want to know all about it because it's amazing.

I've been thinking a lot recently about the reasons that people learn to code - and in fact, I submitted to the ffconf CFP with a talk about this, which I'm going to try and polish up and submit elsewhere. When I started doing web development, I didn't really know what I was doing or why I was doing it - I thought it'd be cool to make a website, and how else was I going to get my Neopets shop to play music and have a flashy background?

It seems like a lot of the coding for creativity's sake has been lost in favour of learning the latest, greatest technology in order to advance your career and to be able to say that you're using it. I could go on, and I probably will in another blog post, but seeing people up on stage doing ridiculous and beautiful things with code gives me hope for creative coding (and, most importantly, it inspires me to do some too).

I came home from ffconf and restyled my entire website with ludicrous link effects and a gradient border. It's not quite making jewellery from SVGs but it's a start.

Here's a bit of what I took away from each of the ffconf talks. I haven't included many photos because my phone's camera is atrocious in low light, but I've borrowed some nice pictures from the official photos by Trys Mudford on Remy Sharp's Flickr.

Sharon Steed - Engaging Empathy

"Empathy: the thing you have to do to not be an asshole in the office."

Opening the conference was author and communications consultant Sharon Steed. She spoke about her experiences of growing up with and living with a stutter - and the difficulties she's had with others not taking her seriously. She's a fantastic storyteller, and as she shared with us her challenges and achievements it felt like she was taking us with her on her journey.

Sharon Steed (photo: Trys Mudford)

She compared empathy to love; "the thing everyone understands, but nobody can explain". It's intangible, but it's also a choice: we can choose to have empathy for others (and we should). (Her tales of new love were accompanied by that picture of Britney and Justin in denim, which was an all around win for me.)

So, what to take away from Sharon's talk? We should foster environments of collaboration and inclusion. People need to feel safe in order to speak honestly - having open lines of communication and being transparent from the start will help this. She also pointed out that teams don't always need to work in the same way: people should be able to do things on their own terms.

Sharon also described what she called the "Key Empathy Behaviours": patience, perspective and connection. As long as we are being present and remembering the why of what we're doing, understanding where others are coming from, and speak for intention and not impact, we'll be able to engage empathy and make everyone feel like they belong.

ffconf talk page: Engaging Empathy

Amina Adewusi - What does it take to become a developer in 2020?

"We need a recruitment revolution."

Amina's talk focused on the barriers to entry for under-represented people in the industry: a topic that has come up time and time again but doesn't really seem to be getting any better (especially for people of colour).

Amina Adewusi (photo: Trys Mudford)

Her words were powerful, and the measured way she spoke really conveyed the gravity of what she was saying. In the last 11 years, the proportion of women and non-white students in computer science has not improved: last year, only 20% of computer science students were female, and only 15% were non-white. And a computer science degree is already a privileged platform to launch your career from. What about those who don't go down that path?

She spoke of the generosity of strangers: the bootcamp alumni who all answered her questions when she contacted them out of the blue, happy to give advice. And while bootcamps are a great way to fast-track your career into tech, they're also very exclusionary for anyone with caring responsibilities, and they can be very expensive. She spoke of her experiences raising a baby while also learning to code, which frankly blew my mind - learning to code is really hard (don't let anyone tell you otherwise!) so to do that while also looking after a very young child is just phenomenal.

For those who self-teach, it's hard to get a job once you've learned the skills. More often than not, recruitment is unforgiving, with high expectations, long interview processes and unreasonable deadlines (Amina recalled being sent a tech test on a Friday, with the expectation she'd send it back on the Monday!). It's not just the time it takes, either - the interview process can be very intimidating and sometimes discriminatory.

As Amina put it: this is a call to action. How can we, as experienced engineers, help the next generation of developers get a foothold? Some of her excellent suggestions:

mentor at organisations like Codebar
pair with new engineers
give engineers time to work on open source
be mindful when recruiting - don't assume everyone has all the time in the world
observe the "pacman" rule when talking to people at events

ffconf talk page: What does it take to become a developer in 2020?

Alice Bartlett - Getting more from Git

"My process is 'try stuff until it works and don't ask any questions'."

Somehow, Alice turned a pretty dry subject - git - into one of the most relatable and entertaining talks I've ever seen.

Alice Bartlett (photo: Trys Mudford)

With entertaining anecdotes about the meaningless commit messages she'd write early in her career (we've all been guilty of that, and you should see the nonsense commits I've made to this very website) she highlighted the importance of considering who else is going to be reading all of it - including Future You. A commit message should be a single unit of work that makes sense in isolation, and that will tell you why the change is made. So no more "fix bug" commits.

Of course, it's not always possible to commit code with this in mind, and many of us approach coding by trying stuff out and going all over the place, so git offers us some handy ways of rewriting history so that we can make the commits sensible after the fact.

Here, Alice took us through a brief history of git (including a very entertaining swipe at Linus Torvalds and his controversy: "the creator of Linux and git, two projects he named after himself"). Many attendees in the room hadn't had the... pleasure of working with non-distributed source control systems like SVN, so she took us through how git differs and why it's so helpful for things like testing out changes and controlling the quality of code that's merged in.

"Why are we so bad at git?"

Everything is confusing

A lot of the problem is the jargon and the impenetrable docs, Alice argued - and I agree with her there, having never read a man page that I understood.

And then, using simple and clear language, Alice took us through the process of rewriting git history using interactive rebase (git rebase --i). It's a super useful tool, allowing you to squash multiple commits into one, reword commit messages and change the order they are applied in. She also showed us git add --patch which lets you choose which "hunks" of your code to commit and which to leave unstaged. I'm not going to go into too much detail here, but the video is definitely worth a watch when it comes out.

Some top git tips here to take away:

Don't just link to Slack posts or tickets in the PR - give a bit of background info
...but don't write an essay about the change, keep it concise
commit messages should be meaningful and say why the change happened

ffconf talk page: Getting more from Git

Laura Kalbag - 8 Unbelievable Things You Never Knew About Tracking

"We're asked to give up everything, or get nothing."

Laura highlighted the ridiculous amount of information that various sites have about all of us just through embedded scripts and images. And even though this data is anonymised, a study showed it was possible to actually re-identify people from this data based on their browsing habits. Scary, right?

)

She touched on the Cambridge Analytica scandal - "tracking affects democracy" - and how companies can manipulate people through precise targeting based on their interests, knowing exactly what will make them tick. Facebook's latest ad campaign got a shout out for being totally hypocritical - when you choose to share something with "Only Me" or "Friends" you're also sharing it with Facebook!

Companies make it worse by having incomprehensible terms and conditions, filled with legal jargon. When you consider that 1 in 6 people in England have very poor literacy skills (source: National Literacy Trust) it's especially problematic. Sites like Facebook are a lifeline for many people, but if they can't understand what they're signing up for is it really consent?

While we can't escape technology - Laura argued there is no longer a distinction between "online life" and "real life" - we must all consider the impact our products will have outisde of the immediate interface. She described how we can build more ethical tech, by making things that function without users' personal info, furthering the human experience rather than for corporate profit. I find this a really interesting and difficult dilemma, as in our society it's really difficult (if not impossible) to build a sustainable product that isn't for-profit in some way. It would require pretty significant government support, which isn't going to happen any time soon.

"Friends don't let friends get tracked by corporations."

I knew from the title that this talk would be worrying, but I didn't anticipate just how unsettled I'd feel afterwards! As someone whose life has been basically entirely managed by Google products for years, I realised I needed to make a change. Laura suggested switching.software as a resource for alternatives to common "big tech" products, which is a great place to start.

ffconf talk page: 8 Unbelievable Things You Never Knew About Tracking

Harry Roberts - From Milliseconds to Millions: A Look at the Numbers Powering Web Performance

"How do you know the site is slow?"

A talk with a rather different tone from the last one - a focus on Harry's experience as a web performance consultant. Performance is definitely one of those things I know I should know more about, so I was geared up for the next couple of talks to help me boost that knowledge a little bit.

Harry Roberts (photo: Trys Mudford)

Harry had the great suggestion of keeping a list of questions that you can ask all potential clients, so that you can better understand the problem. In his case, things like: "How do you know the site is slow?". You could do this for any kind of consulting work - knowing exactly what to ask is hugely important. You can shape these questions over time, knowing exactly where to look next time and what doesn't work.

I must admit I was a little put off when he suggested we "leave our ethics at the door" given the talk he'd just followed, and some of the talk seemed a little too focused on the clients and not on the stories behind it. But this was, after all, a talk on numbers.

I found it particularly interesting how he identified a performance issue localised to Venezuela, and got all the engineers on the team to use a simulated Venezuelan internet connection to get them to think about things like network conditions and how it might be for other countries. We often take our internet speed for granted, and even when Virgin Media is at its worst, we still have vastly better internet than much of the world. Much of the world's population is dependent on mobile internet, so are our apps really suitable for everyone?

Harry advocated for normalising performance - making it part of our everyday work. It can be a hard thing to argue for, when your managers are pushing for more new features, but if you can show them the numbers, it's hard to argue.

ffconf talk page: From Milliseconds to Millions: A Look at the Numbers Powering Web Performance

Anna Migas - Effortless Performance Debugging

"If [the browser] fails to load the frames fast enough, we'll experience jank."

Continuing my crash course in performance, Anna showed us with a live demo how we can use the power of Chrome Dev Tools to debug some common performance issues. Using the Profiler tab she showed how we can identify how loading is progressing and the performance of animations during interactions. You can see at-a-glance what's taking the longest time to load, plus it also has some helpful metrics such as the time to First Meaningful Paint.

Anna Migas (photo: Trys Mudford)

In the spirit of the Live Demo, Anna was going to show us how the Lighthouse integration in Chrome can audit performance issues on web apps, but sadly technology was not on our side and Lighthouse wouldn't work (it seemed it wasn't just Anna though). Despite this hiccup, there were still a lot of really useful tips I took away from her talk:

Look through Network tab to see what's been downloaded, and in what order
Block elements using the request blocking tab to see the impact of not loading them
Using font-display: swap to show a fallback font before the font is loaded
Using a lazy-loading library to only load pictures as you need them
Using an image's intrinsic ratio to show placeholders and prevent text from jumping around as images load
Splitting CSS into a critical path stylesheet and others that can be loaded separately

ffconf talk page: Effortless Performance Debugging

Charlotte Dann - Taking The Web Off The Screen

"You'd think that art is an expressive process, and adding this binary middle step seems incongruous, but... computers are better adapted to the design process than any traditional artistic medium."

I actually didn't make many notes for this talk because I was so engrossed in the incredible visuals Charlotte was showing us. As I mentioned before, I'm a big fan of coding for artistic reasons, even if I don't really do it myself much. I'm not particularly "good" at SVG or any kind of web animation, so it blows me away when I see what people can do with canvas, SVG and JS.

Charlotte Dann (photo: Trys Mudford)

In Charlotte's case, she bridges the gap between digital and physical art, using what she designs using generative CSS to produce prints and even intricate jewellery. She's made jigsaw puzzles which she's laser cut out, got a pen plotter to draw abstract designs onto pieces of paper for that precise yet hand-drawn look.

Using nth-child pseudoselectors, she showed us how you can create an abstract pattern from a series of squares and circles. She's done a few of these, and used them as wall art for her studio!

She's also the founder of Hexatope, a web app that lets you draw beautiful patterns on a hexagonal grid and get them cast into silver and gold jewellery. The designs are incredible, and it's really fun to play with.

I absolutely love hearing about things like this, and it's inspired me to get more involved in creative coding. If only people spent as much time doing things like this as they did arguing about which framework is best.

ffconf talk page: Taking The Web Off The Screen

Suz Hinton - Adventures in reinventing interfaces

"I want less mass-produced surveillance bullshit and more Harry Potter magic."

I was super excited for Suz's talk, as I've followed her online for some time and I think her hardware projects are amazing, so it was great to see some of them demoed. She demonstrated how we can use web APIs to interact with non-standard interfaces like printers and other hardware.

Suz Hinton (photo: Trys Mudford)

Using a thermal receipt printer, the Web Media API and the Web USB API, Suz recreated her very own Gameboy Printer! She also showed off her web app that lets you upload Arduino programs directly to the Arduino via the browser, which made me think I should dig out the Arduino I've had in a drawer for several years and never used. (We've all got a drawer like that.)

The tone of the talk shifted considerably when Suz started talking about ownership over computers and data. She cited a 1985 ruling by the Federal Communications Commission which allocated the 900MHz frequency band to industrial, scientific and medical uses. Amateur radio users were allowed to use the band if they liked, as long as it didn't interfere with the protected uses.

However, now the FCC have proposed that private companies should be able to use these bands. And guess who's jumped straight in there? Everyone's favourite Big Bad Retailer, Amazon.

Amazon's new Sidewalk network functions on this 900MHz band. Even the 700-odd Amazon employees testing the products managed to form a localised network on the 900MHz frequency stretching across much of the Los Angeles Basin. Meaning they've basically made a frequency jammer. (Bear in mind frequency jammers are illegal in many countries.) If hundreds of thousands of Amazon customers start buying these products which operate on this frequency, what's going to happen to all those medical devices that rely on this band?

"This is the scariest thing I've ever heard."

At this point Suz started crying, which really drove home just how doomed we'll be if this stuff keeps happening. "We are pretending that these devices are supposed to be helping people, and these people have no idea that they are actually contributing to a privately owned network that companies like this can do whatever they want with."

It's our job to make sure that we are fighting against things like this - "we've done a bad job at educating people". We should be building more "Harry Potter magic" instead of buying corporate home technology, Suz argued - she namechecked Samantha Goldstein, who built a stained glass panel that goes cloudy if it's raining.

ffconf talk page: Adventures in reinventing interfaces

Reflections

I came away from ffconf inspired and filled with a desire to build weird stuff: I want to learn to do things with hardware, make pretty patterns with CSS, and teach my niece how to do the same just for the hell of it.

I also came away feeling terrified by corporate surveillance and the absolute disregard for ethics in technology under the guise of convenience.

Being a developer isn't just about building flashy stuff and sending it off into the world and moving onto the next thing: we've got a responsibility to make sure that the tech we're building is doing good, not harm, and that people are educated about the implications if we do start building creepy stuff like Sidewalk. As Laura Kalbag put it: be the advocate, and question the default. We know what these products and these companies are doing, so it's our job to tell everyone about it.

ffconf is a small, family-run conference, with passionate speakers who have a story to tell. I'd love to see more community-focused conferences like this - it's all too common nowadays to go to a big conference and end up listening to sales pitch after sales pitch when all you want to do is learn something.

I feel like I should probably get rid of the Google Home that's sitting in my living room right now.

Everything I googled in a week as a professional software engineer

2019-09-02T00:00:00Z

Update 15/10/2022: I've written a new version of this! Everything I googled in a week as a senior software engineer

In an attempt to dispel the idea that if you have to google stuff you're not a proper engineer, this is a list of nearly everything I googled in a week at work, where I'm a software engineer with several years' experience.

Happy birthday to the ground.

Obviously these weren't all googled in a row (although you can probably spot that a few were), but throughout the day. I can't remember the context of everything I was googling, but hopefully it'll make you feel a little better next time you have to google something.

Monday

npm react-testing-library - during a React upgrade, looking at dependencies to see latest versions and checking for breaking changes.

Expecting a parsed GraphQL document. Perhaps you need to wrap the query string in a "gql" tag? - said React upgrade then started causing some super fun errors.

react-apollo release notes

react-apollo/test-utils - tests were throwing some odd errors with our graphQL components.

undo a rebase - oops.

react testing library apollo "invariant violation" - package upgrades are so much fun!

jest silence warnings - don't judge me, ok?

semantic HTML contact details - wanted to check if the <address> tag was relevant here

aa contrast checker

temporary visual impairment - fact checking for an accessibility talk I was giving that week

dominos accessibility - popcorn.gif

shame gif - an important part of any presentation

Tuesday

javascript get array of unique dates - if I have an array of Dates, how can I filter them so they are unique? (reduce, naturally, but I can rarely use that without googling it first)

date to locale string

js date to locale string - after I got a load of Java results

alternatives to Moment.js - it's large

group array items by date - more reduce fun

sort object keys javascript

react fragment keys

next link - needed a reminder of how to use the Link component in Next.JS

React.Children.only expected to receive a single React element child.

visual studio code disable autocomplete html - it keeps autoclosing HTML elements on the same line, and I still can't switch it off

dt dd dl - couldn't remember what the example use for these was.

html nested sections - is it ok to have <section> inside <section>?

display dl in pairs

veggie ipsum - the best lorem ipsum generator

css keyframes

css animate underline text

dl vs ul

react generating keys - should I use some kind of hash, or should I use data in the props? (I ended up constructing a string with unique timestamp data)

css checkbox - can we style checkboxes yet? (no)

flexbox center span - it was 17:24 and I was tired by this point

grid minmax

flexible grid row - I don't have a whole lot of CSS Grid experience, so I always end up googling a ton with this.

grid row height auto

cauliflower shortage - someone told me about this and I panicked

next.js hooks - we can use them, right? (we can, and I did)

Wednesday

cors - today is going to be bleak

the corrs - once I hit some CORS errors I decided I needed to make a meme, and I needed to find the perfect image. It took a surprisingly long time.

Worth it.

git patch trailing whitespace - I was sent a git patch with some whitespace that prevented it from actually patching

jsx annotation

web api fetch preflight - in my CORS adventures I wanted to read up a bit more about preflight requests.

web api fetch origin header

discriminated union flow - trying to diagnose problems with my Flow types.

whitespace regex - is it \w? (no, that's a word - it's \s)

regex not letter

pat butcher emoji - what can I say, I google important things

woman shouting at cat

google oauth

next.js authentication - sometimes it's helpful to google stuff to see if anyone has written examples of how to do common flows in the framework or tool that you're using

component displayname - do I need to do this with my higher-order components?

nextCookie - starting to mess around with oauth cookies

reading cookies in react - there must be a better way than document.cookie

js-cookie npm

cookies-js

npm cookie

universal-cookie

google oauth cookie

🍪

Thursday

"log in with google" localhost - was having all sorts of problems getting this to work

httpserverrequest javascript - I have a feeling this was something to do with Flow types

nextjs flowtypes - yep, there you go

"python-social-auth" react - trying to figure out if the django backend I was working with would play nicely with my React frontend

google social login

vary header

get cookie from 302

google social login cookies - I was having a really fun time with this as you can tell

google oauth cookie

python-social-auth set-cookie

python-social-auth site:stackoverflow.com

python-social-auth react site:stackoverflow.com

django - I think I gave up at this point and just googled Django because I have literally never used it

fetch send cookies

testing same origin credentials locally

cross origin cookies - spoiler alert: not a thing

useState default value

"The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when when the request's credentials mode is 'include'. - googling error messages is only second to console.log() as a debugging method

useState with empty array

react hooks initial state empty array

"Provisional headers are shown" - this is where the requests weren't going through and I couldn't see what the actual headers being sent were

fetch send cookies

how to see request headers in chrome

fetch not sending cookies

Thursday was a whole lot of fun D:

Friday

provisional headers are shown - still at it.

sending cookies from localhost - have I mentioned that I hate cookies?

editing host file - desperate times (and it didn't even work)

sending cookies with different domain

next cookie

getinitialprops functional component

getting cookies from document

js find - to check the usage and return types

string contains

string methods js - I can't keep any of these in my head

js string methods - 20 mins later

js fetch manual cookie

django react cookies localhost

django react cookies localhost site:stackoverflow.com

httponly cookie

django httponly

async await promise.all

nextjs port

google appengine node ports

next rename static

install gcloud cli

method patch - couldn't remember what the HTTP method PATCH does.

nextjs env

next.js environment variables

next js docs

editing data with hooks - literally no idea what I was trying to google here but this was past 5pm so I was evidently quite tired

react form submit

dayjs - I needed the documentation again.

What I'm trying to show with all this is that you can do something 100 times but still not remember how to do it off the top of your head. Never be ashamed of googling, even if it seems like the most basic thing you're looking up. I can never remember how Date works.
I've built plenty of forms in React but couldn't remember how onSubmit worked on the Friday evening at 5:30pm. I constantly have to google JS string methods. Cookies are terrible. (Incidentally, we fixed the cookie issue by running everything in a docker container and tunneling with ngrok, so everything's on the same domain.)

Questions to ask at an engineering interview

2019-08-22T00:00:00Z

Tech job interviews are often different flavours of the same thing, regardless of where you apply. Interviewers are likely to ask you questions about your experiences, perhaps a hypothetical question about what you might do in a certain situation, or delve into some of the how-it-works stuff under the hood of whatever programming language you'll be using. However, there's one question that you can guarantee will come up:

"Do you have any questions for us?"

(At this point you'll probably sigh with relief - internally, at least - as you've reached the end of the interview.)

It might be tempting to just skip over this with a "no, thank you" - maybe the job description gave you enough information for now - but you should always ask at least one question. It's a surprisingly important part of the interview. Firstly, it's an opportunity for you to squash any worries you might have, or find out the answers to anything that wasn't quite clear before. Secondly, it's a chance for you to peek into how things really are at Company X before you get too far in and realise you've Made A Huge Mistake. An interview should be as much you interviewing them as it is them interviewing you, as you need to find out whether the company is a good fit for you.

Of course, you don't have to wait until the very end of the interview to ask questions - it's great to ask relevant questions throughout (though be careful that you don't end up answering every question with another question)!

What your questions say about you

This part of the interview is not just for your benefit: the questions you ask tell the interviewer more about you than you might think. For starters, it shows how engaged you are, what your priorities are and the kind of things you value in your role. It's an opportunity to show off your knowledge and experience by asking questions tailored to the work that you're looking for.

How many questions is too many? It depends how much time you've got left, but don't be afraid to turn up with a list. I brought a notebook into mine, and I took notes while they answered.

So, what kind of questions might you ask? Obviously it's a chance for you to get answers to things that weren't clear about the application process or the job itself. You can ask about the kind of learning and development opportunities, or ask the old favourite of "what do you like most about working here"? Don't be afraid to spin questions that the interviewer asked you back around on them, as long as it's relevant and reasonable.

My favourite interview question tactic is to think about things from my previous roles that frustrate you or that you know you don't want to experience again. Asking questions about these things can give you an idea of whether they do things differently at this place, or whether you're walking into the same job all over again. (Alternatively, if there's something you particuarly enjoy about your current role, it's a good way of finding out whether it'll be the same at this new place too.)

I'll give you some questions that I might ask as a starter (and in some cases, what these questions are really asking). I'm not saying you should ask all of these questions - that would probably take all afternoon - but feel free to pick and choose depending on where you're applying and what's important to you. They're here as a starting point.

The "how does this work here?" questions

These are the questions based on your past experience. It's a great way to understand more about processes at the company, as well as making sure you won't end up working at somewhere that's exactly the same as your last place (unless that's something you want).

Working in product teams

How closely do the dev team work with business stakeholders/customers?

Is this a case of "IT vs The Business" or are engineers embedded throughout the company? I've worked in both situations, and it's much nicer being considered a core part of the business rather than a "supporting function" building a product for someone else's business needs. Is there a product manager on the team who represents the needs of the customer? Are there regular demos with relevant stakeholders? Do they do any user testing?

How does work come in to the team?

How involved are engineers with deciding what to build?

Am I going to be involved in the decision making and the shaping of what we're building or am I going to be blindly picking up JIRA tickets? Is it an iterative development process, or is it a case of "requirements come in, code comes out 6 months later"?

It took a bit of getting used to, but now I love being involved right at the beginning, helping to decide what it is we're going to build and how we're going to build it. It's related to the first question in that it shows that engineering is a core part of the company and not just something that you do to achieve the thing for the business.

Who makes technical decisions? How much independence do product teams have to make technical decisions?

This question is about autonomy in what you're building. Is it going to be a case of "here is the work, go and do it" or "how shall we build this? What do you think?"

Some degree of uniformity is vital, especially if you're working with lots of microservices. But having strategies for the way you work and the technologies you use is one thing; being told exactly what to do and having no independence or flexibility is another thing entirely.

Code, deployment and infrastructure

Who looks after the live applications?

Is it "you build it, you run it" or is it "you build it, and throw it over the wall"? Do engineers have ownership of the apps they build, and are they trusted to look after them?

It's also worth finding out how on-call works, because if that's something that you can accommodate, it's a great opportunity to learn about the tech and how things work.

What's your deployment process like?

What does an average path to production look like for a service or application?

Do you practice continuous integration?

How often do you release to production?

Can I deploy stuff myself on an ad-hoc basis, or is it once a week/every three months? Is it going to be six months before you let me put it into the wild?

This is about finding out how much friction there is in the path to production. The more obstacles and Process With A Capital P, the more obstacles to innovation and experimentation. That said, there is a happy medium, and I don't believe you should be firing off software into prod without due diligence, some process and quality control, especially when you're working with people's data. It's worth finding out how the company handles that delicate balance.

Bonus points for continuous deployment.

Say I wanted to spin up a new service. How would I do that?

Would I need to get permission from the Change Advisory Board in a distant ivory tower? Would I need to write numerous documents and have handover meetings for deployment and maintenance?

The answer I got in my Monzo interview was "there's a command line script to generate a new service" and I nearly wept with joy.

How do you do version control?

If they say "Subversion", it's time to question why. Is there a big beast of a monolith that was written in Java 6 and nobody has quite had the guts to move it off SVN because they aren't quite sure where all the code lives, and do you really want to work with that every day?

How are architectural decisions made?

Do you have an architecture team? What do they do?

Do you have people whose job title is literally "Architect"? If so, are they hands-on and technical, or do they come in and tell you how to build stuff and then leave again? Am I going to be allowed to make my own decisions about the structure of the software I'm building?

I've definitely met some good architects, but really things like solution architecture should be done by the team building the actual thing.

What's your testing strategy?

Do your developers do any testing? (Conversely, are you obsessed with as high test coverage as possible?) And if there's pretty poor test coverage, are they open to improving it or do they see it as a waste of time?

The "how is it really?" questions

The questions that help you delve into day-to-day life at the company.

What does a typical day look like for you?

What are the working hours like here?

Will I be working until 8pm, or can I go to my clay pigeon shooting evening class without getting Meaningful Glances from my colleagues behind their screens?

Perhaps I'm naïve, but I firmly believe in a work-life balance. I was very lucky to have that in my previous job, and I have it in my current job. I don't believe working later makes you a better contributor, as I think the more tired and burned out you get the worse your work is going to be in the long run. I want to know what kind of hours people keep so I can factor it into my decision.

Are there many parents here?

How does parental leave work here?

What facilities do you have for new parents?

This one is not a question I've asked, as I don't have children and don't plan to have them any time soon, but if you're a parent or at that stage in your life where it's something you're thinking about, you want to know whether it's a parent-friendly workplace, whether there's anywhere to go and breastfeed, and what kind of caregiver leave they offer.

I know that some places can be a bit funny if women of childbearing age ask about this kind of thing in interviews; if that's the case, I would question whether it's really somewhere you want to work.

What kind of diversity and inclusion initiatives do you have here?

Does the company take diversity and inclusion seriously? Many (if not most) tech companies have traditionally very poor diversity in terms of gender and ethnicity - and often age, too. Trying to hire from a more diverse pool of candidates is one thing, but how are they trying to make things better in order to get people to stay? Are they hiring a diversity and inclusion lead? Do they have groups or networks?

The "where can I go from here?" questions

What kind of learning and development opportunities are there for employees?

A good way to find out whether they have a learning budget, or whether you can ask for books/courses/conference tickets.

Do you ever host meetups or community events?

Perhas not important to everyone, but as someone who owes a lot of my professional development to the community as a whole, it's really important that wherever I work has a good community spirit.

Do people here ever speak at conferences?

This one is a bit less helpful as (especially if it's a small team) it could be that the employees don't want to speak at a conference, and that's totally fine. But if it's a huge company and nobody really speaks at conferences, it kind of raises the question of whether anyone does anything worth talking about (or, if they are, whether the company isn't keen on letting them talk about it.)

I hope this has given you an idea of the kind of questions you might want to ask at an interview, but more importantly, the value you can get from asking them. If you've got any more thoughts or ideas for interview questions, share this on Twitter with the link below and join the conversation!

Why software engineers should know their audience

2019-04-06T00:00:00Z

When you're talking about what you're working on, do you ever stop to think about what you're saying and whether the person you're talking to can actually understand it?

There's more to being a software engineer than coding. What people often underestimate are the so-called "soft skills" (the worst term for something that's really vital) - the way that you interact with others around you. In particular, how you communicate what you're doing to people with different skillsets.

Imagine you're in a standup and someone gives this update:

I'll synthesize the haptic DDR3 network, that should shut down the SDD capacitor!

This came straight from the brilliant Hollywood Jargon Generator, but to anyone who doesn't have as much technical experience as you, that might as well have been what you just said.

u wot m8

One of the best pieces of advice I ever got was from a tech lead who took all of the engineers aside after a standup where we'd been discussing how we were getting on with the new authentication flow we were writing. She told us to make sure we didn't go into too much technical detail in the standup, so that everyone could understand it. Sounds so simple, right?

We'd just spent ten minutes with the rest of the team - including our product manager and the marketing lead - and we'd been talking about refresh tokens and token expiry. It had meant absolutely nothing to several of the people there. The more we mentioned these arcane technical concepts, the less the rest of the team wanted to come along to standups because they felt it was irrelevant or above them in some way.

"But it's a standup!" I hear you cry. "You're only meant to give a quick high-level update anyway!"

You'd be surprised how easy it is to start talking in jargon without even realising for even the smallest of updates. Next time you give a standup update, ask yourself: if I weren't technical, would I know what I was talking about?

source: xkcd

How much technical detail do you really need to go into? If your standup tends to be "here's what I did yesterday and here's what I'm doing today", do you need to say:

We're still trying to get the auth service to store the user's refresh token in the database and check it against the incoming requests.

or can you just say

We're still trying to get authentication working in the backend.

To you the first example might look pretty easy to understand, but that's probably because you're an engineer. You know what a refresh token is. You know what a request is in this context. Non-technical folk probably knows what a database is, and what authentication is, but that's about it, and they've switched off by the end of the sentence. By keeping the technical detail to a minimum you'll be providing an update that the rest of the team understand, so they know what everyone's working on.

What about if there's a particular technical thing that's blocking you that you wanted to mention in standup? Either mention that you're generally blocked in the update and approach one of your fellow engineers afterwards, or maybe have a 5-minute dev-only standup after the main team standup where you can go into more technical detail.

Here's another example:

Some of our ElasticSearch nodes went down last night, it turns out we are still using the old cluster so we're going to migrate to the new cluster today.

vs.

Our search system went down last night, it turns out we're using an old server* so we're going to move it to the newer one today.

* I know this isn't technically the same thing, but to someone who doesn't know what a cluster is, it literally doesn't matter. You can go into more detail in the relevant dev standup/slack channel/coffee break.

Use real-world analogies

Keeping your language simple works for technical people too. If you're mentoring another engineer or helping someone work through a problem, being able to explain technical concepts in an easy-to-understand way and relating them to tangible concepts in the real world can really help others to learn from you. You'll find it a useful skill for giving talks - there's a real difference between "show me how" and "make me understand". For example, in a talk about redux-saga I used pictures of dogs to illustrate the library of effects it provides. In pretty much every object-oriented programming language tutorial there is some kind of Person or Car class to help you understand the concept of an object, and the tutorials about composition and inheritance usually talk about different species of animals.

With the auth token example, I told my team a story about a secret members' club involving an ever-changing secret handshake and a badge that let you learn the new secret handshake, which went down well and helped the others to get what we were trying to do, even though my product manager thought I was talking about a sex club.

Yeah, so we really need to reticulate the splines in our codebase

It's not just standups where this skill comes in handy: in your day-to-day role, explaining technical things clearly and simply might be the thing that convinces them why you should take a break from delivering new features to go back and tackle the mountain of tech debt that's been piling up:

We need to upgrade a lot of the packages, check for security vulnerabilities and replace a lot of deprecated code.

What does "deprecated" mean? What are packages in this context?

We've got some old code that needs updating because soon it won't work any more, and it might pose a security risk.

It sounds so basic, but to a non-engineer, that's all they need to know. They might ask some questions about what kind of risk it poses, or what "won't work any more" means, but it's a lot easier to follow.

Challenge yourself to keep it simple

It's not always easy to translate the hard stuff in easy terms, especially when you're working on things that involve kubernetes (true story). I still haven't found a good layman's explanation for what Docker does. But next time you're in a standup, listen carefully to what your fellow engineers say and then catch up with your other team members afterwards to ask if they followed everything. If they say yes, then you're fine, and you can just carry on as you were. But if they say no, consider getting your team to challenge themselves to deliver very simple standup for a a week. Make up ridiculous stories to illustrate migrating ElasticSearch clusters. At the end, ask those same people whether they feel like they know more about what you've been up to.

And if all else fails, there's my old favourite fallback:

Everything's slightly broken, but I'm working on making it not broken.

Things experienced speakers wish they'd known:

2018-01-24T00:00:00Z

Congratulations, you've been accepted to speak at a conference!

But once the initial euphoria wears off, you might find the impostor syndrome starting to set in. What if I'm not good enough? Do I know enough about this topic? What if the audience hates me?

That's me right now. I'm currently preparing my first ever conference talk for ReactFest 2018, which I was encouraged to apply to by the excellent folk at ReactJS Girls London. Having gained quite a few new followers on Twitter after my talk was announced, I thought I'd canvas a bit for helpful hints for a first time speaker. I figured a few people might respond.

Sophie Koonin @type__error
People who have spoken at tech conferences: what's one thing you wish you'd known before your first talk?

(RT for reach please?)
751 10:35 PM · Jan 22, 2018

I got so many fantastic tips and suggestions—including some from experienced speakers like Sarah Drasner, Dan Abramov and Anjuan Simmons — that one user suggested I turn it into a blog post. So here it is. (Thanks to @sayzlim for the suggestion!)

These tips have come from the tech community, but I think the majority of them can apply to any public speaking event.

Preparing your talk: Slides and content

You've got the outline of your talk that you submitted to the Call for Papers, but how do you turn it into a full talk? Whether your talk is full-length or a shorter lightning talk, it can be quite stressful when you're deciding what should go in and what you should leave out.

Find someone with speaking experience to help you put together your talk. The organisers of ReactFest put me in touch with a lovely volunteer who offered to give me some pointers. Find a friend, mentor or colleague with experience of giving conference talks, and ask if they will help you out.

One thing that came up repeatedly on Twitter was the concept of storytelling. Rather than just listing ideas or treating the talk like a tutorial, you want to tell a story. This makes the talk so much more engaging, and more likely to be remembered.

🧁 Mark Dalgleish @markdalgleish
@type__error @threepointone Share a story, not a series of facts. Took me far too long to figure that one out.
20 07:28 AM · Jan 23, 2018

дэн @dan_abramov
@type__error It helps if you have one idea to center your talk around. Like in Inception movie, what’s the one thing you want to put in their heads? This helps you decide what to cut (and you might have to cut things when you realize you’re running over the day before the talk).
55 01:01 AM · Jan 23, 2018

When it comes to putting a deck together, most people tend to use Google Slides, Keynote or PowerPoint, but tech folks might also like to try out Reveal.JS, which lets you write fully responsive slides in HTML or Markdown (perfect for code snippets!). I used it for a talk I gave at a meetup, and had the entire talk hosted on GitHub Pages just in case I had to use someone else's computer (which, in the end, I did!).

Once you've got the content nailed, you can focus on the design. Don't worry about being too fancy — you want your audience to focus on what you are saying rather than what's on the slides. Too many words on the slides will distract the audience, as will too many animated gifs! You can always create another version of your deck with more details on for sharing afterwards, as suggested by @henrihelvetica.

John Wards @johnwards
@type__error Take all those points off the slide and move to speaker notes, replace with cat* picture that represents that section.

People will focus on you rather than reading ahead and becoming bored.

*other options are available
27 01:56 PM · Jan 23, 2018

Keep your slide theme nice and simple, and consider whether the theme you have chosen will be easily readable from the back of the room with a crappy projector. Put your name and Twitter handle (if you have one) at the bottom of every slide because people will forget it if you only put it at the beginning (thanks @claireinez).

If you're putting code in your slides, don't go overboard. Sometimes it's inevitable — for example if you're talking about how a particular tool or library works —but as @alexmcpherson suggests, it's best to keep them short, 8–10 lines of code maximum. You can always share a repo or a CodePen link with your audience afterwards.

Practice makes perfect

Something that came up over and over again: rehearse your talk! Do it on your own, give it to your cat, make your colleagues listen to it and get their feedback. I got my fiancé to listen to my talk about redux-saga, and even though he didn't know the content, he gave me some really helpful feedback about how I was delivering the talk. Your manner of delivery is just as important as what you're saying.

Local developer meetups can be a fantastic place to try out your talk before the conference and gather some feedback/see how it lands — a bit like how comedians try out new material in smaller venues before festivals and tours.

Jani Eväkallio @jevakallio
@type__error Rehearse three times:
- First alone
- Second with supportive audience (partner, friends, colleagues)
- Finally, a smaller local meetup

By the conference you'll know your timings & punchlines by heart and have ironed out any kinks, so you can focus on having fun
153 10:47 PM · Jan 22, 2018

Rehearsing your talk will also help you to get a feel for how long it takes to run. Your talk will be strictly timeboxed, so make sure you get your key points across in the time that you have.

дэн @dan_abramov
@type__error If you haven’t practiced you will run over. My first talk at a local meetup was supposed to be 30 minutes, I only got through half of the slides. This is solved by practice: actually rehearse the whole talk (to an empty room, then to an audience).
56 12:56 AM · Jan 23, 2018

Don't be tempted to script out your entire talk, as it'll come across as a bit robotic (plus put a whole lot more pressure on you to learn it). Instead, become familiar with the key points of your talk and deliver those in a more improvised, natural way.

Technology isn't always your friend

Make sure your talk works offline — you never know what's going to happen. I've been to a tech conference before with no wifi or sockets for power. As @naomi_freeman suggests: "Don't trust the wifi. Download any online content BEFORE travelling."

Scott Hanselman 🇺🇦 @shanselman
@type__error test your talk in Airplane mode
13 01:56 AM · Jan 24, 2018

Dan Abramov suggests having a backup of the slides online that will run on someone else's laptop. Google Slides can be run from anywhere if you share the link, or you can host your Reveal.JS talk somewhere like GitHub Pages. Make sure you are comfortable giving your talk without prompts, as you might not be able to access your speaker notes.

If you can, find out beforehand what the setup will be like at the conference. The projector they are using, the size of the room and the equipment available will all affect things like font size, colour scheme and audio.

Paul Bone @Paul_Bone
@type__error @MsAmandaDean Whether the projector is DVI/VGA/HDMI etc. Whether it's 4:3 or 16:9. Whether the room is light or dark (should I use light slides or dark ones).
2 05:46 AM · Jan 23, 2018

Cynthia Savard @CynthiaSavard
@type__error @CallbackWomen Bring all of the dongles, bring your own clicker (usb) , plan for no presenter notes, always email yourself a pdf backup version
4 09:10 PM · Jan 23, 2018

Don't assume the organisers will provide the adaptor you need to connect your laptop! Bring it yourself just to be safe (and label it with your name so nobody steals it).

To demo or not to demo?

This was a bit of a divisive one — should you have a live demo in your talk?

Khang Hoang @khanght
@type__error @dan_abramov Demos won’t work
2 01:17 AM · Jan 23, 2018

дэн @dan_abramov
@khanght @type__error Mine worked tho
3 01:23 AM · Jan 23, 2018

A demo can be a fantastic way of, well, demonstrating a technical concept. But there's always a risk that something will go wrong on the night — whether it's down to nerves, technical issues or just plain bad luck. You can avoid this by making a recording of it beforehand that you can play to the audience and narrate what you're doing. Or have a working copy that you can check out from Git in case of emergency (thanks to Laura Wilson for that tip).

Sarah Drasner @sarah_edo
@type__error @threepointone make 'em work offline and have a backup screen recording of it in action
168 11:05 PM · Jan 22, 2018

Mac users can use Kap to record screen captures in video or GIF format. There's also Kazam for Linux and CamStudio for Windows.

In some cases screen captures might even be better than live demos:

Kyle Shevlin @kyleshevlin
@sarah_edo @type__error @threepointone Yes, I don't recommend any live coding in your first one. No reason to add one more thing to be nervous about. And I've seen Sarah's recordings, they work great for talks! She can describe what's going on without having to type at the same time.
41 11:07 PM · Jan 22, 2018

And as @fforres points out, don't rely on your audience to be sensible — if your demo involves live input from the audience, be warned, people might send in something rude!

On the day

The dress code at tech conferences can be pretty casual, but if you're wearing a dress, make sure it has pockets as you'll need to attach a mic battery pack! @knitcodemonkey says: "Wear something with a collar and a waistband for the mic. Wear comfy shoes."

Bring a water bottle and don't forget to drink from it to keep your voice happy.

Take off your lanyard or any heavy jewellery before you go on, because microphones will pick up the sound of it rattling around.

Make sure your laptop is ready for the talk: close all other programs, have the slides up and ready, and turn all notifications off. Put your laptop on airplane mode if you can. If you have a smart watch or phone on you, don't forget to silence that as well.

Henri Helvetica 🚀 👨🏾‍🚀 🇭🇹 @HenriHelvetica
@keithjgrant @type__error The lanyard bit is 100%! Add jewelry to that.
Btw, ✈️ mode AND shut off wifi.
Someone who loved my talk was kindly tweeting non stop about it and I kept getting notifications on my watch - I actually thought it was an emergency 🚨.
8 10:24 AM · Jan 23, 2018

дэн @dan_abramov
@type__error @acdlite And turn the notifications off! Otherwise you risk exposing private messages hopping on the screen during the talk 😛
20 01:16 AM · Jan 23, 2018

As you're about to go on, you might feel the nerves. The audience is waiting! Take a deep breath and try to radiate confidence, even if it doesn't come naturally to you. The audience won't know you're faking confidence (and soon you won't be). You know your stuff, you love your topic, you've rehearsed it time and time again — you are ready. Enjoy it.

дэн @dan_abramov
@type__error Peak scary is ten seconds before the talk. I didn’t anticipate it to be this scary. But once you get into your element (by talking about things you care about) the fear goes away completely, it even becomes fun. At least it did for me.
69 12:58 AM · Jan 23, 2018

Jani Eväkallio @jevakallio
@type__error Projecting confidence is as good as having it. Even if you are not 100% happy with your talk, nobody knows what it was supposed to look like, so just rock your stuff and don't apologise for a thing
31 10:40 PM · Jan 22, 2018

Be aware you might not be able to see anyone in the audience…

Sara Vieira @NikkitaFTW
@type__error @ReactFest One thing I didn't know and really surprised me is that you probably will not be able to see anything, the lights pointing at the stage will most likely almost blind you 🙁
And you are going to rock!
4 08:30 AM · Jan 23, 2018

Move around a bit, rather than standing still behind the podium. It can be tempting to just keep talking — don't forget to pause now and again.

Sarah Drasner @sarah_edo
@type__error Breathe.

(seriously)
26 11:06 PM · Jan 22, 2018

David East @_davideast
@type__error Plan out when you're going to pause during your talk. "Letting it land" is really important for the audience. It also keeps you from rambling at light speed (a habit I still have to unlearn for each and every talk)
39 01:26 AM · Jan 23, 2018

дэн @dan_abramov
@type__error @acdlite Whenever you get nervous just take a pause. Breathe. Drink some water. It’s empowering to realize you can even make an awkward pause and everyone will just sit silently because you control the room 😎
75 01:10 AM · Jan 23, 2018

Be mindful how you address the audience — don't just fall back on "guys" considering your audience is likely to be a mix of genders (thanks @fforres). Jokes are a fantastic way of lightening the mood and keeping the audience engaged, but avoid any risqué/potentially inappropriate jokes.

Berkubernetus @fuzzychef
@type__error @Heronymus Risque' jokes are a *really* bad idea in a public presentation.
3 05:37 AM · Jan 23, 2018

Don't be put off if you make a mistake! If you leave something out or stumble over something, nobody will know. Keep going!

Amanda Stockwell @MandaLaceyS
@type__error @justjessdc You'll notice your own "mistakes" 100 times more than anyone else. But no one else knows what you were planning to say. So if you take a breath and keep going, probably no one else will know there was even a blip. Also, bring extra clothes. I spilled coffee😂
29 02:03 AM · Jan 23, 2018

Santosh Hari 😷 @_s_hari
@type__error Prep! Whatever the content, prep till you can wake up in the middle of the night and do the talk from memory
2 12:13 PM · Jan 23, 2018

And don't forget the most important thing:

Justin Fagnani @justinfagnani
@type__error @threepointone Everyone's rooting for you
18 10:41 PM · Jan 22, 2018

Damian Brady 🥑 💉 💉 💉 #AlwaysWasAlwaysWillBe @damovisa
@type__error The audience is on your side. They want you to succeed.
14 09:37 AM · Jan 23, 2018

Jon Skeet @jonskeet
@type__error If you enjoy yourself (and your topic) then other people will enjoy the talk. Enthusiasm is viral. People remember good talks. People forget bad talks. People really remember and hate on *nasty* (sexist, racist etc) talks; never be worse than yourself just to be memorable.
33 11:55 PM · Jan 22, 2018

You're at the conference because you love your topic, and so does everyone else there. You're all on the same team. As @tlakomy assures me: "It's going to be okay".

Taking questions?

Sarah Drasner recommends not taking questions during your first talk:

Sarah Drasner @sarah_edo
@type__error oh! a better one: don't take questions your first time. I don't recommend it because you get done with the tada! and then it just kind of tapers off from there. plus the best questions aren't performative, they're the ones that happen off the stage face to face
65 11:13 PM · Jan 22, 2018

That said, it's a personal choice — if you feel comfortable (and time allows it) you can take as many questions as you want. An excellent tip from @bradwaynemartin: always repeat the questions back to the audience, as the microphone won't pick them up.

But if anyone does challenge any decisions you made, you can fire this straight back:

Fernanda Foertter | 🇧🇷🇺🇸🥑👩🏽‍💻🤓 @hpcprogrammer
@type__error Best answer I ever gave to a “why would you do it this way” was “why not? Seemed like a good place to start. Next question?” I don’t know why it took me so long to learn it
21 01:29 PM · Jan 23, 2018

Good luck!

To all first-time or aspiring speakers: you've got this!.

If you're looking to get into the world of conference speaking, a great place to start is local developer meetups (if you can't find one, start one!). You might even start by giving talks at work to your colleagues. The more you do it, and the more feedback you gather, the more comfortable you'll become.

I also recommend taking a look at Jo Francetti's guide to Public Speaking For Beginners and Emily Webber's list of things that speakers need from conference organisers.

Thank you to everyone who contributed to the enormous Twitter thread that led to the creation of this post. If I have forgotten to credit anyone, or you would prefer not to be included, please get in touch.

localghost

Good links: 18 February 2024

Good links: 4 February 2024

Listen to this: The Stand-In by Caitlin Rose

Good links: 28 January 2024

So you've decided to get into mechanical keyboards

How mechanical keyboards work

Switches

Mechanical vs optical switches

Cherry MX switches and their colours

Keyboards

Keyboard size and shape

Keyboard layouts: ISO, ANSI, JIS, ortholinear

Typing angle

Dampening sound

Keycaps

Kits

Materials

Key sizes

How to actually buy keyboards and keycaps

The group buy process

What to buy if you want it now

Where to buy

Further reading & links

Automated weekly links posts with raindrop.io and Eleventy

Collecting the links

Creating the post

Scheduling the script

Good links: 21 January 2024

How I deploy my Eleventy site to Neocities

About Neocities

Hosting a static site on Neocities

Continuous deployment to Neocities with Github Actions

Scheduling builds

Sending webmentions from a static site

Just because you can doesn't mean you should: the element

Remembering the early 00s teen website scene

TLD is everything

This is my space, but here's something for you

Version 17

Website tsatskes

The end of an era

A good podcast: Twenty Thousand Hertz

2023: The year in lists

The year in...

...conferences

...travel

...books

...podcasts

...music

...video games

...learning things

...purchases

...apps and programs

...blog posts

...the web

And so we're at the end

Engineering progression for humans

Know what motivates you

Not everybody needs to (or wants to) progress

The way up (or sideways. Or backwards.)

Engineer I and II

Mid-level engineer / Engineer III

Senior engineer

Senior engineers come in all shapes and sizes!

Senior to ???

Senior to staff

Senior to engineering management

Other potential sideways steps

Cross-company career paths illustrated using tenuous playground metaphors

The ladder

The climbing frame

Monkey bars

Merry-go-round

The rocker

There's no one right way

Beautiful musical chaos

A good recipe: The best chocolate brownies

Ingredients

Method

The `prefers-reduced-motion` media query

Harnessing media queries with the `picture` element

Gradient-fill text with `background-clip`

Now: Canvas and `requestAnimationFrame`