I love how easy it is to write tests, especially asynchronous ones, with QUnit and so was quick to start using it for my JavaScript tests.

The one thing that I found it lacked was support for continuous integration products like Hudson, CruiseControl or Continuum. So I figured that I would change that.

For a long time I have been using JsUnit along with JsUnit Server to merge in client side JavaScript test results with a server side test integration workflow. Essentially, JsUnit Server is a Jetty server and JsUnit posts back a form with test results to that server, which logs the results to standard JUnit formatted test results files. Those files can then be read by most continuous integration products and included in their reporting.

What I decided to do was hack QUnit so that it too could submit test results back to the JsUnit Server in the same format that JsUnit submits results and could therefore continue using the same JsUnit Server workflow and simply change the client JavaScript test framework to QUnit. It worked like a charm!

I wrote a couple of simple function that in the background dynamically create an HTML form in the QUnit test page and add the results to the form as each test is run. When the tests are complete the page submits back to the JsUnit Server and the test results are logged as they were when I was using JsUnit.

It is some pretty simple changes but does make using QUnit that much better, especially if you were hesitant to switch just because the continuous integration support was not there for QUnit.

Check it out on GitHub.

I kept getting an error like:

‘require’: no such file to load — some_gem (LoadError)

In the end it was all because I had forgotten to first require rubygems!

It was a hard thing to find an answer to from The Google.

The Mozilla Developer Center says this about sessionStorage:

This is a global object (sessionStorage) that maintains a storage area that’s available for the duration of the page session. A page session lasts for as long as the browser is open and survives over page reloads and restores. Opening a page in a new tab or window will cause a new session to be initiated.

Emphasis mine.

What we found was that of the three different browsers that currently “support” sessionStorage, there are three different implementations. Go figure.

I looked at a few different ways of opening new windows or tabs and those included anchor tags with target values of “” and “_blank”, window.open() JavaScript calls with different targets, and context menu open in new window or tab.

Internet Explorer 8 is furthest from the spec, as one might expect. No matter how you opened a new window from the page, the sessionStorage is preserved in the new window.

Firefox is only slightly better in that it does not preserve the sessionStorage in new windows when the new window is created by choosing open in new window / tab from the context menu on an anchor.

Safari is more or less like Firefox except that it does not preserve the sessionStorage when the target on an anchor is “_blank”.

In short, if you are expecting that sessionStorage is tied to a single browser window then think again.

More to come soon though since I am working on a few small JavaScript libraries and two services that I will be releasing soon!

There has of course also been a tonne of amazing work being done on PhoneGap (tests, Palm, Nokia, simulator) - though not by me so much

Check out the latest at GitHub http://github.com/phonegap

First, by skipping tests and taking on other types of technical debt during development they come slightly closer to meeting tight timelines and releasing software that is not as good as it could have been, but good enough.

Second, when there are bugs found in the software the manager can blame the developers who were previously told to omit things like tests in an effort to get the software out sooner. Not only do the developers take the blame, but they are also forced to fix the bugs, often by working long hours outside of regular business.

The end result is that the software is closer to the quality it should have been in the first place, and the developers have done it in record time because they had to work evenings and weekends. And the manager, has not only released the software on time but he has also taken the credit for the heroic bug fixing effort.

That leaves the developers paying off the technical debt and looking for a new job where, hopefully, it won’t happen again.

Could not start the spawn server: /usr/local/lib/ruby: Permission denied (13)

So I spent a long time trying to find info about Passenger spawn server settings, but the problem in the end was that the path shown in the error did not exist - it should have been pointing to bin obviously :S

The other part of using passenger is the slightly different Capistrano recipe. With Passenger there is no spinner task and you need to put in an empty restart task. Here is my recipe:

########################
# Application
########################

set :application, “example.com”
set :deploy_to, “/var/rails/#{application}”

########################
# Settings
########################

default_run_options[:pty] = true
ssh_options[:forward_agent] = false
set :runner, “user”

########################
# Servers
########################

set :user, “user”
set :domain, “example.com”
server domain, :app, :web
role :db, domain, :primary => true

########################
# Subversion
########################

set :repository, “http://svn.example.com/trunk/server”
set :scm_username, “user”
set :scm_password, “password”

########################
# Passenger
########################

namespace :passenger do
desc “Restart Application”
task :restart do
run “chown -R apache:apache #{current_path}”
run “touch #{current_path}/tmp/restart.txt”
end
end

after :deploy, “passenger:restart”

deploy.task :start do
# nothing
end

The other thing that I found I had to do was the chown call since Passenger runs the Rails app with the same user as is running Apache, in this case the apache user and apache group.

Now on to try out Cassandra.

It look something like this:

_renderingSession.getRenderingOptions().setProperty(
  RenderingOptions.CORE_OPTIONS_GUID, 17000, true);

After much trial and error it was found that the BrowserContentManager did not support this rendering option (and RIM says it is completely unsupported / experimental anyhow) yet the Field returned from BrowserContent.getDisplayableContent() does support it!

Long story short it looks like PhoneGap on RIM OS >= 4.6 is going to work really well.

Next up is looking at the new features in OS 5.0.

I think that they are pretty much spot on in terms of their interpretation of the App Store rule 3.2.2 that states:

An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built-in interpreter(s).

The two key points in this App Store rule are where it says an app “may not itself install or launch other executable code by any means” and this is exactly what users of PhoneGap are doing if their apps are downloading JavaScript over the network rather than including it in the application www folder. By downloading JavaScript over the network at runtime the application is downloading and running interpreted code that Apple has not control over during their app approval process.

So if any of you PhoneGap developers are worried about Apple rejecting your app just make sure that you don’t download any JavaScript at runtime and instead include it in the application. Having said that, also make sure that you apps don’t look like you just took a shit and emailed it to Apple

That is just my thoughts on the issue, whether or not that is the *real* reason that Apple is rejecting PhoneGap apps we may never know but that is certainly one reason that they would do it I think. It could just be because they feel like it…

I am going to cover Geo related features and issues of IPhone 2.2.1, Android 1.5 (aka Cupcake), RIM OS 4.7, and, most importantly, PhoneGap. I will be sure to post the slides once I am done them as well as put all the sample projects up on my GitHub.

If you are in San Jose Monday night then you will probably find me in the bar, whether I am done my slides or not!