Greg Vaughn gvaughn

Case 1: Missing Colon

.yml looks like:

  purchases_edit
    cannot_edit: "Purchase cannot be edited after submission"

We can test in irb:

Vim and Git in Code Demos

I want to give a code demo that shows progression of the code. I thought it would be great if I could craft the series of commits on a branch and have a single vim keystroke that would checkout the next (or previous) commit and force my buffers to reload. That would allow me to show one commit, then give me the freedom to live code how the next step is done, but when I advance to the next commit I know I'll have working code. It's like a safety harness for live coding.

Here's how it's supposed to work:

I created a test_forward branch, and, yeah, it's hardcoded in the vimscript :-(
Then I created 3 consecutive commits with one line changes in my README
optional: I used "git tag $tag_name" to give a friendly name in my bash prompt for each commit (I wish the fugitive statusline would use it too though)
I checked out the 1st of the demo commits

Step 0:

Get Homebrew installed on your mac if you don't already have it

Step 1:

Install highlight. "brew install highlight". (This brings down Lua and Boost as well)

Step 2:

Greg Vaughn posted this cool alias the other day:

copr = "!f() { git fetch -fu origin refs/pull/$1/head:pr-$1; git checkout pr-$1; } ; f"

Preferring to be a stock-tools person, I wanted to deconstruct this to see how I'd use it off-the-shelf without the alias.

git fetch     -- I'm already familiar with this command
-fu           -- these two flags I'm not sure are necessary, esp. -u since the help says, 
 "unless you are implementing your own Porcelain you are not supposed to use

Keybase proof

I hereby claim:

I am gvaughn on github.
I am gvaughn (https://keybase.io/gvaughn) on keybase.
I have a public key whose fingerprint is C533 8C70 3D72 1F62 AA4C 904F 3580 16C3 FDA7 0311

To claim this, I am signing this object:

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.

What's up with Address and UserAddressBook?

It's a domain level refactoring. Address is now readonly with copy on write semantics, so once it's in the db, it doesn't change. If you use the typical nested attributes for addresses in Orders (and now Users and CreditCards) it'll just work. If you need to create them manually Address.factory and Address.immutable_merge are your new friends. UserAddressBook is foundational work to ultimately allow users a richer set of addresses to use for pre-fill during checkout.

Background

I was asked to add what seemed like a fairly simple new feature to our custom frontend code, but upon digging I found that it would require some fairly large refactoring to do it well. That new feature was to allow the user to manage a list of addresses in their account section of our frontend. Those will be used as options to pre-fill during checkout. The things that I found that I wanted to refactor were some missing and misplaced address associations, plus a lot of unn

	def evolve(generation)
	live_neighbor_stats = generation_stats(generation)
	live_neighbor_stats[3] + (live_neighbor_stats[2] & generation)
	end

	def generation_stats(live_cells)
	live_cells.each_with_object(Hash.new(0)) {\|live_cell, counter\|
	neighbors(*live_cell).each {\|neighbor\| counter[neighbor] += 1 }
	}.each_with_object(Hash.new {\|h,k\| h[k] = []}) {\|(cell, count), collector\| collector[count] << cell}
	end

	#Mars Rover Kata

	#Develop an api that moves a rover around on a grid.
	#You are given the initial starting point (x,y) of a rover and the direction (N,S,E,W) it is facing.
	#The rover receives a character array of commands.
	#Implement commands that move the rover forward/backward (f,b).
	#Implement commands that turn the rover left/right (l,r).
	#
	#Implement wrapping from one edge of the grid to another. (planets are spheres after all)
	#Implement obstacle detection before each move to a new square. If a given sequence of commands encounters an obstacle, the rover moves up to the last possible point and reports the obstacle.