I was pairing with a colleague and we had one of these experiences. We both looked at the section of code in question and knew there should be a more “rubyesque” way.

The original code looked something like the following:

1
2
3
4
5
6
7
8
9
10
11
12
13

node = {
  "webserver" => {
    "users" => {
      "admin" => {
        "password" => "some amazing password"
      }
    }
  }
}

if node['webserver'].member?('users') && node['webserver']['users'].member?('admin') && node['webserver']['users']['admin'].member?('password')
  defaults['password'] = node['webserver']['users']['admin']['password']
end

This is a pretty common use case, especially as we are consuming JSON resources that have several levels deep. You can search StackOverview and find any number of solutions. The solution isn’t complex and, while you can certainly download any number of gems to provide a solution, it turns out it only take a few lines of ruby to implement a nested search method.

After writing this post I came across a Gem called deep_fetch which provides a slightly different implementation. Rather than rename the methods throughout this post I wanted to give them a nod for a ready-made gem that provides the same basic functionality.

One Possible Solution

First, this isn’t the only way to solve this problem. That is the beauty of Ruby, there are many ways to implement smart solutions to common problems. Now, lets dive in.

After a brief conversation we decided we wanted our solution to accept any number of keys, returning the value for the last key or false.

1
2
3
4
5

node.our_custom_search('webserver', 'users', 'admin', 'password')
#=> "some amazing password"

node.our_custom_search('webserver', 'users', 'jdoe', 'password')
#=> false

I like to start by looking at what methods we already have access to. Since we are working with a Hash object I went to the Ruby docs and saw that #fetch looked promising. The #fetch method allows you to provide a key, either a String or Symbol, and receive it’s value. The reason #fetch is ideal for our solution is that you can optionally provide a default value in the event that the provided key doesn’t exist. An exception is raised if you do not provide a default value and the key does not exist.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# Test Hash
person = { name: 'Dan Reedy', website: 'http://reedy.in' }

# Valid Fetch
person.fetch(:name)
#=> 'Dan Reedy'

# Invalid Fetch without a default
person.fetch(:email)
#=> KeyError: key not found: :email

# Invalid Fetch with a default
person.fetch(:email, nil)
#=> nil

Playing off of the name of this method we decided to name our solution #deep_fetch.

Let’s be Good Testers

With the usage defined it is time for test. Since I want to use standard libraries the MiniTest module will be the testing framework¹.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

require 'minitest/autorun'

describe Hash do
  before do
    @hash = {
      'webserver' => {
        'users' => {
          'admin' => {
            'password' => 'some amazing password'
          }
        }
      }
    }
  end

  describe '#deep_fetch' do
    it 'returns the correct value for the provided keys' do
      @hash.deep_fetch('webserver','users','admin','password').must_equal 'some amazing password'
    end
    it 'returns false if the provided keys do not exist' do
      @hash.deep_fetch('webserver','users','jdoe','password').must_equal false
    end
  end
end

Running the test will result in the expected failures.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

Run options: --seed 25720

# Running:

EE

Finished in 0.001193s, 1676.4459 runs/s, 0.0000 assertions/s.

  1) Error:
Hash::#deep_fetch#test_0001_returns the correct value for the provided keys:
NoMethodError: undefined method `deep_fetch' for #<Hash:0x007f944c0ee6f0>
    deep_merge.rb:26:in `block (3 levels) in <main>'


  2) Error:
Hash::#deep_fetch#test_0002_returns false if the provided keys do not exist:
NoMethodError: undefined method `deep_fetch' for #<Hash:0x007f944c0ed1b0>
    deep_merge.rb:29:in `block (3 levels) in <main>'

2 runs, 0 assertions, 0 failures, 2 errors, 0 skips

Implementing the #deep_fetch method

With the knowledge that we are going to take a collection of keys and reduce that down to a single value I chose to use the Enumerable#reduce method for looping. The added benefit with #reduce is the ability to assign the initial value of the memo block variable to self.

1
2
3
4
5
6
7

Hash.class_eval do
  def deep_fetch(*keys)
    keys.reduce(self) do |memo, key|
      memo.fetch(key)
    end
  end
end

This is enough for the first test to pass.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Run options: --seed 60473

# Running:

.E

Finished in 0.001141s, 1752.8484 runs/s, 876.4242 assertions/s.

  1) Error:
Hash::#deep_fetch#test_0002_returns false if the provided keys do not exist:
KeyError: key not found: "jdoe"
    deep_merge.rb:8:in `fetch'
    deep_merge.rb:8:in `block in deep_fetch'
    deep_merge.rb:7:in `each'
    deep_merge.rb:7:in `reduce'
    deep_merge.rb:7:in `deep_fetch'
    deep_merge.rb:31:in `block (3 levels) in <main>'

2 runs, 1 assertions, 0 failures, 1 errors, 0 skips

The #fetch method raises an exception if a key isn’t found. In our implementation we decided that we wanted false if the keys do not exist, so the staight forward solution is to capture the KeyError exception and return false.

1
2
3
4
5
6
7
8
9

Hash.class_eval do
  def deep_fetch(*keys)
    keys.reduce(self) do |memo, key|
      memo.fetch(key)
    end
  rescue KeyError
    false
  end
end

That’s it! Nine lines of code and we have a method to dive deep into nested hashes and pull out values.

But wait…there’s more!

There are two ways I think we can improve this method.

Specify a default value if the key isn’t found

First, I think it would be nice to specify the default value, much like the actual #fetch method. Rather than returning false the code will let the KeyError be raised if there isn’t a default. First update the test.

1
2
3
4
5
6
7
8
9
10
11
12
13

# ... the setup code ...
describe '#deep_fetch' do
  it 'returns the correct value for the provided keys' do
    @hash.deep_fetch('webserver','users','admin','password').must_equal 'some amazing password'
  end
  it 'raises KeyError exception if the provided keys do not exist' do
    -> { @hash.deep_fetch('webserver','users','jdoe','password') }.must_raise KeyError
  end
  it 'returns the provided default value if the key does not exist' do
    @hash.deep_fetch('webserver','users','jdoe','password', default: false).must_equal false
  end
end
# ... the rest ...

This results in a new failure.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Run options: --seed 47519

# Running:

.E.

Finished in 0.001223s, 2452.9845 runs/s, 1635.3230 assertions/s.

  1) Error:
Hash::#deep_fetch#test_0003_returns the provided default value if the key does not exist:
KeyError: key not found: "jdoe"
    deep_merge.rb:8:in `fetch'
    deep_merge.rb:8:in `block in deep_fetch'
    deep_merge.rb:7:in `each'
    deep_merge.rb:7:in `reduce'
    deep_merge.rb:7:in `deep_fetch'
    deep_merge.rb:40:in `block (3 levels) in <main>'

3 runs, 2 assertions, 0 failures, 1 errors, 0 skips

Now to make it pass. I’ll take advantage of Ruby 2’s keyword arguments for this example.

1
2
3
4
5
6
7
8
9

Hash.class_eval do
  def deep_fetch(*keys, default: false)
    keys.reduce(self) do |memo, key|
      memo.fetch(key)
    end
  rescue KeyError
    default.nil? ? raise : default
  end
end

Allow #deep_fetch to locate values by a key path

Developers who spend time with Objective-C’s dictionaries or the various other implementations of Key-Value stores will be familiar with the idea of a key path. Simply put it is a string of dot separated keys³. Rather than changing the existing method, we will create a new method called #fetch_keypath which will leverage deep_fetch behind the scenes.

As always, test first.

1
2
3
4
5
6
7

# ... Setup & other tests ...
describe '#fetch_keypath' do
  it 'returns the correct value for the provided keypath' do
    @hash.fetch_keypath('webserver.users.admin.password').must_equal 'some amazing password'
  end
end
# ... the rest ...

Then code the solution. The internals of this method will rely on the splat operator again. This time it is used to pass the elements within the array as individual arguments rather than a single argument.

1
2
3
4
5
6
7

Hash.class_eval do
  # ... #deep_fetch method

  def fetch_keypath(keypath)
    deep_fetch(*keypath.split('.'))
  end
end

Adding the optional default value is trivial at this point.

1
2
3
4
5
6
7
8
9
10
11
12
13

# ... Setup & other tests ...
describe '#fetch_keypath' do
  it 'returns the correct value for the provided keypath' do
    @hash.fetch_keypath('webserver.users.admin.password').must_equal 'some amazing password'
  end
  it 'raises KeyError if the provided keys do not exist' do
    -> { @hash.fetch_keypath('webserver.users.jdoe.password') }.must_raise KeyError
  end
  it 'returns the provided default value if the key does not exist' do
    @hash.deep_fetch('webserver','users','jdoe','password', default: 'Key Missing').must_equal 'Key Missing'
  end
end
# ... the rest ...

And the updated #fetch_keypath method

1
2
3

  def fetch_keypath(keypath, default: false)
    deep_fetch(*keypath.split('.'), default: default)
  end

You can grab the tests and code for this blog at Github. Also, thanks to Travis Longoria for the inspiration.

I believe one of the most overlooked “core” skills that a student should learn is version control. Many tools (and some operating systems) come with some kind of revision system built-in, but anyone serious about development needs to have a firm grasp on how to manually handle versioning in their projects.

When I hire a new student developer to work with me at my day job the first several weeks are spent on introductory training and we hit on aspects of version control using Git throughout the process. There are lots of great resources to teach and explain Git. My favorites include the Try Git course at Code School, the Pragmatic Guide to Git, and the Pro Git book are my top three recommended sources.

If you aren’t intimately familiar with Git, especially using the command line interface, I would encourage you to take the time to dive in. Get to know the basic commands by heart and remember that it is always acceptable to refer to the documentation if you forget a command or argument. It’s more important to do it, than to have it memorized.

If you are interested you can take a look at my slides for the presentation to TechDawgs. And remember, Version control will save your life!

Over time our implementation failed for a variety of reasons, mostly due to improvements to Ruby and the Rails framework. The most recent issue hit us with Rails version 3.2.x and completely broke the code. Remedying the issue require rewriting the validation aspects of the code.

Before looking at the fix, I’ll describe how the dynamic forms work. From the administrative section a new Form can be created. A Form has many FormComponents that define the various questions and accepted answers. A FormResponse then takes the questions and answers provided and saves it as an “isolated” snapshot. This allows the form to be updated at-will but does not break the history of responses. For example, a particular option may no longer be available or a question from a form my be removed entirely.

1
2
3
4
5
6
7
8
9
10
11
12
13

class Form < ActiveRecord::Base
  has_many :form_components, dependent: :destroy
  has_many :form_responses, dependent: :nullify
end

class FormComponent < ActiveRecord::Base
  belongs_to :form
end

class FormResponse < ActiveRecord::Base
  belongs_to :form, include: :form_components
  has_many :form_components, through: :form
end

A FormComponent can be any of the standard form elements, including selects, check boxes, and radio buttons. Accepted answers are stored in a comma separated list and the form is rendered using Rails standard form helpers. Additionally, a form component can be determined to be required, accepted, or match a specific regular expression.

The following code snippet shows creating a FormComponent called full_name that is a required field within the form.

1
2
3

@form = Form.first
@form_component = @form.form_components.build(kind: 'text_field',
             required: true, question: 'full_name', label: 'Your Full Name')

There are three hurdles to jump for this to work.

1. We don’t know what the questions are going to be for a given form in advance.
2. The answers need to presented to the visitor in a form that will be saved in a FormResponse.
3. FormResponse needs to run the validations defined in FormComponent

The code to display the form fields is relatively straight-forward. Here are the relevant pieces.

1
2
3
4
5

def new
  # @form is defined either by a param or UUID, etc...
  @form_response = FormResponse.single_response_for(@form) # I'll discuss this soon
  respond_with(@form_response)
end

1
2
3
4
5
6
7

= form_for @form_response do |f|
  %fieldset
    %legend Form Fields
    = f.hidden_field :form_id, @form_response.form.id
    - @form_response.form_components.each do |component|
      = render partial: component.kind locals: { f: f, component: component }
  = f.submit

To keep things DRY I’ve created a view partial for each kind of form component. Using the example FormComponent from earlier, this form would use the _text_field.html.haml partial which looks like this.

1
2

= f.label component.question, component.label
= f.text_field component.question

The other partials are not much more complicated and I am looking forward to the Rails 4 #collection_check_boxes method, which I think can clean them up even more. That is all that’s required to display the form for submission. Clicking submit will send the following parameters to FormResponse#create.

1

{form_response: { form_id: 1, full_name: 'Dan Reedy' } }

1
2
3
4
5
6
7
8
9
10
11

def create
  @form = Form.includes(:form_components).find(params[:form_response][:form_id])
  @form_response = FormResponse.single_response_for(@form)
  respond_with(@form_response) do |format|
    if @form_response.save
      # Send an email, redirect, or do other stuff
    else
      # Display the form again with error messages
    end
  end
end

The FormResponse#create action uses the same #single_response_for¹ method that we used in new. To understand what is happening we have to look at the FormResponse class.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

class FormResponse < ActiveRecord::Base
  def self.dup(&block)
    super.tap do |dup|
      def dup.name() FormResponse.name end
      dup.class_eval(&block)
    end
  end

  def self.single_response_for(form)
    block = Proc.new do
      form.form_components.each do |component|
        method = component.question.to_sym
        attr_accessor method
        validates_presence_of method if component.required?
        validates_acceptance_of method if component.acceptance?
        if component.format.present?
          validates_format_of method, with: Regexp.new(component.format)
        end
      end
    end
    dup(&block).new(form_id: form.id)
  end
end

It looks like a lot is happening in #single_response_for but it isn’t doing anything overly complex. It starts by creating a Proc that will be sent to dup at the end. The Proc is where all the unique methods and validations for this instance of FormResponse will be defined.

Inside the Proc each FormComponent for that Form is used in attr_accessor and, depending on the options, any of the standard Rails validations.

Once the Proc is defined it is passed to the dup method, which we override to pass our custom block into the shallow copy of FormResponse. The result is a unique instance of FormResponse with attributes and validations defined by FormComponent.

1
2
3
4
5
6
7
8
9
10
11
12
13

# Instantiate with #new
> @form_response = FormResponse.new
=> #<FormResponse id: nil, form_id: nil, answers: nil>
> @form_response.valid?
=> true

# Instantiate with #single_response_for
> @form_response = FormResponse.single_response_for(Form.first)
=> #<#<Class:0x007f939a770210> id: nil, form_id: 1, answers: nil>
> @form_response.valid?
=> false
> @form_response.errors?
=> #<ActiveModel::Errors:0x007f939a610b40 @base=#<#<Class:0x007f939a770210> ..., @messages={:full_name=>["can't be blank"]}> 

Solving this problem highlights many of the things I love about the Ruby language. If you’ve solved this issue another way, think this was terrible, or otherwise have a comment, please share!

It’s fun to go back and look at that early code. It was aimed at being an absolute beginners guide to starting a Ruby on Rails project. The images are no longer available and I would be hard-pressed to find them in my digital archives, but the content is intact.

Most of the time the questions are the result of differences between Rails 3 and what I am guessing to be Rails 1.x. When I wrote that tutorial the through: option had just been added! However, What always surprises me is there seems to be a decent number of people who are not grasping the most basic concepts, despite the availability of great books¹

I’ve been considering re-writing this tutorial to reflect the changes in Rails 3.2.x but tend to stop when I look at the landscape of great beginner resources, the least of which are the well written Ruby on Rails Guides². It seems, though, that maybe some dead simple beginning tutorials might be helpful for people looking for the concepts rather than the full techniques. This is what Code School³ is great at, but for quick reference it is difficult to hunt through their slides and not everyone will pay for access.

I am regularly training brand new developers, typically students with little to no previous experience in any web development. I plan take with some of our initial conversations related to setup, design, and implementation and turn them into short tutorials. I think I’ll start with a refresh of that 6 and a half year old(!) tutorial on basic relationships.

I’ve settled on a format I like and used it in the previous post. If I am commenting on a specific article or site I will reference it and provide a link within the first paragraph. Beyond that any links to other resources will occur as footnotes for the post. if you wish to jump to the footnote you certainly may, but by providing all external links in one spot I hope you will read through the whole post before flipping away to another page.

This post is primarily to remind myself of this decision for future writing. Also, to my future self who is reading this, don’t over-think it, just write.

Perhaps it is because my chosen field is relatively young, we do not have the luxury of 200+ years of speeches to pull from as is the case in The West Wing, or perhaps its because the greatest developers are often hidden behind their code. There are certainly a few cases that disprove my point. Many in the Ruby community look to _why¹ and all the work he did in advocating Ruby, quoting from his Poignant Guide². The recent suicide of Aaron Swartz has pulled people to his writing³ and I’ve seen many quote his work. I think we’ll see even more of this as the Save Publishing⁴ bookmarklet continues to gain users. However, most developers won’t spend time reading lengthy writing by other programmers. However, with social coding sites we are seeing a different trend emerge.

Just like the great speech writers of history who spend hours reading historical speeches, reciting inauguration addresses, and listening to world leaders, we developers spend our time looking through shared repositories on sites like Github, Bit Bucket, and Google Code. We line ourselves up with programmers who code like we want to code and practice making our code look like theirs. There are strong personalities in our profession and attached is an equally strong sense of style in development. The result is not verbatim quotes, but instead an alignment of coding style. All of our coding practices originated from someone’s idea, from how we name variables to whether we use presenter classes to any other number of development choices. What is important is that we do not stifle our own voice while learning from these greats.

I don’t spend as much time as I would like reading speeches and writings of histories greats, although I am interested in such things. I do, however, spend a lot of time reading the code of developers more talented than myself and I learn from them. We may not have hundreds of years to look back over, but we have a vast amount of knowledge we can look at now. Taking the time to dig in deeper, showing interest in the body of work we pull from, displays a passion for the process and a desire for greater understanding. This is important.

Both she and I like to cook. One result of the GAPS diet is that all the things I have become good at cooking are no longer legal options for our evening meals. Gone are the nights of whole-wheat pizza crusts or pancakes for supper. It’s taken some adjusting, and I will admit that I’ve been less than enthusiastic about the situation, but through this process my wife has demonstrated this passion to improve again and again. When faced with the question “What’s for dinner?” I am dumbfounded, suggesting “Eggs? Chicken?” whereas she is regularly searching for new and exciting ways to make our meals enjoyable. Often building upon a basic recipe using the knowledge she’s gained through this process. Eventually, she ditches the recipe and relies completely upon her expertise.

Recipes are interesting things. They act like safety nets for us when we’re just beginning. It’s wise to leverage them when we are getting started. This is as true in software development as it is in cooking. Some of the best beginning programming books available are called cookbooks or include the word recipe in the title. This books take common scenarios and provide a basic solution. Often times this is enough to satisfy the requirement and the programmer can then move onto another feature.

There’s a problem with recipes though. If you never deviate from the recipe then you aren’t really improving. You may get better at completing that recipe, but what if you never learn how to substitute ingredients, adjust the yield, or navigate an unexpected problem? Recipes are vital when you are starting, but they can hold you back.

This is what my wife is great at. She can take one or more recipes and improvise to create something better. As programmers we should do the same. Be aware of the recipes, the best practices, but do not limit yourself to them. Aspire to improve the recipes while understanding why they became the best practice.

What we do as developers isn’t always complicated. A large portion of what we do is converting database queries to HTML. It isn’t always glamorous or exciting, but we cannot give into the good enough mentality, that’s when we lose the passion to be great at what we do. Simple shouldn’t result in lazy. In Jiro Dreams of Sushi we see this at an extreme level. Sushi, only sushi, is prepared day in and day out at a level beyond what anyone else is doing. This doesn’t prevent the chef, Jiro, from evaluating every plate to understand what could improve.

Our challenge is to not settle back and use the same recipe over and over, never striving to improve. If you do use a recipe, make sure to tailor it to your own style and demands. A well established recipe aims for the widest adoption, which isn’t necessarily what you are doing in your development.

One of the key concepts is the idea of refactoring. Core to test driven development and essential to keeping your code DRY¹, this concept is often not even discussed in the introductory development courses or, if it is taught, is overlooked by the students. Simply defined, refactoring is the process of rewriting code to make it easier to maintain while not altering the behavior of the application. When done well you eliminate complexities while making the code easier to work with. As I look at the attributes of a great craftsmen I see two that can be attributed with refactoring; aspire to improve and maintain cleanliness.

The first weeks of employment of a new developer on my staff consists of going through online courses² and reading well-written books.³ Then, we spend some time pair-programming where we share one workstation with one of us driving and the other navigating.⁴ Through this process the new developer often gets their first taste of refactoring code. I have repeated this cycle many times as I train new developers and, the most recent time, I had the idea to document our refactoring for future reference.

Refactoring In Practice

The following is a summary of conversation and actions performed by myself and one of the student developers.

Our active user story⁵ was to provide date ranges for an application period, interview sign up period, and interview session period for an employment application feature of the website. The current implementation was displaying the beginning and ending dates on individual lines. You can also see that the interviews_begin_on and interviews_end_on attributes are optional.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# list_display is a helper for creating DL elements
# def list_display(label, content)
#   capture_haml do
#     haml_tag :dt, label
#     haml_tag :dd do
#       haml_concat content
#     end
#    end
#  end
%dl
  = list_display 'Apps Accepted Beginning', @ra_app_term.available_at.to_s(:typical)
  = list_display 'Apps No Longer Accepted', @ra_app_term.unavailable_at.to_s(:typical)
  = list_display 'Interviews Begin', @ra_app_term.interviews_begin_on.to_s(:long) if @ra_app_term.interviews_begin_on.present?
  = list_display 'Interviews End', @ra_app_term.interviews_end_on.to_s(:long) if @ra_app_term.interviews_end_on.present?

Our customer⁶ requested we simplify this display, using a format similar to “10/01/12 - 10/09/12”. The first step is to write a our failing test⁷ with the syntax we plan to use in our view. We also focus only on one piece at a time, so we start with available_at and unavailable_at. We plan to create a method called application_period, so we add the following test.

1
2
3
4
5
6

context "displaying date periods" do
  subject { ra_app_terms(:spring_2013) }
  describe "#application_period" do
    its(:application_period) { should == "09/01/12 - 10/14/12" }
  end
end

Predictably, this test fails since we’ve not created the application_period method. So, we switch to the model and add the method.

1
2
3

def application_period
  "#{self.available_at.to_s(:us_date)} - #{self.unavailable_at.to_s(:us_date)}"
end

Our test now passes so we move to the next set of attributes related to interview sign ups. Switching back to our spec file we add another test.

1
2
3

describe "#interview_sign_up_period" do
  its(:interview_sign_up_period) { should == "10/17/12 - 10/23/12" }
end

Skipping forward to making this test pass we add the interview_sign_up_period method to the model.

1
2
3

def interview_sign_up_period
  "#{self.interview_sign_up_at.to_s(:us_date)} - #{self.interview_sign_up_until.to_s(:us_date)}"
end

The test passes and the astute student points out that we could refactor these methods, simplifying the long term maintenance of our code. At this point he becomes the driver and updates the model.

1
2
3
4
5
6
7
8
9
10
11
12

def application_period
  display_date_period(self.available_at, self.unavailable_at)
end

def interview_sign_up_period
  display_date_period(self.interview_sign_up_at, self.interview_sign_up_until)
end

private
def display_date_period(first_date, last_date)
  "#{first_date.to_s(:us_date)} - #{last_date.to_s(:us_date)}"
end

We run our test which returns two passing examples. That’s refactoring in a nutshell. What happened next made this little change extremely important. The phone rang and it was our customer. He expresses that they’d like to add a notice to any applicant letting them know when the interview sign up period is using the format of “October 14 until October 23.” Our refactor meant we could focus our efforts on the new display_date_period method and not the individual date range methods.

I switched to the spec and add the following test and then hand the keyboard over to the student.

1
2
3
4
5
6

describe "#interview_sign_up_period" do
  its(:interview_sign_up_period) { should == "10/17/12 - 10/23/12" }
  it "allows optional date_format" do
    subject.interview_sign_up_period(date_format: :month_day).should == "October 17 - October 23"
  end
end

My student developer drives the following change to our model to handle the now optional date format.

1
2
3
4
5
6
7
8
9
10
11
12

def application_period(options={})
  display_date_period(self.available_at, self.unavailable_at, options)
end

def interview_sign_up_period(options={})
  display_date_period(self.interview_sign_up_at, self.interview_sign_up_until, options)
end

private
def display_date_period(first_date,last_date,options)
  "#{first_date.to_s(options[:date_format])} - #{last_date.to_s(options[:date_format])"
end

The model changes just made are a prime example as to why we write tests. After I kept quiet and let the tests run my student was surprised to see our previously successful tests were failing, while the new test passed. I pointed out to him that the output from the display_date_period method is expecting options[:date_format] to contain a value.

At this point I take the liberty to point out a couple of other Rubyisms we could use to better equip ourselves for future development. I explain the splat operator⁸, extract_options!, and join. These will each help us handle the latest request from the customer.

I take over as driver and update display_date_period method to handle an options hash.

1
2
3
4
5
6
7

private
def display_date_period(*dates)
  options = dates.extract_options!
  options[:date_format] ||= :us_date
  options[:separator] ||= ' - '
  dates.collect { |date| date.to_s(options[:date_format]) }.join(options[:separator])
end

We re-run the test suite and we have three passing tests. My student drives again and writes the next test to handle passing optional joining text.

1
2
3
4
5
6
7
8
9

describe "#interview_sign_up_period" do
  its(:interview_sign_up_period) { should == "10/17/12 - 10/23/12" }
  it "allows optional date_format" do
    subject.interview_sign_up_period(date_format: :month_day).should == "October 17 - October 23"
  end
  it "allows optional separator" do
    subject.interview_sign_up_period(separator: ' until ').should == "10/17/12 until 10/23/12"
  end
end

The previous update to display_date_period set the method up to handle an optional separator being defined, so our new tests run without any issue. My student, interested in seeing whether my code would actually handle multiple options adds one additional test.

1
2
3
4
5
6
7
8
9
10
11
12

describe "#interview_sign_up_period" do
  its(:interview_sign_up_period) { should == "10/17/12 - 10/23/12" }
  it "allows optional date_format" do
    subject.interview_sign_up_period(date_format: :month_day).should == "October 17 - October 23"
  end
  it "allows optional separator" do
    subject.interview_sign_up_period(separator: ' until ').should == "10/17/12 until 10/23/12"
  end
  it "allows multiple options" do
    subject.interview_sign_up_period(date_format: :month_day, separator: ' until ').should == "October 17 until October 23"
  end
end

The test results all come back green, 5 passing tests. I mention that we haven’t written the test to handle the interview session period. Our initial story requested this feature for application period, interview sign up period, and interview session period. Before I finish talking the student has already written the next test.

1
2
3

describe "#interview_period" do
  its(:interview_period) { should == "10/25/12" }
end

We both notice a problem. According to the original design it is optional to have an end date for the interview period. Our test fixture had a value for interviews_begin_on but had a null value for interviews_end_on. We know the first time running the test will fail because we haven’t defined interview_period, so we switch to the model to add that method. We also decide to handle null values within display_date_period, so that this model looks similar to the other specific date period methods.

1
2
3

def interview_period(options={})
  display_date_period(self.interviews_begin_on, self.interviews_end_on, options)
end

Now we have to determine the best way to handle the possible null date attribute. I suggest we run our test to see what errors we get. The error is wrong number of arguments(1 for 0) in #to_s. I point out that if you call to_s on a null value the result is an empty string. However, unlike the to_s method of a Date or Time object, you cannot provide an argument.

To correct this we can explicitly test that the provided value is a Date or Time object or we can use an inline rescue to handle the exception. I take over driving and use the inline rescue to demonstrate another Rubyism.

1
2
3
4
5
6
7

private
def display_date_period(*dates)
  options = dates.extract_options!
  options[:date_format] ||= :us_date
  options[:separator] ||= ' - '
  dates.collect { |date| date.to_s(options[:date_format]) rescue nil }.join(options[:separator])
end

We run the test suite and our test it fails on our expectation and not because of an exception. The returned result was "10/25/12 - " which means our null value is being accounted for in the join method. We open Ruby-doc.org and look into Array methods to strip out a null element and find two that would work: reject and delete_if. Because we do not need the behavior to be destructive we go with reject and use the proc shortcut⁹ with the blank? method to check for null values.

1
2
3
4
5
6
7

private
def display_date_period(*dates)
  options = dates.extract_options!
  options[:date_format] ||= :us_date
  options[:separator] ||= ' - '
  dates.reject(&:blank?).collect { |date| date.to_s(options[:date_format]) rescue nil }.join(options[:separator])
end

All the tests are now passing. The student, ready to continue with adding edge cases asks “What happens if they pass more than two dates?” and reaches for the keyboard to start driving our next test. I quickly put the proverbial brakes on. We could spend the rest of the day working to accept every possible combination of arguments, but as it stands now we have refactored redundant code and have met the customer’s request. We instead switch gears and update the view to use the new methods.

1
2
3
4

%dl
  = list_display 'Application Period', @ra_app_term.application_period
  = list_display 'Interview Sign-up Period', @ra_app_term.interview_sign_up_period
  = list_display 'Interview Period', @ra_app_term.interview_period

We pull open the page in our browser and everything works as expected. The final step is to add the notice to applicants that they can sign up for an interview.

The previous example was relatively simple, but it is a scenario I see many times while teaching new developers. We refactored early in the process and because we did when the code was still simple, adding more complexity was relatively simple. Ultimately, this could have been handled by a presenter class to keep presentation out of the model and that is exactly what we did in a future update.

The Model

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

class RaAppTerm < ActiveRecord::Base
  # ... additional code

  def application_period(options={})
    date_period_display self.available_at, self.unavailable_at, options
  end

  def interview_sign_up_period(options={})
    date_period_display self.interview_sign_up_at, self.interview_sign_up_until, options
  end

  def interview_period(options={})
    date_period_display self.interviews_begin_on, self.interviews_end_on, options
  end

  private
  def date_period_display(*dates)
    options = dates.extract_options!
    options[:separator] ||= ' - '
    options[:date_format] ||= :us_date
    dates.reject(&:blank?).collect { |date| date.to_s(options[:date_format]) rescue nil }.join(options[:separator])
  end

  # ... additional code
end

The Spec

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

require 'spec_helper'

describe RaAppTerm do
  fixtures :ra_app_terms
  # ... additional code
  context "displaying date periods" do
    subject { ra_app_terms(:spring_2013) }
    describe "#application_period" do
      its(:application_period) { should == "09/01/12 - 10/14/12" }
    end
    describe "#interview_sign_up_period" do
      its(:interview_sign_up_period) { should == "10/17/12 - 10/23/12" }
      it "allows optional date_format" do
        subject.interview_sign_up_period(date_format: :month_day).should == "October 17 - October 23"
      end
      it "allows optional separator" do
        subject.interview_sign_up_period(separator: ' until ').should == "10/17/12 until 10/23/12"
      end
      it "allows multiple options" do
        subject.interview_sign_up_period(date_format: :month_day, separator: ' until ').should == "October 17 until October 23"
      end
    end
    describe "#interview_period" do
      its(:interview_period) { should == "10/25/12" }
    end
  end
  # ... additional code
end

With that out of the way, let’s get to the sophomore album, released today, by Mumford and Sons. Babel is fantastic. True to the original sound they established on Sigh No More. Each track has fresh instrumentation and the vocals are simple and point to issues that resonate in each of us.

I appreciate the confidence Marcus Mumford has in approaching subject matter such as faith, life, and death. In several instances the vocals stand with minimal accompaniment and express themselves powerfully. On more than one occasion I replayed pieces of a track to really listen to what was being said.

I, poorly, play the banjo and am I huge fan of Winston’s command of the instrument. Do yourself a favor and listen attentively to how precise and technical his playing is, you won’t be disappointed.

If you have a Spotify account, give the album a listen. Then go buy it. These guys are the real deal and I hope they continue to be supported to make great music.

There’s this movie, Jiro Dreams of Sushi, which has me thinking about how I conduct myself as a professional. Jiro is a sushi chef. Only sushi. His restaurant does not serve drinks or appetizers, only sushi. He is serious about Sushi. He wasn’t a good father, he wasn’t a good husband, he wasn’t good at a lot of things, but he was serious about making sushi. Not to say he was bad at all those things, though the documentary certainly illustrates some of his failures, they just were not his primary goal.

Developers like conferences. I’m not entirely sure why. Perhaps we like to reassure ourselves that we aren’t crazy. Maybe we just like to have an excuse to travel. Whatever the reason, we descend on a city with reckless abandon. I was in Chicago recently for WindyCityRails 2012, a two-day conference for Rails developers. At the end of the two days I wondered if it was worth attending.

Since 2005¹ I have spent nearly all of my time developing using the Ruby language and the Rails framework. In that time it has become a darling language of agile developers and startups. A problem started to emerge though. Through several successes and even more eccentric personalities, Ruby developers started being called Rock Stars and Ninjas².

At one point in my life I wanted to be a rock star³. I had long hair⁴. I liked ninjas. I watched dubbed kung fu movies and wore black T-shirts. I’m down with rock stars and ninjas. The thing is, I’ve grown up. I’ve, theoretically, matured. I don’t want to be a rock star anymore. Ninja are still mesmerizing, but primarily because I have a young son.

At WindyCityRails the background on one presenters computer was himself giving his webcam the finger⁵. Another attempted to give a live demonstration without much success but with much cursing under his breath. A third was successful in his live demo, but what he showed was how to pour a beer⁶.

I mention these three presenters not to ridicule or say they were wrong. It’s not easy to present, I know, I’ve been a presenter at conferences on several occasions. The reason I mention them is to illustrate that I left the conference feeling as though our industry doesn’t take itself seriously. That isn’t quite right though. I do think my industry takes itself seriously. So what was it about these presentations?

I’m an average photographer. I’m an average writer. I want to a great developer. I want to be perfect, though I know that is impossible. I take my aspirations seriously. I read through repositories on Github. I follow developers on twitter. I watch screencasts, I read blogs, and review⁷ books. I do these things in the interest of becoming a better developer.

Those presenters weren’t bad. They didn’t do anything wrong. The problem was within me. I went to WindyCityRails wanting to walk away with knowledge that would make me a better developer. That is not what I received. Instead, I made some new professional connections, shared some war stories with new developers, and laughed at humorous improv comedy. My expectations were wrong to begin with but I was serious about my goal. The marquee names did not deliver toward my goal and I left feeling let down. That was the fault of my expectations. The interactions with others made the conference a success and worth attending and that should have been enough.

So, what should I do? For starters, I created this blog. I established the entry page for reedy.in while at that conference. I starting thinking about topics. I mulled over the tone, I questioned my abilities to write, and then I simply got started.

Next, I’ve resolved to be serious about what I do, but for the right reasons and at the right time. I am fortunate to have opportunities to teach students⁸ about Ruby on Rails, often times with zero prior knowledge of the language or framework, and I hope to plant in them the desire to become craftsman, not just programmers. University is a chance to make mistakes and learn. I want them to take the opportunity seriously. It is also a chance to have fun and experiment, so I plan to give them a place to make the mistakes that we have all had to learn from as developers. Being serious for the right reasons, at the right time.

When I present, I plan to take the opportunity seriously and focus on the message, not on me. If the presentation doesn’t inform, educate, and inspire then it isn’t worth doing. I would like to present at more conferences, specifically industry conferences. So far I have presented at several small, local conferences and events related to higher education. I have a difficult time deciding on what topic I’d like to present and I think this blog might help me identify that. I am not that interesting of a person but I like interesting things. Those interesting things should be in the foreground.

At WindyCityRails, I would have done well to ask myself “Why So Serious?”⁹ The answer might have surprised me and I now, after having written this blog, I will set my expectations with a better set of criteria. Crafting not only the code I write, but myself as a person.

In 1996 I would ride my bike to place called The Education Technology Center, a public computer lab. I was fourteen. It wasn’t very far from my house and on July 5 I was waiting at the door when it opened for the day. The day before they were closed for Independence Day and I’m sure I had a fine holiday with friends and family, but I was anxious to get back to lab.

You see, when I was born I wasn’t the only “new” thing in our house. Around the time I was born my Dad bought an Atari 400. Sure, it took me a few years to gain the ability to use it, but growing up with that beige box hooked up to an old cathode ray tube TV meant that I never knew life without a computer; I never knew life without this sound³.

As I rode my bike to the Education Technology Center I thought about all the things I would do online that day. It was a different web then. There was no Google, Yahoo! was a startup, there was no dot-com bubble. It was young, it was like me. I checked into the lab and the attendant, himself only a few years older than me, told me about this new service where anyone could get a free email address. Until this point I functioned online without such a thing. But here I was, one day after this free service, Hotmail⁴, began offering an email account to anyone and I was faced with a decision…What address do I choose?

One year prior a film came out that, for better or worse, shaped my online persona. Hackers, a movie with questionable ties to any sort of reality, took this beige box that I had grown up with and gave it life beyond 8-bit games. Sure, we’d used our Atari and connected to bulletin board systems using a 300-baud modem, but what this movie showed was something beyond that. It provided inspiration.

I chose poorly…I chose o2kuwl.

I’m not proud about it. I could have had my pick of nearly any account name. Instead, in an attempt to be unique but still pay homage to the movie that so influenced me, I made a terrible choice. But I was inspired to make that choice and for many years that was my identify. Email, IRC, chatrooms, forums, and anywhere else. I was o2kuwl. I made a choice because I was inspired and I lived with it…for awhile anyway.

Another movie has inspired me lately. This one doesn’t have over the top visuals or unrealistic depictions of hacking the gibson⁵. Instead, it’s about one man’s quest for perfection. In Jiro Dreams of Sushi, Jiro attempts to make perfect sushi, knowing full well that such perfection is impossible. He is a 職人⁶, and strives to make those around him one as well, no matter the cost. This devotion to his craft has made me question my commitment to my own profession. I spend much of my day working with simple tools to make a product that is uniquely crafted to a specific need, much like Jiro. The result of my work is not beautifully plated sushi, but instead “hand-crafted” web applications. Clean code.

Jiro, aside from providing another reason to desire a trip to Japan, has inspired me to look at what I do with a critical eye. He has also inspired me to write this and what I hope will become regular entries on this site. There is much to learn from master craftsman from professionals other than our own and I am not the first to recognize the links between developers and chefs⁷. Whether this is simply for me or if you, the reader, gain something from this is ultimately irrelevant. What matters is inspiration has struck and it’s time to act.

In Jiro Dreams of Sushi, Masuhiro Yamamoto provides five attributes of a great chef. I believe they can be extended beyond that just chefs and I will use them as the basis for future entries. They are

1. Take your work seriously
2. Aspire to improve
3. Maintain cleanliness
4. Be a better leader than a collaborator
5. Be passionate about your work.

Certainly something to think about…