stuff.select(&:cool?).flatten

Isn't it annoying when your editor (or your co-worker's) adds or removes whitespace, making a line seem changed when it really isn't?

Long story short:

git diff -w | git apply --cached --ignore-whitespace

This is one of the best explanations I've found of the differences between Ruby's procs and lambdas, and while I've always favored lambdas because they're stricter, the nice new thing I've just found about procs is that they lend themselves to this syntactic sugar:

Status codes are often overlooked when developing Rails applications, but in order to nicely interact with a non-human user-agent, you should really respond with the appropriate HTTP status code when a POST just failed and you're showing the form again.

Metaprogramming is fun and profitable, but as always you have to know the tools of the trade. Many times I've found myself playing with stuff like controller_name.singularize.classify.constantize which is cool when you're following the rules strictly, but breaks horribly if you don't

This tip is no silver bullet against horrible metaprogramming breakages, but it's worth knowing: every ActiveRecord subclass has a method called model_name which gives you a lot of information about its nomenclature at the controller level.

Try for example

User.model_name.param_key User.model_name.route_key User.model_name.collection

Who are you gonna call?

Every once in a while we stumble in some little known feature of our favorite programming language. Recently I found out about Array#sample: without arguments it picks a random element, with an integer as argument it picks that number of distinct random elements.

(1..6).to_a.sample # => a random number between 1 and 6 (1..6).to_a.sample(6) # => all numbers between 1 and 6, in random order

Isn't that brilliant? ;-)

As a bonus, it's also nice to know about Array#to_set (available once you require 'set'). Often times an array is queried for inclusion of an element with Array#include?, but if you have to do it repeatedly, Set#include? is much faster. There's some overhead in converting the Array to a Set, though, so it's useless (actually slower) for a single check.

require 'benchmark' require 'set' big_num = 1_000_000 big_array = (1..big_num).to_a big_set = big_array.to_set puts Benchmark.measure { 100.times { big_array.include?(big_num) } } puts Benchmark.measure { 100.times { big_set.include?(big_num) } }

will output

Sometimes, especially when working on the console, you just want a quick and dirty way to instantiate an object from a hash without having to go through all the (justified!) paranoia of mass-assignment protection. In a nutshell, here's how:

Ever had to work with your application's schema and a legacy schema simultaneously? Rails has you covered: not only can you have per-class database connections, but it's actually easy to do. All you have to do is to declare an additional section in your config/database.yml like this:

development: adapter: sqlite3 database: db/development.sqlite3 legacy: adapter: 'mysql2' database: 'legacy' username: 'legacy_user' password: 'super_secret_password'

and then you'll be able to use the database connection in any model by declaring which connection to use:

class LegacyUser < ActiveRecord::Base establish_connection :legacy end

Of course to make things DRYer you can also declare an abstract class, say LegacyModel, put the connection declaration there, and make all the other legacy classes inherit from there.

Pretty neat, but what if the two schemas are identical and you want to access both with a minumum of fuss? Lets's say you want to programmatically transfer a sample of data from production to testing with the console (be careful!) or you want to mess around in the testing database without risking to break development. Looks like a nice job for metaprogramming, doesn't it? So here we go:

module Legacy def self.const_missing(name) if Object.const_defined?(name) klass = Class.new("::#{name}".constantize) klass.establish_connection :legacy return klass end super end end

This nice snippet of code (which we'll save in app/models/legacy.rb to help the autoloader do its job) is really all it takes to duplicate all models (actually, any class) in the Legacy:: namespace and to change the database connection to the one defined in the configuration file. This way, User will point to the current environment's users database table, but with the appropriate changes, Production::User could point to the users on the production server.