Jan 052016
 

CODE KeyboardAs I type this, the sweet, sweet clicky sound of my new CODE Keyboard fills the air and my fingers, typing speed, and general demeanor couldn’t be happier. I have been debating purchasing a mechanical keyboard for a while now and decided to treat myself to a nice keyboard for Christmas.

 

My prior keyboard was a Logitech KB350, which is a wireless, rubber-dome keyboard. I used it for at least five years and it served me well. However, I had been hearing all of the hype about mechanical keyboards for quite some time. A couple friends had gotten them for gaming, but swore by them for general typing for coding as well. After some research, I discovered that rubber-dome keyboards require the key to travel the full distance to the PCB (printed circuit board) to make contact with the circuit on the board. Supposedly, this causes more fatigue and causes more typing errors due to the longer key travel.

Logitech KB350 and CODE Keyboard

Logitech KB350 and CODE Keyboard

I have been using this keyboard for a day, so I can’t speak to it’s magical powers of productivity increases, but I can say that it is very solidly built. Here are my first impressions:

  1. WASD Keyboard takes pride in their devices.  You need to go check out WASD Keyboards.  They make custom mechanical keyboards that are solid.  This keyboard is heavy.  The possibilities of the keyboards that they can make are endless.  You can go off-script and make any custom mechanical keyboard you want, with different key colors for every key if you want.  You can even have them print images across your keys.  Further, you can specify which MX switch key color that you want on your keyboard.
  2. Cherry MX mechanical keys are cool.  The most important customization that you can make with a mechanical keyboard is the type of switch that is used for each key.  After a lot of consideration, I went with the Cherry MX blue keys.  I thought that I would like the travel and satisfying click of the keys and so far my assumption was correct.  Some folks like the harder-to-push green, or the no-click browns.  To me, these blues are perfect, but you can choose from blue, green, brown, or clear to suit your particular typing style.
  3. I really like the LED backlighting.  You can choose between 6 different levels of brightness.  It’s just a cool, clean look that is nice in a dark office.  You should know that (at the time of typing this) WASD doesn’t have a backlighting option for their other keyboards (other than the CODE).  So if you want, you can print your cat’s picture across your keys.  You just can’t have the keys backlit.
  4. The CODE Keyboard is a collaboration between WASD Keyboards and Jeff Attwood of the popular Coding Horror blog.  This keyboard looks and feels like a clean, professional keyboard. There aren’t any crazy colors to distract.  Just a solid keyboard to get code done.
  5. The multimedia controls on the keys are understated, but very convenient.  On my old KB350, the multimedia controls are on top of the keyboard.  They stand out very prominently and add about 2 inches to the top of the keyboard.  On the CODE, the multimedia controls are in the Home cluster as function keys.  You can control them with one hand very easily.  The nice thing about having the keys as function keys is that you don’t have a lot of other clutter making the keyboard larger.  This isn’t a big deal to me, but I nice the nice, sleek form factor of the CODE.
  6. CODE is configurable for a Windows or Mac and you can tweak the function of the Caps Lock and OS keys via the dip switch on the back.

Back of CODE Keyboard

Will the CODE Keyboard make my C# code more efficient?  Will it make my Azure Powershell scripts more readable?  Will it make my writing more interesting?  Probably not.  However, in the journey from my head to the screen, my fingers and ears will experience a miniscule bit of tactile and audible happiness, which, when multiplied by each click will make me happier, so I think the CODE was a good purchase.

Dec 082014
 

In my last post, I showed a way to generate unit tests for existing code where a pattern exists using .NET’s System.Reflection library. The post showed an executable that would take the paths to a dll and an output file as input parameters where this executable would then tear through the assembly, looking for string properties for which I wanted tests. The exe would generate stub code to ensure that I wouldn’t miss any of the string properties.

I was discussing this with a colleague who suggested that I consider generating a T4 text template within Visual Studio to do this same work.  I had never used the templates before, but have found them to be amazingly simple, yet very useful tools to have in the arsenal.  I was able to take the code from the exe that I described in the last post, incorporate it into a template, and have it generate the same test code in about 5 minutes.

The benefit to using T4 text templates is that they are meta-code that reside within your Visual Studio project.  The cool thing is that the meta code regenerates the output file from the template during builds and after edits to the template.  Because of this close relationship with code in their project, these templates can be used to auto-generate output files that respond to changes in the code.  This can be particularly handy if you are creating schema files, config files, tests, or other forms of output that need to be kept fresh as your code changes.

I took the project that I used in the last post and added the T4 text template.  To do this, I simply added a new Text Template:

AddNewTextTemplate

After adding the template, you can see the template in the Solution Explorer window.  You can also see the generated code file as a child of the text template, as shown here:

TemplateInSolutionExplorer

When you first generate a text template, it puts header information in the .tt file for you that you have to edit.  You’ll notice that code that is to be evaluated is placed inside of <# #> bracketing.  The text within these delimiters will not be shown in the output file, but will contain the code needed to output something useful to the file.

<#@ template debug="false" hostspecific="false" language="C#" #>
<#@ assembly name="System.Core" #>
<#@ import namespace="System.Linq" #>
<#@ import namespace="System.Text" #>
<#@ import namespace="System.Collections.Generic" #>
<#@ output extension=".txt" #>

You can see that the default output extension is .txt. I changed that to .cs. You can also see that the template is generated with assembly and import directives. Assembly is like adding a reference to a project and import is analogous to a using directive in a C# file. Since I already knew my dependencies from my prior project, I modified this information to look like this:

<#@ template debug="false" hostspecific="true" language="C#" #>
<#@ output extension=".cs" #>
<#@ assembly name="System"#>
<#@ assembly name="System.Xml"#>
<#@ assembly name="System.Xml.Linq"#>
<#@ import namespace="System" #>
<#@ import namespace="System.Xml.Linq"#>
<#@ import namespace="System.Reflection" #>

This block is code that the template will use when run. It is the list of references (assembly tag) and usings (import tag) that the code I will add later will use.

Next I will add the using statement block that I want my output file to have. This text will not be inside the <# #> delimiters because I actually want to see this code in my output file. Note that this text is not the usings that the template will need to run. Since it is outside of the delimiters, it is seen as simple text to be output:

using System;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;

Next, since I was writing a unit test file generator, the namespace and class declaration needed to be added. These were in funky functions in executable in my prior post. These functions added “header” and “footer” information, for lack of better terminology. This was awkward, but here it is quite elegant because I am actually writing this one-time-output text as it will be seen in the output.

namespace MyProject.Tests
{
    [TestClass]
    public class MyTests
    {
    }
}

After this, I extracted the code from the executable I built in the prior post and put it into the template. You’ll notice the <#= stuff #> where I wanted to emit text generated from code into the output file. This is the final text template file:

<#@ template debug="false" hostspecific="true" language="C#" #>
<#@ output extension=".cs" #>
<#@ assembly name="System"#>
<#@ assembly name="System.Xml"#>
<#@ assembly name="System.Xml.Linq"#>
<#@ import namespace="System" #>
<#@ import namespace="System.Xml.Linq"#>
<#@ import namespace="System.Reflection" #>
using System;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace MyProject.Tests
{
	[TestClass]
	public class MyTests
	{
		<#
		var a = Assembly.LoadFrom(@"c:\temp\ProjectToTest\ProjectToTest.dll");
        foreach (var type in a.GetTypes())
        {
            // get all public static properties of MyClass type
            var propertyInfos = type.GetProperties();

            // sort properties by name
            Array.Sort(propertyInfos,
                delegate(PropertyInfo propertyInfo1, PropertyInfo propertyInfo2)
                {
                    return propertyInfo1.Name.CompareTo(propertyInfo2.Name);
                });

            // write property names
            foreach (var propertyInfo in propertyInfos)
            {
                if (propertyInfo.PropertyType == typeof(string))
				{

		#>
[TestMethod]
		public void MyTests_<#=  type.Name.Replace("`", "") #>_<#= propertyInfo.Name #>()
		{
			// Put in code here for your test
		}
		<#
				}
            }
        } 
		#>
	}
}

If you’ll notice, the “[TestMethod]” indention looks a little nutty in the text template file. I found that I had to play a little to get the indention right. Also, you can see that I have hard-coded the path to the dll that I wanted to reflect. This could be made better via a project variable somehow.

After the final updates to the template file, Visual Studio automatically generated this output when I saved the template:

using System;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace MyProject.Tests
{
	[TestClass]
	public class MyTests
	{
		[TestMethod]
		public void MyTests_Class1_String1()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class1_String2()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class1_String3()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class1_String4()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class1_String5()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class1_String6()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class2_String1()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class2_String2()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class2_String3()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class2_String4()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class2_String5()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class2_String6()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class3_String1()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class3_String2()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class3_String3()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class3_String4()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class3_String5()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class3_String6()
		{
			// Put in code here for your test
		}
			}
}

If I had some severely repetitious checks to make, I could make this file regenerate and change with every change to my code. This is interesting for unit testing, but really has cool applications in other areas, like schema generation, documentation, etc.

Much thanks to my colleague for pointing T4 text templates out to me! This is another cool tool to keep handy.

Nov 202014
 

There are times when you need to write unit tests and it is important to ensure that you get full code coverage.  That first sentence alone will tip you off to the fact that this is not a TDD scenario, but rather a situation where you need to create test cases for pre-existing code.  It is easy to overlook methods or properties when backfilling tests, so it would be nice to have a tool to help in these situations.  Thankfully, you can use .NET reflection to trawl through your assemblies, writing stub code, looking for the properties and/or methods that you have interest in and making sure that you don’t overlook important items.

I have written a quick example to illustrate how useful reflection can be in auto-generating tests and test stubs. The point here is not that I have written the be-all-end-all test generator, but to show that you can quickly cover some ground in brownfield testing with the proper application of the System.Reflection library.

In this quick example, I have 3 classes that each have some string properties:

namespace AssemblyToTest
{
    public class Class1
    {

        public string String1 { get; set; }
        public string String2 { get; set; }
        public string String3 { get; set; }
        public string String4 { get; set; }
        public string String5 { get; set; }
        public string String6 { get; set; }

    }
    
    public class Class2
    {
        public string String1 { get; set; }
        public string String2 { get; set; }
        public string String3 { get; set; }
        public string String4 { get; set; }
        public string String5 { get; set; }
        public string String6 { get; set; }
    }

    public class Class3
    {
        public string String1 { get; set; }
        public string String2 { get; set; }
        public string String3 { get; set; }
        public string String4 { get; set; }
        public string String5 { get; set; }
        public string String6 { get; set; }
    }
}

Let’s say that you’re interested in looking for all public string properties in classes in your assembly to ensure that you have proper string validation.  In TDD, you would have already written the tests before writing the code, so problem solved!  However, in many cases, you may find yourself retrofitting old code with new tests.  In this example, you can use reflection to load the assembly in which you are interested, loop through all of the types in the assembly, and then loop through the properties of each type.  Armed with this information, you can then use a writer to generate a unit test code file, complete with stubs.  You could even generate some of the test code, if you have enough domain information.

Check out this simple program for generating stub tests:

using System;
using System.IO;
using System.Linq;
using System.Reflection;  // reflection namespace

namespace UnitTestGenerator
{
    /// <summary>
    /// This program returns/generates a list of all properties for all classes in the given assembly that are of type string.  
    /// This program borrows from code found at the following sites:
    /// http://www.csharp-examples.net/reflection-property-names/
    /// http://stackoverflow.com/questions/1315665/c-list-all-classes-in-assembly
    /// http://msdn.microsoft.com/en-us/library/system.reflection.assemblyname(v=vs.110).aspx
    /// http://msdn.microsoft.com/en-us/library/1009fa28(v=vs.110).aspx
    /// http://stackoverflow.com/questions/3723934/using-propertyinfo-to-find-out-the-property-type
    /// </summary>
    /// 
    /// This program generates unit test stubs for all of the string properties of all of the types in an assembly.  It will need to 
    /// be modified to specifically generate the test stubs desired.  
    /// Argument 0 = Path to the assembly
    /// Argument 1 = Path and file name for output file
    class Program
    {
        static void Main(string[] args)
        {
            if (!ValidateArguments(args)){return;}

            using (var sw = File.CreateText(args[1]))
            {
                WriteUsingBlock(sw);
                WriteClassHeader(sw);
              
                var a = Assembly.LoadFrom(args[0]);
                foreach (var type in a.GetTypes())
                {
                    // get all public static properties of MyClass type
                    var propertyInfos = type.GetProperties();

                    // sort properties by name
                    Array.Sort(propertyInfos,
                        delegate(PropertyInfo propertyInfo1, PropertyInfo propertyInfo2)
                        {
                            return propertyInfo1.Name.CompareTo(propertyInfo2.Name);
                        });

                    // write property names
                    foreach (var propertyInfo in propertyInfos)
                    {
                        if (propertyInfo.PropertyType == typeof(string))
                            WriteTestForProperty(sw, type.Name.Replace("`", ""), propertyInfo.Name);
                    }
                }

                WriteClassFooter(sw);
            }
        }

        private static void WriteUsingBlock(TextWriter sw)
        {
            sw.WriteLine("using System;");
            sw.WriteLine("using System.Linq;");
            sw.WriteLine("using Microsoft.VisualStudio.TestTools.UnitTesting;");
            sw.WriteLine("");
        }

        private static void WriteClassHeader(TextWriter sw)
        {
            sw.WriteLine("namespace MyProject.Tests");
            sw.WriteLine("{");
            sw.WriteLine("    [TestClass]");
            sw.WriteLine("    public class MyTests");
            sw.WriteLine("    {");    
        }

        private static void WriteClassFooter(TextWriter sw)
        {
            sw.WriteLine("    }");
            sw.WriteLine("}");
        }

        private static void WriteTestForProperty(TextWriter sw, string typeName, string propertyName)
        {
            sw.WriteLine("      [TestMethod]");
            sw.WriteLine("      public void MyTests_{0}_{1}()", typeName, propertyName);
            sw.WriteLine("      {");
            sw.WriteLine("          // Put in code here for your test");
            sw.WriteLine("      }");
            sw.WriteLine("");
        }

        private static bool ValidateArguments(string[] args)
        {
            if (!args.Any() || args[0] == "/?" || args[0] == "/h" || args[0] == "/help" || args.Count() != 2)
            {
                Console.WriteLine("GenerateUnitTests takes 2 arguments.  The first is the dll for which tests will be created and the second is the output file.");
                Console.WriteLine("Usage: GenerateUnitTests <dll file path> <output file>");
                return false;
            }

            return true;
        }

    }
}

After running the generator code, you will get stub code that looks like this:

using System;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace MyProject.Tests
{
    [TestClass]
    public class MyTests
    {
      [TestMethod]
      public void MyTests_Class1_String1()
      {
          // Put in code here for your test
      }

      [TestMethod]
      public void MyTests_Class1_String2()
      {
          // Put in code here for your test
      }

      [TestMethod]
      public void MyTests_Class1_String3()
      {
          // Put in code here for your test
      }

      [TestMethod]
      public void MyTests_Class1_String4()
      {
          // Put in code here for your test
      }

      // The generator created many more tests, but I have 
      // omitted them for the sake of brevity.

This is just stub code from the example, but you could expand the generator to fit your testing needs.

TDD is definitely the desired way to generate greenfield code.  The benefits of focus alone prove that out.  However, when you have to retrofit tests for when refactoring or generating tests on existing code, using .NET’s reflection capability will save an enormous amount of “pattern pounding” and it will make sure you are thorough!

Apr 302014
 

Don’t Repeat Yourself, or DRY, is a key principle of software engineering.  Various sites on the web and various courses state this principle as

“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”

One of the things this means, practically, is that the abstractions that you use in your code should provide for reuse such that there is never a need to copy code.

Reuse of code can be accomplished by properly designing your objects (abstractions) such that they have a single responsibility.  For example, if you have several objects that communicate with a data layer, you should abstract the data layer away into a data access class that is then injected into the constructor of objects that need to converse with the data layer.  This provides for better data encapsulation and allows for better unit testing as you can create a fake for the data access object.  Another example of how you can reuse code is through the use of base classes that provide functionality that is common to a set of potentially derived classes.

I recently presented a course on best practices for Object Oriented Design at my company and ran across a very cool tool that was mentioned in a Pluralsight course by Steve Smith.  The tool is Atomiq by goldfinch.  It is a completely free tool that they make available (self-admitedly) to drum up business for their static analysis tool, Nitriq.  Atomiq searches your code and finds code duplication and similarities.  It provides statistics and and easy way to navigate to duplications within the code.  It provides a very nifty graphic to show where duplicates are and it even has a command line exe for which a threshold can be set for use with a continuous integration builder (very cool!).

I decided to test drive Atomiq using some old code to which I had access.  I knew this code would give Atomiq a run for its money as this code has been around for a decade and has been touched and tweaked and, well, defiled by many developers.  After letting Atomiq analyze the entire project, this is the wheel graphic that was generated by Atomiq:

Wheel Output From Atomiq For Solution with Lots of Repetition

Wheel Output From Atomiq For Solution with Lots of Repetition – (Class Names Removed to Protect the Innocent)

As I suspected, Atomiq found many sources of repetition in this solution.  Each line crossing this Spirograph looking picture represents an opportunity to refactor this code such that the repetition goes down and the maintainability goes up.

I had another project where I was playing around prototyping a couple ICommand objects for use in ESRI’s ArcMap.  In this project, the two commands were generated using the ArcMap ICommand generation tool in Microsoft Visual Studio.  Because the classes were auto-generated, the same base code was added to each.  For example, this code (along with a few other lines) was auto-generated into both classes:


#region COM Registration Function(s)
[ComRegisterFunction]
[ComVisible(false)]
static void RegisterFunction(Type registerType)
{
    // Required for ArcGIS Component Category Registrar support
    ArcGisCategoryRegistration(registerType);
}

[ComUnregisterFunction]
[ComVisible(false)]
static void UnregisterFunction(Type registerType)
{
    // Required for ArcGIS Component Category Registrar support
    ArcGisCategoryUnregistration(registerType);
}
#endregion

This duplicated code caused Atomiq to (rightly) generate this graph:

Atomiq Output Because of Duplicate Auto-Generated ICommand Template Code

Atomiq Output Because of Duplicate Auto-Generated ICommand Template Code

For this particular duplication, Atomiq found 65 lines that were similar.  Also, Atomiq showed this similarity view, that showed the same code side-by-side:

Atomiq Similarity View Showing ESRI ICommand Boilerplate

Atomiq Similarity View Showing ESRI ICommand Boilerplate

This is one example where Atomiq shows a great place to do some refactoring.  By pulling all of the ESRI ArcMap boilerplate code into a base class, we can move all of this duplicate code to one place and then create derived classes from this base class.  For this example, I just started by refactoring out a part of the similar code, as shown here:


using ESRI.ArcGIS.ADF.BaseClasses

// Base class from which all other ESRI ICommands should be derived for code reuse

[ComVisible(true)]
public abstract class MyBaseCommand : BaseCommand
{
    [ComRegisterFunction]
    [ComVisible(false)]
    static void RegisterFunction(Type registerType)
    {
        // Required for ArcGIS Component Category Registrar support
        ArcGisCategoryRegistration(registerType);
    }

    [ComUnregisterFunction]
    [ComVisible(false)]
    static void UnregisterFunction(Type registerType)
    {
        // Required for ArcGIS Component Category Registrar support
        ArcGisCategoryUnregistration(registerType);
    }

    // Move other common ICommand code here

}

After reanalyzing the code, the 65 similar lines dropped to 55:

After refactoring - Duplicate Lines Dropped from 65 to 55

After refactoring – Duplicate Lines Dropped from 65 to 55

By iterating in this same fashion, Atomiq can help to eliminate duplications and make this code more maintainable.

While there is no silver bullet, Atomiq is a very good (and very free) tool to use in making sure that you write code that complies with the DRY principle.  When coupled with the command line version for a continuous integration builder, this is a great way to improve code quality.

Oct 112013
 

In C#, all types inherit from a single root, the object type.  This allows for primitive types such as int, boolean, and char to be addressed as objects throughout the system.  There is some debate as to whether or not this is a good thing as there is some overhead involved in packaging up or “boxing” primitive types.  Other languages, such as Java, don’t require boxing primitive types into reference types, thus trading overhead for convenience.  However, in the .NET Framework, boxing primitive types is standard practice.

I was curious as to how much overhead is involved in boxing and unboxing primitive, value types in and out of the Object reference type, so I wrote this small test program.

using System;
using System.Collections;
using System.Collections.Generic;
using System.Diagnostics;

namespace BoxingAndGenerics
{
 class Program
 {
 // This test shows that there is significant overhead when boxing and unboxing value
 // types (int, string, double) into the Object type.
 // All explicit variable declarations have been left in the code instead of using var for clarity
 static void Main()
 {
   const int numberOfInterations = 8000000;

   // create an ArrayList of strings
   var startTime = Stopwatch.GetTimestamp();
   ArrayList aListOfStrings = new ArrayList();
   for (var i = 0; i< numberOfInterations; i++)
   {
     string theString = i.ToString();
     aListOfStrings.Add(theString);

    string unpackedString = (string)aListOfStrings[i];
   }
   var ellapsedTime = (Stopwatch.GetTimestamp() - startTime) / (double) Stopwatch.Frequency;
   Console.WriteLine("Time to create string array with boxing: {0}", ellapsedTime);

   // create a List<String> of strings
   startTime = Stopwatch.GetTimestamp();
   List<string> aGenericListOfStrings = new List<string>();
   for (var i = 0; i < numberOfInterations; i++)
   {
     string theString = i.ToString();
     aGenericListOfStrings.Add(theString);

     string unpackedString = (string)aGenericListOfStrings[i];
   }
   ellapsedTime = (Stopwatch.GetTimestamp() - startTime) / (double)Stopwatch.Frequency;
   Console.WriteLine("Time to create string array using Generic array: {0}", ellapsedTime);


   // create an ArrayList of ints
   startTime = Stopwatch.GetTimestamp();
   ArrayList aListOfInts = new ArrayList();
   for (var i = 0; i < numberOfInterations; i++)
   {
      aListOfInts.Add(i);

      int unpackedInt = (int)aListOfInts[i];
   }
   ellapsedTime = (Stopwatch.GetTimestamp() - startTime) / (double)Stopwatch.Frequency;
   Console.WriteLine("Time to create int array with boxing: {0}", ellapsedTime);

   // create a List<int> of ints
   startTime = Stopwatch.GetTimestamp();
   List<int> aGenericListOfInts = new List<int>();
   for (var i = 0; i < numberOfInterations; i++)
   {
     aGenericListOfInts.Add(i);

     int unpackedInt = (int)aGenericListOfInts[i];
   }
   ellapsedTime = (Stopwatch.GetTimestamp() - startTime) / (double)Stopwatch.Frequency;
   Console.WriteLine("Time to create int array using Generic array: {0}", ellapsedTime);


   // create an ArrayList of doubles
   startTime = Stopwatch.GetTimestamp();
   ArrayList aListOfDoubles = new ArrayList();
   for (var i = 0; i < numberOfInterations; i++)
   {
     double theDouble = (double) i;
     aListOfDoubles.Add(theDouble);

     double unpackedDouble = (double)aListOfDoubles[i];
   }
   ellapsedTime = (Stopwatch.GetTimestamp() - startTime) / (double)Stopwatch.Frequency;
   Console.WriteLine("Time to create double array with boxing: {0}", ellapsedTime);

   // create a List<int> of doubles
   startTime = Stopwatch.GetTimestamp();
   List<double> aGenericListOfDoubles = new List<double>();
   for (var i = 0; i < numberOfInterations; i++)
   {
     double theDouble = (double) i;
     aGenericListOfDoubles.Add(theDouble);

     double unpackedDouble = (double)aGenericListOfDoubles[i];
   }
   ellapsedTime = (Stopwatch.GetTimestamp() - startTime) / (double)Stopwatch.Frequency;
   Console.WriteLine("Time to create double array using Generic array: {0}", ellapsedTime);

   // Put in a read so that we can take a look at the output
   Console.ReadLine();
  }
 }
}

After running the program, this is the output:

Boxing and Generics Output

As expected, strings are always going to be expensive to deal with due to their immutable nature.  Interestingly, you can see that numeric types are about 10 times slower when dealing with boxing.  Therefore, when possible we should use generic collection types so that the CLR knows in advance the type that it is dealing with and can avoid the overhead of boxing.

Sep 032013
 

I have been doing a little research on regular expression support in the .NET framework and have been impressed with my findings.  As a developer, regular expressions are a very useful tool to keep in the arsenal.  They can help programs efficiently search text and they can be used to validate input (think phone numbers or email addresses, among other things).

Two great sources of information for expression syntax are regular-expressions.info and MSDN.  These two sources help make sense of the metacharacters, escapes, anchors, groups, and other artifacts of a well-formed expression.

The syntax for searching a string using the .NET System.Text.RegularExpressions.Regex class, is very straight forward and the class seems very efficient when compared with other string search methods.  If you drop the following into a console application, you can compare the time needed to find the string “simple text” in the string represented by the “ipsum” string variable.  In this example, I generated the ipsum variable using the itools Lorem Ipsum generator.  I generated a single string 250,000 words long.


var ipsum = //generate a large string, perhaps using the itools Lorem Ipsum generator and embed "simple text" within the string

var stopwatch = new Stopwatch();

Regex RegexSearch = new Regex("simple text", RegexOptions.None);
stopwatch.Restart();
for (int i = 0; i < 1000; i++)
{
    RegexSearch.IsMatch(ipsum);
}
stopwatch.Stop();
Console.WriteLine("Ellapsed time with Non-compiled Regex: " + stopwatch.ElapsedMilliseconds);

Regex CompiledRegexSearch = new Regex("simple text", RegexOptions.Compiled);
stopwatch.Restart();
for (int i = 0; i < 1000; i++)
{
    CompiledRegexSearch.IsMatch(ipsum);
}
stopwatch.Stop();
Console.WriteLine("Ellapsed time with Compiled Regex: " + stopwatch.ElapsedMilliseconds);

stopwatch.Restart();
for (int i = 0; i < 1000; i++)
{
    ipsum.Contains("simple text");
}
stopwatch.Stop();
Console.WriteLine("Ellapsed time with Contains: " + stopwatch.ElapsedMilliseconds);

// Display times
Console.ReadLine();

The run times were pretty telling.  As you can see from this output, when searching a string with 250,000 word of random length, the non-compiled regex search was much faster:

elapsedtime

Writing regular expressions can be complicated but there are some really useful tools for use in their generation.  The defacto tool right now seems to be RegexBuddy (for a $40 license fee).  Also, Roy Osherove has several regular expression tools available at his website.  Finally, you can search for community submitted expressions at regexlib.com, where there are many, many examples from which to choose.

Your mileage (and mine) may vary from project to project, but using the Regex class to dig through large amounts of text is definitely worth considering.

Jul 202013
 

The Infragistics WinForm controls are some of the best, most extensible 3rd party controls that I have ever used for UI development.  The set of controls is quite comprehensive and the API is exhaustive.  You can do anything with these controls, in terms of overriding their function and form.  This fact makes using the controls a little intimidating as the gain in extensibility brings with it a high overhead in API knowledge.  Since I use (and tweak) the UltraGrid control most often, I have decided to create a “cheat sheet” post with my most used Infragistics UltraGrid API calls.  Hopefully this will help me (and perhaps someone else) in the future.


&nbsp;

//Make column a drop down list style so that the user cannot edit the items in the ValueList
band.Columns["MyColumn"].Style = ColumnStyle.DropDownList;

// Set the ShowExpansionIndicator property to 'CheckOnDisplay' so we don't display
// an expansion indicator for nodes that have no descendants.
band.Override.ExpansionIndicator = ShowExpansionIndicator.CheckOnDisplay;

// Get object bound to row:
return (&lt;MyObject&gt;)row.ListObject;

// Change row to red:
// Do this in grid_InitializeRow
appearance = new Appearance
{
BackColor = Color.PaleVioletRed,
ForeColor = Color.DarkRed
};
row.Appearance = appearance;

// Resize columns to fit available area:
// Do this in grid_InitializeLayout
grid.DisplayLayout.AutoFitStyle = AutoFitStyle.ResizeAllColumns;

// Programmatically resize every column as if you had double-clicked the line to the right of the header
// Expands out every column to fit the largest item in the column
foreach (var column in grid.DisplayLayout.Bands[0].Columns)
{
column.PerformAutoResize(PerformAutoSizeType.VisibleRows, AutoResizeColumnWidthOptions.All);
}

// Change or localize column headers:
// Do this in grid_InitializeLayout
band.Columns[ColumnName].Header.Caption = “My localized text”;

// Make a column a drop-down list (combo style):
// Do this in grid_InitializeLayout
band.Columns[Status].Style = ColumnStyle.DropDownList;

//Don’t display expansion indicators (+ signs to the left) for nodes in a multi-band grid that have no descendants:
band.Override.ExpansionIndicator = ShowExpansionIndicator.CheckOnDisplay;

// Hide a column across all bands
foreach(var band in diagnosticsInformationGrid.DisplayLayout.Bands)
{
if (band.Columns.Exists("Tool"))
{
band.Columns["Tool"].Hidden = true;
}
}

// Manually hide/unhide rows by value. In this example, if the status is 0, hide the row.
var allRowsEnumerator = grid.Rows.GetRowEnumerator(GridRowType.DataRow, null, null);
foreach (UltraGridRow row in allRowsEnumerator)
{
row.Hidden = false;
if (row.Cells["MyStatusColumn"].Value != DBNull.Value)
{
var compareStatus = (string) row.Cells["MyStatusColumn"].Value;
if (compareStatus == "0") row.Hidden = true;
}
}

// Manually remove a column from the column chooser
grid.DisplayLayout.Bands[0].Columns["MyColumn"].ExcludeFromColumnChooser = ExcludeFromColumnChooser.True;

// Hide column headers
grid.DisplayLayout.Bands[0].ColHeadersVisible = false;

// Disable row delete
grid.DisplayLayout.Override.AllowDelete = DefaultableBoolean.False;

// Disable the default grid behavior that allows n splits of the grid into what Infragistics calls "scroll regions"
grid.DisplayLayout.MaxColScrollRegions = 1;
grid.DisplayLayout.MaxRowScrollRegions = 1;

// Disable the activation, and thus edit, of a particular column
grid.DisplayLayout.Bands[0].Columns[0].CellActivation = Activation.NoEdit;

// Add a value list (drop down list) to a grid cell
var editorSettings = new DefaultEditorOwnerSettings();
var valueList = new ValueList();
valueList.ValueListItems.Add(null, null); // Add a blank to allow the user to set the field back to null
foreach (var value in listOfValuesFromSomewhere.ValueList)
{
valueList.ValueListItems.Add(value.Key, value.Value);
}
editorSettings.ValueList = valueList;
editorSettings.DataType = typeof(string);
EmbeddableEditorBase editor = new EditorWithCombo(new DefaultEditorOwner(editorSettings));
row.Cells["Value"].Editor = editor;

// Set the grid to NOT make the first row the active row on load. By default, the grid makes the first
// row active, but not selected. It's a bit confusing, so this changes that behavior.
// WARNING - this only works in a read-only grid. Turning of sync will cause issues if you are updating
// grid data.
grid.SyncWithCurrencyManager = false;

// Set up the grid to support IDataErrorInfo
e.Layout.Override.SupportDataErrorInfo = SupportDataErrorInfo.RowsOnly;

e.Layout.Override.DataErrorCellAppearance.ForeColor = Color.DarkRed;
e.Layout.Override.DataErrorRowAppearance.BackColor = Color.MistyRose;
e.Layout.Override.DataErrorRowAppearance.BackColor2 = Color.MistyRose;

e.Layout.Override.RowSelectorWidth = 25; // Make larger to accomodate error icon. Tweak as necessary and make this a const
e.Layout.Override.DefaultRowHeight = 22; // Make larger to accomodate error icon. Tweak as necessary and make this a const

// Sort the grid by some column value
grid.DisplayLayout.Bands[0].Columns["TheColumnOnWhichToSort"].SortIndicator = SortIndicator.Ascending;

////////////////////////////////
// Add a popup menu to a grid //
////////////////////////////////
// Create a new popup menu //
Infragistics.Win.UltraWinToolbars.PopupMenuTool mnuPopupMenu = new Infragistics.Win.UltraWinToolbars.PopupMenuTool("popupMenu");
Infragistics.Win.UltraWinToolbars.ButtonTool btn1 = new Infragistics.Win.UltraWinToolbars.ButtonTool("Button1");
Infragistics.Win.UltraWinToolbars.ButtonTool btn2 = new Infragistics.Win.UltraWinToolbars.ButtonTool("Button2");

// Add the menu and the buttons to the tools collection //
ultraToolbarsManager1.Tools.Add(mnuPopupMenu);
ultraToolbarsManager1.Tools.Add(btn1);
ultraToolbarsManager1.Tools.Add(btn2);

// Add the button tools to the menu //
mnuPopupMenu.Tools.Add(btn1);
mnuPopupMenu.Tools.Add(btn2);

// Set the caption to be displayed for the button tools //
btn1.SharedProps.Caption = "Button 1"; // Localized string
btn2.SharedProps.Caption = "Button 2"; // Localized string

// Add images to each button on the menu //
btn1.SharedProps.AppearancesSmall.Appearance.Image = imgToolbarImages.Images[0];
btn2.SharedProps.AppearancesSmall.Appearance.Image = imgToolbarImages.Images[1];
// Do large as well //

// Set the context menu for the TextBox control to the popup menu tool created //
ultraToolbarsManager1.SetContextMenuUltra(this.theGrid , "popupMenu");