In general, I don’t like using polymorphic associations, because of inability to have a database-level integrity control and trickier eager loading. However, sometimes they look like a natural choice for certain cases in Ruby on Rails applications.
Recently, I faced a problem, which turned out to be a bug in how Rails handles negations with polymorphic associations. It took me some time to figure out what exactly was wrong, so I decided to share my experience here for future reference (mostly for myself).

I always wanted ‘Go to declaration’ feature in Vim with fuzzy-search, like in many modern IDEs. Of course, Vim has a built-in support of tags jumping, but for some programming languages, like Ruby (when you may have dozens of classes named Base), locating and picking the right declaration may be painful. I didn’t find any existing solutions, so I wrote a small plugin for that.
Here is a demo showing how this plugin works for Ruby file, but it’s not limited to Ruby.

This short article is TL;DR of the talk: RSpec 3 and why I expect(you).to care by Jon Rowe. I picked 3 important recommendations out of this talk which I’m going to follow.
1. Use zero monkey patching mode This will completely disable all the monkey patching and will make RSpec less magical. Of course, it has a few consequences:
DSL will not be exposed globally, so RSpec.describe must be used instead of describe etc.

Ruby on Rails by default caches pre-compiled assets (sass, coffeescripts) to tmp/cache/assets directory in development and test environments. It makes page loading in development and running test faster (when assets are already precompiled), but may cause some weird bugs.
For example, when I was upgrading my Rails 3.2 application to Rails 4, I noticed that there are deprecation messages on CI server, but not on my local machine. I started investigating it and found, that these deprecation messages come from SASS file in one of my gems (it was twitter bootstrap 2.

TL;DR I’ve made RSpec test suite for my Ruby on Rails application 18% faster by following a Non-durable PostgreSQL configuration guide.
Intro When I’m developing (usually Ruby on Rails) applications using PostgreSQL database server for persistence, I don’t need high durability of my development database (or integration server). What I care the most is it’s speed. I realize, however, that database server, probably, is not the bottle neck of the typical application test suite.