View client.js
const puts = (...anything) => {
fetch("/api/puts", {
method: 'POST',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({content: anything})
})
}
View 1_download_wanikani_kanji.rb
#!/usr/bin/env ruby
require_relative "../config/environment"
def kanji_at(level)
api_key = ENV['WANIKANI_API_KEY']
uri = URI("https://www.wanikani.com/api/user/#{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
t.timestamps
end
end
end
View discovery-testing-example.md

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
View dont-mock-me.md

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

View travel-light.md

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.

Clothing

View 20171004204107_add_timestamps_everywhere.rb
class AddTimestampsEverywhere < ActiveRecord::Migration[5.1]
def change
change_table :candidates do |t|
t.timestamps default: Time.zone.now
end
change_table :evaluations do |t|
t.timestamps default: Time.zone.now
end
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 = SplitsFurigana.new
end
def test_some_basics
# No reading, no fuss
assert_equal [h("ひろ", nil)], @subject.call("ひろ", nil)
# All kanji, no splitting
View 2017-test-smell-workshop.md

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

Abstract

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.

Description

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.