Will Beattie's Blog

  In my previous post I showed how you can very easily add Caching to your application by using Castle Windsor. The example used was a very basic implementation and whilst it can be useful for a large number of cases it didn’t cover the all important cache invalidation. In this post I hope to explain how with a bit of convention over configuration how you can invalidate your cache when an object changes. In the last post I was using the Method name combined with the arguments to build the cache key. Now to allow us to build a cache key that can be used when invalidating the cache the key needs to be related to the Result type. For this I’m going to create a simple interface called IAmCacheable to identify the object we want to cache. public interface IAmCacheable { object Key { get ; } } And make sure the object we want to cache implements this interface. public class Product : IAmCacheable { public object Key { get ; } ...

  This post assumes knowledge of Dependency Injection and AOP. AOP or Aspect-Oriented Programming is a very powerful way to add Cross-Cutting concerns to a system without impacting the core code base. Cross-Cutting concerns can cover non-functional requirements and also functional requirements. There are generally three approaches when implementing AOP. 1. Generate Dynamic Proxies at runtime to intercept method calls Spring .NET Castle Windsor 2. Post-Compilation Assembly Transformation Post Sharp 3. Attributes Just using Plain Old Attributes I really really don’t like annotating classes & members with Attributes so for me Dynamic Proxies is the only option and the performance hit is worth the productivity gains. The very common example of AOP is Logging. Logging is by all accounts a Cross-Cutting concern and so lends itself very well to the example. However I tend to think of Caching as a Cross-Cutting concern and really hate to see...

This post maybe a little off the usual thread of my usual Technical posts but I feel it has to be said. Since moving to Singapore and trying to build a development team I have found myself inundated with resumes, in the last 6 months alone I have probably read in excess of 500 resumes and interviewed less than 5% of that number and thought I would share some tips for any hopeful developers. Most of this should be common sense, but the funny thing about common sense is that it’s not so common. 1. Prepare Research the company before going for an interview. If you know who’s interviewing you then Google them and see what they’re about. This can help give you an idea of the types of questions you will get in the interview. There’s no excuse for not even having a basic idea of what the companies core business is. 2. Acronyms != Interesting Resume There are no prizes for the most acronyms you list. As a rule only list those that you are able to discuss in detail for two m...