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:
$ rails new best_app_ever
^C (sigh...)
$ rm -r best_app_ever
$ rails new best_app_ever --template=my_template
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 .rc files
Lots of Ruby tools give you a simple way to store your preferences using .rc files.
.rc files live in your home directory:
$ ls ~/.*rc
.bashrc .irbrc .screenrc
.gemrc .railsrc .zshrc
and they give commands like gem, irb, and rails a place to find your preferences. Here are some .rc files you should try using:
.irbrc
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 ~/.irbrc file:
require "awesome_print"
AwesomePrint.irb!
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:
require "awesome_print"
AwesomePrint.irb!
# returns the instance methods on klass
# that aren't already on Object
def m(klass)
klass.public_instance_methods - Object.public_instance_methods
end
~/Source/rcfiles jweiss$ bin/rails c
Loading development environment (Rails 4.1.1)
irb(main):001:0> m ActiveRecord::Base
[
[ 0] [](attr_name) ActiveRecord::Base (ActiveRecord::AttributeMethods) (unbound)
[ 1] []=(attr_name, value) ActiveRecord::Base (ActiveRecord::AttributeMethods) (unbound)
[ 2] _commit_callbacks()
... about 200 more methods...
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.
.gemrc
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:
gem: --no-document
But there’s a lot more you can do. There are a few other values you can tweak in your .gemrc, including :sources: (to look for gems on other gem servers) and :backtrace: (to see a full backtrace when errors occur):
gem: --no-document
:backtrace: true
:sources:
- https://my.internal.gem.server
- https://rubygems.org
For the rest of the settings you can place in this file, take a look at the gem environment command documentation.
.railsrc
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:
$ rails new my_awesome_app --skip-test-unit
Or maybe the place you work has their own project template:
$ rails new my_awesome_corporate_app --template=http://example.com/my_app_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 .railsrc file:
--template=http://example.com/my_app_template
--database=postgresql
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 --no-skip-test-unit-style commands.
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.