Friday, December 29, 2006

Good article on achieving a zero-bug count

[This was originally posted at]

James Shore wrote a great article on achieving zero-bug count. It's part of his up-coming book.

Some of the things I really like are how he emphasizes that bugs are not "okay" or "necessary", but rather that the team should take active steps not to just prevent bugs, but to prevent the cause of bugs. For example, being required to explain why a bug occurred, such as adding a textbox to your bug-tracking system that requires the developer to explain what caused the bug.

The problem with bugs is that they take 10x longer to fix than create. So if you can improve your process to reduce bugs (which takes more time upfront), you can then go into an "upward spiral", where things keep getting better and better.

It's a thoughtful article.

Monday, December 18, 2006

Different Types of Comments

[This was originally posted at]

Programming enterprise apps and their supporting processes, I've used at several languages. Most of them have different ways to make comments.

Characters Languages Multi-line vs. Single-line Characters
// C#, JavaScript Single 2
/*  */ C#, SQL, CSS Multi 2,2
' VB Single 1
REM DOS Single 3
XML, HTML Multi 4, 3
<%-- --%> ASP.Net Multi 4, 4
-- SQL (single line) Single 2

I didn't have any big dialogue on this, I just found it interesting - 7 different ways to comment code for a set of languages that are often used together for a common goal. I'm sure that someone with a strong Compiler background could explain the significance of multi-line comments vs. single-line comments, and number of characters involved to create the comment identifier.

Sunday, December 17, 2006

ASP.NET AJAX Control Toolkit - making it simple

[This was originally posted at]

Looking at the newly available ASP.NET AJAX Control Toolkit, there are several things I really like about it.

  • It has a quickstart with a sample page for each control.
  • It takes less than 5 minutes to download and get running.
  • The controls are mostly cross-browser compatible.
  • It's free.
  • It's open-source.
  • It's practical - i.e. the controls are based on useful needs, not just flashy toys.

I especially like the ModalPopup and PopupControl. The first presents just that - a modal popup (which nicely fades out the screen). The second provides a dropdown-type control which is great for X-Pickers (Date-Pickers, Employee-Pickers, Color-Pickers, etc...)

Even if you're in an older shop that already developed a lot of your own controls, it's still worth investigating because these are (1) standardized, (2) likely to continually improve with the support of an entire community, and (3) potentially better and more robust than a control that a single dev whipped up a year ago under schedule pressure.

What I notice is that these controls abstract a lot of complicated DHTML features, like drag & drop, multi-layering, and DOM-modification, all while being cross-browser compliant. In a way, it's reduced advanced DHTML to mere copying and pasting.

Tuesday, December 5, 2006

Types: is operator, GetType method, and typeof keyword

[This was originally posted at]

A common .Net question if "how do I determine if object x is of type y? For example, you may only want to perform certain operations on certain objects. Sometimes this can be solved by having that object implement an interface. But, there are other times you'll just need this ability. .Net provides easy ways to do this. Consider the code snippet below (notice that this is actually an MSTest unit test, but it's very easy to demonstrate quick code snippets because you can directly step into the code.

We notice a couple things:

  • is operator - shows if object x is of type y. If this condition is true, then you can cast the instance to the given type. This accounts for inheritance. For example, all types (such as System.Int32) inherit from System.Object.
  • GetType() method - a method on System.Object (and therefore available to all types) that returns the Type of the object. The Type class has a "FullName" property which returns a string of the name. Notice that you can tell the name of immediate type here, but it doesn't inheritance. For example, for an object on type "System.Int32"  the "is" keyword accounts for the current type (int) and the base type (object). GetType requires an instance and returns a type.
  • typeof keyword - Takes a Class an returns a Type (almost the inverse of typeof).

    public void Type_Int32()
      int i = 5;

      //Show 'is' operator
      Assert.IsTrue(i is int);
      Assert.IsTrue(i is object);
      Assert.IsFalse(i is double);

      //Show GetType and typeof
      Assert.IsTrue(i.GetType().FullName == "System.Int32");
      Assert.IsTrue(i.GetType() == typeof(System.Int32));

      //Declare Type instance
      Type t1 = null, t2 = null;
      t1 = i.GetType();
      t2 = typeof(System.Int32);

      Assert.IsTrue(t1 == t2);


Notice that this same pattern can be applied to both value types (like a System.Int32) and reference types (like an XmlDocument):

    public void Type_XmlDocument()
      XmlDocument x = new XmlDocument();

      //Show 'is' operator
      Assert.IsTrue(x is XmlDocument);
      Assert.IsTrue(x is XmlNode);
      Assert.IsTrue(x is object);
      Assert.IsFalse(x is double);

      //Show GetType and typeof
      Assert.IsTrue(x.GetType().FullName == "System.Xml.XmlDocument");
      Assert.IsTrue(x.GetType() == typeof(System.Xml.XmlDocument));

      //Declare Type instance
      Type t1 = null, t2 = null;
      t1 = x.GetType();
      t2 = typeof(System.Xml.XmlDocument);

      Assert.IsTrue(t1 == t2);


By using the is operator, GetType method, and typeof keyword, you can effectively manage type information and solve several problems in various ways.

Monday, December 4, 2006

Essential .Net Chapter 3: Type Basics

[This was originally posted at]


Chapter 3 of Don Box's book Essential .Net: the CLR explains the basic of types. While this is a common topic. Don has a clear way of explaining things. He does a good job of explaining the concepts of types in a way that transcends individual language syntax. This chapter connects a lot of dots, and makes a lot of sense once you've already been using an OOP language like C#. While most of this I've already seen before in other C# books, Don has a good way of explaining it:

Types - "A CLR type if a named, reusable abstraction." (pg 49) - I constantly have junior devs asking "What is a type?" I've heard several answers, like "A type (or form, or kind) of data", but I think Don's phrasing helps clarify the intent.

Sealed vs. Abstract - He explains how the class modifiers sealed (cannot be inherited) and abstract (must be inherited) are really opposites.

Const vs. Readonly - He discusses the difference between the const (made constant at compile time) and readonly (set in the type initializer at runtime, and then no longer editable). For example, consider this code snippet:

  class TypeDemo
    public TypeDemo()
      c2 = 456;
      c2 = DateTime.Now.Second;

    public const int c1 = 123;
    public readonly int c2;

    private void MyMethod()
      //This would cause a compile error:
      //c2 = 123;

Params - He discusses the params keyword in a method signature, which lets you pass in a variable amount of parameters into a method. The called-method receives these params as an array. Using Ildasm to view the code, one can see that the params keyword generates the System.ParamArrayAttribute.

    public static void DialEm(string message, params string[] numbers)    {      //Do stuff    }    public static void CallFred()    {      DialEm("Hi Fred!", "123", "456", "789");    }

Constructors - He explains about static vs. instance constructors. Looking at the IL, it's interesting to note that the static method has the name ".cctor", and the instance method has the name ".ctor" (only 1 c).

Interfaces - He points out that interfaces can strongly-type the context that an object should be used in. SO if you have objects AmericanPerson, CanadianPerson, and Turnip, you can have the first two objects implement the IPerson interface so that methods (at compile time) can uses those in a "person" context. By having an object implement multiple interfaces, you allow it to clearly be used in multiple contexts.

Overall, this chapter constantly transcends just the C# language and points to what the IL actually looks like. Constantly seeing the IL helps to fill in some gaps and see the significance of certain coding decisions.

Lastly, Don observes about the importance of types that "Developers spend most of their time defining new types in terms of existing types." (75). This is an interesting observation, and something that code generation is actively trying to address. For example, without codegen, a developer will spend a significant amount of time constructing objects that map to their database, like an "Employee" and "Customer" object. However, with codegen, the developer ideally just generates these objects based of of existing schema (such as a database or an xml file).

Sunday, December 3, 2006

What Flat Tires Can Teach You About Your Build Process

[This was originally posted at]

While driving with my wife this weekend, we started hearing a strange bumping sound in our car. We didn't want to stop because it was the start of a Chicago winter, we were already late to our destination, and our 16-month old son was in the car. However, we quickly pulled over anyway - just as we started smelling burning rubber. Sure enough, we had a flat tire. After demonstrating my amazing car skills and impressing my wife (that's sarcasm - I have no car skills), we got the tire changed. We then drove back home and everything was okay.

Back in the comfort of our warm home, I started thinking how a flat tire reminded me of a broken build:

  • Both are dangerous if ignored: You will ruin your entire wheel and eventually car frame if you keep driving with a flat tire. Likewise, you will cripple your application with so many compile and test errors if you keep checking in code despite the build already being broken.
  • Both give you clear warning signs: A car with a flat makes an obvious sound, thumping feeling, and smells of burning rubber. A broken build (if you have a continuous integration system like Cruise Control) gives you clear emails about the exact build failure.
  • Both don't get fixed by ignoring the problem: A car tire doesn't magically get un-flat. A broken build doesn't magically get fixed.
  • Both require stopping what you're doing to fix the problem: In development, I constantly hear "but we're to busy to ". Just like fixing a flat requires you to stop the car (even if you're already late), fixing the build requires at least one developer to stop their features and check in a fix.
  • Both can be fixed with relatively little effort: A high-school kid can change a flat time in 10 minutes (i.e. it's not expensive or rocket science). Likewise, if you have continuous integration (and hence can see the exact code-checkin that broke the build, and the exact error that went wrong), it's usually very obvious and quick to make a fix - definitely much easier than if you wait and let the build errors grow.