I’ve got a ticket to DRY

All programmers tend to agree that repeating yourself [in code] should be avoided. This is commonly known by the acronym DRY.

After looking at some demos of a search engine today a light bulb lit up in my head [not an energy effecient one I’m afraid]. The interface to the search allowed you to select from different categories and the result was dynamically updated. Nothing remarkable in that but wouldn’t it be great if we could search our code this way? And I’m not talking about the ability to find something in just your project. What if you could search the entire enterprise code based on filters for method names, return types etc right within the IDE. Every time you write a new method or class you could quickly find similar pieces of code within the enterprise. Now this may lead to some time pressured / lesser experienced developers to copy and paste more, but for me it would identify areas where it makes sense to provide libraries / services based on the actual coding needs of the developers. It would also help target problem areas across different projects. I may try and knock up a proof of concept in .NET using something like Lucene as the search engine. Not sure how this might work just yet, but it would either examine the source itself or use static analysis, something like cecil and the approach I’ve talked about before. Does anybody else think this is a good idea? What should the filters be?

Plain Text Story Runner using RSpec

At work we have started looking at the use of automated accpetance tests to provide validation of our development efforts. There are quite a few tools out there that can help with this; FitNesse, RSpec, NSpec, Selenium, Watir and WatiN to name a few.

So far we have found most success with RSpec and Watir. RSpec allows us to create plain text stories and acceptance criteria and run these as part of our integration builds. The slight problem we have is that we are mainly a .NET shop so using Ruby poses a few problems with regards to experience and knowledge. Unfortunately NSpec [which incorporates NBehave] doesn’t currently have a plain text story runner. Anyway here’s how you go about setting up RSpec in three simple steps.

Step 1: Write your story and acceptance criteria and save in a plain text file

Step 2: Create the story interpreter

Step 3: Create the runner

So without further ado I’ll explain each step in detail:

DDL Hell

There are several tools that you can use to help track database changes, so that come release you avoid an error or omission in the database scripts that brings your system crashing to its knees. However keeping change scripts up to date requires a lot of discipline. Tools such as Redgate’s SQL Compare can validate that one database schema matches another and produce change scripts to align them. This is all useful stuff, but some operations such as renaming tables and columns cannot be picked up using this technique. As a result I mainly use these types of tool to verify changes have been successfully applied. You are still left with the problem that a lack of discipline can mean cancelling the release. There is another method you can use in conjunction to the comparison tools however. When I first heard about the ability in SQL 2005 to capture DDL [Data Definition Language] changes I immediately thought about how I could apply the feature to the problem of tracking DB changes.

I got hold of an example script from here and modified it like so: