Talk Like A Duck

Yesterday, Travis Griggs posted an interesting article on his blog about a couple of tricks he used to write a test which needed to ensure that a race condition actually happened during the test.

And Randal Schartz just discovered it too. These two posts point out some interesting similarities and differences between Ruby and Smalltalk.

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

Here's another video from Ward in which he shows the working environment at AboutUs and talks a bit about the connection between his conception of wikis and agile programming.

In an evolution of the recommended extreme programming workspace setup. AboutUs gives everyone a desk on wheels rather than undedicated pairing stations, so that developers can rearrange the configuration to match who they want/need to work with at the time.

About a week ago, Pat Eyler, who writes the "On Ruby" blog contacted me to ask if I would be willing to participate in one of his "Questions Five Ways" theme articles.

Pat picks five people who he thinks would make an interesting mix, throws a question at them to start a discussion, then sits back and lets the exchanges fly, then weaves them into an article.

So I had a very enjoyable several days discussing the topic with Steve Yegge, James Edward Gray II,, Diomedis Spinellis, and Don Stewart.

The result can be seen here.

I just ran across a reference to this article by Alex Sandler, on how C++ implements "object-oriented" concepts.

It's a more detailed, and probably more recently researched, coverage of a topic I briefly covered in my RubyConf 2008 talk. If you understand this stuff, you have an appreciation why a compile-time static typed, run-time weakly typed language like C++, as compared to a run-time typed language like Ruby or Smalltalk, makes it crucial to avoid tricking the compiler into thinking that an object is of the wrong type.

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.

This started out with a question on the RSpec group about why debugger invocations in Cucumber steps seemed to be ignored.

Now, I didn't know the answer to that, but I did have a bit of related knowledge since one of my contributions to RSpec was adding the --debugger/-u option to the spec command as an analog to the same option in the script/server command in Rails. As far as I know that option hasn't been added to Cucumber.

Which led me to refreshing myself on how Rails implements that option in order to help answer the Cucumber question. So I brought up the rails gem in textmate on the latest version of Rails, and had a minor epiphany.

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.