It’s time to kick off the O’Reilly Ruby coverage of the Google Summer of Code with our first student post. The following announcement is from Scott Ostler about his project, Rubyland. Scott is pursuing a masters degree in Computer Science at MIT. He is researching collaborative writing software for handheld devices.
Announcing RubyLand, by Scott Ostler
I’d like to announce the start of Rubyland, a Google Summer of Code sponsored project, and solicit comments and suggestions. Austin Ziegler is my mentor, and I’m excited to work with both him, and the Ruby community at large.
Rubyland’s goal is to simplify writing tiny scripts for small tasks. I’m planning to build it using a mix of dRB and EventMachine. Rubyland’s core will aggregate events from desktop applications, file system updates, other computers on the network, etc.. Rubyland will then call user-written Ruby scripts in response to those events. Initially Rubyland will target the Mac OS X platform in some ways, but its core will be cross-platform, so that plugins can be written for any platform.
Maybe an example would help. When I write something in Latex, I often keep an updated pdf on a web directory, so I have a copy wherever I go. Rather than opening my sftp client every time I make a little edit, I’d rather have a Ruby script do the transferring for me. Great! A function almost writes itself:
def file_updated(filename)
return unless filename =~ /.pdf$/ # only upload PDFs
filename.gsub!(' ', '-') # URLs with spaces in them are drags
result = `scp #{filename} site:www/#{filename}`
unless result.sucess?
puts "Uhoh! Error uploading #{filename} to site!"
end
end
That function took a few minutes and, though it’s crude, will save me quite some time. But figuring out how to call that function is where the productivity train derails:
- I need to poll the file system for modification times, or register for file notifications if I feel ambitious enough to learn how.
- I have to start the script, and if it crashes, I have to restart it.
- Unless I want the error messages to be lost in a log file, the script needs to make graphical notifications.
Rather than deal with all these problems, I’d rather drag files in my sftp client.
All of those problems are very general, and Rubyland’s goal is to package together the solutions so that finishing the pdf uploader only takes a few more lines:
class PDFUploader < Rubyland::Handler
Rubyland::callback :file_updated => Rubyland::observe_directory('directory')
def file_updated(event_hash)
filename = event_hash[:filename]
return unless filename =~ /.pdf$/ # only upload PDFs
filename.gsub!(' ', '-') # URLs with spaces in them are drags
result = `scp #{filename} site:www/#{filename}`
unless result.sucess?
Rubyland::dialog_box("Uhoh! Error uploading #{filename} to site!")
end
end
end
Saving this snippet to a ruby file in the Rubyland handler directory will cause Rubyland to load it and take care of the rest. Hopefully this sheds some light on the aims of Rubyland, and where I’d like it to be by summer’s end. There are also some other features to highlight:
- A Growl event handler, so that any application that supports Growl notifications will be able to trigger Rubyland events.
- Thanks to RubyCocoa, Rubyland will be able to interact with running Mac OS X applications.
- Network support, so Rubyland can raise events over both the local network and the internet. In this way, Rubyland can glue together applications on different platforms and machines.
- A GUI application to graphically manage Rubyland, and to show off what it can do.
I’m excited to see where Rubyland will end up, and what it’ll be used for. I have plans myself, but if you have any thoughts about what you might like to use Rubyland for, then I’d love to hear them. Also, stay tuned; I plan to have a usable version of Rubyland out by mid-summer, and would love for people to give it a whirl.
Thanks for your support, and please don’t hesitate to contact me with comments or suggestions. I can be reached at sbostler at gmail.com.

very cool, if we can look at the source code of what we're calling.
also, please force version-awareness from ground up.
RubyLand looks quite cool. Hurry up and write it! :)
It reminds me of assorted little tasks I've written with an eye towards greater automation. I, too, have looked at ways to get instant processing to occur when various events occur (e.g., open a new browser tab; download a file; edit a document) and having nice clean layer above the plumbing opens up all sorts of possibilities.
I've been playing around with Ruby+DBus and libnotify recently, so this project is particularly interesting to me. I'd love to see a platform-independant notification API that you can plug into either Growl or Libnotify or whatever Windows uses.
Sounds quite interesting. (But have you checked out whether all this can already be done with existing libraries, and some custom code? - Just wondering ... Not that I think you shouldn't do it if the answer is Yes - I'm a great believer in choice and in having different solutions to the same or similar problems) - the world is richer that way). Do post somewhere visible about where you're going to release RubyLand so we can try it out. But it would be better if you didn't restrict it to Mac OS X - unless you're using something that is present only there. Just IMO, of course.
Anyway, good luck!
Vasudev Ram
Dancing Bison Enterprises
http://www.dancingbison.com
This looks great! In the Linux world this could come to play very well with the new dbus integration that'll come out in KDE4. Maybe something I'll wanna hack on after your SoC ;-)
This sounds super convenient. I can't wait to be writing my own Rubyland Handler's by the end of summer.