After you build a few Rails apps, you’ll begin to have some preferred ways of working with them. Maybe you always want to use
awesome_print in your Rails consoles. Or you might want
rails new to create projects that use rspec instead of minitest.
Sure, it’s only a little annoying to have to specify these preferences each time you run a command. But they’re easy to forget. And it’s infuriating when a computer doesn’t do what you thought you told it to do:
There is an easier way. With a few small tweaks, you can have these commands remember your preferences, so you won’t have to.
Capture your preferences with
Lots of Ruby tools give you a simple way to store your preferences using
.rc files live in your home directory:
and they give commands like
rails a place to find your preferences. Here are some
.rc files you should try using:
When you run
rails console, you might want to see all of your objects awesome_printed by default. You could type
AwesomePrint.irb! at the beginning of each console session. Or, you can add the command to your
And the next time you start a
rails console, your objects will be printed more awesomely, automatically.
.irbrc is also a great place to put hacky convenience methods that help you play with your objects:
When you customize your environment like this, you’ll begin to feel like the libraries you use are yours, instead of just libraries that you use.
Rubygems has its own
.rc file to make dealing with gems more convenient. Lots of people use
.gemrc to skip rdoc and ri generation, which makes gems install much faster:
But there’s a lot more you can do. There are a few other values you can tweak in your
:sources: (to look for gems on other gem servers) and
:backtrace: (to see a full backtrace when errors occur):
For the rest of the settings you can place in this file, take a look at the gem environment command documentation.
Years ago, Rails 3 made it easy to generate apps that don’t use the default Rails stack. If you want an app that doesn’t use minitest (so you can include rspec later, for example), it’s as simple as:
Or maybe the place you work has their own project template:
Once you get familiar with a Rails stack, you’ll probably want to use it for all your new projects. But it’s easy to forget to add these parameters when you generate another app. Instead, you can put these parameters in a
And now you can run
rails new with the right parameters every time. And if you ever want to override those parameters for a single project, you can do it with
Make your environment yours
A little up-front configuration work can make your environment feel more like home. You can skip the pain of accidentally running a command without the parameters you want. You don’t always have to dig up documentation to find the right options. And you can get to the fun part of writing code right away.