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.

According the the Apache URL rewriting guide, the way to handle Canonical Hostnames is like this:

Well, those rules are not always sufficient. Specifically, what if you also owned the www.example.com.au domain, and wished to redirect it also to the primary www.example.com domain? The solution is simple - we just need to add a single $ character to the end of the match-pattern of the first RewriteCond like this:

Now that will work nicely as long as the hosts use standard ports (ie 80 for HTTP, and 443 for HTTPS). However, some Python versions unnecessarily append the standard HTTPS port number to the Host HTTP header. Also I discovered today (after some Apache debug logging) that Adobe AIR applications have the exact same misbehavior for HTTPS, but only when running under Mac OS X.

I've thought about creating my own Drupal theme for this site for sometime now, but haven't really found the time and motivation to get started. That is, until my friend Mike recently radically altered his blog by creating his own Drupal theme. Well, that inspired me to finally have a go at replacing this site's much-loved default "Garland" theme.

Well, after some initial head-scratching, I was pleasantly surprised to find out just how easy it can be to theme Drupal sites! My new theme, for example, is done entirely with three CSS files, and two images.

PDF Alchemy is an interesting new service that I've helped to build. It's a PDF conversion service aimed at developers - that is, it's entirely API based, and not intended for end users. But what makes PDF Alchemy interesting to me, is the way it uses a number of Amazon's cloud services.

To start with, the PDF conversion servers themselves run on Amazon EC2. EC2 is an excellent match here, since it allows PDF Alchemy to easily, and rapidly, scale to handle almost any possible volume, but also to then scale back again during off-peak periods.

If you've used Subversion for any significant length of time, then you've probably run into the following message (or one just like it), near the end of a "svn diff" command.

Of course, you would have realised that this is because your editor has added a newline character to the end of the file in question, where the original had no such newline character.