Rob Herbst

I had previously blogged about finding some good tutorials on how to get started. I’ve been using the WinDBG debugger a little bit more lately and I’ve put together a “cheat sheet” that I use for the most common commands and I thought I would share them. Almost all of these commands are specific to the SOS extension to debug .NET code.

If you are a seasoned WinDBG user, you’ll know all of these command by heart, but if you are just getting started this might help. The first thing to do is run, don’t walk to setup your “Symbol Search Path” setting. Enter CTRL+S from inside WinDBG, mine looks like this:

SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

You can find out more about it in this Microsoft support article.

The WinDBG command line has TAB completion, so when you type the first few characters of a command, hit TAB to cycle through the possible completions.

I have picked up the majority of these tips by reading some of the great blogs on MSDN. If you are interested in learning a lot more about WinDBG and how to debug some very difficult problems you need to subscribe to Tess’s blog right away!

If you know of any other tips or helpful WinDBG command, please post them in the comments and I’ll add them to the list.

While discussing some code with a colleague, I ran across an unexpected behavior of GC.SuppressFinalize. I’ve put together a small sample for our discussion.

using System;
using System.Collections.Generic;
using System.Text;

namespace ConsoleApplication1
{
    public class Base
    {
        ~Base()
        {
            Console.WriteLine(“Base Finalizer called”);
        }
    }

    public class Derived : Base
    {
        ~Derived()
        {
            Console.WriteLine(“Derived Finalizer called”);
        }

        public void Suppress()
        {
            GC.SuppressFinalize(this);
        }

    }

    class Program
    {
        static void Main(string[] args)
        {
            Derived d = new Derived();
            d.Suppress();

            Console.ReadLine();
        }
    }
}

Okay, so what gets printed out at the console?

Actually, nothing.

It was a little surprising to me at first, especially since after years of C++ programming the ~ immediately invokes destructor semantics in my head. I worked through a number of different variations, but I always got the same result. I used the !FinalizeQueue command available in the SOS extension of WinDBG to verify that there was only the Derived class reference on the queue. So when you say, SuppressFinalize(this) you really mean it! 

Now, granted, this is a cheesy example. But the discussion came up when talking about the correct way to implement IDisposable. In the example provided, SuppressFinalize(this) is called in the Dispose method. Now that’s a good thing, because you want to prevent the call to the finalizer since you have already cleaned up any resources via your Dispose implementation. But, what happens if a class you derived from, either your own or a third party, does not implement IDisposable and instead is relying on the finalizer? Or they do implement IDisposable but somewhere else along the virtual method override chain someone forgot to call the base class implementation.

This really never should be a problem if your code implements the IDisposable interface correctly. And since implementing a Finalizer on your class has a negative performance impact you should only use them when you really need to. Anyway, this makes a great conversation at any nerd party

Being the keyboard kind of guy that I am, I’ve totally gotten back into the Vim editor. I had used it years ago, and discovered it again recently when I was looking for a text editor for some Ruby code I was writing.

It’s one of those power tools that most people, myself included, really didn’t like very much the first time you use it. But then you achieve a certain level of proficiency and you can slice and dice any text you have to edit so quickly that you become very spoiled.

I also have switched to using a black background. I found a great dark color scheme for Vim called Moria, that I would highly recommend. It’s a very readable, easy on the eyes scheme, that just seems right to me. I’ve posted an image of my setup using the abbrev.rb file from Ruby 1.8.5.

If you like using keyboard shortcuts, you owe it to yourself to try the Vim text editor. It does take some time to get used to a modal editor, but if you are going to be editing lots of text, it’s time well spent.

I still really like the text editor built into Visual Studio and will continue to post any tips and keyboard shortcuts that I find useful there too.

Here’s my addition to the lists started on the Retrospector blog and commented on by Michael Affronti and Steve Clayton:

Geeks like to be challenged with really interesting problems.

Most geeks, myself included, want to be challenged with really interesting problems to solve. The kind of problems that are only limited by your own creativity and determination to come up with the most simple, elegant and effective solution.

Do you have any more you would add to the list?

There’s a great feature hidden in the Find Window Combo Box that is part of the standard Toolbar in Visual Studio.

1. Open Visual Studio
2. CTRL + N (Create a new file) choose “HTML Page”
3. Position the cursor on the tag
4. Press CTRL + /
5. The focus should have shifted to the Find Combo Box
6. Type >
7. Now type E
8. Cool! It’s a command line with built in Intellisense.
9. Type dit.LineT
10. The entry for Edit.LineTranspose should be selected
11. Press enter

You’ll notice that the and tags are now transposed. Take a few minutes to look around at what commands are available in this list. You can browse the list by entering one letter at a time. For example “>a” to see all the items that begin with a.
This is a great way to quickly execute commands that aren’t mapped to convenient keyboard shortcuts.

If you are interested in creating better software, you should subscribe to the “Creating Passionate Users” Blog right away!

I have found almost every post to be thought provoking and very insightful.

Read this post Are your users stuck in “P” mode, then come back. I’ll wait right here.

Ok great, your back!

As a developer myself, I know that finding the right size of both the green and purple circles requires a lot of hard work. (You did read the article…right?)

There is a great deal of complexity and context that any developer has to keep in their head in order to write code effectively. It’s hard for a developer to step back sometimes and see the bigger picture. Yes, we as developers might think a feature is very cool, but is the user really going to care?

It is much easier for a developer to provide a bunch of options on what the user could do and let them figure it out, instead of focusing on the much harder problem of what the user is really interested in doing, and how can we streamline that as much as possible.

In order to get that kind of feedback, you really need to do usability testing. Watch users trying to use your application, and see what they are having trouble with. Refine and simplify your user interfaces until they feel natural, and don’t require you to review the online help.

I also think once users figure out a way to do things — even if it’s very time consuming, they sometimes don’t take a step back and explore the other features offered in a program that might make their task easier.

We as developers need to make this an easier and less scary thing for the users to do. And users, some of us developers have really been trying, have some of our approaches been that great, no not really, but the thought is there.

The one area currently that I see that seems to find a good balance is the use of screencasts. This gives the users a very low stress way of having new features demonstrated to them. It’s just watching a movie, there’s no way that could do anything bad to the users data. I think a well produced screencast demo, with an underlying voice track that guides the users through the process should be used for each critical feature in an application.

I have seen some progress being made in the new generation of web and desktop applications, but we as developers still need to do more.

I think this post on the 37signals blog really makes a good comparison between the importance of rewriting text and software until you get it right.

What’s really important is to start getting the ideas out of your head, and then working on them relentlessly until you can’t remove anything else, each idea is expressed as concisely as possible.

It made me think about Martin Fowler’s great book Refactoring: Improving the Design of Existing Code. This book gives you a clear guide on how to identify “code smells” and how to use refactoring to fix them. If you haven’t already read it, I would highly recommend it.