Vancouver.rb Q&A with Jim Pick on Ruby and Cloud Computing, Distributed Ruby and Wikis and More

Welcome back to the Vancouver.rb Q&A series. Today let’s welcome Vancouverite Jim Pick, 38.

dRuby is very nice compared to other techniques, because there is almost no stubbing code required at all. On the other hand, any interface that needs to be public and portable to other languages is probably better handled using something like REST and JSON.

TiddlyWiki is a JavaScript wiki implementation that can run entirely inside a users browser, saving locally instead of to a remote server. I am interested in developing a true distributed wiki implementation that supports a local distributed revision control store and conflict resolution — I think TiddlyWiki is an ideal platform to start that from.

Q: Can you tell us a little bit about yourself?

Jim Pick: I’ve been programming since I was twelve years old and been active in the free software and Linux communities since around 1997. I currently maintain the Kaffe.org project (a clean room implementation of the Java virtual machine), and I also host some services for the GNU Classpath project (free core Java class libraries) on my server.

I recently quit my regular day job to start work on a new free software project, which I hope to have ready to launch in September. I’ll be blogging about it on my website.

Q: Can you tell us how you got started with Ruby?

Jim Pick: I first started to use Ruby about two years ago when I started working at a Vancouver company called Bycast. They use Ruby extensively to handle the provisioning, configuration and installation of their Linux-based distributed storage product (which is resold by HP and IBM).

Independently, I’ve studied Ruby on Rails, and I put together a few small web applications for internal use at Bycast.

Q: Are there any Ruby (language) features that make Ruby a great choice for coding/hacking?

Jim Pick: I find the syntax to be quite clean, and it’s easy to write readable, approachable code with it.

It has enough flexibility in the language to support the creation of small DSLs (domain-specific languages) when needed — which is useful when used with restraint.

Q: What’s dRuby? Can you tell us more (about your dRuby hacks/projects)? How can you run DRb over SSL?

Jim Pick: dRuby is a simple way to do essentially remote procedure calls (RPC) between Ruby code running in different Ruby instances (even over the network). I used it at Bycast to write a distributed build system, as well as a distributed installer.

A while back, I did an experiment to see if I could get dRuby to work over SSL (following some instructions found on the ‘net). It worked, but I haven’t yet put it into any production code.

I might possibly use this technique for communication between tightly-coupled code written in Ruby. dRuby is very nice compared to other techniques, because there is almost no stubbing code required at all. On the other hand, any interface that needs to be public and portable to other languages is probably better handled using something like REST and JSON.

Q: Any commentary on Cloud computing and Ruby?

Jim Pick: I’m tracking the cloud computing space very closely for my new project. Ruby on Rails definitely has a lot of buzz around it, and there are quite a number of startups building Rails hosting clouds (e.g. Engine Yard, Heroku). There are a lot of ways to put together a Rails stack, and it will be interesting to see which variations of the stack find market success. I’m very interested in Google’s App Engine, which is definitely Rails-inspired, even though only Python is currently supported.

Q: Any thoughts on JavaScript applications, frameworks and the emerging offline support in browsers? (What’s TiddlyWiki?)

Jim Pick: Eventually, I expect to see just about every high level language show up in web browsers via plugins e g. Ruby will be available for Internet Explorer via Microsoft’s Silverlight Dynamic Language Runtime. However, for the next few years, Javascript is the only language that is almost guaranteed to be everywhere on the client side.

The emerging HTML 5 standard provides some standardized support for offline applications. Until then, Google Gears is a nice browser add-on to provide offline support today in the mainstream desktop browsers.

TiddlyWiki is a JavaScript wiki implementation that can run entirely inside a users browser, saving locally instead of to a remote server. I am interested in developing a true distributed wiki implementation that supports a local distributed revision control store and conflict resolution — I think TiddlyWiki is an ideal platform to start that from.

I feel that it is important to understand client side concepts such as offline and sync, as they also are the key to building cloud computing systems that offer high performance and reliability.

Q: Any tips, tricks or advice for developers getting started with Ruby?

Jim Pick: I started by reading the “Pickaxe book” cover-to-cover (over a period of six months and many coffees). I had some background in Perl already, and many other languages, so I found it pretty easy to absorb — although I imagine that some people might find it a bit dry.

I learned Rails by reading “Agile Web Development with Rails” (Second Edition). Rails is particularly difficult to learn, as it changes so much from version to version, and the books take a while to catch up. Also, it demands a lot of expertise in other areas, eg. HTML, SQL, Unix, Javascript, CSS, etc. It is probably not the best thing to tackle if you are just getting started with computers. On the other hand, it’s approach to “convention over configuration” is a real eye-opener compared to some other web frameworks. Thanks for the questions!

Thanks Jim Pick for your time and insight. Have some more questions for Jim Pick? Join us at an upcoming weekly Vancouver.rb Open Ruby Hack Night mondays and talk in person to Jim Pick or other Rubyists in Vancouver or send along your comments, questions to the Vancouver.rb forum/mailing list. Thanks!