If you can ski in it, you can ride in it

People give you strange looks when you tell them you rode in to work on your bicycle when it’s -10 degrees celsius outside. But these same people don’t think it’s odd to head out to the ski hill in the same weather, bundle up, sit on a cold chair suspended 50 feet above the ground for 15 minutes, race down a snowy hill at high speed, rinse, repeat. All the same rules regarding layering, clothing materials and equipment that help keep a downhill skier comfortable in low temperatures also apply while biking in the city. If anything, biking is easier due to the fact that you’re always moving. By the time I get to work (a 12km ride) I’m always hot & sweaty, regardless of the outside temperature.

Studs are your bestest friend ever

Last year I commuted in the winter on a mountain bike with studded tires (Schwalbe Snow Studs, if you must know). These are what I’ll call “half-assing it” as far as studded tires are concerned. The Snow Studs have two rows of carbide studs that aren’t always touching the ground (this is by design). The end result for me was a few wipe outs, and a lot of dainty route-choosing ballet. One morning while attempting to negotiate a particularly icy section of path (behind Rocky View Hospital) I was passed by a guy riding on real studded tires like I was standing still and he didn’t even notice there was ice on the ground. Lesson learned. This year I’ve resolved to upgrade to some Schwalbe Marathon Winters, which are a little more serious as far as stud count is concerned.

Some maintenance may be required

With all the crap that gets on the road in the winter months, it’s no surprise that some of it ends up on your bike. If I didn’t clean the bike off after at least every couple of rides I’d have a seized up chain and poorly performing derailleurs on my hands. Now, I have nothing against cleaning, but doing it in your garage in the winter cold is really shitty.

Big hills don’t mix well with icy brakes

My mountain bike had a set of “standard” rim brakes, just like most 10 year old $500 bikes do. These were more than enough in the summer, but get a little ice and snow on your rims and suddenly big fast downhills aren’t so much fun.

So what did I do about it?

I tried to address every one of these issues in one form or another:

• I got some new shoes (Five Ten Impacts) which help to keep the feet warm and with grip on icy pathways.
• I’ve been collecting Icebreaker merino wool clothing to wear during the ride. This stuff is not only warm, but it does not stink. Ever. It’s ridiculous how much this stuff doesn’t stink. Well worth the price, Icebreaker clothing has supplanted Patagonia base layers for me.
• Cheap ski goggles should help keep my face warm. I got a pair of cheap $20 goggles with clear lenses for when it’s dark out.
• Schwalbe Marathon Winters are at the bike shop ready to be picked up. I got a pair of 700c 35mms.
• As for the rest of the issues… I hope to have solved them with the Trek Soho:This bike has all the attributes I was looking for in a winter bike: Roller brakes and internal 8-speed hub are basically sealed to the elements, so there shouldn’t be any degradation in performance due to winter conditions. The more upright position and flat platform pedals should make me nice and stable, yet able to safely bail if things get sketchy. Plus it comes with fenders, a coffee mug, and has mounts for my Topeak rack. If it holds up well, it looks like the perfect bike (my fingers are crossed).

First off, let’s set this up. What I’m thinking is that a “software application” maps directly to a “home renovation project” or just actually building a new home. Here are some of the obvious parallels:

• In a home building project you have a general contractor who oversees the entire operation, hiring other contractors or bringing in employees as needed. Software projects will generally have some sort of equivalent “lead/architect” role.
• Both projects would have clients that most likely have no idea what’s going on. They see the end result and have no way of knowing whether that result will last 2 months or 2o years. Generally, as long as the finished product looks pretty and seems to do what’s required the developers/renovators will get paid.
• Size matters in both professions. Anybody can hack their way through installing new countertops or building a simple CRUD web app, but the bigger and more complex the problem gets, the more professionalism and care is required. I’ll take a calculated leap and say that many of the problem projects in both professions happen because somebody who can “install a new faucet” gets it in their heads that they can also “renovate the entire basement” using the same amount of knowledge and preparation.

I’m sure there’s a few more parallels, but you get the idea. Now let’s focus on some differences…

• A general contractor doing a home renovation will bring in “specialists” to work on individual pieces of the project, whereas many software projects are made up of “generalists”. As programmers, we are often tasked with developing business logic, writing html, security, usability, system administration, deployment, testing, etc. Just look at the range of what’s required in the average job posting for a software developer. This is obviously not true in all cases, but in general this is what I think is happening out there.
• The home building industry has these crazy things called “inspections” that are supposed to ensure the builders don’t pull some crazy shit that could endanger the client. Imagine code inspections (by an honest inspector we hope) and how they could protect a client… An inspector could obviously not be expected to know if the application is running a calculation correctly, but that is the one thing that a client can confirm. An inspector could, however, check for signs of incompetence such as SQL injection vulnerabilities, obvious spaghetti code, code duplication, lack of tests, poorly designed databases, mangled HTML, obvious usability disasters and so on. Once notified of the issues, the client would be able to take action as they see fit.

My thinking is that, at least in my own experience, the best project I’ve worked on (in terms of happiness of the client and its likelihood of being maintainable for years to come) was the project that was most similar to a successful home reno project. We had a UI specialist, a bunch of developers focused mainly on the business logic, and testers. Other “specialists” were brought in as needed for database tuning and system admin type work. An “inspector” even came to the project at one stage. This inspector was Eric Evans, who showed up and observed the project for a week and delivered a report on what was good and what could be improved. This visit seemed to be largely positive (I showed up a few months after he came so I can’t know for sure) in the sense that it gave the development team some reassurance and some focus on what could be improved. I’m not sure what the clients got out of it.

I’m wondering if a working on a new project with the goal of running it consciously more like a home reno project could improve things. For example:

• Think of hiring for “concerns” instead of technologies (ie; security & usability instead of Java & Struts).
• Have a defined “general contractor” role that is in place to hire and fit all the pieces together.
• Allow the specialists to come and go. There’s no need to keep everyone around all the time. Call them in when there is a need.

Based on my own limited experience I think doing software development as a home renovation could really work, especially when it comes to focusing on roles and quality. Should any project be open to an SQL injection attack ever? Hell no, there’s just no excuse for that kind of incompetence. But so many are… Inspections and specialists might be one way to mitigate this.

In closing, I’d like to hear other people’s thoughts on this. If it’s already been said before (better hopefully), I’d like to read more about it.

gem list -d gem_name
gem uninstall --install-dir ~/.gem/ruby/1.8 gem_name -a

The first one describes a gem, including the location in which each version is installed. The second will uninstall all versions of a gem from the specified location.

I fought hard for those.

• One factory per type of object being created
• Each factory has a createNewValid method that creates a valid object that can be saved to the database. This method does not persist the object.
• Each factory also has a createAnonymous method that calls createNewValid and then saves the object.

Rails has a number of plugins that do something similar, but object_daddy is the closest to what I was looking for. It follows the same pattern, calling the creation methods spawn and generate instead. It also allows you to customize the look of a valid object by letting you pass in a block that can modify the object’s state. This eliminates a huge problem with our implementation at CGI, where we had hundreds of slightly different createNewValid and createAnonymous methods depending on the scenario we were trying to set up.

Unfortunately I had a couple of problems with object_daddy. The first is that the generate method saves the object before it yields to a passed in block. Thus, when you call User.generate { |u| u.name = ‘Fred’ } you get an object with a name of Fred, but that name is not yet persisted. That was a minor issue, though.

I also had a problem when I tried creating multiple objects with object_daddy within the same setup. I would get an error stating that attributes had already been added for a class, and couldn’t figure out what the heck was going on. It could be just me (probably is), but I found the source code very hard to follow for something that should be pretty simple. Since I’m new to Ruby, I figured I’d just try doing it myself from scratch and maybe learn something in the process.

Enter object_mother. Right now it’s just about as basic as can be. I can think of numerous ways to improve it, but for now I’m pretty happy. Here’s the source in it’s entirety:

module ObjectMother
  class Factory
    @@index = 0
    def self.spawn
      raise 'No create method specified'
    end
    def self.populate(model)
      raise 'No populate method specified for ' + model.to_s
    end
    def self.to_hash(model)
      raise 'No to_hash method specified'
    end
    def self.unique(val)
      @@index += 1
      val.to_s + @@index.to_s
    end
    def self.unique_email(val)
      user, domain = val.split('@')
      unique(user) + '@' + domain
    end
    def self.create
      obj = spawn
      populate(obj)
      yield obj if block_given?
      obj
    end
    def self.create!(&block)
      obj = create(&block)
      obj.save!
      obj
    end
    def self.create_as_hash(&block)
      obj = create(&block)
      to_hash obj
    end
  end
end

All the major concepts are there; create equals createNewValid and create! is the same as createAnonymous. There’s also a create_as_hash method for converting a valid object to a params hash when you’re doing post :create type stuff in functional tests. Currently, you utilize the Factory by sub-classing in your rails app somewhere (I’m just using test_helper.rb for now). Here’s an example:

class AreaFactory < ObjectMother::Factory
  def self.spawn
    Area.new
  end
  def self.populate(model)
    model.name = unique('SW')
    model.city = CityFactory.create!
  end
end

The spawn method just creates a blank instance of the class each individual factory deals with and could definitely be inferred (baby steps, I’ll get to that once the annoyance factor gets higher). Overriding populate is where the attributes of a valid model object are set.

Overall, this is really just what I wanted, and the basic code is only a few simple lines of ruby. I’ll add some smarts in eventually (ie; inferring the class to spawn, creating hashes automatically, giving the user a default place to put Factories, making sure that passing blocks actually works), but for the time being I’m pretty happy.

If we could just always be honest with ourselves, as people, team members and organizations, software development wouldn’t be that hard.

There. Simple. Think about it for a second. All this stuff that we label and group together under methodologies and processes is really there so that we can do One Thing. This one thing, I’m assuming, is usually to create software that fulfills a need.

Let’s pretend that a software team has been assembled to create an application that fulfills such a need. They’ve chosen to use the XP methodology while writing this application. I’ll go through some of the tenets of XP and run them through my honesty filter:

1. Pair programming: The team realizes that people will come and go on a project for good (quit, fired, etc), or for short periods of time (maternity leave, vacation, illness, etc). They want to minimize the risk, so they make sure everyone is familiar with every piece of the code base. They also realize that sometimes even the best developers do stupid shit for no good reason, and believe that having two sets of eyes on the screen at all times will lessen the likely hood of this happening.
2. TDD: The team realizes that writing software is hard, and that stuff that worked last week will have to be changed this week. Since they want to ensure that stuff they worked on earlier still works when they make these changes, they write tests, and ensure that no code gets checked in unless all the tests are passing. They also hope that these tests provide some form of documentation to any developers (and perhaps users/clients) that may come later or who never worked on the feature originally.
3. Incremental design: The team realizes that there are unforeseen forces that may threaten a project at any given time. A big project entails a large amount of risk for both clients and developers. If features can be developed in incremental fashion, hopefully in an order representing the importance of each feature, then risks can be mitigated. The team is always working with a usable application, so that if something comes up that stops the project, at least the client will have something to work with.

Now obviously there is more to XP than what I’ve listed. The point is that those three things exist to handle a need that most teams, if they are really honest with themselves have:

1. Knowledge transfer. Nobody wants to have to rely on one person to get something done. Sooner or later, this always bites us in the ass. Pairing is one way to handle this.
2. Developed features continue working. Nothing is more frustrating (to users and developers) than having something that used to work perfectly stop working. Testing is one way to handle this.
3. The need to guarantee that something will come out of all the money we’re spending. What happens if the development shop you’ve contracted goes bankrupt before they’ve finished your application? Incremental design is one way to handle this.

Listen. We have methodologies and processes for a reason (I hope). Some of these processes may work for you. However, maybe only some parts of a process work for you. The point is, it’s not about the process. If you can understand why you’re using a particular piece of a process, you can assess whether it’s useful for your team. Who cares whether you’re doing XP, Scrum, Lean, Kanban, Waterfall, or Hack ‘n’ Slash. Those are just names. Identify your pain points, problems, worries, etc, and try to fix them. Honestly.

I have a Property model that has a has_one relationship with an Address model. I want to be able to CRUD these two objects as one single entity, however. Luckily, nested forms were recently introduced into Rails 2.3.2 and they seemed like they’d simplify the whole process. Which they did once I put everything together. First, my models:

class Property < ActiveRecord::Base
  def initialize(attributes=nil)
    super
    #we override the initialize method and ensure we always have 
    #an address instance created. This makes sure we don't get any
    #nil reference errors in our forms
    self.build_address unless self.address
  end
 
  #accepts_nested_attributes_for enables the property's address object
  #to be updated at the same time as the property object
  accepts_nested_attributes_for :address, :allow_destroy => true
end
 
class Address < ActiveRecord::Base
  has_one :property
  # the Address model has a :city string column that will get populated from
  # a drop-down list in our view
end

This is the basic stuff that any tutorial on nested forms in Rails will tell you about, with the exception of creating a default instance of the address in the property constructor. This is most likely specific to the has_one case. Most of the examples I have seen deal only with has_many, where behind the scenes rails creates an empty list and we’ll never end up with nil reference errors in our view. This was the first issue I had to solve. Now let’s move on to our new.html.erb view:

<% form_for @property do |f| %>
  <%= f.error_messages %>
  <p>
    <%= f.label :name, "Title" %>
    <%= f.text_field :name %>
  </p>
  <p>
    <% f.fields_for :address do |af| %>
      <p>
        <%= af.label :address_one, "Address One" %>
        <%= af.text_field :address_one %>
      </p>
      <p>
        <%= af.label :city, "City" %>
        <%= af.collection_select(:city, City.all, :name, :name) %>
      </p>
    <% end %>
  </p>
  <p>
    <%= f.submit 'Create' %>
  </p>
<% end %>

The trick here is to make sure you qualify the collection_select for cities with the specific fields_for instance. If you don’t, the form will render and appear to be ok until you post to the create action or view the generated source:

<p>
<%= af.label :city, "City" %>
notice how I've removed the af. qualifier on collection select, and added in a
new parameter :address. This is how most tutorials show you how to use it
The problem with this is that the rendered html does not generate properly for
our nested form scenario
<%=collection_select(:address, :city, City.all, :name, :name) %>
</p>

Once you qualify the collection_select helper properly, you should get generated html that looks like this:

<label for="property_address_attributes_city">City</label>
        <select id="property_address_attributes_city" name="property[address_attributes][city]"><option value="Lethbridge">Lethbridge</option></select>

Now when you post the form, Rails nested form magic just works. My controller looks just as you’d expect (ie; no different than the non-nested form scenario)

  def create
    @property = Property.new(params[:property])
    respond_to do |format|
      if @property.save
        flash[:notice] = 'Property was successfully created.'
        format.html { redirect_to(@property) }
      else
        format.html { render :action => "new" }
      end
    end
  end

Hopefully I’ve explained this properly. Feel free to ask questions in the comments if I haven’t.

Once I’d created a migration to add the new column to the user model, I needed to add the field on the corresponding view so it could actually be input by a user. Since clearance is installed as a vendor gem/engine (still not sure what the difference is) the view files are located in the vendor directory. I figured updating these files wouldn’t be good, since they’d be overwritten if I ever had to update and unpack the gem.

It turns out all I had to do was copy the view files into my app under the views/user/ directory. I could then modify the files at will, and they would be used by Rails instead of the vendor files. One other gotcha was to make sure to add the attr_accessible :name declaration in my user.rb file (so Rails can do a mass assignment of the posted form items). My user.rb ended up looking like this:

class User < ActiveRecord::Base
  include Clearance::User
  has_many :properties
  attr_accessible :name
end

My first order of business is to write functional tests on my controllers and views. For some reason I thought I’d give the tests (which inherit from ActionController::TestCase) descriptive class names like PropertiesDashboardTest instead of PropertiesControllerTest. I had tests running and passing before I renamed the test class, but then started getting this error:

RuntimeError: @controller is nil: make sure you set it in your test’s setup method.

It took me a while to realize that Rails auto-instantiates a controller instance based on the test name when you inherit from ActionController::TestCase. Since I don’t have a controller named PropertiesDashboard.rb, Rails can’t set one up in the test for me. Of course I’m doing this test-first, so a controller doesn’t even exist at this point. That also explains why my existing test started failing when I renamed it.