From my coworker Ryan, while I was complaining about figuring out yet another DSL in Rails (YADSLIR?):

When you're working with Rails, you don't just get to experience the pleasure of using Ruby, you also get to experience the pleasure of learning 40 fucking different DSLs on top of it

I have been corrupted by JavaScript. Ruby really annoyed me when I could not just add properties and functions totally willy-nilly to instances. Ruby makes it easy to reopen classes, or even instances, but it is not so obvious how to do so without creating a new scope (and hence losing your closure).

The ~standared mechanism is to do something vicious like this:

foo = "hello"
msg = "woot!"
class< "woot!"

Aside from the fact that this is a vicious hack, it relies on the fact that send lets you invoke private methods (define_method) on the singleton class (more recently going by the alias of eigenclass) of foo. This is pretty much a bug and a violation of the object. It's like object rape, or something.

A nicer way to do it, to my mind, is to use anonymous modules. The really nice part of using anonymous modules is that the Module constructor takes a block which is evaluated in the context of the new module, letting you legally call private methods, like define_method.

moo = "TOOW!"
foo.extend(Module.new { attr_accessor :baz })

foo.extend(Module.new { define_method(:toow) { puts moo }} )

foo.baz = 7
foo.toow # => "TOOW!"

moo = "MOOO!!"

foo.toow # => "MOOO!!"

This has the same effect and no nasty exploitation of the send bug!

Of course, with javascript, it is just...

foo = "woot"
foo.bar = 7
foo.stuff = function(a, b, c) { a * b * c }

I still like ruby more, though ;-)

After the Silicon Valley Ruby Conference I wanted to hack some at a declarative language for web service orchestration. Tests pass, but the web service bindings don't exist yet =( Right now it can be used as a nice declarative process for... er, ruby?

class TestProcess < Test::Unit::TestCase
  
  def test_example
    p = Processor::process :wombats do
      receive :message

      forward :message, :to => :provisioning, 
                        :save_reply => :provision_response
            
      forward :message, :to => :payroll
      
      if_test( proc { provision_response =~ /example/ } ) do
        transform :message, :with => :some_transformer,
                            :save_in => :transformed_message

        forward :transformed_message, :to => :server_group    
      end
                            
      forward :provision_response, :to => :helpdesk
    end    

The rest of the test case just mocks out the services needed and tests that the things works. Not as exciting but here it is for completeness =)

  
    p.services[:provisioning] = lambda do |process, msg| 
      @provision_msg = msg 
      assert process.expecting_response?
      "address@example.com"
    end
    
    p.services[:payroll] = lambda do |process, msg|
      @payroll_msg = msg
    end
    
    p.services[:server_group] = lambda do |process, msg| 
      @server_group_msg = msg
    end
    
    p.services[:helpdesk] = lambda do |process, msg|
      process.suspend
    end
    
    msg = OpenStruct.new
    
    p.start msg
    
    assert_equal @provision_msg, msg    
    assert_equal @payroll_msg, msg
    assert_equal @server_group_msg, "address@example.com"
    assert_equal p.transformed_msg, "address@example.com"
    assert p.suspended?
    
    p.resume "back from helpdesk"
    
    assert p.completed?
  end
end

For the most part I am kind of happy with it. The nasty wart of

if_test( proc { provision_response =~ /example/ } ) do
  transform :message, :with => :some_transformer,
                      :save_in => :transformed_message

  forward :transformed_message, :to => :server_group    
end

annoys me. It's needed to lazily evaluate the construct, using a real if there evaluates it at the wrong time. Astute code readers will also notice I am not testing the transform. Haven't done that yet -- will probably remove it as a first class concept if I do anything more with the code, a transform is just a local service, and services are all wrapped in ruby methods, so instead of importing the service, just provide the transform and voila, your toast is burnt.

Wish ruby continuations were migratable/serializable.

So, ruby threads have issues. Multiprocessing, on the other hand, works great. I have been doing stuff like:

#!/usr/bin/env ruby

require 'drb'
URI = "drbunix:///tmp/foopie"

class Master
    def initialize(count=100)
        @jobs = []
        count.times do |i|
            @jobs << "Job ##{i}"
        end
    end
    
    def take(n)
      taken = []
      while taken.length < n && !@jobs.empty?
        taken << @jobs.shift
      end
      taken
    end
end

DRb.start_service URI, Master.new

pids = []
10.times do |i|
    pids << fork do
        DRb.start_service
        master = DRbObject.new_with_uri URI
        until (jobs = master.take(2)).empty?
          jobs.each do |j| 
            puts j
            sleep rand
          end
        end
    end
end

puts "started children" 
pids.each { |pid| Process.wait(pid) }

To slam though jobs in ruby. Doing it over unix sockets instead of tcp is just nicer =) It just spreads the workload across processes instead of threads.

So, it is right in the docs, but somehow I overlooked it... You can do DRb over unix sockets dirt easily =)

require 'drb'

class Logger
  def log m
    puts m
  end
end

DRb.start_service "drbunix:///tmp/logger", Logger.new

Note the URI.

require 'drb'

DRb.start_service

logger = DRbObject.new_with_uri "drbunix:///tmp/logger"

logger.log "Woot!"

=)

Chris Petrilli writes what I think is an insightful post on getting things done in a software project. An underlying issue – though not really stated outright – is the whole Java/J2EE vs. Ruby/Rails debate that will never really have an end.

But I think his most salient points transcend language wars and hit on some key issues.

If you deliver an “enterprise solution” in 2 years, and I deliver what you degrade as a “non-enterprise solution” next week, whose solution do you think earns more money for the organization? Who do you think abates the costs faster? Most importantly, who do you think learns where the mistakes are and the real requirements exist.

It’s all about making software that works and is delivered on time. If I get that done, maybe I can have some money in the budget to scale it if I need to. But so much is really unknown, and to act as though you can actually forsee the future is sometimes a fools folly.

Not all problems are knowable. Until you accept this perspective, you will continually pursue the perfect to the deficit of the good.

Until then, I plan on testing first, taking small steps, and delivering something that works every couple of weeks.

So, Martin released a first showing at his wicked cool Atom binding library for ruby:

require 'atom'
require 'net/http'
require 'uri'

str = Net::HTTP::get(URI::parse('http://blog.ning.com/atom.xml'))
feed = Atom::Feed.new(str)

feed.entries.each { |entry|
  puts "'#{entry.title}' by #{entry.authors.first.name}"
}

I like this example more, though ;-)

Meanwhile, Obie apparently leaked ActiveMessagingM-Del a13g. Woot! It's good to see Stomp getting wider usage.

class HelloWorldProcessor < ActiveMessaging::Processor
 
 subscribes_to :hello_world
 publishes_to :hello_world
 
 def on_message(message)
   puts "received: " + message.body
   publish :message => "Hello world!"
 end
 
end

Cool stuff all around!