Beckshome.com: Thomas Beck's Blog

I’m sure if I had a nickel for each time a software project was impacted by introducing production volume data into the testing life cycle either too late, or worse even – not at all, I’d be a rich man and wouldn’t be writing this blog entry. When you think about it, it’s really no wonder that we find ourselves in this situation. Developers new to the craft have no experience to draw on dealing with millions of rows of data. Experienced developers and DBAs often pass on war stories of hand crafted scripts and the perils of migrating data from production to lower environments, further reinforcing the belief that emulating production volumes of data is work restricted to the gods of IT.

Having non-static machine keys when hosting on IIS is just one of those things that’s just bound to cause trouble eventually. This holds true equally for single server hosting environments and load balanced web farm environments. Especially if your goal is to shield your users from any knowledge of IIS lifecycle activities (e.g. application pool recycles), the use of static machine keys is to be strongly recommended. The implications of static versus dynamic keys are enumerated for several different hosting situations below:

I’ve been contemplating the move towards a self-hosted Subversion repository for quite a while. My earlier attempts worked but left me with a lot of inconvenient and sometimes quirky side effects. These experiences always led me back to hosting Subversion on Linux, which is really where it works most naturally. Recently, however, I decided to retry my luck with Subversion hosting on Windows and I made the call to go with a “package” instead of doing the Apache / Subversion integration myself.

I was performing functional tests on my models that employed Attachment_Fu this morning and thought it would be worthwhile to share the code since it was a bit of a hassle pulling it together. Kudos to Mike Subelsky for his introduction to functional testing Attachment_Fu. It got me going in the right direction. What proved difficult once again was the multi-model controller. Once I got over that hump, I was on my way. As you can see from all the detail in the HTTP POST below, that was not an entirely easy task.

Continuing my Rails on Windows thread, I’m going to spend a bit of time on something that’s brought me both some substantial gains and some minor woes lately, running the Attachment_Fu plugin on Windows. I’ll start off with some general Attachment_Fu information and then get into some of the quirks, which are, as expected, mostly specific to the Windows environment.

First, for those not in the know, Attachment_Fu is a Rails plugin that allows you to store binary data (e.g. images, video, documents) and associate it with other models in your Rails application. Metadata (content type, size, height, width) about the attachment is stored in a separate model. Attachment_Fu’s sweet spot is handling images. It can handle automatic image conversion and thumbnailing using a number of popular image processors such as ImageScience, RMagick, or minmagick. Although not provided, you can imagine that Attachment_Fu might be extended to handle other types of binary processing utilities such as PDF converters or audio/video transcoding software. The other very cool thing about Attachment_Fu is that it provides support for pluggable persistence mechanisms. Out of the box, it allows for storage on the file system, as binary information in a database or on Amazon’s S3 storage service.

I’ve been putting a good deal of time recently into converting GeoGlue from .NET to Rails. One of the things that I’m looking to get into the alpha release is the dynamic creation of podcasts. This is really nothing special since a podcast is little more than a special case of an RSS feed that points at external media files (i.e. audio or video).

I plan on covering the audio/video entry in an upcoming post about the nuances of the Attachment_Fu plugin on Windows. In this post, I’m going to just lay out the code for the podcast creation, since this is nothing more that a simple rxml file. I’ve sprinkled in comments liberally but most of the code should be fairly self explanatory to those familiar with Ruby and RSS feeds.

I finally got around to adding videos to the site that I’ve been accumulating over the last couple of years. I’ve blogged about investigating Flash video a number of times before. After putting a number of videos on YouTube and being disappointed with the quality of the end product after their compression and resizing process was completed, I decided to go it on my own.

The decision to make this move provided the necessary impetus to do the final research and prototyping necessary to make this a reality. From my experience, I’ve come up with the three things that you’ll need to host Flash Videos, aside from the source video itself, of course.