Yesterday, David released RSpec 1.2.7, which includes a patch I provided to allow the specification of where to find the 'ruby' program when creating a SpecTask, rather than relying Rakes RUBY variable.

Why did I submit this patch you ask, assuming you didn't read the title of this post?

So you can do this in a Rakefile :

multiruby_path = `which multiruby`.chomp
if multiruby_path.length > 0 && Spec::Rake::SpecTask.instance_methods.include?("ruby_cmd")
  namespace :spec do
      desc "Run all specs with multiruby and ActiveSupport"
      Spec::Rake::SpecTask.new(:multi) do |t|
        t.spec_opts = ['--options', "spec/spec.opts"]
        t.spec_files = FileList['spec/**/*_spec.rb']
        t.ruby_cmd = multiruby_path
       end
   end
end

This is derived from something I just added to RiCal but haven't yet released.

What it does is check that you have multiruby, which is part of the zentest gem, installed, and that your version of RSpec supports the new ruby_cmd option. If both conditions are met it makes a spec task which runs the specs using multiruby instead of ruby.

Now it's easy to run specs with the various ruby versions you want to support.

Yesterday I took a few hours and attended an intro to SolidWorks at TechShop Durham. Then today Kent tweeted about how JUnit Max has been faring, and it got me thinking about the state of the business in software for programmers.

The other day, someone brought up a UTF-8 related issue with RiCal.

RFC2445 specifies that each line of a icalendar datastream must be no more than 75 bytes, and longer lines need to be folded by breaking them into sections with the second and following sections put into lines with an initial space character to mark them as continuation lines. As was pointed out to me, simply breaking a UTF-8 string in Ruby runs the risk of splitting up a multi-byte character.

Here's a spec to show what I needed:

describe "String#safe_utf8_split" do
  context "For an all-ascii string" do
    before(:each) do
      @it = "abcdef"
    end

    it "should properly split an ascii string when n leaves 1 character" do
      @it.utf8_safe_split(5).should == ["abcde", "f"]
    end

    it "should return a nil remainder if the string has less than n characters" do
      @it.utf8_safe_split(7).should == ["abcdef", nil]
    end
    
    it "should return a nil remainder if the string has exactly n characters" do
      @it.utf8_safe_split(6).should == ["abcdef", nil]
    end
  end
  
  context "For a string containing a 2-byte UTF-8 character" do
    before(:each) do
      @it = "Café"
    end


    it "should split properly just before the 2-byte character" do
      @it.utf8_safe_split(3).should == ["Caf", "é"]
    end

    it "should split before when n is at the start of the 2-byte character" do
      @it.utf8_safe_split(4).should == ["Caf", "é"]
    end

    it "should split after when n is at the second byte of a 2-byte character" do
      @it.utf8_safe_split(5).should == ["Café", nil]
    end
  end
  
  context "For a string containing a 3-byte UTF-8 character" do
    before(:each) do
      @it = "Prix €200"
    end


    it "should split properly just before the 3-byte character" do
      @it.utf8_safe_split(5).should == ["Prix ", "€200"]
    end

    it "should split before when n is at the start of the 3-byte character" do
      @it.utf8_safe_split(6).should == ["Prix ", "€200"]
    end

    it "should split before when n is at the second byte of a 3-byte character" do
      @it.utf8_safe_split(7).should == ["Prix ", "€200"]
    end

    it "should split after when n is at the third byte of a 3-byte character" do
      @it.utf8_safe_split(8).should == ["Prix €", "200"]
    end
  end
  
end

So to fix this I came up with a pretty simple idea, split the string and check to see if the second part is valid UTF-8:

class String
  def valid_utf8?
    unpack("U") rescue nil
  end

  def utf8_safe_split(n)
    if length <= n
      [self, nil]
    else
      before = self[0, n]
      after = self[n..-1]
      until after.valid_utf8?
        n = n - 1
        before = self[0, n]
        after = self[n..-1]
      end      
      [before, after.empty? ? nil : after]
    end
  end  
end

In RiCal, I actually implemented this using functional methods in another object, since I didn't want to 'pollute' Strings instance methods, but the code here illustrates the basic idea.

After a few weeks of maturation on github, setting up a bug tracker, and a google group for project discussions, the bug reports died down to the point where I felt comfortable putting a more "official" release out on rubyforge.

Thanks to my most active 'beta-testers', Adam Williams who really drove the calendar generation DSL, and Paul Scott-Murphy, and Bruno Duyé gave a much needed workout to occurrence enumeration.

With folks from Australia and France providing input, it felt a bit like the old OTI days

I pushed version 0.0.6 of RiCal to GitHub. So far it seems to be getting a fair bit of interest. To-date 52 github users are following the project, and 7 have forked it, several of whom have send pull requests for patches and or additional specs when they discover bugs.

I should also mention that I've set up a google group for discussing the library. Anyone can join, but I've got it set so that I need to moderate a new users initial posting.

Run>Code>Run is also keeping an watchful eye and doing continuous integration testing of pushes to github. So far once Run>Code>Run installed the tzinfo gem all the commits have successfully tested.

And finally, Mirko Stocker, who writes for InfoQ, contacted me shortly after I made my low-key announcement of RiCal, and asked me if I would do an email interview. You can see the results of that request here.

Well, "a day or two" turned out to be a little more like a week, and the official release is still a bit in the future, but I've just published an unofficial version of ri_cal on github.

I've been working with Adam who is using github for a Rails app. He's been feeding me bugs to fix and features to add. Most of the work in the past week has been on developing the "DSL" for creating calendars and events programatically. There are a few loose ends to tie up but if you are adventurous, you might want to play with the library. There will likely be some api changes before the initial release.

When I'm ready to make the "official" release, I'll publish it to RubyForge as well as to git hub, and the version will be bumped to 0.x.0 once I've decided what x should be.

RiCal represents a considerable effort over the past several months. I hope someone besides Adam finds it useful.

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

multiruby_setup the_usual
multiruby_setup update:rubygems

multiruby -S rake spec

multiruby -S gem install rspec

def in_outer_cycle?(candidate)
  candidate && (outer_range.nil? || outer_range.include?(candidate))
end

def in_outer_cycle?(candidate)
  candidate && (outer_range.nil? || (outer_range.first <= candidate && outer_range.last >= candidate))
end

    it "should properly format dtstart with a date-time with a local time zone" do
      @it.dtstart = date_time_with_tzinfo_zone(DateTime.parse("4/22/2009 17:55"), "America/New_York")
      @it.export.should match(/^DTSTART;TZID=America\/New_York;X-RICAL-TZSOURCE=TZINFO;VALUE=DATE-TIME:20090422T175500$/)

     # Return a string representing the receiver in RFC 2445 format
    def to_s
      if visible_params && !visible_params.empty?
        "#{visible_params.map {|key, val| ";#{key}=#{val}"}}:#{value}"
      else
         ":#{value}"
       end
    end

     # Return a string representing the receiver in RFC 2445 format
    def to_s
        # We only sort for testability reasons
       if (vp = visible_params) && !vp.empty?
         "#{vp.keys.sort.map {|key| ";#{key}=#{vp[key]}"}.join}:#{value}"
      else
         ":#{value}"
       end
    end

    it "should properly format dtstart with a local time zone" do
      @it.dtstart = date_time_with_tzinfo_zone(DateTime.parse("April 22, 2009 17:55"), "America/New_York")
      @it.export.should match(/^DTSTART;TZID=America\/New_York;VALUE=DATE-TIME;X-RICAL-TZSOURCE=TZINFO:20090422T175500$/)
   end

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.

Joe Van Dyk, a reader, posted a question in response to my recent article about my work towards a new gem providing iCalendar support for Ruby

How do people represent recurring events in a database? I’ve never been able to come up with a good way.

My particular problem is that each event that reoccurs needs to be able to be worked with individually (i.e. comments added to it), deleted, moved, etc.

Rather than answering directly in the comments section, I'll give my thoughts on this as a new article

My approach to this would start with recognizing the difference between an event, and an occurrence of that event. Each event would be stored as a single entity on the database, no matter how many occurrences that event had. Each event entity would have a start date-time which would be the start time of the first occurrence, and a last occurence end date-time which would be the end of the last occurrence if the event had a defined last-occurrence, or null if the recurrence set was open ended.

A non-recurring event would be handled as a degenerate case of a recurring event, with a single occurrence.

The idea is to allow for a database query which returns the set of (recurring) events which have any occurrences between two, points in time. The use-case here is displaying a calendar page, where I need to find all of the events for a given, day, week, month, etc.<\p>

Once I had those events, I'd ask each one for a list of occurrences within the target range, which for some events and some ranges might be empty.

Individual Occurrences

As Joe points out there are time when you need to talk about individual occurrences of an event. RFC 2445 talks about this. There are basic mechanisms in iCalendar to support use-cases like editing a series of recurring events. So iCalendar, defines three attributes which combine to connote a particular event, set of occurrences, or a particular occurrence

UID

A globally unique identifier which identifies a particular event with all of it's occurrences. The set of occurrences may change if the event is edited, with different edits being identified by the ...

Sequence Number

The revision sequence number of a calendar component, in this case a VEVENT, with a given UID

Recurrence-ID

Which represents either a particular occurrence of an event identified by a UID and sequence number, or subsequence either at the beginning or end of the list of occurrences for an event. The value of the recurrence id is a string containing either:

1. A string representation of the start time and date for the occurrence or
2. A string representation of the date of the occurrence in the case of an anniversary (all-day) event or
3. Either of the first two, preceded by "THISANDFUTURE:", indicating all occurrences starting with the one identified by the date or date-time or
4. Either of the first two, preceded by "THISANDPRIOR:", indicating all occurrences starting with the first through the one identified by the date or date-time or

I'd put any attributes associated with an individual occurrence into a separate entity belonging to the event, which would have many of these, and identified with a recurence-id.

Just a word of caution, here. This article reflects a mixture of things I have actually done in the past, with some thought experimentation. I haven't actually had to deal with attributes for occurences, but what I've described 'feels right' to me as a first approximation.