9 Comments

I’ve been tweaking the performance of BlogEngine.NEXT today using my favorite tool: YSlow for FireBug. One of the things YSlow checks for is the expires HTTP header for static content such as images, script files and style sheets. Since BlogEngine.NET has always used custom HTTP handlers for serving scripts and stylesheets, only the static images have been a problem.

The problem

The problem is that with images on hosted environments on IIS 6, it’s impossible to control the serving of them without redirecting them through an HTTP handler. That’s not a good idea for several reasons:

  • It adds unnecessary overhead by going through the ASP.NET ISAPI
  • You need to add custom code to handle the requests
  • You need to change the URL from .gif to .gif.axd or similar

Here is what YSlow finds on my website that needs the expires header set to a far future date:

As you can see, it is all my static images that lacks the expires header.

The solution

If you run IIS 6 there is no good way of adding an expires header to images unless you have control over the IIS. If your site is hosted then you probably have no control at all. If you are using IIS 7 however, you can very easily add the header in your web.config’s system.webServer section like so:

<staticContent>
 <clientCache httpExpires="Sun, 29 Mar 2020 00:00:00 GMT" cacheControlMode="UseExpires" />
</staticContent>

What happens is that all static content will now have an expires HTTP header set to the year 2020. Static content means anything that isn’t served through the ASP.NET engine such as images, script files and styles sheets. This is one of the very easy tricks that will increase the performance of your site as well as your YSlow score.

0 Comments

We’ve had a tradition of doing geek dinners in Copenhagen for the past 2 years. It’s always very good fun and there’s a bunch of interesting .NET guys to chat with. However, it has always been very intimate and most of the people going have been there before.

We need new blood and that’s why it’s time to take the geek dinner concept to the next level and the name is .NETworking dinner. The basic concept remains the same but in a much larger scale. It’s still an informal dinner arrangement with free beer, but this time I’m aiming for at least 50 people. This is important from a networking perspective.

The point is to meet a lot of new people in a relaxed atmosphere and talk about coding, business or just plain fun. Hopefully, that will help strengthen the Copenhagen .NET community and open up new opportunities.

Since numbers are important, please tell your colleagues and friends about this event and sign up to the event on Facebook. It’s Tuesday, April 21st after normal work hours and it's free.

0 Comments

I’ve been a little quiet on my blog lately. That is due to my grand plan for 2009 which was born as my New Year’s resolution. The original plan went like this:

In average, I need to visit a new country I have never visited before, every month of 2009.

That means 12 trips to a new destination for the entire year. I soon realized this was too ambitious, expensive and time consuming. I needed to adjust the plan to something more realistic and this is what I came up with:

In average, I need to visit a new country that I may have visited before, every month of 2009.

So, still 12 different destinations but it is now ok for me to visit countries I’ve seen before. So far it is going quite well. Here is my itinerary for 2009 as it looks right now.

  • January: Germany
  • February: England and Moldova*
  • March: USA
  • April: Spain, Gibraltar* and Portugal*
  • May: Scotland*
  • June: Holland*
  • July: Greece* and Albania*
  • September: Turkey*
  • December: Egypt*

* = have never visited before

These trips have been a mix of business and pleasure. Whenever I go on business trips, I always try to find time to explore the place I visit. Lately I’ve fallen for the idea of visiting the countries along the old silky way including Azerbaijan, Kirgizstan, Georgia, Armenia and a few more. I hope to find the time to spend some time there in the fall. Also, I’ve never been in Asia or Oceania so that’s also very high on my wish list.

Often times when travelling, I don't have access to a PC so I don't read or write many blog posts. Instead I tweet from my mobile phone just to keep a little up to date with the news in tech world.

0 Comments

I’ve read a lot of posts and articles about why and when you should choose WebForms or the MVC framework to build your ASP.NET websites. They are all pretty good, but for some reason they forget or ignore the obvious third option - standard ASP.NET without the WebForm.

Let’s call standard ASP.NET without a WebForm for ZeroForm. Basically, the ZeroForm approach is to use ASP.NET like you always have but without a <form runat="server"> element. I consider the ZeroForm as an excellent compromise between WebForms and MVC.

Server- and user controls

There are some immediate drawbacks from regular ASP.NET WebForms by not using the <form runat="server"> tag. A lot of the regular server controls like the TextBox, DropDownList and all the validators will not work. Other controls like the Repeater, PlaceHolder, custom user controls and all HtmlControls like <div runat="server"> will work as normal. Where WebForms support all the controls and the MVC framework none, this can be considered a good compromise.

ViewState and HTML markup

By getting rid of the WebForm, you are now in (almost) complete control of your markup. No ViewState, WebResource.axd’s and embedded JavaScript are injected in your pages anymore. The only thing that remains out of our control is the rendered ID’s of HTML elements. If you nest server- or user controls you still cannot control that until the release of .NET 4.0. Again, a fair compromise.

Pretty URLs

The MVC framework has a very cool way of creating pretty URLs using the new routing engine in .NET 3.5 SP1. You can use the routing engine with your WebForms and ZeroForms, but it isn’t really as fluent as in a MVC application. But hang on; URL rewriting has always been possible in ASP.NET so you could get the same pretty URLs by using ZeroForms. It does take some extra work but people have been doing it for years using various libraries or their own implementations. This is not a compromise, but the notion of that it's possible on both frameworks.

Separation of concerns

The MVC framework is the champ in separating concerns in your web application. No question about it. A lot of articles explain this very well, so I will not go into details. What haven’t been well explained is that by using the ZeroForm you can also separate a whole lot. Keep your model (custom objects) separate from the code-behind and your .aspx’s and .ascx’s as dumb as possible by leaving the code-behind to deal with data using utility classes or helpers that can be tested. This is nothing near the separation the MVC framework offers, but it is a good compromise.

This post is not meant to bash either WebForms or the MVC framework, but to offer an alternate view for your consideration. I’m a huge fan of WebForms, ZeroForms and the MVC framework and I use them all for different types of projects respectively.

An example of a website using the ZeroForm approach is ifjernsyn.dk (in Danish).