Home

Code Retreat Minneapolis, 2012

Notes by: Brian Westrich, [email protected]

Code Retreat is a set of intentional practice sessions intended to improve one’s craft of coding. The analogy our moderator used was that of football practice: players run through drills (e.g. high stepping through tires) that hone the skills needed in game conditions, but in a situation where other game day pressures (crowds, pressure from opponents) do not distract. To practice coding, we should use similar drills, free from our project oriented such as “get it done now”, “use the legacy code base”, and “adhere to our existing team structures”.

Venue

• Code Retreat Minneapolis was held on December 8, 2012 at Bloom Health in downtown Minneapolis from 9am to 4pm, and was moderated by Kyle Boon. The retreat was held the day after a blizzard, so even though I only heard about it the evening before (from my colleague, Mike Calvo) I was able to sneak in without preregistration due to a number of cancellations. About 20 participants attended.
• We wrote code on our own laptops, though were able to dock these to the high resolution monitors and keyboards provided by the host. All laptops were MacBooks unless otherwise noted.

Practice Sessions

The day consisted of five practice sessions. During each session, we paired with a different person. At the end of each session, the entire group reflected on what we learned, and then we discarded any code developed during that session.

Initial session

• Structure: We learned the problem domain that we were to solve: Conway’s game of life. References for this included the Wikipedia page, as well as a few other very interesting running examples of the game. • Team: I paired with Mike, and we implemented a partial solution. Much of our time was spent discussing the names of the domain objects.
• Technology: We used Java and JUnit as language/testing framework, and IntelliJ for an IDE. No conditionals or branching • Structure: In this session, we were not allowed to use various fundamental programming constructs. The one that stood out for me was to not being able to do branching (if statements). The only way we could do without these was to use a cumbersome and impractical combination of polymorphism and maps. “Running with your hands behind your back”. • Team: I paired with someone who was knowledgeable in LUA. Prior to our implementation session, she gave me a tour of some code she was aware of that used Spock to do table driven tests.
• Technology: We didn’t get as far as we’d liked in LUA due to the programming constraints of the session, and ended up sketching out our ideas on this using Java/Eclipse. Test Driven Development (TDD) • Structure: In this session, one of us wrote a test that failed, and then the other fixed the test and cleaned up the code. We then switched roles, repeating for the remainder of the session. We were instructed not to talk, but instead to only communicate via the code we wrote. • Team: I paired with someone who was familiar with using the “shoulda” framework which makes ruby unit tests more readable. I wasn’t as productive as I’d like to be, as I hadn’t yet before used the “class” related syntax of ruby, and also was not very familiar with how ruby responds to syntax errors. So we ended up talking as a pair related to questions regarding ruby syntax. Still, we were able to get several iterations of testing done.
• Technology: We used ruby for the language, “shoulda” and Test::Unit for testing framework, and TextMate for the IDE. 2 minute fix • Structure: One of us would write a test, and then the other would try to fix it in two minutes or less. If we didn’t finish, we used version control (everyone used git) to rollback the changes we’d done and then the same person tried again. If needed, the other person (who wrote the broken test) would attempt to pare down the scope of the test to make it possible to fix in 2 minutes. • Team: I paired with someone who knew Java/JUnit. We found that the first few tests we wrote were difficult to fix in the allotted time. The session helped us keep testable units at a bare minimum of size, and was also great pairing practice related to all the TDD related tools (IDE, testing library, etc.).
• Technology: We used Java/JUnit, with Eclipse for an IDE. Unlike the other sessions, for this session we used a laptop running MS Windows. Final implementation • Structure: We went back to the person we originally paired with and spent 45 minutes trying to recreate the application from scratch. • Team: I again paired with Mike. We were able to complete the domain model and a number of tests, but not the related Grails application. Within a few minutes after the session ended, Mike had added a few more tests and finalized the domain model implementation. A few days later he implemented the Grails part of the application. I then tweaked the Grails part a bit and posted it at https://bitbucket.org/bwestrich/conway-life-gg. • Technology: Groovy/Grails for application, JUnit for testing, IntelliJ for IDE. Reflections • It was interesting to learn how other people approached a particular problem, and the benefits of each. • Throwing away code five times within a single day was actually quite productive: We could iteratively improve our designs very rapidly as we weren’t constrained by early design decisions. Examples of such decisions included what to name the key domain objects (we evolved from ‘grid’ to ‘board’), and the responsibilities that each object should be (we evolved from allowing the cell to be able to calculate whether it was alive or dead to having the grid do this). • There was considerable ramp-up time when pairing due to differences in machine setup, language, IDE, and tools used, etc. • Only one team completed an implementation that could be demoed to the group: they implemented their solution in Ruby on Rails. • During the TDD session that used Ruby/shoulda, the ability to express the intent of test cases in plain English helped greatly with the communication, especially because we weren’t supposed to talk as pairs. • There was some skepticism on whether TDD was a productivity gain, though I sensed many participants didn’t have appreciable experience with TDD. In the particular example of our (Mike and my) implementation, the tests that were failing at the end of the session eventually led us to a simple error we’d made in parameter order. This error would have taken longer to resolve if we had not written tests. • Several participants mentioned they have gotten good results (in their workplace) using the mockito test framework.

Other notes

Ruby unit testing

1. installed dvm/ruby version 1.9(using curl command, for more info google: rvm.io). Note: wasn’t able to get sublime to use this version of ruby, so installed the ruby gems listed below into the 1.8 version of ruby.
2. installed shoulda (via admin account, as sudo) using: a. gem install shoulda-context b. gem install shoulda-matchers
3. Used Test:Unit and shoulda. For example, here is a minimal test: require 'test/unit' require 'rubygems' require 'shoulda-context' require 'shoulda-matchers' require '../app/cell'

class TestCell < Test::Unit::TestCase context "new cell" do setup do @cell = Cell.new end should "not be alive by default" do assert @cell.alive == false end end end

Groovy grails mercurial commands IDE: Groovy Grails ToolSuite (from SpringSource) Creating a local repo • Right click, Team, Mercurial, ……. Pushing committed changes back to the public repo (requires ssh public key) • cd …../workspace-ggts-3.1.0.RELEASE/conway-life-gg • hg push ssh://[email protected]/bwestrich/conway-life-gg