Down the rabbithole – a frontend blog

Why

2017-09-29T08:53:00+00:00

A few reasons why:

I forget stuff.
I prefer sharing stuff here than on social media.
If this helps anyone, I helped someone. <3

Flexbox with fixed sidebar

2018-05-02T00:00:00+00:00

I love flexbox. It’s… flexible. Today, developers have to think about almost as many resolutions as devices. Things have to shrink (and grow!), fit, and not cover anything else. In some cases, they have to reorder themselves (more on that in a future blog post). Flexbox can do all this. One caveat though — it does not work well with absolute or fixed positioning.

So how do we keep a sidebar in place?

HTML structure •

Our very simple website will contain a sidebar and a <main> part. These will be wrapped in a common parent, which has display: flex property. Something like this (fill main with lots of paragraphs — try Space Ipsum or Fillerama).

HTML

<div class="wrapper">
  <nav class="sidebar">Links...</nav>
  <main>Fill with lots of text</main>
</div>

CSS

.wrapper {
  display: flex;
}

Blocks have an overflow property. They also have width and height, and with these properties, we can easily tame that sidebar.

First, our sidebar should not be taller than the screen. But how tall is the screen? It’s exactly 100vh. Now that we are at it, let’s fix box-sizing for every element too, in case there are any paddings or borders^[1].

* {
  box-sizing: border-box;
}

.sidebar {
  height: 100vh;
}

Scrolling the content •

At this point, our sidebar will be as tall as the screen — but our page height is defined by the length of its content. In other words, .wrapper will be as tall as main, and if we have lots of paragraphs, we will scroll past the sidebar quickly. Overflow to the rescue! Let’s make this main no taller than the screen, and scroll if it has more content:

main {
  height: 100vh;
  overflow: scroll;
}

That’s it! Here’s a working example.

see box-sizing on MDN web docs ↩︎

SVG animations with CSS

2018-05-10T00:00:00+00:00

SVGs are lovely: they are small, scalable, and easily editable by a developer. They can also be animated using CSS, which means that while keeping their tiny size, they can do much better than a GIF. Need those champagne bubbles to bubble a little faster? No problem. Whatever the designer suggests can be done with a few lines of CSS, without ^{significantly} modifying the original asset.

The main ingredients: @keyframes and CSS animation •

@keyframes are a way to define animation functions. They need a name, a few timing points (at least a from and a to, or percentages), and instructions on where to be at each of these time points.

CSS property animation takes name, duration, timing function (default: ease), delay, iteration count (default: 1; number or infinite) etc.

Take this beating heart as an example (it’s 11.15KB):

Heart icon by Kirill Kazachek from flaticon.com is licensed by CC 3.0 BY

Here’s the code itself — you can check the source, I’m not cheating ;)

HTML

<img src="heart.svg" class="heart" />

CSS

.heart {
  width: 120px;
  animation: pulse .6s ease-in infinite alternate;
}

@keyframes pulse {
  from {
    transform: scale(.94);
  }

  to {
    transform: scale(1);
  }
}

That’s boring. Is that all SVG can do? •

Of course not.

SVGs are written in XML, and can contain paths, texts, shapes (lines, circles etc.) — and <g> for groups of these. We just have to name these building blocks (with CSS classes and IDs) to animate them separately.

Consider this image:

Cloud icon by Freepik from flaticon.com is licensed by CC 3.0 BY

Its source code has the following structure:

<svg>
  <!-- cloud in the back -->
  <path style="..." d="...">

  <!-- cloud in the front -->
  <path style="..." d="...">
  <path style="..." d="...">

  <g>
    <!-- cloud fluffs -->
    <path style="..." d="...">
    <path style="..." d="...">
    <path style="..." d="...">

    <!-- rain drops -->
    <path style="..." d="...">
    <path style="..." d="...">
    <path style="..." d="...">
    <!-- ...and many more of them -->
  </g>
</svg>

I would like the little rain drops to fall, and the two clouds to float.
For this, we will have to slightly modify the original SVG. Namely:

The front cloud is made up of several shapes, let’s put them in a group so that they can move together
The back cloud has to float, let’s give it an ID as well
Rain drops will have to do the same thing, but timed randomly, so each of them will need an ID.
I will also make the back cloud a bit darker, because why not.

An illustration of these changes:

<svg>
  <!-- cloud in the back: id added -->
  <path id="cloud-back" style="fill:#8BbbD8;" d="...">

  <!-- cloud in the front: grouped -->
  <g id="cloud-front">
    <path style="..." d="...">
    <path style="..." d="...">

    <!-- cloud fluffs added to front cloud's group -->
    <path style="..." d="...">
    <path style="..." d="...">
    <path style="..." d="...">
  </g>

  <!-- rain drops are all individuals, but if we are lazy, we can "class"
  a few together. some will move at the same time, but it's fine -->
  <path class="drop1" style="..." d="...">
  <path class="drop2" style="..." d="...">
  <path class="drop3" style="..." d="...">
  <path class="drop2" style="..." d="...">
  <!-- and so forth, quasi-randomly assigning classes -->
</svg>

Now we just have to add some css animations, and we’re done.

#cloud-front {
  animation: float 3s ease-in-out infinite alternate;
}

#cloud-back {
  transform: translateX(12px);
  animation: float2 2.2s .2s ease-in-out infinite alternate;
}

.drop1 {
  animation: rainfall .5s linear infinite;
}

.drop2 {
  animation: rainfall .6s .1s linear infinite;
}

.drop3 {
  animation: rainfall .7s .3s linear infinite;
}

.drop4 {
  animation: rainfall .6s .4s linear infinite;
}

@keyframes float {
  from { transform: translateX(0);   }
  to   { transform: translateX(22px);}
}

@keyframes float2 {
  from { transform: translateX(14px);}
  to   { transform: translateX(0);   }
}

@keyframes rainfall {
  from {
    transform: translate(0, 0);
    opacity: 1;
  }

  to {
    transform: translate(-15px, 30px);
    opacity: .1;
  }
}

Cloud icon by Freepik from flaticon.com is licensed by CC 3.0 BY

That’s it — stay dry!

Typing animation with JavaScript

2018-06-16T00:00:00+00:00

Let’s imagine I’d like to show a one-line introduction on my website, but can’t decide what to say about myself. So I’d like to rotate between the phrases I’m a web developer, I like coffee, and I write about stuff I’m no expert in. I could grab the code from the internet, but I’d like to challenge myself today and come up with a solution on my own — which is also a good way to prove it’s not hard at all!

Let us begin.

Part one: rotating phrases

First, we need a default phrase, so that it works for people who have JavaScript off.

HTML

<p id="type">I'm a web developer</p>

Now, we will need JS to replace this nice phrase with the others. I will start by simply alternating the phrases with a setInterval function.

JS

const typeElement = document.getElementById('type');

const phrases = [
	"I'm a web developer",
	"I like coffee",
	"I write about stuff I'm no expert in",
	"But then everyone else does so I guess that's ok",
];

let currentIdx = 0;

window.setInterval(() => {
  currentIdx++;
  if (currentIdx > 3) {currentIdx = 0;}
  typeElement.innerText = phrases[currentIdx];
}, 2400);

Part two: typing

Let’s start off with a full sentence, in case someone has JS turned off, delete from there, and start typing again when we have nothing left.

HTML

<p id="sentence" class="example">Type this.</p>

Next, we will need to handle two directions: deleting or typing text. Once we know which way we are going, and where our cursor is (which we decide based on its previous position and the direction), we know how much text to show.

JS

const sentenceElement = document.getElementById('sentence');
const sentence = 'Type this.';
let cursorPos = sentence.length;
let direction = -1;
const switchDirection = () => direction *= -1;

window.setInterval(() => {
  const atStart = cursorPos === 0;
  const atEnd = cursorPos === sentence.length;
  if (atStart && direction === -1 || atEnd && direction === 1) {switchDirection();}
  cursorPos += direction;
  /* Display only part of the text */
  sentenceElement.innerText = sentence.slice(0, cursorPos);
}, 180);

Part three: a blinking cursor

A blinking cursor is not hard to get in pure css, we just need a good animation-timing-function. (By the way, here’s a recap on animations — it’s for SVGs, but can be applied to any element).

HTML

<span class="blink">|</span>

CSS

.blink {
  animation: blink 1.1s linear infinite alternate;
}

@keyframes blink {
  from {opacity: 1;}
  20% {opacity: 1;}
  28% {opacity: 0;}
  72% {opacity: 0;}
  80% {opacity: 1;}
  to {opacity: 1;}
}

Putting it all together

The desired outcome is to show the first phrase, delete it, type the second one, delete, type etc. and start again after we have typed them all. For this, the only additional info we need is to know when to switch sentences, and this is when we are in delete mode (= direction is -1), at cursorPos 0. We can even skip a few rounds here, blink the cursor a few times, and continue with the next phrase.

Note for the cursor's blinking: the number of intervals we spend without typing, and with a blinking cursor, will not be the number of blinks, rather the number of 180ms intervals passing. There's a bit of math to get it right, the cursor blink animation timing should be divisible by the interval, without remainder. In my example, the cursor is set to blink every `1080ms`, the interval is `90ms`, and I wait `12` interval cycles, which is `12 * 90 = 1080ms`, enough for exactly one blink.

Here’s the code:

const phrases = [
  'I’m a web developer',
  'I like coffee',
  'I write about stuff I’m no expert in',
  'But then everyone else does so I guess that’s ok',
];

const element = document.getElementById('typing-example');
const cursor = document.getElementById('cursor');
let direction = -1;
let phraseIdx = 0;
let sentence = phrases[phraseIdx];
let cursorPos = sentence.length;
let blinking = false;
let blinkIntervals = 0;

const switchDirection = () => {
  direction *= -1;
  toggleTyping();
  if (direction === 1) {
    /* Just started typing again, time to switch phrase */
    phraseIdx++;
    if (phraseIdx >= phrases.length) {phraseIdx = 0;}
    sentence = phrases[phraseIdx];
  }
};

const toggleTyping = () => {
  blinking = !blinking;
  if (blinking) {cursor.classList.add('blink')} else {cursor.classList.remove('blink');}
}

window.setInterval(() => {
  const atStart = cursorPos === 0;
  const atEnd = cursorPos === sentence.length;
  if (atStart && direction === -1 || atEnd && direction === 1) {switchDirection();}

  if (!blinking) {
    cursorPos += direction;
    element.innerText = sentence.slice(0, cursorPos);
  } else {
    blinkIntervals++;
    if (blinkIntervals >= 12) {
      blinkIntervals = 0;
      toggleTyping();
    }
  }
}, 90);

Ways to improve loading speed

2018-06-17T00:00:00+00:00

People hate to wait. More than that, they don’t wait, if your website doesn’t show anything nice or useful in a few seconds, they just close it. There’s plenty other websites out there that load a little bit faster. So before all the images are sharp, animations smooth, fonts reflecting the most recent trends, there’s one important thing to do: make sure it is real fast. Every millisecond counts.

Why is my website slow? •

Before we can speed up anything, we have to understand how websites are loaded in the browser.

document is requested (this is usually your index.html file)
any resources requested by given document are loaded in order of appearance, unless otherwise specified.

To better understand this process, open the dev toolbar’s network tab in Chrome (or your preferred browser), navigate to any website (github.com is a good example), and examine what happens there. The key part is the waterfall (those colourful bars on the right side). When you hover them, you can see every detail of each resource, and a link to Google’s explanation of what this all means.

A simplified explanation of what happens here: the first resource is queued at 0, which is when the first GET request is sent. It doesn’t spend much time in the queue or stalled, as this is the first request. It has to find the IP address to the resource (via a proxy if there is one). Once it gets to the server, the server prepares the response — this is the waiting stage. And finally, the response content is downloaded.

At this point, the browser doesn’t know what’s inside that document, so it can’t make any other requests until its content is downloaded.

Once the client has access to that content, it can start requesting all the resources in there (scripts, images, fonts, stylesheets etc.) The browser does this in order of appearance.

Let’s have a look at the bigger picture:

The bars corresponding to these resources have mostly four visible parts: white means they are queueing, grey means they are stalled, green means the response is being prepared by the server, and blue corresponds to the time it takes for the resource to be fully downloaded from the server.

The first notable thing is that the lower we go, the more time resources spend in the queue. This is because even though they were requested roughly the same time, HTTP/1.x limits the number of parallel requests. That’s 6 requests in most modern browsers, but usually less in mobile browsers (4 in iOS Safari, for instance).

This should no longer be an issue with the release of HTTP/2, but whether that’s supported depends on both the client and the server. Most browsers support HTTP/2 ^[1], but less than one third of the websites use it ^[2], so queueing is something we should worry about, for now.

How to solve queueing? •

Well, we don’t really have to solve it, just handle it strategically.

Decrease the number of assets requested

This will reduce the number of assets that each request has to wait for, thus the request can start earlier.

bundle js files and stylesheets
import dependencies through js before bundling, rather than loading scripts from the html
use sprites for smaller assets (icons etc.), especially if there’s many of them
consider loading small SVGs inline, instead of using them as the source of an img.

Decrease asset sizes

minify js and css
use minified versions of vendor scripts, if you have to include them in the html rather than importing and bundling together with your javascript. These are the ones ending in .min.js.
gzip HTML
make sure images are a suitable format (simple shapes could be inline SVGs, but more complex stuff is more efficient in PNG, JPG or similar
ask the designer for optimised images :)

Use a CDN (content delivery network)

This means static content can be served from not one, but many, geographically distributed locations. The distance the request and response have to travel is smaller, therefore content is loaded faster.

Time requests strategically

In React, I’m using a custom Image component that has a delay property, which, using a simple setTimeout, only loads after that delay has passed. Here’s the simplified version:

export default class Image extends React.Component {
  constructor(props) {
    super(props);
    this.state = {loaded: !props.delay};
  }

  componentDidMount() {
    this.timerID = setTimeout(() => {
      this.setState({loaded: true});
    }, this.props.delay);
  }

  render() {
    return <img src={this.state.loaded ? this.props.src : null} />;
  }
}

Which is used as follows:

<Image src="/assets/fluffy_the_cat.png" delay={200} />

It works because in the html, this is rendered as an img with src set to null in the beginning (well, after the bundled script is loaded, of course), and only once those 200ms have passed, does it request the resource.

A vanilla js solution could look something like this:

<img id="fluffy_the_cat" />

Where the source is loaded once the timeout is complete.

window.setTimeout({
  const catImage = document.getElementById('fluffy_the_cat');
  catImage.src = '/assets/fluffy_the_cat.png';
}, 200);

You might say lazy loading images belongs here too, but that’s more of a visual thing, so I will leave that for next time.

If you only do one thing to improve site performance, decrease the number of requests, that’s a real bottleneck. Asset size in 2018 is not the biggest issue.

Lazy loading images

2018-08-14T00:00:00+00:00

In my post about loading speed, I promised to write about how I lazy load images. It is a useful technique for when you have large photos above the fold, that would take noticeable time to load. The solution is quite simple: we can make use of CSS’s blur filter, with the help of opacity. The basic sequence is:

load page with a tiny, blurred version of the image, and on top of it, a transparent, empty placeholder for the full size image
create an Image element with the full size src using JavaScript
when the full size asset is loaded, set it as the src of the full size placeholder
set the opacity of the full size image to 1.

This will look as if the same image becomes sharper, like this:

Using a preload image means that in this specific case, my initial image size is just 7kB instead of around 500kB. The downside is that you have to know the exact width and height of the image you want to load.

Let’s get to the code! •

I will use React for this example. It’s very much simplified, I’m not passing classes, alt, support for any image extension etc., but you should do that in production.

Our element will accept a src and a preloadSrc for now. Please note that it should have a fixed width and height to work.

<LazyImage src="goat.jpg" preloadSrc="goat_tiny.jpg" />

This is the component itself:

export class LazyImage extends React.Component {
  constructor(props) {
    super(props);
    this.state = {loaded: false};
    this.fullSizeImage = null;
  }

  componentDidMount() {
    const loaderImage = new Image();
    loaderImage.src = this.props.src;
    loaderImage.onload = () => {
      this.fullSizeImage.src = src;
      this.fullSizeImage.classList.add('loaded');
      this.setState({loaded: true});
    }
  }

  render() {
    return (
      <div className="lazy-image" style={this.props.style}>
        <img className="image-full" ref={id => this.fullSizeImage = id} />
        <img className="image-preload" src={this.props.preloadSrc} />
      </div>
    );
  }
}

Finally, the CSS needed to make it work:

.lazy-image {
  position: relative;
  overflow: hidden;

  .image-full,
  .image-preload {
    position: absolute;
    top: 0;
    left: 0;
  }

  .image-preload {
    filter: blur(4px);
  }

  .image-full {
    z-index: 2;
    opacity: 0;
    transiton: opacity .6s ease;

    &.loaded {
      opacity: 1;
    }
  }
}

That’s it, you’re as good at image loading as Medium now.

Building a reading progress bar

2018-09-21T00:00:00+00:00

For this post, I will start from zero and experiment my way through the problem, to show it’s not that hard to build impressive animations. A reading progress bar this time.

My initial hunch is that it has to do with scroll position and the blog post’s height. Quite useful in this case if blog posts sit in their own nice semantic <article> elements, so we don’t have to rely on the height of the full body and account for the height of whatever is below the blog post itself. Our progress bar should show the exact reading position of the post itself, excluding related articles and tall footers!

Letʼs do some maths •

So we want to project our vertical scroll position onto a horizontal bar ranging from 0 to 100%. 100% means we have reached the end of the blog post, and its bottom edge is in view. Letʼs see what we know, and how can we use it. element will be our blog post element.

window.innerHeight: our window size
document.body.clientHeight: the body height
window.scrollY: how many pixels we have scrolled
element.offsetTop: where our blog post starts^[1]
element.clientHeight: the blog post element height

The actual scroll trajectory to measure starts from the bottom of the non-scrolled page (because that is the bottom-most thing we can see without scrolling), and ends at the bottom of the element. The distance between these two points, (element.clientHeight + element.offsetTop) - window.innerHeight, is equal to 100% of the scroll distance.

We only need to know how much of this distance we have covered (or, how much we have scrolled so far) to show the actual progress.

Turning it into code •

One thing I have noticed is that in order to measure progress accurately, we should wait for all the elements to be loaded, so we will do everything on load. Once this is done, we just need a fixed div that sits at the top edge of our window and has a bright background. It should start with 0% width, which we will update as we scroll.

<div id="progress-bar"></div>

#progress-bar {
  width: 0%;
  position: fixed;
  top: 0;
  left: 0;
  height: 6px;
  background: linear-gradient(to right, #ecd2fe, #feaaaa);
}

window.onload = () => {
  const post = document.getElementsByTagName('article')[0];
  const progressBar = document.getElementById('progress-bar');
  const distance = (post.clientHeight + post.offsetTop) - window.innerHeight;

  window.addEventListener('scroll', () => {
    const progress = window.scrollY / distance * 100;
    progressBar.style.width = `${progress}%`;
  });
}

Careful though, this is calculated relative to the closest relatively positioned parent element — see HTMLElement.offsetTop on MDN web docs ↩︎

Unit testing abstract classes in React

2018-11-06T00:00:00+00:00

In unit testing with Jest and Enzyme, a shallow render is a good way to test whether a component works like it should. But with abstract classes^[1] that don’t have a render() method (like one I’m trying to test right now), this fails. So how can we test abstracts?

A simple abstract class •

Our abstract may look something like this calculator. For the sake of simplicity, it can only do one operation (but that, it can do very well!)

abstract class AbstractCalculator extends React.Component {
  constructor(props) {
    super(props);
    this.state = {result: 0};
    this.addOne = this.addOne.bind(this);
  }

  addOne() {
    const result = this.state.result + num;
    this.setState({result});
  }
}

This class could be used as follows:

class Calculator extends AbstractCalculator {
  constructor(props) {
    super(props);
  }

  render() {
    return (
      <div>
        <strong>{this.state.result}</strong>
        <button onClick={this.props.addOne}> +1 </button>
      </div>
    );
  }
}

The fun part: testing! •

Normally, a test for a React class using Jest and Enzyme would look something like this:

describe('Calculator', () => {
  const props = {/* add some props here */};
  const calc = shallow(<Calculator {...props} />);

  it('works', () => {
    expect(calc).toBeTruthy();
  });
});

This will not work for abstracts.

If we try to use any of Enzyme’s renderers, e.g. shallow(<AbstractComponent {...props} />), we will get an error like this: TypeError: this._instance.render is not a function. Indeed, it is not. But we should still be able to test the rest of AbstractComponent’s methods.

We could test the class Calculator that implements AbstractCalculator, but that would not allow for isolated testing of our abstract.

So let’s approach this as testing a class, rather than a React component. Instead of shallow rendering, we just create a new instance and test its methods on this instance.^[2] As for the props, they are, in essence, the parameters of the constructor function for the class, so we will just pass them as params when creating the test instance.

import AbstractCalculator from 'path/to/AbstractCalculator';

describe('AbstractCalculator', () => {
  const props = {/* some test props */};
  const calculator = new AbstractCalculator(props);

  it('works', () => {
    expect(calculator).toBeTruthy();  
  });
});

Voilà! It works.

As for state changes, we will have to mock the abstract’s setState method, otherwise we get Warning: Can’t call setState on a component that is not yet mounted.

it('adds correctly', () => {
  calculator.setState = jest.fn();
  calculator.state.result = 7;

  calculator.addOne();

  expect(calculator.setState).toBeCalledWith({result: 8});  
});

Thatʼs all — to be honest, the solution was simpler and more straightforward than I had imagined. In essence, an abstract class is just a class that can be reused easily, so it behaves just like a class in TypeScript. In our oversimplified example, that is. :)

See the TypeScript Handbook for more explanation of abstract classes (youʼll have to scroll down a little.) ↩︎
Note that creating an instance with new from an abstract class should not be done anywhere else, as abstract classes are there for other classes to implement. ↩︎

Building an API proxy with Serverless — Part 1

2018-12-16T00:00:00+00:00

I’m back to building a weather app, this time not in Flask, but React. I wanted to skip the server part, but DarkSky is strict about CORS^[1], so I had to build a proxy. Not really a front-end topic, but good to know if you work daily with backend engineers (which I do).

Enter serverless •

Constantly running a server just to proxy a single API call would be an overkill — Serverless on AWS Lambda is just the perfect way to solve this^[2]. Of course, serverless is only as serverless as the cloud is not physical. It still runs on a server, but it’s someone else’s (in this case, AWS).

First, we’ll have to install serverless:

yarn global add serverless

Then create our service:

sls create --template aws-nodejs --path weather-service
cd weather-service

By the way, sls is a shorthand for serverless. Wherever you see serverless in the docs, you can use sls instead. The quick start guide suggests to deploy now, but we can skip this until we are ready, and test our proxy locally. Let’s see what we have so far:

sls invoke local -f hello

If we’ve done everything right (not much to break so far), the output should be:

{
  "statusCode": 200,
  "body": "{\"message\":\"Go Serverless v1.0! Your function executed successfully!\",\"input\":\"\"}"
}

Later, we can test the deployed function by calling sls invoke -f hello (without local), but that will count against our AWS Lambda usage.

Let’s turn this into a DarkSky API gateway •

First, I’d like to call my function something more meaningful, maybe getWeather. For this, let’s change the function name in serverless.yml:

functions:
  getWeather:
    handler: handler.getWeather

And in handler.js, module.exports.hello should become:

module.exports.getWeather = () => { … }

Now if we try sls local invoke -f hello, it will fail, because there is no hello function. However, sls local invoke -f getWeather will work like charm!

Ok, on to the weather! •

I will use the request library for handling requests, for no particular reason, other than it’s simple and works well with serverless. There’s no magic here, just calling Dark Sky API with my secret key and some hard-coded coordinates (for now). Getting the API key from process.env is also a temporary solution optimised for local invokes, this may change in part 2.

'use strict';
const request = require('request');

module.exports.getWeather = (event, context, callback) => {
  const headers = {'Access-Control-Allow-Origin': '*'};

  request.get(
    { url: `https://api.darksky.net/forecast/${process.env.DARKSKY_KEY}/44,32` },
    (err, res, body) => {
      if (err) {
        const response = { statusCode: 404, headers, body: err };
        callback(null, response);
      } else {
        const response = { statusCode: res.statusCode, headers, body };
        callback(null, response);
      }
    }
  );
};

Now, sls invoke will return the current weather for those coordinates. You can check out the full source on github.

In my next post, I will show how to deploy the function to AWS Lambda, how to handle requests, and how to create API endpoints. Until then, and happy holidays!

Dark Sky API: Frequently Asked Questions: “If you were to make API calls from client-facing code, anyone could extract and use your API key, which would result in a bill that you’d have to pay. We disable CORS to help keep your API secret key a secret.” Fair enough. ↩︎
Plus, AWS Free Tier includes 1 million monthly invokes. ↩︎

Building an API proxy with Serverless — Part 2

2019-01-10T00:00:00+00:00

In the second part, I will turn a simple Lamda function into an API endpoint. If you havenʼt, now is a good time to read Part 1 first :)

From function to API •

First, let’s prepare our serverless config so that it can handle HTTP requests, and will only allow those from my website.

functions:
  getWeather:
    ...
    events:
      - http:
          path: weather
          method: get
          cors:
            origins:
              - 'https://myweathersite.example.com'

A side note about AWS credentials •

I use AWS for work, so I already had some credentials configured — but I canʼt just deploy my lambda to the company AWS account, can I? So letʼs set up a new profile. This we can do by running
aws configure --profile notMyCompanyProfile, and entering security credentials as usual. Then, we can set a default profile for serverless to use, in serverless.yml:

provider:
  name: aws
  runtime: nodejs8.10
  stage: prod
  profile: notMyCompanyProfile

Deploying the lambda •

Now we can run sls deploy --aws-profile notMyCompanyProfile. Yay! If we run sls invoke -f getWeather (notice the absence of local), it will actually run on AWS this time. We can even curl the url sls deploy created for us. But when I do that now, I get 403 Forbidden: I have to configure my DarkSky API key on AWS. Thatʼs simply done on the AWS Consoleʼs Lambda section, under my functionʼs Environment variables.

If I do a curl now, it will get the weather for me.

Making the server a bit more flexible •

Now a weather forecast is more useful if it can tell the weather for any location in the world, not just one it is hard coded to. In practice, this will mean for now that the client can pass coordinates for which it wants to get a weather forecast. Something like this:

module.exports.getWeather = (event, context, callback) => {
  const { lat, lon, units } = event.queryStringParameters;
  const headers = { 'Access-Control-Allow-Origin': '*' };
  const baseUrl = 'https://api.darksky.net/forecast/';
  const queryParams = !!units ? `?units=${units}` : '';

  request.get(
    { url: `${apiUrl}${process.env.DARKSKY_API_KEY}/${lat},${lon}${queryParams}` },
    (err, res, body) => {
      if (err) {
        const response = { statusCode: 404, headers, body: err };
        callback(null, response);
      } else {
        const response = { statusCode: res.statusCode, headers, body };
        callback(null, response);
      }
    }
  );
};

Thatʼs it! Now, by sending a GET request to https://my-api.url/weather/?lat=10&lon=20, we have weather data for these coordinates.

Building a mechanical keyboard

2019-02-02T00:00:00+00:00

A while ago, the household got a mechanical keyboard. I tried it out, and immediately knew I needed a proper keeb. Fast forward a few months, and I’m building my own, actually soldering parts together.

How it all started •

After I tried the mech board at home, I fell in love with the feeling and got myself a lovely Vortex Race 3 for the office. It looks, um, like a mechanical keyboard, so it gets comments ranging from “OMG your keyboard is so cool”, to “oh I used to have an old keyboard like that at home”, so yes, it gets noticed.

It’s also lovely to type on, super quiet compared to what I had expected (Cherry MX brown switches are absolutely office-compatible). It has built-in mac & linux support, colemak and dvorak layouts, plus three fully programmable layers, too, so I can map my own key combinations (arrows on the home row etc.)

Fast forward a few more months, having spent a week working from bed on a macbook due to a bad cold, I got repetitive strain injury (mostly due to bad posture and hand positioning). So partly due to that, partly because why stop at one keyboard, I started looking into split keyboards.

Why a split keyboard? •

Well, if you put down your hands in front of you, you will notice they sit in an angle rather than parallel to each other. Also, if you lay your hands flat on a keyboard, you will notice that your fingers don’t all rest in the exact same vertical position. This brings us to my chosen keyboard, the keeb.io Iris, which looks something like this:

Keyboard anatomy 101 •

Most mechanical keyboards consist of a PCB (or two, if it’s a split like the Iris — PCB stands for printed circuit board), a case to protect it, key switches, most of the times a plate to hold the switches in place, and keycaps to cover the switches and make typing comfortable.

They also feature a microcontroller, such as an Arduino-compatible Pro Micro, which make it possible for the board to register key presses and send them to the computer, and enables full custom programmability (not just Vortex Race-like, but really, really full.) There’s a lot more bits and bobs that are needed for the build; we’ll get to that.

Split boards have a master and a slave side; the master is connected to the computer, and the two boards are connected with a TRRS jack cable. However, a pro micro is needed on the slave side as well, to enable the two sides to communicate.

Preparations •

Getting parts

I stupidly waited until my go-to EU supplier CandyKeys ran out of Iris kits, so I had to order directly from Keeb.io in the US. Dealing with customs clearance, shipping costs, documentation and paying a high VAT^[1] is not much fun, but whatever. Order from within your customs borders, whenever you can.

My kit includes 2 PCBs (for the two sides), with diodes for each switch, TRRS jack sockets, a reset button, a couple of resistors, and two pro micros (the master side with USB-C, which is considered to be more reliable on the long run, meaning it doesn’t break off).

I also got 56 Cherry MX Brown switches (AliExpress is a great source for getting these), clear acrylic plates, the necessary cables (a TRRS jack, NOT the same as the ones used for audio!)^[2], and some fancy keycaps (that haven’t shipped yet).

Software

Most custom and DIY boards use the QMK Firmware. It already has layouts for most available boards, including the Iris. Before I start soldering, I wanted to have a look at the software side of things to see what I’m up against. Following QMK’s Complete Newbs Guide, I installed the QMK toolbox, played around with it for a while, it seems very straightforward.

Tools

Building a keyboard usually means a lot of soldering^[3]. For those unfamiliar with soldering: the goal is to connect two pieces of metal so they conduct electricity (so that, for instance, a pressed key switch can send a signal all the way to the microcontroller, through the PCB’s circuits). This is done by melting another metal to connect the two. Melting is done by a soldering iron, and the connecting metal is tin and lead solder with a low melting point (around 200℃, but the iron melts it to a higher temperature, to be sure).

A minimal soldering setup has to include:

Soldering iron (I’m using a Weller)
Rosin-core solder (around 0.8mm diameter is best for this purpose; mine was 1mm. It usually comes as a reeled wire, and is much heavier than I thought. A 40% lead, 60% tin content is ideal for this purpose.)
Flush cutter (for cutting diode legs etc.)

In addition, it’s good to have:

Multimeter (to measure conductivity)
Tweezers or long nose pliers (to hold small things in place)
Flux (to make solder stick better)
Solder sucker or wick (for corrections — actual desoldering is best done with a proper desoldering iron)

The build •

It would be exaggerating to say this was the first time I held a soldering iron, but I was definitely not confident. I got a crash course from someone more experienced^[4], desoldered and soldered 4-5 diodes on an old circuit board that had no use, and was good to go. I mosty followed the excellent and detailed build guide on keeb.io. This is how it’s done, and my experience with it.

One really important thing to note is that the two halves have to be symmetrical, so I had to solder on the other side of the other half. Otherwise, I’d end up with two left or two right halves.

1. Soldering the diodes

First, the diodes had to be separated from the paper strip holding them neatly together, then bending the legs with a plier. I also tested each of them with a multimeter before soldering anything. If one of them is faulty, better not to solder it in and realise afterwards.

The only tricky thing with diodes is to insert them in the correct orientation^[5]. After every four or five, I tested them with a multimeter, to see if they were soldered in correctly. I had 56 diodes to solder, that meant 112 soldering points. I think I got quite good at soldering by the end.

2. Soldering the resistors

Resistors are not orientation-sensitive, and only two of them are needed. So this was an easy step.

3. Soldering the TRRS jacks and the reset switches, one on each side.

Nothing special.

After this step, there’s a bunch of optional steps that I skipped, as LED backlighting does nothing for me (for now).

4. Soldering the Pro Micro header pins

Only the header pins for now. We have to make sure they are vertical, as in as close to 90° as possible, and the two rows of pins are parallell to each other. I start by soldering a few pins on each side first, and try on the pro micro to see if it fits. If not, adjust; then solder the rest. The pro micros themselves should NOT be soldered yet.

5. Soldering the switches

This is a very fun part, finally our keyboard will start to look like one! To avoid soldering a faulty switch, I test each of them with a multimeter^[6]. Now, the switches have to be popped into the top plate (easy to identify — this is the one with square holes in it), pushed together with the PCB (facing the non-soldered side) and soldered into place. Following common recommendation, I first soldered in the switches in the corners to make sure everything is tight and well aligned, and added the rest of them after.

It’s important here to make sure that the switches sit tightly in the plate, and fit the PCB as snug as possible. When this is done, there should be no vertical space for the switches to move within the plate^[7].

6. Flashing the pro micros

This step should be done before soldering them, because desoldering is a pain if it turns out that the pro micro is faulty.

As a reminder, we need two of them; one for each side. Only one of them will be connected to the computer though, and I chose a USB-C version for that, the Elite-C, because they are less prone to breaking off. The standard, cheaper version is fine for the slave side.

Pro micros are sensitive pieces of equipment, so I made sure I was not charged before handling them. I did this by simply touching the bare metal parts of a radiator.

To flash the pro micro (meaning, format it and install a keyboard controller), first I open the QMK toolbox on my computer, then connect the pro micro, and put it in reset mode. This is achieved by shorting GND and RST with a pair of tweezers or a piece of wire (while the pro micro is connected). Now, QMK toolbox should recognise the pro micro.^[8] Flashing itself is best done from the command line — I tried using the QMK toolbox GUI, but that didn’t work properly for me. The magic command is:

make iris/rev2:default:dfu for the Elite-C, and make iris/rev2:default:avrdude for the standard pro micro.

After this step, when the pro micro is unplugged and connected again, it should show up as a keyboard — even though it’s not built into one yet!

7. Soldering the pro micros

One thing to keep in mind is that the pro micro on the master side is facing down (the side with the components to the PCB), and the one on the slave side facing up. And, practically, the USB connector towards the edge of the keyboard.

I was very careful at this step, because the header pins are very close to each other, so there’s not much space, and the pro micro is a sensitive piece. I didn’t want to accidentally fry any of its tiny components with the soldering iron.

8. Putting it all together: bottom plate and keycaps

Now the easy and fun part, I put on the bottom plate using the standoffs and screws that came with the plates. They came with 10mm standoffs, which I found a bit too short, so I ordered some tiny nylon washers from RS Online, until the 12mm standoffs get here from AliExpress.

The initial keycaps were cheap TaiHao caps, because they shipped fast (and because I had a hard time choosing the final ones). Now the keeb is sporting EnjoyPBT Black on Whites from Kbdfans.

Building a keyboard was a real fun day and a half, and I’m already looking forward to my next build, probably a second Iris, for the home office.

Second poor decision: I ordered the board to Hungary, where VAT is 27%, as opposed to 20% in the UK. ↩︎
The only f*$%up in my build was getting the absolutely wrong cable to connect the two halves. Luckily, even in my small hometown, a computer accessories store had the right thing in stock. ↩︎
Unless it’s hotswappable, meaning you can put tiny metal tubes (hotswap sockets) into the holes in the PCB where you would solder the switches etc. otherwise, so you just pop in the sockets and the switches and you’re ready to go. This only works on PCBs that already have diodes soldered on. ↩︎
Thanks, dad. If your dad is not the kickass solderer mine is, you can get the same results by searching “how to solder” on YouTube. ↩︎
On the Iris PCB, it’s easy: black end to the square hole, other end to the round hole. ↩︎
Like many things in the build, this would be much easier done with three hands instead of two: two to hold each leg and each multimeter probe end together, and a third to press the switch to test. ↩︎
I learned this the hard way and had to adjust a few switches after the whole thing was soldered. At least I learned some fixing, too! I didn’t have to fully desolder these switches, just heat the tin around the switch legs enough to melt it and be able to push the switch a bit further in. Btw, I totally forgot to solder one switch properly back in, so I have one switch that is connected by mere coincidence, which I should fix ASAP. ↩︎
See more on flashing the Iris here: Flashing Firmware - Keebio Documentation ↩︎

Publishing an npm package

2019-03-15T00:00:00+00:00

There comes a time when you need an npm package that doesnʼt exist — or just want to share something with the world. In my case, itʼs a Typography.js theme. Iʼll use yarn as this is my favourite package manager, but npm can be used in a similar fashion.

Creating a module •

This part is quite simple. yarn init and answer all the questions.

Using npm packages locally •

We should also test the package locally while developing and before publishing it to npm. This can be done by locally linking it — basically, we are letting our local yarn or npm know that this package exists, and where it lives. We also need a test project where we import it from — Iʼm using a Gatsby blog starter, because it already uses Typography.js by default.

To link the package:

cd path/to/package-name
yarn link
cd path/to/test-project
yarn link package-name

Now we can develop away.

Production build (spoiler: using Babel) •

For the sake of performance and compatibility, we should minify and compile our code to be ES5-compatible. The easiest way to do it is using Babel.

yarn add --dev @babel/cli @babel/core @babel/preset-env babel-preset-minify

Now, we can add a build script to package.json:
"build": "babel src -d dist"

Letʼs not forget to point our package entry to this dist folder (it can be called something else of course):
"main": "./dist/index.js"

Ready to publish? •

First, we have to register on npm. At least I have to, because this is my first package published there. This is conveniently done from the command line with npm adduser, which asks for a username, password and public email. Then a simple email verification, and the magic command:

npm publish

Thatʼs it!

Mocking React components with props

2019-04-08T00:00:00+00:00

In many cases, particularly in Gatsby, pages are wrapped in a <Layout> component. Today, Iʼll describe a way to test these pages isolated from their wrapper.

A <Layout> component might look something like this simplified specimen:

export default function Layout({ children }) {
  return (
    <div>
      <SiteHeader />
      <main>{children}</main>
      <SiteFooter />
    </div>
  );  
}

As an example, letʼs write a simple 404 page.

export default function NotFound() {
  return (
    <Layout>
      Sorry, this page does not exist. :(
    </Layout>
  );  
}

A test for our 404 page might look like the following, using Jest and react-testing-library:

describe('Not Found page', () => {
  it('shows a friendly message', () => {
    const { container } = render(<NotFound />);

    expect(container).toHaveTextContent('Sorry, this page does not exist');
  });
});

Letʼs imagine Layout does a lot more than in our example. If we run the 404 Not Found test right now, it will fail miserably, because thereʼs a lot more going on in Layout than just putting things in a div. But thatʼs all we need from it in our test, so letʼs do that!

Mocking the wrapper component •

Not much to change in our original test, we just have to mock Layout so it only returns a div with the children passed inside. This can be easily achieved like so:

jest.mock('./path/to/layout', () => props => <div {...props} />);

Thatʼs it! This will “render” in our test as:

<div>
  Sorry, this page does not exist. :(
</div>

As a result, our test will pass happily, because we are only testing the NotFound page itself, not caring about what happens in Layout.

Friendly UIs: Let users copy with a click

2019-07-28T00:00:00+00:00

There’s lots of subtle but very convenient features on GitHub’s UI, one of them is being able to copy stuff from an action menu. Let’s see how we can replicate that behaviour.

When is this useful? •

One really good use case is GitHub’s links to specific lines in files — generally places where it’s just not feasible to show all of them. (Imagine how littered it would look!)

It’s also a nice touch when you have something long to copy, and it’s not really convenient to select manually. Think product codes, long links with tokens or url params, and so forth.

Using the Document API •

document has much more to offer than appendChild and getElementById, just look at this looooong list, fresh from the console:

Some of them are familiar, but this time we’ll use one that’s a bit more obscure: document.execCommand. It can manipulate editable elements (such as input and anything with the attribute contentEditable). execCommand takes at least one argument: the name of the command we’d like the browser to execute.

You can try document.execCommand('otters') of course (I have), it will simply return false.

Let’s write some code! •

As mentioned, execCommand needs an editable element. This is because only editable elements can be selected programmatically. Let’s try with an input.

<input
  id="some_id"
  value="This will be on your clipboard, chicken and all 🐓"
  onclick="copyToClipboard()"
/>

To copy this text, an editable element must be selected. This can be done by:

finding the element: const element = document.getElementById('my-copiable-element')
selecting it: element.select()

function copyToClipboard() {
  const input = document.getElementById('some_id');
  input.select();
	document.execCommand('copy');
}

There, it should work already!

But this is not really nice yet. •

To use this in production, this little snippet should meet a few more requirements:

scalable (maybe we have a thousand elements, all copiable)
pretty.

Scalability

We’ll just make sure we can pass any id to copyToClipboard, like so:

function copyToClipboard(id) {
	const input = document.getElementById(id);
	input.select();
	document.execCommand('copy');
}

~~Done.~~ We’ll have to change this function after the next bit, so hang tight.

Looks

We could style the <input>, but that’s not what we’ll do. There’s a much more elegant solution, using any HTML element of choice plus a hidden <input>^[1]. Because ids should be unique, we’ll make use of data attributes.

This would almost work, but hidden elements are not selectable. So we will use a .hidden class instead, only to visually hide the element.

This now is our final code:

<div
  role="button"
  class="copy-trigger"
  data-copyid="my_uniq_id"
  onclick="copyToClipboard"
>
  Copy text
</div>
<input
  class="hidden-copy-input"
  id="my_uniq_id"
  value="This will be on your clipboard, chicken and all 🐓"
/>

.hidden-copy-input {
  position: absolute;
  left: -10000px;
  width: 1px;
  height: 1px;
}

const copyButtons = document.getElementsByClassName('copy-trigger');
copyButtons.forEach(btn => btn.addEventListener('click', copyToClipboard);

function copyToClipboard(e) {
  const id = e.target && e.target.dataset && e.target.dataset.copyid;
  const input = document.getElementById(id);
  input.select();
  document.execCommand('copy');
}

That’s it! If you want to be extra fancy, you can now show a message that it’s been copied.

<input type="hidden" ...> can be used to pass values in a form that we don’t want to display. However, they are by no means a secret! ↩︎

Iʼve reviewed lots of CVs recently. Hereʼs how to improve yours

2019-08-12T00:00:00+00:00

A solid CV is crucial to get that first interview. It is a good summary of what you can offer, and if that’s not obvious after a few seconds, hiring managers might just discard it without reading, no matter how good you are.

So what does an ideal CV look like? Quite simply, it enables hiring managers to decide in 3–5 seconds whether a call with the candidate is worth their time or not. They might also refer to it during the interview.

Because of the way they are used, CVs should have two layers: one that allows the reader to deduct a few key facts in a couple of seconds, and another one that provides more details. Both formatting and content should be adapted to serve this purpose.

Format •

As a ground rule, PDF CVs are best. They look the same on all devices, can be printed or shared via email easily, and keep their formatting across all operating systems. I’ve seen web-only CVs as well (a CV page on a personal or portfolio website). This is not a bad solution, although it may look like the candidate is trying too hard to be unique by not bothering to prepare and update a PDF. By all means link to your online CV, but make sure there’s a PDF version (and they match).

No CV, Europass, LinkedIn only, and other formats are not really convincing.

Length •

Keep it short.^[1] A good CV is one or two pages, and well structured (more on that later). Any longer than that, and the hiring manager might not read it at all. At this stage, you really just have a couple seconds of their time.

Aesthetics •

A CV should look pleasant and readable, no matter the position. This is even more important when you are a frontend developer. The essence of the job you are applying to is to make stuff on the screen look good and serve its purpose. This is your first chance to prove you are good at it. A CV is not simply an intention of applying for the job, it is part of the assessment.

Content •

It’s helpful to include your relevant work experience (from latest to earliest), with a few bullet points about responsibilities and/or key results. No need to list your experience as a shop assistant if that’s not what you are applying for — but it’s ok to mention it in one line at the end if you’d like to explain a gap between studies and developer jobs.

One more thing: thereʼs no such thing as 5+ years experience. A company can look for someone with 5+ years, thatʼs different, but you either have 5 or 6, but not 5+. If I see 5+, I immediately know itʼs not more, because then you would write 6 or 7 or 12, right?

tl;dr •

Make a nice one-pager PDF including your name and contact, link to GitHub or portfolio site, relevant positions with responsibilities and/or key results in bullet points, and a mention of education, and you’ll be fine. Remember: you have five seconds of the reader’s attention.

The longest Iʼve received for a mid-level frontend position was 11 pages. ELEVEN. PAGES. What on Earth can span 11 pages in a non-academic CV? ↩︎

Supporting dark mode on the web

2019-11-17T00:00:00+00:00

Dark mode is here to stay, and many websites, including DuckDuckGo, Twitter and my personal favourite Gatsby, make sure they blend in seamlessly with the user’s UI preferences.

Some have offered their own dark mode before this could have been picked up fron the OS settings (for example, CryptoCompare has a ‘Turn Lights On/Off’ switch in their footer).^[1]

But now, there’s a media query for that.

@media (prefers-color-scheme: dark) {
  background: #222;
  color: #f0f0f0;
}

What if I want to use this with styled-components themes?

JavaScript can detect media queries with window.matchMedia.

window.matchMedia('(prefers-color-scheme: dark)')

will return something like this:

MediaQueryList {
  media: "(prefers-color-scheme: dark)",
  matches: true, // or false :)
  onchange: null
}

So, we can set our styled-components theme based on whether there’s a match.

If I did that right (and you have a modern-enough browser), my website should be matching your system preferences!^[2]

I used to have one too, but one has to keep up with the changing times! ↩︎
Ps. you can still switch between light & dark manually, and that will be remembered in localStorage. ↩︎

Curious games

2020-01-27T00:00:00+00:00

The closest I ever got to gaming was Abe’s Oddysee (I guess Robot Unicorn Attack doesn’t count.) — but I do enjoy the odd game now and then.

Here’s an absolutely subjective selection for killing (not too much) time.

Lunar lander

What: a simple but challenging game where you have to land a rover on the moon.
How to play: online on moonlander.seb.ly
Why: because it’s so pretty and monochrome.

killersheep

What: sheep invaders. It’s a vim plugin demonstrating new vim features (as in, popups in 8.2).
How to play: by upgrading vim and installing the vim plugin.
Why: because you can shoot at neon sheep flying across your vim screen and pooping at you.

ninvaders

What: space invaders in your console.
How to play: brew install ninvaders or sudo apt-get install ninvaders.
Why: you shouldn’t have to exit the console to play space invaders.

Google console text adventure game

What: a text adventure game. I didn’t find it too interesting, but it’s an honorable mention.
How to play: Google ‘Text adventure’ (really Google, don’t DuckDuckGo) and open the console.\
Why: there’s lots of creative stuff people do in the console. This is one of them.

Bonus: Chess

What: good old chess, human versus machine.
How to play: if you have a mac, you have chess.
Why: being beaten by the computer feels a bit like being part of history.

Keeping a healthy work/life balance at home

2020-03-13T00:00:00+00:00

Working full-time remote is a bit different from the occasional home office. With this ugly virus going around and forcing a lot of employees to stay home, I’d like to share a couple of tips for a healthy work/life balance and avoiding isolation.

1. Separate office space (and time) •

One can occasionally work from home at the kitchen table or from the sofa, but for any more than a day or two, this just doesn’t cut it. There needs to be physical separation of work and non-work, so we can switch off after we’ve left the office. So we can leave the office. This is extremely important both to keep focused at work, and to be able to switch off after.

If you have a study or guest room you can use, use it — otherwise, simply nominating a chair to be your ‘work chair’ can make a huge difference. Also, avoid checking anything work-related from your personal computer, and outside of working hours. If you have to do work stuff at unusual hours, go to your designated office space to do it, so you know you are working, not spending hours ‘just checking something quickly’.

If you share your home with someone, make sure they know about your working hours and your working spot, and respect it. For me, it helps a lot that we say goodbye in the morning before “going” to work, and say hello after work when we “get home”. We also let each other know if we will stay at work longer than usual.

2. Make sure you’re comfortable, the good way •

I don’t mean sitting on a couch, with the laptop in your lap. That’s a prime way for getting repetitive strain injury^[1]. Ask yourself: “Would this be comfy for watching Netflix?” If the answer is yes, it’s not for extended work.

Sit at a desk or table, use cushions if your chair is not comfortable, and try to change your setup if something hurts. If you have an external keyboard, use it, and put some books under your laptop to bring the screen closer to eye level.

3. Stay in touch with the team •

Speak to people often. Video calls, with the camera on, should happen ad-hoc, without requiring a calendar invite. Respect others’ focus times of course, and from your side, try to be available as much as possible.

Make it clear for everyone when you are available. Don’t rely on just being online on Slack, instead, say hi in the morning and say goodbye in the afternoon. No Irish goodbye! Similarly, let the team know if you’ll be unresponsive for more than 5 minutes or so (e.g. “Need some head space, will be on dnd for an hour”, “Will have lunch now”, or “Off for a coffee break, back in 15”), and make use of Slack statuses.

But the biggest loss when not sharing an office is the lack of watercooler talk. You can still do that: ask someone if they want to share a coffee break with you, pick up the phone, and just chat about whatever comes up.

4. Take regular breaks •

It’s easier (for me at least) to get really, really lost in work in the quiet of the home. Pomodoros help because they remind me of two things:

I’m here to focus
I need a break once in a while.

I use pomodoro to limit working time, not to limit breaks. Sometimes I skip a break, but never two. Some of my breaks are 30 seconds, some are 15 minutes. In the end, do what works for you best, just make sure you do take regular breaks.

5. Have pre- and post-work rituals •

Always, always put on something you would wear to work. How we dress affects how we perform, and getting dressed prepares you for leaving home, and entering office space.

Keep your regular pre-work routine as well: if you shower in the morning, keep doing it.

And, of course, make sure you get home from work. What do you usually do? Have a cup of tea, sit down in the living room? Call someone? Cook dinner? Whatever you already do, keep doing it.

Use the time gained by not having to commute. Maybe you can go for a walk before work. Read a little, catch up on your painting, writing or soap making. Keep safe 😷, and keep in touch.

RSI manifests as a pain in the wrist, forearms, neck or shoulders due to damaged tendons. Although it lead me to the very enjoyable hobby of building a keyboard, I would recommend trying to avoid it. ↩︎

GitHub CLI: create and manage PRs from the command line

2020-04-12T00:00:00+00:00

Recently released in beta, GitHub CLI managed to integrate seamlessly in my workflow, like it’s always been there. As oh-my-zsh’s git aliases, they quickly became muscle memory.

Of course, there are two kinds of programmers: those who use a desktop client for git, and those who don’t^[1]. Vim being my editor of choice, you can probably guess which camp I’m in. Hearing that GitHub have released a tool just for me was music to my ears.

What is it for?

Mainly for managing pull requests and issues directly from the command line.

How to get it

brew install gh

Chechking PRs for code reviews: `gh pr view` and `gh pr checkout` •

For a little bit of context, as a frontend developer, I like to always run pull requests locally, to make sure what I review works and looks fine (sure, QA can do that too, but let them catch the bugs that aren’t obvious.) So, reviewing a pull request involves reading the changes, checking out the branch, and running locally.

In a browser-based workflow, this looks something like the following:

copy the branch name from github.com/org/repo/pull/123
git checkout the-pr-branch
oh, I forgot to pull, it’s not there yet. git pull
git checkout the-pr-branch
run code.

The same using the cli:

gh pr list
gh pr checkout 123
run code.

That’s my kind of workflow! ⚡️

This is what happens in a bit more detail:

$ gh pr list

Pull requests for some-org/some-repo

#123  Add some great feature  feat/cool-feature
#124  Fix nasty bug           fix/nasty-bug

gh pr list shows me all the open pull requests in the current repo. All I need to do is choose which one I’m interested in.

Now comes the best part: checkout switches to the PR’s branch based on PR number.

$ gh pr checkout 123

Switched to branch feat/cool-feature
Your branch is up-to-date with origin/feat/cool-feature.

I can also open the PR on github.com right from the terminal (it opens the browser automatically):

$ gh pr view 123 --web

Opening https://github.com/some-org/some-repo/pull/123 in your browser.

Opening pull requests: `gh pr create` •

$ gh pr create

Creating pull request for feat/cool-feature into master in some-org/some-repo
? Title ▌

After filling title and body (the latter using your system editor^[2]), it will give you the option to preview, submit or cancle the pull request. Depending on the task, I usually preview and request reviews, but sometimes just submit.

$ gh pr create

Creating pull request for feat/cool-feature into master in some-org/some-repo
? Title Fix nasty bug
? Body <Received>
? What's next?  [Use arrows to move, type to filter]
> Preview in browser
  Submit
  Cancel

You can also open a draft pull request by passing the --draft (or -d) flag: gh pr create -d.

Useful for checks: `gh pr status` •

You can check the overall PR status of a branch with gh pr status. This is not an overview though; it is branch-specific. So for the following output, you have to be on the same branch as the PR:

$ gh pr status

Current branch
  #123  Add cool feature
    - Checks passing
  #124  Fix nasty bug
    - Checks passing

Created by you
  You have no open pull requests

Requesting a code review from you
  #123  Add cool feature
    - Checks passing - Review required

Issues etc. •

You can list, view (open in browser) and open issues with the respective commands gh issue list, gh issue view 10, and gh issue create. They work very similarly to prs.

And, just as I was checking the docs to fact-check what I’m writing, I’ve discovered you can create a repo with gh repo create some-org/another-repo. Not something I do on a daily basis, but I might even get to using it! On the other hand, gh repo clone some-org/some-other-repo is a much friendlier experience than either remembering the whole .git repo url syntax or visiting the repo and clicking clone.

Overall? Lgtm. •

GitHub CLI is a simple, easy-to-use tool that’s also easy to love.

Be sure to check out the docs, as there are a lot of useful options. Happy coding! 🎉

I admit this may be a very personal choice, and I have an opinionated… opinion. That is, to understand git properly, and solve more complex issues, it’s better to use the command line. As the desktop repo states, “GitHub Desktop is not a replacement for the functionality of Git, but a tool to enable you and your team to be more productive.” ↩︎
You can set this in ~/.bashrc or ~/.bash_profile or ~/.zshrc, whichever you use, by adding export EDITOR=vim (or any other editor you like.) ↩︎

CSS tricks: respecting spacing in hash navigation

2020-04-28T00:00:00+00:00

When implementing a hash-based navigation, it’s not trivial to control the actual starting position of headings. This could cause headings to be cut off or hidden below your floating navigation. I’ll show you two ways to fix that.

But first: what’s the problem? •

When using hash navigation, browsers take advantage of the id attribute to find and jump to elements on the page. This is very useful in long documents, when you’d like to enable visitors to jump to sections further down. So, for instance, you can have a <h2 id="monstera">, and upon clicking a link <a href="#monstera">, users are taken to the respective section. This works with any kind of HTML element – just make sure ids are unique.

But the problem is where exactly it jumps to: right where content starts.

Consider this example. As you navigate back and forth between the two sections, the title will be hidden by the floating header. As you can see in the screenshot below, the text inside h2#monstera is right at the document’s top, with a lower z-index than the header’s, and it seemingly doesn’t respect the margin. Except, it does — margin is just not part of the content.^[1]

So, how could we make that space part of the content?

Simplest solution: change margin to padding •

Pretty easy: change your element’s margin to 0, and add some padding. Of course, you can offset the extra padding with a negative margin, in case you want less spacing between sections.

h2 {
  margin: -1em 0 0;
  padding: 1.8em 0 .5em;
}

Here’s the previous demo, updated.

Alternative solution: `::before` •

If you don’t want to change padding for some reason, you can use a the ::before pseudo-element as well. It will insert a node as the first child of our h2, and as such, is part of the box. You can control its height as below.

h2 {
  margin-top: -1em;
}

h2::before {
  content: '';
  display: block;
  height: 1.8em;
}

Here’s the demo for this version.

To understand how this works, I recommend reading about the box model. ↩︎

The great expectations of working remotely: 3-month check-in

2020-05-09T13:12:54+00:00

I’ve been looking forward to this. Not having to commute, living in a small town close to nature, still being able to contribute in an exciting startup in a meaningful way. What have I been expecting exactly, and how has it worked out, you ask?

Here’s a list of all my assumptions (and, in some cases, doubts). I noted down all the expectations a couple days before I started working remotely, and after roughly 3 months, it’s time to check in.

Expectation: I will have lots of uninterrupted time to focus.

I will use pomodoro and expect to be done with my 2x4 sets of pomodoros way before 5pm, as opposed to 5.30 or 6pm these days.

Reality: 😕 Haha. Well, not really.

The majority interruptions don’t come in the form of someone walking up to my desk and asking something. Instead, they tend to come in something hijacking my attention, regardless the channel. As for pomodoro, I gave it a try but I struggle to keep up with it. I really should, because it helps a lot in focusing.

Also, I’m not finishing work earlier. But not later either, so it’s ok.

Expectation: I will miss the watercooler talk (and social interaction in general).

To fight this, I will make an effort to get out — sometimes go to a café for my morning espresso, join a country walking club, go to the library, go to the same baker…

Reality: 🤔 ?

Oh, of course I do, but it’s a question mark because the past couple months haven’t exactly gone according to plan.

First, a bit of context. It’s 2020, so if you’re reading this from the future, it’s the year when we spent months in lockdown due to Covid-19. (Sorry, I promised myself to avoid the topic in my blog, but I feel that it belongs.)

The plan was to visit the office every couple months. Next week would be the second time I would have seen my colleagues since going remote, had it not been for the lockdown. But I haven’t seen any of them in person since February — and I really wouldn’t mind to do so by now! On the other hand, living in a small town means people are generally eager to spend a few minutes longer chatting about whatever. Nobody is in a hurry, and if you are open to it, any transaction (buying bread, signing up for a library card) can be more than just a transaction.

Yet… I’ll have to report back on this later.

Expectation: I will be healthier.

As in, I will move a lot more. A couple push-ups before work, the occasional swim, the frequent jog, and much more walking, as I will live in a much quieter place.

Reality: 😊 A bit better physical, and much better mental health.

Sometimes, I go for a long walk on my lunch break, or hop on my bicycle right after work. Or I can go for a jog in the morning. Or a walk. Air quality is much better here too, and being a quiet small town, there’s less noise and light pollution, so I sleep much better.

And something I’ve not expected or thought of: I have the time and energy to take care of myself, and I’m not nearly as stressed as I used to be in London.

Expectation: I will have the willpower to go out and have quality social interactions.

As an introvert, whatever social interaction I get from my commute and at the office is enough to put me in a state when I just want to be left alone and not talk to anyone.

The problem with big city life for me is that there is a limit to what I can comfortably have in a day before I want to turn the world off. And the quality of the interaction doesn’t matter — it’s building up whether it’s a lovely after-work drink with friends or rushing past hundreds of pedestrians and dodging cyclists in central London. So by the time it’s time for quality social interactions, I can’t take any more of them.

That, I hope, will change.

Reality: 😊 Pub Wednesdays!

Absolutely yes, and I’m always looking for our “Pub Wednesdays” (which sometimes fall on Tuesdays because I just can’t wait to go out.) The answer to “shall we do x tonight/this weekend?” is hardly ever a “nah, I’d rather stay in.”

Expectation: I will have two extra hours a day to do something useful.

A lot of time is lost to commute, and some to saying hello and goodbye at the office and generally being interrupted by people who arrive later and leave earlier. You are trying to concentrate, but you also want to say hi, so you step out of your focus zone and chat for a minute or two. Then back to work, but someone else arrives five minutes later, and the same thing happens again.

It’s not that I don’t like saying hi and chatting for a couple of minutes, I love it! But it translates to the first twenty minutes or so at the office absolutely unproductive from a work point of view.

Reality: 😊 I hugely underestimated the difference lack of commute makes.

Now I feel like days aren’t long enough, I have much more mental energy left by the end of the day than I can execute on. I’ve started new pet projects I will never finish, picked up forgotten books, improved my self-care routine (from basically zero), started looking for new hobbies to pick up. I never go to bed exhausted (except for full-day hiking or biking, of course.)

Expectation: Finding a good system for the home office work lunch will be challenging.

I have no good ideas right now on what to do with lunch and lunch time. Cooking a proper meal every lunch seems daunting. Doing my cooking for the week beforehand and eating the same stuff every day seems boring. Going out a lot for lunch seems expensive. Quick-fixing lunch seems bland. I know I will need a system, and I’d also like to minimise decision-making on this one, but not eat anything mediocre at the same time (life is too short for that).

Reality: 🤷‍♀️ Lunch is not so important.

I never really made a big deal of lunch at the office, and I don’t do now. Sometimes we cook something. Sometimes we go for a walk and pick up a sandwich from a bakery in town. Sometimes I just have a nibble. What we do do is try to meet for lunch most days.

Dinner is the more important one, and because I never have a big lunch, I’m usually hungry by the time I finish work, which means an early dinner, which means better sleep.

Expectation: Keeping a daily routine will work.

I think it will! Like brushing my teeth and putting on clothes I would actually wear in civilisation, and taking breaks at regular intervals.

Reality: 😊 It does!

I wrote about the importance of routine here.

Conclusion? •

I think I’ve made the right decision going remote, and I feel very fortunate to have a career and an employer who support it. I hope I’m not an exception but part of a tendency, and more of us will be given the choice to work remotely, each in the environment where we can best function.

Turning any website into a PWA with (mostly) vanilla JS

2020-06-25T15:00:00+00:00

Progressive web apps (PWAs) are installable, responsive web applications that work on any device (within reason) and deliver a reliable experience on unreliable networks, and even work offline (once they’ve loaded, of course).

The progressive in the name suggests that they provide an acceptable experience on as many browsers as possible^[1], while offering an advanced experience on modern browsers, enabling new features as they become available.

PWA availability in major web frameworks •

Gatsby and Sapper offer it out of the box. It’s opt-in both in React and Angular, and Vue offers a core plugin. There’s a PWA plugin for 11ty too. So — we’re fairly well covered!

But what if we need something vanilla, or something more specific?

PWA from scratch •

1. Make it installable

In practice, this is when the user can “add to home screen” on their mobile device. To achieve this, we need just a few things in index.html:

  <head>
    <title etc…>
+   <meta name="theme-color" content="#f00">
+   <link rel="shortcut icon" href="/favicon.ico">
+   <link rel="apple-touch-icon" href="/path/to/icon.png">
+   <link rel="manifest" href="/path/to/your.webmanifest">
  </head>

Now, we need to create those icons and the web manifest we refer to.

your.webmanifest (you can call this anything, with a .webmanifest extension)

{
  "name": "Your site – a cool web app",
  "short_name": "Your site",
  "description": "Here goes your awesome description",
  "icons": [
    {
      "src": "icon32.png",
      "sizes": "32x32",
      "type": "image/png"
    },
    {
      "src": "icon512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ],
  "start_url": "index.html",
  "display": "fullscreen",
  "theme_color": "#f00",
  "background_color": "#f00"
}

If you run a Lighthouse audit now, the PWA section will already show some passed checks, e.g. web app manifest meets requirements, sets a theme colour, provides a valid apple-touch-icon.

It will, however, complain that your app “does not register a service worker.” Let’s get to that!

2. Register the service worker^[2]

This can be done manually, but today we’ll use workbox-build.

$ yarn add --dev workbox-build

In your build script, after building the app:

const { generateSW } = require('workbox-build')

generateSW({
  globDirectory: 'dist', // or your build directory
  swDest: 'dist/sw.js', // or wherever you want to put your service worker
})

The last step is to register the service worker, and we’re good to go, with a green Lighthouse report.

<script type="text/javascript">
  if('serviceWorker' in navigator) {
    navigator.serviceWorker.register('/path/to/service-worker.js');
  }
</script>

A few notes

If you have a very large number of pages linked from your front page (e.g. a blog), it may be a good idea to limit the number of pre-fetched pages or use pagination to avoid downloading old entries unnecessarily.

There are several service worker plugins for common build tools (e.g. Webpack, Rollup and Parcel) on npm — usually, it’s a good idea to use one of those for seamless integration.

Finally, if I’ve made a mistake, please let me know!

See Advantages of web applications and Progressive Enhancement, both on MDN. ↩︎
By the way, service workers can do much more than make an app available offline. ↩︎

Accessible lazy-loading with a

Down the rabbithole – a frontend blog

Why

Flexbox with fixed sidebar

HTML structure •

HTML

CSS

Fixing the sidebar •

Scrolling the content •

SVG animations with CSS

The main ingredients: @keyframes and CSS animation •

HTML

CSS

That’s boring. Is that all SVG can do? •

Typing animation with JavaScript

Part one: rotating phrases

HTML

JS

Part two: typing

HTML

JS

Part three: a blinking cursor

HTML

CSS

Putting it all together

Here’s the code:

Ways to improve loading speed

Why is my website slow? •

How to solve queueing? •

Decrease the number of assets requested

Decrease asset sizes

Use a CDN (content delivery network)

Time requests strategically

Lazy loading images

Let’s get to the code! •

Building a reading progress bar

Letʼs do some maths •

Turning it into code •

Unit testing abstract classes in React

A simple abstract class •

The fun part: testing! •

Building an API proxy with Serverless — Part 1

Enter serverless •

Let’s turn this into a DarkSky API gateway •

Ok, on to the weather! •

Building an API proxy with Serverless — Part 2

From function to API •

A side note about AWS credentials •

Deploying the lambda •

Making the server a bit more flexible •

Building a mechanical keyboard

How it all started •

Why a split keyboard? •

Keyboard anatomy 101 •

Preparations •

Getting parts

Software

Tools

The build •

1. Soldering the diodes

2. Soldering the resistors

3. Soldering the TRRS jacks and the reset switches, one on each side.

4. Soldering the Pro Micro header pins

5. Soldering the switches

6. Flashing the pro micros

7. Soldering the pro micros

8. Putting it all together: bottom plate and keycaps

Publishing an npm package

Creating a module •

Using npm packages locally •

Production build (spoiler: using Babel) •

Ready to publish? •

Mocking React components with props

Mocking the wrapper component •

Friendly UIs: Let users copy with a click

When is this useful? •

Using the Document API •

Let’s write some code! •

But this is not really nice yet. •

Scalability

Looks

Chechking PRs for code reviews: `gh pr view` and `gh pr checkout` •

Opening pull requests: `gh pr create` •

Useful for checks: `gh pr status` •

Alternative solution: `::before` •

2. Register the service worker^[2]