Tuesday, May 1, 2007

Ruby tidbits

This came across my reader, but have not had a chance to dig and delve yet.

Sun Microsystems, Inc. (Nasdaq: SUNW) and the NetBeans(TM) Community, today announced an early access release of the NetBeans Ruby Pack which provides support for the Ruby programming language. The NetBeans plug-in offers developers added support for dynamic and scripting languages and includes editing features for both Ruby and JRuby - a 100% pure-Java(TM) implementation of the Ruby programming language that runs on the Java Virtual Machine.

In the past, I've messed with RadRails, and like it too. I've got a Ruby project in mind that I might start digging into this week, and I'll give it a spin. RadRails is now available over on the Aptana site, and to be folded into the Aptana ide which is another IDE for web development/ajax/css/javascript. Have not tried that either, but some demo shots of Aptana are here.

Needless to say, I've got some catching up to do. I've been focused on a few projects, and if you take your attention away from your feeds for a couple of weeks (and neglect your blog), then you end up behind the curve!

As far as the idea for Ruby, I'm trying to merge my interest in Ruby/Rails, mash-ups, and Second Life. Our group has put up a server dedicated to some Second Life mash-ups, basically a place where scripters working on several UNC islands in SL can collaborate on supporting code. We're starting out looking at tools like silo, and thinking about tools we might gin up. A prime target early on will be to look at better ways to get data in and out of SL. XML-RPC is one mechanism available to push data into Second Life, but it seems unreliable, and I wonder about it's long-term viability.

As an alternative, here's a Rube Goldberg idea, which brings me back to messing with Rails IDE's. Essentially, I'd like to write a store-and-forward queue arrangement. Put out a REST-ful interface on our mash-up server. You may send messages to an arbitrary object in a Second Life sim (and the framework would have to have hooks to resolve a name to a unique id assigned within SL). The framework would accumulate and sequence these messages. Then, build a series of prims that check the queue on a timer, and retrieve bundles of queued messages, routing them to the proper objects within Second Life. These routers could also manage the resolution of SL unique ids.

I'm still new to the environment, so I don't know how silly this is, but sure sounds fun to try!

No comments: