realStorage 2.0.1 released

Just made a quick micro release of 2.0.1 for realStorage. There was a ReferenceError under browsers lacking Gears. It didn't manifest itself as an error in my unit tests as it was in the last executed line of the file.

realStorage 2.0 is out

realStorage 2.0 is now officially released. For those that don't know, realStorage is a compatibility library that handles browser incompatibilities for the W3C Web Storage API as of August. What's new in this release and why I am specifically supporting the August version of the spec and not the newest one, read on.

Testing JavaScript code (and releasing realStorage 1.2)

The motivation behind the blog post is the release of realStorage 1.2. Two main things have been introduced in this version. One is helper functions which handle the (un)serialization of JSON objects into localStorage. This was the last idiom I have personally come across in my thesis work and thus ends (for now) my desire to add convenience functions to realStorage. After this I probably have the greatest desire to get a Gears back-end going for those browsers that do not support localStorage. But that will have to wait until Chromium on OS X begins to support the plug-in.

The other thing I added to this release was support for running the tests using JsTestDriver. This has stemmed from me trying to figure out how to do reasonable testing of both web applications and JavaScript libraries for my thesis work.

For JavaScript libraries I have been using QUnit, the testing framework for jQuery. It's worked out rather well. It is simple and has the proper concept of "sameness" for JS objects (if you have ever tried to do ``{a:42} === {a:42}`` you know what I mean). It also has XHR test support which is handy. Plus the jQuery code uses it so I can delve into their code to find example usage. And finally it has a nice HTML output page to look at failures. Tie that into the developer tools that come with WebKit browsers (e.g. Chrome and Safari) and my debugging situation is pretty good. I personally don't use Firebug as I have found it to be buggy too often and I like the WebKit developer tools. The only thing Firefox has going for it the Work Offline menu option which is handy when you are developing offline web apps.

But having an HTML page for testing a browser is a bit tiresome when you want to test against multiple browsers, which is where JsTestDriver comes in. It's a jar file that lets you "capture" multiple browsers to a server which then runs your tests on all of the captured browsers. Designed for continual integration testing, I find it handy to quickly test all of my tests on multiple browsers while I am developing. Plus there is a QUnit adapter in their svn repository which lets me code in QUnit while running it simultaneously in multiple browsers when I am not actively debugging.

For testing the view of a web app I have found WebDriver works well. There you write Java code (icky I know, but you can use other JVM languages) which uses the Selenium Java bindings and launches browsers to test them. What's neat is that it simulates key input and mouse clicking, so if you use Firefox for the testing browser you can watch the test enter text as it runs (albeit rather quickly).

So that's my JavaScript testing toolchain that I have come up with. So far it has worked out well and helped to keep me sane when dealing with JS.

realStorage 1.1.0 is out

Taking the "release early, release often" mantra almost too seriously, I have now released realStorage 1.1.0 a day after 1.0.0 came out. This new version adds two convenience functions: 'contains' and keysArray.

I added contains() to help prevent people from making the mistake of trying to test for key existence with != instead of !==. Since values are coerced to strings it would mean checking for key existence with realStorage.getItem(key) != null would succeed if the value for a key was null. But if you use !== you will never get an incorrect result as setting a value of null will always lead to "null" being returned.

I added keysArray() because I needed a way to loop through all keys in the store while being able to delete or add keys in a loop. Using realStorage.length and realStorage.key() to loop through keys only works if you don't add/remove keys as key() is only stable as long as all key names are stable. By creating an array of all keys this solves the problem.

This brings realStorage up to parity with my code that I forked it from. Looking at my personal needs, the only thing of great consequence is adding getJSON()/setJSON() so as to simplify my own code. After that I have some interest to get a Gears back-end working, especially if Gears in Chromium on OS X starts working before localStorage does.

Introducing realStorage 1.0.0

A very nice perk of my PhD work involving web applications is that I am working against HTML5 and thus the cutting edge. That means no Internet Explorer issues and most of the other incompatibilities people deal with in deployed web apps.

But working with cutting edge specifications that are still under development means that I do get to deal with incompatibilities with things that no one else is really aware of. In my case I am using the W3C Web Storage spec heavily for my work. If you are not familiar with the spec it specifies a key/value store, both a persistent store and one that is only valid while the web page is loaded -- and a SQL store. I am only using the key/value store as there is talk of dropping the SQL store so as to not have to deal with specifying SQL for the browser.

It turns out that both Firefox 3.5 and Safari 4 do not follow the spec exactly. Both browsers raise an exception in a case where the spec clearly says null is to be returned. And Firefox 3.5 has an extra incompatibility where it does not coerce key and value arguments to strings, e.g. coerce null to "null".

Because of these incompatibilities, both against the spec and each other, I have started a new open source project called realStorage. Version 1.0.0 provides a compatibility wrapper around localStorage so that (at least) Firefox 3.5 and Safari 4 act the same. Version 1.1 will get some non-standard functions that I have found useful in my PhD work.

One interesting thing (at least to me) that I am trying with this project is how to handle versions within an hg repository. I am trying out the approach that has been discussed for Python: named branches for minor versions with tags for each micro versions. A nice thing about this is that I can have people clone the repository with a specific version in the URL to always stay as up-to-date and cutting edge as they want. So people can clone https://realstorage.googlecode.com/hg/#1.0 and get the latest 1.0.x release. Or they could clone #1.0.0 if they want the exact code I released (unminified) along with the history. Or you can simply drop the specific revision and work from the default branch directly (which should be stable as I don't push to the repo until I am happy with the code). I suspect cloning o a specific tag or branch will become more popular as the use of sub-repositories in Mercurial picks up and people begin to want the most stable minor version of some library.