Skip navigation

Tag Archives: ruby

Vinkesh and I made a presentation at xonf Bangalore on building jabber chat bots in cases where web application seem like a redundant solution. Read More »

I am currently working on a project in ThoughtWorks that required a lot of operations work to be done. Translating that to English, we wrote a lot of code that needed to be shared by an online application and a set of background jobs. Not to mentions that a large part of these operations were speaking to REST APIs. Not rocket science right? So  Here is what we did. Read More »

Part1 continued…..
Read More »

Recently, I decided to take quick read of the Russ Olsen’s Design Patterns in Ruby just in case the book had interesting ways of solving common problems. The book tends to digress into type safety (the lack of it) and other gizmoz that Rubyists defend and evangelize. Hence, I decided to write this article that will simply show you the code for the most important patterns. I have just covered the most elegant way these can be used. For what its worth, this is really the only reason you would want to read this book.

Having said that, I assume that you can take a judgement on when these patterns are to be used. That will truly determine whether/if it solves a problem for you. This post is just about doing it the Ruby way. Read More »

Active Record migrations can be useful to not just write migrations related to changes in database schema but to make one-time database insertions as well.

For example, making a new office location entry can be done using Active Record migrations.

class AddOfficeLocation < ActiveRecord::Migration
  def self.up
    OfficeLocation.new(:address_line1 => "Some blah", :address_line2 => "Some more blah", :city => "Coimbatore", capacity => 10)
  end

  def self.down
    office = OfficeLocation.find_by_city("Coimbatore")
    office.delete
  end
end

This is a relatively safe use of the power of ActiveRecord. The trouble starts when the temptation to put ActiveRecord models to better use kicks in.

class AddOfficeLocation < ActiveRecord::Migration
  def self.up
    office = OfficeLocation.my_custom_find_method_that_does_something()
    OfficeLocation.new(:address_line1 => office.address_line1, :address_line2 => office.address_line2, :city => "Coimbatore", capacity => 29)
  end

  def self.down
    office = OfficeLocation.find_by_city(&quot;Coimbatore&quot;)
    office.delete
  end
end

The danger here is that if the OfficeLocation model was to undergo some change during the course of which my_custom_find_method_that_does_something is deleted/changed/renamed, the effect of the method-change on the migration may end up never blowing up if the migrations are run incrementally.

If during the course of development, you are in the habit of doing a rake db:drop db:create before db:migrate, you are safe.

However, if you were to just run rake db:migrate, previously run migrations will never be run again and the effect of having removed/renamed my_custom_method_that_does_something will never be felt during development Finally, when the you deploy the code onto a new instance on production, the migrations break since the method will not be found.

The solution can be to always drop and create before migrating on development — as a habit. However a more robust solution will be to create a custom model within the migration and not depend on the model that the actual application uses.

class AddOfficeLocation < ActiveRecord::Migration
  def self.up
    office = OfficeLocationMig.my_custom_find_method_that_does_something()
    OfficeLocationMig.new(:address_line1 => office.address_line1, :address_line2 => office.address_line2, :city => "Coimbatore", capacity => 29)
  end

  def self.down
    office = OfficeLocation.find_by_city("Coimbatore")
    office.delete
  end
end

class OfficeLocationForMigration< ActiveRecord::Base

  set_table_name "officelocations"

  def self.my_custom_method_that_does_something
    #do something
    OfficeLocationForMigration.find_by_city("Coimbatore")
  end
end

Note: the use of the set_table_name method.

This way, the migration is coupled to a custom model and not the one exposed by the applicaiton.

Handy right?