You know you’re in trouble when the first five minutes of a movie are spent in narration, explaining to you what the movie will be about and, essentially, letting you know that he screenwriters really coud not be bothered to find creative ways to introduce you to the basic concepts with, you know, pictures and dialog.

I had been looking forward to seeing how they would bring the concept of dæmons to the screen in way that viewers would understand it (the book, Northern Lights, starts with taking the conceptof dæmons for granted in literally the first few words, but gradually lets the reader understand what’s behind the concept), and disappointingly, the movie simply gives a dry explanation (or, even more upsetting really, what really is just one possible interpretation), which sucks all the air of wonder and mystery out out of the concept. It’s not the only thing spoiled by the opening narrative, and in hindsight one feels lucky that they didn’t just give the ending (what ending?) away as well, while they were at it.

Unfortunately, it’s all downhill from there. The next 110 or so minutes are spent jumping from scene to scene, in what seems to be a never-ending bullet list of mini-episodes and deus ex machinas. Yes, machinas. Plural. Here a never-before seen or mentioned character appears out of nowhere to tell the lead character where to go next. There, Ms Coulter disperses with an out-of-context piece of information that’s needed to directly cross here, later. The list goes on.

Having read the book, one could of course follow along and try to recognize the original story line, but i don't even want to imagine what an incoherent gibberish of scenes this movie must seem like to someone unfamiliar with the story. You never get the chance to know or identify with any of the great characters (except possibly the lead, who’s portrayal by 13-year-old new-comer Dakota Blue Richards is possibly the only thing this movie has going for itself). There’s never any reasoning on what’s going on or why characters make the decision they do – they simply randomly walk from one scene into the next.

It almost seems as if Chris Weitz had taken the book, cut it’s 300-or-so pages into convenient 10-page chunks, handed them off to 30 separate screenwriters and then randomly concatenated the results again; the result feels a bit like Monty Pythons's And Now For Something Completely Different, with lots of CGI and all the funny parts removed.

The whole shebang ends with – no ending at all: some twenty or thirty pages before the book (which, while being part of a trilogy, does have a proper ending) would end, we just fade to black and roll the credits. I guess there’s only so much you can shoot on a 180 million dollar budget.

In summary, The Golden Compass is 2 hours of your life you will never get back and wish you had wasted on something else. I suppose a first warning sign should have been how the name of the movie differed from the book when, no, there really is no compass in the story, anywhere (not in the book, and not in the movie.

I would recommend anyone to stick to reading the books (which are excellent, btw), and let’s cross our fingers that book 2 and three will be spared this fate.

Recently, we've made the decision to switch version control systems here at RemObjects. In the past, we've been using a commercial system (i won't name any names) that has been working very well for us but - very unfortunately - has been much neglected by it's developers, with no major changes or improvements to the product in years, and even bug-fixes few and far between.

So we started looking around for alternatives, and of course Subversion was considered a good candidate - it's free, it's stable and well maintained, and it's being successfully used by many many software teams all around the globe, from major open source projects to corporate users.

The downside was that all available SVN clients were, well, let's just say pretty minimalistic, and did not really provide the necessary oomph we needed for our day-to-day work. Version control is an important part of the development cycle, and i've found that if your version control system is not a joy and easy to use, you wont use it properly. Yet, almost all version control systems i've ever come across seem to be designed to fight the developer every step of the way (and the main reason we got stuck with the current system was that it was about the only one that did not do that, but instead was actually fun to work with).

So, what to do? Simple - we decided that if we want to make the switch to SVN, there were a couple things we had to do. Firstly, we needed to create a tool that allowed us to automatically migrate our existing repository to the new system, without losing history, labels, or branching (done). Secondly, and a much bigger challenge, we decided to write our own front-end client, in order to give us with the best possible day-to-day experience in using SVN, but also to expose convenient ways to do those tasks we need that do not come as naturally in SVN as they should - such as for example the system we use for promotions.

The result (or at least our current state of it, as this will be a work in progress and see continued evolution over the next months) is what you see below: RemObjects Floss:

click image to view large version

Now, i know what your first question is gonna be: When can i download this? The answer is, you can't ;).

At this stage, Floss is an internal project, and we're developing it for internal use only. There is a big difference in effort in creating a tool vs. shipping a product, so for now, we're concentrating on getting something finished that we can use ourselves, when making the official VCS switch in January. But this is not to say that we won't reconsider making Floss available, in the future (and until then, you can always try to ask nicely for private beta access ;).

Let me know what you think, and what features you are missing in your SVN client...

For those german-speaking folks out there, we've just launched remobjects.de, the german version of our website!

Enjoy.

"Sunrise over Building 41" - see it on dwarfland.com

Building 41 on the Microsoft Campus, and home of the Visual Studio team. Taken September 2006 while in town for the yearly VSIP Summit.

HDR of three exposures taken in the early morning hours (oh, thank god for jet-lag ;).

Huw Collingbourne's Bitwise Magazine has posted a summary of the important trends and developments of year 2007 in tech thru the eyes of a few key members of the industry, including your's truly. Make sure to check it out.

As you probably know, while 'Joyride' is the current version of Chrome, and we plan to have many significant updates to it over the next half year, we're also already busy planning and implementing cool stuff for 'Oxygène', our next major release planned for late 2008.

Among many other cool language features we have in the works (some of which we might start talking about in a short while), we sat down last week to finish our planning of one big area - Parallelism.

What we're planning is really a set of independent features that will work together to bring unprecedented capabilities to multi-threaded development, allowing you to build applications that can leverage increasing core counts with more ease than any other mainstream language around.

Of course we have always had support for async methods and locking in the Chrome language from v1.0, but that has really only been the beginning. One of the coolest things we have planned for 'Oxygène' is native language support for futures.

A "future", for those unfamiliar with the term, is basically a promise to provide a value at a later time. For example, imagine you have a calculation that's split in two parts. Each part is independent, but takes a long time to compute. traditionally, you would write this sequentially, such as

  var part1: Int32 := 1+2;  // lets assume 1+2 is hard to calculate, here ;)
  var part2: Int32 := 3+4;
  result := part1+part2;

Of course part1 takes a long time to calculate, and while that is happening, your second cpu core sits idly by. Now, what if we could make a small change to this (note that this syntax is not set in stone yet):

  var part1: future Int32 := 1+2; 
  var part2: Int32 := 3+4;
  result := part1+part2;

Now, part1 is no longer an Int32, it is a "future Int32". What this means, it represents the value we expect for part1, but that value has not been fully calculated at the time the first statement executes. In fact. the first statement will execute in just about no time, and the main thread of your application will continue to calculate part2.

While part2 is being calculated, another thread (and hopefully another CPU) will get busy calculating part1, in the background.

Note that in our last statement, we can refer to part1, as if it were a plain Int32 (not a future). What's happening behind the scenes here? Simple: if our future has already been calculated in the background, we're simply grabbing the result and using it as part of the expression. If calculation is still in progress (maybe part2 was a bit faster), the expression will Wait for part1 to be completed.

The above example is a bit contrived of course - after all, a simple addition will execute in no time. But imagine part1 and part2 being two halves of a quick sort operation. Or calculations over two sides of a binary tree.

Futures (and Oxygène's other parallelism features that we will talk about another day) will make it easy to parallelize your application, while keeping your algorithms natural and intuitive, and without having to arbitrarily rearrange your code just based on what thread you want it to run on.

Stay tuned for more peeks ahead at 'Oxygène' soon, or grab our Future Subscription (pun not intended) to try Oxygène now, first hand!