Tag: rails

Rails Quick Tip: Set a secret token for Heroku deploy

Rails apps use a secret token to keep user information save, so the more entropy the better. This means using the same secret token on heroku and locally is not ideal, and quite easy to fix.

First make the secret_token.rb set the token from an ENV variable

MyApp::Application.config.secret_key_base = ENV['SECRET_KEY_BASE'] || "sometoken"

And now create the token in the heroku config

heroku config:set SECRET_KEY_BASE=`rake secret`

That’s it, enjoy!

Make sure your rails migrations work, thank you.

Rails migrations are the ugly stepchild of most projects, even though
actually making them work correctly saves so much time. Even though they seem
like one-off scripts, and also are most of the time when you do need to run them
more than once you are already in a bad place, so be sure that the migration you
wrote, when there was time is not making it worse.

At least doing a quick testing of the rollback is worth your time, in all cases!
So just run

$ rake db:migrate && rake db:rollback && rake db:migrate

When creating a new migration, thank you, you are awesome :).

Testing rake tasks

Relying on rake task to do some repetitive work is a really common way in most
rails apps. Testing those tasks seems to not be as common so.

Why?

Personally I think this is mainly due to just not being present in the default
tests stack, so as a developer I assume they are not worth testing because nobody
else is. But actually I think a task which is essential to your application
should be tested never the less, so to ease my journey towards better test
coverage for rake tasks in my own apps I decided to create a little helper to
setup just the basic environment and about as important, be there as a reminder
that I should test those tasks.

Personally I come to like minitest to test rails apps, so the
gist is based on
minitest, but can easily be adapted for any other framework. Looking through the
code you’ll find some conventions I personally like to be enforced in my rake
tasks

  • namespace the task under the app name if it directly interacts with the app
  • put the tasks in sub directories under lib/tasks so it does not become a
    junk drawer of code
  • put each task in its own file
  • name the file after the task (common sense I guess but not always true)

so here we go, enjoy!

https://gist.github.com/sideshowcoder/5891019.js

ActiveRecordTranslatable is moving towards stable

When I extracted
ActiveRecordTranslatable
from an active project is was a pretty quick thing, but since then I found, since
it is just so barebones easy, that uses pop up outside of the initial
project.

Currently I am in the process of moving it towards a more stable release,
just a couple more things are left to do, but for now at version 0.0.9 is here
with a slimmed down interface and better docs. Find and read the
docs here

Rails quick tip: generate and destroy

Rails generators are often known to be a one way street. Often people new to
rails think if they generate the wrong thing they are stuck. Not true! So here
we go, happens to me all the time:

$ rails g controller ReportsController index
...
app/controllers/reports_controller_controller.rb
...

Oh right generate just takes the name without the extension. No need to hunt
down the generated files:

$ rails d controller ReportsController index
...
$ rails g controller Reports index
...
app/controllers/reports_controller.rb
...

Just run d for destroy and generate again. Just thought to point this out!

Rails snippet: Setting up TravisCI

Travis CI is great way to get continuous integration into a project.
So just to get started here is a quick walkthrough, through the setup for a
project of mine. Basically it’s a 3 step process:

Setup rake to run the tests

This is easy, and probably already happens anyway! Just to check

$ rake

Setup .travis.yml

My own .travis.yml for
ActiverecordTranslatable looks like this:

http://gist-it.appspot.com/github/sideshowcoder/activerecord_translatable/blob/master/.travis.yml
So line by line

http://gist-it.appspot.com/github/sideshowcoder/activerecord_translatable/blob/master/.travis.yml?slice=0:2
Set the ruby version to 1.9.3

http://gist-it.appspot.com/github/sideshowcoder/activerecord_translatable/blob/master/.travis.yml?slice=3:5
Setup the database for the tests

Setup a github hook to notify travis about commits

Now to complete the setup setup the hook for travis under the Settings → Service Hooks on Github.

So now quick, learn more checkout TravisCI docs it’s
awesome.

Enjoy

Rails snippet: Rendering a view from model!

Sometimes it comes in handy to render a template from another place than a
controller in Rails. For example using
WickedPdf to generated some pdfs
inside a model comes in quite handy. Normally you need to setup a lot of stuff
for WickedPdf but since everything is already done when calling the build in
render, we can just reuse this.

https://gist.github.com/sideshowcoder/5009089.js

So to call render from somewhere besides a controller, well we need a
controller and we can just call render from there, what pops out is the
actually rendered template as a string (that’s why we call render_to_string of
course), which we can now ship of to wherever we need it.

Enjoy

UPDATE: As Fladam Orin points out in the comments this falls flat if you use helpers like url_for since the controller lacks a request object. This is a problem which can be solved by using an ActionView and loading the helpers.

Rails snippet: running a single test for rails

Getting started to debug a problem within the rails lib itself it is nice to be
able to just run a single test. Doing this is pretty straight forward, still it
took me some minutes to get the command right since I found a lot of non working
ways online first. So here it is (as an example I run the test_label test in
actionpack):

$ cd actionpack
$ bundle exec ruby -I"lib:test"  
test/template/form_helper_test.rb -n test_label

Enjoy

Look at this post as
well for further details about test running in rails.