The new version of Mac OS X, Leopard, came with a much anticipated feature - an officially supported set of Ruby bridges to Cocoa (the Mac OS X Framework) and AppleScript. Digging around I couldn’t find the pre-installed versions, but it was easy enough to gem install rb-appscript

I’ve been playing around with the very complete examples over the last couple of days and am really impressed with how easy it is to build Cocoa apps in just a few lines of Ruby code and using the new InterfaceBuilder. You get full-fledged support of all OS X’s goodness without having to worry about Objective-C.

However, I hadn’t fully considered some of the implications of this until I was stumbled across the open-source OmniFocus-UI. It is a Rails app written as an iPhone interface to the Productivity application (GTD) OmniFocus. It essentially provides a very lightweight web interface to the application by way of the AppleScript interface. rb-appscript and RubyOSA are two Ruby AppleScript bridges that make AppleScript actually really nice to work with.

The fact that it’s a Rails app is almost silly. There is no database connection to speak of. All storage and primary functionality is handled by the app itself. OmniFocus-UI could probably be rewritten as a Camping or Merb application very easily with a much smaller footprint.

The way the Rails app works is that the controllers just route commands via rb-appscript. So when you want a list of contexts (organization of todos), the Rails app just needs to do the following in Ruby:

require 'appscript'
doc = Appscript.app("OmniFocus").default_document
doc.contexts.get.length

Or to see how many Inbox items you have:

doc.inbox_tasks.count

If instead you want to use RubyOSA, it’s really just the Class name that changes (and some more underlying bits):

require 'rbosa'
doc = OSA.app("OmniFocus").default_document

What this means is, it’s very easy to build web interfaces on top of any AppleScript-able Mac application. The one difficulty, however, is configuring your Mac to make it easily externally accessible from anywhere on the Web. If you’re handy on IT, you can always setup port-forwarding on your router.

However, if you just want setup & forget, you should check out Prism (http://goprism.com) - which creates secure, private web accessible connections to your home computer.

Allan from the NonProfitTechBlog pointed me to this article on infoQ, Ruby on Rails case study: ChangingThePresent.org.

The article does a full walk-through, from concept, through development, and to scalability, deliverability, and maintainability, of a Ruby on Rails site/service.

Discussions (arguments) between the various languages and their frameworks are common. It’s helpful to see such a readable and poignant presentation of the entire process to address the various issues other developers bring up about the platform.

I have definitely seen the same effects he talks about in the article. Development and updates occur much faster. I can be more productive creating my ideas and getting them to a working prototype. The code is easy to read and small, so its also easy to maintain the code to optimize or extend with new features.

I’m not saying that the other languages or frameworks fail at this, I know that for me, it feels like its the fastest development I can do short of natural language requirements into code (”Make me a Map” )

I talked a little while ago about the enlightening insight of understanding more about how the next phase of Applications will be “desktop-deployed web applications”. This was inspired/aided by listening to the brilliance of people like Matt Webb. Using standardized, hopefully cross-platform technologies, it’s possible to develop your application once, and “push” it to any number of devices.

Ajaxian discusses Adobe’s new “Apollo”:

Apollo is client-based software that will run Flash applications separately from a browser, whether online or offline

The image shows an example travel application developed in Flash, and deployed to a desktop via Apollo. (via Digital Backcountry)

I also saw that Chris Messina is helping out on a project WebKit on Rails, whose goal is to make it easier to deploy Apple’s WebKit and also to “come up with new ideas and practices that leverage the WebKit platform”. WebKit is an excellent platform to develop desktop web apps, as it can be baked straight into a Cocoa application, but be accessing a “web application” that may be running locally on the users’ machine.

rails-app-installer allows you to bundle and install/uninstall a Rails application, including required gems.

$ gem install my_app
$ my_app install /some/path


I learn best by picking a project and learning a new technology by applying it to the project. This is how I originally learned PHP, MySQL, and various web technologies when developing the Detroit Curling Club site/portal. Looking back, it’s amazing I got done what I did with what I knew. I implemented a Wiki, CMS, user management, uploading, RSS, and so forth, from the ground up, with no frameworks .

However, the result also means the code is, shall we say, “spaghetti”. And is really no fun to maintain and add to. Since then, I’ve learned Ruby and Rails and really enjoy working in the language and framework and wanted to reimplement the site. With so many other projects going on, I was concerned about the time necessary to get the site migrated.

Actually, it was rather easy. by stroke of fortune. Here is how the work went.

On the catwalk…

By similar mindset, when I designed the original database schema, I used “rails-esque” naming: tables are plural, columns are simple singular names. Join tables are alphabetical of the two tables they are joining. I just had to migrate the names of a couple of tables and columns to mee the rails standard configuration. I could have overriden the table/column names, but didn’t want to deal with maintaining that. I really wanted the site to work like it was originally written with Rails in mind.

You’ve obviously created a Rails application by now, so I’ll skip that. Now, I have my database (with backups). Setup your config/database.yml to point to the database and then run rake db:schema:dump to create the schema.rb of the database. If you want, you can copy this to a migration file.

Next, install Dr. Nic’s Magic Models, which automagically give you your model files, associations, basic validations, and so forth with no coding. Magic just begins to describe it. You can verify this by bringing up script/console and toying with your models and associations.

Testing is good

A good idea at this point is to load Selenium, a web user-interface testing application, and walk over your original site to create user interface requirements based on current site design. This should stand as your base-line specification. In the end, your Rails app should act like your current application.

You can also check out the work of Josh Susser who has a ruby script that will validate all the records in your database using your model validations.

Define your application test specification using RSpec and BDD. Again, you already have an existing web application to help define your desired functionality.

The View, the View

Now you have a your base application done. You should start migrating your views. Fill in your layout/application.rhtml with the base layout from your original HTML files.

You’ll now need to start actually defining your controllers for various functionality: calendar, users, leagues, etc. Along the way, run your tests you defined with RSpec and verify operation. This is where the actual work comes in. Overall though, I find the design of Rails to make this very easy going. I just have to deal with various legacy functionality.

I’m also looking more at Unobtrusive Javascript for Rails (ujs4rails) at how to handle graceful degradation (or is it graceful upgrading) to browsers that may not support javascript.

Work in Progress

That all said, migrating the site has been very easy. So easy I’m looking at migrating other projects to Rails. Of course, deploying Rails applications to shared hosts is not nearly as easy as deploying PHP ones. Especially with applications that are meant for other users to easily install on their own hosts. But the ease of development and maintenance is not easily overlooked.

If only Apache supported a built-in Rails module.

Ben Curtis recently released Tesly Jr., is a great web service that runs through your Rails tests, formats the output, displays them, and allows you to share them with other people. It installs as a plugin in your Rails application. Whenever you run rake to test your app, it uploads the results automatically to the Tesly Jr. server.

Using Tesly Jr., its very easy to keep your development team up to date with the status of the project. Combine this with runing tests on deploy with Capistrano (via Jamis Buck) and you have a that much better integration of testing into your development and release cycle.

Tesly Jr. is free when using the hosted service, and available for just $24 if you want your own copy to run on your own systems.