How I Start Rails Projects
Everyone has their patterns, here’s mine for starting a new Rails project:
rvm use 2.3.1@project-name --create
gem install rails
rails new project-name
cd project-name
rvm use 2.3.1@project-name --ruby-version
echo '/.ruby-*' >> .gitignore
The Rails command is probably familiar. I use RVM
to manage my Ruby versions and project gems. rvm use
2.3.1@project-name --create
creates a new “gemset”, which is a
per-project private set of gems. This is nice, because it avoids
conflicts and means I don’t have to type “bundle exec” in front of
everything. There are other, equally good, ways to manage Ruby
versions (rbenv for example) and
other ways to avoid having to run Bundler, but this is the one I use.
The second invocation of RVM rvm use 2.3.1@project-name
--ruby-version
, creates two files .ruby-version and
.ruby-gemset. The files work with hooks that RVM puts in to the
shell that cause it to switch Ruby versions and gemsets when you cd
in to that directory (or any of it’s sub directories).
These files work with rbenv as well, but I prefer to let other developers make their own choices here, which is why I add them to .gitignore.
Once I have a blank slate, it’s time to tweak the gems in the Gemfile. First, I set the Ruby version by adding:
ruby '2.3.1'
right after the source line. I have been bitten too many times by Heroku’s older default version to not do this.
Next I find:
# Use sqlite3 as the database for Active Record
gem 'sqlite3'
Near the top of the Gemfile and move it to the Development and Test section:
group :development, :test do
# Use sqlite3 as the database for Active Record in development
gem 'sqlite3'
[...]
end
We’re going to use something else in production and if we’re deploying to Heroku, the gem will fail to install. I then replace it at the top of the file with:
group :production do
# Use PostgreSQL as the database for Active Record
gem 'pg' # or gem 'mysql2'
end
depending what the production server will have.
Back in the Development and Test section of the Gemfile I add:
group :development do
[...]
gem 'dotenv-rails'
gem 'awesome_print'
gem 'pry-byebug'
end
dotenv-rails automatically sets
environmental variables from a .env
file in the root of your
app. The format is simple:
SOME_API_KEY="s0m3th1ng"
It’s an easy way to set values in development that you will have in production (from Apache “SetEnv” or Heroku “config:set”). These are things you don’t want check in, so be sure to also:
echo '/.env' >> .gitignore
Awesome Print is a “ruby object pretty printer”. It add an “ap” method which nicely formats and syntax highlights things like hashes and objects:
> data = { :now => Time.now, :class => Time.now.class, :distance => 42e42 }
=> {:now=>2016-09-29 20:19:02 -0600, :class=>Time, :distance=>4.2e+43}
> ap data
{
:now => 2016-09-29 20:19:02 -0600,
:class => Time < Object,
:distance => 4.2e+43
}
If you are using Awesome Print, stick this in your ~/.irbrc
:
begin
require "awesome_print"
AwesomePrint.irb!
rescue LoadError => e
end
That will make Awesome Print the default formatter in IRB and the Rails Console, meaning that anytime it would display an object, you get the Awesome Printed version.
pry-byebug brings in the Pry debugger. Rails already ships with the Byebug