Design Patterns - tried-and-true solutions to common problems - have now been around long enough that many of them have very familiar names. We can use those names as part of an object-naming strategy.
This is the fourth in a series of blogs looking at things NDepend told me about a personal project of mine - this time mutually-dependent namespaces.
This is the third in a series of blogs looking at things NDepend told me about a personal project of mine - this time a curious problem with Exception naming.
NCrunch is a Visual Studio add-in which runs your tests while you work so you know if you've broken anything, as well as providing coverage indicators in the IDE and coverage metrics on demand. It recently went commercial, and time is running out for the free version I've been using for the last couple of months. From my experiences using NCrunch I'm going to let it expire, and go about my business without it. Here's why.
I had some really great responses to my last post regarding some bad code I've shown to interviewees - pretty much everything I intended to be bad was spotted, as well as some interesting points I hadn't considered. Here's the code again along with the bad bits as I saw them, and then I'll go over the extra points raised in the comments.
This is the second in a series of blogs about things NDepend told me about a personal project of mine. This time, methods which are apparently never called.
Yesterday I did my first grok talk - it was on Unity Interception at Dot Net Dev Net in Bristol, UK. It went ok! The feedback was that the content was very good but the presentation could have been a bit better, which is very possibly the story of my programming life :) For posterity, I've put the content on Github.
The other day I got an email from Patrick Smacchia, generously offering me an NDepend licence on the grounds that if I find it useful I can write about it on my blog. NDepend allows you to write Linq queries against an assembly or a code base to interrogate it for quality issues and see various metrics and reports. I have a personal project underway which I've been working on for some time, so I figured I'd give it a go and see what it can tell me. This is the first of the results.
I've recently been working with a number of VB6 systems which use C# .NET components via COM, and wanted to keep the same sort of organisational structures and patterns in the C# part of the application as I would if it was a standard MVC app or WCF service - namely, using Dependency Injection to plug the various C# classes together. This is easier said than done with COM, but here's an approach I've used to achieve it.
I recently reused my generic, disposable WCF service client, and made some changes to make it simpler to use and easier to unit test. Here's what I did.