Mono-rail Cat

So, why do I hate this so much. It looks like a great idea, it really does - what use is *just* a wheel? Or a car without a steering wheel? All the stages of development seem reasonable.  But there's a problem. What were the requirements? A car meets a very wide range of requirements, a skateboard just a few specific ones.  What if the most important requirement was to be able to carry 3 large suitcases and 4 people 200 miles?  What's the first "prototype" there? What's the first step then?  It's beguiling and misleading to present this as it's SUCH a narrow focus of what the requirements are and what the customer will actually be able to use as the product develops. Interestingly the picture is called "prototype".  And the end product is a car. Find me ONE car maker whose first prototype is a skateboard. So how do car manufacturers prototype?  They may create the basic chassis with no shell and make sure that the manufacturing process w

Apologies for the lack of updates. Not that I expect anyone is actually reading such an ill-kempt blog. I have been spectacularly busy both at work and at home. However over the following weeks I will be attempting to catch up with a few technical bits and pieces which I have been meaning to share with the world. Lastly, but most importantly, I am sorry to announce the passing on of the original mono-rail cat. Whitby died peacefully in her sleep, in her favourite spot (the hot water pipe which runs under the bathroom) a few months ago now. My wife misses her more than I do. RIP.

Some raw sushi that I made today. Parsnip Rice Wasabi Aioli on the top It was delicious!

OK, Interesting conversation with another "developer" - in the loosest sense of the word, regarding a mutual friend who is just starting to learn C# I mentioned that the world would be a nicer place to be if all developers were given a grounding in things such as: - Source Control - Design Patterns - Unit Testing Before being let loose on the world of code. The question is, should your first "hello world" application be unit tested? Developed using TDD? Adhere to the MVC pattern? Be in source control and properly labelled? I think the answer is a pretty resounding "yes, of course". The reams and reams of substandard C# I see every week (mainly from code posted on the interweb) demonstrates the fact that people don't "pick up those things later on". They simply don't. How many code/function snippets have you seen on various blogs (mine included) which have associated unit tests? Hardly any. Don't get me wrong, I'm as guilty of

Well, it had to happen, I finally got around to posting my fix/hack/dirty for this problem. 1. The problem: NDepend html results are very pretty, but don't work when you integrate NDepend into CC.Net, CC.Net's own xslt log parsers mean that the pretty images created by NDepend (dependency diagrams, Zone diagram, etc) are not shown. 2. The fix! Create new file called image.ashx (ashx = cut-down webpage without the tedious events wired up) Stick this in there: <%@ webhandler language="C#" class="ImageHandler" %> using System; using System.Configuration; using System.Data; using System.Data.SqlClient; using System.Drawing; using System.Drawing.Imaging; using System.Globalization; using System.IO; using System.Net; using System.Web; using System.Web.Caching; public class ImageHandler : IHttpHandler { public bool IsReusable { get { return true; } } public void ProcessRequest(HttpContext ctx) { try { string name = ctx.Request.QueryString["name

So I've been doing SQL queries for a while now, but only just worked out that 99 times out of 100, whenever you think you need a cursor, you probably don't. You probably need some sort of loop and some sort of track of where you are...but the answer to that is NOT a cursor. For example: You have a list of portfolios that you wish to value, but you need to call a proc/function against each in turn, so doing a single query is out of the question. The answer would appear to be a cursor, iterating over a list. WRONG. Here's how NOT to do it: DECLARE pfo_cursor CURSOR FOR SELECT pfo FROM #id OPEN pfo_cursor FETCH NEXT FROM pfo_cursor INTO @pfoLoop WHILE @@FETCH_STATUS = 0 ...do stuff with @pfoLoop FETCH NEXT FROM pfo_cursor INTO @pfoLoop CLOSE DEALLOCATE And here's a quicker, easier, cheaper, better way: SET @pfoLoop = (SELECT TOP 1 pfo FROM #id ORDER BY pfo) WHILE @pfoLoop is not null BEGIN ...do stuff with @pfoLoop SET @pfoLoop = (