Linked contentRepeats

Add indexes on foreign keys when you create a migration (with foreign key)

Whenever you make a migration to add a foreign key, you should also add an index for it

  def self.up
    add_column :comments, :user_id, :integer
    add_index :comments, :user_id

Database: Scopes, migrations, and indices

Wether you modify an existing named scope or add a new one, or when you write a new query, make sure you have the proper indices.

This particularly applies if you're going to run non-trivial queries of course (admin backends, analytics, etc).

Compound indices

A chain of scopes results in (usually) one query. You should take into account all attributes (columns) that are used in :conditions, :join, :group, :having, and :order, as all those result in filtering and sorting–slow operations without indices.

Take the list of all ...


Rebase your feature branches

Regularly, but at least before merging your feature branches, rebase them to get rid of "fix typo" and "wip" commits.

Getting rid of unnecessary commits

Let's say you do a git rebase -i HEAD~~~~ and have this commit history:

pick 1d1e1f My Feature
pick 2d2e2f My Feature - wip
pick 3d3e3f My Feature - fix typo
pick 4d4e4f My Other feature

Change it to use fixup for those commits that should be merged into the one before ...


When you set date attributes, you should not pass times

As you know, time zones make stuff a bit more difficult but are necessary.

A time-zoned record is converted to UTC using to_s(:db) to be stored, and put back into the correct time zone when loaded. So when you are not on UTC, the following will happen:

>> Time.current
=> Fri, 15 Mar 2013 11:56:03 CET +01:00
>> Time.current.to_s(:db)
=> "2013-03-15 10:56:03" # This is now UTC

That will blow up in your face when you sen...

DateTimes are Dates, beware


datetime =
date = datetime.to_date #or

will assert:

datetime.is_a? Date == true
datetime.is_a? DateTime == true
datetime.instance_of? Date == false
datetime.instance_of? DateTime == true

In case you have a table and a model like:

create_table :event do |t|    :day
  t.string  :description
class Event < ActiveRecord::Base; end

And you say:

event = => '2013-03-22')

Rails will convert the supplied value for day to the type of the database field,...

Profiling Ruby with ruby-prof

require 'ruby-prof' # you don't need this if you have ruby-prof in your Gemfile

You can set one of the things you want to measure by using (default is PROCESS_TIME most useful ones are PROCESS_TIME, MEMORY, CPU_TIME):
RubyProf.measure_mode = RubyProf::PROCESS_TIME
RubyProf.measure_mode = RubyProf::WALL_TIME
RubyProf.measure_mode = RubyProf::CPU_TIME
RubyProf.measure_mode = RubyProf::ALLOCATIONS
RubyProf.measure_mode = RubyProf::MEMORY
RubyProf.measure_mode = RubyProf::GC_RUNS
RubyProf.measure_mode = ...

has_defaults issues

The object returned by has_defaults apparently is the same between multiple object creations.
Consider this scenario:

class Order
  has_defaults :items => []

o1 =
o1.items #=>> []
o1.items << item
o1.items #=>> [item]

o2 =
o2.items #=>> [item]

So, now o2.items is not empty by default because we modified the same object in has_defaults

When using has_defaults on a model, consider using it in the following way:

has_defaults :items => proc {[] }

Consider do...

Cleaner Rspec

When simply checking equality or truthiness then
Instead of:
it "should have role set to admin" do
@user.role.should eql('admin')

it "should be valid" do
  @user.valid?.should be_true

it { @user.role.should eql('admin') }
it { @user.valid?.should be_true}

Try to stick to one expectation per test block, diverge in exceptional circumstrances, so instead of:
describe "#some_method" do
before(:each) do
@object =

   it "should have attributes set" do


Method return value should always be of same type

One of the main source of bugs and complexity in the code is when a functional method (that we expect to return a value) return different values under different circumstances.

For example, we ruby programmers have a bad habit of returning nil from a method when certain condition is not fulfilled else return an Array or Hash. That just makes the calling code unnecessary complex and error prone because then it has to do different checks.

Bad Practice:

def bad_method(param)
  return unless param == 'something'


Linked content

Creating a gem in lib folder

Go to lib folder and use bundler to generate main files for a gem:

$ bundle gem test_gem

      create  test_gem/Gemfile
      create  test_gem/Rakefile
      create  test_gem/LICENSE
      create  test_gem/
      create  test_gem/.gitignore
      create  test_gem/test_gem.gemspec
      create  test_gem/lib/test_gem.rb
      create  test_gem/lib/test_gem/version.rb
Initializating git repo in /path/to/webapp/HouseTrip-Web-App/lib/test_gem

cd in to created directory

$ cd test_gem/


ActiveRecord::NamedScopes (2.3.x) obtaining the SQL conditions

It's a good pratice to chain several named scopes like:


Now, to make the lesson more valuable let's assume the following code:

Property.scoped(:conditions => "foo = 2").scoped(:conditions => "foo2 IS NOT NULL")

Next, if you want to be able to fetch the underlying conditions scope generated by ActiveRecord. You must do this:

Property.scoped(:conditions => "foo = 2").scoped(:conditions => "foo2 IS NOT NULL").scope(:find)
# => {:conditions => "(foo = 2) AND (foo2...
This website uses short-lived cookies to improve usability.
Accept or learn more