Anthony Panozzo's Blog

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.

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.

<code>

This tag is more common. Again, using it is more semantic than using something like a <pre> tag for displaying monospaced text. It signifies that the contents are computer code.