I just wrote about the imminent release of my new gem rical which is a fresh implementation of the RFC 2445 (iCalendar) specification for Ruby.

Almost as an afterthought, I decided to look at what it would take to make the gem work with Ruby 1.8.6, 1.8.7 and 1.9.1. I hadn’t really thought about 1.9 compatibility while working on rical, so I didn’t know how much work would be needed.

I’d seen that David Chelimsky had said that a new version of RSpec which ran on Ruby 1.9 was imminent but that was over a month ago and I hadn’t heard an update, but David responded quickly to my email (using his iPhone while stopped at a traffic light!) that yes that rspec 1.2.4 does indeed work with 1.9, and I was off to the races.

Executive Summary

It turns out that making rical compatible with Ruby 1.9 was fairly easy. The problems fell into a few areas: * Ruby 1.9 has made DateTime parsing less flexible. * Ruby 1.9 Range#include? requires the range to be iterable * Hash enumeration order is different

A few months back I wrote about my quest for a new iCalendar library for Ruby. I’ve continued work on it, and it should be ready for its initial public “offering” in a day or two.

I’ve applied for a Rubyforge project called rical (for Ruby iCALendar, although I’d prefer that it be pronounced RICK AL), other than that, I’m waiting for Adam Wiliams who has been using a private pre-release copy and has been pestering me to release it for some weeks now gives it another “smoke test” and some additional rspec examples if he finds any smoke.

I’ve made progress on a couple of fronts since the last report.

• Although occurrence enumeration was reasonably fast there were a few use cases which were noticeably slower. Unfortunately these tended to be those heavily used in the recurrence rules typically used in time zones, ones which occurred just a few times in a large period, like every second Sunday in March at 1:00 A.M. I’ll probably write about why, and the odyssey of re-factoring which ensued in a later post, but suffice it to say, I’ve got a brand new design and implementation of recurrence rule enumeration which is significantly faster. The old implementation ran the entire spec suite, including all of the use cases in RFC 2445 in 15+ seconds on my late 2008 white MacBook, the new implementation runs a slightly larger suite in less than 5 seconds.

• Adam hasn’t been using enumeration (yet, I hope he will soon though). His motivation was solving problems first in parsing icalendar input from other calendar apps using the existing Ruby iCalendar libraries. The VTIMEZONE support in rical is a big help here. He found a few deviations from RFC2445 which rical used to share with the icalendar and vpim gems, but doesn’t anymore.

• Adam’s next need was proper exporting of RFC2445 output, which until then was lightly implemented. He also prodded me for a builder DSL for creating calendars and calendar components similar to that in the existing iCalendar gems. He offered to work on that this weekend while I focused on exporting. But two things changed the plan. I got the exporting done rather quickly, which was lucky because his wife’s OB/GYN apparently decided that she needed to deliver a new son via caesarian right now! So I went ahead and did the builder DSL myself.

• Since the dead tree version of 3rd edition of the Pickaxe showed up in my mailbox on Friday, I decided that it might be good to work on making the library Ruby 1.9 compatible. So I started on that Friday night, and with lots of interruptions, including spending most of yesterday at a Radiant sprint, just finished a few minutes ago. Rical runs fine on Ruby 1.8.6, 1.8.7 and 1.9.1

So barring any surprises from Adam’s explorations, rical should be published soon after I get approval from Rubyforge for the project. I’m also planning to push it to a new github repository under my github account to keep the ‘edge’ version.

I’ve tried to keep rical ‘pure ruby’ and not Rails specific, although it should play well with Rails. In particular it will pick up timezones from ActiveSupport enhanced Ruby Time and DateTime objects using the TimeWithZone stuff which arrived in Rails 2.2. After things settle down a bit, I’m thinking about starting a Rails plugin which will exploit rical and ActiveRecord to help store calendar components in the database.

Although it would have been nice to have more billable time which would have meant that rical might not be quite as ready to ship, I’m looking forward to giving it more exposure, so far I’m pretty happy with it and I hope that others will be as well. Adam seems to think some will.

Watch this space.

This is a bit off topic from the usual fare here. I wasn’t going to write about this on the blog, but since Scott Laird must have reinstalled his blog, causing this old post about getting his iPhone fixed to show up in my feed reader. I took it as a sign that maybe I should. It’s a bit of a rant.

If you don’t care, just move along. I’ll be back with more Ruby stuff soon.

My “evil twin,” Patrick Mueller, recently opined about a possible change in the Javascript (officially called ECMAScript) specification to make Javascript objects have a defined enumeration order for their properties. In Javascript, every object is basically a Hash which maps property names to property values.

The existing ECMAScript spec says that an object is an “unordered collection of properties.” But apparently recent drafts have omitted the word unordered.

It turns out that MOST existing JavaScript implementations enumerate object properties in the order in which those properties were added to the object. This was pointed out in an article by John Resig about the JavaScript engine in Google’s Chrome browser. The Chrome JavaScript VM had a few cases for which this was not the case. Despite the fact that the ECMAScript standard doesn’t/didn’t require a standard order, the Chrome team decided that the incompatibility with the other “major browsers” constituted a bug.

Patrick is not happy about this.

There’s an interesting parallel here with changes in Ruby Hashes between Ruby 1.8 and Ruby 1.9.

"Once I built a railroad, now it's done
 Brother, can you spare a dime?"

A couple of evenings ago at the monthly meeting of Agile RTP Jason Tanner from Enthiosys led a discussion of experience in introducing agile development methods to companies.

He led off by encouraging the audience to make index cards inscribed with impediments to the adoption of agile methods which the attendee had encountered, and tape them to a whiteboard. He then took the cards off and discussed them.

One of the first was something like, “people who can’t work without a detailed long-range plan.”

For some, reason, the old depression-era song “Brother can you spare a dime?” popped into my head as soon as that discussion started.