Dan Matthew

Glofox Data Breach March 2020

Tue, 25 May 2021 16:32:11 GMT

Have you heard of a company called Glofox? Their software provides the booking system for gyms and fitness studios.

They suffered a data breach in March 2020, but haven't said much about it. Nothing I could find. Others have, however.

Glofox has not responded to media requests for comment on a possible security breach but it has, in recent days, responded to individuals on Twitter who posed questions to the company after being informed its website had been compromised.

Lame. I was under the impression that under data protection legislation, organisations must contact the appropriate body and make a public statement as soon as they have knowledge of a breach. As an Irish company, they should have reported it to the Data Protection Commission:

From 25 May 2018, the General Data Protection Regulation (GDPR) introduces a requirement for organisations to report personal data breaches to the relevant supervisory authority, where the breach presents a risk to the affected individuals. Organisations must do this within72 hours of becoming aware of the breach.

Where a breach is likely to result in a high risk to the affected individuals, organisations must also inform those individuals without undue delay.

Whoops. Did Glofox pass this responsibility on to their customers, or are they not bothered? Note the date of the Irish Times report: November 2020.

In January 2021 I was alerted to the breach thanks to a service called Have I Been Pwned. It's integrated in my password manager, 1Password.

Since the Glofox dashboard does not offer a way to delete an account, it took an email to dataprivacy@glofox.com to do so.

It's taken until May for the first spam emails to arrive at the compromised email addresses: both hawking a Norton Antivirus subscription which needs renewing. Do you think it leads to a legitimate website?

If you're going to look after personal data, get your shit together. Mistakes happen, but don't try and hide it.

Access local server from Parallels VM

Sun, 09 May 2021 18:28:53 GMT

I was struggling to access a development server on my host machine from a Windows 10 virtual machine (VM). Despite sharing a network, turns out the trick is not to use the host IP address, but that of the bridged network the VM has created. For Parallels, that address tends to be 10.211.55.2

Netlify CMS

Sun, 17 Jan 2021 00:00:00 GMT

I've been experimenting with services such as Contentful, Prismic, and finally Sanity. Currently, each post on this site is a Markdown file, and it is converted into a HTML page by 11ty when the site is built. The "content-as-a-service" platforms return data over the wire, and each record in the GraphQL response is turned into the post it represents.

However, I think I prefer to keep each post as a file, all wrapped up on Github, so it's back to Netlify CMS for me.

Pharmaceuticals

Tue, 08 Dec 2020 00:00:00 GMT

I thought I was an OK runner. I trained hard over the course of 2018 and aimed to get under 1:40 at the Great North Run. I ran 1:31, and then a few weeks later went 1:27 at Birmingham's Great Run.

Since that purple patch, running has gotten harder and harder because my asthma has become harder to control.

While I've had a blue "rescue" inhaler to hand since I was a child, I've quickly progressed through the various steroids over the past two years:

Beclometasone 400mg (Clenil Modulite, brown)
Fluticasone (Flutiform, white)
Beclometasone 100 micro-grams (Fostair 100, pink)
Beclometasone 200 micro-grams (Fostair 200, pink)

I've been on the Fostair 200 for over a year now, in conjunction with another corticosteroid called Ciclesonide.

Now because my blood tests show high levels of eosinophils the assumption is that I'm allergic to something, so I pair those with the following tablets to try and tamp down those naughty cells in my body which are flaring up and causing constriction:

1x montelukast 10mg
2x theophylline 200mg (Uniphyllin)

In addition, I've also had a spell on Spiriva Respimat – often given to COPD patients - which delivers 3 micrograms of tiotropium bromide monohydrate. I tend to be the youngest in the clinic waiting room when I visit the consultant. From this NHS worksheet, I'm at the "Seek specialist advice" stage of progression.

I don't particularly wish to be taking steroids for any longer than necessary. Because of this constant barrage of steroids, I suffer from oral thrush (yum yum), and my voice has changed in tone. I get frequent upper-respiratory infections, and each morning I get to hock up my lungs like a 20-a-day smoker. I've had several doses of an oral steroid and antibiotics, but was one course shy of being invited to another clinic to take an injected medicine.

What really gets my goat is how it affects my ability to exercise: I can be working and breathing hard, but as soon as an interval ends and my body relaxes – BANG: here comes the constriction. Classic exercise-induced bronchitis symptoms.

While I know I this is still a case of extreme privilege, I would love to discover a route out because a lot of my self-worth was tied up in running.

Weeknotes: 2020-10-25

Sun, 25 Oct 2020 00:00:00 GMT

I'm super consistent with writing these, eh?

There's been a glut of televised cycling with the condensed racing calendar, so we've had the Ronde van Vlaanderen, the climax of the Giro d'Italia, and the start of La Vuelta in the space of the past week.
That helps, because I've been feeling rather sorry for myself when it comes to exercise. I've been suffering from "something" for nigh-on a month. Whatever it is, it's taking a long time to kick and is making activity difficult.
Really enjoyed reading Kat Holmes' Mismatch.
Finished watching The Haunting of Bly Manor on Netflix. Not as creepy as Hill House.
It's been a week for Australian film: watched Justin Kurzel's adapatation of The True History of the Ned Kelly gang, and Jennifer Kent's The Nightingale

Creating Github Releases With Lerna

Sat, 01 Aug 2020 00:00:00 GMT

Reducing the number of manual steps needed to get code live is a good thing. This is how I create Github releases from the CI process.

Lerna

Lerna is a tool to manage a monorepo. It can automate releases on Github when the version of a package changes, which is one less task to perform manually.

Circle CI

Circle is a continuous integration solution. In this scenario, Circle is configured to run the test suite for each component after a commit. Once the tests pass, Lerna will increment the version number of the component, using the Conventional Commits specification

Creating a release

Circle Config

Here is a workflow definition with two discrete jobs. The first runs the tests; the second runs lerna version against the desired components.

version: 2.1
orbs:
  node: circleci/node@1.1.6
jobs:
  build-and-test:
    executor:
      name: node/default
    docker:
      - image: circleci/node:latest-browsers
    resource_class: small
    steps:
      - checkout
      - node/with-cache:
          steps:
            - run: npm install
            - run: npm test

release:
    docker:
      - image: circleci/node
    resource_class: small
    steps:
      - checkout
      - node/with-cache:
          steps:
            - add_ssh_keys:
                fingerprints:
                  - "F1:NG:3R:PR:1N:T"
            - run: npx lerna bootstrap --hoist --ci
            - run: npx lerna version --no-private --conventional-commits --create-release github --yes

workflows:
    build-and-test:
      jobs:
        - build-and-test
        - release:
            filters:
              branches:
                only: main
            requires:
              - build-and-test

All the interesting work is contained within this instruction:

npx lerna version --no-private --conventional-commits --create-release github --yes

Lerna will increment the version of public packages using the Conventional Commits spec, before creating a Github release, and it won't need any prompting to do so.

Creating a deploy key

In order to modify the project repository, Circle will need an SSH key with write access: a "deploy key". The public key is added from the project's settings/keys screen on Github; the private half is added to Circle via Project Settings -> SSH Keys. You'll know if you got it right, because you'll avoid the following:

lerna ERR! lerna ERROR: The key you are authenticating with has been marked as read only.
lerna ERR! lerna fatal: Could not read from remote repository.
lerna ERR! lerna
lerna ERR! lerna Please make sure you have the correct access rights
lerna ERR! lerna and the repository exists.
lerna ERR! lerna

Adding an access token

While the machine might be authenticated, Lerna will need to identify itself as working with the correct permissions. Thus the addition of GH_TOKEN available to it. A new access token can be created from within Github

Publishing the release

When a build goes green on the main branch, a new release will appear automatically on Github. The release notes will be filled automatically, and the changelog for each package will have been updated at the same time. There does appear to be a slight bug with the version number. My understanding is that fix commits will increment the patch number when using semantic versioning, but the component has increased from 0.2.0 to 0.2.1 with a single chore commit…

Next steps

Lerna's publish command works the same as version, but automates publishing to NPM.

Weeknotes: 2020-08-01

Sat, 01 Aug 2020 00:00:00 GMT

I spent a day off watching a series of talks from JAMstack Conf, before getting wet and wild out on the bike: that was not a pleasurable experience.
This week I have been getting to grips with Figma. DesignLab's Introduction to Figma, alongside Sketch Together's video content have been useful.
This resulted in the illustration at the beginning of the page, inspired by RISD's work for the 2006 Winter Olympics. I wanted to play with animation, and SVG will make that easier to achieve.
At Talis, we've been working hard to improve the interactive states of our interface elements to correct issues with contrast.
I played my first-ever game of Fortnite on Switch, and took the Victory Royale. I think I've peaked for 2020.
Rode RLSCC's bash again this week and beat last week's time by a couple of minutes. I've started adding some run training back into the schedule to maintain that fitness.

CircleCI Node Images with Browsers

Mon, 27 Jul 2020 00:00:00 GMT

Building a Node project with Circle and want access to browser binaries? The default circleci/node image doesn't come with them installed, which threw a spanner in the works when attempting to run some tests. Circle maintain an exhaustive list of images one can use: any Node version appended with -browsers will come installed with Chrome, Firefox, OpenJDK v11, and Geckodriver.

Using continuous integration to build, test, and publish with Netlify

Sun, 26 Jul 2020 00:00:00 GMT

Last week, Chris Coyier published a post on CSS Tricks which covered an approach to the simplest of testing set-ups: ensuring the website loads and displays some content. A "smoke test".

Just one super basic integration goes a long way. If your site spins up, returns a page, and renders stuff on it that you expect, a lot is going right.

I've been meaning to add some level of test coverage to this website for a while now. I'd been wanting to run builds against Lighthouse CI to ensure that anything that breaks the performance budget or fails one of the automated accessibility tests doesn't make it into production.

Thanks to some well-written documentation, it was easy to get Cypress installed and configured to test against my local development server.

The test

Per the docs:

/// <reference types="Cypress" />

describe('Home page', () => {
  it('successfully loads', () => {
    cy.visit('/');

    cy.get('h1').should('contain', 'Dan Matthew');
  });
});

Cypress will look for a configuration file in the directory, and it's in this cypress.json where a baseUrl can be defined:

{
  "baseUrl": "http://localhost:8080",
  "ignoreTestFiles": "cypress/integration/examples/*.js"
}

Each call to .visit() will use the baseUrl as its root. While it's set to localhost here, we'll want to change it later on, for reasons that will become apparent.

Testing against a local web server

Netlify expects tests to be run elsewhere, since every commit to the linked VCS causes a build and publish. I'd used Travis CI previously, so thought I'd pick up where I left off. I wanted it to operate like my local development environment, where I'd run npx eleventy serve and then spawn Cypress in the background: npm run serve:ci && npm test

This did not work as anticipated. serve was never going to end, and Cypress was never going to be started 😂. The Cypress docs even warned against this, and do cover a number of solutions, but pig-headedly I didn't want to install yet another package.

Time to rethink.

Building a Deploy Preview with the Netlify CLI

With Netlify in control of builds, I'd configured it to use a couple of Build Plugins. I didn't realise that these can be installed locally as devDependencies and they'll operate on the generated site just as they do on live. This meant using the CLI became a plausible alternative – just as soon as automatic builds were turned off.

This setting can be found at https://app.netlify.com/sites/{YOUR_SITE_NAME}/settings/deploys. Look for "Build Settings", and then "Stop builds". The following warning is displayed:

Netlify will never build your site. You can build locally via the CLI and then publish new deploys manually via the CLI or the API.

Now the onus is on the developer 😬. In this case, we'll get Travis to perform this task for us. With the simplest of configurations each commit will build the site, but only those pushed to main will trigger a deploy:

language: node_js
node_js:
  - "node"
cache: npm
script:
  - npx netlify build
deploy:
  cleanup: false
  provider: script
  script: npx netlify deploy
  on:
    branch: main

The boffins out there will know that this implementation is naive: it doesn't run any tests; and it's going to give me a green build each time, which is nice for the ego, less so for confirming that the site renders. That build script might have only succeeded in pumping out a broken site if something's gone screwy in development.

Testing a Deploy Preview with Cypress

One of the neat things about Netlify is that each branch will get built and published with a unique URL. This makes it easy to visit the preview in a browser and ensure it works as expected. How can we access that URL and provide it to Cypress?

The documentation for deploy offers a hint:

alias (option) - Specifies the alias for deployment. Useful for creating predictable deployment URL's

Very useful indeed, Netlify. But what to use as our alias? I don't know how long branch deploys exist, so it didn't seem sensible to use a hard-coded string. It turns out that Travis surfaces a number of environment variables: I opted for $TRAVIS_JOB_ID because it seemed like it's probably going to be unique…

First off however, the branch build is going to have to be deployed: npx netlify deploy --alias $TRAVIS_JOB_ID. Then Cypress is invoked: npx cypress run --env host=$TRAVIS_JOB_ID--danmatthew.netlify.app --spec \"cypress/integration/home_page.spec.js\" --headless

The --env flag in the cypress run command overrides the baseUrl from cypress.json and ensures we are testing the latest deploy.

In the logs of previous builds I'd seen:

If everything looks good on your draft URL, deploy it to your main site URL with the --prod flag.

Alrighty, then!

🚨 Uh-oh. Cypress crashed: apparently the spec flag doesn't play nicely with CI environments. Ah well, don't have to worry about running all the tests if there's only one test…

With that resolved, the build failed again. --env host is completely the wrong flag, and to set the baseUrl from the environment is done thusly: CYPRESS_BASE_URL=https://$TRAVIS_JOB_ID--danmatthew.netlify.app npx cypress run --headless --config-file false

With that done, our config looks like:

os: linux
dist: xenial
language: node_js
node_js:
  - "node"
cache:
  npm: true
  directories:
    - ~/.cache
script:
  - npx netlify build
  - npx netlify deploy --alias $TRAVIS_JOB_ID
  - CYPRESS_BASE_URL=https://$TRAVIS_JOB_ID--danmatthew.netlify.app npx cypress run --headless --config-file false
deploy:
  cleanup: false
  provider: script
  script: npx netlify deploy --prod
  on:
    branch: main

…and we get a succesful build.

Use the Netlify provider, stupid

There's me, using multiple steps under the script phase, when Travis provides its own deploy step for Netlify projects.

Perhaps the documentation needs to be clearer because it references Netlify Drop, which at first glance looks like a different mechanism entirely. When I looked closer at the required arguments, I realised they were identical to the CLI commands I was using earlier.

Using the provider means the deploy stage of our travis.yml takes this form:

deploy:
  cleanup: false
  provider: netlify
  site: $NETLIFY_SITE_ID
  auth: $NETLIFY_AUTH_TOKEN
  prod: true
  edge: true
  on:
    branch: main

There we go: we've got a CI tool taking care of testing our builds. If the tests pass, the site will be set live. If not, we can go visit the deploy preview and see what's gone wrong.

Bonus: Automating Github releases

Doing this isn't strictly necessary, but I wanted to play with the semantic-release package and see what it could do. I had intended to incorporate it into the Accessible Web Components project, but I discovered Lerna could perform both actions for me, which rendered it superfluous.

To publish a new release on Github, we can add a run property to the deploy stage, or make it a little more obvious with the after_deploy stage:

if tag IS blank
after_deploy:
  - npx semantic-release

The conditional there is to prevent yet another build when semantic-release creates the tag. It took me a while to figure out why I was seeing three builds…

Like many other tools, semantic-release supports many configuration options. In this case, I didn't want the package being pushed to npm, so it was necessary to override the default plugins with the following in my releaserc file:

{
  "branches": "main",
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/github"
  ]
}

Accessible Web Components: Tabs

Sun, 12 Jul 2020 00:00:00 GMT

The web component

I've finally published my first NPM package: a web component to represent a tabbed interface.

View the demo

Rock and roll.

It might not be the most fashionable of side projects - or technologies - but I felt that a wrapping up the desired behaviour of a tabbed interface into a bog-standard web component might do some good. If it saves another developer spending an afternoon doing the same thing, or makes the life of the user a little easier, then I'd consider that worthwhile.

The component follows the behaviours specified in the WAI-ARIA Authoring Practices document. It can be styled with CSS to suit its environment, and will display as a single column should there be a hitch. Alas, web components do require JavaScript in order to be registered, and it certainly requires JS in order to enhance the markup with the required ARIA attributes.

Usage

JavaScript

Import the three components, and tell the browser about them:

import { AwcTabs, AwcTab, AwcPanel } from "@accessible-web-components/tabs";

window.customElements.define("awc-tabs", AwcTabs);
window.customElements.define("awc-tab", AwcTab);
window.customElements.define("awc-panel", AwcPanel);

HTML

It takes the following structure. Add as many tabs and panels as are required.

<awc-tabs>
  <awc-tab role="heading" slot="tab">Tab 1</awc-tab>
  <awc-panel role="region" slot="panel">
    <h2>My first tab</h2>
    <p>Here is some text…</p>
    <ul>
      <li>…and a list</p>
    </ul>

    <button type="button">I am a focusable element within the tab</button>
  </awc-panel>
  <awc-tab role="heading" slot="tab">Tab 2</awc-tab>
  <awc-panel role="region" slot="panel">Content 2</awc-panel>
  <awc-tab role="heading" slot="tab">Tab 3</awc-tab>
  <awc-panel role="region" slot="panel">Content 3</awc-panel>
</awc-tabs>

To the 67 brave souls who have downloaded it since yesterday morning: ~~you are brave~~ thanks ~~for being my guinea pigs~~!. I've put the package level as a pre-release, at 0.0.0-alpha.3. I don't think it's going to break your project, but there are a few more features I want to include before it goes to 0.0.1. I guess it would help if I wrote some tests, and I can certainly improve the documentation.

Side projects, eh? Gotta love 'em.

Four years ago, I made the first commit in a Github repository called Accessible Web Components.

The following year, in March 2017, I gave a talk at HydraHack about my plan to create a whole series of components. As a fellow speaker that night, I'm hopeful Nivi's offer of feedback still stands!

The first component – an alert message – was the "Hello world!" I used to play with various frameworks. It moved across Polymer, Polymer v2, Stencil, a custom element, Vue, and finally LitElement. The Polymer version still lives in the repository, complete with its use of HTML Imports. It's a shame that particular spec got shot down: it feels awkward defining component templates inside the JavaScript.

Then, with the plan to create a whole series of these components, I thought a monorepo would be a good idea. I installed Lerna, and spent way too much time getting its configuration just so.

With Lerna just about sussed, I turned to the guidelines suggested by the open-wc project when it comes to publishing. I've been using their linting and commit standards for some time, but the project has really been evolving: I've used their generator to scaffold the next component in the series.

Finally, it was time to publish. Again, it took too long figuring out how to create an organisation on NPM, such that the package name could be in the format: @accessible-web-components/<blah>. While it sounds trivial, I thought it worth keeping this and future components grouped together right from the start.

Despite it being a fairly trivial piece of software, I'm excited yet nervous at the thought of third parties using something I've written. I'm looking forward to constructive criticism to help shape it and make the web a richer, and more accessible platform.

Goodbye Gatsby; Hello Eleventy!

Sun, 05 Jul 2020 00:00:00 GMT

Hello there! It's been a good while since anything new content has appeared on this website, and while I've tinkered with the splash page on occasion, it's not displayed anything more than my name in a <h1>.

Some thoughts on 'v3':

I've gotten rid of Gatsby. It wasn't long after I upgraded to v2 that I noticed the site no longer rendered if JS was disabled; something I had appreciated in v1.
The site now runs on Eleventy, and uses Andy Bell's Hylia Starter Kit to get me going. I expect to be hacking away at it over the next week.
I wanted to place to display my photos. Yes, I know there's only a single photo being displayed. It's a shot of the Molino Stucky in Venice. I'm using Cloudinary to host the image and apply transforms based on device DPI, orientation, and screen width.
I want the site to feel fast. It's preconnecting to third-party origins (Cloudinary, Google Fonts, Speedcurve), and preloading the most important assets. I'm inlining the first blast of CSS, then loading the rest asynchronously. Benchmarking the site on Web Page Test, it surprised me how much slower the site performed when this wasn't done.
Speedcurve was mentioned above. Thought I'd have a play and see how the site performs over time. Additionally, I only just found out that one doesn't need to use Chrome to play with Lighthouse: Jeremy Keith put together a bookmarklet to send the current document over to the Lighthouse viewer. In the same vein, Lighthouse Metrics seems a neat way to keep tabs on performance.
I want to begin publishing accessibility audits of some of my favourite sites. At Talis, I've been spending a good chunk of time reviewing and improving the accessibility of our products ahead of September's <abbr title="The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018">PSBAR</abbr> deadline. While I've been championing accessibility internally since I started, it has felt like a struggle to get cross-functional buy-in until recently.
When not working on improving our accessibility, the recent focus has been on relaunching our website. I am extremely grateful for Timber, which made working with WordPress a much more pleasurable experience. Something that irks me is that I tried hard to keep the site snappy, but as third-party plugins have been enabled to support desired functionality - "buy, don't build" is the mantra - more and more external resources get pulled in. Even the WordPress core functionality dumps a load of crap in, which has to be manually disabled via the theme's functions.php. Le sigh.

Preload, Prefetch, and Preconnect

Sat, 09 Dec 2017 00:00:00 GMT

Working on a Polymer project recently, I got to experiment with serving the content from Firebase Hosting, which now offers support for HTTP/2 and Server Push. Server Push allows content to be delivered speculatively: content is delivered whether or not the user has it already, and in some cases it might not be required at all.

Preload

To take advantage of this ability though, I needed to declare the assets I wanted to be pushed down. In my firebase.json file I declared:

"headers": [{
  "key": "Link",
  "value": "<my-app.js>;rel=preload;as=script"
}]

which instructed Firebase to serve the file with the appropriate Link header. It's possible to do the same when referencing resources via a link element too:

<link rel="preload" href="foo.js" as="script">
<link rel="preload" href="bar.css" as="style">

If you inspect this site, you'll see that Gatsby does this for me in production. Coupled with HTTP/2 on Cloudfront, visitors should experience a fairly snappy load. Essentially, all assets for a page are transferred in a single round trip, though it does mean if you're a repeat visitor (hi mum!), I'm probably using bandwidth unneccessarily. Addy Osmani suggests that:

Use Push when you know the precise loading order for resources and have a service worker to intercept requests that would cause cached resources to be pushed again.

I guess that's next on my to-do list with Workbox.

Prefetch

<link rel="prefetch" href="/font.woff2">

Prefetch is another resource hint developers can take advantage of. Prefetch tells the browser that a resource will be needed on the next page, or navigation. Resources marked as such will be treated as a much lower-priority fetch than those with preload, and it's up to the browser to make the call as to whether it will load it or not. I've seen a pattern where a webfont is set to be pre-fetched so that it doesn't block rendering on the first load, but is available right away when a visitor navigates to a new page.

Preconnect

<link rel="preconnect" href="/page2">

Preconnect can be used to 'warm-up' the connection to a resource in order to "eliminate the costly DNS, TCP, and TLS roundtrips from the critical path of the actual request"

All of these techniques can be used in an attempt to improve the performance of your site but it's a trade-off between second-guessing the behaviour of your guests, while not exhausting their bandwidth unneccessarily – especially for those on metered connections.

Sources

https://caniuse.com/#search=pre
https://www.w3.org/TR/resource-hints/
https://www.w3.org/TR/preload/
https://medium.com/reloading/preload-prefetch-and-priorities-in-chrome-776165961bbf
https://css-tricks.com/prefetching-preloading-prebrowsing/
https://blog.cloudflare.com/announcing-support-for-http-2-server-push-2/
https://firebase.googleblog.com/2016/09/http2-comes-to-firebase-hosting.html
http://www.bramstein.com/writing/preload-hints-for-web-fonts.html

Automating the Build Process with Travis-CI

Mon, 20 Nov 2017 00:00:00 GMT

Updated 9th December to illustrate latest iteration of Travis.yml

Before I ported this site over to Gatsby, it was powered by good old Jekyll. I'd make an edit, run jekyll build, then push the output to S3 with s3_website. Not exactly onerous, but I noticed that I'd be drafting posts, or updating the structure of the site and then not pushing them live in a timely manner. (And what do you know, it's happened again! – Ed., December 2nd)

Cue a Continuous Integration (CI) solution – although it took me many attempts to get it right. And by right, I mean it at least:

builds the site
deploys to S3
invalidates the CloudFront distribution.

Attempt #1: Use the default S3 provider

Travis' documentation is pretty, pretty, pretty good. I think you could just about get away with this, if you're happy to serve straight from the S3 bucket:

language: node_js
node_js:
 - "8"
script:
 - yarn build
deploy:
  provider: s3
  access_key_id: $AWS_ACCESS_KEY_ID
  secret_access_key: $AWS_SECRET_ACCESS_KEY
  bucket: danmatthew.co.uk
  region: $AWS_DEFAULT_REGION
  # Prevent Travis from deleting your built site so it can be uploaded.
  skip_cleanup: true
  # Path to a directory containing your built site.
  local_dir: public
  on:
    branch: master

Because I have both package.json and yarn.lock in my repository, Travis is smart enough to figure I want to use Yarn to run during the install phase.

I like this implementation, but Travis is only concerned with S3 here. I have a Cloudfront distribution sat in front of this bucket in the hope of saving a few pence and making the site feel snappy. Sure, I could manually log in to AWS and invalidate the distribution or do it via the command line, but y'know: let's automate it.

Attempt #2: Use AWS CLI to invalidate the Cloudfront distribution

This is where it feels messy, and there are a bunch of extra steps to mess up. AWS CLI is installed via Pip, so this implementation needs to be driven by Python.

language: python
python: 3.6
sudo: required
dist: trusty
env:
 - TRAVIS_NODE_VERSION="8"

I had to explicitly specify the version of Python, because the default appeared to be 2.4 and I ran into issues… Java-related, possibly?.

This is where it starts to be a blend of different tasks, and I'm piecing together instructions from various sources.

Install Yarn

before_install:
  - curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
  - echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
  - sudo apt-get -qq update
  - sudo apt-get -y install yarn

Install NVM

As it's not provided by default, I need to install Node and NPM in order to install my site's dependencies and then build it. I figured NVM would be the most sensible approach:

install:
 - rm -rf ~/.nvm && git clone https://github.com/creationix/nvm.git ~/.nvm && (cd ~/.nvm && git checkout `git describe --abbrev=0 --tags`) && source ~/.nvm/nvm.sh && nvm install $TRAVIS_NODE_VERSION
 - pip install awscli

I discover afterwards that the ugly $TRAVIS_NODE_VERSION environment variable could have been avoided by specifying the version in the project's .nvmrc file.

As the Travis cycle goes install, script, deploy, next up is…

before_script:
  npm install
script:
  npm run build

(Travis experts – could those commands just have been listed sequentially in the script block?).

Configure S3 bucket

We use the same deploy block as before:

deploy:
  provider: s3
  access_key_id: $AWS_ACCESS_KEY_ID
  secret_access_key: $AWS_SECRET_ACCESS_KEY
  bucket: danmatthew.co.uk
  region: $AWS_DEFAULT_REGION
  # Prevent Travis from deleting your built site so it can be uploaded.
  skip_cleanup: true
  # Path to a directory containing your built site.
  local_dir: public
  on:
    branch: master

Blow away the old Cloudfront distribution

When this succeeds, we can now use the AWS CLI to ensure that Cloudfront serves the latest version of these files:

after_deploy:
 # Allow `awscli` to make requests to CloudFront.
 - aws configure set preview.cloudfront true
 # Invalidate every object in the targeted distribution.
 - test $TRAVIS_BRANCH = "master" && aws cloudfront create-invalidation --distribution-id $CLOUDFRONT_DISTRIBUTION_ID --paths "/*"

Inspecting the bucket, I notice that Travis doesn't doesn't sync the files – i.e. only new files are added; old ones are deleted. It might not be an issue in practice, but I quite like keeping my buckets tidy… 😒

Next!

Attempt #3: Use s3_website

I mentioned in the intro that when publshing the website from my computer I used the s3_website gem. I know it, it does all the tasks I want it to, and it's straightforward to configure.

(Although, I fib: since upgrading to Sierra, I've not been ~~able~~ inclined to deploy since it requires a Java installation which I really don't want to do. I know, weaksauce.)

So, we go again! Now, we're sacking off a Python-based deployment pipe in favour of a Ruby powered process:

language: ruby
rvm: 2.2
sudo: required
dist: trusty
# Again with the redundant env var
env:
 - TRAVIS_NODE_VERSION="8"
before_install:
  - curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
  - echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
  - sudo apt-get -qq update
  - sudo apt-get -y install yarn

Install s3_website

install:
  - . $HOME/.nvm/nvm.sh
  - nvm install stable
  - nvm use stable
  - gem install s3_website

Push to S3

before_script:
 - yarn
script:
 - yarn build
after_script:
 - test $TRAVIS_BRANCH = "master" && s3_website push

Boom. All my s3_website settings are configured in environment variables and my s3_website.yml config, so that one line in the after_script block pushes to the correct bucket and invalidates the Cloudfront distribution.

Looking back over it, I think I'd be quite happy to sack off the yarn installation and reply on NPM. Again I wonder whether the blocks can be consolidated into one and the commands listed sequentially? I'm not experienced enough with Travis to know what benefits I get from splitting the commands into the different stages, especially since this particular deployment process is not exactly complicated. Perhaps so the process can fail earlier if necessary?

Proposed attempt #4: Use AWS CLI for everything

I suspect I could probably do all of the above with the AWS CLI, though it will need switching back over to Python again. Woe is me 😩.

Attemp #5: Concise

…whereupon I decided to sack off Yarn, and after configuring Travis to build PR and branch merges, whitelist the master branch:

branches:
  only:
    - master
language: ruby
rvm: 2.2
sudo: required
dist: trusty
cache:
  - npm
install:
  - . $HOME/.nvm/nvm.sh
  - nvm install stable
  - nvm use stable
  - gem install s3_website
before_script:
  - npm install
script:
  - npm run build
after_script:
  - s3_website push

Hide An Element From A Screenreader

Wed, 04 Oct 2017 00:00:00 GMT

I recently discovered that it's not enough to rely on either role="presentation" or aria-hidden="true" to remove an element from the accessibility tree. Just like CSS quirks, in order to ensure an element is truly hidden from screenreaders across operating systems and browsers, you will want to double-up on the attributes:

  <!-- Tested with macOS, Voiceover, and Chrome 63 -->

  <!-- Will be announced -->
  <div>I am a presentation element. I don't add anything more than a visual flourish.</div>

  <!-- Will be announced in Voiceover, but not in JAWS -->
  <div role="presentation">I am a presentation element. I don't add anything more than a visual flourish.</div>

  <!-- Voiceover will ignore this element; JAWS won't -->
  <div aria-hidden="true">I am a presentation element. I don't add anything more than a visual flourish.</div>

  <!-- Voiceover will ignore this element -->
  <div aria-hidden="true" role="presentation">I am a presentation element. I don't add anything more than a visual flourish.</div>

You can view the demo at JSBin

npm 101 – Version Ranges

Mon, 25 Jan 2016 00:00:00 GMT

The following is a snippet from this site's package.json:

  "devDependencies": {
    "bower": "^1.6.5",
    "grunt": "~0.4.5",
    "grunt-contrib-imagemin": "~0.9.4",
    "grunt-contrib-sass": "~0.9.2",
    "grunt-contrib-watch": "~0.6.1",
    "matchdep": "~0.3.0"
  }

As per the JSON spec, we've got a series of key/value pairs making up the devDependencies object: the name of the package we want installed for those working on the project, and the version number of that package. However, using npm install <package> will leave odd extra characters in the generated file. So what do they mean?

Indicator	Name	Meaning
`^`	Caret range	Allows minor and patch updates
`~`	Tilde range	Allows patch-level changes if minor version is specified

It's possible to add configure your project to help ensure only a specific version of a package is added. Create a file called .npmrc, and specify save-exact=true. As a bonus, you can also added save=true to make sure that any new installs are added to your projects' package.json

Column Sizing and Captions in Safari

Mon, 07 Dec 2015 00:00:00 GMT

<p class="message"> <em>Updated 25/09/2016:</em> It still appears to be an issue in Safari 10.0 (macOS Sierra). </p>

A couple of weeks ago, I encountered an odd rendering issue with Safari and column widths. I had planned to write about it, lest the afternoon I spent trying to debug it be of use to anyone who stumbles across this post. Before I could get round to it, lo and behold: I've fallen victim to it again! Safari on OSX - both Yosemite and El Capitan - does not like the following scenario:

.col-checkbox {
  width: 28px;
}

.col-content {
  width: auto;
}

.col-action-btn {
  width: 60px;
}

<table class="table table-striped">
 <caption class="sr-only">My caption to describe the table</caption>
  <colgroup>
    <col class="col-checkbox">
    <col class="col-content">
    <col class="col-action-btn">
  </colgroup>
  <thead>
  <tr>
    <th>
      <div>
        <span>
          <input type="checkbox">
        </span>
      </div>
    </th>
    <th>Two</th>
    <th>Three</th>
  </th>
</tr>
</thead>
<tbody>
  <tr>
    <td><input type="checkbox"></td>
    <td>Content</td>
    <td>Content</td>
  </tr>
</tbody>
</table>

Safari refuses to apply the column widths specified in the stylesheet, and instead splits the columns based on their content, flagrantly ignoring the authors instructions.

It seems to be related to the sr-only class applied to the caption. This utility class hides the element from those who can see the table contents as a whole, but provides a useful description for those using assistive technologies. Within this class, the position: absolute declaration used to remove the element from the document flow causes the bug. But strangely, it only happens when applied to caption: were one to use a span here, Safari will respect the column widths.

I've not been able to replicate in other desktop browsers: Chrome, Firefox, and Opera split the columns as desired, though Mobile Safari renders the table as per its desktop cousin. The Internet seems to have a scarcity of other reports, which makes me wonder if I have encountered a bug. Or maybe nobody else is combining this class with table captions, column widths - defined using classes, since the width attribute is obsolete - and Safari. I wonder at what point does it become a Safari / Webkit bug? I have a demo of it available on JSBin and the various permutations are easily replicable.

Two forms of IIFE

Thu, 22 Oct 2015 00:00:00 GMT

TIL there are two ways of creating an IIFE - and there's heated discussion between parties as to why they have chosen their preferred style. Douglas Crockford prefers the second structure here, as the first "looks like dog balls". If you use JSLint, you'll be encouraged to adopt the latter style - it suggests the parentheses that invoke the function should sit within those that contain it.

(function(){
  function foo() {
    // I'm not polluting the global scope!
  }
})();

(function(){
  function bar() {
    // Nor am I!
  }
}());

Shadowing And Hoisting In JavaScript

Sun, 25 Jan 2015 00:00:00 GMT

Shadowing

To "shadow" a variable is to create a new variable with the same name as one that exists in a higher scope. In JavaScript, a new scope is created when writing a function. When resolving a variable, JavaScript starts at the innermost scope and searches outwards.

Hoisting

Hoisting, on the other hand, is a behaviour which results in variables being raised, or 'hoisted', to the top of the scope - the function - in which they have been defined. It's recommended to declare all of your variables at the top of a function in order to avoid overwriting a value.

Checking Date Equality in JavaScript

Wed, 16 Apr 2014 00:00:00 GMT

Checking whether one date is equal to another is made difficult because of the way object equality works in JavaScript. Object equality isn't tested by the internal value of the object, but by identity. If the date object isn't a straight copy, it isn't considered equal. The following example will never return true:

function isChristmas(dateToTest){
  var christmas = new Date("12/25/2014");
  return (dateToTest === christmas);
}

console.log(isChristmas(new Date("12/25/2014"))); // False

To make the isChristmas function work, we need to check equality in a different way. We use the getTime method that is available on Date object, and compare the values it returns. getTime returns an integer representing the number of milliseconds since midnight of the epoch: January 1st, 1970.

function isChristmas(dateToTest){
  var christmas = new Date("12/25/2014");
  return (dateToTest.getTime() === christmas.getTime());
}

console.log(isChristmas(new Date("12/25/2014"))); // True

But! If we happen to compare against a Date object that occurs on the same day, but a different hour, we'll run into trouble - because the time elapsed since the epoch will be different.

A work around here might be to check our date against the year, month and day, like so:

function isChristmas(dateToTest){
  return (dateToTest.getFullYear() === 2014) &&
  (dateToTest.getMonth() === 11) &&
  (dateToTest.getDate() === 25);
}

console.log(isChristmas(new Date("12/25/2014 12:00"))); // True

But then this is glossing over the complexities that daylight savings and timezones introduce.

TL;DR: Be aware that there are 'gotchas' when comparing dates. Use Moment.js to avoid them and make your life easier.

Closures 101

Mon, 03 Feb 2014 00:00:00 GMT

I updated this post on the 16th February in order to clarify my writing and thoughts.

What is a closure?

In computer science:

a closure is a first-class function with free variables that are bound in the lexical environment. Such a function is said to be "closed over" its free variables. A closure is defined within the scope of its free variables, and the extent of those variables is at least as long as the lifetime of the closure itself.

A higher-level definition is that

A closure is a function defined within another scope that has access to all the variables within the outer scope.

And just in case, think of it as:

...like keeping a copy of the all the local variables, just as they were when a function exited.

Closures are a strange concept to get to grips with, but once this core concept is understood they're relatively easy to understand: a closure is created when a developer accesses variables outside of the immediate lexical scope.

An example of a closure in action

function makeAdder(a) {
  return function(b) {
    return a + b;
  };
}

x = makeAdder(5);
y = makeAdder(20);

x(6); // 11
y(7); // 27

JSFiddle demo

What happens in a closure?

When makeAdder is called, a new scope is created with one property: a - the argument passed to the function. It also returns the anonymous function declared within it. This returned function maintains a reference back to that original scope. This scope will persist and escape being garbage collected until there are no more references to that function.

Take a look at what happens when we log x:

function(b){
  return a + b;
}

So when we call x and pass an argument, that's going straight into the anonymous function makeAdder returned the first time. Because we know a closure is a combination of a function and its scope

Since we are then able to all y, we discover that we have ended up with two different copies of makeAdder's local variables: one in which a is 5, and another where a is 20.

When would I use a closure?

The technique is often used to prevent against contaminating higher levels of scope - data is kept tucked away. Along these lines, a closure can be used to help practise encapsulation: an object can return its public methods and variable, while keeping those intended to be private hidden and inaccessible to the rest of the codebase.

You may have taken advantage of one without realising it, as they're a key concept when implementing an 'Immediately-Invoked Function Expression' (IIFE). Using an IIFE within a module, as per the Module Pattern, ensures that the module is self-contained.

An intelligent developer will

use closures to create additional scopes that can be used to group interrelated and dependent code in a way that minimises the risk of accidental interaction.

Useful reading

Exclude folders in Jekyll

Sat, 18 Jan 2014 00:00:00 GMT

After experimenting with Grunt, I noticed that the deploy was taking rather a long time - it turned out that Jekyll was bundling my 'node_modules' directory (all 32MB of it!) into its compiled site folder. However, I can avoid this in future by adding: exclude: node_modules to my _config.yml file.

Remove Child Nodes In JavaScript

Wed, 11 Dec 2013 00:00:00 GMT

After discovering whether an element has children, one may want to go ahead and remove them. The brutalist approach involves setting the node's innerHTML property to an empty string.

<div id="box">
  <h1>Hello</h1>
</div>

var box = document.getElementById('box');
if (box.firstChild) {
  box.innerHTML = '';
}

Another option is to grab the firstChild and then remove it like so:

while (box.firstChild) {
  box.removeChild(box.firstChild);
}

The results on jsperf indicate that removeChild is the faster of the two techniques, and also the more robust: the innerHTML technique won't work on XML markup.

But wait! As usual, there is another alternative. Check out:

while (box.hasChildNodes()) {
	box.removeChild(box.lastChild);
}

It's really just a variant on the method above: ensuring that box still has children and removing them from the bottom instead of the top.