When you’re bootstrapping a business, you typically can’t afford to buy all the software you’re familiar with from your corporate or VC-funded past. It’s hard to go cold turkey on the tool set that’s become second nature. You could see this as another hurdle that’s keeping you from starting your own ISV, or see it as an opportunity to find better tools for less money. Here at GojiSoft when we first started we spent a fair bit of time looking around for good yet affordable tools to run a Windows and .NET based software development shop.
Continue reading 'Software infrastructure for an ISV on a shoestring budget'»
When you’re developing with Visual Studio, it calls MSBuild and the C# compiler, to compile your solution, both of which come with the .NET framework. On your build machine, you don’t need a copy of Visual Studio, you can get by with invoking MSBuild against your solution file. This keeps your build setup cleaner and cheaper. It does mean you don’t get access to features like the Code Analysis feature of Visual Studio 2010 on your build box, unless you hack it. If you have Code Analysis enabled on your dev box, but not installed on your build box, this setup, combined with Post-Sharp 2 will cause problems.
Continue reading 'Fixing PostSharp and Code Analysis on a build machine without Visual Studio'»
Now that Visual Studio 2010 has been released, everyone who wants to upgrade gets to go jump through a bunch of fiddly hoops to get the build system to play nice again. Here are the fixes I had to apply to our build system.
Continue reading 'Getting .Net 4.0, Team City, MSBuild and Nunit to play nice.'»
I was writing some tests that needed to assert that a logging aspect I wrote for Post-Sharp, was correctly using log4net to output to the console. Capturing the console output in C# is easily done through Console.SetOut. But, if you want write to the standard output stream again or keep things tidy and controlled, the original console stream needs to be restored. Very quickly, the calling code becomes a bracket fest of saving the original state and try-finally statements to restore that state robustly.
Continue reading 'Capturing and restoring console output in C#'»
Code coverage is a good tool to provide insight and some evidence towards quantifying the quality of your test suite. The basic idea is that of a profiling tool. You execute your code, typically through your (unit) test suite, the tool picks up which lines and expressions get hit during execution and from that it works out what code is and isn’t being exercised by your tests. This works fairly well in practice, and is a great way to quickly get insight into the major gaps of a test suite, or to find bits of dead code that should be removed. I once inherited a code base which at first glance looked fairly well unit tested, but after running a coverage tool, it barely hit 50%. It was a great help to quickly start beefing up the test suite, without having to go through the entire existing suite. Unsurprisingly, bugs started cropping up pretty quickly in all the gaps the coverage tool spotted.
Unfortunately, code coverage is not a panacea. High levels code coverage means different things to different tools and even 100% coverage with the current tool still allows for some significant issues to go unnoticed. That is because the metrics they support are more limited than you might think at first glance.
Continue reading 'Code coverage for .NET compared'»
For the last eight or so years I’ve been struggling with RSI (Repetitive Strain Injury), probably the result of living behind a computer for the last 25 years. RSI, for those unfamiliar, is an overuse injury that causes pain in the body part that’s being overused. It can lead to weakness or numbness and progress to nerve damage. For programmers that often means pain in your hand or wrist all the way up to the neck and shoulder. It can get so bad, you will start thinking about hands-free careers.
Fortunately, it can be managed so your work and life doesn’t need to suffer. Since it’s an overuse injury, the obvious thing to do is to stop doing it. As a coder, that’s not really an option. The best compromise so far that I’ve found is break-timer software, in combination with an ergonomic desk setup.
Continue reading 'Workrave: A free alternative to Workpace software'»
Comments (2) 
