Working with Rails 4.1

Working with Rails 4.1

Rails 4.1 is finally released with a lot of excited features.
Two features that catch my attention are Spring preloader and secrets.yml. (You should check out release notes for more infomation )

Spring

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!

secrets.yml

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 Rails.application.secrets.

When creating a new project, you will see something like this in your config/secrets.yml

You can access your secret key by Rails.application.secrets.secret_key_base.

Problems

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.

Install direnv

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 $PATH.

At your application folder

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

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 RAILS_ENV.
But you can define something like DEVELOPEMENT_AWS_ACCESS_KEY to overcome it.

Conclusion

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

AnhDuy’s blog

SSS Full-stack Engineer

Love Silicon Straits and want to know more about our company culture, working environment or job vacancies?
Find out more at careers.siliconstraits.vn.

Silicon Straits
Be Challenged. Be Inspired. Be Different.




Posted by

on April 27, 2014

in ,

Comments

Follow us for more later

or subscribe with