Life & Research Notes

Yesterday during a sponsorship-related lunch with the New York Times Company I was lucky enough to be seated across from General Counsel and Vice President Kenneth Richieri. I mentioned to him my interest in this social contract system, and he had a a number of noteworthy tips from his legal and finance experience. Among them, he mentioned an organization called the ISDA that publishes and maintains a very important document called the the ISDA Master Agreement. This agreement is the standardized template contract used in OTC derivative trading. Universal acceptance of this contract vastly reduces transaction costs for traders, resulting in increased market efficiency. From their site:

The ISDA Master Agreement, the authoritative contract widely used by industry participants, represents a milestone achievement because it has established international contractual standards governing privately negotiated derivatives transactions that reduce legal uncertainty and allow for reduction of credit risk through netting of contractual obligations.

After reading up on finance to get most of my terminology straight, I’m renewing my interest in these sorts of streamlined contracts. How can we take what ISDA has done for derivatives and apply it to the diverse and dynamic contracts and agreements used by individuals and small businesses? There are technical and design issues of course, but fundamentally much of the challenge lies in the crafting of a trusted, accepted organization.

We can think of contracts as a set of events that should happen over time. Perhaps the times are fuzzy or relative to one another, or perhaps they are strict. Either way, there is some passing of time. We can perhaps capture this with a little timeline:

This diagram looks like something a project manager would draw. There are perhaps some connections between a project and a contract, since the participants in both must plan out how to deal with the various events and requirements.

Now if we have a few of these contract timelines things are more interesting. We can get a sense for the multiple contracts that a person is engaged in at any given time. They are like tracks in a sequencer, only instead of music we are looking at real life events and expectations:

This particular metaphor may break down if the contracts are more like programs with various control structures like loops, conditionals, subroutines, or even recursion (what is a recursive contract?). The contract won’t be linear. It will have loops, since certain tasks may come up multiple times. Or if it is recursive it will have spirals. How do we represent the same task happening repeatedly at different times? Is it really the same task, or another instance of an abstract task? For now we can draw it as looping, but then we lose the effect of the timeline, which is unfortunate.

I’m not sure where this is going, just some notes for tonight. At the very least the timeline view can be used retrospectively on contracts that are already complete.

1. Innocence. Create a cute, simple little ajax application with Luis. Make it work decently with most browsers. Make it easy. Allow people to do something that they normally wouldn’t think to do, but that they may find fun.
2. Satisfaction. Tell your advisor about your app. Make a screencast. Wake up to see that your advisor has blogged your app. Maybe some people will use it! A few new icons begin to show up. How nice.
3. Happiness. Notice that your app is in the del.icio.us popular feed. How wonderful you think. Post your own app to digg, since maybe the people there will appreciate it. Go to bed with only one other person having digg’d it.
4. Sleepiness. You just woke up and had some nice tea. Go to computer. Look at digg feed and notice your app in there. Feel surprised and happy. Look at the site. It is very slow, like you.
5. Smugness. Something you made is getting digg’d. People love it, and by extension you. Love yourself, and all those around you. Consider staying for a PhD.
6. Stress. Something you made is totally getting digg’d. It is getting very slow. Worry about the hopelessly unscalabale UI, not to mention the new server that you can only hope you set up properly. Make changes to try to make it faster. Wonder why you are worrying so much about something that started out as a fun project. Worry about the worrying. Also wonder why you are working hard just so all these strangers can draw small genitals and swastikas. Tail -f the server log while you work. Notice that it is generating hundreds of icons per hour. Briefly consider that icons per hour is a very new metric.
7. Relief. It isn’t the biggest story on digg. It is slacking off. The app made it. You made it. Go home and watch the latest netflix with your girlfriend.

For something that started as a little “PLW Basic Research” project, Tiny is turning out to be a lot of fun. Now seems like a good time to post a screencast (Quicktime / 6.4MB):

The next iteration will include a fancier tree-based browsing system to reveal which icons are created based on others. I hope to have that up before the end of the week. Fatbit love…

Yesterday Luis posted on some of our recent collaborative activities revisiting the simplicity of the straight line, and he included some images and examples showing our attempt at recreating Bresenham’s Line Algorithm. What he didn’t mention was our very happy accident when we screwed up the horiz vs. vertical condition in our algorithm:

The buggy part of the code looks like this:

public void drawLine(int x, int y) {

    fill(0);
    noStroke();
    rect(x,y,1,1);

    if(x == M || y == N) return;

    int xDelta = M - x;
    int yDelta = N - y;

    if( (M - xDelta) / xDelta < (N - yDelta) / yDelta) {
        drawLine(x+1,y);
    }else{
        drawLine(x,y+1);
    }
}