I was going to write a sweet blog post, and thought that I would quickly add footnotes support to my blog. I use the Redcarpet gem for this blog, and it appears to have support for footnotes. I tried adding the footnotes setting to the Redcarpet configuration, but that didn’t work. I figured that I had an old version of Redcarpet, so I wanted to upgrade it. Unfortunately, my Jekyll version was a little out of date (1.5.1, where the most recent is 3.0.2.)

I figured it wouldn’t be too painful to upgrade. For the most part, upgrading was straightforward. However–I ran into an issue where my drafts were not showing when I ran the jekyll build --drafts command (or its serve counterpart.) It ended up taking me several hours to debug, so I figured I’d share in case someone else runs into a similar issue.

I started making significant headway when I created a new project with the same Jekyll version (3.0.2). I created one simple draft in that project, ran the command, and the draft was correctly generated into my _site folder. I copied over only my _config.yml file (after trying to copy a few other things), and the draft was not correctly generated. So it had to be something with my configuration file.

I ended up commenting out various parts of the file until the file was properly generated, and found the bad line:

# Files to exclude from copying to _site when the site is built
exclude:
  - Gemfile
  - Gemfile.lock
  - Guardfile
  - README.markdown
  - _drafts  # <<< the offending line
  - _reference
  - config.ru
  - ..etc.

Apparently excluding the _drafts folder doesn’t work so well with newer versions of Jekyll. Previously it was excluded (I think) so that I didn’t deploy my _drafts folder. My guess is that since it is excluded from being copied, it is not present for some downstream process. It would have been nice to get a warning about this behavior though.

I tried it out on my blog, and… it still didn’t show my drafts! I quickly compared the two versions and my blog’s drafts had published: false set to true. So I figured that removing this line would make a difference, and it did. I guess that older versions of Jekyll must have ignored this flag when --drafts was passed, but it seems like newer versions of Jekyll take the published flag into consideration. I removed it from all of my drafts and the scripts that generate drafts and pages and posts.

Now it seems to work. It only took me like four hours.

So instead of the sweet blog post, I wrote this up instead. Hope it helps! ^{1, 2, 3}

Since college I have stayed up pretty late and gotten up late. My wife generally goes to bed around 10 or 11, and I am more in the range of 12 or 1 AM. However, the past few months I had some worse sleep hygiene. I was staying up late reading random stuff on the internet, or worse, watching Netflix or even video game streams. I would tell myself that I could go to bed at the next half-hour increment, and then blow through that. It would generally take me some time to fall asleep because I had watched something interesting, thought about engaging things, or just been exposed to a lot of light. My sleep quality would be worse than if I had done non-stimulating activities before bed. The next morning I would wake up and be annoyed that I had wasted that time. The next day I would be pretty wiped and irritable.

The process was a bit cyclical. I would stay late at work because I had gotten in later, and then it would be dark. I would be less likely to exercise and had a lot of energy at night. And on and on.

Taking charge

I realized that something had to change.

My plan was to commit to stop using my computer at around 10 PM. I reasoned that there was nothing that required me to use the computer after that point unless I made poor life decisions. If I truly needed to be on the computer, I either put things off too much or had an emergency that better engineering or planning could fix.

My hypothesis was that if I didn’t have the internet, I would either need to do useful things locally or would turn the computer off completely out of boredom. I don’t have many interesting things to do besides write words, read longer form content, write programs (using the Dash program as an offline lookup), or do spaced repetition when I don’t have a connection. I looked for a program that would try to turn off my internet completely at a certain time. It seemed that the solutions that I found for doing something like this had one or more negative qualities:

• cost money and didn’t quite have the features I wanted
• were irrevocable (could not get the internet back, even after a reboot)
• didn’t have scheduling of blackout periods
• only blocked portions of the internet, not everything

Rolling my own

A Macbook Pro is my primary rig. My first thought was to make a Mac program that would manage all of this. Then I figured that I could run some automated recurring tasks to try to achieve the same result. Typically one would use cron, but since I have a local Jenkins server, I can run Jenkins tasks to get a better interface and more visibility into the job runs.

I have three tasks set up in Jenkins:

1. The first task is called “Warn wifi turning off”. It warns me that the Wi-Fi will be turning off at 10 PM. It does this by invoking the Mac command say to audibly warn me of this fact. Pretty simple:

   /usr/bin/say "The wi-fi is turning off at 10 PM!"
   

   It runs at 9:50, 9:55, and 9:59 (50,55,59 21 * * * in cron syntax.) It could be potentially improved by flashing a system message in the upper corner in case the volume is down, but works fine.

2. The second task is called “Turn wifi off at 10 PM and every five minutes”. This script does not mess around. It turns off my Wi-Fi every five minutes from 10 PM until 5 AM. This is to prevent me from just turning the Wi-Fi back on. It is also quite simple:

   sudo /sbin/ifconfig en0 down
   

   This just says to take down the wi-fi interface through a command-line command. The interval is: 0,5,10,15,20,25,30,35,40,45,50,55 0,1,2,3,4,22,23 * * *.¹

3. The last task is called “Turn wifi on at 5 AM”. It does the opposite of the command above:

   sudo /sbin/ifconfig en0 up
   

   It runs at 5 AM (0 5 * * * in cron syntax.)

The set up is slightly buggy at the moment–the Wi-Fi usually doesn’t turn back on in the morning, for instance, so I have to invoke the script manually. Also, I’ll sometimes be greeted with “The Wi-Fi is turning off at 10 PM!” when I open the computer in the morning if I had it closed before 9:59 PM. But these are acceptable issues.

The result

So far I don’t think that I stayed up late dicking around on the internet once since I’ve set it up. I’ve only disabled it to watch a movie with my wife in the evening on her birthday, and then promptly re-enabled it.

I take the 10 PM deadline much more seriously than if I had to think about it every day. I’m sure that I would see the deadline come and go and not think twice about it after a few weeks. I think this is an example where a little willpower in setting up a system pays dividends down the road. A few times I’ve heard that the Wi-Fi is going to shut off and hurried to finish any tasks that needed the internet. Usually some time shortly after 10 PM I do get bored and do other things or simply go to bed.

Now I am getting more sleep and starting on a more positive spiral.

Another positive belief that I’ve come to realize: if there’s something worth consuming on the internet, it will be there tomorrow. Tomorrow I’ll be more awake, alert, and able to assess whether this thing is worthy of my time. But today, I can be safe in the knowledge that if there is something great, it’ll be there tomorrow and to not need to “complete” things (are they ever really complete?)

What distracts you?

What are your bad habits, and how could you set up a system to try to corral them?

Today I have a handy break down of how I made one of my Vim editing workflows more efficient.

I recently realized that I split code lines a non-trivial amount and that this process takes time and effort. I think this probably happens because I am working with ES6 imports more. Often, I’ll start with one line and add some imports, and then want to split up the line to make it more readable. For example, if I have:

import { clearUser, fetchUser } from 'actions'

and then I want to add another imports, the line gets a bit long:

import { clearUser, fetchUser, somethingElse } from 'actions'

I would prefer this line to be split like this:

import {
  clearUser,
  fetchUser,
  somethingElse
} from 'actions'

To accomplish this, I would ideally:

• go the beginning of the line
• hit f, to go to the first comma
• press l to move one character to the right (past the comma)
• press s to delete the space character and go into insert mode
• press <enter> to create a new line
• hit <esc> to get out of insert mode
• hit ; to go to the next comma (since I had f searched it before)
• then press . to repeat my insertion command
• repeat the previous two steps for the remaining items in the list
• sort the list items by visually selecting the range and invoking :sort (I like sorted lists)
• clean up the brackets and indentation

Splitting one line into multiple lines

I figured there was a better way than doing this manually each time, so I searched online. Apparently the splitjoin.vim plugin “simplifies the transition between multiline and single-line code”. I had this plugin installed but had not used it much. However, it seems like it does exactly what we want.

Instead of the clunky commands above, with this plugin you can press gS to split it up as before. I do this a few times a day, so this is a clear win.

Joining multiple lines together

gJ joins multiple lines together onto one line. It doesn’t handle spaces in this case quite how I like it to:

import {clearUser, fetchDependents, somethingElse} from 'actions'

There are no surrounding spaces, and I prefer having a space around the braces when the code is all on one line.

There is a fix for this: if you have surround.vim installed (and you really should…) you can type cs{{ to add the space after joining so it looks correct. Basically this command says “change the surrounding curly brace pair to be a curly brace pair with a single inner space”. So you’d press gJcs{{.

While a digression, the other permutations of braces do interesting things:

• cs{} truncates all inner brace space
• cs}{ adds a single space to both sides
• cs}} is basically a no-op

Another, shorter way of joining lines like these together is to press 5J (where 5 is the number of lines in between the braces.) This will run the “join lines” command five times.

splitjoin.vim

There are a number of different languages that splitjoin.vim supports. I recommend skimming through its documentation for languages that you use. Another useful example is being able to convert the following Ruby:

if something
  run_a_command
end

to:

run_a_command if something

with gJ (and the opposite with gS). The join lines command from above wouldn’t work here.

Hope this helps!

Often in a modular application you will have functionality that is reused by extracting to a common location. For example, you might move your authentication logic to a server-side middleware so that logic is consistent and only declared in one place. Or you might have a mix-in that multiple classes or modules use to avoid duplicating code.

These are common application patterns, but one question that often comes up is: how can we easily test this and make sure that the code works as we think it should? Since there may be multiple places that use the same logic or functionality, it would be wasteful and boring to test it in multiple places. And if the code in a shared module is changed, we’ll have to change multiple tests.

There is the school of thought that tests should be really dumb so you can be sure of what you are testing. There is merit in this philosophy, but I think that copying many tests has low return on investment and a high maintenance cost. Let’s look at some other approaches.

Test scaffold

One of my favorite approaches to test the functionality of the shared module just once is to use a test scaffold. The test scaffold is responsible for creating a class, module, or application that includes, imports, extends, or uses the code we want to test. (That was a mouthful!) For example, if we have a Rack middleware that we want to test, I can create a new testing application that uses the middleware and run tests against that testing application:

require 'test_helper'

class TestApp < Sinatra::Base
  # middleware that I want to test
  use API::HandleAuthenticationMiddleware

  get '/api/test' do
    [201]
  end
end

class TestAppTest
  include Rack::Test::Methods

  def app
    TestApp
  end
end

Based on the above, we’ll have an endpoint in TestAppTest that is accessible from /api/test and we can hit it to assert that the authentication middleware works as expected. If the middleware is supposed to respond with 401 when the user isn’t logged in, I would test:

• that we get 401 when no authentication is passed
• that we get 401 when invalid authentication is passed
• that we get a 201 response when valid authentication is passed

Similarly, we could test a mixin by doing something like:

require 'test_helper'

class TestClass
  # mixin that I want to test
  include TheMixin
end

Then we can test that TestClass has the behavior that we are looking for when TheMixin is included in it. This would logically extend to other classes that include TheMixin in our application.

Behavior

The above tests get us pretty far. Depending on the importance of the code working correctly, this might be enough.

Tests like these don’t assure that the middleware or mixin handles all of the logic when it is used each time. There might be conflicts with the way that we import it (maybe two methods have the same name), or we might forget to import or include it at all. There are a few ways to get around this.

The first method of solving this problem is through the use of conventions. I usually try to structure the application so that all controllers that need authentication will use the authentication without much thought. Making their routes start with a similar prefix (/api/*) is one way to handle this, and you can specify exceptions (for the login API, for instance.) Another approach is to have the controllers extend a base class that specifies the authentication.

A second way of approaching this is to test whether the class or module includes the mixin we want. This is less verbose and faster than testing all of the methods, but it can be brittle if the functionality moves to a different location. We might be asserting that A includes B, but really the functionality that A should have has moved to C.

The last way is to use something like RSpec’s shared examples to ensure that the module does what we think it should do. Shared examples are basically a fancy way of saying “this class should have all of these behaviors.” Under the hood, Rspec runs the same tests for each test that says it behaves like the shared example. This results in N runs if there are N tests that use a given shared example. So these could be prohibitively expensive to run, but are the most accurate and are still easy to define.

Hope this helped!

I like testing, and since I have done it for a while, I am happy to share what I know. Did you like this post? Would you like more posts that explore testing? What are areas that are hardest for you to test?

I have been looking for a lightweight solution to split test static sites. This blog is a static site generated with Jekyll, and I want to run experiments that might help people get more value out of the things that I publish here. For example, I think the current email subscription call to action is pretty weak, so it would be useful to try to run an experiment around it. Also, I want to beef up my experimental design skills and this seems like a low-risk way to do it.

In this post I’ll tell you how I evaluated a few different options for split testing and why I decided to fork one and open source it.

A potential solution

To start, I didn’t want to use something that required me to set up a server, and I’m guessing that the overall amount of testing won’t require a fancy dashboard. If those were the case, Sixpack seems like an interesting approach.

I found a library called ABalytics that uses Google Analytics to set up split tests. At first, it seemed like ABalytics did everything that I wanted:

• you can specify split test experiments to run
• there can be multiple experiments running at a time
• it stores the tests in an analytics service (Google Analytics)
• it runs with vanilla JavaScript on the client
• there is no server component
• it stores which variant the user has seen and presents it to them if they come back

However, after installing and playing around with it, it seems like the mechanism for how it works in Google Analytics (“Custom Variables”) doesn’t seem to work any more. I think Google Analytics changed the way that they handle these custom variables. Also, it was hard to test since Google Analytics doesn’t really work unless it is on your production site and there is high latency between when you send an event and when Google Analytics reports the event.

Changing ABalytics to use Heap

I considered rolling my own static site split testing framework, but was pretty happy with the feature set of ABalytics. So I decided it would be easiest to fork it and change it to work with Heap Analytics instead.

Heap seems to be a good competitor to Google Analytics. One of the most powerful features of Heap that it stores all of the actions that the user took, and you can retroactively set up events and funnels for tracking the events. So you don’t need to know exactly what you want to track, you can figure this out when you actually want to know it. This seems to be really helpful because unnecessary setup is a large form of waste. Also, you won’t lose days or weeks of data by forgetting to track something important.

Heap tracks most of the same things that Google Analytics tracks, like browser type, number of visits, sessions by a particular user, referral information, and so on. Events that you send to Heap show up almost immediately, so it’s easier to experiment with.

Digging in

First, I had to consider the license of the original code. Since ABalytics uses the MIT license, licensing was not an issue. I just added another copyright line with my information since part of the license requires retaining the existing license when distributing. I don’t think that I would need to change the license if I was using the code for just my site, but it seemed like it would be easy to open source my changes so I wanted to do that. This has the benefit of sharing my work with others and also potentially getting outside improvements.

The key change was changing from using Google Analytics to using Heap. I needed to tell Heap what experiments were being run for the user viewing the page. If we send the experiment information as event properties for the user, all events sent to Heap will be associated with this experiment information. To do this, we just set up a hash with the experiment data and send it to Heap:

HeapWrapper.prototype.recordExperiment =
        function (experimentName, variantName) {
    var properties = {}
    properties['experiment_' + experimentName] = variantName;
    this.heap.setEventProperties(properties)
};

I figured since Heap would potentially get a lot of event data, that I would prefix any experiments with experiment_ before sending.

How it went

I successfully resisted the desire to change a bunch of things, since I didn’t know whether my approach would work at all and I wanted the diff to be as small as possible. I reasoned that I could change the code to my liking after I had a good solution locally and pushed up. I tested the changes locally, and it seemed to come together quickly.

Heap sets up a development and production environment by default, and they are switchable by setting a variable. With this, I am able to test locally and won’t impact my production data. I have a client snippet that looks at the location and uses the production environment identifier if it is running on my blog and otherwise uses the development identifier. This keeps complexity down by not needing to know the environment when building the site.

The source is available at the HeapAB repo. The instructions in the README should be enough to get up and running, but let me know if you run into anything that is tough or could be explained better. I’d like to add a few features and clean it up, but it should be helpful for people today.

I’m not currently running any split tests, but am looking forward to using this library for improving this blog.