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 |
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 |
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 |
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!
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 |
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?"
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 |
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.
require 'ostruct'
require 'benchmark'
ITERATIONS = 10_000_000
FOO = "Bar"
BAZ = "Bat"
NewStruct = Struct.new(:foo, :bar)