www.hans-eric.com

If you are a defensive programmer like me, you make heavy use of assertions to guard assumption you make in your code. For example, a method for adding an order item to an order object could look something like this:

class Order
{
  private List orders;

  int addItem(OrderItem item)
  {
    assert(assigned(item));
    item.order = this;
    assert(assigned(items));
    items.add(item);
    assert(items.count > 0);
    return items.count;
  }
}

This style of programming adds some clutter to the code, but makes the program more robust and reliable over time.

The D Programming Language have built in support for contract programming and I have been curios to see if that can be an alternative to my defensive programming style. At first look it seems to be a close match. Both techniques allow you to make safe assumptions in business logic code. The difference is where you put your defensive code.

In contract programming, or Design by Contract as it was originally called, there are the concepts of pre- and postconditions, conditions that are expected to be met on the entrance to and on the exit from methods. Additionally you have the concept of class invariants, which asserts a certain state before and after (but not during) a method call.

So, a transformed contract programming version of my defensive style example above could look something like this:

class Order
{
  private List orders;

  invariant { assert(assigned(items); }

  int addItem(OrderItem item)
  in { assert(assigned(item)); }
  out {assert(items.count > 0);}
  body
  {
    item.order = this;
    items.add(item);
    return items.count;
  }
}

This may not seem like less clutter but it does two important things: First it separates the defensive code from the business logic. Pre- and postconditions are neatly placed in in- and out-blocks, while business logic dwells in the body-block.
Secondly, general assertions that may need to be checked in every method of the object (like checking that the orders list in the above example is assigned), are handled in in place: the invariant block. Nice and DRY.

It seems like I could use Contract Programming for the same purposes as the normal defensive programming technique, but there are a couple of issues that keep me from taking the step:

1. I’m not sure how preconditions and postconditions are affected in an override scenario. The language specification says that preconditions are OR’ed together, meaning that if one precondition passes the others are ignored. My own tests show a different behavior, but I need to take a closer look to be sure.
2. Contract Programming and Normal Defensive programming are conceptually two very different things: Contract Programming, like the name suggests, are taking place in between the programming interfaces of objects, while the assertion defensive style is more general. You can say that Contract Programming defends the Program Design against abuse, while the defensive programming style defends the implementation against unexpected events.
3. Contract Programming moves the defensive code away from the code that benefits from its protection. This could become a maintaining problem.

I currently feel that Contract Programming should be used only in the context for which it was created: big projects with many developers, where a massive (not agile) design phase precedes an equally massive phase of implementation. But, I’ll probably use class invariants to DRY up my general asserts where applicable.

In my previous post I’m afraid I exposed my inexperience in the world of floating point programming. As many pointed out it’s the inherited behavior of the IEEE 754 standard, and, in Walter Brights own words, to change it would break legacy usage. In other words I should direct my concerns about the handling of uninitialized values toward the standard and not hold the D Programming Language responsible.

I still feel awkward, and to some extent astonished, that I can use an expression like (x != x) to check for an initialized floating point value, but not (x != real.nan). This behavior goes against my intuition.

NaN is defined to return false for all the normal comparison operators. The standard would have been better – in my opinion – if it made an exception for the equality (==) and not equality (!=) operators. It would save many of us from being caught by surprise.

Anyway, I guess you can’t fight an IEEE standard, so I hereby drop my case. 🙂

Update:

I read up on NaN:s in the IEEE 754 specification and found that Not A Number is not necessarily represented by one single value, but rather it could be a whole family of them. That complicates things, but the final nail in the coffin was put by Lars Noshinski on the official D newsgroup. He puts it in this convincing way:

“But you’d probably be surprised to see

0.0/0.0 == sqrt(-1.L)

evaluate to true.”

There is no arguing against that. So I guess the answer to the question in the title is: No, the IEEE 754 is just as advanced as it needs to be.

Update 2:

If you (like me) want to learn more about floating point numbers, there is a great sum up in the What Every Computer Scientists Should Know About Floating-point Arithmetic.

The floating point support in the D Programming Language is more advanced than that of standard C and C++. I’m not sure I like every aspect of it though. The thing I’m having problem with is how D handles the special value NAN (Not A Value).

For instance, a simple comparison will always return false if one or both of it’s operands are uninitialized (having the value of NAN). This produces the following unintuitive behavior:

if (real.nan != real.nan)
{
  writefln("It's strange, but you'll always see this text!");
}

I can see the reason why they chose the always-fail-if-NAN semantics for the other comparison operators, but not for equal-to and not-equal-to. In this case I think they went too far in their strive for consistency.

The consequence of the D floating point semantics is this: If you want to assert that a float value is initialized, for example in an invariant block, this won’t work:

class SomeClass {
  real someFieldVar;

  invariant {
    assert(someFieldVar != real.nan) {...}
  }

}

Neither will this:

assert(someFieldVar);

As a side note, if the value of someFieldVar is zero, the above expression would evaluate to false! This is why I never use non-boolean expressions where true or false are expected. I think that should be prohibited by the language.

Anyway, you have two options when checking for an uninitialized value. Neither is – in my humble opinion – particularly beautiful.

First, you could use one of the new NAN-aware binary operators that D introduces, like !<>=, !<, !>=, or !<>. These new operators just give me a headache, they don’t come naturally and I can’t seem to learn them. Here’s the best way I found to check for the uninitialized value using the new floating point operators:

assert(0 !<>= value);

That operator returns true if one or both operands are uninitialized. I don’t feel comfortable with that solution. It’s not obvious what the code does. In that sense, the only remaining alternative is better: using the std.math.isnan function.

import std.math;
:
assert(isnan(someFieldVar));

This is okay, but it feels a little clumsy and backwards using a function. It would have been much better if Walter Bright had used the more intuitive semantics for the normal equality operator. So that I didn’t have to depend upon the std.math namespace, and could write:

assert(someFieldVar != real.nan);

or even better, added a property to the floating point value:

assert(someFieldVar.isnan);

Agile software development techniques have long been utopia for low level system developers. The C programming language has been the most reasonable choice for implementing hardware near applications and drivers; But C was not designed with agility in mind. Hence methods like test driven development has been a pain to implement using C.

Now an alternative exists: The D Programming Language is designed to combine the low level programming abilities and performance of languages like C and C++, with the productivity features of modern languages.

You could describe D as C with features like object oriented programming, exception handling, garbage collection and design by contract. Cool agile features indeed, but D has another one that I instantly fell in love with: built in support for unit testing.

In D you can declare unittest blocks.

unittest {
  assert(sometest, "sometest failed");
}

The unittest construct makes it very easy to practice test-driven development. For instance, lets say we want to create a new type for three dimensional vectors. In order to be test-driven we need to start with the test:

unittest {
  Vector3 v;
}

We compile the program using the -unittest switch.

dmd -unittest test.d

Of course we get a compiler error, Vector3 is still undefined. Lets define it.

struct Vector3 {
}

This time the program compiles. Back to the unittest. Now let’s try a simple assignment.

unittest {
  Vector3 v = Vector3(1.0, 2.0, 3.0);
}

This, again, produces a compile time error. Vector3 doesn’t have the x, y and z fields, so we implement them.

struct Vector3 {
  real x, y, z;
}

The code passes compilation. Next step: implement vector addition. We start with the test.

unittest {
  Vector3 v1 = Vector3(1, 2, 3);
  Vector3 v2 = Vector3(3, 2, 1);
  Vector3 vr = v1 + v2;
}

As we expect, the code doesn’t compile. We need to overload the + operator.

struct Vector3 {
  real x, y, z;

  // Overload + operator
  Vector3 opAdd(Vector3 a)
  {
    return Vector3(0, 0, 0);
  }
}

Now the program compiles, but we don’t know if the add operator produces the right result (which it doesn’t with the current code). To check the result we can use assert.

unittest {
  Vector3 v1 = Vector3(1, 2, 3);
  Vector3 v2 = Vector3(3, 2, 1);
  Vector3 vr = v1 + v2;

  assert(vr.x == 4);
  assert(vr.y == 4);
  assert(vr.z == 4);
}

We compile, and it compiles without error. To run the unittest code we simply run the program. Unittest code is executed after program initialization, but before the main function. If a unittest fails the program terminates prematurely. Our program terminates (as expected) with an AssertError. Lets correct the add operator.

struct Vector3 {
  real x, y, z;

  Vector3 opAdd(Vector3 a)
  {
    return Vector3(x + a.x, y + a.y, z + a.z);
  }
}

It compiles and runs without errors. Great!

As you can see, test-driven development is a very smooth and simple process in D. There is no need for a separate framework, just compile and run your application. Also, the test code dwells close to the production code, which makes it easier to maintain and keep up-to-date. In fact, you can put unittest blocks anywhere in your code, even within the piece of code you are testing.

struct Vector3 {
  real x, y, z;

  // unittest blocks are allowed
  // within structs.
  unittest { ... }
}

Any type of code is allowed within a unittest block. This means that you can declare functions to do repetitive tasks.

unittest {
  function assertEqual(Vector3 a, Vector3 b)
  {
    assert(a.x == b.x);
    assert(a.y == b.y);
    assert(a.z == b.z);
  }

  Vector3 v1 = Vector3(1, 2, 3);
  Vector3 v2 = Vector3(3, 2, 1);

  assertEqual(v1 + v2, Vector3(4, 4, 4));
  assertEqual(v1 - v2, Vector3(2, 0, -2));
}

The test code is only included in the executable if it is compiled with the unittest flag, so there’s no need for a separate test project or conditional compilation. This is a very clean solution, highly suitable for a traditional language that compiles directly to machine code. Although I’m a big fan of testing framworks such as JUnit, I find it much easier to work with the built in unit testing features of D. Of course you don’t have advanced features like mock object support, but I guess that will be offered soon with some kind of unittest-based framework add-on.

If you have doubts about the foundation of the D Programming Language, you should be relieved to hear that it’s been designed by Walter Bright, who have spent almost a lifetime constructing C and C++ compilers.

You’ll find the complete code within my code sample pages.

I am currently employed at a government owned, medium sized company. The company’s IT-division is struggling to satisfy the diverse needs of the other divisions, and is constantly undermanned. One clear indicator of this is multiple project engagement among developers. It has become the default state.
It’s understandable that management give in to the pressure and tries to squeeze the most out of its staff, but unfortunately it is counterproductive. It’s because the more goals you push onto someone, the less commitment he or she can put into each one. And as we all know: if commitment goes down, production goes down.

You form a project to achieve a specific goal, a goal you want to reach as soon as possible. So projects are all about focus, and you can not focus on more than one task at a time. It’s inevitable that you’ll lose time juggling projects. Thus, part time engagement makes projects move slower.

So, what to do? The same things you always do when resources are scarce: prioritize, divide and conquer. Always form teams that work full time on a single project. They will be more productive, and if you’re lucky they might even jell. Let the teams finish before you assign a new task. Instead, see to it that projects are small and can be completed within relatively short time. If a project swells and get big, find the smallest set of features that would still be useful, and form the project around that. Remember, the process of iteration can be applied at the project level too.

Project iteration has several advantages: it increases the closure frequency which helps keeping the teams performance rate high, it increases the chance of success for the individual project, and it releases something useful to the users sooner. And, it provides a constant stream of opportunities for you to make new strategical decisions based on small manageable projects.

To conclude this rather messy post: Don’t mess with my team, let us stay focused and finish what we have set out to do.

Do you work in a team that jell? Then you know the feeling that comes when the team starts to do everything right: solving problems before they even surface, finishing every iteration early, delivering high quality software – while having fun. That feeling is something you will never forget, and you should consider yourself extremely lucky to have experienced it. It’s very uncommon.

One cannot make every team jell. All you can do is provide the basic ingredients and hope for the magic to kick in. All teams in a jelled state have this in common:

• A jelled team has a specific goal, a goal that is shared by all members.
• All members of a jelled team have a high sense of responsibility and commitment.
• All members of a jelled team feel they are accomplishing something of value.
• All members of a jelled team take interest in each others work, since it’s part of their goal.
• The members are enjoying themselves. They long to get to work to spend time together while moving the project forward. Laughter is frequent.
• A jelled team has great communication: with customers, management and in between members.

As a project manager, if your team enters the jelled state you should step back and let the team dynamics do the work. Concentrate on keeping the team jelled, which most of the time is the same as doing nothing at all. Focus on protecting the team from unimportant external interference, and on stuff that boost the team’s confidence and wellbeing.

Appreciation and the sense of completion is very important to keep a team jelled for a long period of time. I once read (don’t remember where) about a team manager that hung a bell in the center of the workplace. The developers were instructed to ring the bell whenever they had done something good. It may sound silly but it’s actually one of the best ideas I’ve ever heard to boost team spirit. Whenever the bell rung people left whatever work they were doing to join the bell ringer and hear about his accomplishments. That team fed appreciation to itself, and provided a constant feeling of accomplishment.

So, how do you know if your team is jelled? Well, one way would be to hang such a bell in a strategic location. If the bell starts ringing on a regular basis chances are good that your team is jelled. If people also leave their workstations to cheer with the happy fellow – then you know for sure.

I have been working on an article for a Swedish computer magazine. The article is to compare Java and C#.NET. In the writing process I have gone through lots of material, mostly articles found on the Internet.

So far the quality of those articles have been varied. Most of them are old and to some extent out of date. But there is one that is high quality: A Comparison of Microsoft’s C# programming language to Sun’s Java programming language, by Dare Obasanjo. This paper was originally written in 2001, but has been updated in 2007 to include the latest changes. If you are either a Java or a C# programmer and have little or no knowledge of the other, that article is all you need to catch up.

During my work on the article of my own, I have come to the conclusion that there are very few major differences between the two platforms. In fact, there is only one difference that makes a difference: Java supports multiple platforms, while .NET supports multiple languages.
In theory .NET could be as platform independent as Java, but the way the .NET Framework API is designed it makes a complete port difficult, although the mono project is definitely an interesting attempt.
On the other hand, in theory Java could be language agnostic too. And there has been attempts to target the Java Bytecode, but no successful ones. Sun doesn’t seem interested in these projects, and are not giving them any official support. The problem lies in the fact that Java Bytecode was not designed to support multiple languages, the main goal was for it to be compact and take little bandwidth when sent over a network. And Sun cannot make major changes to it’s bytecode due to backward compatibility issues.

The bottom line in my article research is this: C#.NET is the best platform for Windows based systems since it was in fact designed for it. Java on the other hand is the only option for systems that are targeting other operating systems.

I am a very busy man. I have a full time job as a project manager and software developer. In my spare time I am an freelance journalist, writing articles for a Swedish computer magazine. On top of that I am a caring father of two lovely children. Needless to say, spare time is scarce.

Both my job and my writing, as well as my wellbeing, require constant learning. The most convenient way for me to accomplish this is by reading. I love reading books. Tech-, popular science and fiction books – I devour them all.

The only problem is when to do it. I am always busy, either with work or with my family. But the optimizer in me has found a solution: I read while in the toilet. Tech-books are especially well suited for toilet-reading. They are usually well structured and have relatively short chapters. I tend to keep at least a couple of them lying within range.

Of course, I sometimes take unnecessary long time doing my needs, and sometimes my wife complains about it. But you know what they’re saying: a man’s gotta do what a man’s gotta do.

A common habit amongst us software developers is the practice of sub optimization. If you find yourself thinking “I might use this function/class later, I’d better make it general,” or “I’ll use a static variable since it’s faster” then you are guilty of sub optimizing.
Optimizing prematurely is bad, and usually get you into trouble. It tends to make your code unnecessarily complex and difficult to maintain. A much better practice is what the agile methods, like Extreme Programming, recommend.

1. Write a unit test.
2. Start with the simplest possible implementation to make your test pass.
3. Refactor the code for the purpose of making it easier to maintain, fulfilling the principle of DRY (Don’t Repeat Yourself). The unit test is your insurance that the functionality of the code is unchanged.

If you follow these simple rules, and leave the optimizations until you really need them you will avoid spending time optimizing things that doesn’t need to be optimized (what’s a couple of milliseconds in a process that take several seconds?) You’ll also gain simpler, more readable code and spend less time maintaining it.

I’m a great believer in automating time consuming tasks. Since deploying my rails application (the Forlorn Hope movie site I told you about in my last post) has become increasingly painful I decided to automate it. Today I succeeded. It is not a simple task for someone who’s knowledge in Unix server administration is limited, but I made it! I’m finally there.

The basic ingredient is Capistrano, a rails/rake extension designed to automate the deployment of rails applications (although not restricted to that). I may do a write up some day but for now I will just enjoy my newly won ease of deployment. You know: change a little bit here – DEPLOY! – change a little bit there – DEPLOY! Wah, I love it!

If you don’t want to wait for my write up there are plenty of information on the Internet to get you started. Be prepared for extensive tweaking though.

Installing a rails application at TextDrive
Lighttpd the painless way
You need to install the subversion client
How to deploy your first rails application using Capistrano in Windows
Shovel – Rails deployment with Lighttpd