localghost.dev

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

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-22T16:55:34Z

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-24T15: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.dev

Preparing for conferences

Initial planning: about 8-10 weeks before the conference

Content: about 6-8 weeks before

Slides: about 4-6 weeks before

Run-throughs: from 3-4 weeks before

The week of the conference

Delivering the talk

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

The web used to be weirder

Let's bring back the weird

Animated GIFs

The prefers-reduced-motion media query

Harnessing media queries with the picture element

Text effects

WordArt, but make it CSS

Gradient-fill text with background-clip

Adding the drop shadow

Getting some perspective

Music

Cursor trails

Then: Dynamic HTML

Now: Canvas and requestAnimationFrame

Media queries work in JavaScript, too!

Webrings

Guestbooks

Go forth and build weird stuff!

Everything I googled in a week as a senior software engineer

Monday

Tuesday

Wednesday

Thursday

Friday

Looking back

When going back doesn't mean going backwards

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

Don't be like me, please take a break

Heed my words, adventurer!

Start at the beginning: the importance of learning the basics

Where I started

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

Recommended resources

Learning HTML

Learning CSS

Learning JavaScript

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

Semantic HTML conveys meaning

Example: a non-semantic news site

Landmarks

Menus

Checkboxes

Buttons

Headings

Bold and italic text

Image caption

You can still use divs!

The same news site, with semantic tags

Semantics from the start = accessibility from the start

Find out more about semantic HTML

A typical day: pandemic edition

My typical day

Give yourself a break: lessons from burnout

Lesson number 1: give yourself a break

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

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

Lesson number 4: mental health is more important than KPIs

7 myths designers and developers believe about web accessibility

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

Myth 2: Accessibility is optional

Myth 3: Access needs come from permanent disabilities

Myth 4: Accessibility is a barrier to good design

Myth 5: Accessibility is hard to implement

Myth 6: React apps are inherently inaccessible

Myth 7: Automated testing will catch all accessibility problems

It's your turn

Resources & further reading

Defending yourself against cross-site scripting attacks with Content-Security-Policy

Contents

Cross-site scripting (XSS)

Stored XSS

The `prefers-reduced-motion` media query

Harnessing media queries with the `picture` element

Gradient-fill text with `background-clip`

Now: Canvas and `requestAnimationFrame`

You can still use `div`s!

`unsafe-inline` and the risks of inline styles

Scripts, `unsafe-inline` and `unsafe-eval`: why `eval()` is evil

styled-components and `unsafe-inline`