On the chopping Bloc

Setting up MixPanel in Rails

Mixpanel is simply awesome. It’s simple to set up and has a great interface to track user generated events in real-time. Here’s how I set it up in my Rails app.

Gem or no gem?

As usually is the case, there is at least one Mixpanel gem out there. I opted NOT to use the gem because Mixpanel is constantly releasing new features (such as the People module) and the gem author doesn’t seem to update it frequently enough. Plus, the Mixpanel is pretty simple to set up anyway.

Rails.env?

First step is create TWO projects on Mixpanel: one for the development environment and for to track actual users (production). This is important in order to keep the real users events clean, but also have an environment where you can mess around in development.

Installation

Back on the Rails app, I created a view partial on ‘shared/_mixpanel’, where I inserted the standard JS snippet you can find one the Mixpanel instructions page. If you take look at that code, you will see the last line is where you should insert the project’s token. Instead, I added a variable:

  mixpanel.init(‘<%= MIXPANEL_TOKEN %>’);

Then I wrapped the whole script around an if-statement that only runs if we are in development or production:

<% if Rails.env.staging? || Rails.env.production? %>
  (…script…)
<% end %>

I put the actual tokens on their respective config/environment files (development.rb and production.rb):

  MIXPANEL_TOKEN = “1234somerandomnumber1234”.freeze

Mixpanel should be ready to receive the events. Now all I had to do is include them in a JS asset file. For example:

jQuery ->
  mixpanel.track_links(‘li #happy_button’, ‘Happy button clicked’)

After clicking the button a few times, the events show up on the Mixpanel dashboard almost instantly.

Most of these suggestions were taken from this Thoughtbot post, so you might want to check it out as well.

Going deeper - Part III

We successfully created the self-referential association for companies, going through two different models (see Part I and Part II.) However, we still need a way to access a company’s buyers directly from that object, so we need to do a few tweaks.

The simplest way to tackle this problem is to create a method within Company that collects all the buyers from Dealing:

def buyers
  self.dealings.collect { |a| a.buyer }
end  

This approach has a few drawbacks. First, it may present performance issues since it makes one query for each buyer. Second, it is not very flexible, since you can only call a_company.buyers, but not a_company.investors or a_deal.buyers. You could create new methods for the different roles and copy them into all the models, but that doesn’t seem very DRY.

Another approach would be to create new associations for each type of buyer.  So, in Dealing, we would add:

class Dealing < ActiveRecord::Base
  belongs_to :deal
  belongs_to :buyer, :polymorphic => true
  belongs_to :investor, :class_name => 'Investor',
     :foreign_key => 'buyer_id'
  belongs_to :corporate, :class_name => 'Company',
     :foreign_key => 'buyer_id'
end

Note that I called the Company type “corporate”, to avoid conflict with the name “company” which we already use in the opposite direction (a_buyer.companies). How do we further propagate these associations to Deal and finally Company?

The Kick

In the movie Inception, waking someone from a dream involved a “kick”, which could be the sensation of falling into water or a sudden jolt that would startle the sleeper. However, if the person was in a dream within a dream, synchronized kicks at all levels were necessary to jolt the sleeper all the way back into the real world.

Likewise, the changes we made to the app only allow Dealing to access its “investor” or “corporate”. We need to “kick” these relationships further up into the other models.

The next level up is Deal, where we add a has_many through for each buyer type:

class Deal < ActiveRecord::Base
  belongs_to :company
  has_many :offerings, :class_name => 'Dealing',
     :foreign_key => 'deal_id'
  has_many :investors, :through => :offerings,
     :source => :buyer, :source_type => 'Investor'
  has_many :corporates, :through => :offering,
     :source => :buyer, :source_type => 'Company'
end

Note that we need to include the source and source_type options to indicate the source association name and type, since Rails cannot infer them automatically. 

The last level is Company itself, where we again add a has_many through for each type:

class Company < ActiveRecord::Base
  has_many :offers, :class_name => "Deal",
     :foreign_key => 'company_id'
  has_many :offerings, :through => :offers
  has_many :investors, :through => :offerings,
      :source => :investor,
      :conditions => "dealings.buyer_type = 'Investor'"
   has_many :corporates, :through => :offerings,
      :source => :corporate,
      :conditions => "dealings.buyer_type = 'Company'"

  has_many :dealings, :as => :buyer
  has_many :deals, :through => :dealings
  has_many :companies, :through => :deals
end

At two levels deep, it gets a bit tricker because there are two inner joins in the query. Therefore, simply passing “:source_type => ‘Company’” doesn’t work. We need to specify that it is a “dealings.buyer_type” via the condition option.

That should do the trick! We can finally use “a_target.investors” or “a_target.corporates” to return the company’s buyers. We can also access them through any of the intermediary models, such as “a_deal.investors”.

One more thing…

To close it all, we can now refactor our previous buyers method to simply:

def buyers
  self.investors + self.corporates
end

> a_target_company.buyers
# return arrays of investors 

Success at last!

Hoped you enjoyed this post. If you have any other interesting approaches, feel free to share.
 

THE END
(or is it?)

Going deeper - Part II

In the previous post, we created a polymorphic association between deals and buyers. Because of the polymorphism, buyers can now be either Investors or Corporates (the proxy model we created to represent companies when they are acting as buyers.)

But how do we get rid of the Corporate model and allow a Company invest into other Companies? How do we design a model that references itself?
 

Drawing hands

The trick to resolving self-reference is to give different names to each role that the model can assume. On Escher’s drawing above, you could call one arm a Hand, when it is out of the paper holding the pen and making a drawing. But you could also name it Sleeve, when it is being drawn on the paper. Therefore, a Hand can draw a Sleeve, even though it is technically the same object.

In Rails, you can do the same by creating two associations with different names and passing the class name and foreign key. Here is the example from the Rails Guides:

class Employee < ActiveRecord::Base
  has_many :subordinates, :class_name => "Employee",
     :foreign_key => "manager_id"
  belongs_to :manager, :class_name => "Employee"
end 

An Employee can be a manager, who has many subordinates, or (s)he can be a subordinate, who belongs to a manager. Although they carry different names, the underlying model is still “Employee” as determined by the :class_name option. Note that the has_many association also passes the name of the foreign key to look for in “Subordinate”. The Employee schema must have an integer column named ‘manager_id’ in order for the self-joining association to work.

In the Dealbook app, we can apply the same concept. First, let’s add both roles to the Company model by simply copy/pasting from our Corporate model:

class Company < ActiveRecord::Base
  has_many :deals
  has_many :dealings, :through =>= :deals

  has_many :dealings, :as => :buyer
  has_many :deals, :through => :dealings
  has_many :companies, :through => :deals
end

Now we simply have to change the names in the roles, to set them apart.

A dream within a dream

But wait! We are still two models deep!

In the case where a company invests in another company, it is not doing so directly (like in the Employee example). Rather, the Company (buyer) will have a Dealing, which belongs to a Deal, which belongs to another Company (target). Therefore, we need to create different names for all of the links until we reach the target company. 

Here’s one way to rename the associations from the target Company’s perspective:

Deal => Offer
Dealing => Offering
Company => Buyer 

Therefore, a buyer still has many dealings, each belonging to a deal, which belongs to a company. But now, a company has many offers, each having many offerings, each having many buyers.

class Company < ActiveRecord::Base
  has_many :offers, :class_name => "Deal",
     :foreign_key => 'company_id'
  has_many :offerings, :through => :offers

  has_many :dealings, :as => :buyer
  has_many :deals, :through => :dealings
  has_many :companies, :through => :deals
end

class Deal < ActiveRecord::Base
  belongs_to :company
  has_many :offerings, :class_name => "Dealing",
     :foreign_key => 'deal_id'
end

This successfully implements the self-referencial associations on Company! Just like we did with investors, we can now access the companies invested by another company with:

> a_buyer.class == Company
> a_buyer.companies
# returns arrays of companies invested by a_buyer

But, as with investors, the unidirectional natural of polymorphic association prevents us from accessing a given company’s investors:

> a_company.buyers
> a_company.investors
# both throw NoMethodError

As mentioned in the previous post, there a few solutions for this which we will see in the third and last part. Stay tuned!

Going deeper - Part I

It’s funny how seemingly simple features can trigger huge changes to an app’s data structure.

Case in point: my Dealbook app currently has three main models to store information on deals - Company, Investor and Deal. The Investor model represents the entity making the investment (buyer). The Company model represents the entity receiving the investment (seller). Deal is a through model linking Companies and Investors, but also containing deal information, such as close date.

The associations look like this:

class Company < ActiveRecord::Base
   has_many :deals
   has_many :investors, :through => :deals
end

class Investor < ActiveRecord::Base
   has_many_and_belongs_to_many :deals
   has_many :companies, :through => :deals
end

class Deal < ActiveRecord::Base
   belongs_to :company
   has_many_and_belongs_to_many :investors
end

Notice that a given Deal only belongs to one company, but has many investors. That makes sense, because a typical deal usually involves several investors putting money into a single company.

So far, so good. My app was running happily with these model associations, until I ran into the following scenario: what if one of the investors is actually another company?

With the current models, I would have to keep two separate records for the same company (both as Company and as Investor). This is obviously a bad idea, since the company’s data would be scattered around. Ideally, the Company object should be able to store investments into other companies directly.

It seems inevitable that we will need companies to reference themselves. Since dealing with self-references can be mind-numbing, I will skip it for now and address other issues first. To avoid the self-reference, I will use a workaround by temporarily creating a Corporate model to represent a company when it is the buyer. The current Company model will represent only the target company for now. Later, we will try to merge these two models into one.
 

Polymorphism

The first step to solving the puzzle is finding a way to allow Deal buyers to be both Investors or Corporates. This most likely involves creating a polymorphic association between deals and buyers:

class Company < ActiveRecord::Base
  has_many :deals
end

class Deal < ActiveRecord::Base
  belongs_to :company
  belongs_to :buyer, :polymorphic => true
end

class Investor < ActiveRecord::Base
  has_many :deals, :as => :buyer
  has_many :companies, :through => :deals
end

class Corporate < ActiveRecord::Base
  has_many :deals, :as => :buyer
  has_many :companies, :through => :deals
end

There is one problem here, however. (Can you spot it?) The current association between Deals and Investors is not has_many, but rather has_and_belongs_to_many (HABTM), which does not accept polymorphism. Changing it to a simple has_many relationship is not an option, since an investor can have many deals and a deal can have many investors.
 

Two levels deep

One solution would be to change the HABTM association into a has_many through, which does allow polymorphism. Since we already have a ‘has_many through deals’ association, we would now have two intermediary models between target companies (Company) and their buyers (Investors or Corporates). Fortunately, multi-level through associations are supported as of Rails 3.1.

Here, I included a new through model called Dealing:

class Company < ActiveRecord::Base
  has_many :deals
  has_many :participations, :through => :deals
end

class Deal < ActiveRecord::Base
  belongs_to :company
  has_many :dealings
end

class Dealing < ActiveRecord::Base
  belongs_to :deal
  belongs_to :buyer, :polymorphic => true
end

class Investor < ActiveRecord::Base
  has_many :dealings, :as => :buyer
  has_many :deals, :through => :dealings
  has_many :companies, :through => :deals
end

class Corporate < ActiveRecord::Base
  has_many :dealings, :as => :buyer
  has_many :deals, :through => :dealings
  has_many :companies, :through => :deals
end 

This works! Now we can access companies directly from an investor by simply using:

> an_investor.companies
# returns array of companies invested by an_investor 

The only catch is that polymorphic through associations only go in one direction, so trying the opposite call does not work:

> a_company.buyers
> a_company.investors
> a_company.corporates
# all of the above throw NoMethodError

There are a few ways around this, which I will cover later. (If you’re curious, check out this post.)

So now that we can accept both types of buyers in Deals, it’s time to eliminate the Corporate model and create a self-referencial Company.

 
TO BE CONTINUED…

Multiple select boxes with Chosen jQuery

After long hours of sweat and frustration, I finally got the multiple select box to work with the Chosen plugin. It seems other people are having some trouble as well, so I will lay out the steps I followed:

Get the form working

First, I recommend getting the multiple select box to work without Chosen first. It should be fully functional, but without the cool JS effect that Chosen will provide. For reference, it should look like this (second row, left side).

In my app I have two models, Company and Market, which are related to one another through a has_and_belongs_to_many association. In the new Company form, I want to be able to pick one or more markets for a given company. (I will assume here that all the models, migrations and join table have been properly set up.)

If you are using a gem like ‘simple_form’, creating the form should be a piece of cake. With ‘simple_form’, all it takes is one line inside your company form:

<%= f.association :markets %> 

Just pass in the model name (plural if has_many). The gem will locate the HABTM association and create a multiple select form.

If you are not using a gem, it’s a bit tricker, but should work as well:

<div class=”field”>
  <%= f.label :market_ids, ‘Markets’ %><br />
  <%= f.collection_select :market_ids, Market.order(:name), :id, :name, {}, {multiple: true} %>
</div> 

Notice the ‘multiple: true’ option that needs to be included to make the select box accept multiple items.

Whether you used a gem or not, the form should now be working. Make sure you test it by creating a few new records before moving to the next step.

Add Chosen

For simple integration, I used the ‘chosen-rails’ gem. After you add it to your Gemfile and run bundle, you need to add a few lines of code.

In ‘app/assets/javascripts/application.js’, add:

//= require chosen-jquery

In ‘app/assets/stylesheets/application.css’, add:

*= require chosen

Once the gem is installed, we need to add the JS (or rather CoffeeScript) code. Inside the ‘app/assets/javascripts’ folder, I created a ‘companies.js.coffee’ file with:

jQuery ->
  $(‘#company_market_ids’).chosen()

Notice that the selector must have this name, since it is the default id created by the form. It includes the name of the current model (company) and the object ids of the select box options (market_ids). If you want to use a different selector, you will need to change the default name that is generated by the form.

Bingo! The select box should be working properly with the Chosen plugin magic, just like this (second row, right side).

(If you get a “couldn’t find file ‘chosen’” error message, try restarting the rails server.)

Extra configs

There are few handy configurations you can do. 

If you want to change the default style, simple add a ‘app/assets/stylesheets/companies.css.scss’ file and use the same CSS id selector. For example, we can increase the field width with:

#company_market_ids { width: 400px; }

If you wish to change the placeholder (text inside the select box), you can include this option in your field generator (form view file):

<%= f.association :markets, :input_html => {:class => “chzn-select”, ”data-placeholder” => “Select one or more markets”} %> 

For more options, check out the Chosen and simple_form websites.

I hope this was helpful. If there are other interesting ways to use Chosen, feel free to add comments.

Managing project with Trello

Trello is an awesome project management board developed by Joel Spolsky, of Stack Overflow fame. I have been using it to keep track of all the project features and I highly recommmend it.

I’ve made my project board public, so I invite everyone to take a look at it. Feel free to post comments or upvote features directly on Trello:

Luciano’s Dealbook Trello Board

BONUS: the Trello team has made Trello’s own project board public as well, so you can actually use Trello to monitor and influence Trello’s development.

Trello Trello Board

Ruby symbols

One of the first things you notice when you glance at Ruby code are those curious words prefixed with colons. In fact, these interesting constructs are very peculiar to Ruby and are called symbols.

But what are Ruby symbols? They are simply a name or identifier for other objects. They are not strings or numbers, but rather an efficient way to represent them.

One important characteristic of symbols is they are immutable and, therefore, you can’t assign it a value. You will never see the following code:

> :some_symbol = “some string”

The other important feature is that, unlike Strings, Symbols that have the same name are actually the same object. For example:

> “some_string”.object_id == “some_string”.object_id
=> false

> :some_symbol.object_id == :some_symbol.object_id
=> true

As we can see, Ruby creates two different String objects, even though the contents are the same. In the Symbol case, there is only a single object.

Why are symbols so useful? Aside from making writing code easier, symbols are very memory efficient. Because of their immutability, they are perfect to represent an object you will use many times.

A common example is hash keys. You could simply use strings for hash keys but, as we saw above, this would create a new object for every record even if the keys have the same name. Given enough records, you would eventually run out of memory. Using a symbol for the key, we avoid this problem since all of the like keys would point to the same object.

A similar situation occurs in Rails, where we use hundreds of links and methods over and over. Rails makes good use of symbols by choosing them not only for hash keys, but also to represent different objects like method and attribute names.

If you create a custom validation method, you would pass its symbol representation:

validate :some_custom_validation, :on => :create

Note that the option also uses symbols to represent both the option key and the create controller method.

In summary, symbols are a simple but powerful construct that allows Ruby and Rails to run faster and more efficiently.

Proc vs lambda

Lambdas and Procs are a fun and powerful part of Ruby. In essence, they are just a chunk of code that can be stored in a variable  and called later. For example:

> double = lambda { |n| n*2 } 

The code inside the brackets will take whatever number is passed to it and multiply it by two. However, the code is not executed during the assigment. It is simply stored in a the variable double to be executed later.

To do that, we simply call the object:

> double.call 2
=> 4 

Here we are calling the “chunk of code” called double and passing it the number 2. It will take this number and execute the code (double it).

A Proc object works the same way:

> triple = Proc.new { |n| n*3 }
> triple.call 3
=> 9

In fact, lambdais just a Kernel method that creates a Proc object!

> what_is_lambda = lambda { |n| puts “Surprise” }
> what_is_lambda.class
=> Proc 

Diff

There are, however, slight differences between using lambda and Proc.new. First, lambda checks the number of arguments that are passed to it, while Proc doesn’t. Let’s see an example:

> some_lambda = lambda { |x, y| puts “#{x} and #{y}” }
> some_proc = Proc.new  { |x, y| puts “#{x} and #{y}” }

Both contain the same code, however if we pass only one argument:

some_lambda.call(“cats”)
ArgumentError: wrong number of arguments (1 for 2)

some_proc.call(“cats”)
=>  ”cats and”

Proc executes normally, ignoring the missing argument, while lambda throws an Error.

The second main difference between the two is how they deal with return statements. If a return statement is included in a Proc, it will be treated like a method return statement:

def some_method
  some_proc = Proc.new { return “Method ends here.” }
  some_proc.call
  return “This never happens.”
end

> some_method
=> “Method ends here.” 

However, when we use lambda, it simply exits from itself and the method continues executing:

def some_method
  some_lambda= lambda { return “Simply exits lambda.” }
  some_lambda.call
  return “This is returned.”
end

> some_method
=> “This is returned”.

Blocks

So, how are blocks related to Procs? A block is simply a Proc that hasn’t been created yet. It is an anonymous “chunk of code” that needs to be bound to a method and converted into a Proc before being used. 

For example:

> { |n| puts “Hello” }

This throws an Error. On its own, the block does nothing. It needs to passed to a method first:

> 10.times { |n| puts “Hello” }

Under the hood, times will convert the block into a Proc and execute it when called within the method. Here is an interesting example to illustrate this:

def what_is_block(&block)
  puts block.class
end 

> what_is_block { |n| puts “Surprise” }
=> Proc 

Once the block is passed into a method, it becomes a Proc!

Length vs. presence validations

Today I learned (the hard way) that ActiveRecord length validations when a range is used  implicitly validates presence as well. I previously assumed that length would only be validated if the attribute was present, and that presence needed to be validated separately using :presence => true. But that is not the case.

For example, this code would not validate if name is nil.

validates :name, :length => { :in => 2..100 }

To obtain a validation that checks length only if the attribute is present, I had to include the :allow_nil option:

 validates :name, :length => { :in => 2..100, :allow_nil => true }

EDIT: Proof

Test-driven development

I always liked the TDD process. Write the tests first, write the minimum code to make the tests pass and then refactor. As a beginner, it helps me in a few ways:

1. As I write the tests, I am forced to think about the exact results I want to acheive;
2. By checking the error messages for failing tests, I know what to do next;
3. Having a good test coverage gives me some comfort that the wheels are not going to fall off the app.

This may be an overkill for more experienced developers, but it certainly helps me. For Dealbook, I’ll write all model and integration tests using Rspec + Capybara. For factories, I’m using Machinist + Faker. (FactoryGirl is more popular, but Machinist seems to better handle has_and_belongs_to_many associations.)