Google Analytics Navigation

Enter Rack::Rewrite. Rack::Rewrite is a Rack middleware for defining and applying rewrite rules. Though it’s not a full replacement for Apache’s mod_rewrite, a great deal of rules I’ve previously written in Apache config files can be replaced by Rack::Rewrite. Run gem install rack-rewrite to install the gem.

In order to determine which URL’s were most important to issue 301′s for, we turned to Google Analytics. By reviewing the most popular landing pages of the past two months from our site, we were able to methodically write our redirect rules.

Google Analytics | Top Landing Pages

Here is a subset of the associated Rack::Rewrite rules.

  config.middleware.insert_before(Rack::Lock, Rack::Rewrite) do        
    # original wiki smartlogicsolutions.com website
    r301 '/wiki/Main_Page', '/'
    r301 '/wiki/John_Trupiano', '/john'
    r301 %r{^/wiki/(Charity|Charities|Local_Connection)$}, '/gratis-work-and-charities'
    r301 '/wiki/Category:Portfolio', '/portfolio'
    r301 '/wiki/ExxonMobil_-_Brand_Asset_Center', '/portfolio/exxonmobil-brand-asset-center'
    r301 '/wiki/In_the_News', '/in-the-news'
    r301 '/wiki/Getting_to_our_Office', '/driving-directions'
    r301 '/wiki/Category:Employees', '/our-team'
    r301 '/wiki/SimNet_for_Office_2007', '/portfolio/simnet-for-office-2007-and-vista'
    r301 '/wiki/VNC_Collaboration_Application', '/portfolio/shared-desktop'
    r301 '/wiki/Contact_Information', '/contact-us'
  end

This scheme is great for landing pages, but what if we had querystring information that we wanted to keep around? This is common for tracking codes — many marketing platforms generate URL’s that embed data in the querystring for recording and tracking purposes. We can leverage the following trick to maintain the querystring across a rewrite.

  r301 %r{^/wiki/Main_Page(\?.*)?$}, '/$1'

Note the following:

• We are conditionally matching a querystring so that the rule continues to match in the absence of a querystring.
• We are leveraging substitution patterns to reconstitute the querystring in the rewritten URL.

Many more great use cases for Rack::Rewrite are covered in the project’s README.

The primary feature added was the distinction between “freezing” and “rebasing” time. In 0.1.0, Timecop.travel would actually freeze time. This is no longer the case. Rather, a time offset will be calculated, and a running clock is simulated by always offsetting the time returned by Time.now (and friends) by the original offset.

(Note that time can still be frozen with Timecop.freeze.)

To update a previous version:

sudo gem update timecop

To install for the first time:

sudo gem install timecop

The new feature set allows us to avoid the following common pitfalls that were present in 0.1.0.

1. In rails, if you had set up a time mock in the development environment, then every time you invoked script/generate migration (and others), the generator would read your mocked instance of Time.now, and use that date for the migration name.
2. Any benchmarking/timing code executed within the yielded block would always return times of 0 seconds. This was due to time being frozen.

The other major change to the API was the deprecating of Timecop.unset_all in favor or Timecop.return.

This update also vastly improves the rdoc, making the public API much more accessible. The Timecop class has particularly thorough documentation.

For a more complete description of the gem, please refer to the introductory blog post.