First, let’s take a look the code for a repository method that builds a query, executes the query, and returns the results in a list:

public IEnumerable<Cat> FindAllCats()
{
	var query = from c in db.Cats
		select c;

	return query.ToList();
}

The “ToList” is forcing the IQueryable<Cat> query to execute and put the results in a list immediately. However, we know that IQueryable<T> inherits from IEnumerable<T>, so what happens if we avoid the list creation completely?

public IEnumerable<Cat> FindAllCats()
{
	var query = from c in db.Cats
		select c;

	return query;
}

In this scenario, our method is returning the same interface, but the underlying type is now a LINQ database iterator instead of a List<T>.

Delaying execution can lead to multiple executions

If the code is not explicitly putting the results into a list, we’re actually passing back a form of an iterator. This works great if we only need to execute the query once. However, if we iterate through the list more than once, we actually end up executing our query multiple times. This can obviously lead to poor performance.

If you’re writing fast queries, you may not even notice if they’re being called too many times. However, there may be a worse problem lurking in your code. Each time you iterate through the enumerator, you’re getting a different set of objects. The same query is being made with the same results, but the objects are re-built each time. This leads to objects that are equivalent, but not the same. For example, you may get back Cat objects with the names “Bill” and “Ted”, but if you actually check them for equality using “==”, they will not be the same object instance. Correction: Scott points out in the comments that this isn’t necessarily the case. Keep in mind that it can still occur if projecting types and not working with the original objects.

Delaying execution may mean you no longer have a database connection when attempting to execute the query

If you delegate the task of initiating your query to another layer, you better be sure that the database connection is still around, and is in a queryable state. If you’re using the standard repository pattern and a short-lived database connection pattern, you may quickly run into problems when you try to iterate through the results of the enumerator you receive from your repository layer.

Conclusion

If you’re thinking about moving the execution of your queries to another layer, make sure you understand the consequences. You’ll need to weigh those consequences against the tiny benefit that you’ll receive from the delayed execution. There may be cases where delaying the execution or possibly avoiding it completely will improve your application, but those are probably very rare cases.

Understand the terminology

First, UTC, GMT, and even Zulu time are all the same thing. They’re basically a universal time clock that is not subject to changes in time zones or time changes. Each tick of the universal clock represents a moment in our perception of time.

Use UTC as long as possible

UTC is very useful when developing software because it removes the need to know where the time was from, or where it’s going to be used. We don’t even care when it was from, or when we’re displaying it. You can think of your local clock as a view of the time right now, where you are. It has already taken into account the time zone and daylight savings time.

These properties of your local clock suggest that we should always convert from the local clock to universal time as early as possible when accepting user input, and convert it back to the users time only when displaying it. This is a simple, easy to use pattern that may be enough to avoid some of the potential problems that other projects face. This pattern will give you the ability to cope with time changes and time zones much more easily.

Converting between local time and UTC is pretty easy. ToLocalTime will convert from universal time to local time. ToUniversalTime will convert to UTC. Just be aware that these methods have a certain amount of logic in them that only has the rules that were in effect when they were written. They are not perfect for all scenarios. You’ll also want to take a look at the Kind property, which affects which conversions you can perform, as well as providing a nice way to keep track of whether or not he time has been adjusted to UTC.

Daylight Savings Time & Time Changes

Every year in many parts of the world, the time changes. Apparently the idea is to save gobs of money by using the sunlight more efficiently instead of using artificial lights. Unfortunately, this really sucks for software developers.

I used to write software for manufacturing facilities that would run during a time change. If you have software that records and time-sensitive data during a time change, your software had better be prepared to handle it the fact that one hour is skipped, and another is repeated. Storing the data in UTC solves part of the problem. Unfortunately, when you try to display the data you’ll have an hour of missing data, and a hour with overlapping data. You may have to design your user interface to deal with this.

Fixed-time Appointments

Unfortunately, UTC doesn’t solve all of our time offset problems. Let’s say that you have an appointment that you’re scheduling for a future date that occurs when DST is in effect, but it’s not in effect right now. You choose 5:00am for your appointment time. Your application happily converts the time to UTC, and the reverse process expectedly yields the same result. The problem is, the time offset when the appointment occurs will be different than it is now. Daylight savings for the central time zone for example, switches between and offset of –5 and –6. This diagram attempts to visualize:

What we want to store is the fact that our appointment occurs at 5:00am local time. If we simply store the information as UTC, we’re losing this additional information. When we switch to non-DST time and use our current time adjustment of –6 hours, our appointment now occurs at 4:00am.

If you’re writing an application that stores fixed-time appointments as well as appointments that are designed to have even intervals (exactly 1 month apart, etc) or occur in a different time zone or DST, you’ll need to store an additional flag with the event so you can make the determination if it needs to be adjusted.

Conclusion

Times can be complicated depending on the requirements of your project. It would be unwise to work these problems out toward the end of a project, because the consistency of usage can’t be guaranteed. Do yourself a favor and plan ahead for these issues, and it will be much easier.

In my college days, I had to give a presentation in one of my information systems classes. I was pretty arrogant back then (ok, I still am), so I thought it would be a piece of cake to just wing it. I could save time and look like a cool speaker all at the time time. The result was me getting in front of the class, having my face turn red, and basically say “uh” and “um” for 10 minutes. It was so bad that people actually began to laugh. It pains me to even write about it.

A semester later, I had to give another presentation to an even bigger class. I was so nervous I can’t even describe it. I spent hours upon hours making creating a “script” that I could simply read. The result was that I actually didn’t even use the script. I actually knew what the hell I was talking about and ended up using the script as a reference. I did a great job speaking!

So how do I prepare for presentations these days? I have detailed notes, formatted specifically for the presentation. On my slides, I always keep the number of bullet points per slide low, usually 4 or less. In my notes, I organize them by bullet point so that I can walk though them while I go over each bullet point. I try to balance simplify with detail. The notes have to be simple enough to read quickly, but detailed enough that I can just read them out loud if I lose focus and forget the purpose. Bolding keywords and phrases can help quickly identify the key concepts while still having a readable version if needed.

I’ve seen many presentations where the speaker gets nervous and forgets what a slide or bullet point means. The usual remedy they employ is just reading the slide verbatim. Don’t let this happen to you. It is almost certain that you’ll forget a critical piece of information during your presentation. The trick is to be ready for it.

In my most recent presentation (on Unit Testing), I actually wrote a paper on the topic I was presenting on. This allowed me to get all of my thoughts in order, and get feedback from others. Once I actually had to put together the PowerPoint, that was the easy part. I was basically creating an outline from an existing document, and the details became my notes.

Update: I updated the PDF location to one that doesn’t require registration.

There are some really great books out there about unit testing, but I think some of them are trying too hard to be long enough to be considered a “book”. I set out to create a document that fills the gap between the various snippets of information from blog posts, and the comprehensive books on the subject. If you’re interested in something a bit more in-depth, here are some great books on the subject:

• The Art of Unit Testing by Roy Osherove
• xUnit Test Patterns by Gerard Meszaros

The paper currently consists of 5 main sections:

• Why Write Unit Tests?
• Unit Test Mechanics
• Common Unit Testing Strategies
• Designing for Testability
• Advanced Techniques

Here is a more complete snapshot of the current outline:

• Introduction
• Unit Testing & Managers
• What Unit Tests Really Do
• Types of Testing
• Testing Framework
• Test Runner
• Unit Test Structure
• Other Test Attributes
• What is Refactoring?
• Test Driven Development
• Evolving Code
• When Should You Write Unit Tests?
• Test is for Functionality, Not Code!
• The Constraints of Reality
• Interfaces - Quick Overview
• Using a Mocking Framework
• Stubs
• The Test Driven Design Paradox
• Testing Under Pressure
• Extracting Duplicate Logic
• Modular Design Benefits

So what are you waiting for? Go check it out online instantly, you can even download it as a PDF if you like. Is anything missing? Is anything just plain wrong? I’d love to hear your feedback.

Remember, if you want to hear more about unit testing, I’ll be speaking in Northeast Wisconsin Saturday, May 9th.

Want to learn how to write good automated unit tests that are beneficial both to the product/customer and to you as a developer? See an overview of the mechanics of unit testing including the tools and frameworks available. You’ll see examples of how to test existing code, but you’ll also see practical examples of how seemingly un-testable code can be designed so that it can be tested with ease. Learn how test driven development and refactoring will improve the readability of your code, minimize debugging, and speed up development.

If you’re anywhere near the Northeast Wisconsin area, stop in. It’s free!

I’ll be publishing both the presentation and a supporting 25+ page paper shortly, so make sure you’re subscribed to my feed.

Fox Valley Tech is located at:
1825 N. Bluemound
Appleton, WI 54912

When I first heard that int ultimately derived from Object, I didn’t believe it for a number of reasons:

• If you inherit from Object, that derived object IS an object
• If int is a subclass of Object, then boxing isn’t necessary

The truth is, my assumptions were not correct. The .NET team, for consistency sake, made all types fit nicely into the type hierarchy:

If the .NET team had built System.Int32 to work like any other reference type, there would be clear performance issues. In reality, we need value types to be lean and mean. They are stored on the stack (instead of the heap for reference types). To do this, there is some internal “magic” going on that treats objects that inherit from ValueType differently. Behind the scenes it optimizes how they’re used to get the best of both worlds. If you try to inherit from ValueType, you’ll get a compiler error, because it is only exists for build-in value types.

Of course we want our cake and we want to eat it too. There are often times when you want to use a value type in a method that takes an object as a parameter. To keep up the illusion that a value type is an object, the framework employs boxing. It effectively wraps the value type inside of an object.

Take a look a the following code:

public string GetObjectString(object obj)
{
    return obj.ToString();
}

[TestMethod]
public void IntAsObject_Boxing()
{
    var str = GetObjectString(4);
    Assert.AreEqual("4", str);
}

And look at the corresponding IL for the test method:

IL_0001:  ldarg.0
IL_0002:  ldc.i4.4
IL_0003:  box        [mscorlib]System.Int32
IL_0008:  call       instance string _4_17_09_Boxing.UnitTest1::GetObjectString(object)
IL_000d:  stloc.0
IL_000e:  ldstr      "4"
IL_0013:  ldloc.0
IL_0014:  call       void [Microsoft.VisualStudio.QualityTools.UnitTestFramework]Microsoft.VisualStudio.TestTools.UnitTesting.Assert::AreEqual<string>(!!0, !!0)
IL_0019:  nop
IL_001a:  ret

Notice that boxing occurs on line 3. It’s using the IL “box” command to let you stay oblivious to the fact that there is some magic going on behind the scenes.

Conclusion

The end result is that we have an integer, which is an object, but isn’t really, that needs to be wrapped inside of an object, which shouldn’t be necessary, but is because it is.

Does this really matter? Well, not really. For the most part you don’t need to know this. If you’re truly inquisitive and want to know what’s going on, you may find it interesting.

IEnumerable vs IQueryable

First, you need to understand the purpose of IEnumerable and IQueryable. IEnumerable defines a stream of objects that can be retrieved sequentially. It’s implemented for nearly every type of list, and it’s an integral part of LINQ. There are now methods included such as “Where” and “Select” that let us filter, sort, and manipulate lists of data in interesting yet simple ways. This can also be referred to as LINQ to objects.

IQueryable inherits from IEnumerable, and is designed to be translatable into a query. IQueryable is typically used to build an expression tree that represents the requested operations. The operations are not actually executed until the expression tree is evaluated and used.

As an example, let’s say I have a database with a table and entities called DateRange. Suppose I cast the DateRange entityset (which implements IQueryable<DateRange>) as IEnumerable<DateRange>. When I call LINQ expressions on that IEnumerable, the underlying query is run immediately, which effectively causes all of the data from that table to be retrieved. If I use IQueryable without casting, my operations get turned into SQL that gets executed when I actually try to iterate through the data (probably using ToList() or foreach). It’s obviously preferable to have the query run in SQL since it can more efficiently filter the data.

The Problem

As I mentioned earlier, I recently starting writing a data access method that started to contain some non-trivial logic. Whenever I see logic, I want to be able to unit test it! I ended up pulling out the logic into its own static method. This method takes in IEnumerable<DateRange>, which can also accept IQueryable<DateRange> (because of the inheritance, you’ll recall). Then, I simply use the AsQueryable method in IEnumerable. This ends up building the needed expression tree that can be translated into a SQL query, but it also lets me test against an in memory collection.

public static DateRange FindRelativeToDate(IEnumerable<DateRange> enumerable, DateTime reference, int periodOffset)
{
	//Build as an expression tree, if possible, otherwise enumerate
	var queryable = enumerable.AsQueryable();

	//Now put in all the logic

	var reference2 = reference.AddDays(-1);

	var initialRange = from bp in queryable
		 where reference >= bp.Start && reference2 < bp.End
		 select bp;

	var currentDateRange = initialRange.First();

	if(periodOffset == 0)
		return currentDateRange;

	var newRange = from bp in queryable
		select bp;

	if (periodOffset > 0)
	{
		newRange = newRange.Where(x => x.Start >= currentDateRange.Start);
		newRange = newRange.OrderBy(x => x.Start);
	}
	else
	{
		newRange = newRange.Where(x => x.End <= currentDateRange.End);
		newRange = newRange.OrderByDescending(x => x.Start);
	}

	return newRange.Skip(Math.Abs(periodOffset)).Take(1).FirstOrDefault();
}

In my unit test class, I can define a list of sample data. I took real data from the database to make the tests as close to reality as possible:

private static readonly List<DateRange> _DateRanges = new List<DateRange>
{
	new DateRange {Start = new DateTime(2009, 1, 1), End = new DateTime(2009, 1, 30)},
					new DateRange {Start = new DateTime(2009, 1, 31), End = new DateTime(2009, 3, 01)},
					new DateRange {Start = new DateTime(2009, 3, 2), End = new DateTime(2009, 3, 31)},
					new DateRange {Start = new DateTime(2009, 4, 1), End = new DateTime(2009, 4, 30)},
};

Now, I can easily test the static class I wrote (this is 1 of 9+ real tests):

[TestMethod]
public void FindRelativeToDate_MiddleOfDateRange_ContainingDateRange()
{
	var result = DateRangeRepository.FindRelativeToDate(_DateRanges, new DateTime(2009, 3, 15), 0);
	Assert.AreEqual(_DateRanges[2], result);
}

The only thing that is left to do is wire up the repository method so that it calls my static method. This is a thin wrapper layer that will actually get used in production. If you run profiler, you’ll see that the query expression is being evaluated and converted into an efficient SQL expression.

public DateRange FindRelativeToDate(DateTime reference, int periodOffset)
{
	var ctx = dbEntities;
	return FindRelativeToDate(ctx.DateRangeSet, reference, periodOffset);
}

Limitations/Conclusion

Unfortunately, this method of testing a repository doesn’t scale easily. If you start working with multiple entity sets that are combined with join operations, this technique is next to impossible to use. You’ll see the most benefit when working with a single entity type, and need to test logic in your repository method.

One thing you need to be aware of, is that LINQ to SQL and Entity Framework don’t implement every IQueryable/IEnumerable method. This means that you could potentially make calls on the in-memory collection that will then fail when you use the actual database. Fortunately, these problems can usually be detected fairly quickly.

Fortunately, Visual Studio provides a hidden feature that lets you draw a vertical line in the text editor to show you where a certain line length would end. Fire up your registry editor and find this key:

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\Text Editor

If you’re using a version of Visual Studio before 2008, you’ll need to decrement the 9.0 version number in the path above.

Then, add the following value (as a string or REG_SZ) with the name of “Guides”:

RGB(192,192,192) 110

The first part is the color, and the second part is the line length. Personally, I use a line length of 110 to stay consistent with how Microsoft has chosen to do it. I like the color listed above because it’s faint, but visible. Since the line is almost impossible to see in the screenshot above, here is an un-scaled screenshot of the line itself:

To further enforce the 110 character limit, you could also resize the code portion of your Visual Studio window so that it’s near the line. This will make the line itself a little less annoying, while allowing you to use the rest of the window for other information. For example, take a look at how much room I have on a 1920×1200 screen when I horizontally resize my code window:

Obviously this tip isn’t for everyone. You may be working with legacy code with long lines, or you might work on a team that doesn’t mind long lines. The great news is that Visual Studio is pretty accommodating to however you like to work.

Back in the day, I bought one of the first Smartphone’s to be sold in the United States, the Kyocera 6035. It was basically a Palm device glued to a phone. It was pretty cool since I could use the same device to play Monopoly and make phone calls. After getting rid of this phone, it would be years before I would get another so called “Smartphone”.

Years later, I started getting into the Windows Mobile world (Pocket PC at the time). The Windows mobile platform is compelling because as a developer I can write applications using the .NET Compact Framework without a huge learning curve. It’s also one of the few platforms that works/worked great with Microsoft Exchange. My current carrier of choice, Sprint, also tends to have a great suite of Windows Mobile phones. I also like the fact that any hackable feature is just a registry edit away.

My current phone is an HTC Touch Diamond. On paper, this is currently one of the most amazing phones ever created. It’s one of the smallest Smartphone’s you can buy, yet it has a fast processor, VGA screen, excellent GPS, light sensor, stylus sensor, accelerometers, resistive & capacitive features, etc. However, in reality, this phone drives me crazy. Opera is a decent browser except that it takes too long to open, and doesn’t render as fast as it should on 3g. The push email features are pretty good except that the UI is a joke. Scrolling is not as smooth as it should be. Integration between apps is non-existent. The resistive screen isn’t optimal for finger use. The experience is just laughable. The list goes on. I assumed these were all unavoidable simply due to the fact that it’s a mobile platform.

Recently, I decided to try the iPod touch. It’s my understanding that it’s somewhat of a gateway drug to the iPhone. Essentially, it’s the same thing but without a phone, a real GPS, and a microphone.

After using this device for a while, I am consistently surprised how streamlined and painless it is to use. Nearly every function works without even thinking about it. Every motion is perfectly smooth. No configuration is too difficult.

At first I was skeptical about the main interface, which consists of one or more screens full of icons. There is really no organization, no folders. The beauty of this design is in its simplicity. You’re never more than one press away from the information you’re looking for. Weather, click. Headlines, click. Calendar, click. Email, click. Touch Flo 3d on my HTC phone is essentially lipstick on a pig. It looks cool, and kind of works well if you’re completely sober.

Now, let’s get to the real reason that the iPhone is an unstoppable force. They have an insane application ecosystem. Most of the applications are not worth the bytes they’re made of. However, a few of them are so simple, so elegant, and so efficient that they change the platform. For example, if I want to see what movies are in the theater, I can use the movie app. If I want TV listings, I use the TV app. If I want to find local events or lookup a number, I use the yellow pages app.

iPhone applications usually have similar functionality to what you get in your browser on your desktop or laptop computer, but they’re typically designed to do one thing, and do it well. If you were to download an application to your computer specifically for getting movie times, I’m sure the experience would be similar, but on the desktop platform it’s not quite worth it. I find myself using my iPod touch instead of my laptop to get a lot of quick information. I’ve also been opened up to a world of information that I normally would not have seen. For example, I have an application that shows me the local events in the area. I could have Googled for the same information, but this puts it all just a press away.

If you are someone that hasn’t given the iPhone platform a try, do yourself a favor and go spend $230 on the iPod Touch. Then, visit the app store and download some freebies. If you’re waiting for Windows Mobile or Android to catch up and build up the same application ecosystem, don’t hold your breath.

I’ve been so excited by this platform that I ordered myself a Mac Mini that should hopefully be showing up tomorrow :-). Stay tuned as I talk about the experience of a c# developer writing an iPhone app in Objective-C!

It may be difficult to see from the screenshot, but I’m looking at a standard ASP.NET page, but there is tracing information at the bottom. This tracing information is the same information you would see if you configured tracing your web.config, and then used the trace.axd page. However, we’re displaying it right along with the page request. To allow tracing to be enabled with a simple URL parameter, you can add the following code into your Global.asax file:

protected void Application_BeginRequest(object s, EventArgs e)
{
	if (Context.Request.QueryString["trace"] == "true")
		Context.Trace.IsEnabled = true;
}

Of course in a public environment, it may be wise to add security or at least obfuscate the parameter. The trace information contains server information that may be helpful to someone trying to compromise the server.

Now that we have tracing information, how can we get our log messages to show up? Log4net provides an appender for logging to the ASP.NET tracing feature:

<appender name="AspNetTraceAppender"
	type="log4net.Appender.AspNetTraceAppender" >
	<layout type="log4net.Layout.PatternLayout">
		<conversionPattern
			value="[Thread #%thread] %-5level - %message%newline" />
	</layout>
</appender>

Don’t forget to wire up the adapter so that log4net knows to use it:

<root>
	<level value="DEBUG" />
	<appender-ref ref="AspNetTraceAppender" />
</root>

Now, in your code, you can simply log messages as you normally would:

_log.Debug("Loading User Data");

Conclusion

I’ve found this type of configuration very useful in my ASP.NET applications. It lets me analyze how long each portion of the page generation is taking so that I can find bottlenecks. It also motivates me to write a fair amount of logging, since I’ll see a benefit during development, as well as after deploying it into the wild.