Input Output Disconnect

I think its interesting that calendaring tools can understand the definition of complicated event reccurence rules, as well as exchange those definitions in a powerful standard format, but that the user interfaces on the tools I have used (ical, google calendar) don’t actually support creating events with anything more than the simplest recurrence relationships… Goes to show that the bottleneck in many systems is still the interface between the human and the computer.

The other day I received my first $50 parking ticket of the street cleaning season. The rules on my street, even side cleaning on the second and fourth Wednesday, odd side cleaning on the first and third Tuesday seem simple enough to follow, but I still think Somerville’s chief revenue stream must be parking violations.

I thought perhaps I can set the events in iCal, upload that file to google calendar, and get SMS reminders. Turns out one can’t specify a recurring event like second and fourth Wednesday in iCal or google calendar. iCal’s interface allows one and only one “nth day of the month” recurrence. This made me wonder – is this stuff even possible in the iCalendar format?

So I checked the iCalendar spec in RFC2445 and sure enough, it supports powerful enough recurrence rules to handle any conceivable event schedule. Here’s an example that will handle the odd side street cleaning, April through November of every year:


I edited the one 1st Tuesday rule generated by iCal in a text editor to arrive at this iCal file. Imported it back into iCal, and it rendered the recurrences perfectly. Google calendar also reads the file well even saying under details “Every first and third tuesday”.

Its a shame there’s all this underlying power, yet the user interface allows only a small sliver of it. The 80/20 rule probably dictates an organization doesn’t put in the resources to develop and support a really complicated UI for creating event reccurences, but I would think some user facing tool would support that. Are there any out there?

Not Quite Murphy’s Law…

Is there a name for the phenomenon described below?

  1. One has a problem developing or building something for some long period of time.
  2. In frustration makes a post to a newsgroup or other source of public support.
  3. A very short period of time later figures it out on his or her own.

It can’t be murphy’s law, because something went right for once. Or is it just something going wrong in a twisted, different way?

I was working through some tutorials for Macromedia/Adobe flex today, and was having some strange problems with the second tutorial (build a calculator) and not more than 30 minutes after posting to a yahoo group “flexbuilders”, I find the faulty configuration responsible.

Adventures In ActionScript

Once again, post work nap out of the way, I resumed doing my homework project and learning flash in the process. It seems (like most things) there are many different ways to use flash. On one extreme you can use the timeline along with automagic tweening functionality and very minimal scripts to lash things together, or you can go to the other extreme and use it as a visual programming environment, using object-oriented (well as OO as JS/AS get) externally defined scripts for everything. Being a programmer, I chose the latter.

One of the problem’s I’ve had is resolving fields in the various namespaces, particularly finding one “movieclip” from another. Its odd that everything useful has to be a movieclip or a button, and that you can only apply certain graphic filters to those type of objects. Back to the namespace issue – now that I seem to be able to properly find objects from one another, I encountered the problem that function objects in JS/AS don’t know what object instances they’re associated with like they would in Python. So setting a button’s event handler to call one of the functions in either approach below won’t work: (I wish I new why the editor in WordPress is effectively double spacing the text below by inserting break tags)

/* approach one :
* fails because doSomething will not be bound to this instance
this.myButton.onRollOver = this.doSomething;
/* approach two:
* fails because this is not pointing to the right thing when it is executed
this.myButton.onRollOver = function() { this.doSomething(); };

At this point I picked my roommate Phil’s brain because he’s always crawling around the obscure guts of languages like this, and found out some of these strange consequences of Javascript not really being OO – that the this pointer sucks and the above facts about the capabilities of function references.

Big thanks to him for pointing out this simple way to fix the problem using a closure:

var a = this;
this.myButton.onRollOver = function() { a.doSomething(); };

And for reminding me that you can do something like MochiKit does in their bind function to make “real” function pointers that know what instance they belong to (in a really stripped down form below)

class BindUtil {
static function bind(obj,func,args) {
return function() {
if (args != 'undefined')

Because that function makes it possible to pass arguments, one can easily define one handler to use for various buttons inline like this:

this.tempMinusBtn.onPress = BindUtil.bind(this,this.changeTemp,[-1]);
this.tempPlusBtn.onPress = BindUtil.bind(this,this.changeTemp,[1]);

So I’ve got one working dialog for my prototype due on Tuesday, but this is more functional that a lot of the rest will be. Its a screen from a inflight entertainment system we’re prototyping. The screen linked below is the climate control dialog that will fly in from the side to adjust temperature etc. The close button does nothing.

Flash Demo (Requires Flash Player 8 )

Only now do I notice that the control areas aren’t centered. I guess I’ll fix that later.

Interesting Java Snippet

I was at an interview yesterday and got something like this snippet as a test.

Apologies for the lack of tabs,
whatever I try to put them in,
wordpress defeats me.
public class ExceptionTest {
public String method1(){
try {
return method2();
catch (Exception e) {
return "method 1";
public String method2() throws Exception {
try {
throw new Exception();
finally {
return "method 2";
public static void main(String [] argz) {
ExceptionTest et = new ExceptionTest();

I was asked if I thought the finally block in method2 would execute before the catch in method1? So I puzzle over that for a while,
trying to determine how the stack would unroll, particularly in light of the finally block returning a value. I think my guess was pretty good.

I went ahead and tested it to see what actually did happen, and it turns out that returning from a finally block as in this example generates a compiler warning, and gleefully prevents the catch block from even executing, resulting in the program printing out “method2”. If the return is removed from the finally block, finally still executes before the catch block, as expected so that it can clean up the local state of that stack frame, and the program prints out “method1”.