Object property-names in JavaScript must be strings. This may seem obvious, but it has serious repercussions if you’re used to the free-wheeling style of Ruby’s Hash.

a = {};
b = {};
a[b] = null;
for (var i in a) {

In order to have the flexibility I’m used to, I whipped up this simple Hash that stores both keys and values in separate arrays.

/* JavaScript Associative Array */
function Hash(obj) {
Hash.prototype = {
  initialize: function(obj) {
    this._keys   = [];
    this._values = [];
    if (obj) for (var k in obj) {
      this.set(k, obj[k]);
  set: function(key, value) {
    var i = this._indexOf(key);
    if (undefined == i) {
    } else {
      this._values[i] = value;
    return value;
  get: function(key) {
    return this._values[this._indexOf(key)];
  remove: function(key) {
    var i = this._indexOf(key);
    if (undefined == i) return;
    var s = this._keys.length - 1;
    this._keys[i]   = this._keys[s];
    this._values[i] = this._values[s];
  hasKey: function(key) {
    return (undefined != this._indexOf(key));
  keys: function() { return this._keys.slice(0, this._keys.length); },
  values: function() { return this._values.slice(0, this._values.length); },
  eachPair: function(func) {
    for (var i = this._keys.length - 1; i >= 0; i--) {
      func(this._keys[i], this._values[i]);
  _indexOf: function(key) {
    for (var i = this._keys.length - 1; i >= 0; i--) {
      if (this._isElementSame(key, this._keys[i]))
        return i;
    return undefined;
  _isElementSame: function(ele1, ele2) {
    if (ele1 == ele2) return true;
    if ('string' == typeof(ele1)) return false;
    if (ele1.hasOwnProperty('length')) {
      for (var i = ele1.length - 1; i >= 0; i--) {
        if (!this._isElementSame(ele1[i], ele2[i]))
          return false;
    // TODO: Need to do something smarter for objects
    return true;

class Numeric
  def to_ordinal
    to_i.to_s + ((11..13) === (n = to_i.abs % 100) ? 'th' :
      { 1 => 'st', 2 => 'nd', 3 => 'rd' }.fetch(n % 10, 'th'))

This code is based on a snippet for generating ordinals. The other examples used a fixed-size array for pulling suffixes. Instead, I use the 2-parameter version of Hash#fetch to supply a default for most numbers.

It is frequently desirable to represent bidirectional relationships in web applications, and simple databases are not immediately suitable for this information.

Let’s start with a simple unidirectional example that a database like MySQL handles well.

User 1 wants to be friends with User 2.

A row is inserted into the befriendings table with User 1 as the initiator and User 2 as the recipient.

Now, if your friendships are unidirectional the job is pretty much done. If User 2 wants to be friends with User 1, they can initiate a befriending of their own. On Kongregate, users you have befriended are called “Friends”, and users who have befriended you are called “Fans”

class User < ActiveRecord::Base
  has_many :initiated_befriendings,
    :class_name => :Befriending, :foreign_key => :initiator_id
  has_many :received_befriendings,
    :class_name => :Befriending, :foreign_key => :recipient_id
  has_many :friends, :through => :initiated_befriendings,
    :source => :recipient
  has_many :fans, :through => :initiated_befriendings,
    :source => :initiator

However, sometimes you want to follow a friendship model more like the one used by Facebook or MySpace, where all friendships are bidirectional.

Both of these sites implement a relationship-confirmation step before any relationship is finalized. For simplicity’s sake, I’ll skip over modeling that step, but suffice it to say, pending relationships are best stored separately from confirmed relationships. Attempting to mix the two needlessly mingles data and complicates application logic.

Let’s assume any user has the ability to initiate the bidirectional relationship. Now, in the befriendings table, we technically have all the information necessary to list all friends of User 1, and all friends of User 2.

SELECT * FROM befriendings WHERE initiator_id = 1 OR recipient_id = 1 ORDER BY created_at;

SELECT * FROM befriendings WHERE initiator_id = 1
UNION SELECT * FROM befriendings WHERE recipient_id = 1 ORDER BY created_at;

In the first case, only one index can be used (on either initiatior_id, or on recipient_id), and in both cases, the ORDER clause necessitates a filesort on the results.

So the simplest approach here would be to simply duplicate the relationship data in another row, swapping the initiator and recipient ids. This is okay, but starts to fall apart as store more information about the relationship itself. For example, imagine we store a compatibility score between the two users, as last.fm does.

This information would need to be duplicated, as well as keeping the the various timestamps in-sync. Indices against these fields would bloat unnecessarily.

Instead, we can move the duplicated information to a dedicated table, eliminating indices on the relationships table itself. The column by which results are ordered is moved from the relationships table to the dedicated table.

class Befriending < ActiveRecord::Base
  belongs_to :initiator, :class_name => :User
  belongs_to :recipient, :class_name => :User
  after_create do |b|
    BefriendingEdge.create!(:user => b.initiator, :befriending => b)
    BefriendingEdge.create!(:user => b.recipient, :befriending => b)
class BefriendingEdge < ActiveRecord::Base
  belongs_to :user
  belongs_to :befriending

Users then access their list of friends through a :friends association and can access the rich information about the relationship itself through the :befriendings association. The befriending_edges table’s indices are simple and very efficient, and looking up befriendings uses a single primary key, and looking up friends uses two primary keys.

class User < ActiveRecord::Base
  has_many :befriending_edges
  has_many :friends, :through => :befriending_edges, :source => :user
  has_many :befriendings, :through => :befriending_edges, :source => :befriending

Despite an unfortunate fainting spell at the end of the presentation, overall it went alright.

The slides are available here.