Rhodes framework - Open Source Ruby based Smartphone development

The Rhodes framework is an open source Ruby-based platform for building locally executing, device-optimized mobile applications. It is similar in concept to MVC frameworks such as Rails, Merb and Camping but much lighter weight (and hence executable on a mobile device) than any of these. Along the way of course, we had to implement Ruby for these device operating systems (iPhone, Windows Mobile, RIM and Symbian).

In general, developer productivity is much higher in Rhodes than writing to diverse native device operating systems and APIs since most of your UI customization can be done in HTML templates (ERB files). Rhodes also provides access to native device capabilities such as GPS and PIM data via an extended set of tags (e.g. <geolocation/>).

These applications are also optimized for interacting with hosted enterprise app (SaaS) backends . That is,  it allows mobile applications to work offline with synced local data by embedding a client for RhoSync. The Rhodes source tree contains sample apps for SugarCRM, Siebel Field Service and Ligthouse.

Rhodes is available for iPhone, Windows Mobile, Research in Motion (BlackBerry) and Symbian smartphones. Support for Android devices will be available by end of February 2009.

via rhomobile.com

I just found out about Rhodes, and it looks crazy cool. While I don't currently have a smart enough phone to play with it myself, maybe they'll eventually make it so the thing can target J2ME. (Or, I'll end up getting a smart phone). Regardless, the idea of writing phone applications in Ruby (or another dynamic language) has lots of charm for me, and I've been idly contemplating implementing a interpreter for some small language so that I can do just that on my phone.

In related news, I got to play with my friend's developer G1 this past weekend, and I like. I'm pleasantly surprised at the size and how well it feels. Perhaps I'll get one in a year or so. (And maybe I'll end up with version 2 at that point. ;)

Timeout::Error in Ruby (Warning, language rant!)

There are bad design decisions, and there are horrible design decisions. The exception class Timeout::Error in Ruby's stdlib is one of those horrible things.

Ok, let me start from the beginning. In Ruby, the standard way to catch any recoverable error in your program is to catch StandardError. Anything that doesn't inherit from StandardError is generally the type of thing that you want to have crash your program. Now, Ruby has a library for having an exception thrown after a timeout. (We'll ignore for a second that this library is implemented in a provably unsafe manner as far as threads are concerned.) You just call the timeout method, and pass a number of seconds and a block. If the block doesn't terminate after the number to seconds, it is forcibly terminated, and the Timeout::Error exception is called. This would be all hunky dory except that Timeout::Error isn't a subclass of StandardError, it's a subclass of Interrupt. "So," one may say, "why even use this thing at all?" Well, because you kinda have to. Want to do something with HTTP? Well, the standard HTTP library happily uses the timeout library to do it's timeouts. And as a result, so does pretty much every other library that has to do something with HTTP. So you're going along in your nice, happy application, when you suddenly find out that even though you're rescuing StandardError so that a network failure doesn't bring down your application, well, that isn't quite true: the minute a network timeout happens, your entire application comes crashing down. The only answer I can find on the internet is that one should always just rescue Timeout::Error when doing anything that might call the timeout library. (rant from a developer that found this way before I did)

What I don't get is how this is still in the standard library. Why not do the obvious thing and just make Timeout::Error a subclass of StandardError? (Of course, the aforementioned problems with the timeout library should be fixed, but I can see that taking a long time) While I forsook Perl in favor of Ruby because of Perl's many gotchas, at least Perl's evil tends to be in my code, not hidden deep in a library that I'm using. And I still miss Perl's copious, usually well written documentation. (Even CPAN modules tend to be rather well documented)

Sometimes, the land of Python seems like it might be nice... (The grass is always greener on the other side, and there is always something hidden in the grass waiting to bite you.)

(I also have a whole rant about the stupidity of Java's properties object inheriting from Hashtable, but that's a lot less insidious.)

(Yet Another Parenthesized note: maybe I just need to go back to my warm, fuzzy, Perl security blanket.)

Stack Overflow

Joel Spolsky just announced the launch of Stack Overflow, which is free a question and answer site for programmers. As one of those that has tried to search for programming questions on google, only to get mostly useless answers most of the time (and half of them behind some stupid pay gate), this sounds like a totally awesome idea. (And you should read Joel's blog post, it does a much better job introducing the site than I.)

Mock Objects

Brett shared this post from the Google Open Source blog. While I'm not into Python, a mock object generator seems totally awesome. (Why didn't anyone tell me about this earlier?) Anyways, the Google Blog post linked to EasyMock, which is a mock object generator for Java. Now that looks really useful, since I spend my day job hacking on a very large Java system with not enough tests. EasyMock has quickly made it onto the short list of things I need to look into.

Scary

I just came across a method in our code that has a 52 character long name. I'd love to share the name, but I can't come up with a way to disguise the "sensitive" parts of it, and keep the spirit. So instead, I share my astonishment.