Over the last few years, micro-blogging has spread to the masses and everyone from Barack Obama to the New York Times to Amazon has joined in the fun. Essentially (and according to my dear friend, Wikipedia),

Micro-blogging is a form of blogging that allows users to write brief text updates (usually less than 200 characters) and publish them, either to be viewed by anyone or by a restricted group which can be chosen by the user. These messages can be submitted by a variety of means, including text messaging, instant messaging, email, MP3 or the web.

Some of the most popular independent micro-blogging services are Twitter, Jaiku, Tumblr, and Pownce. But even existing platforms like Facebook and MySpace have begun building in various types of micro-blogging functionality.

Read the rest of this entry »

Rails Migrations provide an easy way to make versioned revisions to your database structure over a period of time. When used properly they can make it easy to make modifications to your existing database programmatically as you need to make changes. This is extremely helpful for large up-and-running projects, but what about projects that are still in development? I don't know about you but for me, after working on large project for awhile there can be a ridiculous number migrations sitting around. It's also quite possible that a good portion of your earlier migrations have been nullified by other migrations later on. When you start throwing data into your migrations this can quickly become a tangled patchwork web of evil.

While migrations are extremely helpful for making modifications on production systems, we have found that having a pile of migration revisions really doesn't serve much purpose during the development cycle. This is especially true if you are not needing to work with live data and you have access to a good code repository like SVN. So during the development cycle for most of our Rails related projects we maintain one large initialization migration, an installation shell script, and a refresh shell script. The large migration handles the standard migration goodness, any type of data import, and other dynamic data installation initialization procedures. The installation script is run once to deploy the application on a new system; it typically sets up the database, runs the initialization migration, and handles whatever other settings you need for deployment. The refresh script simply refreshes the database and reruns the initialization migration; this is used when the migration is updated.

Below is a very simple example of how we put this idea to use:

Database Initialization Migration - 001_initialize_database.rb

require 'active_record/fixtures'
 
class InitializaDatabase < ActiveRecord::Migration
  def self.up
 
    # Initialize fixture array
    # This array is used to load a list of fixtures that will be loaded into the database at the end of the installation process
    fixture_array = []
 
    # It's important to use the :force option if you are not going to drop tables in your down method
    # this forces tables to be overwritten if they are already present
    create_table :customer, :force => true do |t|
      t.column :name, :string
    end
 
    # Add to fixture array
    fixture_array << :client
 
    # CREATE REMAINING TABLES
 
    # Load fixture data
    Fixtures.create_fixtures('db/fixtures', fixture_array)
  end
 
  def self.down
  end
end

Installation SQL Script - install.sql

CREATE DATABASE database_name_dev;
CREATE DATABASE database_name_pro;
CREATE DATABASE database_name_test;
GRANT ALL privileges ON database_name_dev.* TO 'user'@'localhost' IDENTIFIED BY 'password';
GRANT ALL privileges ON database_name_pro.* TO 'user'@'localhost';
GRANT ALL privileges ON database_name_test.* TO 'user'@'localhost';

Installation Shell Script - install.sh

#!/bin/bash
 
mysql -u root --password=password -e "source install.sql"
rake db:migrate

Refresh Shell Script - refresh.sh

#!/bin/bash
 
rake db:migrate VERSION=0
rake db:migrate

Then to install on a system we simply run install.sh from the command line.

> ./install.sh

If a change is made to the schema we run refresh.sh from the command line.

> ./refresh.sh

Since refreshing the database wipes the database clean and reloads each time, its really only useful until you have reached a final stage of deployment. Hopefully by that time though you will have a relatively stable db structure and won't need to be adding a butt-load of migrations.

It's really a relatively simple concept, but I can't tell you how much time we have saved in deployment using this methodology. We'd love to hear your ideas and deployment strategies.

ActiveRecord is great and efficient for simple normalized databases, but once you start tread off the beaten path ActiveRecord starts to lose a lot of its mojo. A few months ago I had a rather abstract database that utilized a number of models based on Single Table Inheritance (STI). Prior to refactoring our our database diagram looked something like an upside down untranslated Tokyo subway map. Fortunately single table inheritance saved our butt big time and we were able to knock off a number of confusing entities from the database and refactor in some common functionality. There was but one problem though. Before our moving to single table inheritance we had a few classes that looked something like this:

class Organization < ActiveRecord::Base
end
 
class Client < ActiveRecord::Base
  belongs_to :organization
end
 
class StaffMember < ActiveRecord::Base
  belongs_to :organization
  has_many :clients, :through => :organization
end

After moving to single table inheritance it was something like this:

class Organization < ActiveRecord::Base
end
 
class Client < Organization
  belongs_to :organization, :foreign_key => 'parent_id'
end
 
class StaffMember < ActiveRecord::Base
  belongs_to :organization
  has_many :clients, :through => :organization
end

It looked fine. I had only changed one thing in the client model, but now the has_many association in the StaffMember model just doesn't work anymore. I kept getting an error akin to:

ActiveRecord::StatementInvalid: Mysql::Error: #42000Not unique table/alias: 'organization': SELECT organization.* FROM organization organization.parent_id = organization.id WHERE ((organization.organization_id = 1)) AND ( (`organization`.`type` = 'Client' ) )

Well that just plain sucked... all of that refactoring seemed to have gone to waste. I scoured the net looking for a solution to my conundrum and I couldn’t find a single reasonable answer to it. I could have used the "finder_sql" option but then it only returns read only pseudo models. There just had to be a better way. I begrudgingly started to dig through ActiveRecord hoping to find a quick fix. Alas, I came back empty handed. I had almost lost hope when I realized I could just like the two foreign keys together between the Client and StaffMember model to get the same result as using the Rails has_many :through option. So I dug around a little bit more in ActiveRecord and added an “alternate_key” option to the HasManyAssociation class to define a different foreign_key instead of always needing to link to a primary_key. So now I could link directly to the Client model from the StaffMember model without needing to use the :through option. An example can be seen below:

class Organization < ActiveRecord::Base
end
 
class Client < Organization
  belongs_to :organization
end
 
class StaffMember < ActiveRecord::Base
  belongs_to :organization
  has_many :clients, :alternate_key => 'organization_id', :foreign_key => 'organization_id'
end

Now @staff_member.clients should return a list of clients that are part of that StaffMember’s organization.

Download it

Questions, Comments, Contiributions? Contact Me.

Hello, and welcome to the new MetaSpring blog where we’ll be discussing a wide range of topics - from internet marketing and SEO tricks to web development trends and code snippets. You’ll most likely even find posts about philosophy, music, and the arts, since those are just a few of our core, creative inspirations.

The purpose of this blog is to act as a hub for communications between our company and the rest of the world. We want to start conversations and form stronger relationships because we know that it is these types of connections that produce the greatest ideas. The possibilities are endless in this virtual universe that we call the World Wide Web.

Naturally, this first post comes with the launch of our revamped company website which now features an extended portfolio of our work, detailed descriptions of our services, client testimonials, company history and management biographies. We hope you’ll take a few moments to browse through the site and let us know your thoughts.