Anthony Panozzo's Blog

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.

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:

I was taking a look around the Mozilla Developer Network site to learn more about HTML elements. While doing so, I saw a few that I either didn’t use or thought that I could be using more and wanted to share with you. For each, I’ll post what it is and why you might consider using it more in your code.

Why would you do such a thing?

I think this is interesting because even while I do web development quite a bit, there are always new things coming out. While I might have been familiar with elements a few years ago, the built-in tags are evolving. (I tried to avoid tags in this post that were not supported by most browsers.)

This actually applies to many areas of learning and knowledge. What we think we know ends up being inaccurate or incomplete, so we need to continually review and reevaluate what we know.

The main recurring theme in this post is that more accurate tags allow us to capture the semantics of the content that we have in them. When we use semantic tags, we give a deeper understanding of what the content actually means. Search engines and other automated tools can get a better understanding of our website, and while we are working with it, we also can understand the intent more clearly.

With HTML5, we can create any tag we want. By seeing what tags are already there, we avoid reinventing tags. Also we can get ideas for semantic tags that we can create in our own projects.

Tag, You’re It!

<address>

I like this tag because it is pretty common to put an address on a web page (maybe in the footer or on a contact/about page.) But instead of putting it in a <div> or something, this tag allows us to be semantic about the address.

I just finished up the Fluent Forever book by Gabriel Wyner and thought it was great. I’m interested in learning Spanish, and I like the approach that the book takes. It has solid advice and is backed up with some research citations.

In this post I’ll break down my key takeaways from the book and the accompanying website which has rich videos. Check out Derek Sivers’s post for an in-depth review.

Spaced repetition is key

Consistent spaced repetition underpins the entire system. I won’t go into heavy detail in this post, but it is basically a way to create flash cards that you see at the optimal time for retention. An algorithm determines how often you will see cards, so you only review cards that you actually need to review. By setting up small cards that you can review, you can learn and retain a lot of information.