Regular readers know that I love working here, so I'm going to announce a vacancy. One of the other teams here currently needs a permanent .NET developer, to be based in Crowborough, East Sussex. As the role is in a different team to mine, the exact technologies and tools may differ slightly from what I write about; also I don't have a full spec yet, so I can't give full details. Anyway, drop me an email if you're interested (simon at harriyott dot com), and I'll pass it on to the right people.

Disclaimer: If I introduce a successful applicant to the company, I win some kind of 'experience', like driving a Ferrari or something (no cash alternative). I'd still recommend working here if I got nothing.

When writing a reusable, configurable .NET application, there are often a load of text files that need deploying. To prevent users tampering with the configuration files that control the behaviour of the application, the files can be embedded as a resource. This is particularly useful for XML schemas (why does nobody ever use the original plural, schemata? Oh yeah, it sounds poncy. Still, we do say data instead of datums). The contents of the file can be read using reflection:

public string GetFileContents(string resName)
{
  string contents = "";

  Assembly thisAssembly = Assembly.GetCallingAssembly();
 
  // Read the file from the resource stream
  Stream resStream 
      = thisAssembly.GetManifestResourceStream(resName);
  if (resStream != null)
  {
    StreamReader reader = new StreamReader(resStream);
    contents = reader.ReadToEnd();
  }
  return contents; 
}

The advantage is that the text files aren't even visible to the user, let alone tamperable. The disadvantages are that they are read only, so not appropriate for user settings, and that any changes require a rebuild and deployement. Therefore, appropriate in some cases, but not in others.

...Array

Twice in my career, I have found that learning (but not actually understanding) a definition has got me a long way. The first was at university, when I was revising for my finals. I was working through some past papers, all of which asked for the definition of a monoid. None of the past papers had the typical next question along the lines of "Hence, or otherwise, use the following monoid to prove...". This was handy, as I didn't actually understand what a monoid was (and still don't), but, hey, I could learn the two-paragraph definition, so I did. Parrot fashion.

I made up a comic strip story to represent the words, which I could replay in my head when the time came. I can't remember it now, 10 years later, except for one bit: "which is invariant". For this, I drew a picture of some witches in a Volkswagen Variant. Anyway, in the exam, I replayed the story, and got the definition word perfect. I got a good grade in that exam, which bumped up my final result.

The second time started with an interview at company A. Steve, the guy interviewing me said that they did some work with OPC, which I had never heard of, so I asked him. "OLE for Process Control", he told me, and I was none the wiser. I wasn't offered the job, as it was for a VB programmer, and I wanted a C++ job, so I carried on looking.

My next interview (at company B), was also with a guy called Steve, who also said that they did some work with OPC. "Ah, OLE for Process Control" I said. "You've heard of it" said Steve. "Oh yes" I said. I was offered, and accepted the job (which didn't actually involve any OPC). It didn't work out as well as I hoped, so a year or so later, I was looking for another job. I ended up with another interview with company A, again with Steve, who had clearly forgotten some of the interview I had with him a year or so previously.

"We do some work with OPC" said Steve. "Ah, OLE for Process Control" I said. "You've heard of it" said Steve. "Oh yes" I said. I got the job this time, and after about five years of working there, actually got to play with OPC, and finally learned something more about it than simply how it's spelt.

I try to keep this blog to the point, which is basically software. I've digressed a couple of times, and I'm going to again now. If your only interest in my writing is my "insightful" insights into my experiences with software and working with software, then feel free to move on, as this post is about wine.

OK, so I don't know who most of my readers are, but I have around 30 subscribers in Bloglines and NewsGator combined, and some casual visitors. I'll assume that some readers haven't come across Hugh Macleod, as we write about different subjects. From what I can gather, Hugh used to be involved with big-bucks advertising, then realised it was rubbish, and is now into small-bucks "advertising". Anyway, read his stuff; it's more interesting than mine.

Recently, Hugh has been promoting Stormhoek, a wine company. Instead of sponsoring mainstream American comedy shows, Hugh thought it would be cheaper to just send a sample bottle to a bunch of UK bloggers, and hope that they would write about it. So I signed up, and got through the post a bottle of wine with my name on it:



On Friday, I shared the wine with my wife, my brother-in-law and his fiancee, and we all liked it. The wine is marketed as "fresh", and in my limited knowledge of wine, the word "fresh" does seem appropriate. I generally prefer red wine to white, and I have a couple of "safe" reds that I know I'll like, and usually buy. I'll try other bottles quite often, to see if there's other wines I prefer: I don't drink that much, so I sometimes forget which of the recent wines I liked the best.

I don't have a "safe" white wine yet, as red is safer than white for me. However, I liked the Stormhoek, and so did the others, so I'll make it my safe white for now. As there's an interesting (to me) story behind it, it may be handy for dinner party conversation too. I won't forget what it's called, as Hugh mentions it in his blog often enough that the name has sunk in.

For a while, I considered not writing about the wine, as this is a software blog, and writing about it wasn't a condition of receiving it. Two things changed my mind. Firstly, being sent a free bottle of wine (with my name on it) is a nice thing to happen, so I'd like to do the nice thing in return, which means writing about what I thought of it. Actually, that's reason enough.

Secondly, Adriana, who I recently met at a London geek dinner, is hosting a New York geek dinner soon, and Hugh has offered to supply the wine. I'm due to organise the third Sussex geek dinner soon, so I thought I would ask Hugh if he would like to supply the wine for us too. So there we go. I'm into geek dinners, and Hugh's into geek dinners. It seems that wine is relevant to my software blog after all.

Our new car has a splendid software feature that none of our previous cars have had. I don't know what it's actually called, but it shows the average miles per gallon (to one decimal place) on an LCD on the dashboard. It has completely changed how I drive.

I used to bomb around a bit too fast, because there's no point travelling when I could actually be doing the thing I'm travelling to a bit sooner, right? Now, I spend the journey with half an eye on the econometer (as I've been calling it - what is it really called?), trying to get the number as high as possible.

Living at the bottom of a hill in a housing estate means that I always get off to a bad start, but going down a hill in 5th gear with my foot completely off the accelerator makes the number get bigger. Driving slower makes the number get bigger. I even had a quick search on Google for how to go from standstill to 5th gear as economically as possible. I might even save some money by driving more carefully. Anyway, I realise I'm getting much too nerdy about this, so I'll move on.

The point of all this is that a really simple little thing of a software feature that I didn't think was even necessary has changed how I, the "user", uses the entire package. A couple of times in my career I have written software things that have had that effect on people. I managed to save Tracey at Manchester airport an hour of paperwork every day, which was really gratifying. I wrote a simple pool car booking thing on an intranet that reduced the hire car bookings from around 30 a month to about 1. I was part of a team that wrote something for a rail company that saved them more than what they paid us (for a couple of years' work) in the first month. There may be other features I've written that have made a positive impact, but I don't remember getting feedback about them.

So there we are, in a 10 year career, I can think of only 3 things that I've done that have made a really big difference to someone. I may be getting old and loopy or something, but I think that's a bit of a shame. I know I didn't get into programming for the benefit of mankind or anything, but it would be nice to do some more significant things (without necessarily becoming a nurse or aid-worker or something).

The thing is, I don't know which things are going to make the most impact. I bet the guy who invented the "econometer" won't know that his one feature has changed my driving for the better (when speed limits and cameras couldn't). If you know him, please pass on my appreciation.

[Update: Seth Godin suggests that putting a real-time mpg meter in a car would have an effect. It does!]

I've now registered for DeveloperDeveloperDeveloper the second. There are some interesting looking sessions proposed. I briefly considered volunteering to present a session on MSBuild, but someone has already proposed a similar session, and (more importantly) I've not presented anything before.

When the daily build has finished, the screen goes green or red, according to success or failure. Imagine my surprise, when today it went blue! Yes, the build machine showed me the first blue screen of death that I've ever seen on Windows XP. Not only that, the PC won't boot up again. Someone must have checked in some really iffy code!

[Update]: Sorry, had to remove a comment for commercial reasons.

There must be some impressive improvements in the J# redistributable package, as it clearly has so much more stuff in it:

I've just finished the biggest book I've ever read cover to cover, and it was brilliant. Utterly brilliant. I got it for Christmas, so it has taken ages to read.



There is so much detail about the finer points of writing code: where to put whitespace, how to measure the complexity of a function, how to comment properly, how to make code more readable, how to use pseudo code, and so many other things. I've been applying some of the things I've read, and I think my code is better than it was before I read it, which is a big bonus for my colleagues.

There's loads of other stuff too, as the table of contents shows. I heartily recommend that you read it (if you're any sort of developer). It's available on Amazon.