Tate Johnson

Experimenting With Continuous Deployment for Feature Branches

2013-05-06T00:00:00+10:00

At work we’ve been experimenting with a tool that deploys our project to a staging environment every time a developer pushes to GitHub. If the branch has already been deployed, it will drop, create and seed the database. If the branch has never been deployed, it will provision a new instance. The end result is the same. A usable, working instance of the project accessible to anyone in the company, especially non-developers. You could think of it as continuous deployment for feature branches.

Internally the tool is known as Tug and it deploys straight from GitHub to Heroku. Tug announces when the deploy has finished in Campfire along with the URL. There’s also a dashboard for quickly seeing which branches have been deployed and their URLs. You can also get a log of the output captured from the API and command line to troubleshoot any problems. To date, we’ve had 10 failed deploys out of 460.

Tug works well for us because we use feature branches heavily for development. We’re a small team, but it’s not uncommon to have 2 or 3 concurrent branches. The last thing we want to be thinking about is how are we going to get some early feedback from other people in the company. Even as a developer, it’s nice to be able to look at a pull request and then go and try the code out without having to mess around with my local repository.

What I’m trying to gauge is whether other developers would find this useful in their organisation, or if we have our processes wrong. This idea is not unique to me. We practised this process without the automation at Everyday Hero and the guys at Ennova shipped Koi Deploy for Rails Rumble.

Updated 2013-05-20

View the slides from my lightning talk which I gave at Sydney DevOps on 16th May, 2013.

Antenna Mate Ships in the United Kingdom

2013-05-05T00:00:00+10:00

Antenna Mate has been for sale on the Australian App Store since January 2011. It’s sold over 6,000 copies and has an average rating of 4.5 stars from 48 ratings. It’s appeared in a magazine and gets recommended by customers on various caravanning forums. Not bad for a little project I started in my final year of university.

I’ve always been interested to know what would happen if these numbers could be replicated in other countries. If Antenna Mate went on sale in the United Kingdom would the total number of sales double?

Picking the second country for Antenna Mate required some research. I started by looking at existing traffic to the website. The United States seemed like an obvious choice. After Australia, the United States made up 15% of the total traffic. More interestingly Americans were landing on the website through organic searches with keywords like “tv antenna direction app”. Very promising.

The problem is data. The FCC publishes terrestrial television data in a pipe delimited text file, but doesn’t provide enough context to turn raw data into meaningful information for an antenna installer or caravaner. Admittedly I don’t know much about terrestrial television in the United States.

Going back to the website, the next biggest group was from the United Kingdom. They made up 5% of the total traffic and were arriving through similar organic searches. Terrestrial television is culturally popular in the United Kingdom and there are a couple of big caravanning websites. More importantly, Ofcom publishes similar raw data to the ACMA in Australia. That meant there would be less changes required to the code and the data could be reliably imported.

I estimated that it would take about 10-16 hours to write a script to import the data, verify that it worked from inside the United Kingdom, localise the application and update the website. It probably took closer to 20 hours, but I’m happy to say that it’s now on the App Store. If I were to fund that 20 hours from revenue at market contracting rates then it costs me about 3 months of revenue. But since it’s more of a fun side project, I don’t.

If you’re in the United Kingdom give it a try and let me know what you think. If you’re in the United States and could help with data, I’d also be interested to hear from you.

Design is an Iterative Process

2013-04-29T00:00:00+10:00

I’ve been watching my girlfriend get frustrated at designing her first website. She gets put off after working so hard on something that doesn’t work out the way she thought it would. I keep reminding her that design is an iterative process. The Antenna Mate that thousands of people use today is not the same Antenna Mate that first shipped on the App Store. In fact, I’m really embarrassed by the earlier versions. But I shipped, and I couldn’t have gotten where I did without iterating. You only need to look at the earlier versions of GitHub and Mac OS X to see the same pattern repeat itself. If your core purpose is solid, then hard work and polish will pay off.

Next Stop is Hopping Off

2013-04-07T00:00:00+11:00

Today I made the decision to remove Next Stop for sale on the App Store. I posted this message on the Next Stop website.

Next Stop is no longer available on the App Store. It was fun to build and made sure I got off at the right stop. The truth is, it hasn’t sold that well and apps like TripGo do the same thing and everything else a commuter could want. At the end of the day, I support any well built piece of software that helps to increase public transport consumption. Everyone wins when someone chooses to catch a bus instead of driving a car. Thank you to everyone who supported Next Stop, especially Jason Weathered, Odin Dutton and Rachael Battle.

How well is not well? About 1-3 sales per day. Antenna Mate sells much better than that and at for 2.5 times the price. Next Stop was an enormous effort to build. In retrospect, there were a lot of things I could have cut from scope. It took a weekend to build logging with the expectation that people would submit logs so I could help debug Core Location. Number of logs I received? Zero.

Since building Next Stop I’ve strived to keep focus on the core problem and shipping as early as possible. At the end of the day, you can only commit a finite number of hours to a project and you’ve got to make that project count for something.

What I’ve always wanted is an app I could tell where I’m going and it figures out the route and tells me where to get off. That’s what TripGo does. There’s some good people behind it and I wish them all the best. Now I feel free to focus.

I’m finishing this post off with an experimental design I was contemplating for Next Stop. It was intentionally high contrast to increase visibility for people with vision impairments.

Adding and Removing Children with Rails Nested Forms and AngularJS

2013-01-13T00:00:00+11:00

AngularJS had appeared on my radar before, but I wasn’t inspired to try it until I read Click to Edit with AngularJS by Tim Riley. AngularJS takes a different approach to enhancing pages. Instead of thinking about DOM manipulation, you think about data and bindings.

We have a project at work that has nested forms. You can add and remove children before saving the entire object graph. We also have a rule where you cannot remove a child if there is only one child. When you’re thinking about DOM manipulation, you think about adding your event listeners, cloning the element, changing its attributes and inserting it back into the DOM. In contrast, when you think about data and bindings, all you need to think is “I want another child object”.

I’ll start by giving context, and then break everything down line by line. Starting with the Rails model, we have a plan that accepts nested attributes for polls.

# app/models/plan.rb
class Plan < ActiveRecord::Base
  has_many :polls

  accepts_nested_attributes_for :polls
end

In the Rails controller we setup a default poll.

# app/controllers/plans_controller.rb
class PlansController < ApplicationController
  def new
    @plan = Plan.new
    @plan.polls.build title: 'Time'
  end
end

Then we write the view.

<!-- app/views/new.html.erb -->
<div ng-app>
  <%= form_for @plan do |form| %>
    <div ng-controller="PollCtrl" ng-init="polls = <%= @plan.polls.to_json %>">
      <div ng-repeat="poll in polls">
        <%= form.fields_for :polls, Poll.new, child_index: '{{$index}}' do |poll_form| %>
          <%= poll_form.text_field :title, id: 'plan_poll_{{$index}}', value: '{{poll.title}}' %>
        <% end %>
        <a href="#" ng-click="remove($index)" ng-show="isRemovable()">Remove</a>
      </div>
      <a href="#" ng-click="add()">Add</a>
    </div>
  <% end %>
</div>

And the AngularJS controller.

// app/assets/javascripts/plans.js
function PollCtrl($scope) {
  $scope.isRemovable = function() {
    return $scope.polls.length > 1;
  };

  $scope.add = function() {
    $scope.polls.push({});
  };

  $scope.remove = function(index) {
    $scope.polls.splice(index, 1);
  };
}

You really need to try this jsfiddle to see it in action.

View and AngularJS Controller Line by Line

The AngularJS controller is associated with PollCtrl. PollCtrl is our wrapper around $scope for handling the bindings we declare in the view. The AngularJS controller is intialized with the Rails model objects that were setup in the Rails controller earlier. As a side-effect, these will be the same Rails model objects we’d get back from a failed POST to the create action.

<div ng-controller="PollCtrl" ng-init="polls = <%= @plan.polls.to_json %>">

Next, we want the input and remove anchor elements repeated for each poll JavaScript object.

<div ng-repeat="poll in polls">
  <!-- ... -->
</div>

Using fields_for we instantiate a poll Ruby object to give us access to the nested form builder. We want AngularJS to manage the indexes for us, so instead of specifying an explicit index, we’re going to set the index of the input element to a special variable available within the scope of repeating elements. As a side-effect of using child_index, it is necessary to specify the ID of the input element to avoid ID collisions in the DOM. If you don’t care, then you could safely omit the ID (Thanks to Darcy Laycock for the suggestion to use child_index).

<%= form.fields_for :polls, Poll.new, child_index: '{{$index}}' do |poll_form| %>
  <%= poll_form.text_field :title, id: 'plan_poll_{{$index}}', value: '{{poll.title}}' %>
<% end %>

These two anchors are bound to the add and remove functions in our AngularJS controller. The ng-show attribute tells AngularJS to show this anchor when our AngularJS’s controller isRemovable function returns true.

<a href="#" ng-click="remove($index)" ng-show="isRemovable()">Remove</a>
<a href="#" ng-click="add()">Add</a>

Expanding on the isRemovable function, a poll is only removable if there is more than one of them.

$scope.isRemovable = function() {
  return $scope.polls.length > 1;
};

Add inserts an empty object, and remove deletes an object at the given index.

$scope.add = function() {
  $scope.polls.push({});
};

$scope.remove = function(index) {
  $scope.polls.splice(index, 1);
};

The index came from the special index variable available inside the scope of repeating elements.

<a href="#" ng-click="remove($index)" ng-show="isRemovable()">Remove</a>

Rails Nested Forms

Some people might be surprised at my use of nested forms. Nested forms can suck, and when they do its time to consider something else like an intermediary view object. But until you reach that point, nested forms are the quickest way to ship.

Shipped: Next Stop for iPhone

2012-12-16T00:00:00+11:00

Next Stop lets you set an alarm for the bus stop you want to hop off at. Before you reach the bus stop, you get a push-style notification telling you to hop off. Next Stop became available on the App Store on the 12th of December. It’s the third app I’ve published to the App Store.

The motivation behind the project came from being anxious when catching new bus routes. I remember getting off a bus stop early and having to walk 1KM in the rain when I was staying in Fig Tree Pocket. I commuted on public transport everyday, wishing more people would catch public transport. I’m not a town planner, but I can write software. Building Next Stop is my small contribution toward making public transport better for everyone.

If you’re in Brisbane, give it a try. I’d love to have your feedback.

It was a Mistake to Undervalue the “Contact Us” Button in my iOS application

2012-11-27T00:00:00+11:00

I’m talking about the “Contact Us” button you see hidden away in the “About” screen of your favourite iOS app. The way it works is you tap “Contact Us” and a new email pops up with the to and subject pre-filled. Seems like a lot of work, especially when the email is already linked to from iTunes and the app’s website. I had never used one myself and naively assumed that nobody uses them. After adding a “Contact Us” button to Antenna Mate, I’ve received more emails this month than I have in the last three months.

Most of the emails were “I love your app, but…” and validating some old assumptions I had forgotten about. I used this feedback to drive a major enhancement which I’m hoping will continue to strengthen the app’s position as the best in its category. But more importantly, it gave me a dialogue with my customers. I’m looking forward to emailing them back and going “Hey, I listened, and here you go”.

Sure you’re going to receive more emails, but this dialogue can pay off. One of my customers wants the app in New Zealand (It’s Australia only) so badly that they found and linked me to the New Zealand data. Something I had spent thirty minutes trying to find, but couldn’t.

In case you’re wondering what to put in the “Contact Us” button. It opens up a MFMailComposeViewController that sets the email to the support email address and the subject to “Antenna Mate vX.X.X Feedback” leaving the customer to focus on the content. If email isn’t configured on the device they get an alert “We tried to open an email - Email isn’t configured on this device. Try sending an email to support@antennamate.com from your computer. We’d love to have your feedback”.

Testing Private and Protected Methods in Rails Controllers Without Being Awkward

2012-11-23T00:00:00+11:00

In Rails, it’s considered best practice to mark non-action methods as private or protected. This is because Rails will never route HTTP requests to methods which cannot be called publicly. This practice encourages us to hide important behaviour in methods which are not easily tested. There are many awkward techniques such as chaining instance_eval and send, creating an anonymous subclass and drawing a route, a slow integration test or omitting the test altogether. None of these test the desired behaviour in an intention revealing way. Nor would they be considered acceptable if it were any other class.

Testing doesn’t have to be awkward. It can be greatly simplified if we think about it slightly differently. The idea isn’t radical. It’s to move hidden behaviour into distinct classes which are then invoked privately from inside the controller. A distinct class with a single responsibility becomes easier to reason with. Easier to test. Invoking it privately means we’ll never accidentally route HTTP requests to non-action methods.

Lets start with a typical controller. This controller has been extracted from a code base that I recently refactored. AdminController is an abstract controller that gets subclassed by any controller in the admin section of the website. Authorization is common behaviour shared between all controllers. On each request, we check that the member is an admin. If the member is not an admin we return a 403 and stop them from viewing the page. Authorization is critical behaviour that must be correct. We could never let a member who isn’t an admin have privileged access.

# app/controllers/admin_controller.rb
class AdminController < ActionController::Base
  before_filter :authorize_member!

protected

  def authorize_member!
    unless current_member.admin_role?
      render text: '403: Forbidden', status: :forbidden
      false
    end
  end
end

Your fire up the server and everything is working great. But how do you have confidence that you’re not going to suffer from a regression in the future? If a regression does occur, how do you quickly pin point where it went wrong? Moreover, as our authorization scheme grows in complexity it becomes increasingly difficult to reason with in the context of hidden behaviour.

Lets move the behaviour into a new class called AuthorizeMember and nest it underneath AdminController. We could organise it into its own file, but it’s such a small class and only makes sense in the context of AdminController. AuthorizeMember is comprised of a single, stateless class method authorize! which takes two arguments. The member who is authenticated and the controller where the request orignated from. It might seem strange to pass around a controller. As magical as controllers are, they’re still objects which respond to methods making them no different to passing around a hash or an array. Finally, we delegate our controller’s protected method to AuthorizeMember.authorize_member!.

# app/controllers/admin_controller.rb
class AdminController < ActionController::Base
  class AuthorizeMember
    def self.authorize! member, controller
      unless member.admin_role?
        controller.render text: '403: Forbidden', status: :forbidden
        false
      end
    end
  end

  before_filter :authorize_member!

protected

  def authorize_member!
    AuthorizeMember.authorize! current_member, self
  end
end

The end result is identical, but now it exists in a distinct class where collaborators are injected. Injecting collaborators frees us from the constraints of their implementation. Instead of depending on an instance of ActionController::Base, we now depend on an object that responds to render. The difference is small, but the impact is massive. With only a handful of lines we can write a focused, intention revealing test that runs fast in isolation. ActionController::Base is really well tested, so there is no need for us to double up on that.

# spec/controllers/admin_controller_spec.rb
require 'spec_helper'

class MockController
  attr_reader :last_options

  def initialize
    @last_options = {}
  end

  def render options
    @last_options = options
  end
end

describe AdminController do
  describe 'AuthorizeMember.authorize' do
    it 'is forbidden' do
      member     = OpenStruct.new admin_role?: false
      controller = MockController.new
      AdminController::AuthorizeMember.authorize! member, controller
      controller.last_options.should_not be_empty
      controller.last_options[:text].should include('403')
      controller.last_options[:status].should eq(:forbidden)
    end

    it 'does nothing' do
      member     = OpenStruct.new admin_role?: true
      controller = MockController.new
      AdminController::AuthorizeMember.authorize! member, controller
      controller.last_options.should be_empty
    end
  end
end

The thing I love most about this technique is that you already know it. You practice it every time you refactor a big piece of code into smaller pieces of code. By thinking about controllers as something less magical, and something more like any other ruby class, you enable yourself to reuse your existing knowledge. There’s no special rules like calling instance_eval or additional libraries like RSpec’s anonymous controller. Instead, we write distinct classes focused on a single piece of behaviour that we delegate to from hidden methods in our controllers. Testing private and protected methods in Rails controllers doesn’t have to be awkward. We can write plain old Ruby and keep things simple.

SimpleDelegator + MiniTest::Mock = SimpleMock.

2012-02-22T00:00:00+11:00

SimpleMock is a fast, powerfully tiny mocking library for Ruby 1.9.2 or greater. Under the hood it uses MiniTest::Mock and SimpleDelegator to mix classical mocking with real objects (Partial mocking). An idea born out of an earlier blog post and later captured in these tweets.

Where other libraries temporarily replaces methods on objects, SimpleMock never mutates its delegate leaving objects completely untainted. SimpleMock is isolated in its own namespace and can be safely required in any Ruby project. SimpleMock depends only on the standard library and plays nicely with MiniTest and RSpec. The library code with whitespace is a tiny 81 lines. Parts of the library are tested against itself. The API it exposes is 100% compatible with MiniTest::Mock so there is nothing new to learn.

Using SimpleMock

For the most part classical mocking is satisfactory.

mock = SimpleMock.new
mock.expect :valid?, false
mock.valid?
mock.verify

Changing the behaviour of real objects should be a last resort. If you find yourself needing to regularly set expectations on real objects it may indicate that code is too tightly coupled. However, there are use cases where this cannot be avoided.

Rails route helpers are one of those use cases. Rails uses introspection to build routes from model objects. That means less code is written in controllers, but testing controllers in isolation is difficult. You may start off mocking dependancies, but you’ll quickly end up with a test that has lots of setup. Not to mention your making assumptions about the interfaces of objects out of your control. In such a scenario is makes sense to set expectations on a real model object.

In the comparison below SimpleMock and Mocha are the same number of lines of code.

# Mocha
test "POST create" do
  mock_items = mock()
  mock_items.expects(:create).with(Hash).returns(Item.new)
  mock_order = Order.new
  mock_order.expects(:items).returns(mock_items)
  controller.order = mock_order
  post :create, :format => 'json'
  # ...
end

# MiniTest::Mock and SimpleDelegator
test "POST create" do
  mock_order = Class.new SimpleDelegator do
    def items
      mock = MiniTest::Mock.new
      mock.expect :create, Item.new, [Hash]
    end
  end
  controller.order = mock_order.new(Order.new)
  post :create, :format => 'json'
  # ...
end

# SimpleMock
test "POST create" do
  mock_items = SimpleMock.new
  mock_items.expect :create, Item.new, [Hash]
  mock_order = SimpleMock.new Order.new
  mock_order.expect :items, mock_items
  controller.order = mock_order
  post :create, :format => 'json'
  # ...
end

Fast Tests are Fast

SimpleMock is fast. While it may have a slightly higher overhead than using MiniTest::Mock with SimpleDelegator you get the benefit of a familiar and consistent API. In this benchmark we create an array, set an expectation and call the method 10,000 times.

                  user       system     total      real
mocha:            0.000000   0.000000   0.000000   (0.000279)
simple_delegator: 0.000000   0.000000   0.000000   (0.000029)
simple_mock:      0.000000   0.000000   0.000000   (0.000057)

SimpleMock is available as a gem. Try SimpleMock in your next project and let me know what you think.

Mocking with MiniTest::Mock and SimpleDelegator

2012-02-07T00:00:00+11:00

Libraries like Mocha let you temporarily change the behaviour of objects. This is especially useful when mocking models in rails functional tests. Many of the built-in helper methods introspect models to generate URLs. The same behaviour can be achieved with MiniTest::Mock and SimpleDelegator. Both classes are included in the standard library, it’s fast and there’s no monkey patching.

MiniTest::Mock is a factory for creating light weight objects. Behaviour is controlled by defining expectations. The first argument is the method’s name and the second argument is the return value. There’s an optional third argument for specifying the type of arguments that method takes.

order = MiniTest::Mock.new
order.expect :update_attributes, false, [Hash]
order.expect :valid?, false

order.update_attributes :desc => 'Shirt' # => false
order.valid?                             # => false

SimpleDelegator forwards all missing method calls to a delegate. Inheriting from SimpleDelegator lets you change the behaviour of methods you care about while preserving the behaviour of everything else. In this example we stop #valid? from being forwarded by defining it in an anonymous class. #attributes is missing from the anonymous class and is forwarded to the delegate. The initializer takes one argument which is the delegate.

class Order < ActiveRecord::Base
  # ...
end

invalid_delegator = Class.new SimpleDelegator do
  def valid?
    false
  end
end

order = invalid_delegator.new Order.new(:desc => 'Shirt')
order.valid?      # => false
order.attributes  # => #<Order desc: 'Shirt'>

As a rule of thumb you should use MiniTest::Mock unless neighbouring objects expect specific behaviour. In the case of the latter, you’ll know when to use SimpleDelegator as methods being called further down the stack are beyond your control and confuse the purpose of your test (Eg: Rails built-in helper methods for generating URLs).

The real power of MiniTest::Mock and SimpleDelegator is realised when the two are used together. Below is a comparison of Mocha versus MiniTest::Mock and SimpleDelegator.

# Mocha
test "POST create" do
  mock_items = mock()
  mock_items.expects(:create).with(Hash).returns(Item.new)
  mock_order = Order.new
  mock_order.expects(:items).returns(mock_items)
  controller.order = mock_order
  post :create, :format => 'json'
  # ...
end

# MiniTest::Mock and SimpleDelegator
test "POST create" do
  mock_order = Class.new SimpleDelegator do
    def items
      mock = MiniTest::Mock.new
      mock.expect :create, Item.new, [Hash]
    end
  end
  controller.order = mock_order.new(Order.new)
  post :create, :format => 'json'
  # ...
end

MiniTest::Mock and SimpleDelegator are more verbose than Mocha but I like that it uses the standard library and doesn’t introduce new methods on Object, Module or Class. In addition MiniTest::Mock and SimpleDelegator are faster than Mocha. The benchmark is available as a gist.

                  user       system     total      real
mocha:            0.000000   0.000000   0.000000   (0.000277)
simple_delegator: 0.000000   0.000000   0.000000   (0.000024)

Updated 2012-02-21

SimpleMock takes the idea of this blog post and turns it into a fast, tiny library. The API is is 100% compatible with MiniTest::Mock and it plays nicely with MiniTest and RSpec. SimpleMock depends only on the standard library in Ruby 1.9.2 or greater. Instead of writing your own helpers, consider using SimpleMock. You’ll keep tests fast and write less code.