Spring is a Rails application preloader. It speeds up development by keeping your application running in the background so you don’t need to boot it every time you run a test, rake task or migration. If you have a big application and every command need 5-10s to begin to run, then give Spring a try and you would love it!
Rails 4.1 generates a new
secrets.yml file in the config folder. By default, this file contains the application’s
secret_key_base, but it could also be used to store other secrets such as access keys for external APIs.
The secrets added to this file are accessible via
When creating a new project, you will see something like this in your
# Do not keep production secrets in the repository,
# instead read values from the environment.
You can access your secret key by
Wow, it seems awesome at the first sight, but after a while (in fact, about 5 mins after I created the project), I started to feel something is not right.
Firstly, I must type
bin/rails g instead of
rails g. I want to use Spring to make my command run faster but if I have to type more words then it defeats the purpose. I still lose my time (not waiting but typing).
Secondly, the old thing about secret key. I shouldn’t put my AWS key in my repo, right? So, don’t commit
secrets.yml. Then why don’t use ENV from the first place?
This really annoyed me so I searched around and found this a blog post by Figaro. He pointed out pros and cons of secrets.yml. And in final release, secrets.yml still has not been added to
.gitignore yet. If Rails team doesn’t want to do this, it should be committed to my repo then, right?
So I still need to use Figaro (or dotenv) to keep my private stuff private.
Make it work
Then, I found a small tool that can help us solve two problems above. It’s called direnv. It is a shell extension that loads different environment variables depending on your path.
Check out official guide
Use Spring with direnv
So instead of type
bin/rails I want to type the old
rails only, the easiest way to do this is make your application
bin/rails appear first in your
At your application folder
direnv edit .
It will create a
.envrc, add this line
Whenever you go to your application folder, it will source this file and
rails will be
bin/rails under your application folder location. Sweet!
secrets.yml with direnv
Now the first problem is solved, how about the second one?
In secrets.yml, they use
ENV, to define
ENV variables we still need Figaro (or dotenv).
Don’t tell me you export permanently in your env or export it temporary in current shell.
What about dynamically addding it when and only when I go to my application folder? Hey, we’ve just done it to solve the first problem right, why don’t place it in our
.envrc and let direnv source it for us.
Open your .envrc
Then in secrets.yml
aws_access_key = <%= ENV["AWS_ACCESS_KEY"] %>
aws_secret_key = <%= ENV["AWS_SECRET_KEY"] %>
And your aws.rb
I like this approach very much because I use a new built-in feature of Rails and make my development environment more like production, have ENV load without external gem.
The only limitation here is that you don’t have your ENV variable changed depend on
But you can define something like
DEVELOPEMENT_AWS_ACCESS_KEY to overcome it.
Rails 4.1 offers a lot of new features and enhancement that can help you develop your application faster, better and safer. If your project is still in development phase then upgrading is no brainer.
TL;DR Use direnv
Võ Anh Duy
You may also be interested in:
Love Silicon Straits and want to know more about our company culture, working environment or job vacancies?
Find out more at careers.siliconstraits.vn.
Be Challenged. Be Inspired. Be Different.