While considering using
for a project recently, I was surprised at just how little SQS performance data was available on the Internet.
In particular, while there's a bit of information available regarding throughput, there is very little information
I can find regarding message latency.
Indeed, as long as SQS can scale horizontally, throughput is really not very important at all (within reason
of course). But latency cannot usually be improved by scaling, so if latency is too high to be acceptable for
any given project, then scaling is unlikely to ever change that.
As latency is so important for the project I had in mind, I decided to throw together a very small set of simple
SQS benchmarking scripts to get an idea of what sort of latency (and throughput) we can expect from SQS.
From time to time I find myself building Boost on
Windows. There's a number of small things that need to be done to make that happen. Having had to "rediscover" the build process each
time, I recently decided to create a small Windows command script to automate most of the process.
As I find the build script extremely useful, I figured it would be worth posting it here to inspire others in similar circumstances.
I recently posted an AWK script for combining GPX and HRM files into TCX format. This script is really handy when you have GPX files with or without matching HRM files, but what if you have HRM files without GPX files?
It did not immediately occur to me that there'd be any value in converting lone HRM files to TCX, since I think of TCX as being geographic location focused (which is not strictly true). However, prompted by Conrad, it became apparent that I could indeed convert HRM files (without GPX files) to TCX, and indeed, I already had 30 or so such HRM files that I'd been entering into Strava manually (stationary trainer sessions, and weights workouts).
Following on from my gpx2tcx AWK script and Windows batch file, I now present what will probably the last separate component in the series... my gpx2tcx.sh Bash shell script.
This script is similar in nature to the Windows equivalent presented earlier, however it is considerably more flexible. Unlike the Windows batch file, this Bash script supports a number of command line arguments that allow its operation to be tweaked more easily.
I've previously presented a GPX + HRM to TCX AWK script (see this post). And while this script can be very useful on its own, I've also written a Windows batch file, and a Bash script to make use of that AWK script a little easier. In this quick post, I'll be presenting the former of the two - ie the Windows batch file.
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.
Writing managed (aka .NET) sinks for Exchange Server 2000 / 2003 SMTP events requires Primay Interop Assemblies to wrap Exchange's COM-based event sink interfaces. If you don't know what PIAs are, then I suggest you read Primary Interop Assemblies (PIAs) - MSDN. But chances are, if you weren't already at least aware of the existence of PIAs, then the rest of this post is probably not something that will interest you ;)
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".
A couple of weeks ago, I upgraded my Windows XP machine to Windows 7. I used the Windows 7 Family Pack special, which includes three Windows 7 upgrade licenses in one pack for better value.
Now, the back of the Family Pack box says:
This version of Windows 7 is designed as an upgrade for Windows Vista
®. If you are upgrading from Windows® XP, you will need to back up your files and settings and perform a clean install and then re-install your existing files, settings, and programs.
for important information.
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! :(