novolocus.com

A note for myself. The MSDN DVD for April 2007 (Disc 3070.1) with Visual Studio 2005 on it can’t be installed directly from the DVD. The installer asks you to ‘Install Disk 1′, which is unfortunate, as there is no disc 1, and the DVD contains both CDs in different directories on it.

The solution is to copy both CDs to a single directory on the hard disc of the machine, and run the installer from there.

Unfortunately, for some reason my virtual machine won’t let me do that directly - it complains about copying one of the files from the DVD - but I can share a folder on the host, and copy the installation files into the VM via that folder.

Once you’ve copied the files on, though, the ‘pre-filled’ licence key isn’t there anymore. You can get the key by starting installing from the DVD, writing it down, and then using it when you install from the hard disc.

It’s crazy the work-arounds you have to go through sometimes

Tags: Visual Studio

I didn’t realise this, but Visual Studio allows you to see comments beginning TODO, HACK and UNDONE in the task list pane. That’s really quite neat, though it’s unfortunate that the list only contains items for files that are currently op open in the IDE. You can also add your own ‘tokens’ via the Options > Task List dialog. Vish has a pretty good summary. It’s just a shame that the task list isn’t for all files, irrespective of whether they’re open or not. Still, a neat feature that I didn’t know about.

I’ve been setting up forms based authentication for SharePoint. This is pretty much a normal ASP.NET authentication set up, but I’ve been following the instructions from Andrew Connell, and the excellent instructions from Dan Attis.

In these instructions, we set up the ASP.NET database using aspnet_regsql and then use the Web Site Administration tool to check the connections and create users (if you want to know more, check out the articles). However, here I had a bit of a quirky problem. Both sets of instructions say to, in the Web Site Administration tool, select the Provider tab and then select Select a Different Provider For Each Feature (Advanced). Then click Test by each provider. The problem - no Test link beside either provider.

As I was having some problems, I decided to dig into this. I tracked through the code that makes up the Web Site Administration tool, and found that this link is only shown if your provider contains the text ‘Sql’. I kid you not…

Previously, I’d posted about people and risk - and how we’re bad at judging it. The second part of the thoughts I’d had while driving to work was how risk applies to software development. Read more »

Presumably, everything I’ve written over the last 7 years has been amateur (well, some of it was, certainly). This is in addition to my being…

To be honest, I still feel I’m being firehosed with information about Microsoft stuff, and that I’m struggling to keep up. But I guess that the point of such certifications is that they demonstrate a level of ‘minimum competance’ - that is, the holder still might be “Good” rather than “Brilliant”, but at least you can be fairly sure that they aren’t “Completely Inept”.

Anyway, I learnt a lot doing the Professional Developer exam - or rather, reading the course materials. The exam itself, well, I felt that some of the questions were a bit too technical, while the book seemed to cover a higher level view of the system (at least, in it’s good bits). See my comments on the book I used.

An interesting blog post from Steve McConnell about whether software is engineering.

I actually come more from the engineering end of things (educationally, at least) than the Comp Sci route. I hold a Masters of Engineering, and my degree involved more electronics and mathematics than software. Read more »

As always, Jeff Atwood has an interesting around code being our enemy as developers. His proposal is that code needs to have better ‘brevity’.

I don’t think Jeff is talking about Brevity - and I think he even says that - but about Clarity. Clarity is simple, obvious, and to the heart of the matter. Real clarity is brief, but easy to read. That includes comments, too.

It could be made shorter in ‘text speak’, but how clear are those messages? There is a reason we don’t use 1 letter variable names!

It’s not tiny fragments of obscure code that does massive amounts (yes, I’m thinking of Perl in that, amongst others). And it sure as hell isn’t about lines of code - many languages (with notable exceptions) let you put an entire program on one line. Ever tried reading one? I did - you can’t.

It’s just about being simple, clear, and to the point. It’s kind of like Buddhist enlightnment - someday, with enough practice, I’d might just achieve that.

Unfortunately, I do think that we’re constrained - people often expect very complex things and lots of features from their software, and when people are demanding complex programs, you get complex code. Look at the complexity cost of, say, just having a simple UI for a Windows app, as opposed to a console app.

Some of the comments are very good, too. ‘Mickey’ is right - often, we’re trapped by bloated design. KISS is my watchword (and occasionally gets me a slap too).

Fred Ross is right, too, in his comment about code maintenance - but he does miss the point that often we’re under pressure from the boss to ‘just get it done’, and the idea of ‘get it done, but in a way that will save us time later’, well, usually, that dog won’t hunt.

Someday, we’ll get past the idea of using lines of code as a metric for how ‘good’ code is. I guess the problem is that clarity is more ethereal.

Comments from my old blog:

I agree with most of your points - but diverge in perhaps the same places you might too.

Examples… a typical .NET web application - which has C#, HTML, DHTML, Javascript, horrific call backs for AJAX, SQL, Stored procedures, triggers… the list goes on. There doesn’t seem to be any sensible way of making it “simple”.

The other problem (at least in my recent experience) is RAD or AGILE development… which often leads to spaghetti code unless the client is willing to pay a huge code tax for re-writing swathes of the project.

By Jonathan at 09:20:28 Tuesday 5th June 2007

Though I did have a demo at a potential customer recently, this isn’t about them. These are just the things that I’ve seen repeatedly. I’m not sure what the answers to some of them are yet.

1. The (potential) customer always wants to see 90% of the functionality in the demo - no matter how custom that development is. (This is a case of managing expectations)
2. The complexity of the demo is inversely proportionate to the time available to build it. (Beat the salesman until he understands, then cut all the complex bits and proceed as above)
3. The customer will want to see all logins for all the different users in a process used - and will then yawn as you switch between accounts (and yes, I know about ‘Run As…’. Even so, they’ll yawn). (Don’t show it. Or do it once, and then explain that you’re going to stop switching for the sake of sanity/getting to lunch on time)
4. The bit that you spend ages on getting working because it “must be shown” won’t be shown. (Try to find out how important these hard parts really are)
5. The bit that you spend 5 minutes on, doesn’t do anything, but looks pretty will get them really excited. (This is good! Make sure you show them the exciting stuff)
6. The customer will be utterly confident that they know their business process - and then through the course of the demo show that they don’t. (Try to help them see this, and consider re-engineering/redfining the process. If they won’t, steer clear or work on a T&M basis…)

I’ve been testing some code I’ve written for sending out notification emails according to a moderately complex set of rules. So, what have I learnt?

• Developers make rubbish testers. We know our own code too well, and already have expectations of how things should work.
• Testing has too many variables for any reasonable size application. You can’t test exhaustively. Equally, testing only what you think needs testing will also miss things. I’m beginning to think some automated, semi random testing (if you can) is the way forward - and you’ll still miss things.
• Specialist testers are good. I’m convinced a specialist would see what I’ve missed, and have good ideas over how to test generally. I don’t think I’m alone in that..
• Automated test is not a panacea… I really don’t see how it could apply in this case, at least not without a unit test program that could create database records, read a SharePoint library, and read an exchange server. All reasonable - but how do I then test the test app? ‘Cos it’s a complicated as my actual application.
• … and Unit testing isn’t a panacea either… I know, they’re related, but this does at least imply that you’re testing, well, small units of code. That relies on problems not occuring because of mismatches in the interoperation between units.
• … and with them both, you have to remember that you’re designing the tests. If you didn’t think of the case to handle it in your code, do you think you’ll think of it to test for it?

All that said, my application seems to work pretty well. Just there was a lot of manual cross referencing of results to check things worked, so I had a lot of time to think.

I’d really like a project where I can get thoroughly stuck into unit testing. Didn’t use it in this one, but I did think about how I would’ve done it - and I suspect I’d have missed one of the bugs I found. I suspect that unit testing’s main advantages are in forcing developers to actually think up front (sometimes rare), and in ensuring a consistent public interface despite internal changes. But I don’t see how you can get away from the fact that someone has to site and decide what to test - and that way things can be missed..

Two fascinating articles. I agree with Marcus Ranum, it is interesting how in Feynman’s “Personal observations on the reliability of the shuttle” highlights the good quality of the software. Given how software is usually so bad, how did this happen? Well, it seems that NASA recognised that testing is expensive and hard, and that ‘have you tried rebooting’ is not an adequate answer to a problem. Good testing takes time, money and aggressive pursuit of something better than ‘good enough’.

Those boys at NASA clearly understand software testing. After all, it ain’t rocket science.