Rails tips, part 2
I have finally found some time for another post. So here are some more Rails tips I wish I’d known earlier.
Tip #4: Silence Postgres Warnings
Are you annoyed by messages like these in your terminal when you run migrations?
Well these are notifications, not warnings, that inform us about the awesome stuff Postgres is doing for us. But what do they actually tell us?
Postgres has a numeric type called
serial, which is similar to MySQL’s
serial column stores 4-byte integers combined with a sequence to automatically provide auto-incrementing values.
That’s what the first message is about: Postgres is automatically creating a sequence to make the
id column function.
On to the second message. This is what the official documentation states:
PostgreSQL automatically creates an index for each unique constraint and primary key constraint to enforce uniqueness. Thus, it is not necessary to create an index explicitly for primary key columns.
Pretty clear. Postgres is creating indexes for such columns and informs us about that.
To the point: We can silence these notifications by adding this simple line under the environments we want, inside the
Fortunately, we won’t have to do this anymore in Rails 4!
Tip #5: Rails application templates
Many times I catch myself going through the same setup steps when starting new Rails apps: writing the same Gemfiles, same Rspec configs, .gitignores, rake tasks, YMLs etc.
Wouldn’t it be nice if we could save time by avoiding such repetitive tasks?
Fortunately, Rails application templates lets us do just that: create templates that we can use to create new apps. There’s a relatively unknown DSL that we can use to build our own templates.
Here’s one of mine for example:
Pretty self-explanatory, isn’t it? The way you use it is with the relevant generator:
Actually I have created a repo with some templates useful for me. If you find yourself in the same position I suggest you do the same.
Head to the official documentation for more info.
Tip #6: Quick Benchmarking with Benchmark.ms
Turns out there is a convenient way to measure the performance of bits of code straight in the Rails console.
Fire up your rails console and try it:
You get the response time in milliseconds. This comes from
ActiveSupport::Benchmarkable along with some other benchmarking tools. Neat.
Well, that’s all.
PS. In case you missed it, here is the first part of this post.