./bin/setup

In our protocol guide, we instruct new developers to set up an existing Rails app like this:

git clone git@github.com:organization/app.git
cd app
./bin/setup

The goal of the bin/setup script is quick, reliable, consistent setup. It is placed in the bin directory to match new Rails conventions about executables.

Here’s an example bin/setup:

#!/bin/sh

# Set up Rails app. Run this script immediately after cloning the codebase.
# https://github.com/thoughtbot/guides/tree/master/protocol

# Set up Ruby dependencies
bundle install --binstubs

# Set up staging and production git remotes
git remote add staging git@heroku.com:app-staging.git
git remote add production git@heroku.com:app-production.git

# Set up database
bundle exec rake db:setup

# Set up configurable environment variables for Foreman
if [ ! -f .env ]; then
  echo "RACK_ENV=development" > .env
fi

echo "port: 7000" > .foreman

# Set up DNS through Pow
if [ -d ~/.pow ]
then
  echo 7000 > ~/.pow/`basename $PWD`
else
  echo "Pow not set up but the team uses it for this project. Setup: http://goo.gl/RaDPO"
fi

The first section uses Bundler’s binstubs.

The second section sets up git remotes for staging and production commands.

The third section creates the development and test databases, loads the schema, and initializes with the seed data. It does not need to run all the migrations.

The last two sections use Foreman as process manager, Pow as DNS server and HTTP proxy.

This is just an example bin/setup file. Each project will be different. Some might not use Pow. Some might test if Redis or MongoDB is installed and run, install, or print a message if not. Some might want to pull some ENV variables into .env from Heroku.

Regardless of the bin/setup file’s contents, a developer should be able to clone the project and run a single, consistent, reliable command to start contributing.

Written by Dan Croak.

Directory for shared partials in Rails

Which directory should contain shared partials in a Rails app?

Rejected option: app/views/layouts directory

I’ve seen this:

app/views/layouts/application.html.erb
app/views/layouts/_flashes.html.erb
app/views/layouts/_footer.html.erb
app/views/layouts/_header.html.erb
app/views/layouts/_javascript.html.erb
app/views/layouts/_navigation.html.erb

However, the layout directory should contain… layouts.

app/views/layouts/application.html.erb

Rejected option: app/views/shared directory

I’ve seen this:

app/views/shared/_flashes.html.erb
app/views/shared/_footer.html.erb
app/views/shared/_header.html.erb
app/views/shared/_javascript.html.erb
app/views/shared/_navigation.html.erb

That was the recommendation in the classic, Agile Web Development with Rails.

Also, when you extracted a partial from a layout in rails.vim using :Rextract, it would automatically place the extracted partial into the shared directory.

Current solution: app/views/application directory

This is our current standard:

app/views/application/_flashes.html.erb
app/views/application/_footer.html.erb
app/views/application/_header.html.erb
app/views/application/_javascript.html.erb
app/views/application/_navigation.html.erb

The main reason is a subtle, but functional difference: template inheritance.

Also, invoking the partials is slightly shorter with this approach. Instead of:

render 'shared/navigation'

This is possible from every view:

render 'navigation'

We have formalized this convention in Suspenders

Sharing is caring.

Written by Dan Croak.