Rujubu's View

Dynamically Creating Class and Instance Methods in Ruby

Greg Spurrier — Sat, 02 Feb 2008 18:00:24 GMT

Ruby’s support for dynamically adding methods to existing classes is very powerful and can be used to create seemingly magic results. Unsurprisingly, Rails uses it extensively and you will also find it in the guts of many an acts_as_xxx plugin. Implementing code that adds methods on the fly can be confusing, though. Consider this example:

class ExtendMe
  def self.extend_it
    class_eval "def added_by_class_eval; end"
    instance_eval "def added_by_instance_eval; end"
  end
end

ExtendMe.extend_it

Calling ExtendMe.extend_it injects two new methods into the class in slightly different ways. Fair enough. But, what type of method does each end up being?

Let’s find out. First, we’ll check for class methods:

>> ExtendMe.respond_to? :added_by_class_eval
=> false
>> ExtendMe.respond_to? :added_by_instance_eval
=> true

And now for instance methods:

>> em = ExtendMe.new
=> #<ExtendMe:0x35d5a4>
>> em.respond_to? :added_by_class_eval
=> true
>> em.respond_to? :added_by_instance_eval
=> false

Is that what you expected?

When executed in a class method, using class_eval to define a new method creates an instance method. Using instance_eval creates a class method.

I’ll explore why this is so in a future post. For now, just remember that it’s backwards from what you might expect.

Color Wheel Generation

Greg Spurrier — Thu, 13 Dec 2007 05:38:13 GMT

Today I was working with a set of 32 items that each needed to be displayed with a unique color. The actual color assigned to any given item did not matter, but I wanted to make sure there was enough variation to avoid confusion among them. I also wanted to avoid anyone saying this project was from my blue period or green period.

I did a bit of web searching for color wheels and palettes containing around that many colors, but did not find anything that was immediately useful. I found articles on the theory of color wheels, JavaScript website color scheme generators, and palettes for various desktop environments. I just wanted a simple list of colors that were well distributed across the color space.

I ended up hacking together a quick Ruby script to generate a color wheel with 33 steps moving from red to green to blue and back to red. After I was finished with the project I decided to clean it up a bit, generalize it to n steps, and post it, figuring that it may be of use to someone else.

I am not a color scientist and I have no idea whether this is the “proper” way to generate a color wheel, but it worked for my purposes and I was happy with the results. The code is below:

def ramp(step, total_steps)
  (255 * Math::sin(Math::PI/2.0/total_steps * step)).round
end

# Generates the color sequence for a color wheel containting the specified
# number of positions.  If positions is not a multiple of 3, it will be
# rounded up to the next multiple.
def color_wheel(positions)
  sps = (positions/3.0).ceil # steps per segment
  colors = []
  (0...sps).each do |step|
    colors << "#%02x%02x00" % [ramp(sps - step, sps), ramp(step, sps)]
  end
  (0...sps).each do |step|
    colors << "#00%02x%02x" % [ramp(sps - step, sps), ramp(step, sps)]
  end
  (0...sps).each do |step|
    colors << "#%02x00%02x" % [ramp(step, sps), ramp(sps - step, sps)]
  end
  colors
end

And, here are the results when called with color_wheel(12):

Happy coloring!

Rate Limiting Ruby

Greg Spurrier — Sat, 08 Dec 2007 20:04:24 GMT

I have decommissioned my old blog at gregspurrier.com, but, from time to time, I will re-post here some of my favorite articles from there. This article was originally posted on September 27, 2006.

My software is too fast! That’s not a frequent lament heard from programmers. Sometimes it’s true, though, and it can be just as big of a deal as when things are moving too slowly.

I found myself in this situation a couple of months ago in my work at My Digital Life. I was building a demo that integrated our platform with the web services API of a popular music site. The API’s terms of service required that requests be limited to no more than one per second. Without putting safeguards in place, our platform easily would have violated that constraint.

Ensuring that a portion of code is executed at no more than a maximum rate is not necessarily challenging, and I’d done it many times in the past. This was the first time I’d tackled the problem with Ruby, though, and I was pleased with the elegance of the solution.

The code below is the RateLimiter class that I ended up with:

class RateLimiter
  # Create a new rate limiter object that will ensure that actions are
  # executed with at least the specified minimum elapsed time between
  # successive invocations (specified in seconds or fractions thereof)
  def initialize(min_elapsed_time)
    @period = min_elapsed_time.to_f
    @last_fired = Time.now.to_f - @period
  end

  # Execute the given block of code.  If the time elapsed since the
  # last call is not sufficient to honor the rate limiter's configured
  # minimum interarrival period, the method will first block for 
  # an appropriate amount of time.
  #
  # The block's value is returned as the result.
  def limited(&block)
    # Make sure that we're obeying the limit
    now = Time.now.to_f
    if now - @last_fired < @period
      sleep @period - (now - @last_fired)
    end

    @last_fired = Time.now.to_f
    yield      
  end
end

Any code that must be rate-limited is simply passed as a block to the object’s limited() method. For example:

# Limit to once per second
rl = RateLimiter.new(1.0)
5.times do
  rl.limited do
    puts Time.now.to_s
  end
end

yields the result:

    Wed Sep 27 15:23:24 PDT 2006
    Wed Sep 27 15:23:25 PDT 2006
    Wed Sep 27 15:23:26 PDT 2006
    Wed Sep 27 15:23:27 PDT 2006
    Wed Sep 27 15:23:28 PDT 2006

The same RateLimiter instance can be used to guard multiple blocks of code that all access the same constrained resource.

The beauty of this approach is that it separates the mechanics of rate limiting from the code that is being throttled. Tomorrow I could change the RateLimiter class to allow rapid bursts of activity while still maintaining one request per second on average and I wouldn’t have to change a line of code in the application.

Things like this are why programming in Ruby frequently makes me smile.

Introducing Rujubu's View

Greg Spurrier — Sat, 08 Dec 2007 18:53:23 GMT

Today I’m launching a new blog called Rujubu’s View. It is about Ruby, Rails, and software development in general. The content will be inspired both from the work I do with clients of my consulting practice, Rujubu Consulting, and from my personal projects.

Welcome to the new blog and I hope you enjoy what you read.