I'm presenting this on Friday morning at the QLD ALM User Group:

This is a tale of a naïve protagonist, misguided advisors, princesses[1], dragons[2] and knights[3] in shining armour[4].

Like most fairy tales, this story has an idyllic beginning, a middle, and a happy ending. Also like most fairy tales, the middle of this tale is a grim, dark, scary journey through the Woods of Requirements, blithely past the Ivory Tower of Architecture, into the Depths of Design Despair, under the Mountain of Technical Debt and finishing with an agile leap of faith over the Waterfall of Doom to reach the rainbow on the other side.[5]

This talk starts with a post-mortem of a 3.5-year, $2m project that went horribly wrong. We’ll look at where the project failed: the architectural choices; the management strategies; the personalities involved and some sample code. We’ll also look at the changes that were made to bring the project back on track, get its wildly spiralling technical debt under control, re-release a functioning version and refactor it to something testable – and all in 3.5 weeks.

Finally, we’ll discuss ways to identify the issues encountered in this project so that you can spot them before they bite, strategies for regaining control over a project that’s already in trouble, and effective methods for managing troublesome stakeholders.

[1] There may or may not be actual princesses.
[2] Or dragons.
[3] Or knights.
[4] Motorcycle helmets.
[5] Bingo!

I hope people think it's worth getting up early for :)

Hi,

I didn't even think you remembered me. I used to have a huge crush on you in university. You were my first virtual crush and I lusted after what you could do for a long time. We even dated a couple of times. Nothing serious; just a few dinners, movies and virtual servers.

Then we both moved on.

We both got older and wiser over the years, and when you asked me to try things again I was at first surprised that you even remembered me, but I thought it might be worth a shot.

I was wrong.

You're fitter than before, I'll grant. You look even more attractive now than then; you're faster and more versatile, and those are good things. You were the first to show me what Windows 8 could look like, and I'll never forget that.

But here's the killer: you're an unpredictable bitch.

It's not okay to promise one thing and then do another. When I changed the memory settings on a VM, you told me that you'd need apply those changes once I restarted the VM. You didn't tell me that you'd suspend the VM to disk and break what I was doing. I'm not arguing about who's more important; I'm upset that you didn't ask.

It's not okay to lie about your connections. You said that Bridged Networking was a mutual friend, but it turns out you don't really know him that well at all. You spend all your time hanging out with his loser cousins, NAT and Host-only. What sort of loser name is Host-only, anyway?

It's not okay to spew services all over the couch (I count five) after a big night of installing, to leave your toothbrush in my bathroom or your icons in my system tray without asking. You keep changing them, too, so it always feels like there's a stranger in the house. Which, I guess, there is.

The last straw, however, is this: just like changing the furnishings in my apartment, it's not okay to rearrange my underwear drawer, hang your own pictures or remove my Visual Studio keyboard mappings and replace them with your own. You messed with my Visual Studio keyboard mappings! That's total relationship death right there.

Maybe you can sort out your issues and maybe you can't. Either way, you need to get some help. Even your parents (@vmware) don't answer when people tell them what you've been up to.

VMware, I'm over you. I'm off to take your cute little sister, Hyper-V, out to dinner.

Wow. I was introduced today by Andrew Tobin (@tobin) to DISQUS.

I'd tweeted about my replacement blog engine, and mentioned in my previous post that I hadn't yet implemented commenting. He suggested DISQUS, which is an online commenting service that I'd somehow never heard of. How had I not heard of this?!

From sign-up to comments working and tested, it's taken about half an hour of effort. If you need a public commenting solution, I genuinely can't think why you'd write your own any more. Nice work :)

As per my New Beginnings post, I've tried a couple of times recently to move to FunnelWeb. I've failed. The reasons for my failure are simple:

• I wanted to host everything on AppHarbor.
• I wanted everything (including posts and comments) under source control.
• I wanted a custom look and feel.

Everything that I wanted could be done using FunnelWeb, but when I started doing it I realised that I was re-working lots of code that I didn't actually expect to use in production and that, in a nutshell, a blog is just a web site and making a database-driven web site only really makes sense when there are frequently-changing data.

In addition, I kept finding myself firing up Visual Studio in order to write code snippets, then doing horrible things to them (I'm looking at you, Windows Live Writer) in order to make them appear. If I'd used FunnelWeb then I could use markdown (good) but then I'd have had to use Visual Studio to write any code snippets anyway.

I thought about it some more, and decided that I like writing code in Visual Studio, and can live with using it as my main blog text editor. So... blog posts are all now written using VS.

The other advantage of having a blog that's entirely under source control is that it's trivial to back up, restore and redeploy - and I can deploy it anywhere.

There's a bunch of stuff that doesn't work yet, but I can live with that. RSS isn't hooked up properly; hence feeding to Twitter (TwitterFeed via RSS) doesn't work. Comments aren't ready for prime-time either, but I expect they'll be done shortly. There's also no mobile browser detection, but that's in the pipeline.

Why did I want to change in the first place? Because there have been lots of blog posts that I've found myself wanting to write, but needing to include too many code snippets. Gists are fine but hurt to include via script tags; pre-formatted code blocks are ick and screenshots are kind of pointless when my goal is to allow people to easily copy/paste the code I'm posting. So... now that my roadblocks are mostly out of the way, expect to see more useful stuff here. You can hold me to that :)

1. Once upon a time, a company's youthful founder lucked upon a successful method of performing a task.

2. The task was profitable, and therefore it was good.

3. The founder wrote down that method and bestowed it unto her minions.

4. She said unto them, "This is The Process, and it is good."

5. The minions performed The Process until the end of days.

6. And they all lived happily ever after.

Bollocks.

The adage, "If it ain't broke, don't fix it" has a corollary best expressed by Tess Ferrandez: "If broken it is, fix it you should." Or at least, "If broken it is, don't sodding well inflict it on everyone just because you're too lazy or stupid to bother changing it."

If you haven't figured it out yet, I'm referring to internal corporate processes that serve no purpose other than demonstrating to some ISO 9000 certification minion that a documented process exists.

It seems as if every organisation, once it reaches a certain size, goes into the "create process and perish" stage. If it's a private enterprise it'll die a long, slow, horrible death of three-thousand triplicate signatures, but if it's a government enterprise then it's never going to die and we're all going to hate it.

Is hate too strong a word? I don't think so. Show me a single person who's dealt with a government department and left happy, and I'll show you someone who's on far too many psychedelics to be on the same planet as the rest of us. We hate government agencies because they're slow, bloated and inefficient. (We hate individual governments, too, but for different reasons. That's just not the point of this post.)

So, given the choice, why do organisations choose to have processes that make them slow, bloated and despised? Your guess is as good as mine, but I think it's to do with some misguided idea that they should be able to have any muppet follow the process and get the same result. Guess what, ladies and gentlemen: if you have a muppet-followable process then you'll end up hiring muppets to implement it - which is at best embarrassing while the process makes sense, but an utter disaster once the process becomes obsolete and everyone refuses to recognise it.

The Book of Process above should read something like this:

1. The minions performed The Process until the end of days.

2. The end of days arrived with a pitchfork-waving, torch-brandishing mob of angry citizens who burned the company's offices down around the minions.

3. The minions could not find their backsides with both hands the "In Case of Fire" process document quickly enough to escape.

4. And the citizens all rejoiced, and lived happily ever after.

Is process hurting your company? If so, it might be worth considering whether you actually need all your documented processes, or whether you can just set desired outcomes and performance metrics, and leave your smart people to figure things out for themselv...

... oh. I get it. Smart people. They've already left. Never mind.

There's nothing I can say that hasn't been said before by someone else, about someone else, for similar reasons. Nonetheless: today the world has lost a giant and we are all the poorer for it.

Steve Jobs changed the game so many times that people lost count. His visionary genius, his personal drive and his dedication to making absolute perfection commonplace have left an indelible legacy in which we all share.

His arrogance, his of-course-my-way-is-better approach and his unwillingness to compromise cultivated dislike amongst many, but then, nobody else gave the world the iPhone or the MacBook. Steve's arrogance was justified and, well, his way generally was better.

Steve's example should prompt all of us - in all industries - to treat elegant, beautiful design as a first-class consideration when creating something. If you build something people love, they will love you for it.

Farewell, Steve.

I'm writing another MVC3 app. I'm in the same world of pain with respect to magic strings and anonymous classes. I don't like it here.

I'm sorry, but who on earth thought that this was a good idea for a method signature?

I mean, seriously? Six strings and a Dictionary<string, object>? And that's a sensible collection of arguments? Why not add in a RouteValueDictionary (another string/object dictionary) for good measure? Oh, never mind.

But surely there are smarter overloads than that, right? Well, yes - and honestly, you just couldn't make this stuff up:

Oh My Friendly Geranium, but who on earth thought of this - and why wasn't it knocked on the head by someone sensible? MVC team: I'm really sorry, but IMO you've completely missed the point of a strongly-typed language. I know you've taken a lot of flak for this over the past few years but, to be honest, it's kind-of deserved :(

So, what on earth do we do about it?

When we're in a world of magic-string pain, the first thing to do is generally start creating some conventions. The second thing, of course, is that we test those conventions using unit tests. Hold on a second, though: we're using a strongly-typed language and yet we're *writing unit tests *to test our conventions because we're using strings and anonymous classes? Why don't we have a tool that does this for us?

We want a convention-based test harness that:

1. Runs on every build.
2. Has a set of conventions that are clear and unambiguous.
3. Doesn't make us manually write tests.
4. Will auto-generate test cases for every new piece of code we write.
5. Is refactoring-friendly.
6. Is fast.
7. Will fail the build if something's wrong.

I think we've forgotten something important. Can anyone point to a tool that's all of the above, comes pre-installed with every version of Visual Studio and requires zero integration work, no NuGet packages and just works?

Anyone? Anyone? No? Here's one: csc.exe. Yep, that's right: use the compiler.

Call me old-school, but a compiler is all of the above. Consider this method:

Think about it: why don't I have to test that a and b are integers? Sure, I should be testing for edge cases here, but I don't have to type-check or null-check my inputs. Why not? Because the compiler is enforcing the convention that when I say "int", I mean a 32-bit integer and it simply won't let anyone pass in anything else.

I don't have to write a single unit test to enforce these conventions. The compiler will provide me with fast and reliable feedback - at compile time - if I've broken anything, which is far better than getting the feedback at run-time using unit tests (or worse, at run-time when a user hits an issue).

I think we as developers can afford to take a bit more time to write strongly-typed code, e.g. HtmlHelpers for controller actions. Try this one:

You can make your code infer the controller name, the action name, the area and all sorts of things without ever having a magic string. You could even add strongly-typed parameters to it (built using a fluent interface) so that it's effectively impossible to get it wrong without the compiler complaining.

So why don't more people use such a great convention-based test tool? I have no idea.

I know, I know: apples, oranges etc. It's not really, though - this is actually quite straight-forward. But first, some background.

I was recently involved in building another iPhone application for an enterprise customer. We had previously dealt with that customer and had a good working relationship and level of trust with them, but a huge part of that trust was the visibility that we provided as to what was going on. It's mostly off-topic for this post, but the way we did it involved using Team Foundation Server, giving the client's people accounts and making sure that the client's product owner could log in at any time and see how the project was going.

With the iPhone application, we wanted to do exactly the same. The problem was that we hadn't had that much experience using TFS to build iPhone apps. Most of our collective efforts had either been in Objective C using git (the stock-standard approach that Xcode pushes) or C#/MonoTouch using Mercurial (my experience). While both of those approaches are fine for personal and small projects, we really wanted all the other bonus points that TFS provides (continuous integration, work item tracking, reporting, web-based project portal etc.)

So how'd we do it? Well, the first thing to note is that we're not actually building the application bundle using TFS - yet. That still requires a MacBook, MonoDevelop and a bunch of other stuff. We'll probably get there soon using custom build tasks, rsync, ssh and a few other things, but we're not quite there yet.

What we do have is a working continuous integration and nightly build, plus running tests using MSTest. The nice thing is that it actually wasn't that hard.

1. Open the project in Visual Studio (not MonoDevelop). You'll probably need something like Chris Small's MonoTouch Project Converter to make this work happily.
2. Include monotouch.dll in your /lib directory and reference it from there rather than from the GAC. (It won't be in the GAC on your build server, and nor should it be.)
3. If you have other dependencies (e.g. System.Data), copy those from your MacBook into /lib as well and reference those from there.
4. Done :)

The key point to note when you're building your app is that you're not going to be able to easily test your ViewController classes using MSTest, so make them dumb. If there's business logic in there, extract it out into your domain model. If there's data access logic in there... well... you're doing it wrong anyway and you should definitely extract that out :)

You'll end up with an app that has a dumb(ish) UI shell wrapped around a bunch of well-tested business logic classes. The added bonus of doing it this way is that you can then re-use a lot of that code when you write your WP7 or Android version.

The outcome? The visibility we wanted from the reporting and work item tracking side of things, plus a CI build that didn't require witchcraft to configure, plus automated unit tests.

The only real down-side of this approach is that the build we're unit-testing isn't the build we're shipping - we still have to build that manually on a MacBook somewhere. It does, however, give us a good indication of our overall code quality and a reliable safety net for refactoring.

I just submitted this abstract for DDD Brisbane 2011. Don't forget to vote for me!

An iPhone Eye for the C# Guy

iPhone Development using MonoTouch

This session will cover the basics of developing an iPhone application using C#/MonoTouch, from how to create a "Hello, world!" app through to a look at a real-world, production codebase.

We'll cover the use of web services, threads, databases, generics (yes, you can use generics), reflection, inversion of control (yes, you can use IoC, too!) and general application architecture, and finish with a look at some tools, tips and tricks to make life as an iPhone developer much less painful.

This session will assume prior knowledge of threading, reflection, generics, inversion of control and why you'd want to use all of these, but don't let that scare you :)

Customer: Your app crashed again.
Developer: How? What were you doing when it crashed? What happened?
Customer: I don't know. I was playing with it and it crashed.
Developer: Do you remember which page you were on?
Customer: ?
Developer: bangs head against wall
Sound familiar?
One of the first things I do when I start a project (or when I inherit one) is set up logging. You'd be amazed and depressed at how many projects just don't have any, or bolt it on as an after thought. Here's a hint: it's much easier to debug your app while you're developing it if you know where it's breaking. Ground-breaking, I know
There are a couple of things we want to do:
1. Log when the app crashes. Do it quickly and reliably, and don't rely on any app infrastructure (e.g. injected loggers) as it's already been torn down at this point. 2. Send the log message the next time the app starts. This will allow us to use all our nice web services etc. and means we can use just the one logging mechanism rather than having several different ones. MonoDevelop creates a fairly standard-looking Main.cs for us:

Let's change that to add a simple try/catch block:

The key here is line 11 - it makes it simple and obvious as to what it's doing.
So... the CrashLog class itself is a static class and doesn't do very much at all. The idea is that it's simple to call and doesn't rely on having any of the app's components still available.

We're using the My Documents special folder as that's where we're reliably allowed to write things to on the filesystem.
So now that we have our crash logger, let's hook things up so that we can log when the app starts again. In our AppDelegate class:

Yes, we're using our IoC container as a service locator. This isn't good, but we can't use constructor injection in our AppDelegate as it's the class responsible for creating our IoC container.
So how does the logger work? Well, that's up to you. You can choose to make a web-service call; you could spit it to another text file and periodically upload it; you could even send an email if you really wanted to.
My preference is using a web service as I tend to just hook it straight to the server-side logger (which usually uses log4net under the covers), but your mileage may vary.
The next time a customer tells you that your app crashed, though, you'll be able to respond with, "I know - and I've already fixed that bug."

Ever heard of a cargo cult? It's a term describing the philosophy of many pre-industrial tribes in the Pacific during World War II with respect to the "cargo"; i.e. the foodstuffs and equipment called in by American and Japanese radio operators. The thinking went that the Americans and Japanese had appropriated (stolen) the cargo that rightfully belonged to the natives by means of liaising with the gods.

The interesting thing isn't the belief that the cargo was stolen but more that the means of stealing it back were novel. The natives began to imitate the radio operators in the hope that building the same items of worship (realistic-looking radio sets, landing strips and in some cases even mock aircraft), and memorising the noises that the operators made and faithfully reproducing them, would help them divert the cargo back to its rightful recipients.

So what on earth does this have to do with software? Well, take a look around at most software projects you've been involved in. Why do we have multiple web service layers? Why do we separate concerns? Why do we abstract our data layer(s)?

There are legitimate (and good) answers to these questions, but the most common one is "because everyone else does it." In other words, other people do these things and receive good software ("cargo") in return, so if we do it then perhaps *we'll* receive the cargo instead. The key is that some people understand why they do it, and some people just mimic it.

This post was prompted by a recent experience in which I ended up tearing apart an entire application (data access layer, service layer to access data, business logic layer, view/presenter layer etc.) and rebuilding it with something sensible - and all because someone tried to do it right and sadly had no idea how to do it.

I've seen so many software projects started with the absolute best of intentions. In most cases I honestly can't fault the effort or the diligence displayed by the original developers - after all, almost nobody deliberately sets out to do a poor job. It's heartbreaking, for example, to see someone having spent weeks or even months of their life inserting a web service layer for data access without understanding why they're doing it, then complaining that their app's too slow because every action ends up requiring a full table fetch. Equally, I've seen people follow the Single Responsibility Principle to a ridiculous extent but end up with utterly unmaintainable code because they didn't properly understand why it's important. MVC, MVVM, n-tier... they're all useful tools in the box, but all too often they're just fake radio sets made of wood or landing lights that don't emit light.

Go on. Laugh. Laugh rudely at the natives. You know you want to.

Then cry, because you know it's true - and because, at least once, each of us has been one of them

Finally, to stand on my fake soapbox for a second: go and teach your craft, so that you (and all of the rest of us) don't have to clean up messes like these, and destroy someone's prized wooden radio set while we're at it.

P.S. Credit to Paul Stovell, whose tweet finally prompted me to finish and publish this blog post.

I saw a question on /. this morning about exactly this and decided to blog it rather than comment as it's another one of those "I hear this question all the time" posts.

The question's usually along the lines of, "I'm really good at my job. How come I can't get promoted?"

The simple-yet-offensive answer is this: you haven't done a good enough job to be promoted.

Before everyone starts screaming, let's look at this from the perspective of a mythical manager who actually wants his/her employees to succeed. I know, I know, but they really are out there. So... what goes on?

Usually the internal monologue goes something like this:

1. John's doing a really good job running X/Y/X.

2. I like John and want to promote him.

3. There's a position running a new project and I'd really like to offer it to him.

4. I have nobody to replace him with and would need to train a replacement.

Oh, bollocks. John's just made it impossible for even the best-intentioned manager to promote him. Now imagine what a less-well-intentioned one would do.

At any one of these stages a promotion is easily killable. If John isn't doing a really good job running X/Y/ then there's no way that he's going to be promoted except under the Dilbert Principle. Similarly, if John isn't well-liked then there's no way he's going to get promoted simply because dealing with unpleasant people is unpleasant and a good manager isn't going to inflict an unpleasant person on other people if he/she can at all avoid it. The third one's obvious: if there's no promotion available then there's no promotion available.

The fourth point, though, is the one that almost invariably gets forgotten. I've blogged about this before but the gist of it is that if John's made himself indispensible then that's the end of it. Indispensible means that he cannot be done without; in other words, he's locked himself into his current position all by himself. John hasn't done a good enough job to get promoted because he hasn't trained his own replacement.

Training your replacement is part of your job.

So why don't people do it?

The most obvious answer is fear. Fear of being replaced by someone younger and cheaper; fear of being shown up by someone who ends up knowing more than you; fear that your management won't see this as a valuable use of your time. There's also fear of the unknown - it's much easier in many cases to perennially gripe about being really good but not getting promoted than it is to actually get promoted and run the risk of failing in your new position.

There are other likely culprits (budgetary constraints, time pressure etc.) but the point of this article is that they're all surmountable once the fear is overcome.

Of course, if you're incompetent then you should feel fear - and you should expend all your efforts on trying to get better. Ironically, if you're not very good then you'll probably find that people will actively try to promote you according to the Dilbert Principle. Has an unsolicited promotion offer come your way recently just when you thought you were really struggling? Ouch. Sorry.

I want a promotion. Should I stay in my current company or look elsewhere?

The short answer to this is: go wherever your interests take you.

The longer answer: if you like your company and want a particular position, ask for it. It's much easier to just tell people what you want and ask what you need to do in order to get it. You never know - they might not have realised that you're bored or unhappy where you are, especially if you're keeping things running smoothly and appear to have it all under control.

If your current company can't or won't accommodate you then, by all means, look elsewhere. Before doing that, though, take a good, hard, honest look at yourself and ask whether you'd promote you if you ran the company. If the answer's yes but the company won't then it's time to move on. If the answer's no then it's probably time to ask for help - and also to start making some serious efforts towards your own professional development.

Finally...

Finally, if your company's regularly appearing on FC or NGE then it's time to jump ship no matter how good you are

As a consultant, there's a very common complaint that I hear from clients. The complaint is along the lines of, "It's all such a mess," or "We need to re-write it from scratch." They're almost always right in the first case, and almost invariably plain wrong in the second. A messy codebase is a pain, but learning the wrong lesson from it just means that they're going to experience the same pain all over again once they've done their re-write - if they're still in business when they finish.

The first question to ask is simple: why is it all such a mess? If it's a mess because you made a completely wrong technology choice (e.g. classic ASP for a point-of-sale application, or a thick client where a web client was required) or the team that wrote it simply didn't have a clue and have all been fired, then perhaps a re-write is in order. Other than that, there's almost no good reason to do a complete re-write. Regardless, that's not the point of this post.

The point of this post is that it's usually such a mess because people don't know how to fix it - or, more probably, people don't know how to even decide on a strategy to follow and are drowning in technical debt as a result. Here's a simple one:

Fix what you know is broken.

If you honestly have no idea, go and ask someone who has. Firstly, though, try this:

Do you have source control? No? Then download Mercurial and fix that.
Do you have continuous integration? No? Then download TeamCity and fix *that*.
Do you have unit tests? No? Then go and write at least a "Hello, world!" test to get yourself started.
Do you have an issue-tracking system? No? Then go to AgileZen or similar and get one.
Do you have an automated deployment solution? No? Well... you know the drill.

There's really no excuse for not having these sorts of tools. Moreover, there's no excuse for not having the agility that these sorts of tools offer.

Once you have a build, a rudimentary test suite and a deployment solution, the next step is clear:

Fix what you know is broken.

What's at the top of your issue-tracking list? Does it make sense? If so, then that's what's broken. Go and fix it. If not, then its priority is what's broken. Fix it by re-prioritising it so that it *does* make sense.

I visited one client recently that had a test automation task as a "drop everything and fix now" priority - but below that were cases that were costing parts of their business money every single day. In this case, the prioritisation was broken. So... fix it and move on.

Once you've fixed something that was broken, release it. That's right: release the thing. "Oh," you might say, "but it has to go through n levels of QA, UAT and sign-off first." Guess what: that's the next thing that's broken. So... given that you know what's broken, what now?

Fix what you know is broken.

I'm starting to sound like a broken record here, but I'm also starting to sound like a broken record whenever I have to deliver this lesson in person :)

You need to get your release cycles down to something manageable, and if you've had a messy codebase for a while then I guarantee that you're afraid of releasing to production because of what might have changed while you weren't looking.

The solution is to start releasing earlier and more often. Get used to the idea that a production release is boring and routine, not unfamiliar and scary. Releasing to production should be scripted and ideally entirely automated (but that's the subject of a squillion other blog posts) so I'm not going to re-hash it here. Just accept that if you're afraid of releasing to production then that's the next thing that's broken. After all, if you haven't changed the code since your last release then what's likely to go wrong? If you *have* changed the code, then what you're really afraid of is your testing regime, not deployment per se.

Once you have your releases automated and none of the above things are scary any more, you're down to the boring, menial task of just chipping away at your technical debt. Identify the highest-priority item to fix; fix it; release it.

It really *is* that simple, ladies and gentlemen

I've just spent an entire day on this. Moreover, it's a day that I really couldn't afford to waste right now. Hopefully this minor rant will save someone else the same pain.

The problem: the MS Test framework, QTTask.exe, sgen.exe and a bunch of others were throwing AccessViolationExceptions in all sorts of places, but most painfully during my CI build. This mean that our build server couldn't run our unit tests, which meant that TFS Deployer wouldn't deploy because it thought the build was bad.

A red herring presented itself in the form of SQL Server Management Studio also falling in a heap, which led us to believe that it was an issue with the server image.

After wasting an entire day re-provisioning VMs from images, the simple solution was to turn off Symantec's endpoint protection.

Corporate security policies be damned - if you're going to break my build at crunch-time on a time-critical project, you're part of the problem.

End rant.

I recently had a situation with a client who had a requirement to use Silverlight 4.0 with RIA Services for an application under development. I've used WCF RIA Services on and off and have a bit of a love-hate thing with them (they wreak havoc on ReSharper's Adjust Namespaces feature, for instance, which is an OCD habit of mine), but using them really did make sense in this client's case.

Anyway... The client's application had to interface with a legacy database and no schema changes are permitted (sound familiar?). The database was a monster, with over 300 tables, 255 columns per table in some cases, no referential integrity constraints and eight-character field and table names.

If I'd had a month just to map it, I'd have suggested NHibernate for its ability to tie itself into knots to allow arbitrary key constraints and other cleverness. As I just don't have a month, however, the client's going with EF because it automatically builds a map that makes me cry a beautiful map of the database schema as-is.

Adding a Domain Service based on an EF data layer is also trivial - RIA Services has a magical code generator that builds the entire suite of CRUD WCF services for us and it's entirely possible that we'll never need to tweak them.

If you have a look at the SilverlightApp project at the top, you'll see a "Generated_Code" directory that contains all of the generated proxy code for all the domain services advertised by the SilverlightApp.Web project.

The catch is that it generates proxy code for every single class advertised by EF (although it's selectable, in this case it's actually required), which in this case results in approximately 300,000 lines of code.

The Problem

It takes a long time to compile 300,000 lines (about 10Mb) of code, especially every single time a completely unrelated change is made to the UI.

Enter RIA Services Class Libraries.

RIA class libraries are not your garden-variety of class library. They're not particularly well documented and are fairly unintuitive. If you follow the standard directions you'll miss the really clever part, which is the part that makes it worth-while to use them in the first place.

The key is that we want all the generated code in a library that we don't compile every single time we make a UI change. So... how do we do that?

Creating and using a WCF RIA Services Class Library

1. Create your Silverlight project (use the Business Application template if you don't have any pressing need not to - it's great).

2. Add a new "WCF RIA Services Class Library" to your solution. This will create two projects: the class library itself and another web project to host it in.

3. Add a reference from your existing web site to your new class library's web site.

4. Add your domain services into your class library's web site instead of your main web site. For the sake of an example I've added a domain service around pet ownership, with Pet and Owner entities.

You're not done yet! This is the part where it will all actually work, so people tend to forget the next step. I'll show you that in a minute.

Let's have a look in the Generated_Code folder in our main Silverlight app at this point. Firstly, make sure that you've checked the "Show All Files" button for the SilverlightApp project so that you can see the Generated_Code directory:

Open the SilverlightApp.Web.g.cs file and have a look. You should see something like this:

Note the definition of a proxy class for the "Owner" entity. Hang on a minute, though - this class was supposed to be in the class library - we don't want it in our main application. The whole point of this exercise was to not have all this generated code in our main Silverlight application as it takes too long to compile. The next step then:

5. Add a reference from your Silverlight app to your Silverlight class library. This is the obvious step but it's the one that lots of people miss, hence this blog post.

The WCF RIA code generator is actually very clever and it works out which entities you have proxy code for already to and only generates code for the ones you're missing.

Once you add the reference, if you leave the generated code file open, this is what you should see:

Ooh! No proxy code for our entities! Our compilation times just plummeted

This one's a very irritating gotcha. I guess it illustrates the value of good, descriptive and above all, appropriate, error messages.

One configuration below is obviously wrong and evil; one is all that is good and wholesome. You spot the difference

Hint: don't put a trailing slash on your TFS server name or you'll get the error that's in the title of this post.

I hear variations on the theme of this question all the time:

"Oh, so that's all. That's really easy."

"Really? That's all it does?"

"So where's the hard part? I understood that straight away when I looked at it."

Sometimes these questions are even asked of me, which is flattering ;) The flippant answer, of course, is "So that any idiot can come along and understand it." Disappointing though it might be, this answer is also quite correct.[1]

If you only ever take one piece of advice from this blog, take this one: Code yourself out of your job.

Coding yourself out of a job doesn't mean you're going to get fired when you're done.[2] Coding yourself out of a job means that you don't end up responsible for the same chunk of a project forever, always fixing bugs in it because it's too complicated, too involved or just plain scary for newcomers.

There's an art to having someone look at your code and understand it at a glance. It's a subtle display of skill, the result of which being that the person reading your code doesn't even realise that you got inside their head before they ever arrived, understood what they'd be thinking when they looked at it and gave them subtle cues as to which parts of the code were the ones they were looking for.

There's also a corresponding amount of confidence required in order to be able to choose a less optimal solution in terms of performance for the sake of comprehension. Why confidence? Because as part of having your code look simple, you have to be willing to have someone stroll along after the fact and ask within two seconds of looking at your solution, "Why did you choose this way? This other way's almost twice as fast..." That, my friends, is the whole point: they understood it within two seconds of looking at it.

One "I don't understand" question about a piece of code and unless it's a really, really fast and effective algorithm and the alternatives are awful, it's already cost more in real terms than its fast performance has saved.

Obviously in heavily-hit code paths this would not a good choice, but if I have a method that only gets executed a few times per second then I honestly don't care whether it takes 0.01s or 0.001s to execute. If there's no other real difference between the two then of course I'm going to pick the faster one, but if the screamingly fast one is horrendously complicated and I'm going to be the one who'll have to come back to it every time it needs modifying, then I'll take the quite fast one, thank you very much.

At the point where someone asks why you made a sub-optimal performance decision, you have to be sufficiently confident in your own ability to explain to them that yes, you could have done it another way, but then it'd take longer for every single person who came after you to understand what was going on, you'd have to field more questions about it, and that it actually didn't matter[3]. You also have to be sufficiently confident in yourself to evaluate their solution and confess on occasion, "Actually, I really do like your solution and it's better than mine. Let's do it your way instead."

In a nutshell, the optimal solution is not necessarily the fastest, but the most effective in terms of the long-term maintenance of the application.

Of course, the really smart ones amongst us can write code that's simple, obvious and extremely fast. And we're all that good, right? ;)

[1] Especially when that idiot might be yourself six months later...

[2] Unless you work for a stupid company, in which case you need to leave now anyway.

[3] Be correct about this, though. If it matters, do it better.

One of the most common tasks a software developer will perform is that of creating a bug or a task in an issue-tracking system. Before a task or a case is created, the developer should search for an existing case in the system so as to avoid duplicates. This should, then, according to Amdahl's Law1, be very fast and simple to do.

Team Foundation Server, however, does not make this simple and fast. Please excuse me for not having the energy to articulate the failings of TFS in this respect, and simply offer a solution instead.

Enter EasyTfs.

EasyTfs will search your TFS database as you type, allows per-field matching, regular expressions and all sorts of other goodies that real issue tracking systems have had for years.

Searching for "coffee" in our TFS database here results in this:

We could also search for "createdby:tullemans coffee", "cr:dan coffee" or simply "3165" (the work item number). Image attachments (.png and .jpg) are displayed as thumbnails by default and can be displayed full-screen just by clicking on them.

Searches are quick, too :)

It's read-only and ignores work-item security for the present (early beta and all that), but it's fast and has already saved our team a huge amount of time, both in simply finding cases that we know exist, and also in avoiding raising duplicate cases because it's so much easier to search for them.

It's open-source (GPLv2), and you can find both the source code and a Windows installer (.MSI) at easytfs.codeplex.com.

1 which can be summarised as, "Make the common case fast, damn you!"

Here's a hint to the Visual Studio team:

If I have to wait so sodding long for a modal dialog box to just GTFO of my road that I can write an entire blog post about it, you're doing it wrong!

Every VS developer knows about that stupid sodding help popup, and we all hate it. It's of absolutely no help whatsoever and, just FYI, most of us just re-map F1 to a do-nothing macro.

When reviewing code, everyone picks on different things. This is a good thing, provided that code reviewers move around frequently and everyone gets to benefit from the resulting sharing of knowledge.

Here's a bunch of anti-patterns that have bitten teams and companies that I've worked with in the past, and some ways to avoid them. This is by no means a complete list; it's simply the ones that keep jumping out at me and, more so, the ones that tend to cause pain later rather than sooner with a corresponding degree of compound interest on the original technical debt.

Always picking the same code reviewer.

Asking the guy next to you for a code review is great; just don't do it all the time. That one guy next to you will always pick on the same things, and will likely miss (or simply not value) other points that another reviewer might pick up.

The guy next to you is also probably going to become familiar with the code you're working on. Again, this is often a good thing but it also means that your code, while obvious to you and your favourite reviewer, might become impenetrable to others without your realising it.

Additional "using" Statements

"Using" statements, especially when highlighted by your favourite diff tool, are a good (and simple) indicator of increased class coupling. This isn't always a bad thing, but should always be studied rather than glossed over.

This should also be your cue to check whether the new code has dependencies on concrete classes in the newly-used namespace, or whether someone's been clever and has coded to an interface.

using System;
using System.Text;
using My.Useful.Namespace;
using My.Specific.Namespace.That.I.Shouldnt.Know.About;  // one of these things is not like the other...

Pointless Safe Casts

This is a complete pet hate of mine, as many times I've spent ages tracking down some random NullReferenceException or Debug.Assert( ... != null) failure because someone's used a safe cast and then blithely assumed that the result will be non-null.

// BAD!! This is a NullReferenceException waiting to happen!
ISpecificThingy specificThingy = thingy as ISpecificThingy;
specificThingy.DoSomething();

// GOOD.  This will (correctly) throw an InvalidCastException at the point of the error, rather
// than allowing a null value to propagate along the code path and trip someone up later.
ISpecificThingy specificThingy = (ISpecificThingy)thingy;
specificThingy.DoSomething();

Non-thread-safe Collection Modification

This probably won't bite you, but it will bite someone else who has to come along three months later and figure out why there's some random, non-deterministic explosion. That person, however, will probably kick you, so it all balances out in the end.

// BAD! This is not thread-safe, and is an ArgumentException (item with same key...) waiting to happen.
public void Remember(string k, string v)
{
    if (!_strings.ContainsKey(k))
    {
        _strings[k] = v;
    }
}

// BETTER. This is thread-safe and won't explode. What's missing, though?
public void Remember(string k, string v)
{
    if (!_strings.ContainsKey(k))
    {
        lock (_strings)
        {
            if (!_strings.ContainsKey(k))
            {
                _strings[k] = v;
            }
        }
    }
}

// GOOD
public void Remember(string k, string v)
{
    #region Argument Checking

    // ... actually check arguments, here :)
    
    #endregion

    if (!_strings.ContainsKey(k))
    {
        lock (_strings) // careful, though - when locking on arbitrary objects, it's easy to create deadlocks.
        {
            if (!_strings.ContainsKey(k))
            {
                _strings[k] = v;
            }
        }
    }
}

Catching NullReferenceExceptions

It's just bad. Please don't do it - and never let your name be associated with a review of code that does.

try
{
    myFoo.Bar.OtherProperty.DoSomething();
}
catch(NullReferenceException)
{
    // Hi. I'm so utterly lazy that I can't be bothered to null-check things, *or* to
    // de-couple my classes so that I don't *have* to null-check so many things.
    //
    // Please beat me around the head with a stick.
}

Mapping Symbol Names to Strings

// BAD!
string fooTypeName = foo.GetType().FullName;
if (fooTypeName.Contains("Widget"))
{
    // we have a widget!
    widgets.Add(foo);
}

// BETTER
WidgetBase widget = foo as WidgetBase;
if (widget != null)
{
    widgets.Add(widget);
}

// GOOD
IWidget widget = foo as IWidget;
if (widget != null)
{
    widgets.Add(widget);
}

I'm an upgrade junkie. I really like having the latest and greatest of every piece of software on my workstation. That having been said, I absolutely hate with a passion having to update the whole lot of it manually.

I just returned to work from a week's holiday. (It was a great holiday, by the way - I did almost entirely nothing - but that's not the point of this post.) Let's go through the list of software that pestered me to update it upon my return:

• Firefox (Twice - once to 3.5.7 then another to 3.6! What happened there, guys?)
• Adobe Reader
• Opera
• Windows (surprise)
• Java
• Forefront
• Seesmic
• Firefox (Again!! ("Downloading and installing updates to your add-ons." WTF?)

The list actually goes on, believe it or not, but I'm already fed up with the sight of little scrolly bars.

A plea, then, to all software developers: make your software update itself automatically and silently.

I've been walking around all morning asking people, "Does anyone know what version of Google Chrome we're up to now? Four! Chrome 4.0 and nobody's noticed, because it updates itself silently." As it turns out, we're actually up to version five, and I didn't notice - for the same reason. Chrome team, I take my hat off to you.

Here are a couple of simple questions you should ask yourself as a developer:

1. Is my software life-, mission- or business-critical? That is, will people die or lose vast sums of money if my software fails?
2. Are my unit and regression test suites up to date? Will I be able to tell if I've broken my software?
3. Am I going to change my licence agreement?

If you're writing, for example, an enterprise-grade business intelligence suite, then perhaps you shouldn't auto-upgrade. By all means, make it easy for people to upgrade, but don't do the whole ninja-update-sneak-it-in-at-midnight thing.

If you're writing pretty much any other type of software, here's a tip: users don't care about point releases. They don't care about bug fixes unless it directly impacts them. They don't even really care about major feature additions - they're obviously already using your software, so it must be fulfilling some need for them. By all means, add features, but do it in a way that isn't disruptive to your existing user base.

Users, to be honest, really don't care about anything much, other than how to get their work done - and your stupid "Update Me! Now! Now!" dialog box is just getting in their way.

This is one that's irritated me just a little for ages, but never as much as this morning, when I needed to create a whole swag of small-ish flags enums and then test for bits set in them.

Here's a quick solution:

public static class FlagExtensions
{
    public static bool HasFlag<T>(this T target, T flag) where T: struct
    {
        if (!typeof(T).IsEnum) throw new InvalidOperationException("Only supported for enum types.");

        int targetInt = Convert.ToInt32(target);
        int flagInt = Convert.ToInt32(flag);

        return (targetInt & flagInt) == flagInt;
    }
} 

Notably, while we can't use a where T: Enum constraint in our extension method, an enum (lower-case e) is actually a struct, so we can at least constrain it to structs and then do a quick type-check.

To use it to test whether an enum value has a particular flag set, try this:

MyFlagEnum flags = MyFlagEnum.Default;

if (flags.HasFlag<MyFlagEnum>(MyFlagEnum.Coffee))
{
    // our "Coffee" bit is set. Yum!
}

This is a very, very simple screen saver. I wrote it because I was fed up with not having one that did precisely what I wanted.

There will probably be updates to it, but it does what I want for now. Hopefully it'll work for some others, too.

Features

• Displays photos from your My Pictures folder and/or any other folders that you configure.
• Performs a simple cross-fade between images.
• Navigate forward/backward between individual images and image galleries.
• Multiple monitor support.

Screenshots

What's it cost?

Nothing. It's free. If I update it to do some cool stuff that other screensavers don't do then I'll start asking a small price for it but, for now, it's free.

Licence Agreement

Permission is hereby granted, free of charge, to any person obtaining a copy of this software to use it without charge. All other rights, including those to modify, copy, merge, sell, license, sub-license, publish or otherwise distribute the software, are reserved by the author.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Download and Install

To install it under Windows Vista or Windows 7, save it to your Downloads folder, then right-click the saved file and select Install.

To install it under Windows XP, just save it to C:\Windows\System32 and you're done.

I accept the licence agreement above. Download Ugly.scr.

Please let the screen saver report errors to me

I neither want nor care about your bank account details, Facebook password or whether you tweet or not. I just want to know when my app crashes or experiences an unexpected failure. You can, of course, turn off error reporting, but by leaving it turned on you'll provide anonymous feedback to me so that I can fix things that go wrong.

Okay, so I feel a bit stupid for not having noticed this before. I wanted to geo-tag my blog in FeedBurner and so flicked to Google Maps to work out the latitude and longitude of the head office of the company at which I work.

I found a quick guide on how to extract lat/long information from Google Maps on the Tech-Recipes site, which suggested centring[1] the map and then copying and pasting the following JavaScript code snippet into the browser's address bar:

javascript:void(prompt('',gApplication.getMap().getCenter()));

For the record, the code works, but that's not what caught my attention. The code runs, but the part that was new to me is that the code runs in the context of the current browser window and has access to all its variables. I'd never realised that before, hence why I now feel stupid.

Nonetheless, it means that I now have a quick way of executing arbitrary JavaScript when I want to poke around on a page but don't want to fire up a debugging tool.

Oh, and yes, jQuery expressions do work, but watch out for characters requiring escaping in your selectors.

[1] I'm Australian. That's correct spelling. So there :)

Google has just opened its Google Public DNS service to the public. It's very cool, but I'll come back to that. The coolest features of all, however, are the IP addresses at which the DNS servers live:

8.8.8.8

8.8.4.4

Odds are I'll never need to remember the IP address of another DNS server as long as I live :)

Okay, the other cool stuff. Firstly, it pre-fetches a bunch of records; secondly, it handles recursive lookups; very importantly, it doesn't do the dodgy resolve-to-ugly-spammer-sites that lots of other DNS services do when they can't resolve a particular hostname.

It'd be nice to see localised versions of these so that those of us not in the United States of Litigation don't have to wait for packets to hop the pond and back, but I'm sure that will happen with time.

Oh, and for all the tin-foil-hat-wearing conspiracy theorists out there: yes, this means that Google can tell whose hostname you're looking up. Face it, though, you're probably going to be going there as a result of a Google search anyway, so they already know. I'd trust Google to "Do no evil" way before I'd trust my local ISP.

Microsoft released a preview of Internet Explorer 9 the other day. The world sniggered.

My favourite comment of all of the ones on the IEBlog was by someone known only as Justin": "Your browsers are bad and you should feel bad." Justin, if you send me an email I'll send you a cookie for that quote.

Don't get me wrong; I think it's great that Microsoft's finally staring to accept that their IE8 browser was obsolete before it even shipped. Their own graph shows that IE7 is around three times slower than IE8, which is in turn around five times slower than the next-slowest browser in circulation (Firefox), which is in turn at least twice as slow as Chrome. In other words, Microsoft's own graph shows an absolutely staggering performance difference between IE7 and the rest of the civilised world, and IE8 sitting all by itself in the middle. It's worth noting that while IE6 is also still a supported browser, Microsoft appears to have simply been too embarrassed to even include it.

Microsoft claims that IE9 today is about as fast as the current version of Firefox. Oh, but wait - IE9 hasn't shipped yet, and won't for ages, whereas Firefox is out in the market, systematically eating away at IE's anti-trust-derived market share along with its younger, slimmer cousins like Opera, Chrome and Safari.

Microsoft's next claim to fame is a massive improvement on their Acid3 test score, from 32/100 to... umm... 32/100. Hang on - what? You mean you've got an entirely new browser under development, guys, but you haven't fixed the core of what was broken with the previous one?

For the record, IE's performance is awful. We as professional developers accept that and dislike it, but it's only a reason to dislike Internet Explorer. The reason that anyone who's ever had to code for it hates the bloody thing with a passion is simple: it doesn't support nearly enough of the web standards that every other browser in common use does. Oh, and it leaks memory like a bloody sieve, too.

Oh, but wonderful - I can now have 96-point Gabriola text render really quickly and without jaggies. I can honestly say that of all my complaints about having to write code for Internet Explorer, that's been number one on my all-time wish list. Wow. I can die happy, now.

I'm not suggesting that Microsoft should stop development on IE. Far from it. Competition is good, right? If everyone were to adopt WebKit then we'd only be in a whole new world of hurt five years from now. What the entire development community would absolutely love to see, however, is this:

1. Fix the update mechanism. Has anyone noticed that we're up to Chrome 4.xx now? No? Why not? Because the thing updates itself, that's why. Make IE do the same, and ditch support for all legacy versions. If large corporate clients want to keep using IE6 for their intranet applications, fine. Let them. But if you continue to inflict IE6 and its misbegotten children on the world because of a few large corporate clients, the rest of the world is going to despise you for it. Rightly so.
2. Just make it work. We honestly don't care how fast it runs as long as it's within cooee of the others. We do care about having to write custom code to deal with the broken rendering engine, memory leaks and other nasties.
3. Stop bragging about until you've done it.

To be civil (which is less than you're getting from most of the web community), but blunt nonetheless: put up or shut up.

A while ago, I blogged about how it was amusing that Google had a new-ish product, SideWiki, that only worked in Firefox.

Google has just released a bookmarklet that will allow SideWiki to work in Chrome, Safari and others. Read their official blog post about it here, or, if you already have it installed, perhaps even consider annotating this blog post :)

This morning I cancelled an old account with a DNS hosting provider. I'd been signed up to them involuntarily by a web hosting company, which is one of the reasons it's no longer my osting company. No hyperlinks - I can't really recommend either of them and that's not what this post is about.

I clicked the "Account | Cancel" link and was presented with this dialogue box.

Please, guys. If you don't have a UI designer, get one. If you do have one, get another one instead.

Fail.

Let me start by demonstrating just a tiny amount of corporate cynicism.

"Blogging is so Web two-point-oh."

"Oh, but everyone has a blog."

"If you're not on, like, Twitter an' Facebook 'n' stuff, then you're like, a dinosaur or IBM or something."

Let's now all pause for a moment to welcome those companies that aren't, strictly speaking, technological leaders any more, to the blogosphere[1]. Congratulations, you've finally arrived. But what are we doing, here? What, when you get down to it, is corporate blogging all about? What should it be about? Why should a company do it? And when should it not?

A company should blog, first and foremost, when it actually has something to contribute to the world at large. Rambling personal blogs are fine for... well... personal purposes[2], but corporate blogs should be useful to current and potential customers, partners, shareholders and so on. They should also allow people within the company who normally wouldn't be at the front line of public relations to provide their perspective on things - otherwise, why have a corporate blog at all? Why not just have a series of press releases from your marketing department?

Having people within your company contribute to your corporate blog can be a two-edged sword. Unfortunately, it's one upon which many companies cut themselves. The pitfall should be obvious, but one damaging strategy that many companies employ is to sanitise or censor what their people say. I'm not arguing that you should permit people to blather your corporate secrets all over the web; merely that you should hire good people and then trust them to do their job well.

If you have a trusted, valued employee who's worked on your business-critical systems or in client-facing roles where they've already represented the company, you should trust in their professionalism and let them post what they deem appropriate.

If you have an irresponsible blogger who's publishing commercial-in-confidence information to the web at large, then you don't just have an irresponsible blogger. You have an irresponsible employee, who should be swiftly counselled or transformed into a former employee.

To Companies:

When asking your employees to blog on your behalf, you need to give them some guidelines about what they should and should not say, and you should also give them some benefits from doing so. I suggest these as a minimum:

1. We won't edit your posts. Period. We reserve the right to pull them from the site if absolutely necessary, after which we'll explain to you why we did so, but we will never edit anything that's been published under your name. Period.
2. We won't require an approval process. Post as you will. The corollary to this: be responsible with what you publish, because you will be held responsible for what you publish. We expect - and trust - you to do the right thing.
3. It's infeasible to track whether it was personal or company time on which you wrote a blog post, so it must be accepted that if you publish a post on our corporate blog then we own the content.
4. We grant you a perpetual and irrevocable (but non-exclusive) licence to use the content that you generate for our blog for your own purposes, including but not limited to syndication to your own personal blog, re-publishing as journal articles, or any other purpose you wish - specifically including for personal profit - provided that such use does not harm the company's reputation.

If you don't offer at least these guarantees, then your blogging-inclined employees will simply go off and publish their own content anyway, and you'll derive no benefit from their efforts whatsoever. Moreover, you'll have demonstrated a fundamental lack of trust in your employees that may well cause them to take their talents, not just their blogs, elsewhere.

If you can't offer at least these guarantees, then I respectfully suggest that a corporate blog is not for you.

To Individuals:

Carefully consider your personal reputation. If you haven't one, consider what you'd like it to be in a year or so's time. If you have one, consider whether the opportunity to blog for your company is more likely to enhance or damage it.

Consider whether you're likely to be permitted to express your real opinion on a matter, or whether you're going to be asked to be a corporate mouthpiece. If the former, great. Thank your employer and do the right thing by them. If the latter, I suggest that you respectfully and courteously decline the invitation to contribute.

Never lie. You needn't (and shouldn't) air your corporate dirty linen in public - everyone has it, and nobody appreciates seeing someone else's - but your personal integrity is yours to defend. If you disagree with a tactical or strategic decision made by your company, simply don't write about it. If you think Joe from Accounts is a cretin, keep it to yourself. Write about your area of expertise or influence; ask for feedback from your audience; allow your readers to understand that your company is thinking about their issues and exploring ways and means of helping its stakeholders.

Remember, if you blog as a corporate automaton, those of your readers who aren't very smart will probably take what you say at face value. Those of your readers who are smart and observant (those whom you should hope are your peers) will see straight through it, and these are the people who won't be hiring you at your next job interview - or whom you'll be trying to hire yourself. Presumably your peers are the ones you want to respect and admire you.

In General:

I was recently asked to contribute to a corporate blog. When I responded asking for the guarantees suggested above, I was surprised to learn that nobody had actually considered it yet. On reflection, that shouldn't have been much of a surprise - blogging is, after all, a relatively new beastie in corporate land.

The lessons to be learned from that, I guess, are to not be afraid to ask, and not be afraid to decline the opportunity if it isn't appropriate for you.

Will you see my by-line on a corporate blog any time soon? We'll have to wait and see :)

[1] Wow. Kudos to the Windows Live Writer team - their spell-checker actually recognises "blogosphere" as a word. Pity it didn't recognise "Facebook" :)

[2]  See my personal blog at uglybugger.org for a perfect example of that - anyone want a trailer? :)

Sir Winston Churchill once said, "Those who fail to learn from history are doomed to repeat it."

Cast your memory back to this particular gem: http://www.youtube.com/watch?v=gS0vZFPnksk

That stupid paperclip was one of the worst UI bungles in history, and one would think that Microsoft's UI designers would have done their absolute best to never irritate their users so much again. The lesson to learn is simple:

Never, ever steal the focus when your user is doing something unless it's absolutely critical that you do so.

Short on battery? Flash an icon in the notification area. (Hint to UI designers: in Windows, the system tray is generally at the bottom-right of the display. It has all these little notification-ish thingies in it. It's really remarkably useful.)

I have new email? That's nice, but I'm busy right now. Flash an icon in the notification area.

Someone's unplugged my headphones? Oh, that's right - that'd be me! Don't even bother flashing an icon - I know I unplugged the things. It'd be nice if your media player didn't stop when I did it, though.

Can't connect to the Internet? That's okay, too - you're already taking up two icons' worth of space in the notification area for no good reason, so perhaps you could re-use some of that.

Just about the only reason I can think of off the cuff to steal focus is if the device is critically low on power and is going to fail within the next thirty seconds or so. That's it. And even then, only do so once you've saved my work.

Everything else can be done by - you guessed it! - sticking a notification in the area reserved for them.

Enter Windows Mobile.

Windows Mobile has the extremely annoying habit of popping stupid notification balloons up over whatever I'm doing, just to tell me about something completely unrelated. I finally got so incredibly fed up with this that I decided to photograph it before I fed the device to the Kreepy Krauly. This behaviour is remarkably like Clippit, and even more annoying. What's worse is that this behaviour comes in a small, easy-to-fling-at-the-wall-when-you're-infuriated package.

Seriously, if you haven't taken the time to watch the Salmon Days clip above, now's the time: http://www.youtube.com/watch?v=gS0vZFPnksk.

"Hey, it looks like you're writing a text message!"

F***| off.

"Hey, it looks like you're driving somewhere and really can't afford to be interrupted!"

F***| off.

"Hey, it looks like you're trying to tell me where you want to go today!"

F*| off! I am not trying to connect to the f*|ing Internet, you stupid, f***|ing papercl.. oh, never mind.

Where do I want to go today? Well, I'm off to a dealership to replace this awful contraption. The only question is this: Android or iPhone?

A friend just dropped around and suggested that I have a look at Google's suggested searches for "why is".

Enough said?

Umm... what? Guys, didn't you realise that you have a browser all of your own? :)

I'm sure SideWiki's very cute, but I'm not willing to go back to Firefox to use it.

I'll be honest, Live Mesh: It's not me, it's you.

You're too slow.

You're unresponsive.

I need something larger, faster and more flexible.

I'm in love with Dropbox. (Disclosure: that's a referrer link from my user ID; I get free space if you sign up.)

To be fair, Live Mesh was (and is) a great idea. Unfortunately, it's been in its "Tech Preview" state for far too long. I can live with technical preview status, but what comes with that status is a 5Gb limit, which I just can't survive any more.

I want my data to be on someone's cloud, somewhere. I'm perfectly comfortable that I can encrypt my own stuff as I need to, before handing it over to somebody else. And Dropbox appears to fit the "someone else" bill pretty much perfectly.

It works across platforms; it has a browser interface; it does everything that Mesh does (that I want, anyway), but does it faster and more transparently.

Oh, and it does photo sharing as well. Picasa's going to get a run for its money, here - this is so incredibly easy to store and arrange files on that I'm seriously considering ditching my (paid-for) Picasa web albums.

A friend and colleague, Matthew Rowan, has just spent some time formalising some of the knowledge that many developers will have grasped intuitively with respect to process management - but that many won't have.

Automate, else Enforce otherwise Path of Least Resistance.

This is well worth a read as far too many companies get burdened with process documentation over actual workable process.

There's a nice feature in Outlook that allows users to automatically accept appointments, and even decline conflicting appointments. Unfortunately, what it can't do is allow you to specify specific reasons for rejecting meeting invitations.

A particular pet hate of mine is when people send a meeting invitation entitled "Foo Discussions" or some such, and fail to specify a location or any content. It's even more irritating when I'm trying to be a good little corporate citizen and have my calendar auto-accept appointments, but they send it ten minutes before the thing actually starts. They're going to receive an acceptance notice (of course) but my phone's not going to synch for a good half-hour, and there's just no way I'm going to be there. Funnily enough, I'm not just sitting around on my backside, waiting for someone to invite me to a meeting.

Oh, a meeting! How exciting! I've been waiting for one of these all day!

Of course, if you simply decline offending appointments manually, people tend to get offended. (Which may or may not be a good thing, depending on who it is.) A better way, however, is to automate the process.

Nothing personal, old chap - my calendar just has automation rules that apply to everyone.

The rules for getting into my calendar are simple:

1. Tell me everything I need to know about the meeting. This includes, specifically, its location. Outlook enforces pretty much everything else, but fails to enforce this one.

2. Please do me the courtesy of checking my free/busy information and *do not *attempt to trump something that's already been organised. It shows a complete and utter disregard for my time and that of anyone with whom I've already agreed to meet.

3. Do me the courtesy of giving me at least 24 hours' notice. Don't send me a meeting request at 7pm on Monday evening for 7:30am on Tuesday morning. I'm not going to read it, and I'm not going to be there.

I finally snapped today, after another imbecilic meeting request, and wrote these two quick methods. They enforce the three rules above, automatically accept the request if it passes and automatically decline otherwise. They appear to work for me; your mileage may vary. No warranties, express or implied, etc.

Sub AutoProcessMeetingRequest(oRequest As MeetingItem)

    ' bail if this isn't a meeting request
    If oRequest.MessageClass <> "IPM.Schedule.Meeting.Request" Then Exit Sub

    Dim oAppt As AppointmentItem
    Set oAppt = oRequest.GetAssociatedAppointment(True)

    Dim declinedReasons As String
    declinedReasons = ""

    If (oAppt.Location = "") Then
        declinedReasons = declinedReasons & " * No location specified." & vbCrLf
    End If

    If (HasConflicts(oAppt)) Then
        declinedReasons = declinedReasons & " * It conflicts with an existing appointment." & vbCrLf
    End If

    If (DateTime.DateDiff("h", DateTime.Now, oAppt.Start) < 24) Then
        declinedReasons = declinedReasons & " * The meeting's start time is too close to the current time. " & vbCrLf
    End If

    Dim oResponse As MeetingItem
    If (declinedReasons = "") Then
        Set oResponse = oAppt.Respond(olMeetingAccepted, True)
    Else
        Set oResponse = oAppt.Respond(olMeetingDeclined, True)
        oResponse.Body = _
            "This meeting request has been automatically declined for the following reasons:" & vbCrLf & _
            declinedReasons
    End If

    oResponse.Send
    oRequest.Delete

End Sub

Function HasConflicts(oAppt As AppointmentItem) As Boolean
    Dim oCalendarFolder As Folder
    Set oCalendarFolder = ThisOutlookSession.Session.GetDefaultFolder(olFolderCalendar)

    Dim apptItem As AppointmentItem

    For Each apptItem In oCalendarFolder.Items
        If ((apptItem.BusyStatus <> olFree) And (oAppt <> apptItem)) Then
            If (apptItem.Start < oAppt.End) Then
                ' if this item starts before the given item ends, it must end before the given item starts
                If (apptItem.End > oAppt.Start) Then
                    HasConflicts = True
                    Exit Function
                End If
            End If
        End If
    Next

    HasConflicts = False
End Function

Just open the VBA editor from within Outlook (Alt-F11) and paste the subroutines into the ThisOutlookSession project.

Then go and create an Outlook rule that calls the AutoProcessMeetingRequest subroutine for every meeting request you receive:

Those of your colleagues who persistently refuse to learn how to use email (an essential business tool!) will receive responses along the following lines:

New features are all very nice, guys, but:

a) that feature's been around for ages;

b) I hate it, as does everyone I know;

c) I've already told Messenger not to pop up the today box when I launch it, and this looks remarkably like you're ignoring your users' wishes for your own marketing purposes.

Back to Pidgin, methinks.

Stupid Question #1: What actually constitutes a conflict?

Is a conflict when two people have changed a file, or is it when two people have changed the same part of a file and VSTS needs assistance to resolve it? Every other (sane) version control system in the world interprets a conflict as the latter.

Stupid Question #2: How is it "Auto Merge" when I have to tell VSTS to merge?

Stupid Question #3: If VSTS could not-quite-auto-but-with-the-press-of-a-button merge, and it managed to resolve everything all by itself, why on earth does it pester me about non-existent conflicts all the time?!?!?

Perhaps these questions are stupid, but I most respectfully submit that the answers are stupider.

The genesis of this rant is that a colleague and I have just spent a couple of days diagnosing and fixing memory leaks (sorry, "pseudo-leaks"," according to Microsoft, which presumably means that the memory explosion we were seeing wasn't actually real) caused by awful, awful garbage collection in Internet Explorer.

The icing on the cake was finding this article: Understanding and Solving Internet Explorer Leak Patterns. The markworthy text is this:

Pseudo-leaks almost always appear on the same page during dynamic scripting operations and should rarely be visible after navigation away from the page to a blank page.
In other words, Microsoft Word doesn't leak memory either. All you have to do is close it, open it again and miraculously all the memory that it allocated and failed to release (but that somehow fails to meet the definition of "leaked") is released.

The whole point of Internet Exploder 8 was to build an AJAX-friendly browser. The subtext went along the lines of, "Well, all those AJAX-heavy sites like GMail, Google Maps, Hotmail etc don't perform well under IE7 and we're losing browser market share, so let's make a browser that is AJAX-friendly. But, at the same time, let's make developers require people to navigate away from that application before any of its memory is released."

We've just spent days diagnosing as many of the various ways that IE leaks memory (ways, incidentally, with which none of the other browsers seem to have problems), patching the jQuery core to cope with its idiocy and writing our own DOM garbage collection handlers to deal with it. The jQuery and GWT discussion forums reveal that these guys are having just as much pain, and for similar reasons.

To the IE development team: Please, please, please, guys, fix your sodding .removeChild method and everything that has anything to do with it. And don't talk to me about setting .innerHTML properties either until you have a browser that doesn't seg-fault when I do that to a table element, or when I manually break the relationship between a node and its parent. Finally, at least have the courage to confess that your browser does leak memory in these scenarios rather than some pathetic attempt at explaining why a leak isn't a leak. Grr!!

If you want to cringe, grab the sIEve tool (see Memory leak detector for Internet Explorer for a link) and point it at http://msdn.microsoft.com. Navigate around a bit and then have a look at the number of orphan DOM nodes. Consider how many full-page reloads MSDN causes, and compare this to your own AJAX application. Weep.

I've been playing with Drip and sIEve in order to find some memory leaks that we've been encountering under Internet Exploder.

Drip / IESieve, Memory leak detector for IE Internet Explorer .

If you haven't looked at your application with sIEve, you really should.

Garbage. Of course it can. What a stupid error message.

What it should say is, "Ancestors' control collections cannot be modified..." or "Control collections in a base server control class where a derived class uses markup cannot be modified..."

You'll see this error for a bunch of reasons to do with modifying control collections, and by and large it's probably because you're messing with someone else's collection. (Hint: don't do that. It's a bad practice. Clean up your code and don't mess around with other classes' internals. It's like reaching into someone else's trousers and adjusting things. You just don't do it. Ugh.)

Consider this scenario, though:

public class FooControl: UserControl
{
    HiddenField _hiddenFoo;

    protected override void CreateChildControls()
    {
        base.CreateChildControls();

        _hiddenFoo = new HiddenField { ID = "hiddenFoo" };
        Controls.Add(_hiddenFoo);
    }

    // Presumably we'll also actually *do* something with hiddenFoo, but
    // that's neither here nor there.
}

Remarkably boring. Until, that is, someone creates a control using markup (a .ascx control) and uses FooControl as the base class. All of a sudden, the exception above is going to be thrown, and you're going to be scratching your head, wondering what on earth's going on.

The most common scenario for this is where there's post data for your hiddenFoo field, and the page's ProcessPostData method indirectly calls EnsureChildControls() on everything it needs to in order to re-populate the control tree to where it was last time and then stuff the post data into the relevant field. This can sometimes (and don't ask me about "sometimes") lead to the above exception.

Calling EnsureChildControls() in your OnInit handler won't work, as your control's events won't reliably have started firing yet. (It might work, but it won't guarantee it.) Inspecting your Controls property at a breakpoint in CreateChildControls method will give you a clue, though: your child controls that are declared in markup already exist at this point.

What you want to do instead is the following:

public class FooControl: UserControl
{
    HiddenField _hiddenFoo;

    protected override void AddParsedSubObject(object obj)
    {
        EnsureChildControls();
        base.AddParsedSubObject(obj);
    }

    protected override void CreateChildControls()
    {
        base.CreateChildControls();

        _hiddenFoo = new HiddenField { ID = "hiddenFoo" };
        Controls.Add(_hiddenFoo);
    }

    // Presumably we'll also actually *do* something with hiddenFoo, but
    // that's neither here nor there.
}

The AddParsedSubObject method is what's called to add controls that were parsed from markup to your control tree. As we already know that our parsed controls are happily ensconced in our control tree, all we have to do is demand that all of our other controls get loaded first.

Bear in mind that this won't work if you're doing silly things with your control collection, and it will incur a slight performance hit: AddParsedSubObject is called once per markup element (including for whitespace literals) and calling EnsureChildControls will result in a check against ChildControlsCreated, so you're going to have a lot of those hits. Still', it's better than an unhandled exception, right?

Hmm. I spent today at work, optimising JavaScript and re-jigging chunks of Microsoft's scripting framework. It's a Sunday, by the way.

I then came home and spent the rest of the evening debugging WordPress XMLRPC.

My life is debugging.

Here's a cute new feature from Google: "Undo Send" in Gmail.

Official Gmail Blog: New in Labs: Undo Send.

Cool :)

Microsoft JScript runtime error: Sys.ArgumentUndefinedException: Value cannot be undefined.
Parameter name: type  

Type name defined in .js does not match GetType().FullName in .cs.

There are a bunch of people out there who are fed up with the lack of a console.log() equivalent in Internet Explorer. It shouldn't come as any surprise that I'm one of them.

For anyone who's ever tried to debug a whole bunch of JavaScript code and ended up with myriad alert('here') and alert('here2') calls just so they could see what was happening, console.log() became our friend very, very quickly. No surprise, however, that IE didn't have it.

It becomes significantly more painful, however, when you're trying to clean up JS code for the sake of performance. The usefulness of any metrics collected goes out the window once there's user activity involved. (Besides, clicking "OK" for all those alert boxes is a royal pain.)

(Hint to the IE8 team: Your product is still in beta. You must have a logging call somewhere. Publish it, please. Please. All the other browsers of note do.)

There are quite a few good console.log() equivalents out there, not the least of which are Faux Console and the Yahoo User Interface Logger Widget. For extremely light-weight applications, though, there was nothing that did just what I wanted, so I wrote one. You'll be depressed at how simple it is, and how easy it would have been for the IE team to have included this functionality at almost any point in IE's development cycle.

The JavaScript code:

// rudimentary javascript logging to emulate console.log(). If there
// already exists an object named "console" (defined by most *useful*
// browsers :p) then we won't do anything here at all.
if (typeof (console) === 'undefined') {

    // define "console" namespace
    console = new function() {
        // this is the Id of the console div. It doesn't actually need
        // to be a div, as long as it has an innerHTML property.
        this.ConsoleDivId = "JavaScriptConsole";

        // maintains a reference to the console output div, so that we
        // don't have to call document.getElementById a bunch of times.
        this.ConsoleDiv = null;

        // allows us to cache whether or not the console div exists, so
        // that we can just do an early exit from the console.log method
        // and similar if we're not going to put any useful output anywhere.
        this.ConsoleDivExists = null;
    };

    // this is an expensive (really quite expensive) string padding function.
    // Don't use it for large strings.
    console.padString = function(s, padToLength, padCharacter) {
        var response = "" + s;
        while (response.length < padToLength) {
            response = padCharacter + response;
        }

        return response;
    }

    console.log = function(message) {

        // this will be executed once, on first method invocation, to
        // get a reference to the output div if it exists
        if (console.ConsoleDivExists == null) {
            console.ConsoleDiv = document.getElementById(console.ConsoleDivId);
            console.ConsoleDivExists = (console.ConsoleDiv != null);
        }

        // only do any logging if we actually have an output div.
        // (Check using the cached variable so that we don't end up
        // with a bunch of failed calls to document.getElementById).
        if (console.ConsoleDivExists) {
            var date = new Date();
            var entireMessage =
                console.padString(date.getHours(), 2, "0") + ":" +
                console.padString(date.getMinutes(), 2, "0") + ":" +
                console.padString(date.getSeconds(), 2, "0") + "." +
                console.padString(date.getMilliseconds(), 3, "0") + " " + message;
            delete date;

            // append the message
            console.ConsoleDiv.innerHTML = console.ConsoleDiv.innerHTML + "<br />" + entireMessage;

            // scroll the div to the bottom
            console.ConsoleDiv.scrollTop = console.ConsoleDiv.scrollHeight;
        }
    }
}

Ideally you'd drop this into an included script file, but it's more likely that you'll paste it into a <script> tag in the header of your HTML document.

The HTML that creates the DIV to contain the output:

<!--
    This is here for JavaScript debugging. Please use calls to
    console.log(message) to log to this console, as we're emulating
    the console.log() function that real browsers provide.
-->
<div id="JavaScriptConsole" style="position: absolute; bottom: 30px; left: 30px; width: 600px; height: 200px; overflow: scroll; background-color: Yellow; color: Red;">
    <a href="javascript:document.getElementById('JavascriptConsole').style.visibility = 'hidden';" style="float: right;">Close</a> <span style="font-weight: bold;">JavaScript Console</span><br />
</div>

Note that this div also contains a hyperlink with JavaScript code in it to hide it.

A simple hello world script to log to it:

<script type="text/javascript">
    console.log("Hello, world!");
</script>

... and finally, the output:

... and why you really should care.

I'm sitting in a Microsoft user group meeting right now, and I am, to be honest, pretty unimpressed. Not with the presenters - they're doing a good job - or with the presentation, which is on what should be a fascinating topic, but with the people. Sorry, Microsoft, but the greatest problem you face right now is not your technology; it's pretty damn good[1]. It's the people who are afraid of using it - who, sadly, aren't very.

OK, I'm home now, so I can type properly.

The presentation topic was the� Azure Services Platform, which is� Microsoft's� � answer to the Google cloud. Azure is a fascinating topic, both technically and strategically. The technical merits I'll discuss in a minute. Strategically, however, this platform shows that Microsoft is quaking in its boots over what Google's been doing with cloud computing, and is now trying to play catch-up. The degree of success a) remains to be seen; and b) depends upon the aforementioned people who are going to have to want to learn to use and exploit its strengths.

This platform gives immeasurable advantages to whomever wants them: almost infinite scalability, massive parallelism and redundancy, no more worries about server provisioning or downtime... the list goes on.

One of the reasons I'm so irritated is that instead of asking intelligent questions like, "How much can we scale a single computational task?" or even "How does this compare to the Google cloud in terms of speed, flexibility and response time?" people asked questions around keeping their own servers ("Can I still be woken up at 3am when a server falls over, please?") and security ("Can I host my own database and have the platform talk to it?" or, in other words, "Can I still trust Microsoft with my unencrypted data, but nonetheless re-introduce my own single point of failure into an otherwise-well-designed system?"). Honestly.

I don't want to rant, so suffice it to say this:

Learn about your craft. Go and sign up for the Azure CTP. Go and get your Google App Engine key. Read about the Google file-system and Amazon's S3. And, while you're at it, go and re-read some Knuth and some Fowler[2], just because you should, and probably haven't.

Get some enthusiasm about what you're seeing, people. It's brilliant. Go and learn about it. For what it's worth, if you haven't been hanging out for a cloud computing solution from Microsoft for a very long time, I most respectfully suggest that you might be in the wrong profession.

�

[1] Except for Live Writer. What were you thinking, guys? Writing this post has been painful. I tried to screenshot the crash messages and embed them into another blog post (also in Live Writer) and it crashed, too. Fail.

[2] Who are they? Shame on you.

I know, I know. Lots of people have written about this one, but nonetheless it still gets used and I feel I should add my $0.02. (That's Australian money, by the way, so it probably works out at not very much in your own currency.)

This post is specific to C#, as .NET has the very nice feature of code attributes, specifically the ConditionalAttribute class which allows methods to be compiled and invoked by the JIT compiler only if there's a particular compilation variable set.

Consider the code below:

private static void Hello()
{
    Console.WriteLine("Hello, world!");
}

private static void Goodbye()
{
    Console.WriteLine("Goodbye, cruel world!");
}

public static void GreetTheWorld()
{
    #if DEBUG
    Hello();
    #endif

    Goodbye();
}

Let's say that we compile this in Debug mode with code analysis turned on and warnings set to errors. (We all compile with warnings == errors, right?) All is well.

We go to run our unit tests again in Release mode prior to check-in, so we recompile in Release mode. (Or, if we're lazy, we just check in from our Debug build and let our build server compile and run the tests in Release mode.)

Oops. CA1811 violation: you have uncalled private methods in your code. Please call them if you meant to call them, or remove them if not. The FxCop engine will never notice that our #if DEBUG directive has compiled out the call to our Hello() method, so code analysis throws an error.

Use this one instead:

[Conditional("DEBUG")]
private static void Hello()
{
    Console.WriteLine("Hello, world!");
}

private static void Goodbye()
{
    Console.WriteLine("Goodbye, cruel world!");
}

public static void GreetTheWorld()
{
    Hello();
    Goodbye();
}

This makes the compiler much happier.

Let's consider the first piece of code again, though, and edit it in Release mode. Perhaps we'd like to rename our methods to something more descriptive of what they do: PrintHello() and PrintGoodbye(). So, we whip out our trusty refactoring tool (^R ^R in Visual Studio) and tell it to rename our methods.

Here's what we end up with (remembering that we're in Release mode):

private static void PrintHello()
{
    Console.WriteLine("Hello, world!");
}

private static void PrintGoodbye()
{
    Console.WriteLine("Goodbye, cruel world!");
}

public static void GreetTheWorld()
{
    #if DEBUG
    Hello();
    #endif

    PrintGoodbye();
}

Oh, sod. We've introduced a compilation error because the refactor/rename operation uses the compiled version of the code to check for symbol usage, and our call to the former Hello() method doesn't appear in the compiled assembly because the #if DEBUG check caused it to not be compiled. We've left the old call to Hello() unchanged.

If we'd performed the same operation on the second piece of code instead, we'd be laughing.

The Brisbane Alt.Net User Group has launched. Check it out at Brisbane Alt.Net or, even better, turn up to the first meeting in February.

Just in case you missed it, the Windows 7 Beta is now available.

The Windows 7 Beta Kicks Off This Week - Windows 7 Team Blog - The Windows Blog .

As I've been officially on holidays for the last four days (yes, four days includes two days of weekend; /sigh) I haven't fetched it yet so I have no wisdom for anyone about what's good and what's not. Why not try it and see?

This tells me that I'm signed in in two places, even though a) I'm not, as I signed out on my laptop before I came in to work, and b) the first thing it's supposed to to if I am signed in somewhere else is sign me out.

This option still exists, but apparently isn't honoured.

I'm really quite surprised that I've never needed this before, but today I wanted to embed some JavaScript within a string contained in a C# class and format it using string.Format().

The problem? My JavaScript was a function declaration and therefore contained braces, but the placeholder delimiters in string.Format also use braces.

The solution: braces get escaped using another brace of the same sort.

string jsConditionalHelloWorldTemplate =
    "if ({0}) {{\r\n" +
    "    alert('Hello, world!');" +
    "}}" +
    "";

string sendToBrowser = string.Format(jsConditionalHelloWorldTemplate, "true")
writer.Write(sendToBrowser);

Simple, really, but not intuitive - most civilized formatters use a backslash to escape characters. Hmm.

If you read this post, please download the new beta of Windows Live Messenger, install it and turn on the Customer Experience Improvement Program feature.

Why? Because if enough of us do it, perhaps Microsoft will fix some of the issues before we're lumped with the thing for real.

There are a couple of things about the new beta (build 14.0.5027.908), however, that are driving me completely insane.

Firstly, Microsoft, could you please remove the stupid warning bar telling me that "Clicking this link might open your computer to security risks." For one thing, funnily enough, I know that. I should at least be able to make it go away after it's been displayed once. For another thing, it's warning me about a link that I sent, that just happens to be in my message history.

Secondly, the sign-on in multiple places feature is an absolute pain, even when it's supposedly turned off. It still keeps telling me that I've signed in in multiple places, even when the very next thing it does is sign me out. It also means that if I turn the feature on and then sign out of one machine for a few minutes, messages to me aren't presented as offline messages; they just never seen at all until I happen to move to the other one. That strikes me as a bit silly.

Finally, although it's petty: The whole point of having an adjustable profile picture size is to provide more screen real estate for messages. In the new Messenger, if I make my profile picture smaller, that's all that happens. That's kind of silly...

All in all, IMHO the new Messenger "beta" should really have been called an early alpha. Good ideas, but awful implementation.

Just for the record, I hate JavaScript. It makes me feel dirty. Nonetheless, if you're going to use a tool - even one that you hate - use it well.

Here's one that will one day bite you. Consider this code:

<html>
    <head>
        <script type="text/javascript">

            var OnLoad = function() {
                document.getElementById("cloneme").onclick = function() { alert("onload");};
                document.body.appendChild(document.getElementById("cloneme").cloneNode(true));
            }

            window.attachEvent("onload", OnLoad);
        </script>
    </head>
    <body>
        <a id="cloneme" href="javascript:alert('href');">Test Hyperlink</a><br />
        <br />
    </body>
</html>

If you drop it into a local .html file and point a browser at it, it'll look something like this:

There is a catch, however: although one hyperlink is a direct clone of the other, they're not identical.

If you click the first one, you'll see the order in which the events should fire represented by two alert boxes, the first one shouting "onload" and the second "href".

If you click the second one, you'll only see the "href" message.

Why is this?

The key point to remember is that the DOM object is being cloned from its textual representation. In other words, .clone() does not do a deep copy; rather, it effectively just creates a new node based on the .outerHtml property of the old node. Notably, that does not include any event handlers that have been attached programmatically.

While I think the .NET provider model is great as a means of codifying dependency inversion, it really irritates me that we have to create so many peripheral classes in order to use it.

For example, we need to create a strongly-typed collection class that contains them all (presumably a left-over from the .NET 1.x days where there were no generic types), we need a configuration section class just to support an addition to the (web|app).config file, we need the provider class itself (effectively a factory class) and we need the class(es) of which it provides instances. Oh, and the interface that our provider stuff actually provides.

Here's a code snippet (what's a code snippet?) for creating a .NET provider and all the associated paraphernalia. Unfortunately it dumps all the classes into one .cs file, but AFAIK there's no way to get a single snippet to create multiple files. You can (and should) do that yourself, though.

Handily, the snippet will also generate XML for you that can be copied/pasted directly into your (web|app).config file.

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>provider</Title>
      <Shortcut>provider</Shortcut>
      <Description>Code snippet for a .NET Provider implementation</Description>
      <Author>Andrew Harcourt</Author>
      <SnippetTypes>
        <SnippetType>Expansion</SnippetType>
      </SnippetTypes>
    </Header>
    <Snippet>
      <Declarations>
        <Literal>
          <ID>providerName</ID>
          <ToolTip>The name of the provider (e.g. "Cache", "Licence").</ToolTip>
          <Default>Stupid</Default>
        </Literal>
        <Literal>
          <ID>interfaceName</ID>
            <ToolTip>The name of the interface that the provider will return (e.g. "ICache", "ILicence").</ToolTip>
            <Default>IStupid</Default>
        </Literal>
        <Literal>
          <ID>defaultProvider</ID>
          <ToolTip>The name of the default provider instance to use (e.g. "Web", "File"). The suffix "$providerName$Provider" will be added automatically.</ToolTip>
          <Default>Default</Default>
        </Literal>

        <Literal Editable="false">
          <ID>className</ID>
          <ToolTip>The type of the owning class.</ToolTip>
          <Function>ClassName()</Function>
          <Default>StupidClass</Default>
        </Literal>

      </Declarations>
      <Code Language="csharp">
        <![CDATA[using System;
using System.Collections.Specialized;
using System.Configuration;
using System.Configuration.Provider;
using System.Diagnostics;
using System.Reflection;
using System.Web.Configuration;

#region $providerName$Provider

    [Serializable]
    public abstract class $providerName$Provider : ProviderBase
    {

        protected abstract string DefaultName { get; }
        protected abstract string DefaultDescription { get; }

        public abstract $interfaceName$ Get$providerName$();

        protected static void CheckForUnrecognizedAttributes(NameValueCollection config)
        {
            if (null == config)
            {
                throw new ArgumentNullException("config");
            }
            if (config.Count > 0)
            {
                string attr = config.GetKey(0);
                if (!string.IsNullOrEmpty(attr))
                {
                    throw new ProviderException("Unrecognized attribute: " + attr);
                }
            }
        }

        protected string VerifyInitParams(NameValueCollection config, string name)
        {
            if (null == config)
            {
                throw new ArgumentNullException("config");
            }

            if (string.IsNullOrEmpty(name))
            {
                name = DefaultName;
            }

            if (string.IsNullOrEmpty(config["description"]))
            {
                config.Remove("description");
                config.Add("description", DefaultDescription);
            }

            return name;
        }
    }

#endregion

#region $defaultProvider$$providerName$Provider

    public class $defaultProvider$$providerName$Provider : $providerName$$end$Provider  //TODO Implement abstract class "$providerName$$end$Provider"
    {
        //TODO Add or merge the following into your (web|app).config file.
        /*
        <configuration>
          <configSections>
            <section name="$providerName$ProviderService" type="FULL_NAMESPACE_HERE.$providerName$ProviderSection, ASSEMBLY_NAME_HERE" />
          </configSections>

          <$providerName$ProviderService defaultProvider="$defaultProvider$$providerName$Provider">
            <providers>
              <clear />
              <add name="$defaultProvider$$providerName$Provider" type="FULL_NAMESPACE_HERE.$defaultProvider$$providerName$Provider, ASSEMBLY_NAME_HERE" />
            </providers>
          </$providerName$ProviderService>

        </configuration>
        */
    }

#endregion

// The code below here is auto-generated and shouldn't need any manual
// editing unless you want to do interesting stuff.  -andrewh 18/9/08

#region $providerName$ProviderSection

    [Obfuscation(Feature = "renaming", Exclude = true, ApplyToMembers = false)]
    public class $providerName$ProviderSection : ConfigurationSection
    {
        [ConfigurationProperty("providers")]
        public ProviderSettingsCollection Providers
        {
            get { return (ProviderSettingsCollection)base["providers"]; }
        }

        [StringValidator(MinLength = 1)]
        [ConfigurationProperty("defaultProvider", DefaultValue = "$defaultProvider$$providerName$Provider")]
        public string DefaultProvider
        {
            get { return (string)base["defaultProvider"]; }
            set { base["defaultProvider"] = value; }
        }
    }

#endregion

#region $providerName$ProviderService

    [Serializable]
    public class $providerName$ProviderService
    {
        private static $interfaceName$ _instance;
        private static $providerName$Provider _provider;
        private static $providerName$ProviderCollection _providers;
        private static object _lock = new object();

        public static $providerName$Provider Provider
        {
            get { return _provider; }
        }

        public static $providerName$ProviderCollection Providers
        {
            get {
              LoadProviders();
              return _providers;
            }
        }

        public static $interfaceName$ $providerName$
        {
            get
            {
                if (_instance == null)
                {
                    _instance = LoadInstance();
                }

                return _instance;
            }
        }

        private static $interfaceName$ LoadInstance()
        {
            LoadProviders();
            $interfaceName$ instance = _provider.Get$providerName$();

            // if the default provider fails, try the others
            if (instance == null)
            {
                foreach ($providerName$Provider p in _providers)
                {
                    if (p != _provider) // don't retry the default one
                    {
                        instance = p.Get$providerName$();
                        if (instance != null) // success?
                        {
                            _provider = p;
                            break;
                        }
                    }
                }
            }

            Debug.Assert(instance != null);
            return instance;
        }

        private static void LoadProviders()
        {
            if (null == _provider)
            {
                lock (_lock)
                {
                    // do this again to make sure _provider is still null
                    if (null == _provider)
                    {
                        $providerName$ProviderSection section = LoadAndVerifyProviderSection();
                        BuildProviderCollection(section);
                    }
                }
            }
        }

        private static void BuildProviderCollection($providerName$ProviderSection section)
        {
            _providers = new $providerName$ProviderCollection();
            ProvidersHelper.InstantiateProviders(section.Providers, _providers, typeof($providerName$Provider));

            if (_providers.Count == 0)
            {
                throw new ProviderException("No providers instantiated");
            }

            _provider = _providers[section.DefaultProvider];
            if (null == _provider)
            {
                throw new ProviderException("Unable to load provider");
            }
        }

        private static $providerName$ProviderSection LoadAndVerifyProviderSection()
        {
            // fetch the section from the application's configuration file
            $providerName$ProviderSection section = ($providerName$ProviderSection)ConfigurationManager.GetSection("$providerName$ProviderService");
            if (section == null)
            {
                throw new ProviderException("$providerName$ProviderService section missing from (web|app).config");
            }

            return section;
        }
    }

#endregion

#region $providerName$ProviderCollection

    [Serializable]
    public class $providerName$ProviderCollection : ProviderCollection
    {
        public new $providerName$Provider this[string name]
        {
            get { return ($providerName$Provider)base[name]; }
        }

        public override void Add(ProviderBase provider)
        {
            if (null == provider)
            {
                throw new ArgumentNullException("provider");
            }

            if (!(provider is $providerName$Provider))
            {
                throw new ArgumentException("Invalid provider type", "provider");
            }

            base.Add(provider);
        }
    }

#endregion
]]>
      </Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>

What more need I say? jQuery is making my life bearable.

From Simon Willison's blog:

I feel dirty. Oh, so dirty.

Internet Exploder runs script evaluated using the JavaScript eval() function in the global scope.

So what?

Well, if you're doing something silly, as I'm being obliged to do right now, such as dynamically adding and removing click handlers based on CSS attributes, fake HtmlTextWriter objects and third-party controls (over which I have no control), you're eventually going to run into the error above.

Your code might look, in a very simplified form, something like this:

var RunCrazyUnsafeScript = function(scriptToEval) {
    eval(scriptToEval);
}

... and you're probably invoking it something like this:

RunCrazyUnsafeScript("alert('Hello, world!');");

... and by and large, this all works perfectly well. Occasionally, however, you'll see the error above. The odds are that you're probably doing something like this:

RunCrazyUnsafeScript("alert('Hello, world!'); return false;");

This is perfectly legitimate in an event handler, and there are plenty of cases in which you actually want to return a value from evaluated code. I can't understand why the JavaScript implementation of eval() doesn't function more along the lines of perl, where eval() can be used to return all sorts of things, including - gasp! - the return value of the evaluated code. Wow.

Anyway... I'll come to the code snippet that you can copy and paste so that you can leave this blog and go back to your own code.

�

var ScriptHelpers = function() {
    var _this = this;    // don't trust "this" in JS unless you *really* know what you're doing

    // IMPORTANT: This function is NOT thread safe. If you want to use it in a
    // multi-threaded application, you need to make it so. Or, preferably, fix
    // the code that's forcing you do use this approach at all.
    _this.EvalWithReturnValue = function(scriptToEval) {
        returnValue = undefined;
        scriptToEval = expToEval.replace(" return ", " returnValue= ");    // euww.. global. icky, icky, icky.  -andrewh 25/11/08
        eval(scriptToEval);
        return returnValue;
    }
}

var scriptWotWeGotFromSomeBlokeInAPub = "alert('Hello, world!'); return false;";
var scriptReturnValue = ScriptHelpers.EvalWithReturnValue(scriptWotWeGotFromSomeBlokeInAPub);

If you haven't played with it yet, IE8's JS profiling is awesome. Happy, happy, joy, joy and all that.

Just don't look at the actual execution times below, or you'll cry (as I am :'( ).

I know, I know. Everyone's a gun coder, and nobody ever forgets to check the inputs to their public methods - in the same way as no coder ever makes a mistake, right? Which suggests that all bugs are deliberate...

Anyway, to the point. Below is a code analysis rule (don't ask me what a CA rule is; ask Google) to encourage developers to check all parameters to their public methods.

It's not the complete rule; you'll need your own BaseRule class and XML rule definition file, but if you're competent enough to write these rules in general then you're competent enough to find examples of those elsewhere.

internal class EnforceArgumentChecking : BaseRule
{
    #region Constructors

    public EnforceArgumentChecking()
        : base(typeof(EnforceArgumentChecking).Name) { }

    #endregion

    #region Public Properties

    public override Microsoft.FxCop.Sdk.TargetVisibilities TargetVisibility
    {
        get
        {
            return TargetVisibilities.All;
        }
    }

    #endregion

    #region Public Methods

    public override ProblemCollection Check(Member member)
    {
        ProblemCollection problems = new ProblemCollection();

        Method method = member as Method;
        if (ShouldCheck(method))
        {
            Dictionary<string, int> parameterExceptions = GetParameterExceptionCounts(method);

            // require that each parameter have at least one /Argument.*Exception/ associated with it
            foreach (string parameterName in GetParametersToCheck(method))
            {
                // if there's no count for this parameter name, or the count's less than one, we have a problem.
                if ((!parameterExceptions.ContainsKey(parameterName)) || ((parameterExceptions[parameterName] < 1)))
                {
                    Resolution resolution = GetNamedResolution("ArgumentNotChecked", parameterName, method.Name.ToString());
                    problems.Add(new Problem(resolution));
                }
            }
        }

        return problems;
    }

    #endregion

    #region Helper Methods

    /// <summary>
    /// Gets a list of the parameter names to check. This will return all parameter names except those
    /// that have a Zap.Attributes.SuspressParameterCheck entry for that individual parameter.
    /// </summary>
    /// <param name="method">The method whose parameter collection to scan.</param>
    private IEnumerable<string> GetParametersToCheck(Method method)
    {
        List<string> parametersToIgnore = new List<string>();

        foreach (AttributeNode attr in method.Attributes)
        {
            if (attr.Type.FullName.Equals("Zap.Attributes.SuppressParameterCheck"))
            {
                Expression paramName = attr.GetPositionalArgument(0);
                Expression justification = attr.GetPositionalArgument(1);

                if (!string.IsNullOrEmpty(justification.ToString()))
                {
                    parametersToIgnore.Add(paramName.ToString());
                }
            }
        }

        foreach (Parameter p in method.Parameters)
        {
            string paramName = p.Name.ToString();

            if (parametersToIgnore.Contains(paramName))
            {
                continue;
            }

            yield return paramName;
        }
    }

    /// <summary>
    /// Decides whether we should apply this rule to the given method.
    /// </summary>
    /// <param name="method">The method.</param>
    /// <returns>False if the method is null, non-public, an interface or abstract method, a public property setter; true otherwise.</returns>
    private static bool ShouldCheck(Method method)
    {
        if (method == null) { return false; }

        if (!method.IsPublic) { return false; }

        // this will catch methods that are defined as either abstract or interface methods
        if (method.IsAbstract) { return false; }

        if (method.IsAccessor) { return false; }

        // we don't check operators - they all generally call the AreEqual, Add, Append or other named methods anyway - and they're almost
        // always overloads.
        if (method.Name.ToString().StartsWith("op_", StringComparison.Ordinal)) { return false; }

        return true;
    }

    /// <summary>
    /// Looks for the creation of instances of /Argument.*Exception/ and counts them for each parameter on the method.
    /// </summary>
    /// <returns>A dictionary mapping the parameter name to the number of /Argument.*Exception/ thrown against that parameter.</returns>
    private static Dictionary<string, int> GetParameterExceptionCounts(Method method)
    {
        Dictionary<string, int> exceptionsThrownOnParameters = new Dictionary<string, int>();

        // count the exceptions thrown on each parameter.
        for (int i = 2; i < method.Instructions.Count; i++) // start from 2 because it's pretty much impossible to throw a useful exception before this.
        {
            Instruction instruction = method.Instructions[i];

            // are creating a new Argument*.Exception object?
            if (instruction.OpCode == OpCode.Newobj)
            {
                InstanceInitializer initializer = (InstanceInitializer)instruction.Value;
                if (Regex.IsMatch(initializer.FullName, "Argument.*Exception"))
                {
                    for (int paramIdx = 0; paramIdx < initializer.Parameters.Count; paramIdx++)
                    {
                        Parameter p = initializer.Parameters[paramIdx];
                        if (p.Name.ToString().Equals("paramName"))
                        {
                            int paramOffset = initializer.Parameters.Count - paramIdx;

                            Instruction loadStringInstruction = method.Instructions[i - paramOffset];
                            if (loadStringInstruction.OpCode == OpCode.Ldstr)
                            {
                                string parameterValue = loadStringInstruction.Value.ToString();

                                if (!exceptionsThrownOnParameters.ContainsKey(parameterValue))
                                {
                                    exceptionsThrownOnParameters[parameterValue] = 1;
                                }
                                else
                                {
                                    exceptionsThrownOnParameters[parameterValue]++;
                                }
                            }
                        }
                    }
                }
            }
        }

        return exceptionsThrownOnParameters;
    }

    #endregion

}

Hand in hand with this rule is a code attribute that allows the programmer to suppress warnings on individual method parameters, rather than just suppressing the entire rule for a particular method:

[AttributeUsage(AttributeTargets.Method, Inherited = false, AllowMultiple = true)]
public sealed class SuppressParameterCheck : Attribute
{
    private string _parameterName;
    private string _justification;

    public SuppressParameterCheck(string parameterName, string justification)
    {
        if ((string.IsNullOrEmpty(justification)) || (justification.Length < 10))
        {
            throw new ArgumentNullException("justification", "If you're going to suppress a parameter check, you MUST MUST MUST give a reason.");
        }

        _parameterName = parameterName;
        _justification = justification;
    }

    public string ParameterName
    {
        get { return _parameterName; }
    }

    public string Justification
    {
        get { return _justification; }
    }
}

And an example of how to use the SuppressParameterCheck attribute:

public void Insert(string key, object value)
{
    #region Argument Checking

    #region Argument Check for "key"

    if (string.IsNullOrEmpty(key))
    {
        throw new ArgumentNullException("key");
    }

    #endregion

    #region Argument Check for "value"

    if (value == null)
    {
        throw new ArgumentNullException("value");
    }
    #endregion

    #endregion

    // Accept the object, but don't cache it.
}

[SuppressParameterCheck("key", "This will be checked in a called method.")]
[SuppressParameterCheck("value", "This will be checked in a called method.")]
public void Insert(string key, object value, CacheExpireType expireType)
{
    Insert(key, value);    // Accept the object, but don't cache it.
}

Of course, it goes without saying that you're compiling with warnings == errors, right? :)

Todd's quote for the day:

"I tried to explain to him why these things were important, but then I gave up, and just said, 'You should probably go now.'"

Not the way you'd want your interview to end...

OK, the entire point of this blog post is to save some other poor sod from the pain that I've just been through.

If you have a Windows Mobile device and get synchronization error 0x8503001c, your life is close to over. Trust me.

You can delete and re-create the sync partnerships between your PC and your Windows Mobile device as many times as you want, with whatever permutations of synchronization settings you choose, but it's not likely to help. Try it anyway, but don't waste too much time on it.

What you're going to do, at some point after you've realized that it's all hopeless, is reset everything to factory defaults and start over.

The first tool you'll want is Dotfred's PIM Backup tool, available at http://www.dotfred.net/. Get it and back your device up (NOT to your device memory!).

Reset your device to factory defaults. On my Dopod you hold both of the multi-function buttons (the "-" buttons) while poking the reset button with your stylus. Press the Send button when it prompts you to confirm. Yours is probably different.

Re-create the sync relationship between your phone and your PC.

Re-sync everything.

Restore your backup.

Cry.

See? Now isn't everyone glad that we have check-in policies that search for words like this? :)

http://thedailywtf.com/Articles/We-Burned-the-Poop.aspx

Here's a particularly nasty gotcha that new .NET developers should be aware of. It should *go without saying, but nonetheless it appears that it *does need to be said. Hmph.

The sordid details are not included here to preserve the dignity of the guilty parties, but basically it boils down to: a property getter/setter is NOT the same as a public instance variable.

In other words, you are never guaranteed that the value you put in will be the value you get back. Consider the following:

this.Foo = "Hello, world!";
Debug.Assert(this.Foo.Equals("Hello, world!");

If I were evil (or just incompetent, as the developers of certain pieces of code I've had to deal with recently were), my definition of Foo could be as below:

private string _foo;
public string Foo
{
    get
    {
        return _foo;
    }
    set
    {
        Trace.WriteLine("The caller asked me to store '{0}', but I'm going to drop it on the floor instead. <snigger />".FormatWith(value));
    }
}

As I said, this is an elementary distinction (and a trivial example) but do not not not assume that just because you've asked a setter to store a value that you'll get the same value back from the getter. You should, but "should" is the most over-used word in this industry.

Microsoft's CRM tool offers some pretty powerful JavaScript event hooks. One thing it doesn't appear to offer, however, is a way to import a library of JS functions and re-use them across different event handlers.

For example, if one wanted to display a "Hello, world!" message whenever several different attributes were changed, the conventional approach would be to embed the call to alert() in each of the event handlers. Obviously, for such a simple example, this isn't such a big deal, but for more sophisticated logic it becomes unwieldy very, very rapidly.

One common approach is to use externally-referenced script files. Great, but imagine the horror when you suddenly discover that your system administrator has been religiously backing up your CRM server for the last six years, but hasn't backed up the web server from which you were serving your scripts... We still have the problem of how to reference them, too.

Variable declarations in JavaScript (evilly) default to global. What you can do to exploit this, however, is to declare a global function pointer from within an OnLoad event handler as follows:

// This is the OnLoad event handler provided by CRM
function OnLoad() {
    // This is the function that we want to make
    // available globally. Note the lack of a
    // "var" declaration.
    helloWorldFunction = function() {
        alert("Hello, world!");
    }
}

Then, in your event handler for other controls on the page, you can re-use that global variable:

// This is the OnChange event handler provided by CRM
function OnChange() {
    // ... and here's the one we prepared earlier.
    helloWorldFunction();
}

... and Bob's your father's creepy brother, you have code reuse with no external dependencies.

Writing Unit Tests

• Why do we write unit tests?

  • Improve code quality

  • Fewer reported defects

  • Make checking code faster

  • Tell us when we've broken something

  • Tell us when our work is done

  • Allow others to check our code

  • Encourage modular design

  • Keep behaviour constant during refactoring Functions as a spec (think TDD)

• The law of diminishing returns most definitely applies here

  • Testing everything is infeasible. Don't be unrealistic.

  • 70% code coverage is actually pretty decent for most classes.

  • First, test the common stuff.

  • Next, test the common exception-case stuff.

  • Then test the critical stuff.

  • Add other tests as appropriate.

• When to write a unit test

  • Use a unit test to provide a framework for writing your code

  • If you find yourself running up an entire application more than once or twice to test a particular

  • method you've written, wrap it in a unit test and use that test to invoke it directly

  • ^R ^T is your friend

  • When someone comes to you with a bug report, write a test to reproduce the bug.

Key Principles for Unit Tests

• Each and every test must be able to be run in isolation

  • Tests should the environment up for themselves and clean up afterwards

    • Use your ClassInitialize, ClassCleanup, TestInitialize and TestCleanup attributes

  • Tests should never rely on being executed in any particular order (that's part of the meaning of "unit")

  • Tests should not rely overmuch on their environment

    • Don't depend on files' being anywhere

    • Never, ever, ever hard-code a path. Find a better way.

    • For the Zap crowd: anyone who codes "C:\Projects" into a unit test (again!) is going to get a swift kicking. Politely, of course :)

  • If a class depends on another class that depends on another class that you can't easily instantiate in your unit test, this suggests that your classes need refactoring. Writing tests should be easy. If your classes make it hard, fix your classes first.

• Tests should be cheap to write

  • Don't worry about exception-handling - if an unexpected exception is thrown, the test fails. Don't bother catching it and manually asserting failure.

  • Be as explicit as you can

    • Don't allow for variations in your output unless you absolutely have to.

    • If there are going to be different outputs, ideally there should be different tests

• Tests should be numerous and cheap to maintain

  • Each test should test one (perhaps two or three, but generally just one) behaviour

  • It's much better to have lots of small tests that check individual functionality rather than fewer, complex tests that test many things.

  • When a test breaks, we want to know exactly where the problem is, not just that there's a problem somewhere in a call stack seven classes deep.

• Tests should be disposable

  • When the code it tests is gone, the test should be dropped on the floor.

  • If it's a simple, obvious test, it will be simple and obvious to identify when this should happen.

• Tests need not be efficient

Cool Stuff

• Private Accessors

  • These allow you to call private methods and access private variables from another class

  • This deliberately breaks OO principles

  • Use it for testing implementation-specific stuff, but depend on concrete types when you do.

• 

• ASPX page testing

  • You can automate all sorts of stuff with respect to ASPX pages

  • Button clicks

  • Form inputs

  • 

  • This does not replace regression test automation (e.g. Mercury et al), but should be used by individual developers when writing new ASPX pages and ASCX controls.

  • Don't run the application and click stuff manually

  • Write a unit test and tell it to click stuff automatically

• Testing web service methods

  • The unit test framework will get confused

  • Use either a wrapper (think Adapter or Façade pattern) and/or a Strategy-pattern.

• Using the unit testing framework for integration testing

  • Have a couple of common-case "unit" tests that actually represent an end-to-end use case of your application.

Note for young players: if you get an invalid cast exception such as...

Test method Test.Zap.CubeModel.DigitalSearchTreeTest.TestInsert threw exception: System.InvalidCastException: Unable to cast object of type 'Node`1[System.Char,System.Char]' to type 'Node`1[System.Char,System.Char]'..

...it may be that your type is a nested class or similar and does not have public visibility.

It's useful for me. Your mileage may vary. I wouldn't mind knowing if it's useful for anyone else, though :)

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>eventr</Title>
      <Shortcut>eventr</Shortcut>
      <Description>Code snippet for a WPF Routed Event</Description>
      <Author>Andrew Harcourt</Author>
      <SnippetTypes>
        <SnippetType>Expansion</SnippetType>
        <SnippetType>SurroundsWith</SnippetType>
      </SnippetTypes>
    </Header>
    <Snippet>
      <Declarations>
        <Literal>
          <ID>eventName</ID>
          <ToolTip>The name of the routed property (should *end* in ...Event).</ToolTip>
          <Default>Stupid</Default>
        </Literal>
        <Literal Editable="false">
          <ID>className</ID>
          <ToolTip>The type of the owning class.</ToolTip>
          <Function>ClassName()</Function>
          <Default>StupidClass</Default>
        </Literal>
      </Declarations>
      <Code Language="csharp">
        <![CDATA[#region $eventName$ Routed Event

        public static readonly RoutedEvent $eventName$Event = EventManager.RegisterRoutedEvent(
            "$eventName$",
            RoutingStrategy.Bubble,
            typeof(RoutedEventHandler),
            typeof($className$));

        public event RoutedEventHandler $eventName$
        {
            add { AddHandler($eventName$Event, value); }
            remove { RemoveHandler($eventName$Event, value); }
        }

        /// <summary>
        /// Invoke this method when you wish to raise a(n) $eventName$ event
        /// </summary>
        private void Raise$eventName$Event()
        {
            RoutedEventArgs newEventArgs = new RoutedEventArgs($className$.$eventName$Event);
            RaiseEvent(newEventArgs);
        }

        #endregion]]>
      </Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>

Here's a very (very!) quick WCF overview I prepared the other day for the team at Zap. It's intended as a soldier's five on the topic; no more and no less.

Service Contracts and Operation Contracts

This is what your WCF service promises faithfully to do for its callers.

Data Contracts

These are the data types that your WCF service expects its callers to understand. Thankfully, it will happily explain these data types to its callers.

Events (... or "Duplex Contracts")

Out of scope for this presentation, but see http://msdn.microsoft.com/en-us/library/ms731184.aspx for a pretty decent explanation.

Hosting Your WCF Service

Note the endpoint address:

Adding a service reference to your project

The metadata exchange address is the equivalent of the old Web Service Definition Language (WSDL) address.

Calling the WCF Service

Call it just as you would your local methods.

It's that easy.

Purely for edification, this is what some of the generated code looks like:

... or, "What's that SolutionInfo.cs thingy for?"

http://bloggingabout.net/blogs/jschreuder/archive/2006/11/02/Centralizing-AssemblyInfo-settings_2C00_-or-simplify-versioning-of-solutions.aspx

This error will occur for many reasons. If you've arrived at this blog, however, the odds are that you're searching for something .NET-related, possibly even a provider-related issue.

A .NET provider specified in a web.config file has its status set to enabled=false by default. Don't ask me why.

This problem, when using a custom role provider, might manifest as the above error. Very frustrating, as none of the Google results I've seen will mention this particular cause of this error, anything about how to actually fix it.

Yes, you can actually use the DBML editor to generate classes tagged with the WCF DataContract attribute.

.NET 3.5 rocks.

http://blogs.msdn.com/wriju/archive/2007/11/27/linq-to-sql-enabling-dbml-file-for-wcf.aspx

The problem:

When using WPF OnContextMenuOpening, ContextMenu doesn't display on first load.

The reason:

The OnContextMenuOpening routed event is used for dynamically creating a ContextMenu object for a particular UIElement.

Each UIElement has a ContextMenu property which dictates what gets displayed when a user right-clicks on it. If the property is null, nothing will be displayed. If the property is not null, the context menu that it references will be displayed.

The catch? The ContextMenu property must not be null before the event handler first fires, or the menu won't load. This appears to be a WPF bug, but it's a pain either way.

The solution:

Create an empty ContextMenu object and assign it to each UIElement that's going to have any context menu displayed. In the OnContextMenuOpening event, either Clear() the existing context menu or just create a new one and assign the property to the object reference. Either will work.

Disclaimer: This is an OLD, OLD blog post.

I shudder to think how much this PERL code looks like it was written by a C programmer...

If you still find it useful, great. If you'd like to mess with the code, great too. If you're really annoyed with fetchmail and it doesn't already have this feature built in, why not change the fetchmail code yourself and submit it to the maintainers? :)

Why don't I? Because I wanted to learn PERL...

I recently had some trouble with fetchmail and multidrop mailboxes. fetchmail handles mail well when a local address is found in the To: field of an email, but badly when it has to extract address information from the other headers of an email. In particular, people on the BCC list of an email (and who never appear in "official" mail headers) are likely to never receive emails addressed to them when handled via fetchmail with a multidrop mailbox.

I was also looking for an excuse to learn PERL (08/2004 update: wow, this page really is old...).

qmail has a nice solution where it inserts an Delivered-To: line into the mail headers. For virtual hosts, it prepends the domain name to the email account it was delivered to. My domain is uglybugger.org, so when the MX host for mail.uglybugger.org accepts mail for me, it dumps it into a single account. The headers it inserts look like this:

Return-Path: Andrew.Harcourt@team.telstra.com
Delivered-To: uglybugger.org%uglybugger@uglybugger.org
Received: (cpmta 5066 invoked from network); 2 Apr 2001 21:59:52 -0700
Delivered-To: uglybugger.org%andrewh@uglybugger.org
Received: (cpmta 5062 invoked from network); 2 Apr 2001 21:59:51 -0700

Read this from the bottom up. You'll see that the first Delivered-To: line reads uglybugger.org%andrewh@uglybugger.org and the second Delivered-To: line reads uglybugger.org%uglybugger@uglybugger.org.

fetchmail can be configured to read envelope addresses. These are the addresses (such as the Delivered-To: line) that mail servers include in mail headers to record which account the mail was delivered to. This is an important distinction from which address the mail was intended for. You can tell fetchmail to use these headers by specifying the following in your .fetchmailrc file:

envelope "Delivered-To:"
qvirtual "uglybugger.org%"

Obviously, please change the qvirtual line to read your domain :)

The problem here is that fetchmail will only read headers top-down, and it matches the first one it finds. This breaks the envelope/qvirtual delivery process completely as fetchmail is unable to ignore the first line it receives. So if the envelope/qvirtual settings do not solve your problem, read on.

What we need to do is specify an alternate delivery agent, so that we can handle our processing ourselves. You can do this by specifying an external Mail Delivery Agent for fetchmail. Use the mda keyword to point mail to a script that you can copy and paste from here:

----- /usr/sbin/fetchmail-inject ----------
#!/usr/bin/perl
# fetchmail-inject
# Andrew Harcourt, 1 May, 2001
#
# this script removes a nasty header that fetchmail can't handle
# from incoming mail and then passes the mail to sendmail to
# deliver locally

# write the mail to a temp file on disk
# as we do, parse it for the address
# lines
local($outputName, $fromAddress, $toAddress, $cmd);

$outputName = "/tmp/message.".$$;
open(OUTFILE,"> ".$outputName)
        || die "could not open $outputName!";

while (&ltSTDIN&gt) {
        if (/^Delivered-To: uglybugger\.org\%uglybugger\@uglybugger\.org/) {
                # just ignore this line - it's ugly
        }
        elsif (/^Delivered-To: uglybugger\.org\%(.*)\@uglybugger.org/) {
                $toAddress = $1."\@uglybugger.org";
        }
        elsif (/^From: .* /) {
                $fromAddress = $1;
        }
        elsif (/^From: /) {
                $fromAddress = $1;
        }
        elsif (/^From: .*/) {
                $fromAddress = $1
        }
        print OUTFILE $_;
}

close(OUTFILE);

# check that we have our addresses correct
if ($toAddress eq "") {
        $toAddress = "postmaster\@uglybugger.org";
}
if ($fromAddress eq "") {
        $fromAddress = "postmaster\@uglybugger.org";
}

# now call sendmail to deliver the message
$cmd = "/usr/sbin/sendmail -f $fromAddress $toAddress < $outputName";
system($cmd);
-------------------------------------------

Good luck :)