Just been reading Rory's post, titled Python-O-Rama, and it got me thinking about choice. It's not always a good thing.

I won't repeat what I wrote in the comments there, but the basic point of my argument was that choice is not good when all you're doing is offloading the decision-making process to the end-user. Now, there's plenty of examples of this out there, and open-source software is not the only culprit (in fact, I mentioned WinZip in my comments, which isn't open-source) but it seems to me that OSS seems to have the mentality that choice (even just for the sake of choice) is always better than no choice.

I think, as developers, it can sometimes be difficult for us to take on the role of a proper designer and make a few executive decisions, because we seem incapable agreeing on some of the most unimportant details of our own work - like whether or not to use hungarian notation, whether or not Java/C#/whatever is better than C/C++/whatever else, or even whether the curly-brace should stay on the same line or go on the next! If we get into near fanatical discussion about such trivial things as this, how can we possibly expect to come to any other decision than "let's give the user an option to choose" with, perhaps, more important decisions?

It should be fairly obvious that the more unimportant choices an end-user needs to make, the less likely that they'll be enjoying their experience. Unlike us developers who use a computer all day, every day, most end-users only use their computers for long enough to actually get a task done. They don't want to spend hours customizing their applications with hundreds of options and add-ins - they want it all to just work, straight out of the box.

Until we can make a decision and stick with it, software will always be hard to use, and it'll always require too much training to get non-technical users proficient with it.

I've been working with CDO (Collaborative Data Objects) from C# recently, and while most of it works fairly well, one thing I was having trouble with was loading an in-memory byte array of MIME-encoded data into a CDO.IMessage object. There seemed to be no simple example on the internet anywhere.

So anyway, after much anguish, I finally found what I was looking for. Basically, you need to load the binary data into an ADODB.Stream object, and use the CDO.IMessage.DataSource.OpenObject method. Here's a sample of the code I came up with:

public CDO.IMessage GetCdoEmail(byte[] mime)
{
    CDO.IMessage email = new CDO.MessageClass();

    // We need to save the mime into an ADODB.Stream object
    ADODB.Stream stream = new ADODB.StreamClass();
    stream.Type = ADODB.StreamTypeEnum.adTypeBinary;
    stream.Open(Missing.Value, ADODB.ConnectModeEnum.adModeUnknown,
      ADODB.StreamOpenOptionsEnum.adOpenStreamUnspecified,
      null, null);
    stream.Write(mime);
    stream.Position = 0;

    // Then use the CDO.IMessage.DataSource's OpenObject
    // method to load the message from that stream.
    email.DataSource.OpenObject(stream, "_Stream");

    return email;
}

There's a lot of talk about at the moment about how the SHA-1 algorithm has been broken. I've seen quotes like:

SHA-1 has been broken. Not a reduced-round version. Not a simplified version. The real thing.

Now, while that's actually true, it's probably a bit sensationalist. It's not exactly been "broken" but it's now much easier to find another document that hashes to the same value as your document.

Normally, if you have a document and it hashes to a 160-bit SHA-1 hash value of A then using a brute-force algorithm and random documents it'll take 2⁸⁰ operations to find another document which also hashes to A. This result has reduced the brute-force number of operations from 2⁸⁰ to 2⁶⁹ operations. That's still quite infeasible for any single computer today.

Of course, once someone reduces it by that much it's only a matter of time before someone reduces it more. And Moore's law says that it probably won't be too long before 2⁶⁹ operations isn't that much.

But the other thing is that this will only find you a random document that hashes to the same value. The trick is finding a meaningful and malicious document that hashes to the same value. If you could do that, then we'd be in trouble.

Now, don't get me wrong. I think the result the Chinese have found is of significant importance, and we definately do need to start looking for a new algorithm, but I don't think it's time to throw out all our SHA-1 hashing algorithms just yet.

I just wanted to take a few minutes to give this site a plug. I've been an avid fan of the wallpapers produced by Ryan over at Digital Blasphemy for some time now (and in fact, it's the main reason I made my Wallpaper Changer app - so that I can have a different Digital Blasphemy wallpaper every day!) I often get comments from friends and coworkers about the wallpapers I have, all of which I got from Ryan's site.

Anyway, if you haven't yet, check it out. It's got a great selection of free wallpapers, and the member's section (which is a bargain to join - I did!) has even more. Plus new wallpapers regularly - what more could you ask for?

This is very cool. Mike Stall has released the source for a C# compiler, written completely in C#!

I remember taking a Compilers class back in Uni (not that long ago, really) and I have a copy of The Dragon Book on my bookshelf (I even read most of it during my compilers course!). So writing my own compiler has always seemed quite interesting to me.

This one includes a hand-writer lexer and parser (no mean feat, that!) for most of the C# grammer (and it shouldn't be impossible hard to add the rest). There are some lexer and parser generators for .NET (for example, C# Tools is one, though I haven't really tried it myself yet).

If I ever get some free time (yeah, right) I might take a closer look!