The news is spreading quickly, Google has decided to make their own browser.. Google Chrome, which is odd considering that there's already Mozilla Chrome. Anyway, what's interesting to me is the brewing Javascript engine war that's going on. Let's take a look:

Safari 4, nightly builds - WebKit, has a new engine called SquirrelFish. It makes their javascript run faster.

Firefox 3, nightly builds, has a new engine called SpiderMonkey. It makes their javascript run even faster. It uses traced dynamic compilation.

Chrome, has another new engine called V8. It makes their javascript run the fastest. It uses jit and garbage collection with a heritage from Smalltalk, Self, Strongtalk and Resilient (OOVM).

Is it that much of a surprise that the same technology that powers Smalltalk can super charge Javascript? no not really, they're both similar dynamic languages. It's interesting though that hot on the heels of SpiderMonkey's success at speeding up Javascript comes V8. And hot on the heels of SquirrelFish came SpiderMonkey. Three new Javascript engines in as many months? I love it.

It wouldn't surprise me if Safari took V8 in under its hood - though I think the Firefox guys are wed to their shiny new engine, so they're unlikely to pick up V8. We'll see.

It's very important in Software development to know when to pull the plug on something that isn't working. At least whenever that happens you've learnt important lessons along the way.

My latest project I was working on was a way to improve my Diabetes management. Right now I have a glucose monitor that records up to 450 measurements. You can get a special plug for it that connects to serial and you can download those measurements on to your computer. The software then graphs things for you nicely and you can see important trends. Frankly it's great - except that it's serial! RS-232! .. WHY?

So this is fine, I guess, but what I really want to be able to do is record how much insulin I'm taking, what meal I'm eating - and to get insulin amounts based on the carbs in a meal and my current insulin dosages. There's a nice piece of software called Diabetes Pilot which runs on Palm OS and WinCE and Win32 x86 which does just that. It's priced fairly. It does not, however, read from my glucose monitor (or anyones for that matter).

So I came up with an idea.. I want the next generation - a combination of glucose monitoring and diabetes management. I want it mobile and I want it wireless. So here's the plan: Get a Windows Mobile device, get a RS-232 to Bluetooth adaptor, implement my Glucose monitors protocol and download its data in to Diabetes Pilots database.

• Step 1: Implement Glucose Monitor protocol. This went pretty well. This device is not open at all - which required some reverse engineering. With a fair bit of work, snooping on the protocol and searching the web, myself and another guy called Chris Ridd have managed to get together a good webpage on the protocol of the Optium Xceed blood glucose monitor. Chris implemented the protocol in Python so that he could run it on Linux and MacOSX instead of just Windows. I implemented it in Smalltak (Public store - see package OptiumXceed) so that I could run it on the ARM processor and x86 (Windows Mobile and regular Windows Desktop)
• Step 2: Reverse engineer Diabetes Pilots database. Simple, this turned out to be sqlite3 - found this with my friend James. Smalltalk already has a sqlite3 database driver for VisualWorks. I plugged that in, looked at the tables for Diabetes Pilot - vwalla.
• Step 3: Download results from Glucose monitor in to a running copy of Diabetes Pilot. A complete success - no problems here what so ever. I can now sync my glucose measurements in to this other program. It provides the same sorts of graphs (though not as detailed, but better looking) as Precision Link (the software that is for the Xceed glucose monitor).
• Step 4: Purchase an RS-232 to Bluetooth adaptor and get that working. I already bought an RS-232 to USB adaptor, that's what I'm using on my laptop right now. So I know the cable works, I know adapting the cable works.. however, my $250 BlueportXP which I got a week ago has been a complete and utter failure. We cannot get even the simplest of RS-232 devices to work with it. I can talk to the device itself, I just cannot get anything to talk through it. This was most disappointing.
• Step 5: Test all of it on a PocketPC before purchasing my own PocketPC. I haven't done this step.. read below for the final decision I've made.

So it comes to this. PocketPCs do come with serial adaptors - if you purchase them. But, the cables are unwieldly. It's just plain impractical. Unfortunately, I'm reaching for next gens diabetes management and next gen is too far for the makers of the glucose devices. Right now there is one bluetooth glucose monitor being prepared to be sold by a German company. Their estimated release is mid next year - if we're lucky.

Without the bluetooth, this approach just isn't worth it. Ultimately, it would be best if the two devices were one - and the German company making the GlucoTel is intending to do just that - although their first version won't include a food database like Diabetes Pilot has. All in all, this is disappointing. Without the bluetooth I don't want to go ahead - so I'm canning the project.

It's nice to see that Smalltalk made the software development part of this project really easy. I guess I'll just stick with the basics for now and perhaps in a few years time the industry will have matured a bit more.

Now.. on to my next project!

Pair Programming is where some guy next to you nags you until you program the thing properly.

Spotted in Bob Congdon

It's interesting who picks up what in a blog post. Chris Double has an interesting note on how ensure works with continuations in Scheme by doing a re-execute of the 'entry' code when you begin a continuation again. This is called 'dynamid-wind'.

Here's a reason why some people may never ever understand what Unit Testing is all about

I've been trying to monitor a phenomena that I've been seeing in my code.. I call it "Noise".

What is this noise thing all about. Well, to put it simply, ever time you add a new method, you add noise. The longer the method, the more noise in that method. The more methods, the more noise, the more classes, the more noise, the more packages the more noise.

What is being done to combat this? Well, there is the whole concept of a class - encapsulation. Put the behaviour where it belongs. This allows developers to organise their code well, but it creates more noise by moving unrelated behaviour to the place that can provide the answer.

I fully agree that the code should be where it can run, but I don't agree that unrelated behaviour should be closely 'related' via viewership. When you look at a class, you see a hodgepodge of concepts muddled together.

What is being done to combat this? Well, Smalltalk has the concept of Extensions. This allows you to define methods on a class but have them live in different packages. This means you can put the behaviour on the class it belongs on, but hide it from unrelated concepts.

Unfortunately this means you need many many packages to properly segregate all the different kinds of behaviour. This simply isn't possible sometimes - also, instance variables must all live on the core. As you add more and more instance variables to support the concepts the class itself becomes noise.

So what can be done about this? - to tell the truth I believe this may be the reason there are so many anti-OO people out there. The supposed reduction of complexity actually increases noise.

Let's look at it from a different angle - Smalltalk is the only language I know that has gone to the trouble of trying to reduce the noise. And it shows.. teams can work on larger amounts of code for longer periods of time before the "Noise limit" is hit. Yet, I'm still finding myself uncomfortable as code becomes more "lived in".. cluttered.

I requested a new definition of 'categories' in VisualWorks, such that it is a cosmetic human organisation technique only. But the engineers were unreceptive to the concept. Perhaps I wasn't able to articulate what the true problem was well enough. Let alone the fact that other environments are still far behind VisualWorks in this regard any way.

Spotted in Cincom Smalltalk Blog - Smalltalk with Rants. James is right. Metadata isn't enough. You need topic maps.