View 1_download_wanikani_kanji.rb
#!/usr/bin/env ruby
require_relative "../config/environment"
def kanji_at(level)
uri = URI("{api_key}/kanji/#{level}")
response = JSON.parse(Net::HTTP.get(uri))
raise response["error"]["message"] if response.has_key?("error")
return response["requested_information"]
View 1-20180123123916_create_posts_tags.rb
class CreatePostsTags < ActiveRecord::Migration[5.1]
def change
create_table :posts_tags do |t|
t.references :post, foreign_key: true
t.references :tag, foreign_key: true

I'm currently undergoing a 9-month-long in-place rewrite of testdouble.js (which has proven to be a really stupid idea, but mildly entertaining at least).

This morning, my goal was to break down the responsibilities of the totally not unit-tested td.verify() function with a number of smaller modules which are test-driven with an outside-in approach.

I get a bunch of questions about how I "actually" do this, so I logged each step I took in a separate commit. You can see the 9 steps I took, including the final step—realizing that the contract I'd created was not how I wanted, refactoring one of the dependencies' contracts before it had even been written!

  1. Psuedo code the module with comments to start shaking out desirable names of dependencies
  2. [Define thos

Don't Mock Me

Confusion over test doubles starts with what to even call them. You might know them as stubs, proxies, mocks, or spies (but I call them test doubles, because a book you've probably never read declared it to be the most general term). I've spent a decade fascinated by the disconnect between why test double libraries were invented and how they are actually used by teams. What I've learned: their purpose fills a little-known but valuable niche, whereas their appeal addresses a mainstream but self-destructive impulse.

If you don't leave this talk with a clearer distinction between tests that ensure safe changes versus tests that promote simple designs, I'll give you your 45 minutes back. Once that groundwork is laid, you'll better understand the characteristics that matter most in a test double library and the nuanced rules that should govern their use. I've found this clarity invaluable for producing valuable tests and


The 5-minute backpack demo

Here's what I carry in a Tom Bihn Synapse 19 bag when I travel for 1-to-n days. In general, I optimize for low-weight items, with a secondary focus on reducing maintenance. You can peruse a gallery of pictures, too.


View 20171004204107_add_timestamps_everywhere.rb
class AddTimestampsEverywhere < ActiveRecord::Migration[5.1]
def change
change_table :candidates do |t|
t.timestamps default:
change_table :evaluations do |t|
t.timestamps default:
View puts.js
app.puts = (...anything) => {
fetch("/api/puts", {
method: 'POST',
headers: {
'Content-Type': 'application/json'
body: JSON.stringify({content: anything})
View splits_furigana_test.rb
class SplitsFuriganaTest < ActiveSupport::TestCase
def setup
@subject =
def test_some_basics
# No reading, no fuss
assert_equal [h("ひろ", nil)],"ひろ", nil)
# All kanji, no splitting

What to expect() when you're expect()ing


Most people test their JavaScript, but many feel hamstrung by erratic, inconsistent, and redundant tests. New tools claim they'll save us, but test pain is rarely a tooling problem. Instead, this workshop focuses on test design, mapping participants' test antipatterns to real, practical solutions.


Every day, brilliant programmers around the world write awful tests.

These days, most developers (finally!) test their JavaScript. In fact, many of us write so many tests we often feel overwhelmed by massive suites of erratic, inconsistent, and redundant tests. Worse, because tests play second-fiddle to production code, it can be hard to make the time to identify & address root cause problems before they metastasize throughout our projects.


There's under the sun


Quick: say something about Ruby that hasn't already been said.

Not easy, right? This community is prolific. In thousands of talks, Ruby's story has been told and retold. We heralded programmer happiness, path of least surprise, and confident code. We unleashed metaprogramming (until we tamed our DSLs). We built apps, tested them to death, and then legacy-rescued them.

What's left to say? We could tell the same stories again, but that wouldn't be very DRY. What we need to hear was often said years ago, so this talk will help us rediscover timeless lessons from our community's greatest hits.