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.

As I mentioned, extension methods were a new feature in .NET 3.0, and they’re compatible with the 2.0 CLR. They’re backwards compatible because they’re simply a compiler trick. In fact, you may already have methods that are only one step away from being considered extension methods.

Here is a method that is not an extension method (we’ll come back to those in a bit):

public static Report GenerateReport(ReportData data)
{
	//Create a report from the report data
}

A method like this is useful because it avoids cluttering another class with unrelated functionality. Imagine the opposite situation in which case the report data class is responsible for the data in the report, as well as the formatting of the report. The single responsibility principle tells us that we should separate the operations so that each class has only one reason to change. In practice, I have personally seen the advantages in code maintainability, readability, and testability. I won’t delve deeply into the supporting information in this post.

So how do extension methods come into play? As I mentioned, they’re simply a compiler trick. If we wanted to convert the aforementioned static method into an extension method, we simply add the “this” keyword before the first parameter, which is the type that our method is acting on:

public static Report GenerateReport(this ReportData data)
{
	//Create a report from the report data
}

Now we’ve added an additional way to call our method:

var reportData = new ReportData();

//Old way of calling - still works in either case
var r = GenerateReport(reportData);
//New way of calling with extension method
var r = reportData.GenerateReport();

Our method still works the way it always did when it was static, but now we have an additional way to call it. It’s also important to note that the extension method doesn’t have any extra permissions in regards to accessing the other class. It has to use its publicly exposed interface. In fact, if we wanted to rely simply on the interface instead of the implementation, we could modify our extension data to work on an interface such as IReportData.

The entire reason that extension methods exist is to make the calling syntax easier to read. The driving force was the new LINQ functionality. In particular, chaining the old static method syntax quickly becomes cumbersome.

The new extension method syntax allows us to make the calling code more elegant, and yet organize our methods so that there are clear boundaries between the pieces of functionality that we’re wiring together. Extension methods are obviously not always the best way to follow SRP, but they certainly give you a new tool in your toolbox.

First, lets look at how a regular overloaded method signature is matched. Consider the following methods:

public void a(object obj)
{}

public void a(IEnumerable enumerable)
{}

If we call the method “a” with a class that implements IEnumerable such as an array or a List, the second version will be called. Basically, the compiler matches the method that is the most specific.

Now, consider the generic versions of the same methods:

public void a<T>(T obj)
{}

public void a<T>(IEnumerable<T> enumerable)
{}

Now, if we pass in a generic list such as “List<string>”, you might expect the second version to be called. Unfortunately, you would be wrong. The first version of the method is called. There are two ways to force the second version to be used:

a((IEnumerable<string>)new List<string>());
a<string>(new List<string>());

As you can see, you can either cast the generic list specifically to a generic IEnumerable, or you can specify the type parameter on the generic method.

What you’re seeing is a subtle difference in the way method overloading is handled with generic methods vs non-generic methods. Standard method overloading picks the match at compile time, and chooses the most specific, or “best” match. When you don’t specify a type parameter for a generic call, it type inference to determine the correct signature to call. Unfortunately, it chooses the most direct route, not the most specific match.

Workarounds

I’ve already mentioned the ways that you can work around this issue by modifying the way that you make the call to the generic method. Unfortunately, you’re relying on knowledge that the caller must have. If you want to avoid ambiguity, do not use standard method overloading. You can see that the authors of Linq to SQL must have ran into the same issue. Take a look at “InsertOnSubmit” vs “InsertAllOnSubmit“. If it was easy to use method overloading for that scenario, that would have been a great opportunity for simplification.

Conclusion

I recommend being very careful when overloading generic methods. There are a lot of hidden side-effects that can occur. I also recommend checking out another post, which talks about the effects of overloading non-generic methods with generic methods. Don’t be ambiguous when writing code that other developers may call. Make your code easy to use, but also clear as to which code path will be taken.

<asp:ContentPlaceHolder runat="server" ID="AfterScripts">
</asp:ContentPlaceHolder>

In the page, I have the content defined:

<asp:Content runat="server" ID="conTrackingScripts" ContentPlaceHolderID="AfterScripts">
    <!-- Blah -->
</asp:Content>

Unfortunately, this code does not work:

conTrackingScripts.Visible = false;

The error given is "The name ‘conTrackingScripts’ does not exist in the current context. A quick Google search shows that many others have had the same issue. The solution is to use the following code instead:

(Master as MasterPage).FindControl("AfterScripts").Visible = false;

Substitute the name of your master page for "MasterPage", and the name of your ContentPlaceHolder for "AfterScripts" in the above code

It appears that you cannot edit properties on the content, you have to edit the ContentPlaceHolder directly.

"Does .NET/IIS output caching vary by user-agent?"

Good question Shawn! By default, the output cache stores the same version of the page for all users, regardless of their user agent. To change this behavior, add the VaryByHeader parameter to your OutputCache declaration:

<%@ OutputCache Duration="60" VaryByParam="*" VaryByHeader="User-Agent"  %>

This is probably a good idea to include in your OutputCache directive, because ASP.NET will render controls differently to some browsers. It modify the output HTML based on the browsers capabilities.

If your site is only targeting the latest generation of browser, you can probably avoid varying by user agent.

One last note. You can include multiple headers in the VaryByHeader parameter. Simply separate them with semi-colons.

For more information about OutputCaching, this is a great article.

I was sort of banking on the fact that I could use the Ext2 installable file system for Windows to read one of the drives in the array. For some reason, it was unable to read the disk. I had assumed that since the drives were simply mirrors of each other, it would be able to read one by itself. I was wrong.

My solution was to create an Ubuntu Desktop virtual machine, and use it to mount the physical partition. I was then able to copy the files over the virtual network adapter.

If you’re boss is gauging your performance based on the amount of time your butt is in your chair, you have a BIG problem. He obviously doesn’t have a good understanding of what it is that you do. Obviously the short term solution is to figure out how to keep your butt in the chair longer for appearances. For example, come in earlier and catch up on the latest tech news. You may have been doing this at home, but why not get credit for it? The extra time you put in is also great for “playing” with the tools you use. It’s a good time to find out the most efficient ways to use them, so that you don’t have to get out of the zone when you’re working on something important.

Of course the long term solution is to change your bosses perception. Here are a few ways to do this:

• Let your boss share your pain. When you are running into hard problems, make sure he is aware of it. It might seem a little cruel, but if you don’t do it, he might not understand why you spent a week on something and have nothing to show for it.
• If you’re excited about something, tell your boss about it. He might just get excited about it too.
• In small talk situations with your boss, that’s a good time to give an update, but keep it short.
• In software development, there are changes that the average person would think are very easy. Your boss needs to be aware of when situations like that arise.
• Email weekly status reports to the tem. If you’re busy, this can be a good place to put some of the above suggestions instead of talking face to face. Your boss will appreciate your enthusiasm, especially if this is something that is not normally expected of you. It also serves as a good project history for him, yourself, and the rest of the team.

Also understand that your boss may need to report your progress to his boss. Be mindful of that, and try to boil down some of the information so that it can simply be repeated instead of being interpreted. Remember that anyone in the chain of command up to the President are interested in what you’re working on. The higher up you go, the more summarized the information needs to be. If you have opportunities to speak with them, you always want to be seen as passionate and motivated. It could very well affect a decision that they’ll have to make one day.