Three of the most common file formats for recording exercise data are HRM, GPX and TCX. HRM is an older proprietary, but open, standard created and maintained by Polar, which deals with heartrate information, as well as speed, cadence, altitude and power. GPX is another older standard which deals primary with geolocation data from GPS receivers. TCX is a newer format that effectively supports all that HRM and GPX support combined, and then some.

My shiny new Polar RCX5 (which I really like) happens to export data (via the Polar WebSync application) as separate HRM and GPX files (for legacy reasons, no doubt). Whereas Strava (which I also really like) supports GPX and TCX imports (amoung others). So of course, I can import my GPX files from the RCX5 to Strava pretty easily, however, that will provide Strava with no heartrate nor cadence data, since the GPX format does not support those.

So the question I faced was: how to combine the GPX and HRM files from my RCX5 to a single TCX file? Since I found no appropriate tools readily available, I wrote my own ;)

Apache Qpid™ is a high performance open-source message queuing system. But there's no point me telling you all about it - just check it out over at http://qpid.apache.org/.

The Qpid project provides two different message brokers, and several client APIs. However it did not yet have a PHP client API, so I set about writing one :)

Although the PHP binding I created is SWIG-based, it was not as straight-forward as writing a simple SWIG interface file, and compiling... no sir! First off, running SWIG on the standard Qpid headers in PHP mode resulted in SWIG seg-faulting. So after reporting that bug to SWIG (it has since been fixed, yay!) and developing a workaround, I then had to solve a number of small issues, and then write some Qpid Variant ⇔ PHP type-mapping routines.

Now, there are no official binary PIAs for Exchange Server 2000 / 2003. However, Microsoft does provide such PIAs in "source" form (not really source code as such... but we'll get to that) that you can download and compile yourself. There is an MSDN article that explains how to use the Exchange Server PIA wrappers, however I strongly recommend you download the code and read the included "Writing Managed Sinks for SMTP and Transport Events.doc" file instead - it is far more up to date than the MSDN article in areas that are quite significant (such as the actual build process).

Having owned an N900 for a little while now (casting my vote for openness and freedom in the mobile space), I've been eagerly waiting for a MeeGo release that I could install on my N900 and play with. That moment came a little over one week ago! :) So, after waiting for my nice new class-10 microSDHC card to arrive (cheaper to buy online with shipping, than to buy locally), I finally had a play last weekend. I was a little dissapointed :|

Although I had expected a lot of bugs and instabilities, and my overall expectations were quite low at this stage, I was still quite surprised at just how incomplete MeeGo Handset is. I guess my unrealistic expectations stemmed from the fact that the current MeeGo handset release has the version number 1.1 - that implies to me that it should be "fairly complete" (albeit with bugs, etc). However, it is more inline with what I would call a version 0.1.

Now, the back of the Family Pack box says:

Which is completely fine with me, because I always do a fresh install anyway, for performance reasons. So, with all my important data backed up, I formated the disk and proceeded to install.

The initial stages of the installation were pleasantly slick - feeling much more refined than good old XP, but the pleasantries were put on hold when it came time to enter my product key, which was consistently rejected! :(

I've been experimenting with QtSvgDialGauge in a personal project, and so far, I like it a lot! :)

For those who don't know, QtSvgDialGauge is nice SVG-based dial/gauge widget, which is part of the Qt Embedded Widget demos. You can see it (and several other embedded widgets) in action in the Qt Embedded Widgets Catalog and Qt Patient Care Demo applications. And you can download the source for both applications here.

With most non-trivial Qt projects that I create, I like to include a pre-pre-build command in the qmake project file. I'll explain why as we go, but first off, let's look at what I mean by "pre-pre-build" (it is not at all a standard term).

The typical build process (as performed by make looks something like this:

1. For the given target, check if any of the target's dependencies have been updated since it was last (re)built.
   1. If no dependencies have changed, do nothing - we're done ;)
   2. If one or more dependencies have changed, then:
      1. Build each dependent target.
      2. Build this target.
      3. If appropriate, link this target with its dependencies.

That is, of course, a gross oversimplification... but it will do the purpose of this post.

Whoa!! I just got a rather surprising (to me) warning from Gmail. It reads:

You are almost out of space for your Gmail account. You can view our tips on reducing your email storage or purchase additional storage.

As I said, this was a bit of a surprise to me. When I first began using Gmail, I kept a close eye on my storage usage, but it used to climb so slowly that I soon forgot all about it. But upon seeing the above message, I quickly glanced down to read:

You are currently using 6989 MB (95%) of your 7356 MB.

Since Google released Chrome last year, I've gotten used to regularly using two browsers on my PC: Google Chrome for all of my "simple" personal browsing such as webmail, and Firefox for more advanced browsing such as website development. This also tends to create a nice separation of personal (Chrome) versus work (Firefox) tasks.

However, one thing that has bothered me for some time is the (slightly) proprietary nature of Google Chrome... don't get me wrong, Chrome is built from the opensource Chromium project, so it's not all that proprietary, but still, something does not quite sit right with me.

Back in part 1 of this build, I ran in to some overheating concerns with the northbridge. So I decided to try a passive tower cooler for both the north and south bridges.

So here's the new parts that are ready to go... From left to right, they are:

• Thermalright HR-09S (type 3) VRM cooler... which I didn't end up using (more on that later);
• Thermalright HR-05 IFX chipset cooler - this is the straight-up version, which I'll use for the southbridge;
• Thermalright HR-05 SLI IFX chipset cooler - the "bent" version for the northbridge.