Heather McLean

As another code exercise, I decided to look at RFC 4122 (“A Universally Unique IDentifier (UUID) URN Namespace”) and create an object in C# that was capable of handling all five versions presented in that document. I wanted to see if I could successfully interpret the algorithms as described by the document without looking at any reference implementations.

I think in the end it was quite successful and offers a pretty robust implementation of version 1 through 5 UUIDs, including a version 4 UUID which is compatible with the native System.Guid implementation. There is one class called Uuid which can represent any version of UUID, and it is used similar to the aforementioned System.Guid to either create a new unique identifiers or represent existing ones. It also supports explicit casts to/from System.Guid.

Uuid existingUuid = new Uuid("9b1ea5f8-702b-4ad5-97f0-34bb10a28602");
Uuid newUuid = Uuid.NewUuid(Uuid.UUID_VERSION_1);

A battery of unit tests is also included to help verify the implementation. You can download the code from my Code page as usual.

My new Code page is now online, where you can download some of my little project exercises. You’ll find the REST web services project I talked about a few weeks ago, as well as a lightweight inversion of control container. I’m releasing these projects as public domain since they were really just exercises and not full-fledged usable codebases.

After a discussion of the merits of various web service technologies with a colleague of mine, I decided to do a little programming exercise. I felt I hadn’t really gotten to do any seriously complex programming in a while, so it was nice to exercise my brain a bit and learn some new things. I basically implemented a REST web service stack in .NET. It has both a server and client model. For the client, it’s as simple as decorating an interface:

[RestWebClient(Url = "http://local.yahooapis.com/MapsService/V1")]
public interface IYahooTrafficService : IRestWebService
{
    [RestNoun("trafficData", Method = RestHttpMethod.GET)]
    [return: RestReturnType(RestReturnType.Xml)]
    XmlDocument GetTrafficData(string appid, string street, string city, string state);
}

The example here uses the Yahoo Traffic Data API. Once the interface is created, I can get a concrete instance through the RestWebClient factory:

IYahooTrafficService svc = RestWebClient.Create<IYahooTrafficService>();
XmlDocument xdoc = svc.GetTrafficData("YdnDemo", "1771 LBJ Fwy", "Dallas", "TX");

And voila! Traffic data:

Example of output from the Yahoo! Traffic Data API.

Pretty simple, and it works with a variety of REST interfaces. It can also handle complex types through XML and binary serialization as well as straight binary streams, such as image files. The server piece works similar to the client; decorate a class with attributes to describe the service contract, and an HttpHandler does the rest.

This was particularly challenging on the client piece because I had to learn the System.Reflection.Emit namespace, which I had never used before, and it requires an in-depth knowledge of MSIL. So that was difficult at first, frustrating most of the time, and rewarding in the end.

At some point I would like to clean up the code and release it as open source. Some other folks might actually find it useful. It definitely needs some heavy refactoring first, though.

“Waste”—it’s an ominous word by itself, and in the world of Lean principles, it’s the one thing you’re striving to eliminate. Waste can be defined as that which adds no value to a project; i.e., those things that you are spending time and money doing, but they don’t move the project forward. Software projects are often full of waste, and in such an imprecise discipline, it can be difficult to identify the sources of waste. In fact, a lot of times we end up running in circles, attempting to clean up the symptoms rather than the causes.

In my experience, the one largest source of waste that can be eliminated or reduced to add immediate benefit to a project is rework¹. Rework falls into two major categories:

• Technical debt
• Defects

Read the rest of this entry »

I’ll admit this is a little bit of geek porn today, different from my usual fare. Google has released a new algorithm for sending software updates dubbed Courgette. In particular, I found the section on “guessing” intriguing:

We can think of a differential update as a prediction followed by a correction, a kind of guessing game.  In its simplest form (just bsdiff / bspatch), the client has only a dumb guess, ‘original’, so the server sends a binary diff to correct ‘original’ to the desired answer, ‘update’.  Now what if the server could pass a hint that could be used to generate a better guess, but we are not sure the guess will be useful?  We could insure against losing information by using the original and the guess together as the basis for the diff…

This system has some interesting properties.  If the guess is the empty string, then we have the same diff as with plain bsdiff.  If the guess is perfect, the diff will be tiny, simply a directive to copy the guess.

A predictive software update engine has some interesting potential. I would love to see with what kind of accuracy their algorithm can actually “guess” the correct patch.

I’m not ashamed to admit that a recent post from Dave Nicolette reminded me of myself. After spending most of the past year being indoctrinated with Scrum, it is very, very tempting to start trying to apply iterative development to everything. I mean, why not? Iterative development is superior, right?

As with all things, the answer is “not always.” With my current project, the temptation is high. The organization and the project already exhibit several agile/XP qualities:

• Continuous integration.
• 30-day release cycles.
• The project has already been broken down into smaller chunks of deliverable features.
• We do daily status meetings. (Although they are an hour long and much less focused than a daily stand-up.)

As you can see, it has the potential… on “the cusp of greatness,” you might say. It would be tempting to think that we could just overlay Scrum or some other form of iterative development and succeed, and trust me, it is very difficult to resist that urge to evangelize Scrum. However, there are several factors that mean I must take a healthy dose of reality first:

• The organization has no agile history, and I would bet that 99.9% of the managers and developers have never heard of agile development, let alone practiced it.
• The “product owner” currently lacks the discipline/desire to commit to a set of requirements for any length of time. (We would be aborting sprints right and left.)
• Policy prevents us from actually working on anything until it is completely designed and documented. (Of course, the policy is not always followed 100% of the time.)
• The developers are not accustomed to self-managing.

Those are just a few off the top of my head. As you can probably imagine, trying to throw Scrum into the mix here would not work out so well. On top of the above hurdles, it would be a hard sell to management, and I have a feeling any initiative would be quickly abandoned if positive results were not immediate.

Still, that doesn’t mean I’m not going to try at some point. I just have to be subtle and introduce things one step at a time rather than going whole hog from the beginning.

The Discipline of Agile (followed from a post on Mr. Appelo’s blog) made me pause and think. Mr. Ambler’s article does an excellent job of breaking down agile into some key disciplines:

1. Regular Delivery
2. Quality
3. Active Stakeholder Involvement
4. Scale
5. Teamwork

I was thinking, though, that the list was far too specific. Some of these things are results of similar disciplines—for instance, Active Stakeholder Involvement and Teamwork are both principles of good communication. Others are esoteric, such as Scale.

I decided to reorganize these disciplines a bit and change them around, hopefully making them more broadly applicable to agile processes. Below are what I believe to be the disciplines of an effective agile/lean project.¹ Read the rest of this entry »

As a matter of course, I like to follow Jakob Nielsen’s Alertbox posts (as I have been since 1998). Today I think he posted for the first time regarding Agile methodologies:

Agile Development Projects and Usability by Jakob Nielsen

If I didn’t know better, I’d say he has some disdain for Agile, but he makes some good points on how Agile can threaten a project’s user experience.