Justin Etheredge over at CodeThinked is asking for tips for technical presentations. I can certainly relate to his experiences. Technical presentations, or any type of presentation for that matter, can be intimidating, difficult, and scary.

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.

Extension methods were a new feature in .NET 3.0 (they are also supported by the 2.0 CLR). The single responsibility principle (SRP) is a strategy for structuring our code to make it more maintainable and testable. In this post, I’m going to discuss how we can use extension methods to make our code easier to read and satisfy the idea behind SRP.

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.

Recently I ran into a very unexpected behavior when working with an overloaded generic method. Basically, the selection process for overloaded versions of generic methods is different than their non-generic counterparts.

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.

In my master page, I have a ContentPlaceHolder defined:

<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.

I received this question from ObiShawn:

"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.