In the meantime, though, I noticed something very interesting: the firms that appeal to me most, in terms of web site content, community involvement, portfolios, marketing approach, etc., are disproportionately Ruby or Ruby-Rails shops. I admire the “vibe” of the Ruby community:

• Strong focus on design, to the extent that some Ruby-centric development firms have web sites which could pass for visual-design firms instead.
• Ruby developers seem unusually aware of the extent to which syntax and conciseness matter.
• There is much discussion of craftsmanship, though I’d need to survey a broader swath of production code to determine whether this discussion has a basis in reality.
• Seemingly contrary to the above factors, Rubyists also appear to be unusually pragmatic.
• This pragmatism translates to real-world financial impact: many developers make a good living with Ruby, and many firms are very happy with their Ruby projects.
• Ruby events are numerous, nationwide.

There are numerous Ruby- or Ruby-Rails-centric development firms, and Oasis Digital is not one of them (we are perhaps a 5%-or-so Ruby shop, with Ruby expertise to effectively attack automated sysadmin, integration projects, and so on). We aren’t going to become a Ruby-centric-firm, either; and there are some technical aspects of Ruby that don’t impress me.

Rather, we want to bring some of the cultural qualities seen in the Ruby community, to other languages and tools. We care about design much more than most firms, and it shows in our GUIs. We care about user experience, and we are obsessed with quality, working results.

Yesterday I set up a DokuWiki instance (which stlruby.org might migrate to), and found that its underpinnings (PHP, plain text files) make for ridiculously easy installation:

• wget
• tar xzf
• browse to install page, set a few settings
• delete install page

Yet those underpinnings are very well suited to the task at hand. A typical Wiki does not need a database underneath it. As with many things, this reminded me of a general principle: use the least complex, most readily and commonly available, easiest to administrate technology appropriate for the task at hand.

If you need to make a change, but that change is difficult / tedious / risky to make, first improve the underlying system that makes it so.
(OasisDigital.com is a static web site; we have dynamic contact (issue trackers, etc.) to automate our work together and with our customer, but that content is on another domain.)

Webby is a client-side, simple CMS for generating static web sites, written in Ruby. Why serve a static site (plain old files on a web server) in 2008?

• It minimizes the moving parts, there is almost nothing to break or maintain.
• It is very unlikely that any hosting issue will break a static site.
• It is easy to serve a static site fast (though our current host, TextDrive, sometimes is not all that fast).
• Security vulnerabilities are very unlikely, in the absence of any executable content.
• The canonical content (in this case, mostly Markdown) is stored in plain text files, which we track, diff, and merge in git.

In an earlier foray in to Drupal, we found that Drupal has extensive and useful capabilities, as well as a vibrant community, but it also has many moving parts; too many, in my judgment, to make it a good solution for building an essentially static web site.

What’s the difference between an application and a framework?

An application is something a customer actually wants!

However, for some applications, I recommend use of an application framework. For some Oasis Digital projects, I require it:

Please, Use a Web Application Framework

My reasoning here applies specifically to web applications with many CRUD (create-read-update-delete) features, and an underlying database. The advice applies much more widely, and with many nuances and caveats, but this article I am discussing only CRUD-ish web applications. Even within this niche, my reasoning does not apply to web applications which “push the envelope” of what is possible or which attempt to advance the state of the art.

Regardless of the programming language, the application should be built on a framework. More specifically, the framework should popular and mainstream, with a community of developers, and the appearance of momentum for the future. Likewise, the client-side JavaScript used in these applications, should also be based on such a framework. Here are some examples:

Ruby: Ruby on Rails, IOWA

Python: Django, TurboGears, Pylons, TwistedWeb

PHP: Akelos, CakePHP, CodeIgnitor, Symfony, Zend

Java: Struts, Seam, Rife, Tapestry, Stripes, Wicket Spring MVC

JavaScript: Scriptaculous, Prototype, JQuery

This is just a list of some frameworks that I am aware of; I have not evaluated all of these in detail, and I do not endorse them; nor is this an exhaustive list. For Oasis Digital projects, we help evaluate proposed frameworks, then I personally give the go-ahead to use a particular framework for a particular project.

An in-house web application framework does not meet the “community of developers” criteria, except at the very largest firms. Everywhere else, you are better off with an off-the-shelf, popular framework than with an inhouse framework, even if the latter is brilliantly designed.

Justification

My recommendation (and requirement, for some projects) for using an application framework for this kind of application is not based on a fad. Rather it is based on my years of experience as a developer, a team leader, a maintainer, and most importantly, a customer of software development.

The wild success of some frameworks (such as Ruby on Rails) has shown that they can reduce the amount of code and time needed to develop an application. That second factor, the amount of code specific to the application, is at least as important as the development time. Lines of code are not an asset; they are a liability. Only the features that the code provides are an asset. The most valuable software provides a lot of features using the smallest possible amount of application-specific code.

Therefore, even if a developer is so extraordinarily fast that they can create a system very quickly without using an off-the-shelf framework, they still have provided less value by doing so, compared to creating that same system quickly with fewer lines of code.

Another benefit of using a common framework (not a custom, in-house framework) is that this makes an application much easier and faster for other developers are work on in the future. A more maintainable system is more valuable.

Framework Caveats

Vidar Hokstad left a lengthy and excellent comment below, disagreeing with my thesis. It turns out that I mostly agree with Vidar, and it sounds like he and I have been through many of the same experiences with poor application frameworks. There are a lot of things an application framework can do wrong, and sadly, many of them take the opportunity to do so. In-house frameworks created by “architecture astronauts” seems to be especially prone to these defects:

• All-or-nothing: Some frameworks intentionally or accidentally make it hard to replace a section of the framework. Don’t use these. Use a framework instead that has a “library” philosophy, such that you are readily choose to use some parts but not others.

• Just Different: There are frameworks which offer an API wrapper around the underlying mechanisms, which isn’t really any better, just different. In this case, different is worse. Writing to (for example) the com.acme.inhouse.servlet API is, all else equal, much worse than writing to the standard Java Servlet API. To be worth its weight, a framework API must be demonstrably and obviously more concise.

• Lower Abstraction: There are frameworks which, ironically, lower the level of abstraction of the application code, because that code ends up working around the framework features to get the job done.

• Pile of Pieces: There are frameworks in which it is necessary to shred your application in to a pile of pieces, and then wire those pieces together with configuration files. This is sometimes useful, but often makes the application harder to understand, not easier, especially if there are extensive “XML pushups” involved. (I’m looking at YOU, Struts!) Instead, choose a framework with convention-over-configuration, and one which offers but does not require manual wiring.

• Keyhole Database Access: If you find you mostly use a frameworks’ DB access features, and as a result you have short, easy to change code, then keep it. But if you find you use extensive SQL to work around lots of framework issues, throw it out. If a framework intentionally makes it hard to reach to the underlying SQL access, throw it out now.

• No Source: If someone proposes a framework for which you won’t have source code, laugh. Aloud. If this gets you fired, then it has set you on a path to find employment at a more enlightened organization.

• Exceptionally Bad Exception Handling: Java frameworks are especially prone to issues with exception handling, in which the framework code “eats” exception details.

In summary, pick up a framework and use it to get your application up and running quickly, but don’t be stupid. Do what makes sense locally for your project over time. It is a win to use an application framework to reach “1.0” functionality, even if you end up removing or swapping out parts of it later.

Shoes creates native applications with a Web feel. It is not built atop GTK, Qt, etc., but rather directly on the relevant native API (Win32 on Windows, for example). Shoes has a lot of potential, which it can realize only if a community accrues around it, leading to lots of polish and a rich widget set.

One thing that surprised me about the Shoes install it that, as far as I can tell, it includes its own Ruby install; I installed Shoes on a machine with no (obvious) Ruby installation and it worked.

I (mostly) agree:

JavaScript is in nearly every browser, including tiny ones (like the one in my BlackBerry Pearl). It may be the single most widely available language today.

Because of the above, an enormous population of JavaScript programmers (though sometimes of dubious skill) has emerged.

Starting with Java 6 it’s “in the box” there also. To me, this makes it the likely winner, by a wide margin, for a dynamic language to be used at Java shops or inside Java projects. Being “in the box” is a powerful advantage, one which the many other contenders will have a hard time overcoming.

Adobe’s new JavaScript virtual machine implementation, which they handed over to Mozilla as “Tamarin”, sounds like it will boost JavaScript performance great, making it good enough for a very wide variety of projects.

JavasScript uses curly braces, like the last few Big Languages.

Like Java, C, C++, etc., JavaScript has specs and multiple competing, complete, current, high quality implementations. This, to me, is a big advantage over Ruby, Python, and other currently popular dynamic languages. Of course there is plenty of room in the industry for these language to thrive also, I am not saying any of them will go away; we use Python with great results and expect to keep doing so.
Mark Volkmann initially thought I was nuts to predict JavaScript as a winner but came around a few month later (and said so in a user group talk).

In a project at work, we’d adopted JavaScript as our plugin extension language for user-customizable rules (billing rules, etc.). I’d have chosen Lua (as I did for another project), but there are at least 1000x as many JavaScript programs out there. So far it has worked very well. If we had it to do over we might implement far more of the project in JavaScript.

However, there are a few reasons why I only “mostly” agree:

First, with JavaScript there isn’t a good way to avoid shipping source code. Sure, you an obfuscate JavaScript with various tools, but the results remains far for amenable to readable-source recovery than in a more traditionally compiled language. For open source projects this is no big deal, but there are also many worthwhile businesses and projects which depend on proprietary, not open software (including most of our projects), and it’s not year clear that obfuscation is sufficient protection. (Update in reply to a comment below: This matters even for server-side software, because some of us create and sell software products for other people to run on their servers.)

Second, at the moment JavaScript appears to lack a module system, without which it’s painful to build large systems. I expect an upcoming language version will address this.

I find this very appealing, yet also a bit impolite; 37Signals has built a good business on Basecamp, the ActiveCollab team has created (well, is creating) an open source clone, while BaseJumpr did neither of these things yet stands to gain (at 37s’s expense). However, I doubt BaseJumpr is a significant threat or bother to 37Signals because most users interested in the open source ActiveCollab would likely not be using the Basecamp service in the first place.

Speaking of Basecamp, I am fascinated by 37Signals’ business success with such a simple (but well executed) application. I tried out Basecamp myself, and found it far too feature-anemic for my taste; but I could readily see its appeal and simplicity, and it has me thinking about the merit of building a business in a focussed niche, intentionally and happily excluding the potential customers outside it.

Update in 2009: BaseJumpr doesn’t appear to exist any more. I am curious how it worked out.

I also recorded audio of the talk with my Olympus WS-100 digital voice recorder, then used Audacity to clean it up; Audacity’s “Remove Noise” feature worked surprisingly well. The recording lasts 1 hour 23 minutes, is 49 MB in size: RubyGUIToolkitTalk.mp3

A transcript of the talk is also available.

In the audio I mention screen shots and demos; you can find those at the respective toolkits’ web sites (linked below). I also briefly discuss and demo some code from a 2005 talk about Swing.

The handout contents follow below.

Ruby GUI Toolkits

St. Louis Ruby UG – http://stlruby.org – March 27, 2007

Kyle Cordes – http://kylecordes.com – Contact me via my web site

These notes will on my web site sometime this week.

Agenda

1. Review the myriad options

2. Let’s see some code

Ruby is quite popular for web applications (mostly with Rails) and for utility scripting. But there is a world of GUIs beyond web applications, a world which is not going away. To build such applications in Ruby, we must choose a GUI toolkit and Ruby bindings. My criteria for a rich client application toolkit (or the resulting application) are perhaps harsh:

• Polished, rich set of widgets (Consider the vast array of widgets available for .NET, Java Swing, Delphi, etc.)

• Consistent, comprehensible API, with both API reference and “how-to-use-this” narrative

• Robust, production-grade: No beta, no pre-1.0.

• Features beyond what’s readily possible in a web application

• Look like 2007, not 1997

• Look and feel, if desired, like a mainstream GUI application

• Actively developed and updated

• Ideally cross-platform; at minimum, great results on Windows, where most of the customers are.

• Sufficiently popular that programmers and community resources are available

In summary: it must be suitable for creating applications that people will pay for. Not merely pay for in a vacuum or an internal-project-single-bid situation, but pay for in a competitive environment where I am trying to outmatch others who are using Java Swing, Java SWT, MFC, Visual Basic, Delphi, etc.

I investigated each option enough to form an opinion of its suitability according to the criteria above. With some of them this took only a short while. Here they are, alphabetically:

Cocoa

Sadly, I don’t have a Mac. If I did (and was targeting that platform only), the Ruby-Cocoa bridge would be very appealing, as it produces applications with a completely native Mac look&feel, and appears to be a joy to program.

http://www.rubycocoa.com/

http://rubycocoa.sourceforge.net/doc/

Fox

The Fox GUI toolkit was somewhat weak when I first learned of it a few years ago, but appears to have improved considerably since then. It uses non-native widgets (which resemble “vintage”, pre-XP-Themeing Windows controls), and has a somewhat limited selection of them. http://www.fox-toolkit.org/

FXRuby, the Ruby binding, is in the “one click installer” box. The benefit of being in the box is hard to overstate.

http://www.fxruby.org/

http://fox-tool.rubyforge.org/

Gtk

Gtk, the graphic toolkit from the GIMP and Gnome problems, is a strong candidate. Gtk is stable and well documented, and thoroughly proven by the large number of polished Gtk applications for Gnome. Gtk feels most at home on Linux, but also works on MacOS and Windows. I didn’t try MacOS, but I found it works and looks good on Windows.

Glade, the Gtk GUI design tool, treats GUI layout as data rather than code. (NeXT did this in the 1980s, and MS has recently reinvented it in the form of XAML.)

To install Gtk-Ruby on Debian (from http://ruby-gnome2.sourceforge.jp/hiki.cgi?Install+Guide+for+Windows):

sudo apt-get install ruby-gnome2

Then to try it out:

ruby -r gtk2 -e ‘Gtk.init ; Gtk::Window.new.show ; Gtk.main’

Unfortunately the simple invocations above didn’t work for me; but with a bit more work the samples run well.

JRuby + Swing, JRuby + SWT

Java Swing or Eclipse’s SWT can be used with JRuby. I didn’t investigate these much (aside from running the samples), because JRuby was not yet “ready for prime time” yet, as of around the end of 2006. It looks like there has been a lot of progress since then, so if you are reading this in mid-2007 or later, give it a close look.

require ‘java’

JFrame = javax.swing.JFrame

frame = JFrame.new(“Hello Swing”)

frame.getContentPane.add javax.swing.JLabel.new(“Hello World”)

frame.setDefaultCloseOperation JFrame::EXIT_ON_CLOSE

frame.pack

frame.visible = true

Local Web Application

Ship a “local” web application: install Rails + Mongrel + etc., and launch a web browser pointed at http://localhost:port. AJAX or Flash can be used to build a richer GUI than you can get with plain HTML. Aside from the local install process (which is not difficult), the tools are mature and powerful, and programmers are abundant. Because of these advantages, and because of the various problems with the GUI toolkits, I would consider this strongly if I needed to build a local Ruby GUI app today.

.NET

There is a Ruby-.NET bridge which can use WinForms (in .NET 1.x), but it hasn’t been updated since 2004.:

http://www.saltypickle.com/rubydotnet

There is at least one Ruby compiler in development which targets .NET (analogous to JRuby). When that is ready, it will be possible to use WinForms and WPF (the new “Vista” era .NET GUI toolkit).

http://www.plas.fit.qut.edu.au/Ruby.NET/

OpenGL / SDL

There are Ruby bindings for OpenGL and SDL; I didn’t investigate these because they are most suited for producing graphical / game software rather than application GUIs. However, as application GUIs become richer, I expect the two categories to merge to some extent, so don’t rule out this approach completely.

http://ruby-opengl.rubyforge.org/

Qt

Qt is mature, stable, and of high quality. It is used for many commercial applications on Windows and Linux. The documentation is extensive and GUI layout tools are available. Qt uses native widgets on each platform. Qt is available for free for use on open source software (including KDE and the many KDE applications). For commercial use, it is less free:

$2000 per dev, for the “desktop light” edition (one platform)

$5000 per dev, for the “full” edition on 2 platforms

$more for various other packages

The QtRuby bindings are free, and described as “very complete”:

http://developer.kde.org/language-bindings/ruby/index.html

There is a book from the Pragmatic Press about QtRuby:

“Rapid GUI Development with QtRuby”

http://www.pragmaticprogrammer.com/titles/ctrubyqt/

Qt/QtRuby is very appealing, probably the most polished of all the options, except for the price. I believe the price will prevent large scale adoption. For those large corporate Ruby GUI projects, go with Qt.

Tk

Tk is in the Ruby “box” (installed by the installer, though I also saw instructions to install it separately), and has a complete, documented API. Unfortunately, it is also quite old and generally ugly; it seems more suitable for simple GUIs for utility programs, than for large, rich applications. However, this seems to be changing – the “Tile” theme engine for Tk greatly improves the appearance.

require ‘tk’

root = TkRoot.new

button = TkButton.new(root) {

text “Hello, World!”

command proc { puts “I said, Hello!” }

}

button.pack

Tk.mainloop

Win32

Also included in the Ruby installers are SWin and VRuby. SWin is a low level Win32 API binding, with VRuby is a GUI toolkit (OO wrapper) on top of that. VRuby appears to be inspired by Visual Basic or the Delphi VCL. Its controls are the Windows controls (including the TreeView and ListView), and are of course 100% native and 0% cross-platform. It uses a clever implicit event-binding technique, requiring generally 0 lines of code to bind an event to a method.

The documentation, while detailed, is in Japanese, and this is a relatively low-level toolkit, so it may be quite hard to adopt for non-Japanese speakers.

Update, January 2008: Anthony Leotta wrote in to point out that there is now good VRuby documentation, in English.

WxRuby / WxSugar

WxWidgets itself is stable, featureful, free, and used in many commercial applications. The most common way to use Wx appear to be with its native C++ API, and with WxPython. Wx uses native widgets for each platforms, and with a little work can have a modern slick look and feel.

http://www.wxwidgets.org

Unfortunately, the WxRuby bindings are incomplete and unstable – even the demo application crashed several times.

http://wxruby.rubyforge.org/

WxSugar adds a layer of “syntactic sugar” on top of WxRuby, to enable a more expressive, compact coding style.

http://wxruby.rubyforge.org/wiki/wiki.pl?WxSugar

Ruby Scripting for a non-Ruby GUI

Ruby can be used as an embedded scripting language; to do this, you’d write your application “core” in something else, then use Ruby for instance-specific business rules, plugins, etc. I demonstrated this last year at Code Camp with Lua, the same approach works well with other languages.

So What Do We Do?

I don’t have a single answer as to which of these to use; none of them has impressed me as a compelling replacement to the mature toolkits I’ve used, such as Java Swing (in the Java language, which for all its issues, is a good language to use for interacting with massive Java APIs).

Other References

Jeff Barczewski pointed out that the “Ruby Developer’s Guide” (a 2002 book by Michael Neumann), which features a free sample chapter on Ruby GUIs.

http://wiki.rubygarden.org/Ruby/page/show/ComparingGuiToolkits/TakeTwo

http://groups.google.com/group/comp.lang.ruby/msg/58504a6e39e6a1c7

http://www.trug.ca/Ruby_GUI_Toolkits

http://www.arachnoid.com/ruby/RubyGUIProject/index.html

http://www.trug.ca/VRuby

Ruby/TK tutorial: http://members.chello.nl/~k.vangelder/ruby/learntk/hello.html

]]> http://kylecordes.com/2007/ruby-gui-toolkits/feed 8 http://kylecordes.com/2007/haml http://kylecordes.com/2007/haml#comments Sat, 03 Mar 2007 04:12:01 +0000 Kyle Cordes http://kylecordes.com/2007/03/02/haml/ When I starting with Python sometime in 2001, I was briefly frustrated by the intentation-as-block-structure syntax; but after a few weeks I found it  natural. Its most obvious advantage is that it avoid the duplication between indentation and braces / keywords. Yet this kind of syntax has not become popular outside of Python.

Today I saw an interesting use of it “in the wild”: HAML, an HTML templating mechanism for Ruby on Rails. I haven’t used HAML (and may not, since at the moment we have only some sample projects using RoR, nothing in production), but from the tutorial it appears to be a very tight (indentation-based) syntax for HTML templating. I’ve encountered a Rubyist or two who disdains the Python syntax – I wonder if that similarity will limit HAML’s adoption.

So today I joined Geoffrey Grosenbach in supporting Evan Phoenix’s rubinius project, by sending $200 to help sponsor the work. It’s not much in the grand scheme of things, but I believe in “putting your money where your mouth is”.

This isn’t the first time I mentioned Geoff; earlier this year I took him to task for his choice of music for the Ruby on Rails podcast, which has changed since then to something more suitable.

“FogBugz is written in Wasabi, a very advanced, functional-programming dialect of Basic with closures and lambdas and Rails-like active records that can be compiled down to VBScript, JavaScript, PHP4 or PHP5. Wasabi is a private, in-house language written by one of our best developers that is optimized specifically for developing FogBugz; the Wasabi compiler itself is written in C#.”

Fortunately DHH saved me some minutes of typing about it, with a scathing commentary.

Over at Oasis Digital we use both common tools (.NET, Java, PHP, C, Delphi, etc.) and more unusual ones (Lua, Prolog, Ruby, sorry no Lisp yet), so I believe that puts us in the DHH and Paul Graham camp: If you want to win, you must be willing to do something different from the pack… such as, in an extreme case, creating your own language optimized for the task at hand, whether in the form of Lisp macros or a C# compiler for Wasabi.

I’ve noticed this myself, in my last few forays in to esoteric languages: the illusion of plenty of choices, runs in the the reality of no good choices.  This is not a universal problem; I’ve had great results with Ruby, Python, and Lua, all of which are to some extent esoteric.  The thing that those languages have in common is that there is at least one (and generally, only one) robust, production grade implementation with a community actively supporting it.

If you want to see your favorite language gain acceptance, spend your time creating / maintaining / vigorously supporting a production-ready implementation.

This stack trace is considerably shorter than a typical Java web app stack trace. But it is not so good either, and it is an ominous sign that excessive complexity is making its way in to Rails.

Dave talked about 3 key areas where Rails should improve. The one I want to focus on is deployment. Rails has Capistrano, a slick tools for deployment automation. Capistrano is great, but it misses the boat in one key way: it is push-based. It assumes a world where the developer sets up, controls, and performs deployment to production servers. That is of course the case at the start of a small operation, but it doesn’t scale; in large organization, or even in small growing ones, sooner or later there is staff dedicated to production deployment and monitoring, separate from development.

One way, to me right way, to handle deployment is push / pull:

For the “push”, a developer uploads a new version to a storage site somewhere. It travels in the form of an archive file (ZIP, tgz, whatever) which contains all of the needed artifacts, as well as metadata about the required libraries, pre- and post-install steps, etc. for the new version. It has a unique name; it lands at a URL. Normal, off the shelf technology (FTP, web servers, etc.) can be used to serve and secure this storage, implement policies about who can upload new versions, etc. This upload happens with some simple one-line command (or as part of an auto-build); it does not actually put a new version in production, but only makes it available for pulling.

Then, on a production machine, someone with software installation rights on that machine (administrated by the normal tools – not by any special feature of the deployment mechanism) runs a command (something like “deploy staging http://ourserver/project1/project1-build-3453.tgz”) which downloads the new build, runs various sanity checks, deploys it to a staging area, and makes it available to try out. Once the staging is verified, a similar command brings it in to live production. These builds refer as needed to configuration data on the deployment machines (such as production DB access credentials); the build archives are generic, not specific to any particular production machine.

The main idea behind this is that each person has the rights they need for the work they need to do, and these rights don’t need any special help or support from the deployment mechanism. Developers don’t need any special rights on deployment machines, nor to deployers need any special rights on development machine

I wrote this in the context of a Rails / Ruby talk, but it’s at least as relevant in Java and Delphi world; in fact at Oasis Digital we need something like this on a Java project and a Delphi project right now.

]]> http://kylecordes.com/2006/deployment/feed 0 http://kylecordes.com/2006/pure-ruby-sparklines-no-rmagick-imagemagick http://kylecordes.com/2006/pure-ruby-sparklines-no-rmagick-imagemagick#comments Tue, 23 May 2006 19:42:46 +0000 Kyle Cordes http://kylecordes.com/2006/05/23/pure-ruby-sparklines-no-rmagick-imagemagick/ This Pure Ruby Sparklines implementation got my attention – unlike other Ruby graphics packages, it does not need RMagick, and thus not ImageMagick, sparing the installer considerable effort and misery. The source of that misery is the long list of dependencies; now of course a great positive of the open source world is that tools can readily build on each other – but this comes with a cost of unexpected complexity in getting things to compile and install. We had a project here delayed by a couple of weeks of working through issues in getting it all to work on shared hosting account. I never did get it working with Ruby 1.8.4 on Windows, I reverted back to 1.8.2 for now.

With a “Pure Ruby” implementation, you copy the .rb files over and it works. I wonder if “Pure Ruby” will become a marketing point like “Pure Java”.

Lest anyone accuse me of unwarranted Ruby fanhood, I’ll point this out: with Ruby it is necessary to find or what code for graphic drawing. With Java, it is in the box, in the form of the excellent Java2D feature set. Ruby is way behind in the area.