September 26th, 2011

Like everyone, we never want our site to go down.  Some pages display data and if something happens to the database we’d like at the very least to display old data instead of an error.  In that vain I wrote a proof of concept that might help.  This is not live and may never go live but it tests well and I thought it was interesting enough to post.

The implementation is based on two interconnected pieces – an OutputCacheProvider and an HttpModule.  The OutputCacheProvider, like the built in output cache provider, is responsible for storing and retrieving cached pages.  In addition, however, it keeps cached pages around past their expiration in case the need arises to render them.  The HttpModule’s responsibility is to handle exceptions and by writing out cached versions of the page regardless of their age.

The sourcecode is available at on github but I’ll step through the initial check version of the code here to better explain what’s going on. ### GracefulDegradationOutputCacheProvider

This is just a standard OutputCacheProvider (OutputCacheProviders were introduced with ASP.NET 4.0.  Check out for more info).  The interesting piece to note though is that the standard Get method implemented for OutputCacheProvider just calls another Get method that takes a boolean parameter called respectExpiration.  The “standard” Get method just passes in true for this.  Here’s the code:

August 7th, 2011

Based on this article on MSDN I decided to code the data layer for an app in F#.  After a few weeks of hobby time coding, I don’t believe that EF via F# is a viable solution yet.  Here’s why:

NOTE: Windows Live Writer is crashing constantly on me.  I’ve got 2 reasons so far and may update this post with more when Live Writer starts behaving (going to restart at some point this week I suppose) or I find a more stable editor. #### 1. No protected keyword

Because the Entity Framework’s proxy classes inherit from their base classes (and because they do not support setting private properties of their ancestors), the protected keyword becomes especially important.  Protected becomes a way of creating properties that can be set only by the class itself and by Entity Framework’s proxy classes.  I’m especially fond of this in constructors.  Take the following code snippet:

July 28th, 2011

I posted a question to StackOverflow yesterday ( and will describe the issue and resolution in this post. <!--more-->

May 6th, 2011

I get the following error on build intermittently: <!--more-->

Error 52 It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level.  This error can be caused by a virtual directory not being configured as an application in IIS. C:\Work\…\web.config 98 Frontend

I get it infrequently enough that I never remember the fix for it.  I always Google it and come up with the same links – they all imply it’s because of a problem with some configuration.  For me it’s not a configuration problem.  If I delete the \obj directory and rebuild that fixes it.  Go figure.

April 29th, 2011

The next language I’ll be learning will be F#.  I just started and have already written my first stack overflow!  But it taught me a lesson about the order of precedents in F#.

I was writing my first real function, one that wasn’t pre-written in the tutorials I was using (at least not that I got up to yet!): Fibonacci.  I started with

April 13th, 2011

I attended a session at MIX11 entitled Windows Azure from Startup to Scale ( which was presented by the makers of  While explaining the problem which his company solves (and forgetting to actually speak about any technical details!), the presenter mentioned some issues with checking job applicant's’ Facebook and other social media pages.  From an employer’s perspective, there are some liabilities with checking these services since a potential employee’s ethnicity and sex are visible and obviously it would be inappropriate to make any sort of decisions based on that information.

From the potential employee perspective, however, I actually think this ‘liability’ is a good thing I’d like to share some thoughts.  You’re certainly welcome to disagree and I welcome discussion. 

I gave a .NET class about a year ago and there was a religious Jew there who was looking for a job and asked me for some suggestions.  When I recommended building an online brand he expressed similar concerns as the presenter; he worried that if he posted a picture of himself that some employers might hold his religious beliefs and behavior against him.

As anyone who knows me already knows, and if you don’t know me you could probably figure out from my blog picture, I’m a religious Jew.  I don’t shave or trim my beard.  I wear a yarmulke ( on on) my head and I don’t shake hands with women (  I eat only Kosher food and leave work early on Friday in the winter to make it home in time for the Sabbath (though I make sure to get the necessary work done Saturday night or Sunday).  So I look and act somewhat different than many other professionals and I suppose that some companies might look down on that.  However, I still explicitly post my photo my blog, twitter, and LinkedIn account.

I do this for a few reasons; here’s what is what I told the individual who took my class.  First, I’m proud of who I am.  But more importantly from a professional perspective, I want prospective employers to know who I am regardless of (or even because of) what they may think of me (note: I am not currently looking for a job).  For one, my picture is memorable – this helps build my brand.  I have the same picture across all my branding outlets (and I used to have it on my business card too) so it’s very easy to remember me.  And frankly, I only want to work for employers that want me to work for them.  If an employer doesn’t like me for who I am, why should I wait until I step in the door and take time out of my day for an interview?  I want to weed them out from the start.

March 9th, 2011

Today’s lesson learned: if a property may or may not be computed, provide a mechanism that allows consumers to check if it is computed.  Seems pretty simple when you hear it but we don’t always design like this.  And I think we probably should most of the time.  I came to this conclusion based on the following problem:

My project has a lot of similarities to a shopping cart.  Imagine a product catalog with both a Product and a SubProduct (only one level deep).  Both a Product and SubProduct have a price but price is only required on a Product, not a SubProduct.  If a price is null on a SubProduct, it just inherits its parent Product’s price.  And if the Product price is updated, the SubProduct’s price automatically takes note:

January 26th, 2011

I posed a question a while ago on stackoverflow ( about how to map a computed property in Entity Framework 4.  I didn’t get any answers so I figured I’d post what I came up with.

January 7th, 2011

There’s somewhat of a pattern in the Linq supported ORM world to create extension methods for filtering.  I’m working on a project right now that uses this pattern.  If you’re not familiar with it, the pattern basically works by creating extension methods for IQueryable that return IQueryable like this:

December 27th, 2010

I’ve heard a lot of people bash Entity Framework for being incomplete.  I happen to think that EF4 is pretty good for a first version.  It’s just too bad it’s a second.  Especially considering there’s plenty of mature ORMs from which Microsoft could take some more hints.

I’m using EF4 code-first which should be a lot like other ORMs out there like, for example, NHibernate (which I used in many previous projects).  NHibernate supports hydration of data into fields.  EF4 can only hydrate properties.  This is more annoying than it may sound.  For example, take the following code snippet: