May 28, 2009

Not sure? Bing it!

Today, at the D7 conference in the US, CEO Steve Ballmer announced Bing, Microsoft's new search engine, in a bid to change the way we search online. Bing was designed to be a decision engine, and a step forward from information search towards knowledge search. will go live next week, in a market ~60% owned by Google. It's like David versus Goliath all over again, except David has a rumoured $80 million marketing budget and Goliath is the beloved of the people. Of the utmost symbolic significance, of course, bing rhymes with sling.

The world of online search has definitely become a lot more exciting this spring, with the recent launch of Wolfram|Alpha and the announcing of Bing. I'm anxious to see how this will ripple across the world wide web and how long it will take Google to react. Right now the ball is in Microsoft's court.

May 23, 2009

Felicitări, Adi Buzgar şi Călin Juravle!

Adrian Buzgar, Călin Juravle si Andreas Resios s-au calificat în finala probei regină a Imagine Cup, Software Design! Ei vor reprezenta România, Iaşul şi Universitatea Alexandru Ioan Cuza în finala de la Cairo (click pentru detalii şi poze). Felicitări şi respect, băieţi! Mult succes în finală!


May 15, 2009

Again* on overriding Object.GetHashCode()

Overriding Object.GetHashCode can rightfully be regarded as one of the more mundane tasks in .NET programming and indeed, often enough, when your own application is the only consumer of your code, you might as well return 42 (don't do it, though!).

However, if you're writing reusable components or if you're implementing types that you plan to use as keys in an IDictionary, you are required to provide (at the very least) a decent hash function implementation.

The hashing algorithm advocated by Joshua Bloch in his Effective Java is widely regarded as a good enough algorithm for most circumstances (think non performance critical). It's also very easy to implement, as per the sketch below:

  1. choose a non zero initial value and store it in a variable h
  2. choose an odd prime multiplier and store it in variable m
  3. for each relevant member field f (also used in evaluating this.Equals) do: h = h * m + f.GetHashCode()
  4. return h as the hash code
One thing I would recommend is encapsulating this into a utility method (or class, depending on the degree of API flexibility you want) for ease of reuse. The second (and I know I'm being somewhat pedantic) is surrounding the arithmetic operations in an unchecked block. Arithmetic overflow is bound to happen (and that's fine), but even if by default operations involving variables (unlike constants) are implicitly executed in an unchecked context, you can never be sure that the client code doesn't call your GetHashCode inside an explicit checked block, exposing itself to an unwanted OverflowException.

* No, my role in the team is not to implement Equals and GetHashCode all across our codebase :)

May 09, 2009

Never mind the bollocks, design upfront!

In a recent blog post, Robert Martin (aka Uncle Bob), one of the leading figures of the world of agile software development, tackles a widely circulated agile myth: up-front design is evil.

I must admit that I haven't read literature on agile and that my team is rather struggling to function in a somewhat agile manner, so I'm far from being savvy. But I have heard people who claimed they were, say things like "you should evolve your design from nothing, one test-case at a time". Like Bob Martin, I too associate that with a certain solid-hoofed herbivorous quadruped's digested waste material.

In his post, Martin explains that the real agile principle is to avoid Big Design Upfront, not any design upfront. He criticizes the zealotry that turned a solid agile principle into a dangerous myth and argues that a Little Design Upfront is essential, and that we shouldn't be afraid to scale "Little" proportionally to the complexity of the project.

So how do we design upfront and still keep ourselves agile and resilient to requirements change? I believe there's at least one simple question to which if our design can answer, there's a high chance that we're on the right track: "How will I test this?".