I promised last week to touch base again today and I’m happy to report that the CloudKit gem is available for the brave amongst you to browse and use. I say this because there are several working pieces that are of value right now while the completed gem will take a few more days before being worthy of an “official” release and a push to RubyForge.

http://github.com/jcrosby/cloudkit/tree/master

Here’s what the code straight out of GitHub can do right now after a “rake local_deploy”:

• Generate a small, fast RESTful web app that supports OpenID and OAuth out of the box using Blake Mizerany’s killer Sinatra DSL (more on this later).
• Generate a GWT UI and REST client skeleton for those of you who dig that sort of thing. (A similar jQuery skeleton generator is in the works.)
• Generate RESTful resources with migrations plus ActiveRecord models that have their RESTful routing and authentication baked in.

Things that are extremely close and may be available by the time you read this:

• A rake task for running the app using Adobe AIR.
• JavaScript/ActiveRecord model synchronization stolen from my GWT on Rails project.

Other items in the works that won’t likely be ready when you read this but will appear rapidly, piece by piece, prior to the gem release:

• Desktop application updates.
• Automatic desktop schema migrations that match the server side counterparts.
• Automatic data/resource synchronization between desktop clients and server side storage.
• Transparent offline/online detection and management using the Application Context (a.k.a. MCP) mentioned in the previous post.

I’ll continue these frequent updates as the pieces roll out.

Given the zero dollar budget and the fact that I don’t know people who do the press conference thing, I’ll just deliver the details here and now.

I was targeting today for the CloudKit release. On Friday evening, I began a code-a-thon of sorts to wrap up the last bits of the platform prior to release. The weekend was spent entirely at the computer, bachelor style, with pizza, coffee, soda, and various other forms of sugar in the shape of rabbits. Each remaining bit was scribbled on a white board with a plan to get to Monday morning with the goods.

Sometime on Saturday, I chose to take a risk and drastically reduce the hosting requirements for CloudKit apps (and give it a massive boost in performance as well). Knowing that this kind of change would be a pain for users after a first release (it included an ORM and web framework switch), the risk/reward ratio seemed about right. This part of the work is now done and I am back on track for wrapping up (again).

So, thanks for sticking with me, for being awesome, and for the encouraging comments and emails. Building free software is its own reward but having enthusiastic users makes it even better.

Sneak Peek

For the curious, CloudKit is coming together as an SDK delivered by way of a ruby gem. The installed gem will allow anyone to generate a small, fast web app that supports OpenID logins and OAuth API authorization right out of the box. Stealing liberally from my GWT on Rails plugin, CloudKit will keep data models in your web app in sync with the models in your distributed, online/offline desktop apps (built with the same HTML, CSS, and JavaScript UI on both sides). The center of it all is a tightly optimized bit of JavaScript known as the Application Context.

This Application Context is kind of like the MCP in Tron, minus the evil part. It knows when it is running in a browser or on the desktop and makes decisions about what to do when the network connection is unavailable. Local SQLite storage is used for both speed and network fault tolerance. Based on launch times, network state, and web service information, the wannabe MCP updates client apps to the latest version, migrates their data models to match the server versions, and synchronizes data that is stale on either side.

There is probably a day or two of work left at this point, to be distributed over spaces between the best full time job ever and my role as the luckiest husband and father ever. Let’s touch base again next Monday, shall we?

A few hours ago, Adobe released a public version of AIR for Linux. This makes it the first cross-platform WebKit runtime that supports local SQLite storage. They are the only player in this space at the moment. Although many lump AIR in with Gears, Flash, and Silverlight, it is operating entirely in its own space and this should not be underestimated.

When CloudKit is released, likely on Monday of next week (quickly followed by Actionatr), it will include support for Adobe AIR but the pieces that are AIR-specific have been isolated into their own surprisingly small implementation classes. The end result may come in at less than 100 lines of code. Because of this, I have been working on a Qt wrapped version of the latest WebKit runtime that supports HTML 5 local SQLite storage without having to use a top level “air” namespace. If you have experience with the Qt toolkit or WebKit builds in general and would be interested in working on this cross-platform wrapper, please leave a message in the comments or send an email to my first name at this domain.

A big thank you to Larry Halff (Ma.gnolia, thmbnl) and Chris Messina for hosting Todd Ditchendorf (Fluid) and me on the Citizen Garden Podcast. If you’re interested in site specific browsers, check it out. CloudKit, the “data everywhere” platform powering Actionatr, is discussed along with Fluid, Prism, AIR and other juicy bits.

Here’s an annotated peek at some Actiontastic and Actionatr source code for the 1.0 releases. I don’t like Photoshop hype nor do I like showing a raw un-styled UI, so this is my attempt to show real working code and highlight some of the new features that it enables.

1. All Actions View

Sometimes you just want to see everything on your list, regardless of what project or context contains the items.

2. Project List View

The new project list view shows all projects with their actions listed underneath in a tree-like view. Projects can also be marked as complete.

3. Tags Instead of Contexts

Tags are a great way to build a scalable user interface. By scalable, I mean an interface that grows with the user. Contexts are canonical to GTD but tags are more universally understood, not to mention expendable. If you don’t do full-on GTD, tags are easier to ignore than the imposing “Contexts” button in the toolbar of Actiontastic today. (As an aside, the toolbar is going away in favor of an iTunes-like source list.)

So, you can still have tags for contexts like “calls” or “errands” but you can also use them in a more free form manner as your personal system grows. Beyond this, there is no more “one context per action” rule; you can apply as many tags to an item as you desire. Tag collections are in the works too, for things like “important” and “calls” in a single click.

4. Time Travel

Go back in time to see what was completed on each day.

5. Trash

Just in case you delete something that you didn’t mean to delete, these apps now have a Trash Can, just like your desktop.