I play Ultimate¹. While throwing and catching are an integral part of the game, I don’t see most players work on strengthening their grip or forearms to make their catches and throws better. At some point I randomly saw an article for baseball pitchers to strengthen their grip and thought that this could be useful to Ultimate players. So, I bought a five gallon bucket and filled it with rice and tried it.

While doing the workouts, I can definitely feel that my forearms and hands get tired. Within a few days, I feel that I can make more difficult catches, have better hand and forearm agility, and get a tighter grip on the disc for hucks (long throws, in Ultimate parlance.) I try to be more careful to be gentle while typing, since my forearms feel slightly inflamed and I don’t want to have any carpal tunnel issues.

Here is the workout I follow, which usually takes less than ten minutes. I definitely recommend watching the video from the link above, since it explains most of the setup and exercises. I took out some things from the workout that related specifically to pitching, and added a few things that might help with Ultimate-specific movements. I usually only do ten to twenty repetitions of each exercise. You will be sore for a day or so after doing it, at least the first few times. Don’t overdo it!

With Left And Right Hands, Individually

Grab the rice at the top of the bucket: I treat this like a warm-up. Just grab the rice at the top of the bucket and pull it up and release it.

Grab the rice at the bottom of the bucket: Dig a bit deeper when grabbing the rice and pull it up like above.

Grab the rice like your hand is a crab pincher: This is a good workout for the hands, and mimics the hand mechanics of one-handed grabs.

Use only the thumb movement in the crab pincher: This is a good workout for the thumb muscles. Your video game controller skills will be on point after doing this.

With a fist go in circles both ways in the rice: This definitely gives the forearms a workout, since the hands are not active.

With a fist go side to side in the rice: Some more forearm workout.

With a fist go up and down in the rice: This does not refer to pulling the rice up and down, but rotating the fist up and down.

Pretend you are throwing a backhand, in the rice: This is a new one. Works the wrist muscles that you would use for throwing. Be sure to use both hands to strengthen both and to work on your non-dominant hand strength.

Pretend you are throwing a forehand, in the rice: This is a new one. Similarly, this strengthens your forehand throwing muscles (outside of the wrist) and whichever fingers you use for throwing forehands.

Pretend you are throwing a hammer/scoober, in the rice: This is a new one. This works on your outside wrist muscles and finger muscles at a different angle.

Handshake while in the rice bucket: Works the top and bottom of the wrist.

Grab the rice as hard as you can: This really works the hand strength and overall forearm strength.

Pinch the rice as hard as you can: Again, this works those hand muscles for pinch grabs.

Flick your fingers outward while totally submerged in rice: This is surprisingly hard. I’m not sure what Ultimate exercise this mimics, but it’s probably good to have balance.

With Both Hands Simultaneously

Simulate pinch grab with fingers on top, into the rice: This is a new one. This exercise works on syncing up the hands for catching, while also working on strength. Pretend you are grabbing a disc that is in front of you for a few, and then one that is above your head if you can get the angle correct.

Simulate pinch grab with fingers on bottom: Another simulation (grab at knees)

Optional

Forearm curls with rice bucket: Take the bucket at your side and do some forearm curls.

Shoulder shrugs with the bucket: Similarly, grabbing the bucket and doing shoulder shrugs on each side works to strengthen your shoulder muscles (so you don’t get tired lugging your stuff around at tournaments.)

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?