Often times you have an association that you want to be available as soon as you access it. That is, given a User model that has_one :location, you want to call user.location.country without worrying about whether user.location has been instantiated.

Isn’t it nice how Rails server automatically reloads your code before each request in the development? Wouldn’t it be nice if Rails console worked the same way? Sure, you can manually call reload!, but gems like active_reload - or Rails 3.2 itself - make reloading a near no-op most of the time, so we really don’t have to be so stingy about reloading.

Here’s how you can get IRB to reload your code automatically.

I was supposed to work on a side project with my wife this weekend. Much to her chagrin, I stumbled on an article about 4k demos which had some great 3d visualizations of fractals, and a new weekend project immediately pushed its way onto my spare-time stack. I’ve been looking for an excuse to try out WebGL with something more complex then a spinning cube example… and there went my weekend.

attr_accessible is the current Rails way to prevent mass-assignment injection, but it has some shortcomings. Here’s a different approach to mass-assignment protection that is the laser to attr_accessible’s shotgun.

The Tip

Do you have a collection of Records that can be displayed in multiple different views? If your application is anything more than minuscule, you probably do - and each of those views likely displays a distinct set of the Records’ associations. Rails provides the handy includes method for you to eager-load these associations, but in this case it would be wasteful to load the superset of associations for both views (scale this example up to a dozen views, and “wasteful” becomes “untenable”).