Anthony Panozzo's Blog

Today I want to share a tool that I have found indispensable for finding and fixing intermittent tests in test suites. It's a little script I wrote, called ntimes.

Based on the commit logs to my dotfiles repository, until about 2014, to run the same command many times, I would press up in my terminal and press enter. While effective, this approach has the disadvantage of requiring me to be present at the machine and do manual work. I thought: there must be a better way.

So, probably by cribbing from somewhere and adding my own extensions, I made a script that could run an arbitrary command-line command multiple times and report a summary at the end. To use it, I would use something like:

In our Slack organization and Github pull request review, I have noticed a small pattern of using parentheses to soften or clarify the statements that we make. Sometimes it used by someone in a position of authority to emphasize that a comment is an idea, not a directive. Other times, it represents that things are not critical to address, but might be something that we want to look into.

I originally wanted to call this post "The Shipley Parenthetical" since Kyle uses it all of the time. Didn't know if he thought of it this way / approves though. :)

In this post I'll give a few examples of how this works and some thoughts on it.

Example 1

Just capturing a thought that would be helpful or is on the commenter's mind, but wanting to be clear that there is no specific action item around this.

Although I wrote about how automatically turn the internet off at night, sometimes my schedule shifts later or I am trying to get some side project work done and want to burn the midnight oil. In this post I'll cover what I consider the best tools for an evening computer work environment.¹ So what can you do besides changing your text editor colors?

Chrome

I use Chrome for my browser since it has many extensions and doesn't seem to eat up memory at this point. For the nighttime setup I'm using one extension to make the new tab page black, and another to make most other pages dark.²

Dark Reader

To make most pages inverted and dampened, I highly recommend the Dark Reader Chrome extension.³ It is excellent. Sites look as good or better than their brighter counterparts. Github diffs in particular look really good. Here's a screenshot of it in action:

Dark Reader has several hue and brightness settings that you can change (see right image), and you can toggle it globally or for a particular website. Generally I just turn it on globally with alt+shift+d at night and turn it off in the morning with the same shortcut.

Recently I finished up some shell functions that help me with some common git and testing workflows. They are up on Github, but I wanted to call them out since they might be helpful to others and just making something open source does not mean that it is discoverable. I think the philosophies are pretty solid even if you use different tools. You could use similar functions if you are using Bash or ZSH.

Overview

The general problem that I am trying to solve is that different tools like RSpec, git, or RuboCop produce output in a certain format, and I often want to do things with that output. For example, I might want to re-run the RSpec tests that just failed so I can verify fixes more easily.¹ However, RSpec outputs in a certain format that is not easily consumable. For example:

...
Failed examples:

rspec ./code/fail_spec.rb:2 # something failed
rspec ./code/fail_spec.rb:8 # yet another failure
...

If I want to re-run these two tests, I could copy the two lines and paste into my terminal. This would have a couple of downsides though. One is that I would need to spin up one RSpec process for each test that failed. This is time-prohibitive if the project loads the Rails environment. It also prevents me from getting a reliable list of the tests that failed so I can repeat this process. Last, I'd like to ideally use a faster test runner like Zeus or Spring. So my real goal is to re-run the failing tests as quickly as possible.

One approach that I took for a few years was to copy the output, paste it into an editor (Vim), and then do some macros or other commands to munge it into the format that I want. However, this is time-consuming and potentially error-prone. It is also usually wasteful since I need to do it each time that I want to transform the output to a particular format, and often I don't have the editor macros saved. It can be nice to have the list of tests to retry in an external editor to be able to check them off, but I prefer to not need the intermediate step.

Solution

The specific solution I made to solve this problem was to create a shell function that I called respec:

# copy the rspec failures, and this will rerun them as one command
function respec() {
  pbpaste | \
    cut -d ' ' -f 2 | \
    sort | \
    xargs rspec
}

First, I manually copy the tests that I want to run again. Using iTerm2, it is as simple as selecting the failure summary text since selections are automatically copied to the clipboard. pbpaste then echos the contents of the system clipboard. From there, we want a list of the tests that failed so we can run them again. The format of failing tests are:

After completing a project at work that used the Redux state container, I gave a presentation to the local JavaScript meetup group about my understanding of Redux and showing how it works in the app that we built.

(Slides no longer available.)