Use PostgreSQL 9.3 on Travis CI

Heroku's default is Postgres 9.3 [1], but Travis' default is Postgres 9.1
[2]. This can occasionally cause problems which are difficult to debug.

[1]: https://devcenter.heroku.com/articles/heroku-postgresql#version-support
[2]: http://docs.travis-ci.com/user/using-postgresql/
Set up Segment.io by default

In order to analyze metrics later, we need to instrument our app to log
the right metrics. The primary type of instrumentation we care about is
called "event tracking."

We use Segment.io to capture events whenever possible. It is basically
the adapter pattern for analytics services.

Segment.io lets us drop one JS library into our web apps, or one Ruby
library into our server-side framework, or one iOS SDK into our mobile
apps. Then, we can toggle on and off different services such as Google
Analytics, Intercom, and others.

http://playbook.thoughtbot.com/#instrumentation

If we are working on an app that uses authentication through a library
such as Clearance, we should add the following to
`app/views/application/_analytics.html.erb`:

    <% if signed_in? %>
      <%= render 'signed_in_analytics' %>
    <% end %>

https://github.com/thoughtbot/clearance

At that time, we should also add
`app/views/application/_signed_in_analytics.html.erb`:

    <script type="text/javascript">
      analytics.identify("#{current_user.id}", {
        created : "#{current_user.created_at}",
        email : "#{current_user.email}"
      }, {
        Intercom : {
          userHash : "#{OpenSSL::HMAC.hexdigest('sha256',
    ENV['INTERCOM_API_SECRET'], current_user.id.to_s)}"
        }
      });
    </script>

The most likely first signed in service we'll want is Intercom. It plays
two important roles for an early stage product:

1. communication (and support) with customers and
2. measuring retention (such as Weekly Active Users)

https://intercom.io
Set up staging and production for CDN

The value of `ASSET_HOST` will look like `//global.prod.fastly.net`.

In production every asset has a hash added to its name. Whenever the
file changes, the browser requests the latest version as the hash and
therefore the whole filename changes.

Putting the assets version in an environment variable makes it possible
to invalidate the cache without a re-deploy, if necessary. Simply re-set
the `ASSETS_VERSION` as a Heroku config variable to change the hash
globally and make the browser request every asset again.

Stuff we already have in Suspenders that makes this all work:

Gemfile:

    gem 'coffee-rails'
    gem 'sass-rails'
    gem 'uglifier'

config/environments/{staging,production}.rb:

    config.assets.compile = false
    config.assets.digest = true
    config.assets.js_compressor = :uglifier

We don't have to set `config.serve_static_assets = true` because the
`rails_12factor` gem does it for us.

We recommend using Fastly for the CDN.

http://www.fastly.com/
Bump to 1.12.0
Remove FactoryGirl.lint in before(:suite)

We estimate that `lint`ing adds an extra ~300ms on a typical app we work
on for every `rspec` run, even a focused test that only runs one spec.
Until we can find a way to avoid paying that penalty, the discussion
below has landed at not putting it in Suspenders:

https://github.com/thoughtbot/suspenders/pull/299/files#r10642936
Remove before(:suite) block
Join the Heroku app in bin/setup
Bump to 1.13.0
Set `viewport` to `initial-scale=1`

This sets the content's initial scale to 1 for mobile devices. Without
this tag, devices will load the page zoomed out to fit the entire
content on the screen. This is needed when using a responsive grid
framework such as Bourbon Neat.

https://developer.apple.com/library/ios/documentation/appleapplications/reference/safariwebcontent/usingtheviewport/usingtheviewport.html
https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag
Use RSpec 2.x until Travis/Capybara issues resolve

https://travis-ci.org/thoughtbot/suspenders/builds/26602519

    rspec-support-3.0.0/lib/rspec/support/version_checker.rb:28:in
    `raise_too_low_error': You are using capybara 2.1.0. RSpec requires
    version >= 2.2.0. (RSpec::Support::LibraryVersionTooLowError)

https://rubygems.org/gems/capybara-webkit
Enforce Ruby version

The pessimistic operator makes it possible to install Suspenders on Ruby
2.1.2 but then run Suspenders and have it not bundle because the Gemfile
is restricted to Ruby 2.1.1. This change enforces an exact Ruby version.
Remove SimpleCov

* SimpleCov was returning zero status even when build failed.
* Remove SimpleCov so that we get real build results on Travis.
* The team was reporting not regularly reviewing the coverage stats.
Add bitters during setup
Use Ruby 2.1.2

Group gemspec dependencies together.
Lock Suspenders to a Rails version

This is intended to help solve the error people are seeing by having
Rails 4.1.2rc1 on their machine:

    thoughtbot/suspenders/lib/suspenders/actions.rb:7:in
    `replace_in_file': "config.assets.version = '1.0'" not found in
    config/environments/production.rb (RuntimeError) from
    thoughtbot/suspenders/lib/suspenders/app_builder.rb:94:in
    `setup_asset_host' from
    gems/railties-4.1.2.rc1/lib/rails/generators/app_base.rb:133:in
    `build'

I don't think it will totally solve the issue but it is at least more
declarative. To totally solve it, I think we need to fail fast when the
script runs by checking for `rc` in the `gem list railties` output or
something.
Avoid `gem build` error

* Use more specific version requirements.
* Use `>=` instead of `==` for Ruby version check.

Fixes:

    ERROR:  Error installing
    /Users/croaky/github.com/thoughtbot/suspenders/pkg/suspenders-1.13.0.gem:
            suspenders requires Ruby version = 2.1.2.
Bump to 1.14.0
Add byebug

* An interactive debugger is an essential tool for debugging behavior
* byebug is the most stable and usable debugger on Ruby 2
Upgrade Capybara and Capybara Webkit

The previous stable release of capybara-webkit didn't support Capybara 2.3. We
just released capybara-webkit 1.2, with support for the latest version.
Remove Pow in bin/setup

Our primary issue is that we do not have development/staging/production parity
when using Pow locally. Pow doesn't use event machine or a forking model, so:

* Projects using Thin will work locally but not work in production if they use
  threads or gems with eventmachine incorrectly
* Projects using Unicorn will work locally but not in production if process
  spawning is not managed correctly

Using Pow in development and something else in production would be like using
single threaded code in development but multiple threads in production; we'll
end up with race conditions eventually.

Pow is more different from production than Foreman is (at least Foreman uses the
same web server), and it's likely to be different from other members of the
team.

We'd prefer to have only one way of running the app within a project and we'd
prefer to have that way be as close to production as possible.

Keeping it the same reduces the likelihood that somebody breaks the app for
everybody else because of a "works on my machine" scenario. It also reduces the
number of onboarding questions, because everybody sets up and runs the app the
same way: `bin/setup` and `foreman start`.