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 debugger, but I’m used to using Pry. This gem (from the author of Byebug) brings Byebug’s nice step-by-step debugging and stack navigation capabilities to Pry.
Pry and Byebug are posts in there own right and have probably been written already, but the short version is that dropping:
binding.pry
or
byebug
anywhere in your code and when it runs you’ll be dropped in to a full blown debugger that looks a lot like the Rails console. You can inspect and change variables and step through code. Either is a huge help when debugging incoming data.
Once I have my tools in place, I usually throw in one more gem:
gem 'bootstrap-sass'
and replace the contents of app/views/layouts/application.html.erb
with:
<!DOCTYPE html>
<html>
<head>
<title><%= application_name %></title>
<%= csrf_meta_tags %>
<%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
<%= javascript_include_tag 'application', 'data-turbolinks-track': 'reload' %>
</head>
<body>
<div id="wrapper" class="container-fluid">
<%= yield %>
</div>
</body>
</html>
which gives me a simple blank canvas to work on.
And finally:
git init
git add .
git commit -m 'Blank Slate'
Typically, I hang on to this for a while, creating new projects out of it. However, fairly regularly, I rebuild it so everything is bleeding edge. I could automate the process, but honestly I haven’t felt like tackling the fiddly bits of inserting code into the development/test and production blocks.
I’m not saying this is the right way to do it, but it works well for me. What works for you?
Comments