Learn from my mistakes, you don't have time to make them yourself

I was asked recently about caching expiration policies in response to my rant in my Caching should not be the source of truth post and a comment I made in a post by Chris Blankenship. I have written an article about cache expiration policies which you can find here. It discusses the high level concepts in expiration polices and some suggestions about which options to pick. It makes references to HttpRuntime.Cache and the Caching Application Block in EntLib.

This article aims to provide an overview about caching expiration policies and how they can be used. While the concepts are technology agnostic, the article references the System.Web.Caching.Cache exposed from HttpRuntime for code examples and also some references to the Caching Application Block in EntLib.

What is a cache expiration policy?

A cache expiration policy is a combination of concepts which define when a cache entry expires. Once a cache entry has expired, it may be removed from a cache. The policy is typically assigned when data is added to the cache and is normally custom to a single cached entry based on characteristics of the entry.

In the article, Peter addresses two of the common reasons that cause people to not use caching. These are data being stale and losing data. There is some good advice regarding stale data. People need to determine the volatility of their data to decide on cache expiration policies. There are also some notification services that can be used to flush the cache when data stores are updated.

The article then discusses issues about losing data. This is where I don’t like the guidance provided. What I can’t agree with in the article is the concept of having the cache as the source of truth of the application data. The article promotes the idea of keeping application data in the cache (usually in memory) when it is created or updated and only providing that information to the back-end data store when the item is removed from the cache.

I have done it again. In order to work on a particular project, I have been sidetracked into writing a utility to help me continue with what I am actually trying to do. In my defense, I did look around the net for an application that would do what I needed so I didn’t have to write it, but no application seemed appropriate.

In essence, I need an application to resolve all the links internal to a website and check their status. This will give me an initial view of the state of the site. I then want to take all of those links and replay the analysis of those resolved links using a different base address. The reason I am doing this is because I am looking at migrating my Community Server based blog to use BlogEngine.Net instead. As part of that migration, I want to maintain as much of the Community Server url formats as possible so I don’t lose my existing audience.

I read the Visual Studio Tip: Disable F1! post a few weeks ago and was very tempted to take the advice to remove the F1 keyboard mapping in Visual Studio. I kept it because sometimes I do actually want to open help. The problem is I keep missing ESC and hitting F1.

I’ve finally cracked. It is just too annoying, especially when you haven’t opened help yet and it takes a long time to come up. I’ve got a different take on the solution though. Because I still want access to help, rather than removing the F1 keyboard mapping, I’ve changed it to F1, F1. A double tap on the F1 key is much more deliberate.

Kudos to Andrew Stevenson who inadvertently provided the title to this blog in his comment in the above mentioned post.

I really don’t know what to think about this. I definitely don’t like the phrase “free for download” because it can be very misleading. James Moore has been more explicit in other posts by saying that existing functionality will remain free for download and use. I’m supportive of this move if this is the case and I hope that Red Gate can add value to this product. While it is one of the best .Net tools around, it isn’t perfect.

I think this brings great risk to Red Gate. Any serious developer has Reflector as their #1 tool and I am confident that the percentage of good developers out there is substantial. It will be really bad publicity for Red Gate if they tick off that number of people in the industry. Everyone wins if they make the right moves though.

On that point, Red Gate is spending the next couple of months asking the community about what they should do with Reflector. Want to be heard by Red Gate? Flood the forum and let them know how you want this to play out.

I hope that Lutz was well paid for this product. He deserves every cent for how he had supported the industry for so many years.

There are several issues that can prevent trace data being written. Here are a few of that you might encounter.

TraceSource names

If using TraceSource, the name provided to the TraceSource constructor is case sensitive. If the string doesn’t match your configuration exactly, a default TraceSource instance is created rather than the configured one you were expecting.

TextWriterTraceListener

The yield statement is one of those C# statements that is really powerful but is either not understood or is unknown to most developers. Raymond Chen just posted a very good write up on how the compiler deals with the yield statement.

The great feature that the yield statement brings is delayed execution in iterations. If building a collection of items to iterate through is an expensive operation on either performance or memory, getting individual items as they are requested may be a better design. Using the yield statement means that this is really easy to achieve.