A Template for Starting New Projects on Ruby on Rails

In this story, I want to show you how to bring your Ruby on Rails development to the next level.

Like often in programming, all it takes is automating repetitive stuff.

One task that begs for automation in the Ruby on Rails development is starting new projects.

If from day one you care about:

1. Code quality,
2. Easy maintenance,
3. Good performance,
4. Code that's pleasant to work with,

then you've come to the right place - let's see why.

All this stuff we need...

Starting new Ruby on Rails project is like:

No, seriously - so much stuff to do:

1. Install the latest stable Ruby version - check.
2. Install the latest stable Ruby on Rails version - check.
3. Install the latest stable database version: MySQL, PostgreSQL, you name it - check.
4. Prepare strict separation of config from code: Rails credentials, Dotenv, Figaro - check.
5. Create a new git remote repository: Github, Gitlab, Bitbucket - check.
6. Install the latest stable Redis version - check.
7. Configure ActionCable to use Redis in development to keep the gap between production and development small - check
8. Async code execution, like Sidekiq - check.
9. Create a new project on the monitoring cloud: Rollbar, Sentry, Honeybadger, Bugsnag, Airbrake, Skylight - check.
10. Prepare a cloud storage bucket: Microsoft Azure Blob Storage, Google Cloud Storage, Amazon S3 - check.
11. Prepare SMTP or email sending API settings: Amazon SES, Gmail, Mailgun, Mandrill, SendGrid - check.
12. Send emails in development: MailCatcher, LetterOpener - check.
13. Prepare RSpec configuration for testing, and try not forgetting any of the following: DatabaseCleaner, FactoryBot, TimeCop, Rspec Sidekiq Testing, VCR - check.
14. Oh yeah, code coverage with SimpleCov and Coveralls - yeah, I forgot when talking about RSpec - check.
15. Keep the bar up: RuboCop, RuboCop Performance, RuboCop RSpec, RuboCop Rails, Fasterer, Brakeman, Dawnscanner, Bundle Audit, Rails Best Practices - check.
16. Set up this whole standardized-code in the Continuous Integration - Github Actions, GitlabCI, Bamboo, CircleCI, Travis - check.

Damn, that's a handful.

Now, try for example to not keep the bar up from the first commit, and someone will take a crap in the middle of your code base - happily.

Not to mention sending emails in development to some random folks, and doing it synchronously, cause "ah,

ActiveWork

Or, let's skip logging errors and leave the default logger only. Then enroll the MVP blindfolded.

And.. have you noticed? Not a word yet about:

1. Deployment, not to mention a Continuous Delivery and

   staging

   ,

   preprod

   and

   whatnot

   environment.
2. Front-end setup, that nowadays, with rich JavaScript doubles some of those points: like linting, separate tests.

Don't get me wrong, I love Ruby on Rails, it's still my favorite - so much stuff out of the box.

Just all this configuration is what, like two, three workdays?

Disclaimer: it's minutes with Hix on Rails Application Template.

Default Ruby on Rails options

Before we get to the template, one cool thing worth mentioning with Rails are the default

new

When using

rails new

$ rails new --help                                                                   
Usage:
  rails new APP_PATH [options]

Options:
      [--skip-namespace], [--no-skip-namespace]              # Skip namespace (affects only isolated applications)
  -r, [--ruby=PATH]                                          # Path to the Ruby binary of your choice
                                                             # Default: /usr/share/rvm/rubies/ruby-2.6.1/bin/ruby
  -m, [--template=TEMPLATE]                                  # Path to some application template (can be a filesystem path or URL)
  -d, [--database=DATABASE]                                  # Preconfigure for selected database (options: mysql/postgresql/sqlite3/oracle/frontbase/ibm_db/sqlserver/jdbcmysql/jdbcsqlite3/jdbcpostgresql/jdbc)
                                                             # Default: sqlite3
      [--skip-gemfile], [--no-skip-gemfile]                  # Don't create a Gemfile
  -G, [--skip-git], [--no-skip-git]                          # Skip .gitignore file
      [--skip-keeps], [--no-skip-keeps]                      # Skip source control .keep files
  -M, [--skip-action-mailer], [--no-skip-action-mailer]      # Skip Action Mailer files
      [--skip-action-mailbox], [--no-skip-action-mailbox]    # Skip Action Mailbox gem
      [--skip-action-text], [--no-skip-action-text]          # Skip Action Text gem
  -O, [--skip-active-record], [--no-skip-active-record]      # Skip Active Record files
      [--skip-active-storage], [--no-skip-active-storage]    # Skip Active Storage files
  -P, [--skip-puma], [--no-skip-puma]                        # Skip Puma related files
  -C, [--skip-action-cable], [--no-skip-action-cable]        # Skip Action Cable files
  -S, [--skip-sprockets], [--no-skip-sprockets]              # Skip Sprockets files
      [--skip-spring], [--no-skip-spring]                    # Don't install Spring application preloader
      [--skip-listen], [--no-skip-listen]                    # Don't generate configuration that depends on the listen gem
  -J, [--skip-javascript], [--no-skip-javascript]            # Skip JavaScript files
      [--skip-turbolinks], [--no-skip-turbolinks]            # Skip turbolinks gem
  -T, [--skip-test], [--no-skip-test]                        # Skip test files
      [--skip-system-test], [--no-skip-system-test]          # Skip system test files
      [--skip-bootsnap], [--no-skip-bootsnap]                # Skip bootsnap gem
      [--dev], [--no-dev]                                    # Setup the application with Gemfile pointing to your Rails checkout
      [--edge], [--no-edge]                                  # Setup the application with Gemfile pointing to Rails repository
      [--rc=RC]                                              # Path to file containing extra configuration options for rails command
      [--no-rc], [--no-no-rc]                                # Skip loading of extra configuration options from .railsrc file
      [--api], [--no-api]                                    # Preconfigure smaller stack for API only apps
  -B, [--skip-bundle], [--no-skip-bundle]                    # Don't run bundle install
  --webpacker, [--webpack=WEBPACK]                           # Preconfigure Webpack with a particular framework (options: react, vue, angular, elm, stimulus)
      [--skip-webpack-install], [--no-skip-webpack-install]  # Don't run Webpack install

Runtime options:
  -f, [--force]                    # Overwrite files that already exist
  -p, [--pretend], [--no-pretend]  # Run but do not make any changes
  -q, [--quiet], [--no-quiet]      # Suppress status output
  -s, [--skip], [--no-skip]        # Skip files that already exist

Rails options:
  -h, [--help], [--no-help]        # Show this help message and quit
  -v, [--version], [--no-version]  # Show Rails version number and quit

Description:
    The 'rails new' command creates a new Rails application with a default
    directory structure and configuration at the path you specify.

    You can specify extra command-line arguments to be used every time
    'rails new' runs in the .railsrc configuration file in your home directory.

    Note that the arguments specified in the .railsrc file don't affect the
    defaults values shown above in this help message.

Example:
    rails new ~/Code/Ruby/weblog

    This generates a skeletal Rails installation in ~/Code/Ruby/weblog.

And there's a handful to remember, as you can see.

If you already built some Ruby on Rails apps, you probably have a list of options you don't like, or you're in the PostgreSQL or MySQL camp.

If that's the case, you can define the magic ~/.railsrc file in your home directory, with initialization flags that you always use.

touch ~/.railsrc
vi ~/.railsrc

For example, my looks like this:

--database=postgresql
--skip-spring
--skip-test
--webpack=react
--template=https://hixonrails.com/template.rb

Here, I tell every

rails new

1. go Postgres!
2. nope Spring
3. nope MiniTest, I want RSpec
4. go React!

And the last thing: use the Rails Application Template.

Say what?

Ruby on Rails - Application Template

Ruby on Rails Application Templates are simple files with a Domain Specific Language.

You can add stuff to the brand new Ruby on Rails project - initializers, gems, rake tasks - you name it.

rails new project --template /path/to/template.rb
rails new project --template https://example.com/template.rb

Simple, yet so powerful.

The template code runs after the initial Rails configuration, and before the bundle installs.

That means that you can:

1. Override every file generated
2. Add any gems you want
3. Create new files
4. Create database tables

On top of that, you can run any shell command.

For example: create a remote git repository via Github or Gitlab API.

Afterwards add the git remote to the project.

So cool.

Template DSL

Let's now take a quick look what we can do using Rails App Template specific language:

1. Install and group gems by environments with

   gem

   and

   gem_group

2. Declare gem sources with

   add_source

   method
3. Write to declared

   environment

   files
4. Write

   lib

   ,

   initializer

   ,

   vendor

   ,

   rakefile

   and any

   file

   with HEREDOC
5. Gather user input with

   ask

   ,

   yes?

   and

   no?

   methods and run other stuff conditionally
6. Launch rails

   generator

   for scaffold, migration, model, controller, whatever
7. Execute

   git

   commands
8. Explicitly run selected code

   after_bundle

   installs.
9. Execute shell commands with the

   run

   method.

That's a lot of useful stuff right here, so let's see it in action.

Rails Application Template with static code analysis

Let's give some of the methods a spin by setting up a really simple Rails Application Template, that:

1. Installs and uses RuboCop by default
2. Installs and requires RuboCop Performance extension
3. Installs and requires RuboCop Rails extension

So here's how to do that.

First, let's create our template.rb file and open it with a text editor.

vi ~/ws/articles/hackernoon/template.rb

Next, let's install all the RuboCop gems in the

development

test

 # frozen_string_literal: true
 
 gem_group :development, :test do
   gem 'rubocop'
   gem 'rubocop-performance'
   gem 'rubocop-rails'
 end

Now that we have those in place, let's tell Rails to add the .rubocop.yml file, so we can loose up those restrictions a little.

Add the following code.

file '.rubocop.yml', <<-CODE
require: 
  - rubocop-rails
  - rubocop-performance

AllCops:
  Exclude:
    - node_modules/**/*
    - db/**
    - db/migrate/**
    - bin/**
    - vendor/**/*

Layout/LineLength:
  Max: 120

Metrics/BlockLength:
  Exclude:
    - config/**/*

Style/Documentation:
  Enabled: false
CODE

That's going to write our RuboCop configuration file in the root of the new Ruby on Rails application initialized with the template.

The last thing is to clean up the default Rails code with RuboCop after the project initializes, and when all RuboCop gems are available.

Hint: after bundle installs.

Add the following code:

 after_bundle do
   run 'bundle exec rubocop --auto-correct'
 end

At the point of writing this article, with Rails 6.0.2.1, it fixed 75 of 78 offenses automatically, so I needed to do some work manually.

$ bundle exec rubocop
Inspecting 31 files
.............C...............CC

Offenses:

config/environments/development.rb:19:6: C: Rails/FilePath: Please use Rails.root.join('path/to') instead.
  if Rails.root.join('tmp', 'caching-dev.txt').exist?
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
test/channels/application_cable/connection_test.rb:5:7: C: Style/ClassAndModuleChildren: Use nested module/class definitions instead of compact style.
class ApplicationCable::ConnectionTest < ActionCable::Connection::TestCase
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
test/test_helper.rb:7:7: C: Style/ClassAndModuleChildren: Use nested module/class definitions instead of compact style.
class ActiveSupport::TestCase
      ^^^^^^^^^^^^^^^^^^^^^^^

31 files inspected, 3 offenses detected

Not so much though.

Less hardcore option is using the

--safe-auto-correct

FrozenStringLiteral

For those chickens who don't like code that writes code, there's a lightweight alternative that'll point to all the violated lines in the special .rubocop_todo.yml file.

 after_bundle do
   run 'bundle exec rubocop --auto-gen-config'
 end

It does two things:

1. Launches a dry run of RuboCop, that writes .rubocop_todo.yml with violated files excluded from the next RuboCop runs
2. Edits .rubocop.yml file, telling it to mind the exclusions

This way you can make sure that RuboCop's auto-correction does not beak anything, by fixing it all one by one, by hand. No YOLO though.

Now all that's left to be done is launching the Rails installer pointing to our new template file:

rails new project_name --template=/path/to/local/template.rb

Sit back and relax - it all happens automatically. Cool, huh?

When to use Rails Application Template

Everytime, really, cause why the hell not.

But for some it is a goldmine:

Software Houses: let's say one project a week, doing all this stuff - I can only imagine that there's this one go-to guy, probably mid to senior level, that sets the stuff up, for one to three working days.

I remember my co-worker telling me a story about someone, who worked at a Software House and once per two weeks he was literally installing the same gems in a next new project all over again.

There's even a company that I know for a fact that uses their own application template, cause they open-sourced it.

Next, Freelancers: if you happen to take on some work and code in Ruby on Rails, it's a great way to speed up the process.

Last, Corporations, or any micro services freaks, even smaller companies.

I'd say that if you:

1. Maintain around five Ruby on Rails projects already,
2. Keep certain coding standards in your development team,

it's time to extract the commonly used stuff to the template before starting the next project.

If you like to compartmentalize stuff into small Ruby on Rails pieces, Application Templates are the way to go.

What's the problem with Rails Application Template?

Maintenance. You won't use it that often.

Rails itself, same as a lot of gems that you happily use, evolve.

You can lock the gems versions, but it's not the best idea - it's better to use the latest stable versions available, for a security reasons if not for anything else.

Worry not though, cause those are exact reasons why Hix on Rails decided to take care of all the up-to-date stuff, so you can focus on what really matters for you.

Just get to the point and implement business logic after completing a short wizard in the CLI. Painlessly, simple as that.

Conclusion

So, how do you like the concept of automating Ruby on Rails projects initialization?

Do you have in mind anything that would be so cool to go into the Rails Application Template?

Maybe you already use templates yourself, and I've missed something?

I'd love your feedback - please, tell me in comments!