Posted by Eric Kidd
Sat, 21 Nov 2009 23:35:00 GMT
I’m currently attending the Wave hackathon at the Massachusetts GTUG. Here’s some code from a protocol-level Wave agent that I just demoed:
replace /\b(random|words)\b/i do |word|
word.upcase
end
replace /\bhttp:\/\/([^ ]+)/ do |url|
$bitly.shorten(url).short_url
end
In keeping with the traditions of hackathons, this agent is horribly fragile. It only works with FedOne’s console-based wave client, and it doesn’t handle annotations correctly.
Some earlier—and more robust—wave-related projects:
- Pick Several: A gadget which implements approval voting. Written using GWT. Includes a reusable library for writing GWT-based wave gadgets.
- BugLinky: A robot which links bug numbers to a bug tracker. Includes a reusable library for simple pattern-matching, text replacement and annotation.
Many thanks to GTUG and to Google for organizing this hackathon!
Tags Ruby, Wave
Posted by Eric Kidd
Fri, 08 May 2009 18:06:00 GMT
Have you ever considered using instant messages to communicate between programs? You can do this using Jabber’s XMPP protocol, of course. But it’s also worth taking a look at AMQP, a distributed messaging protocol first used at JPMorgan Chase. AMQP is fast, easy to use, and implemented by at least 4 open source servers.
To try it out, install the excellent Ruby AMQP bindings, and set up the RabbitMQ server (which is written in Erlang using Mnesia). On a Mac, you might do something like this:
sudo gem install amqp
sudo port install python25 rabbitmq-server
sudo rabbitmq-server
Once your server is running, save the following code as chat.rb:
require 'rubygems'
gem 'amqp'
require 'mq'
unless ARGV.length == 2
STDERR.puts "Usage: #{$0} <channel> <nick>"
exit 1
end
$channel, $nick = ARGV
AMQP.start(:host => 'localhost') do
$chat = MQ.topic('chat')
queue = MQ.queue($nick)
queue.bind('chat', :key => $channel)
queue.subscribe do |msg|
if msg.index("#{$nick}:") != 0
puts msg
end
end
module KeyboardInput
include EM::Protocols::LineText2
def receive_line data
$chat.publish("#{$nick}: #{data}",
:routing_key => $channel)
end
end
EM.open_keyboard(KeyboardInput)
end
Now, run copies in two different terminals:
ruby chat.rb channel_1 sarah
ruby chat.rb channel_1 joe
Everything you type into one terminal will be relayed to the other.
How it works
The following line creates a topic exchange named “chat”:
A topic exchange allows many-to-many communication. Here, we bind a listener to our exchange, and ask to receive all messages tagged with our channel name:
queue.bind('chat', :key => $channel)
Note that :key may be hierarchical, and it may contain wildcards. To write data to our topic exchange, we use publish:
$chat.publish("#{$nick}: #{data}",
:routing_key => $channel)
Our keyboard input is processed using EventMachine, a Ruby library for writing high-performance, multi-protocol servers. It’s very similar to Python’s Twisted library, though it has less documentation and support for fewer protocols.
We use EventMachine’s EM.open_keyboard to create a asynchronous keyboard input channel, and we use EM::Protocols::LineText2 to treat the keyboard input as a line-oriented protocol.
Adding a Shoes GUI
Shoes is an eccentric, entertaining, and highly-portable GUI library by _why the lucky stiff. With a certain amount of grotesque kludging (and some pointers from “s1kx” on the #shoes IRC channel), I managed to get the Mac version of Shoes to talk to EventMachine. You may find that this code fails strangely on your computer. Honestly, I don’t know anything about Shoes. And I’m doing some pretty bad things with threads.
First, the pretty pictures:
Next, the code:
Shoes.setup { gem 'amqp' }
require 'mq'
$app = Shoes.app(:width => 256) do
background(gradient('#CFF', '#FFF'))
@output = stack(:margin => 10)
def nick str
span(str, :stroke => red)
end
def display text
@output.append do
if text =~ /^([^:]+): (.*)$/
para nick("#{$1}: "), $2
else
para text
end
end
end
end
Thread.new do
begin
AMQP.start(:host => 'localhost') do
MQ.topic('chat')
queue = MQ.queue('shoes')
queue.bind('chat')
queue.subscribe do |msg|
$app.display(msg)
end
end
rescue => e
$app.display(e.to_s)
end
end
Note that the GUI client listens to all channels simultaneously, because it doesn’t pass a :key to bind. And when writing code to run in a Shoes background thread, don’t expect to see any error messages.
Learning more about AMQP
The Ruby AMQP documentation page has a good list of papers, magazine articles, and other background material on AMQP.
Tags AMQP, EventMachine, MQ, Ruby, Shoes
Posted by Eric Kidd
Thu, 30 Apr 2009 15:07:00 GMT
Over the last couple of years, I’ve occasionally written Ruby programs using RSpec and (more recently) Cucumber. These two tools are inspired by Test Driven Development (TDD), a school of thought which says you should write unit tests before implementing a feature.
When doing TDD, you work inwards from the interface to the implementation. You start by writing a test case against the interface you wish you had, and then you make that test case work. This is a subtle shift in how you approach a design problem, but it frequently results in beautiful APIs. (And you also get a fully automated test suite for your software, liberating you to make much larger changes without fear of breaking things.)
The problem with the word “test”
Unfortunately, the name “Test Driven Development” is misleading. Most folks think of “testing” as something you do after development is complete. But TDD is really more of a design activity—you’re specifying how your APIs should work before you actually start coding.
Dan North spent some time struggling to teach developers about TDD. After a while, he decided that the main barrier to understanding was the word “test.” He proposed replacing TDD with Behavior Driven Development (BDD), and he started referring to unit tests as “specifications.”
In the Ruby community, the most popular BDD tool is RSpec. Using RSpec, you might specify an API something like this:
describe "simplify_name" do
it "should convert all letters to lowercase" do
simplify_name("AbC").should == "abc"
end
it "should remove everything but letters and spaces" do
simplify_name(" Joe Smith 3 -+\n").should == "joe smith"
end
end
After writing this specification, you would then go ahead and implement simplify_name. And from then on, whenever you changed your program, you could automatically check it against this specification.
Using specifications to communicate with clients and users
By itself, RSpec is mostly useful for programmers. Sure, a specification looks a lot like English. But would you really want to show it to an end user?
Cucumber goes one step further. Instead of using code to specify how an API should work, it uses plain text to describe how a user interface should work. For example:
Feature: Log in and out
As an administrator
I want to restrict access to certain portions of my site
In order to prevent users from changing the content
Scenario: Logging in
Given I am not logged in as an administrator
When I go to the administrative page
And I fill in the fields
| Username | admin |
| Password | secret |
And I press "Log in"
Then I should be on the administrative page
And I should see "Log out"
Scenario: Logging out
...
Here’s the neat part: This specification is actually an executable program. Each line of text corresponds to a “step”, which is defined in another file. Here’s an example from the standard webrat_steps.rb file:
Then /^I should see "([^\"]*)"$/ do |text|
response.should contain(text)
end
Cucumber encourages you to think at a very high level, and to specify how different users will actually use your software. It’s particularly helpful if you need to communicate between programmers and end-users.
My experiences with RSpec and Cucumber
I’ve been using RSpec on and off for a couple of years now, and Cucumber since late last year. Initially, I found both tools fascinating, but also a bit frustrating. Both RSpec and Cucumber have very strong opinions about how you should write software. Now, I found those opinions very interesting, and I was quite happy to be influenced by the assumptions built into the tools. But every now and then, I would need to do something that the authors of RSpec and Cucumber hadn’t anticipated, and I would inevitably wind up struggling to make things work.
But recent versions of RSpec and Cucumber are richer and more flexible. They cover more important cases straight out of the box, and they’re easier to customize. So I can finally recommend both tools for real-world projects: They’ll still guide your thinking, but they should give you enough flexibility to handle the corner-cases.
The RSpec (and Cucumber) book
Unfortunately, the documentation for RSpec and Cucumber is scattered around the web, and there aren’t enough online guides showing the best way to solve common problems.
But the Pragmatic Press is working on The RSpec Book, which contains a large section on Cucumber, and a walkthrough of a typical development session using Cucumber and RSpec.
Currently, the RSpec book is available as a “beta book”. This is a downloadable, DRM-free PDF, with periodic updates throughout the publishing process. Right now, between one-third and one-half of the chapters have been roughed in, and the book is already very useful.
So if you’re curious about RSpec and Cucumber, have a look around the two web sites, and maybe watch some of the screencasts. If you decide to investigate further, pick up the beta book and dive in.
Tags Cucumber, RSpec, Ruby
Posted by Eric Kidd
Sun, 01 Jul 2007 19:00:00 GMT
Programming in Ruby makes me happy. It’s a lovable language, with a
pleasantly quirky syntax and lots of expressive power.
Programming in JavaScript, on the other hand, frustrates me to no end.
JavaScript could be a reasonable language, but it has all sorts of
ugly corner cases, and it forces me to roll everything from scratch.
I’ve been trying to make JavaScript a bit more like Ruby. In particular, I
want to support Ruby-style metaprogramming in JavaScript. This would make it possible to port over many advanced Ruby libraries.
You can
check out the interactive specification, or look at some examples
below. If the specification gives you any errors, please post them in the comment
thread, and let me know what browser you’re running!
Read more...
Tags JavaScript, Macros, Planetary, Ruby
Posted by Eric Kidd
Thu, 01 Feb 2007 18:36:00 GMT
Reginald Braithwaite has just posted a short introduction to closures in Ruby. Closures allow you to pass functions around your program, and build new functions from old ones.
Programming languages that support closures include Perl, Ruby, Python (sorta), Lisp, Haskell, Dylan, Javascript and many others.
The Dylan programming language included four very useful functions built using closures: complement, conjoin, disjoin and compose. The names are a bit obscure, but they can each be written in a few lines of Ruby.
Let’s start with complement:
def complement f
lambda {|*args| not f.call(*args) }
end
We can use this to build the “opposite” of a function:
is_even = lambda {|n| n % 2 == 0 }
is_odd = complement(is_even)
is_odd.call(1)
is_odd.call(2)
compose is another useful function:
def compose f, g
lambda {|*args| f.call(g.call(*args)) }
end
We can use this to pass the output of one function to the input of another:
mult2 = lambda {|n| n*2 }
add1 = lambda {|n| n+1 }
mult2_add1 = compose(add1, mult2)
mult2_add1.call(3)
The conjoin function is a bit more complicated, but still very useful:
def conjoin *predicates
base = lambda {|*args| true }
predicates.inject(base) do |built, pred|
lambda do |*args|
built.call(*args) && pred.call(*args)
end
end
end
We can use it to construct the logical “and” of a list of functions:
is_number = lambda {|n| n.kind_of?(Numeric) }
is_even_number = conjoin(is_number, is_even)
is_even_number.call("a")
is_even_number.call(1)
is_even_number.call(2)
The opposite of conjoin is disjoin:
def disjoin *predicates
base = lambda {|*args| false }
predicates.inject(base) do |built, pred|
lambda do |*args|
built.call(*args) || pred.call(*args)
end
end
end
This allows us to construct the logical “or” of a list of functions:
is_string = lambda {|n| n.kind_of?(String) }
is_string_or_number =
disjoin(is_string, is_number)
is_string_or_number.call("a")
is_string_or_number.call(1)
is_string_or_number.call(:a)
These were four of the first closure-related functions I ever used, and they’re still favorites today.
Feel free to post versions in other languages below!
Tags Hacks, Ruby
Posted by Eric Kidd
Sat, 20 Jan 2007 03:20:00 GMT
New Ruby programmers often ask, “What, exactly, is a symbol? And how does
it differ from a string?” No one answer works for everybody, so–with
apologies to Wallace Stevens–here are 13 ways of looking at a
Ruby symbol.
Read more...
Tags Ruby
Posted by Eric Kidd
Sat, 03 Dec 2005 11:30:00 GMT
Years ago, I looked at Ruby and decided to ignore it. Ruby wasn’t as
popular as Python, and it wasn’t as powerful as LISP. So why should I
bother?
Of course, we could turn those criteria around. What if Ruby were more
popular than LISP, and more powerful than Python? Would that be enough
to make Ruby interesting?
Before answering this question, we should decide what makes LISP so
powerful. Paul Graham has written eloquently about LISP’s virtues. But, for the sake of argument, I’d like to boil them down to two things:
- LISP is a dense functional language.
- LISP has programmatic macros.
As it turns out, Ruby compares well as a functional language, and it fakes
macros better than I’d thought.
Read more...
Tags LISP, Macros, Recommended, Ruby
Posted by Eric Kidd
Tue, 15 Nov 2005 22:13:00 GMT
This weekend, I moved Random Hacks to Typo, a nifty Rails-based blogging system. Here’s what I did:
- Set up my Mac for Rails development
- Pointed Typo at MySQL
- Created a custom theme
- Wrote an article importer
- Routed my old URLs to new locations
- Wrote some custom sidebars
- Configured Debian’s mod_fcgid
Now for the gruesome details.
Read more...
Tags Rails, Ruby, Typo
Posted by Eric
Tue, 11 Oct 2005 00:00:00 GMT
I just recovered the contents of this site after a two-year hiatus.
I'm going to try to dig up some other old stuff, too.
I should really rebuild this whole site using Ruby on Rails and some
Ajax goodness. But that's going to have to wait until I ship some
software at work and take care of other personal projects.
Tags Rails, Ruby
Posted by Eric
Tue, 11 Oct 2005 00:00:00 GMT
Back in 1961, John McCarthy (the inventor of LISP) described
an interesting mathematical operator called amb. Essentially,
amb hates to be called with no arguments, and can look
into the future to keep that from happening. Here's how it might look
in Ruby.
Read more...
Tags Continuations, Hacks, Recommended, Ruby
