It’s 2012. We know it’s the World Wide Web. We don’t need to be reminded of
that by prepending www. to the URL of every site we visit. In fact, the use of www. as the
de facto subdomain of The Web was an accident. And
what’s more, it was deprecated back in August of 2003.

I am over www. and hereby pledege to do my best to stop using it on the
portions of the Internet that I build. To be successful, I need the Ruby on
Rails-powered apps I create to also drop the dubs. The powerful
router in Rails 3 (and newer) makes this trivial. Peep this:

Let’s talk about what’s going on there…

Routing Constraints

That outermost constraints block is a Rails routing constraint
that only matches requests where the host starts with www.. When that
constraint is met, we match ALL THE PATHS and any HTTP verb. Upon making the match, we tell the router
to redirect the request to a new URL.

The new URL is whatever URL the request came in on, sans the leading www..

Easy peasy!

What if you want the dub-dub-dub?

For starters, I’ll hold it against you. But then I’ll immediately get over it
and we’ll go back to being friends.

In fact, as a token of my friendship, I’ll show you how to redirect non-www.
requests to a www.-version.

This works much like the first example, but in reverse. An incoming request
lacking a leading www. matches our constraint and gets redirected to the same
URL prefixed with a www..

Also easy, just more dub-dubs.

To www. or not?

Do you have a preference or just an argument? Let’s hear it!

The post Redirect www Subdomain to Your Apex Domain Using the Rails Router appeared first on Big Nerd Ranch.

Database-bound tests are a drag. Inconsistent tests are a pain. Database-bound,
inconsistently failing tests are the worst!

The following commit message is from a real code base:

Run in transactions by default.

When we added controller specs they weren’t being run w/any kind of DB
cleaner b/c there was no default strategy and they weren’t explicitly
included in a group. Now, we use :transactions be default, setting request
specs to use :truncation

Also, I saw a 2 second speed up from this change!

myself

Let’s look at what we changed in this commit to turn our inconsistently failing
database-bound tests into slightly faster, consistent, database-bound tests.

Prefer isolated tests

Whenever possible I strive to write isolated tests, stubbing out collaborators
where necessary, while driving from the outside of the system downward, one
layer at time. However, there are occasions where you must hit the database.

Testing ActiveRecord scopes and higher-order acceptance tests are two cases
where I believe it is okay to have tests which cross layers, and may even hit a
database.

Ensuring idempotent tests

When you are going to hit a database, your
tests should be good citizens and clean up after themselves.

If you’re using RSpec with Rails your tests run within a transaction
by default. Yay!

Unfortunately, test tooling like Capybara won’t work with
transactions and you’ll be forced to resort to techniques like database
truncation to ensure proper data clean up. I really like Database
Cleaner for that job.

An example RSpec configuration

What follows is the RSpec configuration we ended up with after the previously
mentioned commit. Or at least a very close approximation of it

A few key take aways:

To start, turn off RSpec’s built-in transaction support as we’ll handle that
with database_cleaner.

Next we configure a default clean-up strategy for every RSpec suite. We’ll use
transactions by default, being sure to clean up any thing that might have been
left behind with a truncation.

We make a special exception for request specs, which are often driven by
Capybara, and switch them over to truncation.

Then, before every test runs start Database Cleaner

And finally, after every test runs, tell Database cleaner to clean up using
whatever strategy it is currently configured with.

For posterity’s sake, you can see a full before and after of
this particular spec_helper on The GitHubs.

The post Reasonable RSpec Config for Clean, and Slightly Faster, Specs appeared first on Big Nerd Ranch.

This weekend we Big Nerd Ranch (a.k.a. Taconauts) took some time to do one of the things we really love: create and release Open Source Software. In fact, we released not one, but three new tools into the world: grocer, git_tracker, and puppet-osx_defaults.

Announcing: grocer

Grocer interfaces with the Apple Push Notification Service to send push notifications to iOS devices and collect notification feedback via the Feedback Service. There are other gems out there to do this, but Grocer plans to be the cleanest, most extensible, and friendliest.

Andy, Patrick, and I built the grocer in the course of just two days. Andy and I started it with a morning-long ping pong-pairing session on Thursday, the three of us hacked on it through the afternoon and most of Friday, and pushed it out Friday night.

Announcing: git_tracker

Some simple tricks that make working with Pivotal Tracker even better… and easier… um, besier!

I technically pushed the first version (0.0.1) of git_tracker a week ago, but it went v1.0 Saturday afternoon. Please give it a shot, and feel free to open issues and send pull-requests.

Announcing: puppet-osx_defaults

This is a simple puppet module for managing the defaults system in OS X. It currently has support for defaults domain keys whose values are boolean, integer, or string types.

Will, a lover of all things automated, whipped together a Puppet script for sane OS X defaults.

Image credit: http://timmyclunkers.tumblr.com/

The post Weekend Update: Open-Source Software Contributions appeared first on Big Nerd Ranch.