Recently, while doing a performance pass through a Sitefinity 4 application, I noticed that a public facing page had an unusually slow load time. Of course, the first thing I did was open up Firebug to see where the time was being spent. To my surprise, the majority of the time was spent waiting for the initial response from the server. After a little digging, I narrowed down the time-sink to a custom widget that pulled images from a Sitefinity image album. In particular, the query to figure out which images to display was the source of slothness.

Nerd service announcement:

If you played video games in the 80s and/or 90s and have never heard of, or watched Matt Chat, you you are in for a treat. One of my friends aptly described it as, “Behind the Music for vintage video games.”

This post is an attempt to capture how my previous team dealt with dependency / package management. The team, at its largest point, consisted of about 15 developers. There were roughly 200 3rd party dlls, and roughly 150 internal dlls in the dependency mix. No single app needed all 350 dlls, but groups of these dlls were common to applications in the same domain space of the enterprise. 3rd party dlls were things such as the MS Enterprise Library, image conversion libraries, desktop scanner interop libraries, etc… Internal dlls were things such as common utility libraries, WCF service contracts, DTOs etc…

This week, I decided to install the newly released Web Deploy 2.0 on my machine at work. I already had Web Deploy 1 on my machine, so I decided to uninstall that first before installing 2.0. After the installation I begain getting the following error when trying to execute VS2010 created web deployment packages from the command line:

Here are my initial thoughts after reading: Programming is not a Craft

If you want to use GVim as your Ruby editor in Ubuntu (and most likely any other Gnome based distro), you’ve probably found out that your .bashrc file is not read when launching GVim from the Gnome menu. This means that your RVM paths are not available in the scope of apps launched from the menu. However, when launching apps from the menu, the launcher can access your .profile file. That being the case, here is a quick work-around for this issue:

In my last WPF related post I spoke a bit about my WPF learning experience. I was fortunate enough to have an MSDN Universal subscription and any book I wanted via my employer as I went down the path. Unexpectedly, I recently received an email from a reader who wanted to learn WPF on a budget of $0.00. After thinking for a bit, I came to the conclusion that WPF can be learned without spending any money (assuming you have a computer that can run the tools). Below is a roadmap on how to do so.

We’ve all worked on projects where the codebase is a mess. Here are a couple of common messy codebase analogies I’ve heard over the years:

One of the things I see over-and-over-again when reading about teams that are deciding if they should adopt WPF or not is the fear of the learning curve, and the worry that they will not be productive for a huge period of time. Given that I’ve recently become productive in WPF myself, I thought I would talk about my experience in this area.

Should .NET auto properties be unit tested? It is very easy to argue that testing auto properties falls into the “testing the .NET framework” smell and is a waste of time. However, experience has shown me otherwise. This is something that I’ve gone back and forth on many times since auto properties were introduced. For the time being, I think I’ve reached a conclusion. That conclusion is yes.