Kevin Y. Chan

The news is out, Layerboom is now officially a part of Joyent.

Layerboom was co-founded by Howie and Trevor in May 2010 bringing on Josh and I onboard as founding employees. I met and worked with Josh and Howie at a previous job and it was a pleasure to be able work with them again. Trevor made it all happen.

For the first 6 months, all four of us worked out of a tiny room at Bootup’s old offices. Our office was a tiny 10ft by 10ft room with a giant pole in the middle. At one point, to save money, we bought packs of dogs and buns from Costco to make our own hotdogs for lunch. We calculated the cost for a cheap lunch in Vancouver ($10), we can feed on a week of hotdogs. In fact, after the acquisition, Trevor banned us from going to Costco for lunch.

Being a part of the Layerboom team has been nothing but spectacular. Trevor worked closely with Howie on the business side of things while keeping Josh and I focused on hacking out the product.

I think Josh and I both appreciated Trevor’s “Here is what we need to build, go nuts!” approach to getting the product/service out the door. Plus, we got to work with bleeding-edge tech every single day. What more could a developer ask for?

In 12 months, we built a turn-key solution for hosting companies to provide cloud services, ran our own VPS provider for a few months, threw it all away and rebuilt it from scratch (learning from our mistakes) as an appliance, sold some boomboxes and got acquired by Joyent.

We feel that Joyent and Layerboom are a perfect fit as our companies’ visions are pretty much identical.

Today marks the end of an amazing first week as a Joyeur and it was nothing short of awesome. The Joyeurs have been extremely accommodating. Nothing beats working with talented hackers who are as passionate as you are about building awesome shit.

We are glad that at the end, it was all worth it.

The ruby metaclass (also known as the Singleton class) is a very commonly misunderstood ruby language construct.

Lets look at a simple class definition:

class Dog
  def bark
    puts "woof woof!"
  end
end

The class Dog contains the instance method bark. This is pretty self-explanatory.

What happens when you define a class with class methods (also known as static methods).

In ruby, everything is an object. That means classes are objects too.

class Dog
  def self.bark
    puts "woof woof!"
  end
end

The Dog class above is actually an instance of Class.

> Dog.__id__
=> 2152689112
> Dog.class
=> Class
>

If the Dog class contains instance methods, what class contains the Dog’s class methods?

You might at first think Class class contains the Dog class methods. If is true, all instances of Class should contain bark method right? That wouldn’t really make sense if it behaved like that would it?

Introducing the Metaclass (also known as the Singleton class)

In between Class and Dog is a class called the Metaclass. An object’s metaclass is a Singleton class that objects inherits it’s methods from. The reason why it is so confusing is primarily due to the fact that they are invisible. You can, however, get a hold of the metaclass:

> metaclass = class << Dog; self; end
=> #<Class:Dog>
> metaclass.instance_methods
=> [:bark, :allocate, :new, :superclass, :freeze, :===, :==, :<=>, :<, :<=, :>, :>=, :to_s, :included_modules, :include?, :name, :ancestors, :instance_methods, :public_instance_methods, :protected_instance_methods, :private_instance_methods, :constants, :const_get, :const_set, :const_defined?, :const_missing, :class_variables, :remove_class_variable, :class_variable_get, :class_variable_set, :class_variable_defined?, :module_exec, :class_exec, :module_eval, :class_eval, :method_defined?, :public_method_defined?, :private_method_defined?, :protected_method_defined?, :public_class_method, :private_class_method, :autoload, :autoload?, :instance_method, :public_instance_method, :nil?, :=~, :!~, :eql?, :class, :clone, :dup, :taint, :tainted?, :untaint, :untrust, :untrusted?, :trust, :frozen?, :inspect, :methods, :singleton_methods, :protected_methods, :private_methods, :public_methods, :instance_variables, :instance_variable_get, :instance_variable_set, :instance_variable_defined?, :instance_of?, :kind_of?, :is_a?, :tap, :send, :public_send, :respond_to?, :extend, :display, :method, :public_method, :define_singleton_method, :hash, :__id__, :object_id, :to_enum, :enum_for, :gem, :equal?, :!, :!=, :instance_eval, :instance_exec, :__send__]

Lets add a couple more methods to the Dog class using the metaclass:

metaclass.class_eval do
  def sit
    puts "<sits down>"
  end
end

Dog.sit => "<sits down>"

You may have came across code that used the following idiom to define class methods.

class Dog
  class << self
    def sit
      puts "<sits down>"
    end
  end
end

What we are actually doing above is defining a sit instance method in Dog’s metaclass.

For whatever reason, TD Canada Trust (the best bank in Canada by the way) decided to limit the maximum length of your online banking password to 8 characters. One possible reason for doing so may be to prevent people from coming up with passwords that are too long or complex to remember and end up writing them down.

Unfortunately, they do realize that having simple-to-remember-passwords limited to 8 characters is insecure and thus, requires your password to be composed of letters and numbers. Some sites (CRA) enforce upper-and lower case into the mix, while still limiting your password length. Perhaps it gives the user the sense of security?

Referring to an article I read a couple years ago on Password Usability, a password composed of two common words is more secure than a password composed of 6 random characters (no numbers) – chickenpaper is more secure than zcacnq. With a password composed of three common words, the password would theoretically take 2,537 years to crack against a dictionary attack (impossible to brute-force).

Which is easier to remember? Which are you more likely to write down on a post-it note and stick it on your monitor? These are both considered indefinitely secure.

kZ98c5aQ or turbogoesforawalk

You decide.

Lets assume we have a module called Fruit, within the Fruit module is a bunch of Fruit classes.

module Fruit
   class Apple
   end
   class Orange
   end
   class WaterMelon
   end
end

If the name of the fruit comes from some data or memory store, and we want to instantiate the class dynamically via the fruit name, you might attempt to do something like this:

>> fruit_name = "Apple"
> "Apple"
>> class_name = "Fruit::#{fruit_name}"
> "Fruit::Apple"
>> klass = Object.const_get(class_name)
NameError: wrong constant name Fruit::Apple
        from (irb):14:in `const_get'
        from (irb):14

The problem here is #const_get does not support retrieving constants within a nested namespace. In order to combat this, we must first retrieve the module in which the class is in, then get the class.

>> Module.const_get("Fruit").const_get(fruit_name)
> Fruit::Apple
>>

Here is an example in action:

module Fruit
  class Apple
    def self.color
      "red"
    end
  end

  class Orange
    def self.color
      "orange"
    end
  end

  class WaterMelon
    def self.color
      "green"
    end
  end
end

%w{Apple Orange WaterMelon}.each do |fruit_name|
  klass = Module.const_get("Fruit").const_get(fruit_name)
  puts klass.color
end

# output
red
orange
green