Ruby is Awesome - Home

Moved my Blog to http://tom.preston-werner.com

2008-11-09T21:14:00Z

I will no longer be posting here at rubyisawesome.com. Check out my new site http://tom.preston-werner.com. You'll also need to update your feed. Hope to see you there!

Tom

Lazy Mixin

2007-10-13T06:40:00Z

# Before you ask--yes, this has a very specific use case and is not
# generally applicable to the problem of fine-grained lazy evaluation.
# But it does *exactly* what I need it to do. =)

# Allows attributes to be declared as lazy, meaning that they won't be
# computed until they are asked for. Just mix this module in:
#
#   class Foo
#     include Lazy
#     ...
#   end
#
# To specify a lazy reader:
#
#   lazy_reader :att
#
# Then, define a method called __bake__ that computes all your lazy
# attributes:
#
#   def __bake__
#     @att = ...
#   end
#
# That's it! (Tom Preston-Werner: rubyisawesome.com)
module Lazy
  module ClassMethods
    def lazy_reader(*args)
      args.each do |arg|
        define_method(arg) do
          self.__prebake__
          instance_variable_get(('@' + arg.to_s).intern)
        end
      end
    end
  end
  
  def __prebake__
    return if @__baked__
    self.__bake__
    @__baked__ = true
  end
  
  def self.included(base)
    base.extend(ClassMethods)
  end 
end

# A pedagogical class with a lazy attribute
class Foo
  include Lazy
  
  attr_reader :id
  lazy_reader :body
  
  def initialize(id)
    @id = id
  end
  
  def __bake__
    puts "__baking__"
    @body = "The 30th fibonacci is #{self.fib(30)}"
  end
  
  def fib(n)
    return 1 if n == 0 || n == 1
    return fib(n-1) + fib(n-2)
  end
end

t = Foo.new('abc')

puts t.id      # => (immediate) "abc"
puts t.body    # => (short pause) The 30th fibonacci is 1346269
puts t.body    # => (immediate) The 30th fibonacci is 1346269

Hash Defaults and Path of Madness

2007-09-11T22:52:00Z

This is a little story about innocent Ruby mistakes and how they can ruin your day. One of our interns here are Powerset had some code that used default hash values.

12	h = {}h.default = []

Fair enough. Then the code did this:

h[:foo] << 'foo' # => ["foo"]

Which happily returns in exactly the expected fashion. We can even check the value to make sure:

h[:foo] # => ["foo"]

But then later on we look more closely at the hash and WTF it's empty!

h # => {}

Madness! Until you realize that a hash's default value is only used as the return value for a hash lookup of a non-existent key.

12	h.default # => ["foo"]h[nil] # => ["foo"]

And then you can only laugh once you look back at the code that seemed to work and see exactly why it was so deceiving.

god 0.4.0 released

2007-09-10T20:10:00Z

Progress on god is moving along as quick as ever. This release adds a bunch of new features and bug fixes. Most interestingly you'll find several useful new command line functions:

god status prints out the status of each Watch
god log shows realtime logs for a specific Watch (even if you don't have god logging to file)
god load loads or reloads a config file into a running god instance
god terminate stops all Watches and then stops god (useful when testing your setup)

The logging system has been beefed up with proper timestamps and criticality levels. Log messages are more complete overall. You can also get the STDOUT/STDERR of a god-daemonized process written to a log file by specify 'w.log = <log>' in your Watch config.

If you let god daemonize your process for you, there's no need to provide a stop command. A default killing lambda will take care of gracefully (or not so gracefully if necessary) stopping your god-daemonized process.

The validity of your config file is checked better than previous versions to point you to the problem area of your config.

The bug that prevented group control from working has been fixed so you can now start/stop/etc groups of Watches.

Updated documentation is now available on the website:

http://god.rubyforge.org/

WHAT IS GOD?

God is an easy to configure, easy to extend monitoring framework written in Ruby.

Keeping your server processes and tasks running should be a simple part of your deployment process. God aims to be the simplest, most powerful monitoring application available.

DISCLAIMER

God is still very young, I'd love to get feedback and bug reports, but I do not yet recommend you use it for mission critical tasks. I personally use it in production but then I'm a daring fellow.

INSTALL

sudo gem install god

FEATURES

Config file is written in Ruby
Easily write your own custom conditions in Ruby
Supports both poll and event based conditions
Different poll conditions can have different intervals
Easily control non-daemonized processes

EXAMPLE

The easiest way to understand how god will make your life better is by looking at a sample config file. The following configuration file is what I use at gravatar.com to keep the mongrels running:

# file:      gravatar.god
# run with:  god -c /path/to/gravatar.god
# 
# This is the actual config file used to keep the mongrels of
# gravatar.com running.

RAILS_ROOT = "/var/www/gravatar2/current"

%w{8200 8201 8202}.each do |port|
  God.watch do |w|
    w.name = "gravatar2-mongrel-#{port}"
    w.interval = 30.seconds # default
    w.start = "mongrel_rails cluster::start --only #{port} \
      -C #{RAILS_ROOT}/config/mongrel_cluster.yml"
    w.stop = "mongrel_rails cluster::stop --only #{port} \
      -C #{RAILS_ROOT}/config/mongrel_cluster.yml"
    w.grace = 10.seconds
    w.pid_file = File.join(RAILS_ROOT, "log/mongrel.#{port}.pid")
    
    w.behavior(:clean_pid_file)

    w.start_if do |start|
      start.condition(:process_running) do |c|
        c.interval = 5.seconds
        c.running = false
      end
    end
    
    w.restart_if do |restart|
      restart.condition(:memory_usage) do |c|
        c.above = 150.megabytes
        c.times = [3, 5] # 3 out of 5 intervals
      end
    
      restart.condition(:cpu_usage) do |c|
        c.above = 50.percent
        c.times = 5
      end
    end
  end
end

DOCS

Detailed documentation is available at http://god.rubyforge.org/

CHANGES

== 0.4.0 / 2007-09-13

Major Enhancements
- Add the ability for conditions to override transition state (for exceptional cases)
- Implement dynamic load of config files while god is running (god load <filename>)
- Add ability to save auto-daemonized process output to a log file
- Add robust default stop lambda command for auto-daemonized processes (inspired by _eric)
- Add status command for god binary (shows status of each watch)
- Create proper logger with timestamps
- Add log command to god binary to get real time logs for a specific watch from a running god instance
- Add terminate command for god binary (stop god and all watches)
Minor Enhancements
- Enforce validity of Watches
- Enforce that God.init is not called after a Watch
- Move pidfiledirectory creation and validation to God.start
- Remove check for at least one Watch during startup (now that dynamic loading exists)
New Conditions
- Tries < PollCondition - triggers after the specified number of tries
- Add :notifywhenflapping behavior to check for oscillation [kevinclark]
- Add :degrading_lambda condition. [kevinclark] It uses a decaying interval (1/2 rate) for 3 cycles before failing.
Bug Fixes
- Use exit!(0) instead of exit! in god binary to exit with code 0 (instead of default -1)
- Command line group control fixed
- Fix cross-thread return problem

AUTHORS

Tom Preston-Werner Kevin Clark

Powerset Interview

2007-08-20T21:01:00Z

I was recently interviewed by my buddy Ryan Ferrier as part of a series of Powerset employee interviews for Steve Newcomb's blog. I know you think interviews are boring, so here's a little taste of mine to dispel any myths:

Rumor has it that you listen almost exclusively to techno music, is this true?

My dream is to code in a large, white, egg-shaped room wherein a large, omnidirectional speaker system is suspended at one locus, and an elaborate, 9 screen, multi-platform computing setup is suspended at the other locus. In this dream, I am sitting comfortably at the computer locus while thundering trance emanating from the opposite locus is parabolically focused upon my exact location. Then I could get some *real* coding done.

Rumor also has it that when listening to said techno music, you get in a trance-like state for hours on end and transform into a coding machine. Could you describe this altered state of being for us?

Remember the guys from "The Matrix" that could look at those screens of waterfalling green glyphs and see real world objects in them? It's nothing like that. That's impossible and ridiculous. If you've ever sat zazen and meditated on some ancient koans, that would be another good example of what it's not like. It's also not like watching your dog eat peanut butter. I'd keep going but it would take infinitely long to describe everything that it's not, so I'll have to stop and leave you mystified by the enigma of it all.

Continue reading the full Tom Preston-Werner Interview.

god 0.3.0 released

2007-08-17T21:25:00Z

Plenty of big changes and improvements in this release of god. Most noticeable is a simplification of the config file. Sadly, we must say goodbye to the much loved God.meddle and promote God.watch to top level. This change allows you to easily load in other god config files and have them work as expected. There's even a God.load that takes a glob-style file path string and expands it to load multiple files.

PID file support is now baked in so you don't have to set the pid_file attribute on conditions anymore. This also allows god to support processes that aren't already daemons. If you don't specify a PID file for the watch, god will auto-daemonize and keep track of your process for you! To use this feature, you must either run as root (pid files will be stored by default in /var/run/god) or set the pid_file_directory attribute in a God.init block (see docs).

For anyone that had problems installing the 0.2.0 release because of the events system not compiling, god 0.3.0 will now allow you to install without event support. Most systems are capable of supporting events, but it requires some dedication to get the headers in place and make sure your kernel is new enough. To determine if your god installation has event support you can run "sudo god -V" (this MUST be run as root on Linux, as netlink connector requires root permissions).

Using the god binary you can now control your watches from the command line. You can start/stop/restart/monitor/unmonitor watches at your demand.

New watch attributes now available: pid_file: sets the watch process' PID file location uid/gid: start processes as someone else (requires root access) group: assign a watch to a group (to control them all at once) autostart: prevent auto start on god start if false

Updated documentation is now available on the website:

http://god.rubyforge.org/

WHAT IS GOD?

God is an easy to configure, easy to extend monitoring framework written in Ruby.

Keeping your server processes and tasks running should be a simple part of your deployment process. God aims to be the simplest, most powerful monitoring application available.

DISCLAIMER

God is still very young, I'd love to get feedback and bug reports, but I do not yet recommend you use it for mission critical tasks. I personally use it in production but then I'm a daring fellow.

INSTALL

sudo gem install god

FEATURES

Config file is written in Ruby
Easily write your own custom conditions in Ruby
Supports both poll and event based conditions
Different poll conditions can have different intervals
Easily control non-daemonized processes

EXAMPLE

The easiest way to understand how god will make your life better is by looking at a sample config file. The following configuration file is what I use at gravatar.com to keep the mongrels running:

# file:      gravatar.god
# run with:  god -c /path/to/gravatar.god
# 
# This is the actual config file used to keep the mongrels of
# gravatar.com running.

RAILS_ROOT = "/var/www/gravatar2/current"

%w{8200 8201 8202}.each do |port|
  God.watch do |w|
    w.name = "gravatar2-mongrel-#{port}"
    w.interval = 30.seconds # default
    w.start = "mongrel_rails cluster::start --only #{port} \
      -C #{RAILS_ROOT}/config/mongrel_cluster.yml"
    w.stop = "mongrel_rails cluster::stop --only #{port} \
      -C #{RAILS_ROOT}/config/mongrel_cluster.yml"
    w.grace = 10.seconds
    w.pid_file = File.join(RAILS_ROOT, "log/mongrel.#{port}.pid")
    
    w.behavior(:clean_pid_file)

    w.start_if do |start|
      start.condition(:process_running) do |c|
        c.interval = 5.seconds
        c.running = false
      end
    end
    
    w.restart_if do |restart|
      restart.condition(:memory_usage) do |c|
        c.above = 150.megabytes
        c.times = [3, 5] # 3 out of 5 intervals
      end
    
      restart.condition(:cpu_usage) do |c|
        c.above = 50.percent
        c.times = 5
      end
    end
  end
end

DOCS

Detailed documentation is available at http://god.rubyforge.org/

CHANGES

== 0.3.0 / 2007-08-17

Fix netlink header problem on Ubuntu Edgy [Dan Sully]
Add uid/gid setting for processes [kevinclark]
Add autostart flag for watches so they don't necessarily startup with god [kevinclark]
Change command line call options for god binary to accommodate watch start/stop functionality
Add individual start/stop/restart grace periods for finer grained control
Change default DRb port to 17165 ('god'.to_i(32))
Implement command line control to start/restart/stop/monitor/unmonitor watches/groups by name
Watches can now belong to a group that can be controlled as a whole
Allow god to be installed (sans events) on systems that don't support events
Daemonize and handle PID files for non-daemonizing scripts [kevinclark]
Fix simple mode lifecycle gap
Remove necessity to specify pid_file for conditions
Change config file to use God.init and God.watch directly instead of God.meddle block
Move god binary command logic to main library
Enhance god binary with better reporting
Fix synchronization bug in Timer (reported by Srini Panguluri)
Add Lambda condition for easy custom conditions [Mike Mintz]
Add sugar for numerics (seconds, minutes, kilobytes, megabytes, percent, etc)
Add optional PID and log file generation to god binary for daemon mode
Add God.load to do glob enabled loading
Add -V option to god binary for detailed version/build info

AUTHORS

Tom Preston-Werner
Kevin Clark

god 0.2.0 released

2007-07-19T22:16:00Z

A lot of work has gone into god since the last release. Say goodbye to polling for process status--support for event based conditions via kqueue/netlink has been added (thanks Kevin Clark)! Only a few events are currently supported (most prominently process exit), but the way is now open for the addition of other events. A new, advanced syntax is available (in addition to the familiar simple syntax) that gives you full power over the new state based lifecycle of your Watches. Updated documentation is available on the website:

http://god.rubyforge.org/

WHAT IS GOD?

God is an easy to configure, easy to extend monitoring framework written in Ruby.

Keeping your server processes and tasks running should be a simple part of your deployment process. God aims to be the simplest, most powerful monitoring application available.

DISCLAIMER

God is still very young, I'd love to get feedback and bug reports, but I do not yet recommend you use it for mission critical tasks. I personally use it in production but then I'm a daring fellow.

INSTALL

sudo gem install god

note: currently tested only on Redhat Linux and Darwin (won't work on Windows)

FEATURES

Config file is written in Ruby
Easily write your own custom conditions in Ruby
Supports both poll and event based conditions
Different poll conditions can have different intervals

EXAMPLE

The easiest way to understand how god will make your life better is by looking at a sample config file. The following configuration file is what I use at gravatar.com to keep the mongrels running:

# file:      gravatar.god
# run with:  god start -c /path/to/gravatar.god
# 
# This is the actual config file used to keep the mongrels of
# gravatar.com running.

RAILS_ROOT = "/var/www/gravatar2/current"

God.meddle do |god|
  %w{8200 8201 8202}.each do |port|
    god.watch do |w|
      w.name = "gravatar2-mongrel-#{port}"
      w.interval = 30 # seconds default
      w.start = "mongrel_rails cluster::start --only #{port} \
        -C #{RAILS_ROOT}/config/mongrel_cluster.yml"
      w.stop = "mongrel_rails cluster::stop --only #{port} \
        -C #{RAILS_ROOT}/config/mongrel_cluster.yml"
      w.grace = 10 # seconds
      
      pid_file = File.join(RAILS_ROOT, "log/mongrel.#{port}.pid")
      
      w.behavior(:clean_pid_file) do |b|
        b.pid_file = pid_file
      end

      w.start_if do |start|
        start.condition(:process_running) do |c|
          c.interval = 5 # seconds
          c.running = false
          c.pid_file = pid_file
        end
      end
      
      w.restart_if do |restart|
        restart.condition(:memory_usage) do |c|
          c.pid_file = pid_file
          c.above = (150 * 1024) # 150mb
          c.times = [3, 5] # 3 out of 5 intervals
        end
      
        restart.condition(:cpu_usage) do |c|
          c.pid_file = pid_file
          c.above = 50 # percent
          c.times = 5
        end
      end
    end
  end
end

DOCS

Detailed documentation is available at http://god.rubyforge.org/

CHANGES

== 0.2.0 / 2007-07-18

Rewrote innards to use a state and event based lifecycle
Basic support for events via kqueue (bsd/darwin) and netlink/pec (linux) [kevinclark]
Added advanced syntax (simple syntax calls advanced api underneath)
Condition returns have changed meaning. With simple syntax, a true return activates block
Updated http://god.rubyforge.org with updated simple config and new advanced config

AUTHORS

Tom Preston-Werner
Kevin Clark

MySQL secrets: \G instead of ;

2007-07-10T18:47:00Z

I'm a MySQL command line junkie. Even when I have a GUI frontend installed, I always find myself typing mysql into terminal when I need to peek inside the database. As such, one trick that has changed my life for the better is the \G statement terminator. Normally when you execute a query you get something like:

mysql> select * from queries order by id desc limit 1;
+-----+------------------------------------+--------------+------------+------------+
| id  | query                              | query_set_id | created_at | updated_at |
+-----+------------------------------------+--------------+------------+------------+
| 969 | when a stranger calls sound boards |          103 | 2007-07-09 | 2007-07-09 | 
+-----+------------------------------------+--------------+------------+------------+
1 row in set (0.00 sec)

That's ok, but for tables with more than a few columns you get a nasty bunch of badly wrapped output that's essentially impossible to decipher. If you replace the terminating semicolon with \G, you'll get this output instead:

mysql> select * from queries order by id desc limit 1 \G
*************************** 1. row ***************************
          id: 969
       query: when a stranger calls sound boards
query_set_id: 103
  created_at: 2007-07-09
  updated_at: 2007-07-09
1 row in set (0.00 sec)

Aaaaaaaaah! Now we're talking. You can even copy this output and paste it right into a YAML fixture in your rails app (with a little fixing of the indentation)!

god 0.1.0 released

2007-07-07T22:12:00Z

I'm proud to announce the initial public release of god!

http://god.rubyforge.org/

WHAT IS GOD?

God is an easy to configure, easy to extend monitoring framework written in Ruby.

Keeping your server processes and tasks running should be a simple part of your deployment process. God aims to be the simplest, most powerful monitoring application available.

DISCLAIMER

God is still very young, I'd love to get feedback and bug reports, but I do not yet recommend you use it for mission critical tasks. I personally use it in production but then I'm a daring fellow.

INSTALL

sudo gem install god

note: currently tested only on Redhat Linux and Darwin (won't work on Windows)

FEATURES

Config file is written in Ruby
Easily write your own custom conditions in Ruby
Supports both poll and event based conditions
Different poll conditions can have different intervals

EXAMPLE

The easiest way to understand how god will make your life better is by looking at a sample config file. The following configuration file is what I use at gravatar.com to keep the mongrels running:

# file:      gravatar.god
# run with:  god start -c /path/to/gravatar.god
#
# This is the actual config file used to keep the mongrels of
# gravatar.com running.

RAILS_ROOT = "/var/www/gravatar2/current"

God.meddle do |god|
  %w{8200 8201 8202}.each do |port|
    god.watch do |w|
      w.name = "gravatar2-mongrel-#{port}"
      w.interval = 30 # seconds
      w.start = "mongrel_rails cluster::start --only #{port} \
        -C #{RAILS_ROOT}/config/mongrel_cluster.yml"
      w.stop = "mongrel_rails cluster::stop --only #{port} \
        -C #{RAILS_ROOT}/config/mongrel_cluster.yml"
      w.grace = 10 # seconds
      
      pid_file = File.join(RAILS_ROOT, "log/mongrel.#{port}.pid")
      
      w.behavior(:clean_pid_file) do |b|
        b.pid_file = pid_file
      end

      w.start_if do |start|
        start.condition(:process_not_running) do |c|
          c.interval = 5 # seconds
          c.pid_file = pid_file
        end
      end
      
      w.restart_if do |restart|
        restart.condition(:memory_usage) do |c|
          c.pid_file = pid_file
          c.above = (150 * 1024) # 150mb
          c.times = [3, 5] # 3 out of 5 intervals
        end
      
        restart.condition(:cpu_usage) do |c|
          c.pid_file = pid_file
          c.above = 50 # percent
          c.times = 5
        end
      end
    end
  end
end

DOCS

Detailed documentation is available at http://god.rubyforge.org/

CHANGES

== 0.1.0 / 2007-07-07

1 major enhancement
- Birthday!

AUTHOR

Tom Preston-Werner

Disable STDOUT for tests

2007-06-26T23:48:00Z

I write a lot of command line tools at Powerset, so I need to output status messages to the console while code is executing. Big deal, right? Well, it becomes a big deal once you run your test suite and you've got two hundred lines of status messages mixed in with the normal test output. I don't need to see console output during my tests. Here's a little method that will disable output to STDOUT for the duration of the block that it's given:

def no_stdout
 old_stdout = $stdout
 $stdout.reopen(File.open((PLATFORM =~ /mswin/ ? "NUL" : "/dev/null"), 'w'))
 yield
 $stdout = old_stdout
end

In your test, you'd call it like this:

def test_whatever
  no_stdout do
    puts 'no one will ever see this'
  end
end

This technique also works well for 3rd party libraries that might send some output to STDOUT that you don't want to see.

Sometimes, when I have a lot of output I need to do, I'll wrap puts and print in my own methods and call those from my code. This also allows me to add a $stdout.flush to make sure that the output is sent to the terminal immediately (some systems will buffer output up to a certain size, making those little progress meters useless):

class Base
  def out(text = '')
    print text
    $stdout.flush
  end

  def outs(text = '')
    out(text + "\n")
  end
end

Now instead of using the no_stdout method from above, I can simply redefine those methods to do nothing and all my output vanishes!

1234	class Base def out(x); end def outs(x); endend

Don't settle for crufty test output. We have the technology!

Fuzed (Rails on YAWS)

2007-05-24T17:57:00Z

Dave Fayram and I started working on a new deployment option for Rails last week and had something to show off at RailsConf. If you're into Erlang, you'll immediately see the awesomeness that can come out of putting a connection pool of Rails instances (just Rails, no mongrels) behind YAWS, the pure Erlang web server.

We showed this sucker off at RejectConf and Geoff Grosenbach was kind enough to record it, so here's the audio for your pre-alpha enjoyment!

Fuzed @ RejectConf Audio

You'll be seeing much much more about this project in the coming weeks. It's gonna be sweet!

Daemonizing Ruby Scripts for Monit

2007-05-06T11:24:00Z

Monit is a very useful, if not occasionally frustrating tool for monitoring processes on a server. Many of you have probably used monit to keep your mongrel clusters up and running. Monit plays well with anything that has built in deamonization, but if you have a plain old Ruby script (to do file cleanups, synchronizations, or whatnot), you'll find that monit leaves you out to dry.

Luckily, there's a nice gem called daemons that makes it dead simple to daemonize your Ruby scripts. Once you've daemonized a script, you can start, stop, and restart it by calling the script with one of those commands as the first argument. It takes care of writing out a PID file and redirecting STDOUT to a logfile.

One very useful thing I needed to do was daemonize a Camping app, and since Camping doesn't have a -d option yet (hopefully someday it will), it's up to us to add that functionality. Let's see just how easy it is to write a control file for a Camping app. Here's a file named campyctl.rb:

#!/usr/local/lib/ruby
require 'rubygems'
require 'daemons'

Daemons.run('/var/www/campy/campy.rb',
            {:mode => :exec,
             :dir => '/var/www/campy/',
             :dir_mode => :normal,
             :log_output => true,
             :app_name => 'campy'})

Now we can call campyctl.rb start to fire up the camping app. Doing so will also give us a file called campy.pid that will contain the PID of the Ruby process that's running Camping, and a campy.log file with the redirected STDOUT. With a true daemon in place, we can easily set up monit to keep an eye on the process and issue a start command if it goes down!

If you need daemon functionality, totally check out daemons. In addition to the control file paradigm above it offers several other ways to daemonize your code. Great stuff, and a huge timesaver!

Multi-Site Mephisto Apache 2.2 Config

2007-05-01T19:19:00Z

Mephisto truly is a wonderful piece of weblog/cms software. It's even more powerful in multi-site mode, where you can have completely separate blog instances running under a single installation. Doing this, however, requires a fair bit of RewriteRule magic in your Apache configuration. Crafting large sets of Apache rewrite rules is a very exacting science. One which I do not relish having to do more than once for a given set of behaviors. And so, to alleviate the pain for my future self and others, I present a full virtual host configuration suitable for use with Apache 2.2 and mod_proxy_balancer with a cluster of Mongrels.

This config is for two sites: example.com and blog.example.com. Because of the way Mephisto stores cached pages, all requests to www.example.com are redirected to example.com (no www). This is wise in general. It proxies requests to a cluster of three mongrels.

<VirtualHost *:80>
  ServerName www.example.com
  ServerAlias example.com
  ServerAlias blog.example.com

  # admin's email
  ServerAdmin awesome@example.com

  # paths
  DocumentRoot /var/www/example/current/public
  ErrorLog /var/www/example/current/log/error_log
  CustomLog /var/www/example/current/log/access_log combined

  ServerSignature On

  RewriteEngine On

  # no-www
  RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
  RewriteRule (.*) http://example.com$1 [L,R=301]
  
  # Don't redirect /admin*. Send it directly to rails. 
  RewriteCond %{REQUEST_URI} ^/admin.* 
  RewriteRule ^/(.*)$ balancer://example_cluster%{REQUEST_URI} [P,QSA,L]

  # Basic content redirection
  RewriteCond %{DOCUMENT_ROOT}/cache/%{HTTP_HOST}/index.html -f
  RewriteRule ^/?$ /cache/%{HTTP_HOST}/index.html [QSA,L]
  
  RewriteCond %{REQUEST_URI} !.*/mephisto/.*
  RewriteCond %{DOCUMENT_ROOT}/cache/%{HTTP_HOST}/$1.html -f
  RewriteRule ^/([^.]+)$ /cache/%{HTTP_HOST}/$1.html [QSA,L]

  # asset redirection 
  RewriteCond %{REQUEST_FILENAME} /assets/.* 
  RewriteCond %{REQUEST_FILENAME} !-f 
  RewriteRule ^/(assets)(.*)$ /assets/%{HTTP_HOST}/$2 [QSA,L]

  # other redirection (imgs, js, css, ...) 
  RewriteCond %{REQUEST_FILENAME} !-f 
  RewriteCond %{REQUEST_URI} !.*/mephisto/.* 
  RewriteCond %{REQUEST_URI} !.*html 
  RewriteCond %{REQUEST_URI} !^/cache
  RewriteCond %{DOCUMENT_ROOT}/cache/%{HTTP_HOST}/$1 -f
  RewriteRule ^/(.*)$ /cache/%{HTTP_HOST}/$1 [QSA,L]

  # Redirect all non-static requests to cluster
  RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
  RewriteRule ^/(.*)$ balancer://example_cluster%{REQUEST_URI} [P,QSA,L]

  # Rewrite debugging
  # RewriteLogLevel 4
  # RewriteLog "/var/www/example/current/log/rewrite.log"
  
  # Error pages
  ErrorDocument 503 /503.html

  # Proxy setup
  <Proxy balancer://example_cluster>
    BalancerMember http://127.0.0.1:5000
    BalancerMember http://127.0.0.1:5001
    BalancerMember http://127.0.0.1:5002
  </Proxy>

  ProxyPreserveHost On
</VirtualHost>

Based loosely on the config from the Mephisto Wiki.

Calling Erlang from Ruby (Teaser)

2007-04-30T04:48:00Z

With Moore's Law about to crumble from beneath our feet, we all need to start thinking about how to make use of those 64 core processors we'll be rockin' in our laptops in a few years. Ruby is an amazing language for many tasks, but sadly concurrent programming is not one of them. In preparation for the future I could consider dropping Ruby altogether and find another more appropriate language. But that would be madness. Ruby is awesome. What if I could still write the bulk of my projects in Ruby, but farm out the threaded stuff to the concurrency mercenary that is Erlang? That would be cool, right?

Consider a small Erlang module:

-module(funs).
-export([add/2, cat/2, fac/1]).

add(A, B) ->
  A + B.
  
cat(A, B) ->
  A ++ B.
  
fac(N) ->
  fac(1, N).
  
fac(Memo, 0) ->
  Memo;
fac(Memo, N) ->
  fac(Memo * N, N - 1).

I'd like to be able to call these Erlang functions from my Ruby code without a lot of fuss. Hmm, how's this for a low-fuss approach:

require 'rebar'

funs = Rebar::Erlang.new(:funs, '127.0.0.1', 5500)

funs.add(1, 2)
# => 3

funs.cat("foo", "bar")
# => "foobar"

funs.fac(10)
# => 3628800

Wow, that would be nice. Good thing I just spent the last two days writing some code to make it a reality!

The library is called Rebar (Ruby to Erlang Bridge And Runner). Rebar has two parts: an Erlang server and a Ruby client. The server listens for JSON-RPC requests, calls the specified Erlang function, and responds with a JSON-RPC response. The Ruby client object simply accepts any method name, captures it with method_missing, wraps everything up in a JSON-RPC request, fires it off, waits for the response, and then extracts the result out of the JSON-RPC response, returning it like a normal Ruby call.

It's still too hackish to release, but with some error handling and robustification, it'll be all good. If you'd like to help out with Rebar, you just let me know.

Rubinius Hacking with Evan Phoenix

2007-04-23T06:40:00Z

After the Silicon Valley Ruby Conference ended today, a few of us gathered up at my place to hack on Rubinius while Evan was around. I think I've got enough of a feel for Rubinius now that I can make some meaningful contributions. I want to flesh out the Time class in preparation for my work on BigTime. A huge thanks to Evan and all the Rubinius guys for what looks to be an extremely promising project. I can't wait to get to know it better.

Clockwise from the left: Josh Susser, Ezra Zygmuntowicz, Kevin Clark, Kyle Maxwell, Chris Wanstrath, and Evan Phoenix.