Google Tag Manager Research

Experimenting Rails Eager Loading

While building Rails app, what we frequently do is get a collections of objects from database and then iterate through each of them and get the associated objects and do some operations on these associated objects. For example, we have a PurchaseOrder and PurchaseOrderLineItem model, we might write some thing like

pos = Purchase.all
pos.each do |po|
  po.purchase_order_line_itesm.each do |li|
    # li.some_method
  end
end

How many queries does it issue in this code snippet. The number is 1+the number of purchase order that's returned from the first query. This is called N+1 query problem. Luckily, in Active Record, we have a solution to this problem, which will reduce the number of queries from 1+N to 2 in cases like that. What you need to do is to specify the associated objects using includes method, and it will make sure all the associated objects are loaded with the minimum possible number of queries. So the revised version of the code snippet above would be

pos = Purchase.includes(:purchase_order_line_items).all
pos.each do |po|
  po.purchase_order_line_itesm.each do |li|
    # li.some_method
  end
end

Now if we run this code snippet again, it will only issue two queries. The second query will use IN clause to get all the PurchaseOrderLineItem records whose purchase_order_id matches the ones of the returning Purchase Orders of the first query. This is how the name eager loading comes from, instead of loading a small amount of data using N queries, it loads all the data once using one query.

Why Strings Are Mutable in Ruby

Objects can be either mutable or immutable. Mutable objects are objects whose states can be changed, while immutable objects are objects whose states never change after creation. One important implication of immutable objects are any modification of existing objects results in new objects.

Immutable objects has many desirable properties.

• Immutable objects are thread-safe. Since any modification of existing objects results in creating new one, there is no need to set up lock to avoid conflicts while multiple threads attempt to access the object at the same time. 
• Immutable objects make good hash keys, because the value of the hash key should never change. 
• Immutable objects have higher memory efficiency, because the same object can be pointed to by multiple variables, thus enhancing reusability. 

Why Ruby does not adopt immutable string if it has so many advantages? The reason is it is intuitive to think of string as mutable, because you can do so many operations on a string, concatenation, appending etc. Ruby thus makes string mutable by default at the expense of performance. 

For example, appending on a string didn't creating new string.

> a = 'Hello'
=> "Hello" 
> a.object_id
=> 70161220331780 
> a << ' world!'
=> "Hello world!" 
> a.object_id
=> 70161220331780 # object_id does not change!

Don't confuse the code above with the following code

> a = 'Hello'
=> "Hello" 
> a.object_id
=> 70161220396780 
> a += ' world!'
=> "Hello world!" 
> a.object_id
=> 70161220412700 

As  "+=" creates a new string and then assign it to "a". The old string is not changed. You can make a string as immutable by using the method "freeze". After you freeze a string, an attempt to change it results in RuntimeError.

> a = 'Hello'
 => "Hello" 
> a.freeze
 => "Hello" 
> a << ' world!'
RuntimeError: can't modify frozen String

Why we need "freeze". What if we don't have it. Then we can't use string as hash key in Ruby. Because if you change the value of the string, you can't use the old value to refer to the right position in the hash. Here is how Ruby deal with it. It copies the string, freezes the copy and use the copy as the hash key.

Ruby: load vs require, include vs extend

When it comes to including files within another file, there are two methods we can use, load and require.

Here is a table that gives the differences

	load	require
file path	absolute/relative	absolute/relative
file extension	Required	Optional
Can load a file multiple times	Yes	No

The file path and file extension rows are pretty straightforward. The most important difference is the third row, Can load a file multiple times. You can load a file multiple times by using method load, but for require, you can't. That's because The absolute path of the loaded file is added to $LOADED_FEATURES. Every time a new file is going to be required, ruby checks if there is already a same absolute path in $LOADED_FEATURES, and if there is, the file won't be loaded again.

It's easy for beginner to confuse load/require with include/extend. To some extent, these two groups of methods are similar. However, they are used under different context. include and extend are used to adding methods from a module to classes. If you include a module within a  class, all the methods within that module will be added to the class as its instance methods. If you extend a module within a  class, all the methods within that module will be added to the class as its class methods.  See the example below,

module Mod_1
  def hello1
    puts "Hello from Mod_1.\n"
  end
end

module Mod_2
  def hello2
    puts "Hello from Mod_2.\n"
  end
end

class Klass
  include Mod_1
  extend Mod_2
  def hello3
    puts "Hello from Klass.\n"
  end
end

a = Klass.new
a.hello1      
Hello from Mod_1
=> nil 
Klass.hello2
Hello from Mod_2
=> nil
a.hello3
Hello from Klass
=> nil

Rails router, route, path, URL, resource routing

When it come to routing, there is a lot of confusing terms. In this blog, I'll try to shed some light on their meanings.

Router
Rails router is just a piece of code that handles HTTP verb and URL combos and dispatch them to a controller's action.

Route
Route is just the mapping from HTTP verb and URL combo to controller's action.
For example

get '/patients/:id', to: 'patients#show'

Path vs URL
Paths and URLs are easy to be confused.
Say we have a users controller, we can have a path and a URL for it, shown below.
Path => /users
URL => http://www.example.com/users

As we can see here, URLs are just paths prefixed with the current host, port and path prefix.

Resource Routing
In Rails, resource routing allows you to quickly declare all of the common routes for a given resourceful controller by using a single line. For example, you have a controller called photos.

resource :photos

By adding this line into our routes.rb file, we creates the following seven routes.

HTTP Verb	Path	Action	Used for
GET	/photos	index	display a list of all photos
GET	/photos/new	new	return an HTML form for creating a new photo
POST	/photos	create	create a new photo
GET	/photos/:id	show	display a specific photo
GET	/photos/:id/edit	edit	return an HTML form for editing a photo
PATCH/PUT	/photos/:id	update	update a specific photo
DELETE	/photos/:id	destroy	delete a specific photo

For example, if Rails application receives a incoming request for 

GET /photos/1

The router would dispatch that request to the show action in the photos controller with {id: '1'} in params.

Experimenting Rails Notification Module

Rails ActiveSupport::Notification module offers a mechanism to launch certain behavior when certain events occur. A common instance is to send an email to user after they finished signing up. Here we will do something much easier to show you how Notification module works. The basic idea is we'll simulate a man (which we will call it mess maker) pouring water into a pitcher. Each time he will pour certain amount of water into the pitcher, and when the pitcher can no longer hold any more water, a warning is fired telling him that the water is overflowing.

So first of all, we need to create a Pitcher class and a MessMaker class.

class Pitcher
  attr_accessor :content

  VOLUME = 100

  def initialize
   @content = 0
  end

  def check_overflow(name)
   ActiveSupport::Notifications.instrument("overflow", :name => name) if content > VOLUME  end
end

class MessMaker
  attr_accessor :name

  def pour_water(pitcher, amount)
   pitcher.content += amount
   pitcher.check_overflow(name)
  end

  ActiveSupport::Notifications.subscribe("overflow") do |name, start, finsih, id, payload|     puts 'Hey, ' + payload[:name].to_s + '. Stop pouring water!'
  end
end

As we can see, each Pitcher instance has a instance variable called content which is initialized to be 0 and recalculated as the mess maker pours more water into it. When the content reaches the VOLUME, an event called "overflow" is instrumented.  Right after "overflow" event is instrumented, the block in the Notification.subscribe gets executed, asking the mess maker to stop pouring more water. Note that subscribing code is not necessarily under the MessMaker class, you can put it wherever that makes sense as long as that chunk of code is loaded when you launch the application.

Now let's do some experiments in rails console

1.9.3-p392 :001 > mm = MessMaker.new
 => # 
1.9.3-p392 :002 > mm.name = 'david'
 => "david" 
1.9.3-p392 :003 > p = Pitcher.new
 => # 
1.9.3-p392 :004 > mm.pour_water(p, 30)
 => nil 
1.9.3-p392 :005 > p.content
 => 30 
1.9.3-p392 :006 > mm.pour_water(p, 30)
 => nil 
1.9.3-p392 :007 > p.content
 => 60 
1.9.3-p392 :008 > mm.pour_water(p, 30)
 => nil 
1.9.3-p392 :009 > mm.pour_water(p, 30)
Hey, david. Stop pouring water!
 => nil 

Rails Single Table Inheritance

Updated at Sep 21, 2014
Rails Version 4.1.1

Why single table inheritance?
In Rails,we usually have one database table for each of our model. That's very straightforward. But how do we deal with classes (or models) that inherit from other classes. Do we need to create database tables for each of them. The answer is it depends. If all the subclasses are very similar to each other or even identical (attribute wise), then creating individual tables for each of them might not be a good idea. Luckily, we have single table inheritance in Rails. Implied by its name, single table inheritance has only one table for the base class and all the subclasses. This table must meet the following requirement:

• Contains the attributes of all the classes involved in single table inheritance
• Contain a column called "type" to identify the class of each record in it
• Allow null for each of the attribute that do not appear in all classes

What's the benefit of it?
The benefit of single table inheritance is very obvious: you got only one table. You give up data purity to gain more performance. Model wise, however, you still get the flexibility: each class can have their unique behaviors (methods).

In the following I'm going to show you a simple example of how to use single table inheritance. Let's say we have a base class Student, which is the super class of the class TA (teaching assistant) and class RA (research assistant). First of all, we need to find out all the attributes these three classes have. The base class Student has student_id, firstname, lastname, department, major. TA has an extra attribute called course_number, indicating the course TA assists in teaching. RA has an extra attribute called topic, indicating the topic s/he is researching on. As we've mentioned, all the six attributes have to appear in the table student, as well as the type attribute.

Create the migrate for Student model

class CreateStudent < ActiveRecord::Migration
  def change
    create_table :students do |t|
      t.integer :student_id, :null => false
      t.string :firstname, :null => false
      t.string :lastname, :null => false
      t.integer :department_id, :null => false
      t.string :major, :null => false
      t.string :type, :null => false
      t.integer :course_number
      t.string :topic
    end
  end
end

Now let's create the hierarchy of our single table inheritance

student.rb

class Student
end

ta.rb

class Ta < Student
  def grade 
    puts 'I can grade'
  end
end

ra.rb

class Ra < Student
  def research 
    puts 'I can do research'
  end
end

Now let's launch the console and do some experiments.

david = Ra.create(:student_id => 1, :firstname=>'david', :lastname=>'zheng', :major=>'cs', :department_id=>1, :topic=> 'Database')
mike = Ta.create(:student_id => '002', :firstname=>'mike', :lastname=>'lu', :major=>'cs', :department_id=>1, :course_number =>'CS511')

All the records we created using subclass RA and TA will go into the table students.

david.research
I can do research
mike.grade
I can grade

Objects of subclasses can only call their own methods.

dave = Student.find_by_first_name('david')
dave.class.name
=> "RA"

The object uses the "type" column to determine which class it belongs to.