Rails to the rescue

It's good to keep the tools in your box sharp, I'm happy I've been messing with Rails on my own, because I need to knock out a prototype for work really quickly, Rails to the rescue!

A couple notes, NetBeans 6.0 is out, and I highly recommend it as your Rails development environment. I took a few minutes to switch to the new IDE, and it's very smooth. Alas, when I switched, I was having a very hard time getting plug-ins, and getting Rails to upgrade via Gems. I was receiving weird buffer errors. Google to the rescue, there was a simple fix that involved upgrading gems..just run this command:

gem update --system

and you should be in business...thanks to the DRY blog for the heads up! I'm also incorporating the WillPaginate plug-in in this round, and I've got to mash-up with Google maps. I did find a gem for Google maps, we'll see how far I get, but I'll post any findings..


Updates:

Apparently, will_paginate returns nil if your collection is smaller than the per-page. I was having a problem where I was returning an array of results for my 'position log', and it would not show up in the form where I had used

<%=will_paginate @obs_log %>

I'm not sure why, but here's the code for will_paginate..

# Renders Digg-style pagination. (We know you wanna!)
# Returns nil if there is only one page in total (can't paginate that).
#

def will_paginate(entries = @entries, options = {})
#total_pages =

if entries.page_count > 1
renderer = WillPaginate::LinkRenderer.new entries, options, self
links = renderer.items

content_tag :div, links, renderer.html_options
end
end

So this really does me no good, I'm sure I'm missing something obvious, but it should at least render the collection without the paging cruft. I'm just in too much of a hurry, but this was frustrating. I punted and just showed the last 30 or so with a :limit in my find_all.

I want to present a REST-ful interface for my app to accept data from a mobile with a GPS, I ran across this RailsCast on REST, which seems useful...

will paginate

I've been working on a Rails app as a sort of hobby, it's for a site that I'm prototyping for fun, and we'll see where it goes. I've been off and on, depending on the home schedule, but having a concrete goal helps in my effort to keep my chops up. My areas of focus right now are Ruby, Rails, AJAX, JavaScript (with the Dojo toolkit), as well as CSS and design (never my strong suit). The things I work on lately are quite fun and challenging, but have taken me away from heads-down web app coding for quite a while.

Anyhow, working with the project, pagination turns out to be deprecated in Rails. I grabbed the new plug-in, classic_pagination, but the first thing I got is a notice that it's dead code, and I should move to WillPaginate. I love working with Rails, but the capricious nature of open source does have its drawbacks! Anyhow, I'm working with it, it looks nice. I found a quick jump-start on a RailsCast episode dedicated to pagination, linked here. RailsCast is a fine resource, and I highly recommend it.

One thing I would point out, and something that I'm still working to change, is to wake up to the fact that Rails and Ruby let you pop open a console and work with your code while you code. Try things out, see what responses you get, and if it looks good, copy it into your codebase. As a Java monkey, this is still a foreign mode of operation. The point is, if you're used to coding Java like I am, get used to having that console open, and monkey with your code! Check out the RailsCast, and give WillPaginate a try.

Try NetBeans 6.0 Milestone as your Rails IDE

I don't have a comprehensive analysis, just a general feeling. I really like coding Rails apps using the NetBeans 6.0 Milestone. I love Eclipse, and switch between the IDE's depending on the specific task, so this is not coming from a particular camp.

I like RadRails a lot, but it seems to have stalled a bit. I kept having problems where the IDE would loose my Rake tasks. I found a fix to manually add an Eclipse builder to the project, point it at rake, etc. Even so, I still periodically see the app forget about Rake. A small complaint, really, but it frustrated me enough to switch. What I found in NetBeans is a rather tight-feeling, smooth IDE for Ruby on Rails. No big analysis, just a nice experience. I'm back to coding, and my IDE seems to not forget about rake. Now if only I can remember my anniversary coming up!

Doooh!

An obvious point, but do your Rails model validation code before developing your unit and functional tests very far, otherwise, you have to re-do a bunch of test cases....

Doooh!

Rails Active Scaffold - from a DHSB

Saw this come across from my del.icio.us network, an article from IBM about the Rails ActiveScaffold plug-in...


This is a plug in to nicely handle all the CRUD that still required lots of coding using the vanilla Rails framework. The promised benefits include (quoting from the ActiveScaffold page):

• An AJAXified table interface for creating, updating, and deleting objects
• Automatic handling of ActiveRecord associations
• Sorting, Search and Pagination
• Graceful JavaScript degradation
• RESTful API support (XML/YAML/JSON) baked in
• Sexy CSS styling and theming support
• More extension points than you can shake a stick at
• Guaranteed to work on Firefox 1+, IE 6+ and Safari 2+
• Released under the MIT License, the same one as Rails itself, so you can use it freely in your commercial applications.

Worth a try! Of the plug-ins and Rails extensions I've seen lately, this one looks promising.

This plug-in is good for me, as I found I'm a DHSB, from this programmer's test...what are you?

Your programmer personality type is:

DHSB

You're a Doer.
You are very quick at getting tasks done. You believe the outcome is the most important part of a task and the faster you can reach that outcome the better. After all, time is money.


You like coding at a High level.
The world is made up of objects and components, you should create your programs in the same way.


You work best in a Solo situation.
The best way to program is by yourself. There's no communication problems, you know every part of the code allowing you to write the best programs possible.


You are a liBeral programmer.
Programming is a complex task and you should use white space and comments as freely as possible to help simplify the task. We're not writing on paper anymore so we can take up as much room as we need.

Next version of SlIcer deployed

I've been up late a few nights on this, so allow me to go on a bit...This is the next version of SlIcer, which is essentially a utility for hookup up things in Second Life to things in real life. I've seen things like ObjectOverlord that work on the client code, but I wanted to do things that would work within the vanilla client. Good idea? Not sure, but at least it's workable.

What it does now:

• Inventories people and objects within a sim using scripted sensor objects that are placed in strategic locations. This inventory can be for multiple regions, and is kept in a database.
  
• Creates a queue for messages bound for Second Life. These messages are stored in a database, and delivered through scripted hub objects (co-located with the sensors). Essentially, the hubs poll the database for pending messages, which come down in a bundle, and are distributed to target nodes.

The test case is a mapping room, with a map on the floor, and 3D symbols that reflect state and position. Messages can come in from external applications, and the objects on the map change position, reconfigure to reflect state changes, and can also display floating text for other messages.



That's a picture of the map floor. The round object floating in air is the sensor/hub. Against the wall is our people sensor that looks for individuals, sort of virtual RFID. The SlIcer web app, which is still very much a work in progess, can show an inventory of everything discovered by our in-world sensors.


That's a screen shot that shows, for example, a rover_counter on the map. The database contains info like the last sense time, the x,y,z coordinates, etc. The cool thing is, there are simple URL's that an external app can call, targeting a region and object by their known name. This obviates the need to keep up with SL UUID's.


I'm an awful object builder, but this is my pitiful truck object in a 'stowed' state..an external source (such as a mobile GPS unit), could send telemetry by calling a URL, this enqueues a message for delivery to the sim...




And bammo...state/position change...




What's next:

• I've already got a database of objects, and it will be easy to add a table of arbitrary name/value properties per object. This gives a Silo-like capability to maintain object state outside of the sim. Objects could update their own state, or pick up state changes pushed in from the web. What would be cool is that that state can survive object name changes, and also re-rezzing. The drawback is that objects have to have a unique given name, I don't do duplicates.
• Thinking about a pub/sub system for events. For example, do something when an object is rezzed, when an object moves, when a certain person walks into a room, etc. I thought about putting this up in an additional sim, and doing some stupid pet tricks where moving and object in one sim causes a change in an object in another.
  

From there, I'm not quite sure, but it seems to open a lot of possibilities up. I have some cruft in the database for doing some reliable delivery stuff, but that's not a burning issue right now. The whole thing is done using Ruby on Rails, which I am really keen on these days. This has not taken a huge effort, development can go very quickly one you make the mental jump!

Rails, SL, mash-ups, all in one project...how cool is that...

Progress on acts_as_authenticated and authorization in Rails

I'm happy to say I fairly quickly was able to implement authentication using 'acts_as_authenticated', a Rails plug-in. Props to the helpful Rubyists of Second Life for turning me on to that. I prefer the plug-in model to the engine model, much easier for me to grok.

So the steps were fairly simple. First, I went and grabbed acts_as_authenticated, per the helpful instruction page. If you have not tried a plug-in, it's worth it to do a bit of background to understand what is happening, I'd suggest the link-fest on the Rails Wiki as a primer. This gives you a basic database user repository. Then you can, in your controller, say things like:

class RolesController <>

before_filter :login_required

This filter will divert to a login page, along with signup, logout, password hashing, and other basic facilities. Badda-bing, badda-boom. Note that you can exclude various controller actions from the login requirement, so you can have guest pages, and other non-critical data in plain view.

Important to note, acts_as_authenticated only does the authentication part, so you need to go the extra mile to add authorization. There are a couple advertised plug-ins that sit on top of acts_as_authenticated, and I took a stab at the acl_system (actually, I grabbed acl_system2 out of SVN). The files and directories from acl_system2 go in your vendor/plugins directory in your Rails application. There are also a few pre-reqs to using the acl_system, as explained in the instructions:

You will need to have a current_user method that returns the currently logged in user. And you will need to make your User or Account model(or whatever you named it) have a has_and_belongs_to_many :roles. So you need a model called Role that has a title attribute. Once these two things are satisfied you can use this plugin.

So I created a role table in MySql, with id, title, and the usual created and updated dates. I added the following to my User model:

class User <>
has_and_belongs_to_many :roles

Along with this, I have a join table to link users and roles. Once this is configured, you can add additional filtering to the above authentication filter, as in this simple example:

class RolesController <>

before_filter :login_required
access_control [:list, :show, :new, :create, :update, :edit, :destroy, :index] => '(administrator)'

Note that this is simple, and the specification of complex action/role mappings looks fairly flexible. At any rate, it works in initial testing. Lots more to go, but this took much less time than grokking and implementing the user engine, YMMV, of course!

Nice Comparison of Ruby/Rails IDE's

This morning, my RadRails seems to have forgotten about my projects Rake tasks. I've seen that before, somewhat frustrating. Made me look at the grass across the fence again.

Here's a nice comparison of Rails IDE's, as part of my short detour into alternatives. It looks like grabbing the latest NB 6.0 Milestone gives you the Ruby support.

Rails Authentication

So as I'm working on a couple Rails apps, I'm worried about the best way to authenticate. I had originally done some things with rails authentication and authorization using a rails engine. I pretty much got it to work, but it seemed a bit kludgey. Part of this, I'm sure, is not quite grokking out how the engine was wired in to my app. Chalk it up to a state of perpetual newbie-ness.

So perhaps my feeling about engines is not totally unfounded. I'm not jumping into the whole debate, but there seems to be a split in the Rails community about engines, enough to look for alternatives. Anyhow, I asked a few more experienced rails programmers, and like a chorus they all told me to forget about engines and go with Acts as Authenticated. That's on my plate, I'm going to try this plug in as part of this SlIcer mash-up.

Additionally, I came across this nice review of Rails authorization tools...a good read.

REST-ful Rails reflections, SlIcer, and the 3D Web

So I've been quite busy throwing together a web/Second Life mash-up, implementing ideas outlined in a previous post. The basic premise is to build a framework, (I apply the term loosely, perhaps 'hack' is the more appropriate term), that could start bridging the gap between Second Life and the web.

I called the framework SlIcer for the hell of it, and began implementing it using Rails. The basic functions I'm working on include:

• A set of sensors, deployed into Second Life, to detect people, and to detect scripted objects within range. These sensors are installed in various areas, and tuned for sensor range and angle to provide localized service. The sensors repeatedly sweep for named objects and people, and report up to SlIcer via HttpRequest with the object name, second life key, and the location vector. It would certainly be possible to add state properties to the report for real-life storage as well.
  
• Co-located with certain sensor types are 'hubs', which act as the bridge between Second Life and real life. This may be a dumb idea, but I thought it useful to create a database to store and forward incoming data in SlIcer. The hub would poll SlIcer, and get messages as bundles. The bundles are pulled into Second Life, marked as distributed in the database, and then distributed to the target objects in range. The main benefits are:
• A real time view of the objects in range, and the current position. Again, state properties are also possible. External applications could use this data in ways I quite haven't come up with yet...
• An ability for real life apps to address objects within Second Life by a 'plain english' handle. This obviates the need to know the current key of a rezzed object in the sim.
• A plain http call can be put into any application to post message bound for a Second Life object. Any application can push data into Second Life without any SL cruft, as long as the name of the target object is known.
• The (future) ability to add reliable delivery (sequencing of messages, and delivery confirmation) semantics if this seems useful.

A later development might be to have some sort of event pub/sub mechanism. For example, anytime an object within a location is touched, it could report that event, and listeners outside of Second Life could tie in. We're looking at ambient orbs, as an example. It would be possible, given these mechanisms, to watch for certain thresholds of people occupying a certain room in a sim, and change the orb status...really, any number of interesting things would be possible.

So I've got the basics working using Rails. I have not tried NetBeans and Rails yet, sticking with RadRails for now, that seems to be all I need at this point. My original impulse was to use a REST-ful approach, given the new facilities in Rails for scaffold_resource. The particulars are described in this great tutorial. This was particularly attractive as the llHttpRequest LSL function supported GET, POST, PUT, and DELETE>. At any rate, I had some initial success, but rapidly ran into strange problems with Second Life. There are likely some strange ACCEPT headers sent out from an HttpRequest, because I began running into strange 406 Not Acceptable errors. Lazy developer I am, I just decided to punt REST for now, and just use GET and POST within normal Rails controllers. Now it works fine. I'll go back and dig when I have time...but I just don't.

It's an odd thing if you think about it. I was going through all sorts of gyrations to implement REST-ful interfaces, which was supposed to make things 'simple'. Really, the gyrations were there so I could code to a particular programming philosophy, and while attaining a philosophically pure implementation still has it's attraction, I was wasting time. Ironic!

I want to add props for a pretty interesting blog on the 3D web, there's more out there than I thought, and I thought I was pretty tiresome hyping this technology around my shop! Look through some of the reported developments, and see if you agree...hype or not?

Well, the sim is down for mx, hence attention to the blog. I'll put up some screen shots of how we're using SlIcer when I can get back in! Cheers...

REST-ful Rails

Ok, I'm drinkin the kool-aid...

I've been hacking around (with purpose) on the ideas described in my previous post. I've got a prim in Second Life that acts as a sensor, identifying active (objects running scripts), and capturing the name, SL key, position, etc of each responding object. The first case is to collect these relations between 'given' name, and SL-assigned key for the object. Given that my sensor works, I'm working tonight to create the interface on the real-life side. The sensor can take each detected object, and use the LSL http request to send this observation for storage outside of Second Life.

Http request from SL....there's good reason to take advantage of REST-ful approaches. That's where I am tonight, going through a really interesting tutorial/document about building REST-ful interface using Ruby and Rails. So I'm loosing steam, and won't have it all done tonight, but should be soon! As I had posted yesterday, maintaining an easily updated database/registry of SL objects is the first step. Next, I'm working on more formalized mechanisms for a store-and-forward queue from RL => SL, and some fashion of an event pub-sub mechanism for SL => RL. The latter may be a cursory attempt, just for grins, but I could see applications.

2-way messaging with Second Life

So I'm messing with the idea of a messaging hub for Second Life. The idea would be to create a web app that would accumulate messages bound for named objects in Second Life. These would queue up in a database, and be delivered in batches over some period that would not kill the sim in question.

So you'd have a table with stuff like this:

sl_bound_messages
----------------
id
destination (fk to id)
contents (right now, big varchar text)
source (source of message)
delivered_at (time of batch pick-up)
hub_pickup_id (fk to hub)
status (p = pending, b = batched, e = error, n = no object)
date_created (will be queue time)
date_updated

So an external application, fed by a GPS unit, could report the location of a RL object. This hub would accept the report, and hold it until it can push it through to Second Life. The hub could wait for polls from a 'repeater' in SL, which could be a prim running http requests on a timer. The 'repeater' would call up to the hub, get a batch of messages, and then distribute them around to target objects.

Objects in SL could also be hooked into the hub, in two ways:

• An object can be scripted to listen for, and register with, a hub. The object could report its location in the sim as it is pinged, as well as the unique id that is assigned to it. This gives some ability to track the location of objects within SL, and allows the hub to provide a handle to objects in the sim by relating a name with the SL-assigned unique id.
• The hub could know the objects it 'has', and route messages to the objects. The hub would request batches of messages on some period.

The hub could keep a registry that looks something like this:

sl_uids
-------
id
sl_uid
object_name
description
type (a = avatar, o = object, h = hub)
last_check_in
object_location_x
object_location_y
object_location_z
date_updated
date_created

So how to efficiantly distribute messages, and how many http requests and deliveries can be done without causing lag is a question, but I have some things in mind given these facilities. Much of LSL is undocumented, so there could also be better ways of doing this, but sure sounds like a fun experiment

The hub would keep a queue of messages like this:

sl_bound_messages
----------------
id
destination (fk to id)
contents
source (source of message)
delivered_at (time of batch pick-up)
hub_pickup_id (fk to hub)
status (p = pending, b = batched, e = error, n = no object)
date_created (will be queue time)
date_updated

Also, a simple event publishing mechanism seems useful, where SL objects publish an event, and RL things can be notified. Simply, a prim with an LSL script could shoot out an http request on some event in SL, this would go up to the hub, and the hub could allow registration of these events to interested parties outside. These events could note the object, object location, and any other relevant data, and the real world could react.

I've got RadRails fired up, and gonna start hacking.