kerrizor

SaddleSore 1k Planning

SaddleSore 1000

documentation and forms

Final Route

Google Maps

Start (5:00 am)

Shell — 812 NE 65th St, Seattle, WA 98115

kerrizor

context "when the moon is rising" do

let(:moon_phase) { ->(){ planet.moons.first.blah.baz.bat[0].phase } }

 it "looks it up" do
   expect { change_moon_phase }.to change( moon_phase.call }
 end
end

kerrizor

def link_to_github(rubygem)
  [rubygem.linkset.code, rubygem.linkset.home].detect do |linkset|
    URI(linkset.to_s).host == "github.com"
  end
rescue URI::InvalidURIError
  nil
end

kerrizor

desc "Check for ActiveRecord orphans"
task orphan_check: :environment do
  # Silly housekeeping.. I'm sure there's a better way to spin up the app before
  #   we run the rake task but I A) can't remember and B) can't be bothered I'm
  #   just spiking some code here. Only PITA here is it makes us Rails specific.
  #
  Rails.application.eager_load!
  ActiveRecord::Base.descendants.each{ |k| k.connection }

  # Load up all the AR models in our app

kerrizor

The Selfish Programmer

Using Ruby at work is great… but sometimes it feels like a job!

This year, I rediscovered the joy of writing Ruby apps for nobody but myself—and you should, too! Solo development is a great way to learn skills, to find inspiration, and to distill what matters most about programming.

Building an entire app by yourself can be overwhelming, but this talk will make it easier. We'll start with a minimal toolset that one person can maintain. You'll learn how many "bad" coding practices can actually reduce complexity. You may be surprised how selfish coding can make you a better team member, too!

Details

kerrizor

require 'set'
require 'find'

class Array
  def to_h; Hash[self]; end
  def to_set; Set.new(self); end
  def freq; group_by {|e| e }.map {|k,v| [k,v.count] }.to_h; end
end

kerrizor

Crescent Wrenches, Socket Sets, and Other Tools for Debugging: Creating your own Toolkit of Inquiry

Software exists in a constant state of failure, facing pressure on many fronts - malicious intruders, hapless users, accidental features, and our own limits of imagination all conspire to bring our system to a screeching halt. Untangle even the most tangled of Gordian Knots by building your own toolkit for inquiry, by relying on the simplest technique of all: asking "why?"

kerrizor

Papers in Brian Troutwine's Moonconf talk:

"The Case of the Three Engineers vs. BART" :: Gordan Friedlander - 1974
"SIGSOFT Vol. 6 No. 2: Frontmatter" :: 1981
"The BUG Heard 'Round the World: Discussion of The Software Problem Which Delayed the First Shuttle Orbital Flight" :: John Garman - 1981
"Analyzing Software Requirements Errors in Safety-Critical, Embedded Systems" :: Robin R. Lutz - 1993
"Eliminating Embedded Software Defects Prior to Integration Test" :: Ted Bennett, Paul Wennberg - 2005
"Engineering a Safer World: Systems Thinking Applied to Safety" :: Nancy Leveson - 2011
"The Role of Software in Spacecraft Accidents" :: Nancy Leveson - 2004
"The OpenBSD Culture" :: David Gwynne - 2006

kerrizor

I'd like to share some git aliases that you might find useful if you handle pull requests from others.

Add these to your ~/.gitconfig in the [alias] section:

copr = "!f() { git fetch -fu origin refs/pull/$1/head:pr-$1; git checkout pr-$1; } ; f"
prunepr = "!git for-each-ref refs/heads/pr-* --format='%(refname:short)' | while read ref ; do git branch -D $ref ; done"

Now you can "git copr #{pr_number}" (check out pull request is the mnemonic) and it will pull down the PR in a local branch of pr-#{pr_number} and check it out for you. To do it right, you must pronounce it "Copper" with a James Cagney gangster accent.

kerrizor

require 'ostruct'
require 'benchmark'

ITERATIONS = 10_000_000
FOO        = "Bar"
BAZ        = "Bat"

NewStruct = Struct.new(:foo, :bar)