Mark Starkman

Musings of a long time computer geek

I am using the jQuery slideUp and slideDown transitions with a Twitter Bootstrap Well and while it was functional, it felt very jerky at the beginning of the slideDown transition and at the end of the slideUp transition. You can see an example of this here: http://jsfiddle.net/tWTB6/.

After doing some digging on the interwebs, I found several posts about how the css margin and padding properties could be creating this issue. Well, I tried those solutions and none of them worked for me. Then I noticed that the .well class from Twitter Bootstrap included the min-height property. So I overrode that property and set it to 0px and my problem was solved. Here is the jsFiddle that includes the solution: http://jsfiddle.net/MUVVh/1/.

Introduction

Metaprogramming is both fun and challenging all at the same time. Metaprogramming with Ruby is easier than some other languages due to its dynamic nature. However, testing metaprogamming code can be a real challenge especially covering various edge case scenarios. In these situations, I’ve come to appreciate RSpec Shared Examples to make testing metaprogramming code easier.

For the purposes of this post we’ll start with a simple Ruby class and modify it, along with the specs, to include metaprogramming and shared example.

The starting point

Let’s start with a simple class that defines one method that returns a string. This is a trivial example, but in the next section we’ll add some metaprogramming to allow the method to be created on initialization of the class.

1
2
3
4
5

class MyClass
  def my_method
    :my_method.to_s
  end
end

Here is the corresponding example that validates the functionality.

1
2
3
4
5
6
7

require 'spec_helper'

describe MyClass do
  it "returns 'my_method'" do
    MyClass.new.my_method.should eq("my_method")
  end
end

Adding the metaprogramming

Building upon the previous version of my_class, let’s enhance the code and the specs to define the method when the class is initialized. The method still returns a string that matches the method name.

1
2
3
4
5
6
7
8
9
10

class MyClassDynamic
  DEFAULT_METHOD_NAME = :my_dynamic_method

  def initialize(method_name = nil)
    method_name = DEFAULT_METHOD_NAME unless method_name

    method_definition = Proc.new { method_name.to_s }
    self.class.send(:define_method, method_name, method_definition)
  end
end

The specs for this class get a little more challenging, because we need to handle the case when there is no method_name passed in and when there is one passed in.

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

require 'spec_helper'

describe MyClassDynamic do
  it "creates the method with the default method name" do
    MyClassDynamic.new.should respond_to MyClassDynamic::DEFAULT_METHOD_NAME
  end

  it "returns the default method name as a string" do
    MyClassDynamic.new.send(MyClassDynamic::DEFAULT_METHOD_NAME).should eq(MyClassDynamic::DEFAULT_METHOD_NAME.to_s)
  end

  it "creates the method with the :dynamic_method" do
    MyClassDynamic.new(:dynamic_method).should respond_to :dynamic_method
  end

  it "returns :dynamic_method as a string" do
    MyClassDynamic.new.send(:dynamic_method).should eq(:dynamic_method.to_s)
  end
end

These specs are pretty straight forward. The first and the third examples ensure that the correct method is created. The second and fourth examples ensure that the method returns the correct string value.

What I don’t like though is the duplication of code. For each scenario I want to test I need to add two more examples. This will only further compound as the functionality of the code grows.

Adding some shared example

In order to DRY up the specs and to allow for easily adding other scenarios to test, I’m going to implement RSpec Shared Examples.

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

require 'spec_helper'

shared_examples "a dynamic my class" do |method_name = nil|
  let(:address) { method_name.nil? ? MyClassDynamic.new : MyClassDynamic.new(method_name) }

  it "creates the method" do
    address.should respond_to method_name
  end

  it "returns the method name as a string" do
    address.send(method_name).should eq(method_name.to_s)
  end
end

describe MyClassDynamic do
  it_behaves_like "a dynamic my class", MyClassDynamic::DEFAULT_METHOD_NAME
  it_behaves_like "a dynamic my class", :my_dynamic_method
  it_behaves_like "a dynamic my class", :your_dynamic_method
end

You can see in this example that the specs no longer repeat in the specs. All that I have to do is to call it_behaves_like "a dynamic my class" for each scenario that I want to test. I also added a third scenario that tests the method name of :your_dynamic_method with one line of code, demonstrating how easily we can add another scenario.

By passing the method_name into the shared example, we can use the method_name parameter to ensure that the examples can test a variety of scenarios.

Normally I wouldn’t include the shared examples in the same file as the specs. I would move these to a support/my_class_shared_examples.rb file and require that file in the rspec_helper.rb file or the individual spec files themselves to keep the spec code tidy.

Conclusion

By using shared examples as described above, not only is your code DRY, but there are a couple of added benefits. First, adding additional scenarios to test requires adding one line of code to your existing specs. Second, each time that you add an example to the shared example, you can be confident that it works in all scenarios.

When I wanted to change the configuration in my CanBe gem to allow anyone using the gem to pass in the details association name, I turned to shared examples to ensure that the metaprogamming required is working properly. It greatly reduced the time to implement this functionality and ensured that it was working correctly without breaking existing functionality.

All of the code for this example can be found in my rspec_shared_example_post repo on GitHub.

This is not a post about customer validation as defined in The Lean Startup book. Rather it is a post about who your actual customers are when you are creating a new product, especially early on in the development process. A product can be something that you are creating for your employer, for a client you are freelancing for, or even something your are making for your own personal use.

A customer is defined as “a person who purchases goods or services from another; buyer.” However, in the age of free services such as Google and Facebook, I would like to redefine a customer as “a person who makes use of goods or services from another” for the purposes of this post. This new definition of a customer would also include the company owner, product owners and other stakeholders of the project that you are developing.

In today’s environment we can develop software as little bits of functionality and deliver them almost immediately to our customers, both internal and external. No longer should we be developing in a vacuum, delaying delivery on a piece of functionality until it’s “complete.” Continuous Integration and Continuous Deployment offer the customers, of a software product, early access to the functionality that is being developed.

With this early access, the customers of a product can help to shape the features and functionality very early on and ensure that the correct product is delivered to the paying customers when it is finally released to the world. From a developers perspective, this might be frustrating because of the constant rework and changing requirements. However, there is an upside for the developers of the product as well. Once the product is finally delivered to the paying customers, there is a greater chance of it being used and increasing the revenue generated by the product. This can be infinitely more rewarding, to create software that is used as opposed to creating software that no one wants to use. Also, once the product is released to the paying customers and they are using it, there will not be a big push to quickly change the code to meet the needs of the customers.

If you are developing a software product, you should be releasing it to your customers as soon as there is anything visible that they can use. Enjoy the feedback that you get and take solace in the fact that you will developing a quality product that has a greater chance of succeeding.

When I started creating my CanBe gem, I realized that I would need to test fully functioning Active Record models. This would ensure that the gem would function correctly when used in a Rails app. However, I didn’t want to force myself or anyone else to setup a database on their local system when developing. A SQLite database seemed to fit the bill. Anyone developing functionality for my gem would likely already have the requirements for the sqlite3 gem since they probably would have already started a Rails application or two.

Still, I didn’t want to have to worry about creating the database and ensuring it was available every time the specs were run. Then I found out that you can create an in-memory SQLite database. This was a perfect fit!

There are only a few things you need to get this up and running. I am using RSpec for my testing, so all of the configuration below is in that context. First, you will need to add this line to your spec/spec_helper.rb file.

1

ActiveRecord::Base.establish_connection adapter: "sqlite3", database: ":memory:"

Now you have a database that you can run your migrations against and use your regular Active Record models. Here is an example migration that you could create in the spec/support/schema.rb.

1
2
3
4
5
6
7
8
9
10
11

ActiveRecord::Schema.define do
  self.verbose = false

  create_table :addresses, :force => true do |t|
    t.string :street
    t.string :city
    t.string :state
    t.string :zip
    t.timestamps
  end
end

To actually run them you need to load the file. Add this line to your spec/spec_helper.rb file.

1

load 'support/schema'

Next, create your models. I did this in a spec/support/models.rb file.

1
2

class Address < ActiveRecord::Base
end

Once, you require the models.rb file into your spec/spec_helper.rb file, you will have access to the Address model in your specs and it will function as a fully functioning Active Record model.

1

require 'support/models'

Using an in-memory SQLite database helped me ensure that the CanBe gem works against fully functioning Active Record models.

For as long as I can remember, I’ve spent the majority of my spare time to learning new technologies and shipping stuff with what I’ve learned. I love learning new stuff and I’ve always done it under the pretense that I will use my new found knowledge where I work. For the most part that has been a problem for me since my jobs haven’t always lined up with what I wanted to learn. For example, when I was a SQL Server DBA/Developer, I was learning more about web development, specifically Ruby on Rails. Eventually, I did get a job where I was developing in Ruby on Rails.

However, at the time of learning, I wasn’t shipping anything with the knowledge, personally or professionally. To some degree, what I learned went stale and I had to re-learn some of the basics when I started using it for my job.

Lately, I’ve begun to change that. I’m still learning, but I starting to ship more personal stuff with what I’m learning. How did I do it? I put more focus on shipping instead of learning. Since I’m not an expert in everything, I always learn something new when creating anything personal. For example, I wanted to change the domain name for my blog and switch the blogging engine that I was using. You are reading this post on the results of my efforts. This blog is using Octopress. I had to learn how Octopress works and how to incorporate some of the changes that I wanted. Nothing monumental, but at least I shipped something.

Another example of shipping for me is when I created my first Ruby Gem, CanBe. I learned more about the Ruby language and how to integrate a gem with Ruby on Rails, specifically Active Record. Yes, I learned something, but more importantly, for me, I shipped something.

I’ve been able to discern that learning and shipping aren’t mutually exclusive, rather they can be complementary. For me, it’s just where I put my focus. So my new plan is to focus more on shipping and push myself with each project to learn something new. This will enable me to focus on completing a project by being able to quickly use technology that I am familiar with and still choose one aspect of the project to learn something new. As I wrote in my post, Keeping an Eye on Productivity, it is important for me to still have the focus on shipping instead of learning.

For my next project, I want to focus on having a more reactive user experience on the client side of a web app. I have narrowed it down to two technologies that I want to use, Ember.js or Meteor. Given my new process of shipping over learning, the decision is pretty easy, I will be using Ember.js. I will use Rails for the backend. This will allow me to focus on delivering the functionality that I want because I am already familiar with many of the languages and tools, while still learning Ember.js. If I chose Meteor, I would have to learn how to code the front-end and the back-end.

My suggestion to all developers who work on side projects, is to determine what is important to you, shipping or learning, and focus on that. Just because you pick one over the other doesn’t mean that the other can’t happen. Rather, you just won’t get as much accomplished on that front as fast as you might like. In my opinion, you will have more personal satisfaction by picking one.