Peter Williams

I ♥ DVCS

This week I worked on a project that uses Subversion and, man, what a difference a year makes. Back then I dreamed of being able use Subversion instead of Perforce. Now using svn feels a bit like walking around waste deep in water.

I have been using Git almost exclusively for the last couple of months. I am now firmly convinced that distributed version control systems, such as Git and Mercurial, are the way of the future. The basic model of dVCSs matches with real world software development much more cleanly that the model imposed by most (if not all) centralized VCSs.

Consider the scenario I ran into, I checked out an svn project and made my changes, then I svn up-ed and found one of the files I had edit had been changed in a way that resulted in a merge conflict, and a fairly complicated one at that. I manually resolved the conflict, merging the files by hand, and the commit the merged file, but what if I had gotten it wrong? My version of the file was never stored. Which means that after doing the svn resolved the merge cannot ever undone or fixed.

svn up is a branch merge which throws away the entire history of the target branch. Working directories are branches whether the VCS acknowledges it or not. Not acknowledging it simply results in branches in which the history is not tracked. A branch that does not track its history sounds silly. Because it is. None the less, that is the model that is forced by most VCSs.

Distributed VCSs, on the other hand, treat your working directory as the branch it really is. And that makes all the difference in the world.

OpenID 2.0’s Killer Feature

The OpenID 2.0 spec has been finalized. On the surface, it does not seem to be very different from the 1.1 spec but it does include at least one sweet new feature. It provides protocol support for directed identity.

Directed identity is the concept of having a single identity that appears to be a different identity for every relying party (ie, an application that wants to verify your identity). The identity provider would, of course, understand that all these single use identities are really all part of the same identity. This would, theoretically, prevent unscrupulous people from building a profile about all the things you do online, because each website you visited would know you by a different identity. However, you could still log into all those websites using the same credentials since the identity provider would know that all those single use identities belong to you.

The change that was made to the OpenID protocol to support directed identity is brilliantly simple. It amounts just defining that if a provider receives a normal authentication request with a predefined URI¹ as the identity that the request is a directed identity request. The provider would then verify the user’s credentials and respond with the appropriate identity for the relying party. The OpenID provider responses always include the identity being verified so it turned out to be a very minor change to support that in our provider.²

Now, just to be clear, I don’t actually have any use for directed identity in the applications on which I work. However, the protocol mechanism that supports directed identity can also be used to implement multi-application single sign-on. And that is a killer feature for the stuff on which I work.

For maintainability, we have divided our application into five³ separate components. This works great as a way to keep the code simple, the architecture comprehensible and the system distributable. However, in the past, it left a bit to be desired with regards to the user experience because a user was forced to login five different times just to use the different sections of the application. Well, actually, we have been using OpenID for a while so the user did not actually have to login five time, but the did have to type in their user name five times. And that is not any better.

The directed identities support in OpenID 2.0 provides a solution to this repeated challenge problem. Each supplementary application discovers the trusted OpenID provider for the system and the performs a direct identity authentication request against that provider. The provider figures out who the user is and conveys that information to the supplementary application in the id_res response.

This means that once you have logged into any component of our system you will never the asked for your identity info again. We may make half a dozen requests to determine and verify your identity when you navigate to a component for the first time but all that work it is completely seamless from the users point of view. To the user it seems like just another page in the application.

How REST Can Relieve Your (Lack of) Documentation Guilt

A couple of months ago we hired a contractor to write a reporting interface for our high volume monitoring system. Our system exposes all of it’s data in RESTful web services, and his job has been to take that data and allow users to create reports based on it.

This morning a couple of my teammates and I asked him if he thought our documentation was sufficient to allow supplementary applications, like the one he was finishing up, to be written without having direct access to the developers. He replied to this effect,

To be honest, I did not really look at the documentation. I just fetched the URLs you gave me, and the ones I found in those documents, and so on. It did not take me very long to get a pretty good idea of what kind of data was available and where.

That ability to understand a large system by simply exploring it is one of the most powerful features RESTful architectures. But only if you are using all the precepts of REST, including that resources are represented by documents with links¹ (or, hypermedia is the engine of application state, if you prefer a more traditional phrasing).

A RESTful architecture will let you scale, and distribute your application beyond all reasonable expectations. But even better, since you know that anyone who cares can just go exploring, it will also let you feel less guilty about not writing all that documentation that you never quite get around to.

The Sad State of Mobile Phones

The current crop of phones are depressingly lame. I am currently using a Samsung t519. It has served me well for pretty close to two years now. My two biggest complaints with it are that phone allowed T-Mobile to permanently hijacked the right soft button, and that is, perhaps, a tiny bit too thick. That second complaint is particularly unfortunate given the fact that I believe it to be the thinnest phone ever available in the US.

A few days ago I dropped my phone. It still works but case cracked so I decided that it was probably time for a new phone. Two years is a pretty good run for a phone. So I mossied over to my local T-Mobile kiosk to take a look at what is available. Man does the selection suck. The are all bricks with absolutely no sense of style. Hell, my very first cell phone, the Nokia 2190, (in 1997) looked almost as good as most of the phone available today. And it was only a little bigger.

How is it that phones have gotten less interesting, and larger, in the last two years? I guess I am not the target market for phones being produced today. If someone where to produce a thin candy bar with a decent sense of style and a reasonable feature set I would definitely be interested. Until that happens I think I am just oing to continue to use my two-year-old-but-still-better-than-anything-that-is-available-today phone until it actually stops working.

When To Use Exceptions

Marty Alchin recently posted about the “evils” of returning None (or nil or null depending on your language of choice). I think he has it basically right. Sure there are situations where returning nil¹ is appropriate, but they are pretty rare. For example, if a method actually does what the client asked and there is nothing meaningful to return, then by all means return nil. If, however, the method was not actually able to do what the client asked, raising an exception is the appropriate thing to do. Unfortunately, I think that most methods that return nil in modern libraries and programs actually do so as a way to indicate a failure condition, and that is evil.

Cédric Beust responded to Mr Alchin saying basically, a) “problems caused by returning null are easy to debug” and b) “programmers are all knowing, about now and the future, so they can decide when to return nil and when to raise an exception.” (I am, as you might have guessed, taking significant liberties in my para-phrasing. You should go read Mr Beust’s post if want to know what he actually said.)

Ease of debugging

On the debugging point I would say that Mr Beust is generally correct. It is usually the case that nil returns are fairly easy to debug. However, this is not always true. In fact, it is not uncommon, in my experience, to find a nil where it is not suppose to be but then to spend a fair bit of time tracking down where that value became nil. That time is usually spent walking my way up the call stack trying to find the subtle bug that results in a nil return from a method in only some odd situations.

That sort of debugging is not the end of the world but it is annoying particularly because it is so easily avoidable.

All knowing programmers

To be fair, Mr Beust did not actually say that he believes that programmers are all knowing. But he did describe a way of using exceptions that would only make sense if programmers were all knowing. From that, one might infer that he does believe that programmers are in fact omniscient. In my experience this misconception is fairly common in the Java community (Actually, this mentality exists to varying degrees in most programming communities) . Java itself includes many decisions that seem only to make sense in the presence of this assumption. But I digress.

The statement to which I am referring is

Here is a scoop: exception should only be thrown for exceptional situations. Not finding a configuration value is not exceptional. Not finding a word in a document is not exceptional: it can happen, it’s even expected to happen, and it’s perfectly okay if it does.

My response to this is: Who exactly are you to decide that not finding a configuration value is a non-exceptional event for my application? Library programmers² should not be deciding what is and is not an “exceptional” event. That is a value judgement they cannot possibly make correctly, unless they understand every way that every program will make use of that library (or class) in perpetuity.

Exceptions are not about “exceptional situations”, whatever that means. They are a way for methods tell their caller that it was not able to do what the caller asked it to do. If I say, “dictionary give me the value associated with a particular key” and the key does not exist, the appropriate response is a NoSuchKey exception. Returning a nil in that situation is a lie. A lie with real, and negative, consequences. Consider this, I ask a dictionary for the value associated with a key and it returns nil. Does that mean the key does not exist, or that the key does exist and it’s value is nil? Those two are very different but a nil returning method conflates them requiring, at the very least, an addition method call figure out which possibility is actually the case.

If having methods actually inform you of their inability to perform the desired action is complicated or hard to understand it is time to upgrade your language or write a better interface. For example, if catching an exception from a dictionary look up complicated for the cases where you just want to use a default value, that exception catching and default value behavior could easily be put in a get_with_default(key, default_value) method that either returns the value from the dictionary or the default value. That would certainly be clearer than returning nil and having every consumer add an ugly if block after the get. Or you could switch to a language (such as Ruby) with a compact single line exception handling syntax.

Either way my advice is: Do not use nil as a way to indicate that the object was unable to perform the requested operation, that is job of exceptions. If you see a method that returns nil demand an affirmative defense for that behavior because it is often incorrect.