Gauges allows you to share a gauge with someone else by email. That email does not have to exist prior to your adding it, because nothing is more annoying that wanting to share something with a friend or co-worker, but first having to get them to sign up for the service.

If the email address is found, we add the user to the gauge and notify them that they have been added.

If the email address is not found, we create an invite and then send an email to notify them they should sign up, so they can see the data.

The Problem: McUggo Route

The aforementioned sharing logic isn’t difficult, but it was just enough that our share route was getting uggo. It started off looking something like this:

post('/gauges/:id/shares') do
  gauge = Gauge.get(params['id'])

  if user = User.first_by_email(params[:email])
    Stats.increment('shares.existing')
    gauge.add_user(user)
    ShareWithExistingUserMailer.new(gauge, user).deliver
    {:share => SharePresenter.new(gauge, user)}.to_json
  else
    invite = gauge.invite(params['email'])
    Stats.increment('shares.new')
    ShareWithNewUserMailer.new(gauge, invite).deliver
    {:share => SharePresenter.new(gauge, invite)}.to_json
  end
end

Let’s be honest. We’ve all seen Rails controller actions and Sinatra routes that are fantastically worse, but this was really burning my eyes, so I charged our programming butler to refactor it.

The Solution: Move Logic to Separate Class

We talked some ideas through, and once he had finished, the route looked more like this:

post('/gauges/:id/shares') do
  gauge    = Gauge.get(params['id'])
  sharer   = GaugeSharer.new(gauge, params['email'])
  receiver = sharer.perform
  {:share => SharePresenter.new(gauge, receiver)}.to_json
end

Perfect? Who cares. Waaaaaaaaay better? Yes. The concern of a user existing or not is moved away to a place where the route could care less.

Also, the bonus is that sharing a gauge can now be used without invoking a route.

So what does GaugeSharer look like?

class GaugeSharer
  def initialize(gauge, email)
    @gauge = gauge
    @email = email
  end

  def user
    @user ||= … # user from database
  end

  def existing?
    user.present?
  end

  def perform
    if existing?
      share_with_existing_user
    else
      share_with_invitee
    end
  end

  def share_with_existing_user
    # add user to gauge
    ShareWithExistingUserMailer.new(@gauge, user).deliver
    user
  end

  def share_with_invitee
    invite = ... # invite to db
    ShareWithNewUserMailer.new(@gauge, invite).deliver
    invite
  end
end

Now, instead of having several higher-level tests to check each piece of logic, we can just ensure that GaugeSharer is invoked correctly in the route test and then test the crap out of GaugeSharer with unit tests. We can also use GaugeSharer anywhere else in the application that we want to.

This isn’t a dramatic change in code, but it has a dramatic effect on the coder. Moving all these bits into separate classes and tiny methods improves ease of testing and, probably more importantly, ease of grokking for another developer, including yourself at a later point in time.

Things are still moving along on the Rails 4 front, with a mix of tidying up and new features. Here are some of the commits that caught my eye last week.

• A whole mess of commits worked over some of the collection form helpers. Now collection_select and options_from_collection_for_select can take procs to evaluate their text and value in the current context, and there are new collection_check_boxes and collection_radio_buttons helpers. The easiest starting point is with f506c806 which documents the API changes.
• 8270e4a8 implements the null object pattern for ActiveRecord relations. Post.none will return a relation containing no posts – which may seem daffy, but makes for much nicer chainable methods on your ActiveRecord objects.
• b31eac56 replaces all for loops in the Rails source code with Enumerable#each. This should lead to considerably less confusion for new Rails developers.
• 336ff8a9 deprecates the :dependent => :restrict construct for ActiveRecord associations.
• 66c04431 updates Rails’ Unicode support from 6.0 to 6.1, making it pile of poo compatible.

Things are still moving along on the Rails 4 front, with a mix of tidying up and new features. Here are some of the commits that caught my eye last week.

• A whole mess of commits worked over some of the collection form helpers. Now collection_select and options_from_collection_for_select can take procs to evaluate their text and value in the current context, and there are new collection_check_boxes and collection_radio_buttons helpers. The easiest starting point is with f506c806 which documents the API changes.
• 8270e4a8 implements the null object pattern for ActiveRecord relations. Post.none will return a relation containing no posts – which may seem daffy, but makes for much nicer chainable methods on your ActiveRecord objects.
• b31eac56 replaces all for loops in the Rails source code with Enumerable#each. This should lead to considerably less confusion for new Rails developers.
• 336ff8a9 deprecates the :dependent => :restrict construct for ActiveRecord associations.
• 66c04431 updates Rails’ Unicode support from 6.0 to 6.1, making it pile of poo compatible.

• Twitter’s Bootstrap in the Asset Pipeline – Hooking it up using the less-rails-bootstrap gem.
• Async JavaScript – Book project on Kickstarter.
• Try Redis – An in-browser demonstration and tutorial.
• HTML5: Browser Caching – the latest from PeepCode.
• riak-ruby-client – This gem has hit version 1.0, for those of you interested in riak.
• Introducing Falcore and Timber – A pipelined web server (written in Go) and a logger library to go with it.
• Heroku and Rails 3.2 asset:precompile error – And how to fix it.
• turn.js – Page-turning animation for your HTML5 sites.
• QuoJS – “Micro JavaScript Library for Mobile Devices.”

• Twitter’s Bootstrap in the Asset Pipeline – Hooking it up using the less-rails-bootstrap gem.
• Async JavaScript – Book project on Kickstarter.
• Try Redis – An in-browser demonstration and tutorial.
• HTML5: Browser Caching – the latest from PeepCode.
• riak-ruby-client – This gem has hit version 1.0, for those of you interested in riak.
• Introducing Falcore and Timber – A pipelined web server (written in Go) and a logger library to go with it.
• Heroku and Rails 3.2 asset:precompile error – And how to fix it.
• turn.js – Page-turning animation for your HTML5 sites.
• QuoJS – “Micro JavaScript Library for Mobile Devices.”

For those that do not know, Gauges currently uses Pusher.com for flinging around all the traffic live.

Every track request to Gauges sends a request to Pusher. We do this using EventMachine in a thread, as I have previously written about.

The Problem

The downside of this, is when you get to the point we were (thousands of a requests a minute), there are so many pusher notifications to send (thousands of a minute) that the EM thread starts stealing a lot of time from the main request thread. You end up with random slow requests that have one to five seconds of “uninstrumented” time. Definitely not a happy scaler does this make.

In the past, we had talked about keeping track of which gauges were actually being watched and only sending a notification for those, but never actually did anything about it.

The Solution

Recently, Pusher added web hooks on channel occupy and channel vacate. This, combined with a growing number of slow requests, was just the motivation I needed to come up with a solution.

We (@bkeepers and I) started by mapping a simple route to a class.

class PusherApp < BaseApp
  post '/pusher/ping' do
    webhook = Pusher::WebHook.new(request)
    if webhook.valid?
      PusherPing.receive(webhook)
      'ok'
    else
      status 401
      'invalid'
    end
  end
end

Using a simple class method like this moves all logic out of the route and into a place that is easier to test. The receive method iterates the events and runs each ping individually.

class PusherPing
  def self.receive(webhook)
    webhook.events.each do |event|
      new(event, webhook.time).run
    end
  end
end

At first, we had something like this for each PusherPing instance.

class PusherPing
  def initialize(event, time)
    @event         = event || {}
    @time          = time
    @event_name    = @event['name']
    @event_channel = @event['channel']
  end

  def run
    case @event_name
    when 'channel_occupied'
      occupied
    when 'channel_vacated'
      vacated
    end
  end

  def occupied
    update(@time)
  end

  def vacated
    update(nil)
  end

  def update(value)
    # update the gauge in the
    # db with the value
  end
end

We pushed out the change so we could start marking gauges as occupied. We then forced a browser refresh, which effectively vacated and re-occupied all gauges people were watching.

Once we new the occupied state of each gauge was correct, we added the code to only send the request to pusher on track if a gauge was occupied.

Deploy. Celebrate. Booyeah.

The New Problem

Then, less than a day later, we realized that pusher doesn’t guarantee the order of events. Imagine someone vacating and then occupying a gauge, but receiving the occupy first and then the vacate.

This situation would mean that live tracking would never turn on for the gauge. Indeed, it started happening to a few people, who quickly let us know.

The New Solution

We figured it was better to send a few extra notifications than never send any, so we decided to “occupy” gauges on our own when people loaded up the Gauges dashboard.

We started in and quickly realized the error of our ways in the pusher ping. Having the database calls directly tied to the PusherPing class meant that we had two options:

1. Use the PusherPing class to occupy a gauge when the dashboard loads, which just felt wrong.
2. Re-write it to separate the occupying and vacating of a gauge from the PusherPing class.

Since we are good little developers, we went with 2. We created a GaugeOccupier class that looks like this:

class GaugeOccupier
  attr_reader :ids

  def initialize(*ids)
    @ids = ids.flatten.compact.uniq
  end

  def occupy(time=Time.now.utc)
    update(time)
  end

  def vacate
    update(nil)
  end

private

  def update(value)
    return if @ids.blank?
    # do the db updates
  end
end

We tested that class on its own quite quickly and refactored the PusherPing to use it.

class PusherPing
  def run
    case @event_name
    when 'channel_occupied'
      GaugeOccupier.new(gauge_id).occupy(@time)
    when 'channel_vacated'
      GaugeOccupier.new(gauge_id).vacate
    end
  end
end

Boom. PusherPing now worked the same and we had a way to “occupy” gauges separate from the PusherPing. We added the occupy logic to the correct point in our app like so:

ids = gauges.map { |gauge| gauge.id }
GaugeOccupier.new(ids).occupy

At this point, we were now “occupied” more than “vacated”, which is good. However, you may have noticed, that we still had the issue where someone loads the dashboard, we occupy the gauge, but then receive a delayed, or what I will now refer to as “stale”, hook.

To fix the stale hook issue, we simply added a bit of logic to the PusherPing class to detect staleness and simple ignore the ping if it is stale.

class PusherPing
  def run
    return if stale?
    # do occupy/vacate
  end

  def stale?
    return false if gauge.occupied_at.blank?
    gauge.occupied_at > @time
  end
end

Closing Thoughts

This is by no means a perfect solution. There are still other holes. For example, a gauge could be occupied by us after we receive a vacate hook from pusher and stay in an “occupied” state, sending notifications that no one is looking for.

To fix that issue, we can add a cleanup cron or something that occasionally gets all occupied channels from pusher and vacates gauges that are not in the list.

We decided it wasn’t worth the time. We pushed out the occupy fix and are now reaping the benefits of sending about 1/6th of the pusher requests we were before. This means our EventMachine thread is doing less work, which gives our main thread more time to process requests.

You might think us crazy for sending hundreds of http requests in a thread that shares time with the main request thread, but it is actually working quite well.

We know that some day we will have to move this to a queue and an external process that processes the queue, but that day is not today. Instead, we can focus on the next round of features that will blow people’s socks off.

• RubyGems Guides – This was where I did most of my work the past week, bringing in a new Contributing page and taking editing passes over a few other pages. Details are in the repo.
• RubyGems – Deprecated the separate contribute repo and retargeted the Contribute link on the RubyGems.org home page to point to the Guides Contributing page instead.

Show me the cookies – Updated the documentation for this Capybara addon.

• What’s New in Edge Rails -Finished up #6 in this series.

• Jason – Free JSON viewer and editor for OS X.
• The History of Rubinius – Evan Phoenix offers some insights into the origin and growth of Rubinius.
• Ruby Freelancers – New site featuring a podcast for those interested in getting started.
• Yes, You Should Write Controller Tests! – Argues that as classes, they need test coverage in every method. I find that recently I’ve been writing a lot more integrations than functionals to achieve that, though.
• Shef Tips and Tricks: Steppiong Through Chef-client Runs with Shef – An introduction to the interactive console for the Chef automated provisioning system.
• Backbone.js: A Roundup for Beginners – Start here with a bunch of links to other resources.
• Customising ActiveRecord’s attribute formatting on inspect - Yes, it can be done. And it’s useful.
• Unicode Character ‘PILE OF POO’ (U+1F4A9) – Yes, it’s really part of the standard.
• The Ultimate Collection of Emacs Resources – Yep, you have fun with that.
• StratifiedJS – Another approach to concurrency programming in JavaScript.

• Jason – Free JSON viewer and editor for OS X.
• The History of Rubinius – Evan Phoenix offers some insights into the origin and growth of Rubinius.
• Ruby Freelancers – New site featuring a podcast for those interested in getting started.
• Yes, You Should Write Controller Tests! – Argues that as classes, they need test coverage in every method. I find that recently I’ve been writing a lot more integrations than functionals to achieve that, though.
• Shef Tips and Tricks: Steppiong Through Chef-client Runs with Shef – An introduction to the interactive console for the Chef automated provisioning system.
• Backbone.js: A Roundup for Beginners – Start here with a bunch of links to other resources.
• Customising ActiveRecord’s attribute formatting on inspect - Yes, it can be done. And it’s useful.
• Unicode Character ‘PILE OF POO’ (U+1F4A9) – Yes, it’s really part of the standard.
• The Ultimate Collection of Emacs Resources – Yep, you have fun with that.
• StratifiedJS – Another approach to concurrency programming in JavaScript.