ReinH Blog

How to Cache Anything With ActiveSupport

2009-04-27T17:55:39-04:00

We use a REST-like web service to communicate with a large Endeca index. This web service is stateless and uses JSON. Unfortunately, its performance leaves much to be desired and the server does not cache requests. Fortunately, even with its weak implementation of REST, the service’s statelessness makes it trivial to add a caching layer to our client.

Rather than write our own caching solution, we looked to reuse one that already exists. No NIH for us. The caching provided by ActiveSupport::Cache turned out to be perfect for our needs and darn simple to implement. The end result is that web services requests that took from 200ms to 500ms and sometimes more (I told you it was slow) are now cache retrievals that take from 2ms to 5ms. That’s 10,000% faster. From 20 lines of code. With all the power and flexibility of the caching already built in to Rails. Winnage.

A Brief Review of ActiveSupport Caching

ActiveSupport caching is used by Rails to provide page, action, fragment and SQL caching. With SQL caching, the results of a SQL query are cached in memory for a given action so that repeated queries within an action hit the cache rather than the database. The Caching With Rails guide has a section on SQL Caching that provides a brief overview of the concept. For a more thorough introduction to caching in general, check out Ryan Tomayko’s “Things Caches Do”. It has sweet illustrations.

Our strategy is similar to SQL caching, except that we want to persist the cache rather than emptying it after each rails request. The API documentation for ActiveSupport::Cache explains how to set up a cache store and we will implement caching using the interface provided by the abstract class ActiveSupport::Cache::Store.

Caching A RESTful Web Service

We need to set up a cache store and determine whether or not we’re going to use caching. This will work similar to ActionController::Base.cache_store.

module Endeca
  class << self
    def cache_store; @cache_store end
    def perform_caching?; !@cache_store.nil? end

    def cache_store=(store_option)
      @cache_store = ActiveSupport::Cache.lookup_store(store_option)
    end
  end
end

Next, we need a unique cache key. Because we’re caching a web service that provides safe and idempotent GET requests, the simplest cache key is the Request-URI itself. We’ll SHA1 encode it for space and consistency, but this step is optional (and will require digest/sha1 from the Ruby standard library).

def cache_key
  Digest::SHA1.hexdigest uri.to_s
end

We’ll write a wrapper for ActiveSupport::Cache::Store#fetch that uses the generated cache key:

def fetch(&block)
  Endeca.cache_store.fetch(cache_key, &block)
end

We’ll also hook into the client’s get_request method (which performs the request and returns the JSON body of the response) using Rails’ alias_method_chain. We need to return the response directly unless we are performing caching. If we are performing caching, we attempt to fetch the cached response. If the cache retrieval fails, we make the actual web service call, cache the result, and return it. Here’s that code:

def get_response_with_caching
  return get_response_without_caching unless Endeca.perform_caching?
  fetch { get_response_without_caching }
end

The #fetch method provided by ActiveSupport::Cache::Store is a particularly useful pattern. It takes a cache key and does a cache lookup (à la #read). If a value is cached by that key – a cache hit – then it is returned. So far, so good. But here’s where it gets interesting: if there isn’t a value for that cache key – a cache miss – then one of two things happens. Either nil is returned or, if a block is given, that block is executed and the result is both written to the cache (à la #write) and returned.

Finally, we hook up the alias_method_chain when the module is included:

def self.included(base)
  base.alias_method_chain :get_response, :caching
end

And that’s it. Seriously. The entire caching code is available on the githubs for you to review. Yes, it has tests. This caching strategy can be reused to provide a transparent caching layer for many applications. It also works out of box with all of the cache stores provided by Rails, which means that if you are already using memcache for your rails caching in production then this will plug right in without any extra fuss.

The caching code is reproduced here in its entirety (minus documentation) for your reading pleasure:

# lib/endeca/caching.rb

require 'digest/sha1'

require 'rubygems'
require 'active_support/core_ext/module/aliasing'
require 'active_support/core_ext/array'
require 'active_support/core_ext/class'
require 'active_support/cache'

module Endeca

  class << self
    def perform_caching?; !@cache_store.nil? end
    def cache_store; @cache_store end

    def cache_store=(store_option)
      @cache_store = ActiveSupport::Cache.lookup_store(store_option)
    end
  end

  module Caching    
    def self.included(base)
      base.alias_method_chain :get_response, :caching
    end

    private

    def get_response_with_caching
      return get_response_without_caching unless Endeca.perform_caching?
      fetch { get_response_without_caching }
    end

    def cache_key; Digest::SHA1.hexdigest uri.to_s end
    def fetch(&block); Endeca.cache_store.fetch(cache_key, &block) end
  end
end

Custom FiveRuns TuneUp Instrumentation

2009-04-21T11:30:23-04:00

TuneUp is a development performance monitoring tool from FiveRuns. It can help you catch poorly performing actions and queries early and is a great tool to add to your performance monitoring toolbelt. TuneUp also makes it very simple to add custom instrumentation to your Rails app, which came in handy when we needed to report on web service queries made by our Endeca client.

A brief chat with Bruce Williams helped point the way to TuneUp’s FiveRuns::TuneUp.step, the jumping-off point for its instrumentation of your model, view and controller activity. We were able to write a simple plugin that adds instrumentation to calls made by the Primedia Endeca gem (a gem used to consume Endeca’s RESTful JSON bridge API).

The plugin takes advantage of alias_method_chain to add instrumentation to the Endeca query methods. This solution is very clean and is idiomatic to Rails itself as Rails uses alias_method_chain to “embellish” many parts of the request response cycle for things like benchmarking and caching, as David mentions in a blog post from his Rails Myths series

If you want to look at the code, you can find the plugin at its github repo. All the code is in the init.rb but I’ll reprint it here for convenience. Note that we could have refactored these similar method definitions using metaprogramming techniques but chose not to do so for reasons of simplicity and clarity.

if defined? FiveRuns && defined? Endeca && defined? Endeca::Document
  # Tuneup instrumentation
  class << Endeca::Document
    def all_with_tuneup(*args)
      Fiveruns::Tuneup.step "#{name}.all", :model do
        all_without_tuneup(*args)
      end
    end
    alias_method_chain :all, :tuneup

    def first_with_tuneup(*args)
      Fiveruns::Tuneup.step "#{name}.first", :model do
        first_without_tuneup(*args)
      end
    end
    alias_method_chain :first, :tuneup

    def by_id_with_tuneup(*args)
      Fiveruns::Tuneup.step "#{name}.by_id", :model do
        by_id_without_tuneup(*args)
      end
    end
    alias_method_chain :by_id, :tuneup
  end
end

Simplify Your Dev Environment With Passenger Pane

2009-04-17T10:04:11-04:00

On OS X? Develop web applications with Rails? Or Merb? Or Sinatra? Or any other Rack compatible framework? Want drag-and-drop and point-and-click development server management? Then you need Passenger Pane. We’ll walk you through the installation process and show you how to get a simple Rack application up and running. Thanks to Jason Noble for his help getting everything working.

Passenger Pane is an OS X preference pane designed to work in concert with Phusion Passenger and your OS X Leopard's default Apache2 installation (the same one that serves your Web Sharing). Setup is pretty simple and will probably take about 10 minutes. Here's what we're going to do:

Install Phusion Passenger
Install Passenger Pane
Serve a "Hello World!" Rack endpoint
Profit!

Install Phusion Passenger

Phusion Passenger is the (not so) new hotness in the Rails deployment world. Phusion is great for serving Rails applications via Apache in production (especially in concert with Rails Enterprise Edition, which provides a 33% memory savings over standard MRI Ruby), but it's also great for simplifying your development environment.

The Phusion team have done a great job on the passenger install. Here are the official installation instructions. We'll repeat them here for the sake of convenience.

Open a Terminal window.
Install the passenger gem:
```
sudo gem install passenger
```
Install the passenger apache2 module:
```
sudo passenger-install-apache2-module
```
Include the module and some supporting configuration settings into an apache conf file. The code will be provided by the passenger install script.
Finally, add a Directory directive to your apache2 config that allows access to the directory where your app source codes are located. You can put this at the bottom of your passenger.conf file (replace my source directory with yours):
```
<Directory /Users/reinh/code/>
  Order Allow,Deny
  Allow from all
</Directory>
```

Note: We put the passenger apache configuration in /etc/apach2/other/passenger.conf (a file we created). The default apache2 httpd.conf imports all .conf files in /etc/apache2/other.

Install Passenger Pane

Passenger Pane gives you a Preference Pane that lets you add, remove and manage apps deployed on Phusion Passenger. Drag-and-drop to serve a new app and restart with a single click — it even provides host entries for each app so you don't have to mess with virtual hosts or your hosts file. This is great for serving multiple applications simultaneously or just generally being awesome.

Installation is simple. Download the preference pane from their homepage and double-click to install. If you installed Passenger correctly (as above), this should just work. If not, look for errors in Console.app or a helpful notice in the preference pane and ask for help on the Passenger forums or in the #passenger channel on irc.freenode.net.

After installing Passenger Pane, you will need to restart Apache. The simplest way to do this on OS X is to open the Sharing preference pane and uncheck and recheck Web Sharing.

Serve A "Hello World!" Rack Endpoint

Let's test that everything is working by creating a simple Rack "Hello World!" endpoint.

Install rack:
```
sudo gem install rack
```
Create a new directory called rack-hello-world.

Add a file inside it called config.ru with these contents:

run lambda{|env| [200, {"Content-Type" => "text/plain"}, ["Hello World!"]]}

Create a public directory inside rack-hello-world (you'll see why later).
Drag the rack-hello-world folder into your Passenger Pane panel (if you're using TextMate, you can drag it from the project panel). You will probably need to click the lock first to allow modifications.
Browse to http://rack-hello-world.local and behold the awesome!
Profit!!!

If you've done this correctly, your Passenger Pane should look similar to this:

Your browser should be showing you your glorious "Hello World!" homepage.

Now you can drag in the app folders of any Rails, Merb, Sinatra or Ramaze applications and have them instantly served by Passenger. In fact, any Ruby web application that can run on Rack can be run in Passenger Pane. How's that for a painless local development environment?

Note: Why (I hear you asking) did we create a public directory? The answer is that Apache expects to serve a public directory and will fail if one is not found under the root of the app you're serving. If you had not created the directory, you would have to look at your apache error log (usually located at /var/log/apache2/error_log) to find out what went wrong.

A Git Workflow for Agile Teams

2009-03-02T20:05:55-05:00

At Hashrocket we use git both internally and in our Agile mentoring and training. Git gives us the flexibility to design a version control workflow that meets the needs of either a fully Agile team or a team that is transitioning towards an Agile process.

There are many usable git workflows. Indeed, git is really “a tool for designing VCS workflows” rather than a Version Control System itself⁵. Or, as Linus would say, git is just a stupid content tracker⁶.

This is by no means a normative document or my attempt to define The One True Workflow. I have found this workflow to be productive and relatively painless, especially for teams that are still learning and transitioning towards a more Agile process. I invite you to comment below and describe the git workflow that works best for you.

Thanks

Anyone interested in using git in an Agile environment should read Josh Susser’s Agile Git and the Story Branch Pattern¹. This workflow is based largely on his.

The process of squashing commits into more atomic and incremental units has been described by Justin Reagor in A “Squash” WorkFlow in Git². Justin’s post also references a git rebase -i walkthrough by MadCoder³ that provides a good explanation the interactive rebase process.

Thanks also to Rick Bradley of OG Consulting and Josh Susser of Pivotal Labs for many fruitful and often hilarious discussions about git, Agile and ponies.

Feature Development
Bug Fixes
QA Branch Management
Production Tagging
Summary
Notes

Feature Development

Our git feature development workflow consists of these steps:

Pull to update your local master
Check out a feature branch
Do work in your feature branch, committing early and often
Rebase frequently to incorporate upstream changes
Interactive rebase (squash) your commits
Merge your changes with master
Push your changes to the upstream

First, and while in your master branch (git checkout master), pull in the most recent changes:

git pull origin master

This should never create a merge commit because we are never working directly in master.

NB: Whenever you perform a pull, merge or rebase, make sure that you run tests directly afterwards. Git may not show any conflicts but that doesn’t mean that two changes are compatible. Also run tests before you commit (of course).

We begin with the topmost available story in Pivotal Tracker. Let’s say that it’s #3275: User Can Add A Comment To a Post. First, check out a feature branch named with the story id and a short, descriptive title:

git checkout -b 3275-add-commenting

The id allows us to easily track this branch back to the story that spawned it. The title is there to give us humans a little hint as to what’s in it. Do some work on this branch, committing early and often (for instance, whenever your tests pass). Rebase against the upstream frequently to prevent your branch from diverging significantly:

git fetch origin master
git rebase origin/master

NB: This is often done by checking master out and pulling, but this method requires extra steps:

git checkout master
git pull
git checkout 3275-add-commenting
git rebase master

Once work on the feature is complete, you will have a branch with a lot of small commits like “adding a model and a migration”, “adding a controller and some views”, “oh crap – adding tests” and so on. This is useful while developing but larger, incremental commits are more easier to maintain. We will use an interactive rebase³ to squash them together. Also, squashing these commits together will allow us to pretend that we wrote the tests first…

We want the rebase to affect only the commits we’ve made to this branch, not the commits that exist on the upstream. To ensure that we only deal with the “local” commits, use:

git rebase -i origin/master

Git will display an editor window with a list of the commits to be modified, something like:

pick 3dcd585 Adding Comment model, migrations, spec
pick 9f5c362 Adding Comment controller, helper, spec
pick dcd4813 Adding Comment relationship with Post
pick 977a754 Comment belongs to a User
pick 9ea48e3 Comment form on Post show page

Now we tell git what we to do. Change these lines to:

pick 3dcd585 Adding Comment model, migrations, spec
squash 9f5c362 Adding Comment controller, helper, spec
squash dcd4813 Adding Comment relationship with Post
squash 977a754 Comment belongs to a User
squash 9ea48e3 Comment form on Post show page

Save and close the file. This will squash these commits together into one commit and present us with a new editor window where we can give the new commit a message. We’ll use the story id and title for the subject and list the original commit messages in the body:

[#3275] User Can Add A Comment To a Post

* Adding Comment model, migrations, spec
* Adding Comment controller, helper, spec
* Adding Comment relationship with Post
* Comment belongs to a User
* Comment form on Post show page

This also follows Tim Pope’s git commit message best practices. Now, save and close your editor. This commit is now ready to be merged back into master. First rebase against any recent changes in the upstream. Then merge your changes back into master:

git checkout master
git merge 3275-add-commenting

And finally, push your changes to the upstream:

git push origin master

Bug Fixes

Bugfixes will use the same workflow as feature work. Name your bugfix branch after the bug id and give it a descriptive name. Prefix the branch name with “bug” to help you keep track of them, for instance: bug-3845-empty-comments-allowed.

Do work in your bugfix branch, committing early and often. Rebase frequently against the upstream and again when you are finished. Then, use an interactive rebase to squash all the commits together. Use the bug id and title for the subject of the new commit. Include “BUG” or “BUGFIX” to make these commits easier to identify. For instance:

[#3278] BUGFIX: Empty Comments Should Not Be Allowed

NB: With a bugfix, squash the commits down into one and exactly one commit that completely represents that bugfix. Half of a bugfix is useless.

QA Branch Management

In a truly Agile process, as Josh Susser explained to me, you simply deploy directly from your latest “green” build. While this may seem impossible, there are real world examples of the viability of Continuous Deployment⁴.

For most of the teams we train, this sort of extreme agility is a goal rather than a way of life. They are transitioning towards a fully Agile process from a more rigorous one and often have a significant investment in Quality Assurance. For these teams, I recommend a compromise solution: Use a remote QA branch that is fast-forward merged from the latest “green” (all CI tests pass) master build for QA deployments.

If you don’t already have a QA branch, create one from the current master (assuming it’s green) and then push it to your git host:

git checkout -b qa
git push origin qa:refs/heads/qa

To update an existing QA branch with the latest changes from master, do this:

git checkout qa
git merge master
git push origin qa

Ensure that the master branch is green when you merge. Also ensure that this merge is always a Fast Forward merge. If it is not, it means that commits have been made in the QA branch that are not in the master branch. QA should be merged into from master only, never worked on directly.

Production Tagging

While an Agile team will be deploying continuously, most teams will require a more rigorous vetting process before a build is deployed to production. Tags provide a simple way for QA to vet a particular build.

Once QA has signed off on a build as ready for production, a tag should be made and deployed. In git, a tag can be created with git tag <name>. It is important that tag naming is consistent and it is useful if they sort in a meaningful way (latest last, for instance). Two good options are a timestamp or product version. Use whichever is more meaningful to your team.

The process of creating a timestamped production tag can be automated with a simple script or a git alias like this one:

git config alias.datetag '!git tag `date "+%Y%m%d%H%M"`'

With this alias, git datetag will create a new tag from HEAD with the current timestamp. You will want to be in the QA branch. If the QA branch has moved beyond the last commit vetted by your QA team, be sure to checkout that commit first.

Notes

¹ Agile git and the story branch pattern by Josh Susser

² A Squash WorkFlow in Git by Justin Reagor

³ git awsome-ness [git rebase —interactive] by MadCoder

⁴ Continuous Deployment and Continuous Deployment at IMVU: Doing the impossible fifty times a day by Timothy Fritz of IMVU

⁵ My Git Workflow by Oliver Steele

⁶ git(1) Manaual Page

REST & Rails

2007-11-13T12:29:16-05:00

I am giving a presentation on Rails, REST, and the Resource Oriented Architecture today entitled “REST & Rails: Web Services for the Rails World”. Check out the slides.

Story Driven Development With Rails

2008-12-09T12:22:26-05:00

As a follow up on writing incremental stories, we’re going to take the first story and walk through a behavior driven development process to implement it in a simple Rails application. We will focus on making small, iterative changes and following a strict test-first philosophy where we write granular unit tests and implement them with just enough code to make them pass.

Let’s review our first story:

As A User I Want To View A List Of Projects
So that I can find a project that interests me

#1

Acceptance:

All projects shown in list
List is paginated
List is sorted by age

Cost: 1 Point

At this point, let’s assume that this story is on top of our current iteration. First, we’ll need to review the story for any missing information and communicate with the client to clear up any questions. Keep in mind that a story is just a way to capture a conversation about a feature. It is not set in stone. After talking to the client, we find that we will need to display a project’s author name and title and that the title will need to link to that project’s page. Let’s update the story appropriately.

As A User I Want To View A List Of Projects
So that I can find a project that interests me

#1

Acceptance:

All projects shown in list
Show title for each project
Show author name for each project
Project title links to the project’s page
List is paginated
List is sorted by project age

Cost: 1 Point

Now that the story is complete, deliverable and acceptable, we can begin work on the new feature. A implementation plan should be forming in your head. Now is the time to divide the work into testable units. In our case we already have a Project model with the requisite fields (let’s say) so our work will focus on the controller and view.

Test All The F***ing Time

Client sign-off on well written acceptance tests means that the specifications you write and the feature that is implemented as a result will be more closely in line with the client’s expectations. This minimizes the kind of impedance mismatch between expectation and execution that so often plagues a project with poor client communication and a disorganized process.

Now it’s time to take our acceptance tests and use them to drive our iterative, test-driven development process. Let’s take it from the top.

All Projects Shown in List

Let’s start with the controller. A list of projects needs an index action. Starting at the top, we will need to load all of the projects. Let’s write a test for this:

describe ProjectsController do
  describe "getting a list of products" do
    it "loads all the projects" do
      projects = [mock_model(Project)]
      Project.stub!(:all).and_return(projects)

      get 'index'

      assigns(:projects).should == projects
    end
  end
end

Note: Stubbing the call to Project.all has the immediate benefit of eliminating the database from our test but is potentially more brittle since we cannot be sure that this interface point to our Project model will not need to change in the future.

On a side note, I tend to view controller tests as integration-level tests rather than unit tests. As such, I usually do write tests that touch the database since these are often less brittle. If you write tests that touch the database, ActiveRecord factories such as Factory Girl or object daddy are useful for populating the database with valid records in known states.

Now we can write the implementation:

class ProjectsController < ApplicationController
  def index
    @projects = Project.all
  end
end

Then we have to display a list of projects. We’ll write a view test to cover this:

describe "/projects/index" do
  before(:each) do
    @project = mock_model(Project)
    @projects = [@project]
    assigns[:projects] = @projects
    render 'projects/index'
  end
  
  it "should include a list of projects" do
    response.should have_tag('li.project', :count => @projects.size)
  end
end

And the implementation:

<ul>
  <% @projects.each do |project| %>
    <li class="project"></li>
  <% end -%>
</ul>

Note: View tests can often be brittle. They can be made less brittle by testing only for semantically appropriate tags, classes and ids whenever possible. Using semantically rich markup in your views will make it much easier to write robust view tests — and is also a great practice for its own sake.

Show Title for Each Project

describe "/projects/index" do
  # SNIP
  
  it "should show the title for each project" do
    response.should have_tag('li.project .title', @project.title)
  end
end

<ul>
  <% @projects.each do |project| %>
    <li class="project">
      <h2 class="title"><%= project.title %></h2>
    </li>
  <% end -%>
</ul>

Show Author Name for Each Project

describe "/projects/index" do
  # SNIP
  
  it "should show the author name for each project" do
    response.should have_tag('li.project .author_name', @project.author_name)
  end
end

<ul>
  <% @projects.each do |project| %>
    <li class="project">
      <h2 class="title"><%= project.title %></h2>
      <p class="author_name"><%= project.author_name %></p>
    </li>
  <% end -%>
</ul>

Note: We are using an accessor on our project model, Project#author_name. There’s a good chance that this name will be taken from an associated User or Author model in any non-trivial Rails application. From an object oriented standpoint, however, having the author name hang directly from the Project model improves encapsulation.

The benefits of this were already seen in the test, where we were able to stub author_name directly on the Project mock. Without the accessor, we would be forced to stub #author on the Project mock to return an Author mock that then stubs #name just so that we could properly test the method chain project.author.name that is used in the view. Violating the Law of Demeter makes testing harder.

Project Title Links to the Project’s Page

describe "/projects/index" do
  # SNIP
  
  it "should have project titles that link to the project page" do
    response.should have_tag( 'li.project .title a[href=?]', project_path(@project),   
      :text => @project.title)
  end
end

<ul>
  <% @projects.each do |project| %>
    <li class="project">
      <h2 class="title"><%= link_to project.title, project %></h2>
      <p class="author_name"><%= project.author_name %></p>
    </li>
  <% end -%>
</ul>

The story is now about half complete. I’ll leave pagination and default sort order as an exercise for the user. In fact, these could also have been broken out into a secondary story or stories given that what we have done so far is an incremental unit of work.

I hope this rather contrived example shows how stories with well written acceptance tests inform a test- or behavior- driven development process and help bridge the gap between what the client expects and what the developement team delivers.

Incremental Stories and Micro‑Releases

2008-08-29T17:14:23-04:00

Agile estimating and planning is difficult. One of the practices that we are learning and adopting at Hashrocket that has truly improved our ability to ship is micro-releases. The idea, championed by author Joshua Kerievsky, is that constantly planning and shipping small, feature based incremental releases within the iterative cycle drives the delivery of tangible business value. In other words, the most important stuff gets shipped sooner.

Committing to micro-releases ensures that we are constantly working on delivering the highest priority features that represent real business value in an agile, incremental way. Complex stories that won’t fit into a micro-release cycle are broken down into stories that deliver core value and supporting stories that can be deferred to a later iteration.

A Complex Story

As A User I Want To View A List Of Projects
So that I can find a project that interests me

#1

Acceptance:

All projects shown in list
List is paginated
List sorts by age by default
List is sortable by the following criteria
- Age
- Owner
List is filterable by the following criteria
- Status
- Category

Cost: 4 Points

This is a reasonably good story. It is clear, concise and deliverable. Its acceptance criteria are testable. It adds real business value. A short time ago ago I would have been quite happy to write stories just like this. That’s not the case today.

Now that our development process is becoming more geared towards focused micro-releases, the value of incremental stories is becoming exceedingly clear. Writing incremental stories allows us to break complex stories apart into a first increment focused on delivering core value and a set of secondary stories that can be added as later increments to deliver supplementary value.

A Simple Primary Story

As A User I Want To View A List Of Projects
So that I can find a project that interests me

#1

Acceptance:

All projects shown in list
List is paginated
List is sorted by age

Cost: 1 Point

This story is smaller and simpler but it delivers most of the value of the original complex story. Users can browse a list and find projects. Additional value is certainly provided by selecting sort and filtering criteria. But that’s the point: these provide additional value. The simple primary story is an increment that delivers on the core value behind this feature: users want to discover projects. It’s the minimum functionality needed to start using the feature.

Some Simple Supplementary Stories

As A User I Want To Sort The Project List
So that I can better discover projects based on certain criteria

#1.1

Requires:

A list of projects

Acceptance:

List is sortable by the following criteria
- Age
- Owner

Cost: 1 Point

As A User I Want To Filter The Project List
So that I can browse only projects that match a given criterion

#1.2

Requires:

A list of projects

Acceptance:

List is filterable by the following criteria
- Status
- Category

Cost: 2 Points

One interesting and important observation is that the primary story is a one point story while the secondary stories total to three points. This means that these secondary stories represent fully three fourths of the original value of the complex story. In other words, shipping on the core value of the feature becomes much, much easier once it’s broken up into increments.

Ship Leaner Features, Sooner

Breaking complex stories into simpler incremental stories becomes especially important in situations where your iterations are extremely time-sensitive. This is precisely the case in our 3-2-1 Launch projects. Breaking stories into increments allows us to deliver more of the application’s core value sooner. It also helps clients make real-time decisions about the importance of the primary and secondary value stories separately. Once they can get their hands on the core functionality they often re-prioritize the secondary stories more effectively.

In the case of this particular story, once the basic list and pagination were out there – and once project search (another core value feature) was implemented – it became clear that the secondary project listing stories only duplicated functionality. These secondary stories are cooling off in the icebox as we speak. Meanwhile, we shipped a feature four times leaner and four times sooner.

Git Push: Just The Tip

2008-04-18T11:09:13-04:00

Today we delve into the world of git push, one of the most often used git tools. git push is typically used to update a remote ref and associated objects based on a local ref – in other words, to push your local changes to an upstream repository – but you can also use it to create or delete remote branches and ~~much, much more!~~ actually, that’s about it.

Just The Tip

The most common use of git push is to push your local changes to your public upstream repository. Assuming that the upstream is a remote named “origin” (the default remote name if your repository is a clone) and the branch to be updated to/from is named “master” (the default branch name), this is done with:

git push origin master

Get used to this. You’ll be doing it a lot.

A Bit Deeper

Git uses the term “refspec” when describing the usage of some of its commands. A refspec is essentially a name that git can resolve to a commit object. This can be the name of a branch or an arbitrary “SHA1 expression” such as master~4, among others core/docs/git rev-parse.html. Git gives you a lot of ways to refer to a commit but for most purposes you’ll just use the name of a branch with git push.

The kernel.org manpage for git pull core/docs/git push.html#URLS will rather cryptically tell you that “The canonical format of a <refspec> parameter is +?<src>:<dst>”. Most of the time this translates to <branch to push from>:<branch to push to>. The branch to push from and the colon are optional. If left out, git will push from the local branch to the remote branch of the same name. If no refspec is used at all, git will push all “heads” (f.e. branches) on the local to matching heads that exist on the remote.

In practice, this means that:

git push origin will push changes from all local branches to matching branches the origin remote
git push origin master will push changes from the local master branch to the remote master branch
@git push origin master:staginwill push changes from the local master branch to the remote staging branch if it exists

Tips and Tricks

Create a Remote Branch

git push origin master:refs/heads/staging will create the branch staging in the origin repository by copying the local master branch

Delete a Remote Branch

git push origin :staging will delete the branch staging from the origin repository.

Set Up A Branch’s Default Remote

You can use git config to assign a default remote to a given branch. This default remote will be used to push that branch unless otherwise specified.

This is already done for you when you use git clone, allowing you to use git push without any arguments to push the local master branch to update the origin repository’s master branch.

git config branch.<name>.remote <remote> can be used to specify this manually.

To Design A Blog (act 2)

2008-02-26T21:28:16-05:00

fig. 1.1 | ReinH-02.png

In our first installment, the typography and layout of the blog were mostly decided. With this ground work in place, it’s time to start focusing on the details. But first, it’s time to give our eyes and brain a chance to relax and reset. Staring at the same design for hours tends to give you tunnel-vision and we want to be able to look at the site afresh.

Now that we’re ready to continue, the most obvious issue is the arrangement of the sections in the footer. The rest of the design follows a strict grid system but the haphazard placement of the bottom columns is jarring to the eye and the whitespace between them is also problematic. figure-1-1).

fig. 1.2 | ReinH-03.png

A third column is added and the columns are properly aligned with the grid layout once again figure-1-2). Great success! The remaining changes are all relatively minor and mainly involve tweaks to font size, color, and spacing. Bonus points if you can spot them.

Now then: Welcome to the new blog! Enjoy your stay.

Rocking the Hoedown

2008-08-10T14:02:38-04:00

We had a great time at the Ruby Hoedown this weekend. The Hashrocket crew was out in force (and there was much debauchery in the Hashrocket RV). We got to meet or get better acquainted with a lot of great rubyists and hear a lot of entertaining, informative talks.

Jim and Joe’s Mock Dialog

Jim Weirich and Joe O’Brien presented their talk about mocks and stubs in the form of a short play in three acts. This was very timely for me since mocking properly in tests is area we have been discussing quite a bit at Hashrocket.

One thing they said that struck a chord was that complex mocks are a code smell that can clue you in to problems or hot spots for refactoring in the code under test.

The presentation style was fresh and the tips they provided should be very valuable to anyone using mocks in testing (which should be everyone).

Ruby Best Practice Patterns

I’m afraid I played a little trick on poor Jeremy and my dear audience. Instead of spending an hour giving examples of patterns and practices, I thought it might be fun to take a more satirical slant on the material. The resulting talk, Unfactoring From Patterns: Job Security Through Code Obscurity, turned out to be a modest success (if I do say so myself) and I think rather more entertaining to boot.

I did have time to show a few actual patterns but the dialog during the question and answer period was especially valuable. David Black, Yehuda Katz and others made some great points and I really enjoyed getting a chance to discuss one of my favorite topics with such a receptive and informed audience.

We Ain’t Got No Keynote

Chris decided to forgo the slides to tell us a more personal story about his growth from a lowly PHP hacker to the successful rubyist, entreprenuer and open-source champion that he is today. Chris is an exemplar for me of the right way to go about creating a personal and company brand.

Chris’s years of passion for tinkering, experimenting and exploring really have payed off in a big way. I think his story could rightly be considered inspirational. I’m sure a lot of people left his talk and started side projects this very weekend. I really enjoyed his talk (even if he did tell people not to buy my book).

Flog Your Tests, Test Your Flog

Testing is such a crucial part of my process that I was very excited to hear Rick Bradley’s account of his rather epic battle to add tests to flog. The irony here, of course, is that flog itself is a testing tool.

This talk combined two of my favorite topics: testing and refactoring. Rick’s war stories had some great takeaways: the importance of integration tests to characterize the behavior of the existing system, the ways in which code that is written test first differs from code that is written without tests, the utter importance of testing all the f—king time. Bryal Liles will have more to say on that last topic in a bit.

I really can’t say enough about Rick’s talk. Hashrocket often takes on applications with little or no testing for our Rescue Missions and Rick’s deliberate, careful, comprehensive methodology is exactly the process we try to follow when we refactor and resuscitate our clients’ code back to health. Rick could very well write the Hashrocket Rescue Mission manual.

MIDI Machinations and Hungry Hungry Hippos

Giles Bowkett is a mad genius. Perhaps more importantly, he’s an artist who can ship. He lured us all to a talk about archaeopteryx, his amazing MIDI generator, and then proceeded to smack us all with the enlightenment stick.

I won’t spoil his talk for people who haven’t seen it. Suffice it to say that it was far more than I expected. Giles’s opinions on software development are unique and somewhat iconoclastic. Be careful, the code he writes might blow some people’s minds.

Giles’s presentation style is engaging and he can be down right hilarious at times. Also, hippos are scary!

Wrap It Up!

Taking a road trip down to the Hoedown with the Hashrocket crew was one of the best conference experiences I’ve had so far. The talks were great, but I think the after-conference festivities were the real hilight. Watching Obie and Jason play beer pong on a table constructed of pool noodles (watch the video), playing werewolf with a crew of drunken rubyists and spending time with some of my favorite conference friends. Who could ask for more? Also, Jeremy has big plans for next year’s Hoedown. It involves words like “free” and “Nashville” – I would be inclined to add “awesome” as well.

ReinH Blog

How to Cache Anything With ActiveSupport

A Brief Review of ActiveSupport Caching

Caching A RESTful Web Service

Custom FiveRuns TuneUp Instrumentation

Simplify Your Dev Environment With Passenger Pane

Install Phusion Passenger

Install Passenger Pane

Serve A "Hello World!" Rack Endpoint

A Git Workflow for Agile Teams

Thanks

Table of Contents

Feature Development

Bug Fixes

QA Branch Management

Production Tagging

Notes

REST & Rails

Story Driven Development With Rails

As A User I Want To View A List Of Projects So that I can find a project that interests me

#1

Acceptance:

Cost: 1 Point

As A User I Want To View A List Of Projects So that I can find a project that interests me

#1

Acceptance:

Cost: 1 Point

Test All The F***ing Time

All Projects Shown in List

Show Title for Each Project

Show Author Name for Each Project

Project Title Links to the Project’s Page

Incremental Stories and Micro‑Releases

A Complex Story

As A User I Want To View A List Of Projects So that I can find a project that interests me

#1

Acceptance:

Cost: 4 Points

A Simple Primary Story

As A User I Want To View A List Of Projects So that I can find a project that interests me

#1

Acceptance:

Cost: 1 Point

Some Simple Supplementary Stories

As A User I Want To Sort The Project List So that I can better discover projects based on certain criteria

#1.1

Requires:

Acceptance:

Cost: 1 Point

As A User I Want To Filter The Project List So that I can browse only projects that match a given criterion

#1.2

Requires:

Acceptance:

Cost: 2 Points

Ship Leaner Features, Sooner

Git Push: Just The Tip

Just The Tip

A Bit Deeper

Tips and Tricks

Create a Remote Branch

Delete a Remote Branch

Set Up A Branch’s Default Remote

To Design A Blog (act 2)

Rocking the Hoedown

Jim and Joe’s Mock Dialog

Ruby Best Practice Patterns

We Ain’t Got No Keynote

Flog Your Tests, Test Your Flog

MIDI Machinations and Hungry Hungry Hippos

Wrap It Up!

As A User I Want To View A List Of Projects
So that I can find a project that interests me

As A User I Want To View A List Of Projects
So that I can find a project that interests me

As A User I Want To View A List Of Projects
So that I can find a project that interests me

As A User I Want To View A List Of Projects
So that I can find a project that interests me

As A User I Want To Sort The Project List
So that I can better discover projects based on certain criteria

As A User I Want To Filter The Project List
So that I can browse only projects that match a given criterion