msol

Mac productivity tips for developers

2019-06-15T04:50:13-07:00

Working faster

Software developers spend hour after hour on their machines, so it’s worth spending a little time improving common workflows now and then.

The time you can spend on this is virtually unbounded, but I have found there are a few tricks that many people miss—a handful of high-value improvements that can go a long way without hours of investment.

Some of these improvements require extra software, (all of it free and open source) and there’s a section at the bottom to set that up when needed.

1: The “Hyper” key + transform Caps Lock into Escape

You know what would be great? Having an extra modifier key open for whatever we want.

We can make use of Steve Losh’s idea of emulating the extra “Hyper” key introduced by the Space Cadet keyboard by defining Hyper as control+option+command+shift. Since no sane application will expect a user to hold all those keys at once, we can effectively create a new modifier key.

My primary use for Hyper is machine-global shortcut keys, especially for window management with Hammerspoon.

Vim users often remap caps lock to Escape to save their pinky finger some pain. We are going to do that too–but only when tapped. That way, we can user Hyper and Escape on the same key, without them interfering.

Setup

First install Karabiner Elements.

Then, install this karabiner configuration.

Alternatively, you can download this file and add it by hand to the complex modifications section of ~/.config/karabiner/karabiner.json.

Now that that’s done, it’s time to set up some shortcuts that use Hyper in order to ease window management.

2: Managing windows with Hammerspoon

Hammerspoon is a macOS swiss army knife. I mostly use it for window management, not unlike other tools like Divvy or SizeUp. It lets you arrange, resize, switch between, and open applications and windows on one or more monitors.

By setting up a few basic commands in Hammerspoon, switching between and resizing windows in macOS becomes much faster. I have a simple set of related commands that are easy to learn and use, but improve my daily efficiency manyfold.

First, I have the 10-15 most common applications I use bound to Hyper + a single key, such as Hyper+space to open my editor. Next, I have shortcuts for window movement and resizing for the active window: full-screen, two half-screens, four quarter-screens, one to cycle the application between monitors, and one to cycle between instances of the same application.

Mastering these commands is enough to work extremely efficiently, but I have a few others included that I find useful as well.

Setup

First install Hammerspoon. Then open up ~/.hammerspoon/init.lua and add this:

-- Mike Solomon @msol 2019 local log = hs.logger.new('main', 'info') DEVELOPING_THIS = false -- set to true to ease debugging HYPER = {'ctrl', 'shift', 'alt', 'cmd'} -- App bindings function setUpAppBindings() hyperFocusAll('w', 'React Native Debugger', 'Simulator', 'qemu-system-x86_64') hyperFocusOrOpen('e', 'Notes') hyperFocus('i', 'IntelliJ IDEA', 'IntelliJ IDEA-EAP', 'Xcode', 'Android Studio', 'Atom', 'Code') hyperFocusOrOpen('a', 'Finder') hyperFocusOrOpen('x', 'Calendar') hyperFocusOrOpen('m', 'Messages') hyperFocusOrOpen('r', 'Slack') hyperFocus('t', 'Safari') hyperFocusOrOpen(';', 'iTerm2') hyperFocusOrOpen('s', 'OmniFocus') hyperFocus('f', 'Google Chrome', 'Firefox') hyperFocusOrOpen('space', 'Sublime Text') end -- Window management function setUpWindowManagement() hs.window.animationDuration = 0 -- disable animations hs.grid.setMargins({0, 0}) hs.grid.setGrid('2x2') function mkSetFocus(to) return function() hs.grid.set(hs.window.focusedWindow(), to) end end local fullScreen = hs.geometry("0,0 2x2") local leftHalf = hs.geometry("0,0 1x2") local rightHalf = hs.geometry("1,0 1x2") local upperLeft = hs.geometry("0,0 1x1") local lowerLeft = hs.geometry("0,1 1x1") local upperRight = hs.geometry("1,0 1x1") local lowerRight = hs.geometry("1,1 1x1") hs.hotkey.bind(HYPER, 'l', mkSetFocus(fullScreen)) hs.hotkey.bind(HYPER, 'h', mkSetFocus(leftHalf)) hs.hotkey.bind(HYPER, "'", mkSetFocus(rightHalf)) hs.hotkey.bind(HYPER, "y", mkSetFocus(upperLeft)) hs.hotkey.bind(HYPER, "b", mkSetFocus(lowerLeft)) hs.hotkey.bind(HYPER, "u", mkSetFocus(upperRight)) hs.hotkey.bind(HYPER, "n", mkSetFocus(lowerRight)) hs.hotkey.bind(HYPER, "up", hs.window.filter.focusNorth) hs.hotkey.bind(HYPER, "down", hs.window.filter.focusSouth) hs.hotkey.bind(HYPER, "left", hs.window.filter.focusWest) hs.hotkey.bind(HYPER, "right", hs.window.filter.focusEast) -- hs.hotkey.bind(HYPER, "v", hs.window.filter.focusNorth) -- hs.hotkey.bind(HYPER, "c", hs.window.filter.focusSouth) -- hs.hotkey.bind(HYPER, "j", hs.window.filter.focusWest) -- hs.hotkey.bind(HYPER, "p", hs.window.filter.focusEast) hs.hotkey.bind(HYPER, "q", hs.hints.windowHints) -- HYPER "d" -- Bound in Karabiner to Cmd+Tab (application switcher) -- HYPER "k" -- Bound in Karabiner to Cmd+` (next window of application) -- throw to other screen hs.hotkey.bind(HYPER, 'o', function() local window = hs.window.focusedWindow() window:moveToScreen(window:screen():next()) end) end -- focus on the last-focused window of the application given by name, or else launch it function hyperFocusOrOpen(key, app) local focus = mkFocusByPreferredApplicationTitle(true, app) function focusOrOpen() return (focus() or hs.application.launchOrFocus(app)) end hs.hotkey.bind(HYPER, key, focusOrOpen) end -- focus on the last-focused window of the first application given by name function hyperFocus(key, ...) hs.hotkey.bind(HYPER, key, mkFocusByPreferredApplicationTitle(true, ...)) end -- focus on the last-focused window of every application given by name function hyperFocusAll(key, ...) hs.hotkey.bind(HYPER, key, mkFocusByPreferredApplicationTitle(false, ...)) end -- creates callback function to select application windows by application name function mkFocusByPreferredApplicationTitle(stopOnFirst, ...) local arguments = {...} -- create table to close over variadic args return function() local nowFocused = hs.window.focusedWindow() local appFound = false for _, app in ipairs(arguments) do if stopOnFirst and appFound then break end log:d('Searching for app ', app) local application = hs.application.get(app) if application ~= nil then log:d('Found app', application) local window = application:mainWindow() if window ~= nil then log:d('Found main window', window) if window == nowFocused then log:d('Already focused, moving on', application) else window:focus() appFound = true end end end end return appFound end end function maybeEnableDebug() if DEVELOPING_THIS then log.setLogLevel('debug') log.d('Loading in development mode') -- automatically reload changes when we're developing hs.pathwatcher.new(os.getenv('HOME') .. '/.hammerspoon/', hs.reload):start() hs.alert('Hammerspoon config reloaded') log:d('Hammerspoon config reloaded') end end function setUpClipboardTool() ClipboardTool = hs.loadSpoon('ClipboardTool') ClipboardTool.show_in_menubar = false ClipboardTool:start() ClipboardTool:bindHotkeys({ toggle_clipboard = {HYPER, "p"} }) end -- Main maybeEnableDebug() setUpAppBindings() setUpWindowManagement() setUpClipboardTool()

Then run Hammerspoon (or “Reload Config” from the menu bar icon).

The configuration file is pretty easy to read with a little effort. If you set up the Hyper key, then this file should just work for you, and I find these particular settings to be very useful.

3: Tap shift to move over words

I find that moving my cursor word-by-word is very useful even outside my text editor. OS X provides line-editing shortcuts similar to Readline/Emacs, for example Control+a to jump to the beginning of a line and Control+e to jump to the end (which I recommend you use). Even better is to do this without a modifier key!

Inspired by a similar idea about parens from Steve Losh, notice that tapping your shift key normally does nothing, and you rarely do so. Instead, why not tap left-shift to move one word to the left, and tap right-shift to move one word to the right?

I find this very useful for moving short distances in text of all kinds, and it soon becomes second nature.

Setup

First install Karabiner Elements.

Then, install this karabiner configuration.

Alternatively, you can download this file and add it by hand to the complex modifications section of ~/.config/karabiner/karabiner.json.

4: Right-thumb control key

How often do you use the right-side command key? Never.

Instead of wasting that key, why not turn it into a control key? Control is very useful if you spend time in the terminal (iTerm2 is great) so you can do e.g. control+p to get the previous command, or control+r to search previous commands.

You press this key by curling your right thumb. It may feel unnatural at first, but before long the relief on your left pinky will be palpable.

Setup

First install the excellent Karabiner Elements.

Then open it and under “Simple Modifications” change the “From key” right_command and the “To key” to left_control. Done!

5: Ctrl+W deletes the previous word

When you make a typing mistake, it is often faster to rewrite the entire last word than to repeatedly press backspace to erase the typo. I find this to be much more efficient overall. Emacs users will already be familiar with the choice of Ctrl+W.

Setup

First install Karabiner Elements.

Then, install this karabiner configuration.

Alternatively, you can download this file and add it by hand to the complex modifications section of ~/.config/karabiner/karabiner.json.

This works especially well with the right thumb control key.

6: A better shell with oh-my-zsh

Most people use Bash for their shell. Assuming you spend some time in the terminal, you probably already know your way around Bash pretty well. Sadly, Bash has limited capabilities, especially for command completion. Other shells, like Zsh, offer more but can be unfamiliar.

Enter oh-my-zsh: a layer of frosting on top of the powerful Z-shell that makes it Bash-compatible and adds a self-updating system of plugins and themes. You will find your autocomplete much improved as well as available niceties like changing directories by typing directory names without cd, and a very nice default prompt.

Oh-my-zsh also opens the door to more powerful customizations, and boasts an active community of people who have often already implemented features you wish your shell had.

Setup

First install Zsh. If you use Homebrew—which I hope you do—then simply brew install zsh. You will also need Git (brew install git). Then just run the curl-to-shell command from oh-my-zsh’s setup instructions, open up ~/.zshrc and enable a few plugins by adding them to the plugins=( ... ) array you’ll see in that file, and you’re done! Be sure to open a new terminal window to see your changes.

7: Syntax highlighting in the terminal

I love syntax highlighting because it lets me catch errors in my code as I type. Why not have the same thing for my bash commands in the terminal?

This syntax highlighting makes valid commands yellow, invalid commands red, highlights strings, and underlines valid file paths.

Setup

This one requires oh-my-zsh as seen in the previous tip. Syntax highlighting is an oh-my-zsh plugin, but it doesn’t come bundled by default.

Run the commands

mkdir ~/.oh-my-zsh/custom/plugins
git clone git://github.com/zsh-users/zsh-syntax-highlighting.git ~/.oh-my-zsh/custom/plugins/zsh-syntax-highlighting

to install the plugin. Then open up ~/.zshrc and add zsh-syntax-highlighting to the end of the plugins=( ... ) array. Open up a new terminal and enjoy your syntax highlighting!

8: Faster key repeat

OS X defaults to a very slow key repeat rate, but it also doesn’t let you lower it enough to please me in System Preferences. This often comes in handy for moving short distances in text.

Setup

You can customize this by running commands in your Terminal.

Here are the settings I use, that I got from somewhere online (fractional values do not work). You may need to log out and back in to see them applied.

defaults write -g InitialKeyRepeat -int 10 # normal minimum is 15 (225 ms)
defaults write -g KeyRepeat -int 1 # normal minimum is 2 (30 ms)

9: File-searching aliases

Many terminal users set up aliases to shorten common tasks, such as alias gc='git commit' so that the whole command doesn’t need to be typed. You should of course set up custom aliases, but there are two in particular that I find useful quite often.

The first is f, which searches the current directory subtree for files with names containing a string (ignoring case). f png would find all PNG files in the current subtree, as well as “PNGisMyFavorite.txt” and so forth.

The second is r, which recursively greps the current directory subtree for files matching a pattern. r HTTP would grep for files containing that exact string, while r '"http[^"]*"' -i would search for double-quoted strings starting with “http”, ignoring case.

Setup

We will actually implement these as Bash (or Zsh) functions or aliases in ~/.bashrc or ~/.zshrc. Just add these lines anywhere in the file appropriate to your shell:

Software

Some of these improvements require software. Here are some of the most important.

Karabiner Elements

Karabiner lets you rebind keys, key combinations, trackpad gestures, set key delays, and more. It allows customization through a GUI, or a configuration file which lives at ~/.config/karabiner/karabiner.json.

Hammerspoon

Oh My Zsh

Oh My Zsh makes it easy to get a great shell configuration, making your work in the terminal much better. It is community maintained and has many plugins.

More resources

I tried to hit high-value improvements that I don’t think most people already have, but there is a whole world of deeper customization out there. Here are some links to resources I’ve found useful:

Toward a more useful keyboard, Jason Rudolph
A Modern Space Cadet, Steve Losh
Holman does dotfiles, Zach Holman
Hammerspoon documentation
Karabiner Elements options

Nietzsche would write clickbait

2016-01-08T07:24:05-08:00

Nietzsche’s style is outrageous.

He denies morality and immorality. He criticizes popular religions like Christianity and Judaism, popular moral philosophies like utilitarianism, and popular virtues like modesty¹.

His language is evocative and exaggerated. As Higgins & Solomon² point out:

… it is evident that he was willing to be misunderstood if that was the price of attracting our attention.

and go on to cite Nietzsche’s biblical tone in Thus Spoke Zarathustra among other things.

That sounds as close to clickbait as things got in the 19th century. And spreading new ideas, generating ad revenue—what’s the difference, anyway?

gutenberg.org/files/4363/4363-h/4363-h.htm, § 265 ↩
p. xxv, Introduction to Thus Spoke Zarathustra, Barnes & Noble 2005. ISBN 978-1-59308-278-9.

I have no relation to Robert C. Solomon. ↩

Dirt-cheap client-encrypted online backups with Raspberry Pi

2016-01-07T01:01:51-08:00

To be useful to me, backups must be:

Stored in a reliable and offsite location
Readable only by me (client-side encryption)
Cheap
Automatic

We can achieve all of these goals with a combination of tools:

Duplicity
Google Nearline
GPG
Raspberry Pi

I have been using this setup for about a year, and it costs me about $2 a month for about 100 GB of backups.

The Raspberry Pi is very useful because it uses very little power and can backup my Network Attached Storage (NAS) automatically over the network.

Aside: backing up a computer

You should strongly consider using Backblaze¹. It’s cheap, has no storage limit, and lets you use your own encryption key. It’s going to be the simplest and most reliable bet if you only need to backup the computers you use frequently, instead of your NAS.

Backing up your NAS, or multiple computers

There are five basic steps we need to get backups running:

Set up the storage service: Google Nearline
Set up the connection to the files to be backed up: sshfs
Set up encryption software: GPG
Configure the backup software: Duplicity
Run the backups on a schedule: cron

Set up Google Nearline

Go to the Google Developer’s Console, and sign up as necessary. You may need to enter billing information. Create a new project on that page, perhaps called duplicity-backups.

Click on the duplicity-backups project and click the hamburger menu (three lines) button in the upper left corner and select “Storage” under “Storage.” Press “Create bucket” and choose a name (perhaps “photos”) and select “Nearline” for “Storage class.”

The last piece needed is access credentials for this storage bucket. Press Settings on the left, then click Interoperability. Create a new key, then copy down the Access Key and Secret shown. We will use these later.

Mounting via SSH

You will need to access the files you wish to backup (likely located on your NAS) over the network. I will assume that they are reachable via SSH. If they are not, you will need to mount them on the filesystem in a similar way (perhaps with NFS).

Run sudo apt-get install sshfs to make mounting drives over SSH possible.

It will be easier to connect to your NAS via SSH if you use passwordless authentication with a public/private key pair. Run ssh-copy-id nasuser@mynashost to copy it, substituting in your actual NAS information.

Run mkdir ~/nas to create a place to mount your NAS directories.

Add lines like this to /etc/fstab so your Raspberry Pi can treat the remote host as a drive:

root@mycroft:/my-nas/Photos /home/pi/nas/Photos fuse.sshfs      user,delay_connect,noauto,_netdev,uid=1000,gid=1000,idmap=user,allow_other,reconnect 0 0
root@mycroft:/my-nas/write /home/pi/nas/write fuse.sshfs      user,delay_connect,noauto,_netdev,uid=1000,gid=1000,idmap=user,allow_other,reconnect 0 0

And test it with sudo mount /home/pi/nas/Photos, verifying that the files appear in that directory as expected.

I recommend that your create a second partition directory on your NAS (separate from that which you wish to back up) to store Duplicity’s local cache and log files. Otherwise, you are likely to quickly fill your Raspberry Pi’s local storage. This directory is called “write” in my examples. Run touch /home/pi/nas/write/.useThisWriteDir after it is mounted to use with the script below.

Set up GPG and your encryption keys

GPG is supported by Duplicity for encryption, and provides a high level of security.

Run sudo apt-get install gnupg. Then run gpg --gen-key and follow the prompts, choosing the defaults. Be sure to choose a long (ideally random) passphrase and to write it down (preferably in a password manager). You won’t be able to read your backups without the generated keys, so be sure to back that up as well.

We will need the fingerprint of the newly-generated key to tell Duplicity to use it. Run gpg --fingerprint to see it. gpg --fingerprint | grep pub | grep -P "(?<=/)\\w{8} " should highlight the 8-character fingerprint you require.

Set up Duplicity and the backup script on your Raspberry Pi

These instructions assume you use Raspbian. They should be adaptable for use on other Linux (or Linux-like) systems.

Install duplicity by running sudo apt-get install duplicity.

A simple backup script is needed to store credentials and run the backup. I store it along with the files I wish to backup (Photos), but you could do something more secure instead.

#!/bin/sh
# stored in Photos, the directory I wish to back up

export SRC=/home/pi/nas/Photos
export DEST=gs://<your Google Cloud Storage bucket name>/Photos

export FTP_PASSWORD="<password>"
export GS_ACCESS_KEY_ID="<your Google access key>
export GS_SECRET_ACCESS_KEY="<your Google secret>"

export KEY="<your GPG key fingerprint (8 characters)>"
export PASSPHRASE="<your GPG passphrase>"

# Locking is handled by cron. This has helped it restart after problems.
killall duplicity
find /home/pi/nas/write/.cache/duplicity/ | grep lockfile.lock | xargs rm

# make sure we're using the right write dir.
# remote mounting issues can otherwise cause problems
if [ ! -f /home/pi/nas/write/.useThisWriteDir ]; then
  echo "write directory does not appear to be mounted"
  exit
fi

duplicity \
  --sign-key $KEY \
  --encrypt-key $KEY \
  --log-file /home/pi/nas/write/duplicity.log \
  --archive-dir /home/pi/nas/write/.cache/duplicity/ \
  "$SRC" "$DEST" 2>&1 >> /home/pi/nas/write/duplicity-foreground.log

Run the backup script on a small test directory to make sure it’s all set up properly.

Scheduling backups with cron

The last step is to run this backup automatically. Cron can do this for us, and is built-in.

We will use a simple perl script to keep things from running multiple times. Download it to /home/pi and make it executable with chmod u+x /home/pi/solo.pl.

Run crontab -e and add these lines:

# m h  dom mon dow   command
* * * * * grep -qs '/home/pi/nas/write' /proc/mounts || /home/pi/solo.pl -port=3386 mount /home/pi/nas/write
* * * * * ls /home/pi/nas/write || /home/pi/solo.pl -port=3386 sudo umount -f -l /home/pi/nas/write
* * * * * grep -qs '/home/pi/nas/Photos' /proc/mounts || /home/pi/solo.pl -port=3385 mount /home/pi/nas/Photos
* * * * * ls /home/pi/nas/Photos || /home/pi/solo.pl -port=3385 sudo umount -f -l /home/pi/nas/Photos
* * * * * grep -qs '/home/pi/Drive' /proc/mounts || /home/pi/solo.pl -port=3384 mount /home/pi/Drive
* * * * * /home/pi/solo.pl -port=3383 sh /home/pi/nas/Photos/backup.sh > /dev/null 2>&1

# optional: automatic reboots and software updates to keep things well-oiled
0 5 * * * ssh mynasuser@mynas 'reboot'
0 5 */2 * * sudo /sbin/shutdown -r +1
0 6 * * * sudo rpi-update
0 7 * * * sudo apt-get update -y && sudo apt-get upgrade -y
0 10 * * * sudo apt-get autoremove -y && sudo apt-get autoclean -y && sudo apt-get clean -y

This will start a new backup as soon as the last completes. This works well for my use case, adjust as necessary.

Be sure to test your backups to ensure you can restore in a disaster! duplicity verify may help you here.

Future improvements

This could be improved with emails about failed backups, or when backups haven’t run for some time. The overall process could also be simpler. Ideas? Let me know in the comments and I can update the article with them!

I have no affiliation with Backblaze. ↩

Pro-style testing

2015-10-10T09:47:07-07:00

If you write software professionally, you probably write automated tests. This is fantastic.

But have you ever thought about how to leverage the experiences of other software engineers to:

Write tests that are maximally likely to prevent bugs
Write tests that make locating and fixing the cause of a bug easy
Write as few (and as short and readable) tests as possible while achieving the above

Below are general guidelines to build a mental framework of what, how, and why to test in any language. There are also specific and hard-earned recommendations for and against a variety of possible testing strategies. Most recommendations come with links to more reading.

If you want to test like a pro, read on. If you disagree with a recommendation or would like elaboration, leave a comment or send me an email. There is always room to improve.

Table of Contents
Terminology
- Test sizes
- Properties of tests
General principles to follow
Mistakes to avoid
- Don’t write change-detector tests
- Don’t test code you don’t own in Small or Medium tests
Red flags and code smells
Concrete tips
More about testing
Reading and resources

Terminology

Language around automated testing is often ambiguous and overloaded. I will use these terms:

Test sizes

Terms like “unit test” and “integration test” can mean different things to different people, so we will use test sizes as defined by Google, recapped here:

Small: Usually called unit tests, Small tests are each extremely narrow in scope, run quickly, and test behavior in isolation.
Medium: Sometimes called integration tests, Medium tests check interactions between layers and components.
Large: Also called end-to-end or system tests, Large tests are very coarse-grained and often touch many components and make use of the network.

Properties of tests

Fidelity: A high-fidelity test is sensitive to defects in the code under test: the test fails when the code is broken.
Resilience: A resilient test fails only when the code under test is broken–refactoring won’t break it, and it is not flaky.
Precision: A high-precision test tells you where the defect is. Ideally the exact line number and what differed from our expectations.

General principles to follow

Test one behavior per test

Each test should test one behavior. Many of your methods will have one behavior, so verify that behavior and as little else as possible (often nothing!). Asserting runtime invariants is okay, but usually there should be few assertions other than the primary expected behavior.

Test each behavior once

Testing the same thing more than once is a maintenance burden. Obviously you should not test the same behavior with two separate tests, but sometimes it is tempting to “cross-test” by adding an extra assertion in a related test. Avoid this, because it decreases the Precision when the test fails, and because it violates “Test one behavior per test.”

Too Many Tests

Write tests that provide value by reducing risk

A test should reduce risk, or it is not providing any value.

One way to check this is to ask “what class of bug could this test detect?” If there is no answer, there should be no test. You can rephrase as “what risk does this test help us avoid?”, and if there is no answer, you need no test.

It works the other way too: think of what the risks (possible classes of bugs) are, and write the appropriate tests to detect them.

One case that obviously provides value is a regression test: you’ve encountered a bug before, so it’s important to have a test to prevent it from reappearing in the future.

Name tests to describe the behavior precisely

Test names appear in test failures and in the code itself. If the names precisely describe the behavior being tested, readers do not need to read the test to understand what cases are covered and which aren’t, and failures become easier to debug and fix.

Tests are often a good way to learn how an interface works, and clear test names can be useful to demonstrate an interface.

Writing Descriptive Test Names

Rework code until it is easy to test

You must test your code, so your code must be easy to test. If you write your code before your tests without keeping this in mind, you may not notice until you begin writing tests. When this happens, consider reworking your code to be more testable.

If your test is long, your code may need to change to improve testability.

These strategies can make your code more testable:

Ensure your methods, classes, and modules each have only one concern, one job, one reason to change. Each should deal with one thin layer only, and rely on other methods/classes/modules to deal with other layers.
Reduce the number of dependencies. Are you sure the code under test has only has one reason to change?
Use dependency injection
Avoid static methods (in Scala, look for companion objects and other objects)
Avoid singletons (in Scala, look for companion objects and other objects)
Wrap unavoidable singletons or static methods (such as those provided by a library) in a simple class that can be injected as a dependency
Inject small, single purpose methods that encapsulate dependencies–these are easy to test, and prevent overreliance on mocking

Watch it fail

It’s tempting to write a test, see that it passes, and move on. But what if you made a mistake in your test? You probably don’t have tests for your test, so instead, break your code in a way the test should detect, and run it.

This avoids two classes of bugs:

Your test won’t detect the bug you thought it would (low Fidelity)
Your tests aren’t actually being run (it happens)

Tests should use literals where possible

In production code, deduplication and flexibility are very important. Surprisingly, in tests, it is often better to duplicate and inline simple values and literals to reduce the likelihood of mistakes and to improve the direct readability of the test. Simple immutable objects shared across tests are also acceptable.

For example, URLs strings should be literal values in tests instead of being constructed as URL objects. This sort of duplication is more readable, simpler, and less error prone. In exchange, it is very inflexible–but this is a better tradeoff in a test.

See Don’t put logic in tests

This does not apply as much to property checks, which should use generators where possible.

Leverage the type system

Careful use of statically type-checked languages render entire classes of Small tests unnecessary because the type checker can enforce certain guarantees. Availability of static typing features vary by language; make use of those that are available, and consider this when choosing a new language.

Carefully choose the types of primitives so they enforce as many guarantees as possible. For instance, prefer an unsigned integer over a signed integer when a value cannot be negative; this eliminates the need for one test. This principle applies similarly to objects and other derived types. Consider introducing new types that can only be constructed with guarantees that will later be relied upon, this removes the need for checking these guarantees in the code relying on them. Consider refining interfaces to accept only values maximally verified by the type system.

A unit tester walks into a bar

Mistakes to avoid

Don’t write change-detector tests

One way to test code is to duplicate some of the logic you are trying to test in the test itself, then assert that the results are equal.

This only detects when your code changes, and cannot catch any bugs apart from “the code changed.” Such a test has low Fidelity and low Resilience. Such a test is a maintenance burden. Rewrite or delete.

One common form of change-detection is a test that checks each step of the implementation. Test behavior instead.

A very specific type of test that looks like (but is not) a useless change-detector can provide refactor/optimization safety (yet no value up until then): a test that reimplements the code under test and compares the outputs. This verifies that the underlying behavior has not changed. This type of test is easy to misapply. It is insufficient on its own. Prefer other types of tests when possible, perhaps simple property checks.

Change-Detector Tests Considered Harmful

Don’t test code you don’t own in Small or Medium tests

Tests should live in the same project as the code that they test, and should be maintained by the same people. This gives the owners freedom to refactor and make bug fixes as needed, provided their tests still pass. This lets the people best suited to test and maintain test code do so. This reduces your own maintenance burden. Note that it makes sense to test Adapter or other code that wraps a dependency.

Most dependencies will be services or libraries. If you do not trust a dependency, consider contributing new tests to cover the cases they do not. If you still don’t trust a dependency, consider removing or replacing it. If you cannot contribute to a dependency directly, consider maintaining a patch, or if necessary, consider a fork. If you have a binary or service dependency that you cannot contribute to, eliminate, or trust, consider writing a separate suite of tests to ensure it works as you expect. In no case should you test an external dependency as a side effect of testing your own code in a Small or Medium test.

Large tests may implicitly test external dependencies; this is to be expected. Even so, they should not explicitly test external dependencies beyond, say, setting up connections.

Red flags and code smells

Long tests. Tests should generally be short and easy to follow. Arrange, act, assert (see AAA below)
Sleeping (Thread.sleep, Future.sleep, sleep(), etc.). There are very few places this is actually what you want.
Many mocks (specifically mocking, not other test doubles). You may be testing the implementation too closely. The code under test may have too many dependencies, and it may have more than one concern.
The test generates nontrivial data. There may be bugs in the data generation code. Consider separating it out and testing it. Consider using a property check, which can help make this reusable. Consider breaking the code under test into multiple methods which can be tested on simpler data.
Tests with logic that also appears in the code under test. Is this a change-detector test?

Concrete tips

Hat-tip to Ryan Greenberg, from whom I stole most of this section.

AAA test structure

Many tests are easy to read if they are in the form: Arrange, Act, Assert. First Arrange the required objects, perform the Act you want to test, then Assert the results are as expected.

Write the assertion first

Think of test cases in terms of properties that must be true, then assert them. It may be easier to think of the assertion first, then write code to arrange objects and act on them.

Write exactly one test for each equivalence class

For example, if the code is intended to work the same on any number of items in a sequence, you don’t need a test for 2 items, 3 items, and 4 items.

When testing state changes, assert before as well as after

For example, if a method should increment a counter, assert that the counter value starts at what you expect before calling the method. This avoids certain bugs in tests.

Only control direct dependencies, not dependencies of dependencies

Only set up and rely on direct dependencies of what you are testing (possibly using a test double such as a stub, mock or fake), never dependencies of dependencies.

For example, imagine:

We have a request handler logValidRequests that validates a request req by calling validate(req) and then logs req
logValidRequests won’t log req when validate returns false
One way req can be invalid is if it is all lowercase

You should not write your test by calling logValidRequests with an all-lowercase req. Instead, stub validate to return false, then assert that nothing is logged (and don’t forget other test cases!). This improves Resilience and Precision.

Assert on boundaries for functions accepting a contiguous range of inputs

def isBig(num: Long) = num > 100

You should test 100, but also 99 because it is at the boundary of the change. Even better, write a property test. Remember to test each equivalence class exactly once.

More about testing

Property-based tests

Property-based tests (also called property checks) are a different way to think about testing. The basic idea is to assert that some law holds about the code under test, and then let the test framework generate test cases in an attempt to disprove the law. When it does so, it will try to find a minimal failing case to help you find your bug.

It is worth writing property checks if you can, despite the initial learning curve. They allow you to declare laws and let the computer worry about coming up with cases that are likely to fail. They encourage writing reusable Generators that improve readability and reuse.

Property-based tests are most useful in unit tests.

In Scala there is ScalaCheck and more can be found online.

Large tests

Large tests are your last line of defense before production (or “reported by users”). Not all tests are equally useful at this level.

Test “happy path” behavior. This makes sure that the system works end-to-end in the real environment. Depending on your setup, you may be able to run this in a staging environment as well as the production environment.

Test for regressions in known high-level bugs. If you can write a Small or Medium test for this, prefer that instead. However, make sure each regression gets a test, and sometimes this means a Large test.

Don’t attempt to test every way in which your system can fail. For example, if you have a suite of validations that are already tested in Small tests, do not repeat every test at the Large (or Medium) level. Instead, test one representative validation to ensure that the validations are wired in. Even better, test at the Medium level.

Refactoring tests

It can be hard to refactor your tests, because unlike your production code, you don’t have tests (for your tests).

One good strategy is to refactor your test code after manually (and temporarily) breaking the production code. This gives you some confidence that your tests fail when they ought to fail (showing their level of Fidelity).

Refactoring tests in the red

Reading and resources

More terminology

Box colors

Black box: Knows nothing of internals–testing the interface’s contract, not implementation
White box: Testing the internals–testing the implementation, not the interface
Grey box: Testing interface’s contract as in black box, but sets up state beforehand with knowledge of internals

Subtypes of tests

Regression: did a bug we fixed reappear?
Performance: how fast is the code? is it fast enough?
Security/Privacy: will this leak data or allow unwanted access?
Code quality: does the code meet standards we can automatically (statically) measure?
Acceptance: Does it conform to specifications?
Stress: How does it handle being put under increasing loads, up to failure?

Good resources

Google’s Testing Blog, including Testing on the Toilet
Clean Code by Robert C. Martin
Writing testable code

Short but valuable reading

You’re probably wrong about caching

2015-09-05T05:22:40-07:00

There are only two hard things in Computer Science: cache invalidation and naming things –Phil Karlton

Caching is a great tool. Lots of useful data fits easily in memory–so cache it! Improve your latencies, ease the load on your database, reduce your hardware costs! Can you spell free lunch?

Many of the costs of caching aren’t paid up-front. This makes caching seem very attractive–and to be clear, there are many situations where caching your data is a great option–but if you’re just looking to pick up some “quick wins,” caching is a bad place to start.

I believe we, as software developers, have a very strong tendency to underestimate the complexities and issues caching brings along with it, especially when we look at oh-so-seductive early results of exploratory caching atop our data sources. In turn, I believe we often cache before the benefits actually outweigh the costs.

Fine, why do you think caching is so hard?

I’m glad you asked.

Reasoning about cached data is harder

Caching fundamentally means that you no longer read from your source of truth. Whenever you see something unexpected in your data (say, while debugging during an incident), you now must ask “does this data match our source of truth?” Every read or write to a piece of cached data is subject to mismatch with the source of truth and this must often be taken into account when tracking down issues.

A new class of perspective bugs are possible with cached data

Not all data appears in the same way to all users. For example, a list of “Best Articles” on a news site might depend on which user is logged in. A classic caching mistake is caching these perspective-dependent values and serving them to users who should have a different perspective. This is avoidable enough once, but is easy to mistakenly introduce later on. This can lead to serious privacy or even security issues.

Reproducing behavior involving caching is harder

When you introduce caching, you also introduce a new layer in which behavior can differ from your expectations. New race conditions are possible where they weren’t before: items can expire from the cache when you don’t expect them to, which objects are cached depends on access patterns that can vary by time of day or other factors. This means that issues can appear, but it is not obvious how to reproduce them to assist in fixing them.

Access pattern changes can subtly lower cache hit rates which damages performance

When access patterns change, so can performance. A special case of this can occur when data is fronted by a cache and access patterns change. As cache misses increase, latency increases and throughput can drop. However, traffic levels may stay the same, masking the cause, and potentially overloading the underlying data source. Like any issue, this can be dealt with, but it makes dealing with certain incidents more difficult.

In-process caching in garbage-collected languages increases GC pressure¹

This only applies to certain scenarios, like in-process caches on the JVM, but it serves as another example of how caching can introduce unexpected issues. In this case, large numbers of long-lived cached objects can get promoted into older generations of the garbage collector and increase both the run time of individual collections and the frequency at which they must happen.

Recovering from a failed cache is hard

Caches can let you scale up your serving capacity past what your underlying data source could serve alone, which is one reason to cache. Unfortunately, when your cache machines go down (or are unreachable on the network, or unresponsive, or…) you cannot simply bring them back online, as all data stored in memory will already be lost. You must warm your caches by reading from the underlying store while still trying to serve production traffic. Often your only choice will be to deny all but a fraction of traffic, slowly ramping up the amount you serve as your caches warm.

Is it worth it?

It depends; the tradeoffs are yours to choose between.

But before you choose, consider that many of the downsides won’t manifest themselves right away. Don’t forget how easy it is to ignore these downsides and focus only on the benefits–the payoff is immediate, but the costs must be paid constantly throughout the cache’s lifetime.

Garbage collector (GC) pressure happens when your application (running on the JVM, CLR, V8, and other garbage-collected runtimes) allocates then releases memory for many objects. The runtime must occasionally collect this garbage by walking through your memory graph to determine which objects are still needed, and which can be freed.

When your application produces and discards many objects in a short amount of time–say, from an in-memory cache–the garbage collector needs to interrupt your running code and collect dead objects more frequently, and each collection can take longer. ↩

Ruby on Rails: Don’t delete, tombstone

2015-08-18T11:32:38-07:00

In many web apps, things need to be deleted (no way!). But actually deleting records from your database has some side effects that aren’t immediately obvious:

Undelete isn’t possible without additional work
In small, simple apps, you may not have any other record of deleted rows
You may be able to improve your product based on what has been deleted
Extra work is required to “reactivate” deleted users or other models with their former data attached

One easy way to deal with this is with tombstones. A tombstone is simply a column in a table that marks whether a given record has been deleted.

This means that nearly all queries will need to filter based on this column to make sure it isn’t reading “deleted” (tombstoned) data. How annoying!

Fortunately, in Rails it is easy to separate out this concern. We can define a mixin called tombstoneable such that any ActiveRecord model that mixes it in will automatically filter out deleted records by default, and add some easy methods to query for tombstoned records as well.

Make it work

Create a new file lib/mixins/tombstoneable.rb:

module Mixins::Tombstoneable
  extend ActiveSupport::Concern

  included do
    default_scope { where(deleted: false) }
    scope :include_deleted, -> { unscope(where: :deleted) }
    scope :deleted, -> { include_deleted.where(deleted: true) }
  end

  def destroy
    update_attribute(:deleted, true)
  end

  def delete
    destroy
  end

  def undelete
    assign_attributes(deleted: false)
  end

  def undelete!
    update_attribute(:deleted, false)
  end
end

Nice! The magic is in the included block. We augment the default scope to always look for records that have not been deleted. If we wish to include deleted records as well, we can use the include_deleted scope:

User.include_deleted.find(...)

Or if we wish to only select deleted (tombstoned) edges, we can do that too:

User.deleted.find(...)

Now mix it in

We never finished actually mixing this in to a model. Let’s assume we have a model called User. Only one line is needed to mix in the tombstoning behavior:

class User < ActiveRecord::Base
  include Mixins::Tombstoneable
  ...

And add the column

We also need to make sure the database has a column to track which records have been deleted. This will be necessary for each model we wish to make tombstonable. From the command line:

rails g migration AddDeletedToUser deleted:boolean

Then modify the generated file to add a default and make the column NOT NULL:

class AddDeletedToUser < ActiveRecord::Migration
  def change
    add_column :users, :deleted, :boolean, null: false, default: false
  end
end

And run the migration:

rake db:migrate

That’s it!

I have found this to be a useful practice. Let me know how your experiences go (or have gone previously) in the comments. Enjoy your not-quite-deleted records!

How I doubled my Internet speed with OpenWRT

2015-03-10T15:09:10-07:00

OpenWRT is a powerful Linux distribution for embedded devices, such as my router, and this is the story of how I used it to double my bandwidth at no extra cost to myself.

How? By doubling the number of Internet connections I have.

My setup

My internet

My internet is through Comcast (unfortunately).

Comcast has an initiative called Xfinity WiFi. When you rent a cable modem/router combo from Comcast (as one of my nearby neighbors apparently does), in addition to broadcasting your own WiFi network, it is kind enough to also broadcast “xfinitywifi,” a second “hotspot” network metered separately from your own.

This hotspot allows Comcast customers to connect with their credentials.

My router

My router is a Buffalo WZR-HP-AG300H. Crucially, this router 1) supports OpenWRT and 2) has two independent radios. I use one of them for my home WiFi network.

My idea

By now, you’ve probably put two and two together.

I use my router’s extra radio to connect to the xfinitywifi hotspot, then load balance my outbound traffic across the connection I pay for and the bonus xfinitywifi connection.

Obviously this is a pretty specific scenario, but if you have:

A hotspot you have credentials for within range
A router that supports both OpenWRT
That same router has a spare radio

How to set this up

1. Install OpenWRT

Find your router on OpenWRT’s table of hardware and follow the instructions to install it, getting your WiFi and network set up as usual.

2. Install multi-wan software in OpenWRT

Open your router’s web interface and navigate to /cgi-bin/luci/admin/system/packages and install luci-app-mwan3. This (along with its dependencies) allows you to support multiple internet connections with round-robin load balancing between them (with connection pinning for HTTPS).

3. Authenticate a MAC address with xfinitywifi

The xfinitywifi hotspot requires authentication, not via WPA2 or other normal network security, but with a Comcast login. It remembers this login by way of your MAC address. Unfortunately, it is not very easy to authenticate directly through the router, so instead we will authenticate a MAC address through a computer, then switch the apparent MAC address the router uses.

Generate a fake MAC address. Here’s one: 02:67:1c:16:1f:21
Spoof your MAC address (for your wireless adapter) on your computer. Be sure to find out how to do it on your Linux/Mac/Windows system. Remember to record your old MAC address.
With your MAC address spoofed, connect to xfinitywifi and enter your Comcast credentials
Disconnect from xfinitywifi and restore your original MAC address

4. Connect the router to xfinitywifi

In your OpenWRT web (LuCI) interface at /cgi-bin/luci/admin/network/wireless, press Scan on your available radio, and select Join Network for xfinitywifi. Name it wan2 and add it to the wan firewall group. Save & Apply your settings.

Now, go to /cgi-bin/luci/admin/network/network/wan2 and go to the Advanced Settings tab. Paste your fake and authenticated MAC address into the “Override MAC address” field. Save & Apply your settings.

5. Prepare mwan3 for a wireless WAN

In your OpenWRT web (LuCI) interface at cgi-bin/luci/admin/network/network/wan/, click the Advanced Settings tab and enter 10 under Use gateway metric and Save your settings.

At cgi-bin/luci/admin/network/network/wan2/, click the Advanced Settings tab and enter 20 under Use gateway metric and Save your settings.

In your OpenWRT web (LuCI) interface at /cgi-bin/luci/admin/network/mwan/advanced/networkconfig, you will see your network config file. Paste this section at the bottom, adjusting as necessary with settings from your xfinitywifi connection:

config route 'default_wan2'
  option interface 'wan2'
  option target '0.0.0.0'
  option netmask '0.0.0.0'
  option gateway '192.168.1.1'
  option metric '20'

Normally this last step is not necessary, but for some reason mwan3 seems to need it to work with wireless networks.

Submit your changes.

Check it!

Go to cgi-bin/luci/admin/network/mwan and you should see both networks green!

At least you will if you’re the luckiest person ever. More likely you’ll run into problems, check out the mwan docs and Google around.

Another good test is to a website that tells you your IP and refresh several times and ensure you see two different IP addresses.

Good luck!

Keybearer: Decrypt a secret using M of N keys

2015-03-07T09:02:56-08:00

Keybearer uses several independent passwords to encrypt a file and later requires a subset of those passwords to decrypt it.

All operation are performed in client-side Javascript, so you can try it live right now.

Example

For example, Magician Mike uses Keybearer to encrypt the password to his laptop containing his secret repertoire of tricks. He gives the 3 passcodes he used to his estranged siblings Alice, Bob, and Charlie, on the condition that at least 2 of them reunite on his death to gaze on the majesty of his secrets.

After Magician Mike is tragically sawed in half by his careless assistant, Alice and Bob meet to decrypt Mike’s files using their passcodes. They are reunited through their Keybearer experience, while Charlie maintains his grudge and burns his passcode with fire.

More on GitHub

Keybearer is open source, so feel free to fork it on GitHub!

Disclaimer

I am not responsible for anything bad that results from the use of this software, nor am I liable: use this software at your own risk. In no circumstances should you rely on this to protect you or your data. This is a proof of concept created by someone with no security expertise.

Host your own web fonts

2015-03-07T04:45:10-08:00

Web fonts are very popular these days, and sites like Google Fonts and Typekit make it very easy to use them on your website.

Hosting them yourself is also pretty easy. I recently moved away from Google Fonts for this site using this same process.

Selecting a font

First, you must select a font. Be sure that the license you have allows you to host it on the web. We will use Lato, which is also available on Google Fonts.

Making the font available for use

Let’s say we want to use Lato and allow for bold, italic, and italic bold. This is how we would make the font accessible from CSS using Google Fonts:

<link
  href='//fonts.googleapis.com/css?family=Lato:400,700,400italic,700italic'
  rel='stylesheet'
  type='text/css'>

To self-host, the process is slightly different. First, we must download the files and put them in a folder, such as fonts.

Ideally we want to have each font variant (regular, bold, italic, bold + italic) in three formats: .woff for modern browsers, .eot for old Internet Explorer, and .ttf for other browsers. Font Squirrel has an online tool to convert easily between them if you’re missing any.

Now it’s just a matter of some simple CSS:

/* Normal */
@font-face {
    font-family: 'Lato';
    src: url('fonts/Lato-Regular.eot');
    src: url('fonts/Lato-Regular.eot?#iefix') format('embedded-opentype'),
         url('fonts/Lato-Regular.woff') format('woff'),
         url('fonts/Lato-Regular.ttf') format('truetype');
    font-style: normal;
    font-weight: normal;
    text-rendering: optimizeLegibility;
}

/* Italic */
@font-face {
    font-family: 'Lato';
    src: url('fonts/Lato-Italic.eot');
    src: url('fonts/Lato-Italic.eot?#iefix') format('embedded-opentype'),
         url('fonts/Lato-Italic.woff') format('woff'),
         url('fonts/Lato-Italic.ttf') format('truetype');
    font-style: italic;
    font-weight: normal;
    text-rendering: optimizeLegibility;
}

/* Bold */
@font-face {
    font-family: 'Lato';
    src: url('fonts/Lato-Bold.eot');
    src: url('fonts/Lato-Bold.eot?#iefix') format('embedded-opentype'),
         url('fonts/Lato-Bold.woff') format('woff'),
         url('fonts/Lato-Bold.ttf') format('truetype');
    font-style: normal;
    font-weight: bold;
    text-rendering: optimizeLegibility;
}

/* Bold + Italic */
@font-face {
    font-family: 'Lato';
    src: url('fonts/Lato-BoldItalic.eot');
    src: url('fonts/Lato-BoldItalic.eot?#iefix') format('embedded-opentype'),
         url('fonts/Lato-BoldItalic.woff') format('woff'),
         url('fonts/Lato-BoldItalic.ttf') format('truetype');
    font-style: italic;
    font-weight: bold;
    text-rendering: optimizeLegibility;
}

Your fonts should now be available. Be sure to adjust the url paths if you place your fonts in a different directory.

Applying your font

Simply apply your font in CSS as usual (this will also work with Google Fonts or Typekit):

body {
  font-family: Lato, 'Helvetica Neue', Helvetica, Arial, sans-serif;
}

Now you’re good to go!

Extreme optimization

If you really want to get fancy, Google Fonts has a feature called subsetting that lets you strip unused characters out from the font before transmitting it to clients, saving bandwidth.

You basically have two options if you want to do it yourself. The easy way is to use FontSquirrel’s excellent Webfont Generator, and use the subsetting options there.

The hard way is complicated and you will need to work out the exact details, but a basic setup would be:

Determine what characters you use

If you have a static website, you might be able to do this fairly easily, perhaps by finding every character displayed on any page (accounting for HTML encoding).
Set up a pipeline to subset your fonts

fontTools’ subset.py is probably the best way to do this, or the related version in Google Font Directory.
Use the generated files as above

Before going down this route, you probably want to measure your maximum possible speed improvement and see if it’s actually worth the trouble.

How to win when you’re small

2015-03-04T12:23:55-08:00

We all know it happens–the underdog wins, the smaller army emerges victorious, the startup overtakes the multinational.

But why?

And how can we apply this effect to our companies, sports teams, or lives?

Modeling unequal conflict

Enter Colonel Blotto.

Colonel Blotto is a simple game, well-studied in game theory. The Colonel must choose how to distribute troops over some number of battlefields. The goal is to emerge victorious at more battlefields, but the Colonel doesn’t know in advance how many opponents will arrive at a given field. Victory is determined simply by allocating more troops at a given battlefield.

Fighting and winning at a disadvantage

Unfortunately, our Colonel is at a disadvantage and doesn’t have as many troops as the enemy.

For example, if we have 3 battlefields:

Battlefield	Blotto	Enemy
A	4	5
B	4	5
C	4	5

Despite this disadvantage, Blotto can still succeed:

Battlefield	Blotto	Enemy
A	6	5
B	6	5
C	0	5

This is our first bit of insight: picking your battles (and picking which to sacrifice) is unquestionably more effective given limited resources. This is hardly earth-shaking news, but it is good to see that our model bears out conventional wisdom.

In fact, there is a common application of this in politics: gerrymandering. By carefully choosing districts, politicians have learned to win elections without the popular vote.

Now, the obvious objection is that an Enemy with superior resources could easily reallocate troops to guarantee victory on a majority of battlefields—this is unfortunate for Blotto, but it reveals a second insight: the Enemy doesn’t have enough resources to win at everything! Unless the Enemy has a truly overwhelming number of resources, Blotto has a good shot at winning at least some battlefields, just as a small business can often outperform larger competitors in a few key areas by focusing on filling needs unmet by those larger competitors.

Fighting at a major disadvantage

But what can an outgunned Blotto do in a situation where the enemy has many more resources?

Battlefield	Blotto	Enemy
A	2	4
B	2	4

Even if our good Colonel allocates all troops to one battlefield, the Enemy has enough resources to prevent a Blotto victory on either battlefield.

So why not add more battlefields?

Battlefield	Blotto	Enemy
A	3	2
B	1	2
C	0	2
D	0	2

By adding new battlefields to the game, Blotto is able to be victorious on one battlefield despite having half the troops.

Of course this isn’t allowed in the game theory version (and Blotto still hasn’t won!), but it uncovers a third insight: adding new areas to compete in is advantageous for the underdog. Doing one thing (or a few things) well is a better strategy for small companies, and it can be a great advantage in a career as well.

This applies even more in situations where a victory on one battlefield may be sufficient to win–imagine a small company suddenly competing on grounds no other company knew existed.

The math behind the maxim

We have seen a few good insights suggested by Colonel Blotto that can be rephrased as more conventional wisdom:

Pick your battles. If you spread your resources too thin, you are easily defeated.
Know thy enemy. If you know how your opponents will use their resources, you can pick the right battles.
The underdog can win too. It’s easy to get disheartened, but remember that you can win even with fewer resources.
If you can’t win, cheat. Add a new dimension to the game, a new product, a new battlefield. It might just be the edge you need.

msol

Mac productivity tips for developers

Working faster

1: The “Hyper” key + transform Caps Lock into Escape

Setup

2: Managing windows with Hammerspoon

Setup

3: Tap shift to move over words

Setup

4: Right-thumb control key

Setup

5: Ctrl+W deletes the previous word

Setup

6: A better shell with oh-my-zsh

Setup

7: Syntax highlighting in the terminal

Setup

8: Faster key repeat

Setup

9: File-searching aliases

Setup

Software

Karabiner Elements

Hammerspoon

Oh My Zsh

More resources

Nietzsche would write clickbait

Dirt-cheap client-encrypted online backups with Raspberry Pi

Aside: backing up a computer

Backing up your NAS, or multiple computers

Set up Google Nearline

Mounting via SSH

Set up GPG and your encryption keys

Set up Duplicity and the backup script on your Raspberry Pi

Scheduling backups with cron

Future improvements

Pro-style testing

Table of Contents

Terminology

Test sizes

Properties of tests

General principles to follow

Test one behavior per test

Test each behavior once

Write tests that provide value by reducing risk

Name tests to describe the behavior precisely

Rework code until it is easy to test

Watch it fail

Tests should use literals where possible

Leverage the type system

Mistakes to avoid

Don’t write change-detector tests

Don’t test code you don’t own in Small or Medium tests

Red flags and code smells

Concrete tips

AAA test structure

Write the assertion first

Write exactly one test for each equivalence class

When testing state changes, assert before as well as after

Only control direct dependencies, not dependencies of dependencies

Assert on boundaries for functions accepting a contiguous range of inputs

More about testing

Property-based tests

Large tests

Refactoring tests

Reading and resources

More terminology

Box colors

Subtypes of tests

Good resources

Short but valuable reading

You’re probably wrong about caching

Fine, why do you think caching is so hard?

Reasoning about cached data is harder

A new class of perspective bugs are possible with cached data

Reproducing behavior involving caching is harder

Access pattern changes can subtly lower cache hit rates which damages performance

In-process caching in garbage-collected languages increases GC pressure1

Recovering from a failed cache is hard

Is it worth it?

In-process caching in garbage-collected languages increases GC pressure¹