Derik Whittaker : Featured, Development

Simple extension methods to help with Asserting values

Derik Whittaker — Thu, 10 Apr 2008 12:49:43 GMT

In the past I have written about the Fail Fast principle. This is a principle I try to live my development life by. I would rather explicitly check for possible failure points then have a runtime error crop up. In the past when writing these failure check we have had to resort to a few 'cavemanish' techniques. But with the inception of Extension Methods (here or here) we can actually create something that is pretty simple as well as elegant.

Lets take a look at a few examples where we are NOT using extension methods to accomplish our failure checking.

public bool SomeMethod( string key )  
{  
	// In this case the key cannot be null or empty  
	if ( key.length == 0 ) { throw new ArgumentOutOfRangeException( "key", "Some Message Goes here" ); }
}

The code above works, it is pretty simple and will get the job done. But to be honest, having this sprinkled all over your code is kinda ugly.

public bool SomeMethod( SomeObject obj, Int32 someInt )  
{  
	// In this case the object cannot be null  
     	Assert.IsNotNull( obj, "Some Object" );  
  
	// In this case the int must be greater then 1  
     	Assert.IsTrue( someInt > 1, "Some Int not correct" );  
}

This code works as well and is more concise the the previous example. However, this code is still less readable then the example below.

Now, lets take a look at the same thing, but using Extension Methods

public bool SomeMethod( SomeObject obj, strnig someString )  
{  
	// In this case the object cannot be null  
	obj.AssertNonNull(); 
  
	// In this case the cannot be null or empty
	someString.AssertNotNullOrEmpty();	
}

Here is the code for the actual extension methods assert

public static void AssertNonNull( this T value )
{
	// Do our null check here.
	if ( value == null ) 
	{ 
		// Could even use reflection to gather info such as calling method, method exception was
		//	found in, etc.
		throw new ArgumentNullException( "Some message here" );
	}
}

The assert above using the extension method to me is the most elegant. It is easy to read (very important) and very concise.

Keep in mind, all the examples above do the exact same thing, but they do in varying levels of elegance. I would argue that the usage of extension methods here makes the code cleaner and easier to read.

Till next time,

Subclassing for Success

Derik Whittaker — Fri, 02 Nov 2007 12:36:58 GMT

As someone how has been designing and developing WinForms based applications for the past 7+ years, I have learned that subclassing UI controls is a must. You may be thinking, why would I want to subclass a text box? Or a combo box? The answer is simple, the better future proof your app.

How many times have you been into the development cycle of your application and you found out that you needed/wanted to extend the text box that is being used. By extend I am not necessary talking about adding functionality to it, but do something like having the control highlight the entire contents of the control when the it receives focus.

If you don't have your controls subclassed, extending your control will be a pain in your ass. Sure you could find EVERY use of the control and add the needed code. Or you could find and replace your control later with the subclassed control, but both of these suck.

When I start a new WinForms (same concept should work for Browser based as well) application, I will immediately add a Controls namespace and simply add my subclassed controls. In many cases I never extend the control, but knowing that I can do so allows me to make better decisions later on.

One example of where this has helped me in the past was on a project where about 6 months into development, the business owners decided that would like the UI controls (text box, check box, combo box, etc) to change background color when the control receives focus and then change back when it loses focus. Because I had everything subclassed i was able to implement this request in a very short time frame and did not even have to open up a single form. Had I not subclasses the controls I would have either pushed back heavily or it would have taken me much longer to implement this change.

Another good use is for things like data grids. Whether you are using the out of the box data grid, or some third party grid like Infragistics or Janus, subclassing can save you a ton. How many times have you developed an application where you wanted a standard look and feel for your grids. Say every other line is gray, and there are no selection column. If the control is not subclassed you are asking each developer to remember to make the look and feel customizations. But, if it is subclassed, simply add the control to the form and you are done.

Till next time,

Using Anonymous Delegates to handle Async Web Service Calls

Derik Whittaker — Mon, 15 Oct 2007 13:27:00 GMT

I just thought I would share a little trick I used today to back in Async web service calls into existing code using anonymous delegates.

Here was my problem:
I have a library that makes use of an existing web service that I do not control (so I cannot change/up the timeout on this). I have been using this code now for a few weeks with no issues, however late last week I noticed that I was experiencing timeouts when making certain requests via the service. My original code was making use of the synchronous methods on the web service. In order to get around the time out issue I wanted to make the calls asynchronous, but I did not want to have to put in a ton of time or effort to retrofit my code.

Here is my solution:
Create an anonymous delegate to handle my Async call and move on.

Here is my original code

XmlNode results = listService.GetListItems( param1, param2, param3, param4, param5, param6, param7 ); .... Do something here ....

Here is the new code using the delegates

asyncResults = null; asyncReturned = false; // Wire up the async callback with our delegate listService.GetListItemsCompleted += delegate( object sender, GetListItemsCompletedEventArgs e ) { asyncResults = e.Result; asyncReturned = true; }; listService.GetListItemsAsync( param1, param2, param3, param4, param5, param6, param7 ) // hack, but works....:( while( !asyncReturned ) { System.Threading.Thread.Sleep(1000); } .... Do something here ....

As you can see, this code is not 'slick' and 'cool' but it does do the job. By tweaking this code I was able to not have to re-write any other outside logic to handle the new async way of making this call.

Till next time,

Why I believe IN and WRITE unit tests

Derik Whittaker — Tue, 02 Oct 2007 00:27:25 GMT

In my last post I think I struck a cord with some people in my post 'Unit tests taking too much time'. My intent was NOT to sound like an elitist Agilist or any else of that nature. My intent was simply to put a post out there about the misperception (in my opinion) about how writing unit tests take too much time.

I thought I would put my 'retort' on why I believe in and write unit tests.

Allows ME to write better code

I believe that when I truly follow TDD practices my code comes out simpler. I have also found, that my code tends to follow YAGNI more so then when I don't follow TDD practices.

Here is an example from my past experience. On a prior project I needed to build a 'search engine' into our app (this was not an actual search engine, more like a hunt path engine). When I first started out writing code I started out by creating all these classes and logic that I thought I would need. After about 3-4 hours of coding I was dead in the water. I was not able to solve my problem in a simple manner and I was frustrated. I decided to take a step back and start over.

This time though I started out by writing test to mimic what I actually needed. I continued to follow the principles of TDD (btw, TDD is more then just about writing tests), within an hour or so I had my solution pretty much good to go. All those classes and methods I THOUGHT I would need I did NOT. I was able to scrap about 50% of the code/classes that I thought I needed. And guess what, now I have a test suit to test my new code.

Allows ME to find more bugs during the development process

It has been my experience that I find more bugs while writing tests. This is due to the fact that I not only follow TDD, but I also do my best to implement the Fail Fast Principle. When I am writing my tests I have the ability to create tests that easily walk though the different pathways of my code (I attempt to hit 100% code coverage as well). If I were not writing tests I would have to do this via the application, and this is much more painful and it less likely that I would actually do it.

By writing my tests and testing my code during the development process I know that I have reduced my bug count significantly.

Makes ME feel more comfortable making changes

This is the beauty of TDD, I am not afraid to make any critical changes to my code because I KNOW that I have tests to verify if I screwed anything up.

Have you ever run across some code that 'you were scared' to change? If you had tests for that code I bet you would a WHOLE LOT LESS scared to make any changes. I know that I am.

A case in point for this is as follows. On a prior project a consultant I was working with needed to make changes to some 'smelly' logic. This just happened to be a week or so before a scheduled release. Beacuse he had NO confidence that the changes he would make would NOT break the application, he convinced the business to NOT make the changes. I bet you a dollar that had there been unit tests he would have been much more willing to make the changes. In this case the fact of NOT having tests may have caused the business to lose out on features it needed.

Improves MY code

Because following TDD practices forces you to write your failing code before your passing code, I tend to implement my intent much cleaner and simpler. I also know that because I am writing tests along the way my code is solid.

Allows ME to better convey intent

I know that tests are not a substitution for quality comments that convey intent, but they sure are the next best thing. It is really nice to be able to point someone towards a suite of tests to 'demo' how to use a component.

A case in point for this is as follows. A few weeks ago at work I wrote an API to allow the querying of some data via our imaging system at work. Turns out that an outside party needed to use this API for integration into on of our 3rd party applications. When he came to me asking for 'how do I use this', I simply emailed him my suite of tests. In this suite I had pretty much any conceivable use for the API. To date the vendor has not asked me how to implement the API.

Allows MY tests to be automated and rerunable

This is a nice side effect of having tests. Because we use both NUnit and CruiseControl I can run my tests on every check in. This is cool because now I (and the team) know if changes I made breaks some other part of the system. I would rather know now then before QA hits it.

The above are simply my opinion, if you don't share the same opinions, let me know.

Till next time,

Updating List Information in SharePoint via Web Services

Derik Whittaker — Wed, 19 Sep 2007 12:49:00 GMT

In my continued learning on SharePoint and how to manipulate the data stored in SharePoint I thought I would post on how to perform updates on existing data inside a document library.

When performing an update on data inside of SharePoint there are a few steps that need to happen to make your journey a successful one.

Steps overview

Connect to the correct web service
Know the correct document site (sub site) and document library you want to use
Get the ID/Version for the Site/Library combination
Know the data you want update, along with build the correct CAML statement
Perform the update via the web service

Connecting to the correct web service.
When performing an update you will want to connect to the Lists.asmx server. You can get information about the web service here or if you have downloaded the latest SDK you can find information about the service inside there.

Lists returnService = new Lists(); System.Net.ICredentials credential = new System.Net.NetworkCredential("usernamehere", "passwordhere", "domain here"); returnService.Credentials = credential; returnService.Url = string.Format("{0}/{1}", baseURL, ListsWSName);

In the code above I am simply creating the service and providing it with the correct network credentials. It may be possible for you to use System.Net.CredentialCache.DefaultCredentials in place of providing actual network credentials

Knowing the correct document site/document library
Any time you do anything with the SharePoint web service you will need to know the sub-site and document library. This is because all the web services are isolated to a given sub-site and there are multiple locations for the service. This is also why in the code above I provide the baseURL to connect to. This URL is formatted as this
string.Format( "{0}/{1}/{2}", siteURL, DocumentSiteName, "_vti_bin" )

Get the ID/Version for the Site/Library
I found that in order to perform the update i needed to get the correct version/id for the given library that contains the data to be updated. This information will be used during the actual update.

Build the CAML statement
To perform pretty much any action via the web services you will have to build a correct CAML statement. You can get information on CAML here or check your SDK for info as well.

// Simple CAML for performing an update <Method ID='1' Cmd='Update'> <Field Name='ID'>RowIndexVersion (default to 1)</Field> <Field Name='FieldNameGoesHere'>New Value goes here</Field> </Method>

The CAML above is a very simple one. This will update one field within a single row of data. If you want to perform multiple updates you can do this, check your documentation for more information how.

Perform the actual update
Time to perform the actual update for the data.

// Create the List.asmx object Lists listService = // Do something here to build the list (see above code) // Get the information about the given list ID/Version XmlNode listResponse = listService.GetList( documentLibraryName ); string listID = listResponse.Attributes["ID"].Value; // Provides the GUID id for the actual list string listVersion = listResponse.Attributes["Version"].Value; // Provides the version number for the actual ist // Build the CAML statement string updateCAML = // Do something to build the actual statement (see above code) // Build the XMLdocument object that contains the update request XmlDocument xmlDoc = new XmlDocument(); XmlElement elBatch = xmlDoc.CreateElement( "Batch" ); elBatch.SetAttribute( "OnError", "Continue" ); elBatch.SetAttribute( "ListVersion", listVersion ); elBatch.InnerXml = updateCAML; XmlNode ndReturn = listService.UpdateListItems( listID, elBatch ); // If the ndReturn object has no errors in the Inner/Outer XML then your update was successful.

There you have it, a quick and dirty way to perform data updates via the Lists.asmx web service in SharePoint.

Till next time,

Logging Bugs: Do's and Don'ts

Derik Whittaker — Mon, 20 Aug 2007 00:40:00 GMT

All software that is being developed WILL have bugs, sorry, but this IS a fact. Now I know some people and companies don't like to call them glitches in software bugs. They would rather call them issues or defects. For all I care we can call them 'WizBangs', just call them something and LOG THEM.

However, logging 'WizBangs' (ok, I will call them bugs from here on) is not as simple as it may sound. I would like to go over some of MY Do's and Don'ts in this post. If you don't like my list, or would like to add to it, drop me a line.

When to log Items:

Do log everything. Just because the bug may seem trivial or simple or only happen 'every now and again' does not mean that it should be ignored. Even it you are not sure it is an issue, LOG IT. Better to have close off an non-issue then fail to report a major bug in hiding
Don't assume that someone else is going to fix the issue. Also, don't assume this issue is too trivial or minor to report. Wouldn't it suck to find out after the application went lived that you failed to report a critical bug because you thought it was not a 'big deal'?

Providing information on the log:

Do provide detailed information about the bug. Save yourself the headache later and provide as much information as you possible can. This should include, but not limited to items such as Build Version, Environment, Platform, Short Description of issue, Severity, Detailed steps to reproduce.
Don't make provide a single sentence that says something like 'Unable to perform XYZ in the ABC process'. This type of information will provide nothing of real value to the next guy. Sure, this would be a great line for the title of the bug. But by no means is this enough information to fix the bug.

What types of items to log:

Do Log Everything. Enough said
Don't make assumptions

When to log bugs:

Do log them as soon as possible.
Don't put it off. If you dont log the bug as soon as you find it you WILL forget something about what you did to cause it. For the sake of your fellow co-workers log it now before you forget.

The plain and simple truth about logging bugs is, it sucks!!!! However, it is a necessary part of most developers jobs. If you take some time and put in a little effort, you will be rewarded with great riches. Ok, maybe not great riches, but it will make fixing the bugs much easier.

Till next time,