Live Demonstration of Slingshot

Filed under:RailsDay, Joyent Slingshot — eric @ 4:21 pm

The last week has seen a lot of changes to the Slingshot codebase that have made much of my previous work obsolete. That’s OK, though… the newest code takes care of a lot of the troubles I had getting things going.

I’m going to be doing a live demonstration of Slingshot in its entirety tomorrow evening at the Atlanta Ruby User Group meeting. I’ve spent the weekend making a dirt-simple Personal Inventory Application. It’s up and running on my accelerator right now, and I’m packing up a Slingshot application to download. I’ll show what goes into making an application Slingshot-ready and how to create the Slingshot application itself. Those in attendance with Macs* will be able to get online, create an account, download the Slnigshot application, sync the data down, go offline, make changes, go online, and sync those changes back up. Should be good times!

If you’re at all interested, come on by. If you RSVP, we’ll even have enough pizza to go around.

*Slingshot is not yet ready for Windows. If it is by tomorrow and I can easily package the app, I’ll let the Windows users play along too.


Slingshot On Target

Filed under:Ruby On Rails, Joyent Slingshot — eric @ 8:09 pm

When I last left you, I had moved a scratch copy of my application to a shiny new Joyent Accelerator, brought it current with Rails, and was preparing to migrate new created_at and updated_at columns to my database.

All that went well. Several of my models already had created_on (date) fields, but Slingshot needed more detail. Those got converted over to full datetimes. I also inserted raw SQL into my migration to quickly set all of the new created_at and updated_at to the current date/time.

The Slingshot synchronization process has two components: a plug-in/generator that adds a new controller and several methods to the “live” application and a somewhat complicated rake task that resides on the client side.

In the new controller you build an array of arrays that contain the data that is able to be brought up and down, using any rules and logic you need. For my first tests, I went ahead and included almost everything. In future work, it’ll have to be much more complicated, as my application has a three-tiered authentication scheme. First, each registered subdomain acts as a standalone instance of my application (though in truth they’re all served up by the same mongrel processes). Second, each subdomain has a set of users. Third, each user has a set of roles. There is a mechanism for passing authentication information from the client to the server, but in the interest of just getting things working I only bothered to check subdomain.

The controller (named in my routes.rb “sync”) has three main actions: “down”, “up”, and “log”. The down action builds the array of arrays of allowed data and the serves up an XML file containing the data as well as a number of meta data. The up action…. well, I actually haven’t yet gotten that far. The log action records the successful imports and exports, so it knows where to pick up next time.

The rake script does all of the client side work. It calls sync/down from the server, receives the XML data and saves it to the local /log directory, parses it, and performs the necessary deletes, updates, and inserts to the local sqllite database.

It took me a *long* time to get that part to work properly. First, it was silently failing and I didn’t know enough to be watching OS X’s terminal log to see what was going on. I actually opened it up by accident and found the error messages I had been looking for. The first few were related to errors in the documentation (then very meager but now much better as Joyent prepares for a general release), but I was able to get past those in pretty short order.

The rest were my fault. The data transfers are not raw SQL. They create instances of your Models and use all of the regular model methods, including validations. First, the instances were failing because I did not include all of the gems required by my application into Slingshot’s local VM (more on that in another post). Once I took care of that, then they were failing on the save validations. I have a number of custom validations that check for things such as uniqueness within a subdomain, and as I mentioned above, I was skipping most of my authentication for this test. I got past this by modifying the rake task to use save(false) (and thus bypassing validations). I think it’s safe to say the data coming from the live app has already been validated, so I was fine with that change. Then, saves were failing because of database integrity constraints. You see, when my real app first went live, I allowed null values for several fields that I had since switched to not. The old null values were still in the database, though, so when the imported data was saved, sqlite rejected them. I fixed that by changing the nulls to “Unknowns” and everything was fine.

So that’s where I stand. Slingshot is able to pull data down and I can interact with that data locally. Next up, sending the changes back up. And then, adding the real authentication.


Exploring Joyent Slingshot

Filed under:Ruby On Rails, Joyent Slingshot — eric @ 3:09 pm

Last Friday, I received the Slingshot SDK (Software Developer Kit). About an hour later, I had a copy of my Rails application running in an off-line, fully self-contained environment.

Of course, that was only the beginning, but it did right away show that you could use Slingshot to quickly deploy stand alone Rails applications. Slingshot provides the database (sqlite), the browser (Webkit in OS X and IE7’s engine in Windows), and the server, all in one application window. All you need to supply is the code. No one had talked about that use of Slingshot on the weblogs and forums (that I saw), but it was the first thing that came to mind when I saw it face to face.

My application was not ready for data synchronization. First, I hadn’t upgraded it to Rails 1.2 yet (it was frozen to a slightly pre-1.2 edge release). Second, all of the models to be synched need to have created_at and updated_at data — mine did not. Third, my live app is currently sitting on a shared TextDrive server, and a shared server is not the place to be playing with something like this.

Joyent is helping me with the third problem by providing me with a small accelerator for the duration of the pre-release testing period. An email mix-up on my part kept me from accessing the accelerator until late Wednesday. Yesterday, I logged in for the first time and found myself sitting at the business end of a console prompt in Solaris for the first time in 15 years or so.

I’ve been a shared host sort of guy since I’ve been on the internet, just before the World Wide Web was invented. Having my own server computer, getting it up and running from scratch, has not been something I’ve ever done. Still, by this morning, I had everything installed, Apache was proxying to four Mongrel instances, and a scratch copy of my Rails app was being served smokin’ fast. The documentation to get all this going is still spotty (accelerators are still a new offering, and the early adopters tend to already know what they’re doing), but I was able to piece enough together to get off the ground.

I’ve already frozen my application to Rails 1.2, so that step is out of the way. Now, I have to add created_at and updated_at columns to all my tables, and at that point I can begin adding code to support extraction for offline use and full data synchronization. I’m still not sure what that’s going to entail (I’ve been reading all about accelerators instead of Slingshot these last few days).


Successful Phone Call

Filed under:Ruby On Rails, Joyent Slingshot — eric @ 3:42 pm

I talked with David Young of Joyent and Jeff Mancuso of Magnetk (the developer of Slingshot). They asked me some details about locallygrown.net and possible offline use cases for it. We all agreed that it could very well be a good match for Slingshot, so the project will proceed.

They’ll be sending me a developer’s kit next week that will get me started. I did learn that I decide (at the controller level) what data (and controllers and actions) get taken offline and how the data gets merged back in. Slingshot provides the framework to get it done but I tell it *how* to do it. I like that.

Locallygrown.net is now sitting on a shared hosting server (don’t worry… I’m a good neighbor, or at least try to be). I’ll be migrating it over to a Joyent Accelerator, essentially a dedicated server running the Solaris operating system. This will allow for future growth, among other things. Since the move will be tied to getting Slingshot running, I’ll document that process here as well.


A new series of posts

Filed under:Ruby On Rails, Joyent Slingshot — eric @ 11:32 pm

Regular readers (all four of you) know that over the past two years I’ve picked up a new programming language, Ruby on Rails. I’ve been using it for every bit of web programming I’ve done over the past two years.

Most recently, I used it to build my farmers market system, LocallyGrown.net (my own Athens market). LocallyGrown is getting a lot of attention, and I truly feel it can revolutionize how small farms get thier produce on people’s plates.

The web hosting company I use, Joyent, has announced an exciting innovation for Rails applications that will allow developers to make their online programs work offline, with data synchronization when the user connects back up. This could be very useful for LocallyGrown, as market managers could take their online market with them on a laptop to the physical market, even if there is no wi-fi or other network connection on site.

Joyent has offered to give me early access to this framework, which they’re calling Slingshot. I don’t yet know how it works technically, and it may actually not be a good fit for LocallyGrown. The project kicks off with a coference call with the Joyent folks in the morning, and then we’ll take it from there.

One interesting thing about this early access program: I’m required to write about my experience with it, both good and bad, here on my weblog. So, this entry is the first in a series of entries that will document just that. I’ve created a new category, “Joyent Slingshot“, so all of these entries will be grouped together for easy access.

More to come!