At eComm Jeevan and I heard some intriguing stuff about a service called Tropo, a cloud-based scriptable VOIP system designed to let web hackers start working in the voice and telephony world.

The app provides a pretty damn slick interface to quickly set up a real phone number (plus SIP plus Skype, all in one place), then assign it to a script written in javascript, groovy, python, ruby, or probably whatever other BSF language they support.

Here’s one I wrote and deployed in about 20 minutes to read off all the Miniature Monster descriptions from the RSS feed (Tropo calls highlighted). You can test it out by calling (650) 273-5382 (or +99000936 9991428654 on Skype, though I haven’t tried that):

require 'net/http'
require 'rexml/document'

answer
wait(3000)
say "hello, welcome to professor engd's miniature monster hotline. here are your monster updates."
wait(1000)

url = "http://feedproxy.google.com/miniaturemonsters"
xml_data = Net::HTTP.get_response(URI.parse(url)).body
xml_doc = REXML::Document.new(xml_data)

xml_doc.elements.to_a( "//description" ).reverse.each do |desc|
  if (m = (/\<div id=\"description\">\s*\<em\>(.*?)\<\/em\>\<\/div\>/i).match(desc.text))
    say m[1]
    wait(1000)
  end
end

hangup

I’ve worked on some projects recently involving Asterisk-to-web-to-hardware style hacking, typically using something like Gizmo to register a regular phone number assigned to a SIP number, then setting up asterisk as the SIP softphone and messing around with a retarded dialplan syntax to get things going. Tropo seems to simplify all that… substantially.

The documentation is solid if a little thin, but it’s so new, and the app is so slick and well done, so I’m sure there’s more coming. It’s unclear at this point which Ruby libraries and gems they support, if any. And it all feels a little like a toy, but no more than, say, Google App Engine, and for me it’s actually more potentially useful. What I can say at this point is that it’s a solid way to sketch your telelphony ideas quickly and with zero setup time, which is very cool. Are you listening ITP?

Anyway, happy voip hacking.

Tired of stepping over homeless people on your way to bikram? Jonesing for a Yacon Root smoothie? Gentrify helps the elite urban bourgeois find their natural habitats.

Gentrify is currently in alpha lite preview stealth mode edition. Created for Rails Rumble ‘08 by 734m: Huned Botee, Brent Fitzgerald, Visnu Pitiyanuvath, and Gerad Suyderhoud.

Breach and Success

There are two reserved methods: breach and success. Each takes an optional message parameter. Your code defines the conditions under which the promise breaches or succeeds. For example, a really simply promise would be:

if condition_x
  success "it happened!"
end

The value of the condition_x variable determines whether the promise evaluates to success. When condition_x evaluates to true, the promise will be evaluated as a success, with corresponding message “it happened!”. A marginally more sophisticated promise might look like this:

if condition_x
  success "x happened!"
elsif condition_y
  breach "sorry, y happened"
end

In this one we have possibility of a breach as well, if condition_y evaluates to true.

Promise State

Those variables like condition_x and condition_y aren’t defined anywhere in this code. This means that they are free variables.

All these free variables in your promise code are extracted as you write the promise, and together form the state of the promise. When writing the promise, you can change the values of these variables to the desired initial state. Once published and signed, all participants can also change the values of these variables.

Time

Most promises are commitments with respect to some future action or event. So it may make sense to take time into account.

if document_received
  success "thanks, nice work"
elsif  Time.now > document_deadline
  breach "missed the deadline
end

Again, document_deadline and document_received become promise state variables, meaning they can be changed by the participants. If we wanted to fix the deadline and remove it from the state, we could simply add in a line.

document_deadline = Time.parse("5/11/2007 6:00pm")
if document_received
  success "thanks, nice work"
elsif  Time.now > document_deadline
  breach "missed the deadline
end

Keep in mind that Time.now evaluates differently each time the promise is evaluated. Future versions of Promiserver will have a timeline or calendar view, to try out the code for different times in the future.

Ruby Niceness

Since we’re using Ruby with some special activesupport magic, we can use some cool shortcuts. For example, say we want to allow for an extension:

...
if Time.now > (final_date = deadline + extension.days)
  breach "missed the extended deadline #{final_date}"
end
...

This is just a starting point. I have a few people using the system now, and in particular Burak has been a great tester, authoring some promises that have pushed Promiserver a little our of its comfort zone. So we’ll see how this contract-as-code idea continues to develop.

Check it out: promise.media.mit.edu. Borrowing the slogan from OpenCode, This is so alpha, you won’t even want to use it™

Well, it’s been a while coming, and now I have a super alpha version of Promiserver live and ready for you to make all your programmed commitments with that same desperate, wanton abandon we saw in the early field tests. It’s got bugs aplenty, as well as interface problems, but I can fix em as we find em. Tags coming soon, plus REST API for creating promises programmatically, which is where I think a lot of the applications will be. A lot of other updates too, providing I have enough time given this whole writing ordeal I’m still in the middle of (sigh).

Forever alpha at http://tiny.media.mit.edu/

The excitement will really never end. There are 2^169 possible images! Thanks to Amber for the original inspiration with her Mini app for OS.

module Friendly

  def method_missing name
    @_new_methods ||= Hash.new
    unless @_new_methods.has_key? name
      prompt_for_definition name
    end
    eval @_new_methods[name]
  end

  def prompt_for_definition name
    puts "It appears that #{name} is undefined."
    puts "Please define what I should do (end with a blankline):"
    @_new_methods[name] = ""
    while $stdin.gets !~ /^\s*$/
      @_new_methods[name] << $_
    end
  end

  def added_methods
    @_new_methods.keys
  end

  def added_method_definitions
    @_new_methods.map {|k,v|
      s = "def #{k}\n  "
      v.rstrip!
      s << v.gsub("\n", "\n  ")
      s << "\nend"
    }
  end

end

Example usage, in this case just using Friendly to extend the top level object:

irb(main):001:0> include Friendly
=> Object
irb(main):002:0> foo = bar * z
It appears that bar is undefined.
Please define what I should do (end with a blankline):
12

It appears that z is undefined.
Please define what I should do (end with a blankline):
4

=> 48
irb(main):003:0> foo
=> 48
irb(main):004:0> bar
=> 12
irb(main):005:0> z
=> 4
irb(main):006:0> added_methods
=> [:z, :bar]
irb(main):007:0> puts added_method_definitions.join("\n\n")
def z
  4
end

def bar
  12
end
=> nil
irb(main):008:0>

./script/plugin discover \
   http://plw.media.mit.edu:9090/repository/public/rails/plugins
./script/plugin install -x acts_as_permalinkable
./script/generate permalinkable_migration
rake migrate

Then just add the acts_as_permalinkable snippet to your models:

class Article < ActiveRecord::Base
  acts_as_permalinkable
  ...
end

class Photo < ActiveRecord::Base
  acts_as_permalinkable
  ...
end

When you save your model the permalink will automatically update as well. By default it uses a title attribute to create the slug and the created_on attribute for the date, but this is easily customized. For example to use it with the name attribute and the updated_at attribute:

  acts_as_permalinkable \:on => :name,
                         :use_date => :updated_at

You can also provide a Proc that filters the permalinkable title field before it is turned into a slug. For example maybe you want to strip the tags and only take the first 20 characters:

  acts_as_permalinkable \:on => :content,
      :slug_modifier => lambda { |x|
             x.gsub(/\<.+?\>/, "").strip[0..20]
          }

Within your views you can link to the permalinks with a few url helper methods, url_for_permalink and link_to_permalink:

<%= url_for_permalink @article,
    {:action => "permalink"},
    {:class => "permalink",
     :title => "Permalink for '#{@article.title}'"}
%>

<%= link_to_permalink "permalink", @article,
    {:action => "permalink"},
    {:class => "permalink",
     :title => "Permalink for '#{@article.title}'"}
%>

And within your controller just use the find_permalinked method:

find_permalinked :slug => "this-is-a-slug",
    :year => 2006,
    :month => 8,
    :day => 7

Underspecifying these parameters will return a collection for all matching records. Or if your parameters already have these values it is pretty easy:

find_permalinked params

You can add permalinks to existing records with the create_all_slugs singleton method. I use the console. For example, with an Article model:

Article.create_all_slugs

Hope it works out to be helpful for at least a few people out there.

If we’re using a before_invocation interceptor, like say for authentication, we can clean things up by creating a subclass of ActionWebService::Base that includes the authentication method:

app/apis/authenticated_web_service.rb

class AuthenticatedWebService < ActionWebService::Base
  def authenticate name, args
    @authenticated_user = User.find_by_login args[0]
    unless @authenticated_user.authenticated?(args[1])
      raise "Not authenticated"
    end
  end
end

Because we are actually using an instance variable here, @authenticated_user, we have to set up our layered web service controller to use instances of the services rather than the classes.

app/controllers/services_controller.rb

class ServicesController < ApplicationController
  web_service_dispatching_mode :layered
  wsdl_service_name 'contract_services'
  web_service_scaffold :invoke

  # Here we use instances...
  web_service(:contract) {ContractService.new}
  web_service(:account) {AccountService.new}

  # rather than classes...
  # web_service :contract, ContractService
  # web_service :account, AccountService
end

Then your various services can inherit from this "abstract" AuthenticatedWebService. Each can make use of the authenticate method and the @authenticated_user variable.

app/apis/contract_service.rb

class ContractApi < ActionWebService::API::Base

  api_method :all,
             :returns => [[Contract]]
  api_method :new,
             :expects => [{:login => :string},
                          {:password => :string},
                          {:description => :string}],
             :returns => [Contract]
end

class ContractService < AuthenticatedWebService
  web_service_api ContractApi

  def all
    Contract.find :all
  end

  def find contract_id
    c = Contract.find(contract_id)
    raise "Contract not found." if c.nil?
    c
  end

  ## Authenticated API Methods
  before_invocation :authenticate, \:only => [:new]

  def new l, p, description
    c = Contract.new :creator => @authenticated_user,
                     :description => description
    c.save!
    c
  end
end

Once your service is put together, keep in mind that XML-RPC requests will use a method of the form service.method. So for example, my contract service's find method is contract.find. I have to admit that this really threw me off for a little while when I was testing out the API in XML-RPC Client and I kept getting back a "no such web service 'api'" error message. The manual does point this out, but I missed it the first time, and only on a close reread did I figure this out, at which point I realized how much good sense this approach makes. Note that for SOAP requests the service API is encoded in the header.

One more final note is that Rails logger object is not available in the layered services. This could be a deal breaker in certain cases.

The biggest stumbling block in my Cocoa experience has been Interface Builder. I know it is supposed to be easy and elegant. But I’ve been suspicious, and consequently hesitant to really get into it. Along with other Apple systems like WebObjects and Quartz Composer, it requires aquisition of knowledge that is essentially non-transferable. Learning how to visually connect these specific little icons, widgets and outlets just isn’t going to help me in any other system. It is abstracted to the point of simulation, and learning the rules of the system involves little knowledge of the inner workings. It reminds me of the tension Sherry Turkle noted in the introduction to the new edition of The Second Self:

The aesthetic of transparency (common to the Logo movement and the early generations of personal computer hobbyists) carried with it a political aesthetic that was tied both to authorship and to knowing how things worked on a level of considerable detail. There is a kind of understanding that is not communicated by playing off-the-shelf simulations (p13).

Turkle is concerned that the increasing opacity in modern software and systems is leading to a new type of illiteracy within the emerging generation:

…as I meet professional in all of these fields who move easily within their computational systems and yet feel constrained by them, trapped by their systems’ unseen and unknown assumptions, I feel continued concern. Are the new generation of simulation consumers reminiscent of people who can pronounce the words in a book but don’t understand what they mean? (p14).

Yet I’m giving in. After investing only a few days I’m realizing how Interface Builder takes care of many parts of the application that I don’t ever want to handle myself. The abstraction is easier, simpler, and it saves me time, leaving room in my brain for other problems and puzzles. Turkle’s concerns are understandable, and to some extend I share them, yet I wonder whether it is in part nostalgia for an aethetic that is only interesting now that it is so obviously impossible (in a recent talk my colleague and friend Jeevan elaborated on the connection between simplicity and nostalgia for a simple past).

Maybe it is this tension between opaque abstraction versus transparent details that makes for good design. Which details do we choose to hide by assuming defaults? Which details do we conflate versus keep separate? Which details to we expose? As the abstraction increases, the gap between the two increases as well. Finding the balance is harder, yet also much more important.

#!/usr/bin/env ruby

def center_str s, len
  n = (len - s.length) / 2.0
  ' '*(n.floor) + s + ' '*(n.ceil)
end

n = ARGV[0].to_i
rows = [[1]]
for i in 1..(n-1)
  k = -1; r = rows[i-1] + [0]
  rows << r.map{ |x| j = k; k+=1; x + r[j] }
end
m = rows.last[n/2].to_s.length * 2
n = n * m
rows.each do |r|
  puts center_str(r.collect{|x| center_str(x.to_s, m)}.join, n)
end

Sample output:

                             1
                          1     1
                       1     2     1
                    1     3     3     1
                 1     4     6     4     1
              1     5     10    10    5     1
           1     6     15    20    15    6     1
        1     7     21    35    35    21    7     1
     1     8     28    56    70    56    28    8     1
  1     9     36    84   126   126    84    36    9     1