• Copy the angle brackets and thread number to clipboard. E.g. “[12]”
• Menu -> TextFX Viz -> Hide Lines without (Clipboard) text
• Press Ctrl-A (Select all text)
• Menu -> TextFX Viz -> Delete Invisible Selection
• Press Ctrl-A (Select all text)
• Menu -> TextFX Edit -> Delete Blank Lines
• That’s it! You are now viewing one logging from only one Thread

This works very quickly even with 70,000+ line 10MByte log files. IMO it avoids the need for xml log4net logging and Chainsaw (or similar).Simpler is always better.

Demo: Two threads counting to 100:

Copy the angle brackets and thread number to clipboard. E.g. “[12]”

Menu -> TextFX Viz -> Hide Lines without (Clipboard) text

Press Ctrl-A (Select all text)

Menu -> TextFX Viz -> Delete Invisible Selection

Press Ctrl-A (Select all text)

Menu -> TextFX Edit -> Delete Blank Lines

That’s it! You are now viewing one logging from only one Thread

c:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(2015, 9): error MSB3091: Task failed because “sgen.exe” was not found, or the correct Microsoft Windows SDK is not installed. The task is looking for “sgen.exe” in the “bin” subdirectory beneath the location specified in the InstallationFolder value of the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A. You may be able to solve the problem by doing one of the following: 1) Install the Microsoft Windows SDK for Windows Server 2008 and .NET Framework 3.5. 2) Install Visual Studio 2008. 3) Manually set the above registry key to the correct location. 4) Pass the correct location into the “ToolPath” parameter of the task.

The first thing I did was use msbuild from the command line; sure enough Debug Builds were fine and Release Builds had the same error. This ruled out Team City. Obviously installing VS2008 on our build box would solve the issue, but I assumed the build tools must available elsewhere without need all of VS2008. They are:

The solution is: Download the Windows SDK and install .Net Development Tools (it says 2008 Server but I did this on XP SP3):
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e6e1c3df-a74f-4207-8586-711ebe331cdc

. Zero Defects can be the norm
Given a serious amount of control on projects I insist on ~100% coverage for the most complex pieces. Every time this happened the complex code was delivered with zero (or very close) defects. Admittedly before NUnit I received a lot of praise of stable code and attention to detail, but with with NUnit we can even redesign working code to be more maintainable and still release with almost 100% stable code. Redesigning for maintainability is not practical without a suite of automated tests – it normally requires a complete rewrite.

. 100% Coverage is for Fools
Sometimes creating Automated Tests make prefect sense, and sometime it costs more time than it saves. I aim for 100% coverage on reusable libraries, critical architecture and anytime I think the business rules are far too complex for QA to completely understand let alone regression test on a regular basis. 100% Coverage on simple data manipulation web page will be a frustrating waste of your time.

. TDD – Good luck with that!
Unless your company has several years experience writing Automated Tests you will not get buy in for TDD. Learn to walk before you try to run.

. Continuous Integration is an easier win
I can install a Cruise Control in a day and educate all devs in one 30 minute presentation. Before looking at Automated Developer Tests I highly recommend rolling Continuous Integration our first. It is a massive win for very little effort. Managers and developers alike always see the value, this should build up your credibility enough to start an NUnit pilot.

. Screw Mocks, use a real database, ldap etc
Yes Mocks can work, but in my experience I have seen developers waste time coding Mocks, Object Mothers etc. A far simpler approach is to commit to a reasonably large amount of upfront effort so the Automated Tests setup and tear down a real environment. This framework should be created one expert developer and will result in some complex, hard to maintain code, but it then becomes very simple for even junior developers to test large sections of their code, not just wimpy Unit Tests. This is the foremost reason I have had so much success with NUnit. I have my own framework for SQL Server/ Oracle which took about three re-writes to become as simple and stable as it is today – you will need great database skills and good C# but once written it just works. Via Cruise Control we automatically spot problems in build scripts instantly, if anyone changes sproc parameters without updating the DAL we spot that too! I even have a suite of test on one project that does an end-to-end publish mimicking data coming from several internal feeds, being data scrubbed by our system, transformed into records in our system and push out the other end to table ready for user consumption! Probably 100klocs of C# and PL/SQL are executed by a single test – if anything breaks we know about it very quickly.

. Hundreds of small tests or a few Large Tests?
A classic mistake I see is developers taking the Unit word too literally and set about writing literally hundreds of test for one module. Although sound in theory, it is madness in practice. These developers run out of time and generally I see a stack of pretty useless tests. You should aim for the most coverage you can per test, of course when such tests break it is not immediately obvious what broke but you will be aletred that something broke, and Cruise Control will show you what code changed since the last build – making it an easy fix almost every time. So do you want to spend weeks writing hundreds of tiny tests or a few days writing all-encompassing tests? In reality no team I have worked on has every has been permitted the time to write hundreds of test. Also most developers don’t have that kind of patience which is why TDD has a low adoption rate. To clarify this point in general go black box rather than white box – not I said in general, use your common sense here

. NUnit can really stress developers out
This is a serious problem when developers are under the gun to meet deadlines and an NUnit test breaks the Cruise Control build. Of course everyone knows all work should stop until the build is fixed, but 90% of developers will just mark the test with [Ignore] and work on what their manager is shouting for.

. Some Managers think that is what (cheaper) QA staff is for
No explanation is needed I am sure. Some managers get the SDLC and some do not, and I can offer no solution to this problem. Some managers can only focus on very short-terms goals.

Can anyone tell me why one would NOT always deploy pbd (debug symbols) files with your code other than IP issues? “Because we hate all developers and it makes Management’s day watching them debug blind” is not a valid answer.

Coupled with log4net deploying pdbs really helped me stabilize a nightmare headless process on my last assignment. What is log4net I hear many ask? Attend the first fifteen minutes of my Atlanta Code Camp presentation or read a post or two like this:

http://blogs.acceleration.net/ryan/archive/2004/11/10/380.aspx

Do I hear a few voices at the back are saying they love EIF and the MS Application Block? If you are using them already then probably stick with them as they do work, if not scan these posts and make an educated decision:

http://weblogs.asp.net/cazzu/archive/2004/05/17/133196.aspx

http://www.cauldwell.net/patrick/blog/CommentView,guid,13345.aspx

http://dotnetjunkies.com/WebLog/kenbrubaker/archive/2004/10/04/27581.aspx

There are many more posts debating EIF and log4net:

http://www.google.com/search?hl=en&lr=&q=log4net+eif

Prior to the main event Burr Sutter (who I already knew) led a great discussion with the audience on a raft of subjects. Our .Net groups are missing someone with his panache to work the crowd; he is at least a DCC level speaker.

A fundamental subject of the book is Why Do Many Java Project Fail? As a former Java developer I agreed with many of the assertions including:

. Complexity – Java people love buzzwords and apply any they know anywhere!

. Taking things too far – e.g. Layering everything

. EJB misuse – Been there personally!

. Peer Pressure to write ‘smart’ code

It was also interesting to see just how fragmented the Java tools/ platform extensions market has become since I booted the JVM out of my career (March 2001). The number of commercial-quality Open Source tools available is amazing. In fact commercial companies are now viewing projects like Hibernate as serious competition. In my view this fragmentation lowers each tool’s user base and hence their quality. Why is the CLR, .Net Framework and VS.Net so stable? Because a massive number of sales means Microsoft can afford serious development and gargantuan testing efforts. Java EJB Servers cost around $100K and are apparently as stable Scott McNealy’s career. Without the effort of a Microsoft style Product Development Lifecycle you just cannot create Microsoft quality products. I would love to yatter on about the evening but no one reads long blog entries, so watch this space for news from future Java meetings.

Recently, while on a group cycle ride a fellow rider’s lack of experience/ judgment in jumping a road hazard led to reasonably serious injuries on my part. Was it my fault? Well, he lost control while jumping falling on my bike and taking it down. Still I partially blame myself; I had never seen this guy cycle before, and just assumed he knew how to hop a bike over obstacles. In future when such an obstacle arises, I’ll be very alert for problems and maintain a good distance from unknown cyclists when potential danger arises.

We can do the same in programming. The recent Fail-Fast post highlights one such technique. In Code Complete 2 Steve McConnell collectively groups such techniques as Defensive Programming. This chapter should be read by anyone who writes code for a living. He correctly points out that a fail-fast technique is not always the correct action. Over the last eleven years I have exclusively written serious business applications that often work with financial data. In these cases if an error occurs we would rather fail in a hard manner than have the code work in an inconsistent state:

“A dead program normally does a lot less damage than a crippled one”

But, what if you are writing a video game, or the error happens in simply rendering data to the screen. In such cases a graceful recovery option may be better. Would you rather have Windows crash, or show a desktop icon using the wrong colors?

The chapter is too long to do justice in a blog post. It covers sub-topics including Assertions, Barricades, Graceful Recovery options, Robustness v’s Correctness and Exceptions. At the bare minimum skim-read all the sections (although the Exception section is pretty weak IMHO).

Certainly one project I participated on in 1997 suffered politically because it was the GUI to a lousy messaging system, which feed the GUI with bad data. My manager’s defense was ‘Garbage In, Garbage Out’, and it fell on death ears. With the hindsight of Steve McConnell’s wisdom, if we had Barricaded our code from bad data then fighting politics would have been much easier. The manager could have attended meetings with
the log from the Barricade Layer, proving in black and white where the problems lay. Both teams would then have been able to solve the problems much quicker, without escalating it up the management chain.

Luckily the fix is trivial. Open up machine.config (beg, grovel, kiss the feet of your sys-admin if necessary) and make this change:

Original machine.config entry:

<machineKey validationKey=”AutoGenerate,IsolateApps” decryptionKey=”AutoGenerate” validation=”SHA1″/>

To enable sharing of cookie authentication:

<machineKey validationKey=”AutoGenerate” decryptionKey=”AutoGenerate” validation=”SHA1″/>

>>Totally trivial change that took under five minutes of searching documentation but I bet many organizations are struggling with separate logins even today. All the more reason to hire a Microsoft Certified .Net consultant [shameless plug!].

if (this.dataGrid.EditItemIndex > -1)
{
// Update the DataGrid
this.dataGrid_UpdateCommand(
this.dataGrid,
new DataGridCommandEventArgs(
this.dataGrid.Items[this.dataGrid.EditItemIndex],
this.dataGrid,
new System.Web.UI.WebControls.CommandEventArgs(“Update”, “”)));
}

Not a pretty event call but it works. On my last ASP.Net project several pages used one Update Button to perform updates on three or more DataGrids simultaneously. If your code forces users to click several update buttons, then use of this code may just make them a little happier.

The key concept is to fail early, that is as soon as you can programmatically detect bad data exists throw an exception reporting useful contextual information.

e.g.
using System.Reflection;
…..
DataRow drWorkingData = someoneElseClass.FindTheRow(iPrimaryKey);
if (drWorkingData == null)
throw new ApplicationException(
“Failed to find data for Primary Key >” + iPrimaryKey + “<” +
“[" + MethodInfo.GetCurrentMethod().DeclaringType.FullName +
"." + MethodInfo.GetCurrentMethod().Name + "()]“);

In this example had we not used a Fail-Fast policy the code would have continued until drWorkingData was referenced, at which point the run-time would automatically throw a null object exception. If you have debugged much code in your life, you will realize that this error could be thrown quite a distance from the original source of the error.

Note the use of reflection to obtain the location of the error. This is my most prevalent cut-and-paste reuse. An obvious improvement would be to encapsulate it in a utility class, and walk a step up the call-stack to report the method’s class and name. That is beyond my knowledge of .Net Reflection.

Also note that instead of using ApplicationException I always use a custom Exception called FailFastException which makes it very easy to trap such errors in a central location and report/ log them in a consistent fashion.