I recently spoke to some of the wonderful guys on the ASP.NET team over at Microsoft (@shanselman @haacked and others). Somebody asked if anyone had any complaints they wanted to share. I brought up the topic of Silverlight since it’s been on my mind recently.

I would like to make it clear that the product we built with it is still amazing, and Silverlight has a lot to do with that. Silverlight is a solid product that has reflected the amount of effort that the developers put into it.

When I was originally confronted with the decision of building our user interface in Silverlight or HTML, I chose Silverlight for the following reasons:

• It’s the cool thing to do
• Perceived fast development
• User interface performance without having to touch “icky” JavaScript

Now that the first commercially available version of our software is available, I can’t help but admit some regret with the choice to use Silverlight.

The bottom line for me comes down to the fact that HTML runs everywhere, and Silverlight runs some places.

It’s becoming abundantly clear that the future of computing is in a wide variety of form factors, and they’re getting smaller. iPads, tablets/slates, iPhones, Android Phones, Microsoft phones, etc. are all widely available. Even Microsoft’s own Windows CE devices don’t support the Silverlight we know and love. These new types of mobile devices are showing us that the future it not just staring at a 19” screen. Our own Silverlight front-end is not only un-optimized for these devices, but worse yet, it doesn’t work, period.

So is the HTML story better? I believe it is. Let’s examine my original reasons for going to Silverlight:

• It’s the cool thing to do – I believe this gap is closing. jQuery and other animation and scripting tools are making cross platform development reliable and easy to develop. The proliferation of web standards has been helpful as well.
• Perceived fast development – My mistake here was thinking that since we didn’t have to deal with HTML, CSS, and JavaScript issues, we would be able to develop much quicker. The reality is that the time we would have spent on those issues is now spent dealing with another layer of misdirection. We now have to get the data from our database to the web server, but then we have to get it to the client. This is all while managing the subtleties of RIA services and LINQ to SQL objects. ASP.NET MVC removes one layer of mapping and complexity (we can optionally add layers obviously).

  On notable exception to this is our scheduling interface. We’re using the wonderful Telerik scheduler, which really shows when Silverlight can shine compared to an equivalent HTML page.

• User interface performance – Silverlight wins this one. We’re doing some amazing things with layout transforms that really wows our customers. The easy animations will be about the same amount of work in JavaScript, but the more complex animations will likely be easier in Silverlight.

Most of my reasons make common scenarios a wash (or possibly in favor of Silverlight). However, there are reasons that I’m avoiding Silverlight going forward:

• It doesn’t run well on Linux, CE, iPad, etc – This is huge. Unless you have a captive audience, you’ll want to make sure that your application runs on the newest devices. HTML is the only sure bet.
• Memory leaks/issues – This one really irks me. I’m sure that there are issues in our code that cause some leaks, and I’m sure some can be attributed to this seemly unsolvable issue. We have a screen that stays open on a touchscreen, and it consumes all the memory on the machine within half a day. The bottom line is that these simply don’t happen in HTML.
• Initial load hit – I know there are ways to mitigate this in Silverlight by spreading your application over multiple XAP files. However, HTML is the better choice for slow connections. The slow speed is spread throughout the screens, instead of switching between fast and slow.

In conclusion, all of the amazing reasons that I went with Silverlight have faded, and now I’m left with the reality of a platform that will never achieve 100% accessibility. There are plenty of situations where Silverlight may be the perfect fit, but next time I wont be as quick to lean toward Silverlight without serious consideration as to the potential audience and goals.

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.