Weeknotes 52

It has been a year since my first weeknotes.

I still haven’t finished that blog post on React Hooks.

Since reading Caroline Crampton’s “The Problem with the Inconsequential Quest”, I’ve found it hard to listen to recommended podcasts that fit the description, e.g. Underunderstood’s “Amazon’s Next Top Model”:

I’m sure readers will be very familiar with the form: a host chooses something that is of seemingly little importance and investigates it with a thoroughness and journalistic rigour that seems completely out of proportion to the original question. The resulting episode or series documents this journey in detail and ultimately reveals a conclusion that surprises and delights listeners.

Instead of writing these notes on Sunday while C napped, I attempted to remap the extra buttons on my trackball to go back and forwards in my browser. I tried USB Overdrive, SteerMouse and Sensible Side Buttons but balked at the need for kernel extensions (and sadly Sensible Side Buttons doesn’t work because one of the buttons is interpreted as a middle-click).

I spent an hour trying to clean up the various bits of software I’d tried as kextstat revealed USB Overdrive’s kernel extension lingered after uninstallation. In the end, I had to use kextcache to clear “staged” extensions in Recovery Mode.

I’ve actually made things worse than when I installed the official Kensington TrackballWorks driver.

I’ve been doing quite a lot of work with Amazon Web Services for a client and was very grateful to have automated it with Hashicorp Terraform as I needed to quickly destroy and recreate S3 buckets connected to CloudFront distributions with ACM certificates.

I’ve found it useful to manage both our production and staging environment using a single Terraform repository by leveraging AWS Organizations and the ability for an administrator in the root organization to temporarily assume the role of an administrator in any of the member accounts. By default, AWS will create a role called OrganizationAccountAccessRole to do exactly this.

To manage Terraform resources in different AWS accounts we can then use an “Assume Role” block in an AWS provider like so:

provider "aws" {
  alias  = "root"
  region = "eu-west-1"
}

provider "aws" {
  alias  = "production"
  region = "eu-west-1"
  assume_role {
    role_arn = "arn:aws:iam::PRODUCTION-ID:role/OrganizationAccountAccessRole"
  }
}

provider "aws" {
  alias  = "staging"
  region = "eu-west-1"
  assume_role {
    role_arn = "arn:aws:iam::STAGING-ID:role/OrganizationAccountAccessRole"
  }
}

Then you specify the appropriate provider alias in each resource, e.g.

resource "aws_s3_bucket" "staging" {
  provider = aws.staging
  bucket   = "bucket-staging"
}

resource "aws_s3_bucket" "production" {
  provider = aws.production
  bucket   = "bucket-production"
}

You can use something like AWS Vault to run your Terraform commands as an administrator in your root account and it’ll assume the appropriate role for each resource automatically:

$ aws-vault exec root-account-administrator -- terraform plan

I’ve been working on a new feature in a Rails application and needed to hide it behind a feature flag so I wasn’t blocking other features that needed deploying. Now that I have two possible sets of behaviour in various parts of the application, I wanted to test them both with RSpec.

The feature flag lives in a bit of custom Rails configuration, e.g.

Rails.configuration.cool_new_feature = ENV['COOL_NEW_FEATURE']

Then various parts of the application switch on the value of that flag:

if Rails.configuration.cool_new_feature
  # do something cool
else
  # do something less cool
end

I wanted to change the value of that configuration before running some examples and reset it back to its original value after the test, e.g.

context 'with the cool new feature enabled' do
  around do |example|
    original_value = Rails.configuration.cool_new_feature
    Rails.configuration.cool_new_feature = true

    example.run

    Rails.configuration.cool_new_feature = original_value
  end

  # Examples here...
end

However, adding this across several places in the test suite seemed rather noisy but we can leverage user-defined metadata with hook filtering to clean this up:

# in spec/rails_helper.rb
RSpec.configure do |config|
  # ...

  config.around(:each, :cool_new_feature) do |example|
    original_value = Rails.configuration.cool_new_feature
    Rails.configuration.cool_new_feature = example.metadata[:cool_new_feature]

    example.run

    Rails.configuration.cool_new_feature = original_value
  end
end

Then in our specs, we simply tag examples with the appropriate metadata:

context 'with cool new feature enabled', cool_new_feature: true do
  # ...
end

context 'with cool new feature disabled', cool_new_feature: false do
  # ...
end

I haven’t had any epiphanies after writing these notes every week for a year but I still think about the Paul Murray quote I shared in weeknotes 15:

Although technology has the capability now to record entire lifetimes, meaning that every moment may be pulled from the foaming sea of oblivion to the dry land of perfect recall, the mythic power of the photograph nevertheless relates to the future, and not to the past. Every recording conceals the secret fantasy of a future self who will observe it; this future self is himself the simulacrum, the persona ficta. He exists beyond time, beyond action, beyond need; his only function is to witness the continuum of the past, as he might observe the steps that brought him to godhood. Through this fantasy, time is transformed from the condition of loss into a commodity that may be acquired and stockpiled; rather than disappear ceaselessly into the past, life accumulates, each moment becoming a unit of a total self that is the culmination of our experiences in a way that we—biological composites who profligately shed our cells, our memories and our possessions—can never be.