Anthony Panozzo's Blog

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.

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.

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:

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:

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.