Events
Thursday: Thursday night pair exchange
In addition to the regular Tuesday event. Same time, 6:15 – 9:00.
Friday: Block Party
next Friday celebrating start ups in SF w/food trucks at lunch time.
In addition to the regular Tuesday event. Same time, 6:15 – 9:00.
next Friday celebrating start ups in SF w/food trucks at lunch time.
Meet after work to go there:
http://www.sfruby.info/events/96446412/
In addition to the regular Tuesday event. Same time, 6:15 – 9:00.
next Friday celebrating start ups in SF w/food trucks at lunch time.
At Pivotal we practice a form of Agile software development descended from the original Extreme Programming (XP) created by Kent Beck et al. XP codifies many of our core practices including pair programming, test-driven development, iteration planning, and stand-up. XP also has a very strong emphasis on flat hierarchies and frequent communication. Because of its values and engineering guidelines, XP allows for high-quality software to be produced and shipped extremely quickly. XP values working software over extensive specifications or documentation, so-called “big design up front.” This is so the product can be iterated on quickly, both in the business and the technical sense.
Opinions differ as to which of XP’s practices is the most valuable in accomplishing this. One of my personal favorites is simplicity and clarity in code and design. Simplicity is a difficult thing to pin down. Occam’s Razor, one of the earliest and most popular statements of the parsimony principle, suggests we form a hypothesis with the least “plurality,” or the fewest assumptions or entities possible. Since then people have rephrased this idea as “keep it simple, stupid” (KISS) or probably the most elegant, “less is more.” My favorite statement is St. Exupéry’s:
“It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away.”
XP offers us its own guidance on simplicity and writing simple code. It has two simply stated tenets on simplicity: “do the simplest thing which can possibly work,” and the related “you ain’t gonna need it” (YAGNI). Ward Cunningham, another father of XP, explains the first concept as:
“What’s possible? What is the simplest thing we could say in code, so that we’ll be talking about something that’s on the screen, instead of something that’s ill-formed in our mind. Once we get something on the screen, we can look at it. If it needs to be more, we can make it more.”
YAGNI is an answer to the temptation to prematurely optimize: “Always implement things when you actually need them, never when you just foresee that you need them.” Yet, XP also tells us we should “refactor mercilessly,” and Cunningham has long been a proponent of object-oriented design patterns. There is some tension there and it depends on the project and situation.
Clojure creator Rich Hickey tells us in his 2011 talk that the easiest thing isn’t always the most simple, and the simplest design isn’t always immediately apparent. This is a veiled jab at object-oriented programming in favor of functional languages. Obviously object orientation leads to many more “entities” than functional design, assuming entities are objects. Yet most programmers will tell you that objected-oriented design is “easier” than functional design. Perhaps this is merely because they are more familiar with OOP from past experience. However, many would also argue that functional code is quite complex. Code is communication, so a good design is easily parsed (by humans) and understood. That might mean favoring OOP conventions over a more functional style. In Ruby we have a number of functional-inspired techniques that allow for some middle ground to follow the principle of least astonishment.
Let’s look at a case study. Some months ago, I worked on a Ruby implementation of Tetris in my spare time. My goal was to have a working implementation in the shortest time possible, to win a bet that a working game of Tetris would take more than a few days. I settled on Gosu, a C++ 2D game development library that provides graphics, sound, and many other features in a pure Ruby wrapper. The game is on Github. After bundling, you should be able to run it with ‘ruby game_window.rb,’ and try prefacing that with bundle exec if it doesn’t work right away. You will need to have a number of dependencies installed, see the Gosu documentation for more.
I assume the reader is familiar with the rules of Tetris. One of the first things I did was create the shapes for the pieces. Tetris has 7 pieces. All somewhat resemble letters: I the 4×1 stick, J and its mirror L, S and its mirror Z, O the square box, and T. I knew in my head what these pieces looked like, and could easily draw them. So, I created a relative X,Y coordinate system and a draw method. For example, the I piece was [[0,0],[1,0],[2,0],[3,0]].
Now that I had pieces, I needed rotation. I knew what the rotation should look like, but I was not entirely sure how to implement the concept in code. Without researching the question much, I decided to hard-code my values. This seems “dirty” or “ugly,” but it is in keeping with Cunningham’s urging to put something on the screen now and iterate on it later. It was the simplest thing that could possibly provide a working implementation of the game. I also knew that there was a bounded number of possible pieces and rotations in the game, and no need to generalize further. Furthermore, I wasn’t working with a team, didn’t need to maintain the code going forward, and had to win a bet. So I created a large case statement of hashes that looked like this:
def shape
case @type
when :I
{0 => [[1,0],[2,0],[3,0]],
1 => [[0,-1],[0,-2],[0,-3]],
2 => [[-1,0],[-2,0],[-3,0]],
3 => [[0,1],[0,2],[0,3]] }
The pieces, when generated, would randomly assign themselves a type from the list, and a rotation starting at 0. The current_shape method would call to the shape hash method with the current rotation to get the current shape. When the player pressed up, the game would increment the rotation by 1 or reset it back to 0 if it had reached 3. This is not a bad “simplest thing” solution because it is fairly easy to understand what it is doing, and hopefully easy to refactor it into something a bit more elegant. You can see this early commit here. Feel free to checkout that version of the code and run it as well (git checkout 04d590d114cdd564f54491b77339c6ac24bb1693). It will generate a random Tetris piece and then crash. The next commit, ebfcc34e461d30321edf7293f8dc3de95fa2af2b, has semi-functional rotation using the hash method.
I was able to finish the Tetris game with this hard-coded implementation and left it alone for some months. However, in the back of my head, the hard-coded solution was bothering me, and I wanted to implement it using a rotation matrix, a concept I dimly recalled from math class.
Good tests are the most important requirement for refactoring confidently, since they provide a known basis that your refactor preserved the correct behavior and did not break anything. I had been sloppy the first time around and hadn’t written a test for the method that contained the massive case statement, which later became a class method with a type parameter. So here it is:
it "I" do
Piece.shape(:I)[0].should == [[1,0],[2,0],[3,0]]
Piece.shape(:I)[1].should == [[0,-1],[0,-2],[0,-3]]
Piece.shape(:I)[2].should == [[-1,0],[-2,0],[-3,0]]
Piece.shape(:I)[3].should == [[0,1],[0,2],[0,3]]
end
This was green, as you’ll note it is quite similar to the implementation above. For my refactor I wanted to change the interface of the shape method to have 2 parameters instead of returning a hash, so my test would look like
Piece.shape(:I,0).should == [[1,0],[2,0],[3,0]]but would otherwise remain the same. The case statement would remain, but would only return the 0 rotation, after which I would perform some sort of matrix transformation.
Wikipedia tells us that the rotation matrix for 90 degrees counterclockwise is:

After some Googling I settled on an implementation like this:
rotation.times do
shape = shape.map{|arr|(Matrix[arr] * Matrix[[0,-1],[1,0]]).to_a.flatten}
end
Although the tests passed for the I, J, and L shapes, the other piece tests did not. The O shape actually moved around its axis of rotation even though in my hard-coded version, I had it remain stationary. I had also previously suspected a bug in the implementation of the S or Z shapes, since they seemed to be roughly the same, even though they should have been mirror images. More than likely my known “true” values were simply off. Playing the game confirmed that the rotation was functional and acted as intended. You can see the commit at GitHub.
I was further able to refactor away the rotation variable, generate the shape at object initialize time, and apply the rotation upon receiving player input (commit). This optimizes the number of rotations. Previously, each rotation would start at 0 and progress to a maximum of 3. So if I rotated from 2 to 3, the old code would actually calculate the interim steps 0 to 1 and 1 to 2 as well. The new stateful version will only perform one matrix transformation per rotation.
This change also allowed me to rewrite the test in a much more object-oriented and end-to-end way, as follows:
let(:piece) { Piece.new(window, grid, type) }
describe "I" do
let(:type) { :I }
it "rotates" do
piece.shape.should == [[1,0],[2,0],[3,0]]
piece.rotate
piece.shape.should == [[0,-1],[0,-2],[0,-3]]
piece.rotate
piece.shape.should == [[-1,0],[-2,0],[-3,0]]
piece.rotate
piece.shape.should == [[0,1],[0,2],[0,3]]
end
end
endI think this is a reasonable showcase of a balance between refactoring and simplicity. My initial implementation was pretty ugly, but it allowed me to continue making progress. After getting the simplest thing out the door and hitting my deadline, I went back to refactor the technological debt I had accrued.
Also, I am not going to need it, but the solution is now generalized enough that I could add additional pieces. For example:
[[1,0],[2,0],[2,1],[2,2],[2,3],[3,0],[4,0],[5,0],[5,1],[5,2],[5,3]]Some would argue that the new design is actually simpler. It's fewer lines of code, fewer branches in logic, it uses a well-established algorithm, it's more elegant. Sure, the refactored version is a vastly improved design, but "simple" isn't about lines of code or branches in logic. "Simple" is about complexity of implementation. For example, XP tells us about the "rule of three": refactor out duplication only on the third occurrence of duplicate logic, not the second. The implication is that duplication is more lines, but "simpler" to write.
What "simple" definitely is not about is elegance. The hard-coded solution was simpler because it had fewer levels of abstraction and required less of a cognitive load to understand than the matrix manipulation: the difference between basic Cartesian coordinates versus a result obtained using linear algebra. Math, even pre-calculus, is often quite elegant but quite abstract and therefore more complex than a simple table of values. Why does the rotation matrix work? Well, to understand that, you'll need to understand its generalized form, and quickly this solution becomes quite slow and complicated to implement, especially if it's late at night and you're having trouble remembering trigonometry.

It's clear that according to XP's philosophy, the hard-coded solution is the preferred first step. Kent Beck outlines the benefit of doing the easiest simple thing first:
- You get done sooner
- Your work is easier to communicate
- Duplication is obvious, so the needs and means for refactoring are clearer
- Tests are easier to write
- The code is easier to performance tune (Or, at least, there will be more scope for tuning performance)
- You feel less stress, which enhances all of the above
The key benefit of a simple solution is that you get it done faster so you can iterate on it. It's a first pass used to enable continued progress. Perhaps this principle should be called "do the easiest thing to make the tests pass," "do the ugliest, dirtiest thing first," "do what comes to mind first and stop thinking so hard," or maybe just "be as agile as possible." Agile, of course, primarily means "quick."
next Friday celebrating start ups in SF w/food trucks at lunch time.
Compiled Ruby with clang and the compile output contained a warning to "expect errors". Has anyone experienced these alleged errors?
One member or our audience said that they had compiled the same way and not experienced any problems.
Nasty remote execution vulnerability.
rack.github.com
If you're using parallel_tests, be aware that, unlike rake db:test:prepare, the rake parallel:prepare task does not purge the databases before it loads the schema. You'll only notice this if you're dropping tables – the dropped tables will stay forever in the parallel databases.
We have a fork that works properly. (Pull request coming soon.)
https://github.com/pivotal-gemini/parallel_tests
next Friday celebrating start ups in SF w/food trucks at lunch time.
We have a Rails app that is saving a new ActiveRecord object, and then immediately afterwards, enqueueing a Resque job that looks up that record by its ID. Sometimes, the lookup inside the resque job fails – it claims no such row with that ID exists.
If we put the lookup into a loop that catches that exception and retries the exact same lookup, it always eventually succeeds, usually after 1-2 seconds.
The ID exists on the ActiveRecord object before the job is enqueued, which (I think) means that the save transaction has completed. But the resque job is using a different database connection, so maybe there's some weird caching going on? But here Google has failed us.
Any ideas? We could leave it in a loop that catches the exception, sleeps 1 second, and retries, but: ugh.
Some ideas from the audience:
There is a connection object that can be queried about transaction states.
Wait for transaction count increment/decrement?
Could be a problem with the way that sqlite fakes nested transactions.
Usually we have a single GitHub account for a project that contains a key for each of the machines being used on a project. On our project we want to use a separate account for each person on the project. Is there a way to do this without a lot of trouble shuffling SSH keys around?
Pivotal Git Scripts may have some tools for this.
You can also use HTTPS URLs and enter username/password on each commit.
If you need to write your own chef recipes to install your project's dependencies, you can add a cookbooks directory to the root of your project. Make sure to delete the cookbook_paths section from your lobot.yml (to use the default values), or add ./chef/project-cookbooks to the cookbook_paths section.
So, to have a bacon recipe, you should have cookbooks/pork/recipes/bacon.rb file in your repository.
http://intridea.github.com/stately/
For all those times you need a vector representation of the USA and to color the states separately.
Takes a well formed file and generates really usable REST API documentation. Integrates with Github for collaboration
Does anyone have any experience with it?
Appium is an open source test automation tool for native and hybrid iOS apps.
Use Ruby, Java, Javascript etc.. to write your tests.
You don't have to recompile your app or modify it in any way because Appium's automation is based on Apple's UIAutomation library
http://rubygems.org/gems/smooth-jazz-nyan-cat-formatter
With some display fixes. Coming eventually, configure your own music and cat!
We keep getting this error across multiple projects & machines, with different versions of the pg gem and the PostgreSQL server, with varying consistency. Switching the tests to sqlite seems to fix it.
Failure/Error: Unable to find matching line from backtrace
ActiveRecord::StatementInvalid:
NoMethodError: undefined method `fields' for nil:NilClass: SELECT "locations".* FROM "locations" WHERE "locations"."id" IN (11, 10, 5, 4, 1, 3, 2)
It appears that PG::Connection#async_exec is returning nil for some queries.
It was suggested to add a "fields" method for the nil class.
http://www.kickstarter.com/projects/homebrew/brew-test-bot £50 to get a pair of pint glasses…
If you want to test your media query css as part of your acceptance suite, you can just ask Capybara to resize the firefox window.
Don't use the iframe to do this, because it will be buggy. Note you will need to use min/max-width not min/max-device-width when defining your media queries. Otherwise resizing the browser window will not trigger the media query.
Capybara.current_session.driver.browser.manage.window.resize_to(width, height)
Capybara.current_session.driver.browser.manage.window.position = Struct.new(:x, :y).new(session_name == :default ? 0 : width, 0)
Thanks to Ryan for the tip.
(Alexander & Matt)
We want to make sure that our fixtures don’t get out of sync with our test suit. So we wrapped everything into timecop. Now we are getting “Mysql2::Error: Lock wait timeout exceeded” when running “rake parallel:spec”. The offending database call is a “Fixture Delete”.
(Will Read)
The latest RubyMine EAP find & replace doesn’t seem to respect exclusions. BE AWARE.
A beta was released over the weekend which may or may not fix it.
(Matt & Will)
Yard doc is a pretty sweet way to generate some documentation. On our project, we had developed a little system of helper methods for our acceptance test suite (a DSL if you will), and we could not remember the names of everything, so we wanted to organize and expose it. After installing the yard gem (and the redcloth gem), we were able to generate documentation with “yard server –reload”. This runs a web server that we can hit during development that reloads on every request.
If you’re looking at your code and realizing “I need this number in bytes, not MB so I can use Rails’s handy number_to_human_size helper”, don’t forget that the Numeric class is there to help!
5.megabytes => 5242880 == 5*1024*1024
number_to_human_size(5.megabytes) => “5 MB” == YAHTZEE!