Andrew Stopford's Weblog

JQuery and Microsoft, some thoughts.

I noted this last night from Scott Hanslemans twitter messages and Scott Gu's blog post, it makes a lot of sense that a popular javascript lib have VS support and be included in the MVC framework. What caught my attention the most however was these parts from Scott Gu's announcement.

I'm excited today to announce that Microsoft will be shipping jQuery with Visual Studio going forward.  We will distribute the jQuery JavaScript library as-is, and will not be forking or changing the source from the main jQuery branch.  The files will continue to use and ship under the existing jQuery MIT license.

The jQuery intellisense annotation support will be available as a free web-download in a few weeks (and will work great with VS 2008 SP1 and the free Visual Web Developer 2008 Express SP1).  The new ASP.NET MVC download will also distribute it, and add the jQuery library by default to all new projects.

We will also extend Microsoft product support to jQuery beginning later this year, which will enable developers and enterprises to call and open jQuery support cases 24x7 with Microsoft PSS.

The implications for this are pretty big, while Microsoft don't have retail product that competes with JQuery they still sending patches to an OSS project, shipping an OSS project and supporting an OSS project. If the license fits then Microsoft could look at integrating with other OSS projects, it will be interesting to watch.

VSTS Rosario Team Lab

While running through the PDC 08 sessions I spotted this session

Microsoft Visual Studio Team System: Leveraging Virtualization to Improve Code Quality with Team Lab 

Would you like to test fixes in a production-like environment before checking them in to source control? The Visual Studio Team System (code name "Rosario") release of Team Lab improves productivity and quality while reducing the cost of building and testing world class products. Learn how Team Lab provides a fast and easy way to create a test environment and tear it down, target specific test environments, and take snapshots of an environment for easy deployment.

VibrantInk for tired eyes

I've been using a black color scheme in VS ever since Rob released his VibrantInk scheme. Lately however I've been suffering with tired eyes after hours of looking at the screen and decided that I need to make some changes. Beyond the screen flicker rate I also adjusted the scheme as follows

• Changed font size to 13pt
• Changed plain text background to RBG (454545) and foreground to RGB (235235235)

My aim here was to tone down any glare in the colors to something of a softer tone. The larger font size is also stopping me squinting.

Yeah I likely need an eye test but these changes are working.

Caching and SRP pt2

In the comments of the previous example Petar suggested a refactroring to reduce the coupling between object using the cache and the cache it's self, he proposed using generics and it works just fine in the IOC, let's take a look. Starting with the interface

   1:  public interface ICache<T>

   2:  {

   3:    void Add(T res, string key);

   4:    T Get(string key);

   5:     void Remove(string key);

   6:  }

now the cache class

   1:  public class Velocity<T> : ICache<T>

   2:      {

   3:          private const string CACHE = "MyCache";

   4:          

   5:          public void Add(T res, string key)

   6:          {

   7:              var CacheCluster1 = new CacheFactory();

   8:              var Cache1 = CacheCluster1.GetCache(CACHE);

   9:              Cache1.Add(key, res);

  10:          }

  11:   

  12:          public T Get(string key)

  13:          {

  14:              var CacheCluster1 = new CacheFactory();

  15:              var Cache1 = CacheCluster1.GetCache(CACHE);

  16:   

  17:              return (T) Cache1.Get(key);

  18:          }

  19:   

  20:          public void Remove(string key)

  21:          {

  22:              var CacheCluster1 = new CacheFactory();

  23:              var Cache1 = CacheCluster1.GetCache(CACHE);

  24:   

  25:              Cache1.Remove(key);

  26:          }

  27:      }

The object using the cache now looks like the following.

   1:  public class BasketActions

   2:  {

   3:    private ICache<Basket> _cache;

   4:   

   5:    public BasketActions(ICache<Basket> cache)

   6:    {

   7:       _cache = cache;

   8:    }

   9:   

  10:    public Basket Get(int basketid)

  11:    {

  12:      var cacheValue = cache.Get(basketid);

  13:     if(cacheValue == null)

  14:     {  

  15:       var res = GetBasket(basketid);

  16:       if(res != null)

  17:       {

  18:          cache.Add(res, cachekey);

  19:       }

  20:       return res; 

  21:      }

  22:      return cacheValue;

  23:    }

  24:   

  25:    private Basket GetBasket(int basketid)

  26:    {

  27:      ...

  28:    }

  29:  } 

and finally we change our IOC call to the following.

   1:  IOC.Register<ICache<Basket>, Velocity<Basket>>();

Caching and the SRP

I've been using Velocity (Microsofts new caching product) on a project and while lurking on the lists spotted a post about testability around the Velocity API's. There may be reasons for doing this but it is something I avoid. I tend to use the SRP principle when it comes to anything that is associated with crosscutting concerns in my code (Caching, Logging, Session etc). As such I have one class that just deals with caching, a simple example would be.

   1:  public interface ICache

   2:  {

   3:    void Add(Basket res, string key);

   4:    Basket Get(string key);

   5:    void Remove(string key);

   6:  }

   1:   public class Velocity : ICache

   2:      {

   3:          private const string CACHE = "MyCache";

   4:          

   5:          public void Add(Basket res, string key)

   6:          {

   7:              var CacheCluster1 = new CacheFactory();

   8:              var Cache1 = CacheCluster1.GetCache(CACHE);

   9:              Cache1.Add(key, res);

  10:          }

  11:   

  12:          public Basket Get(string key)

  13:          {

  14:              var CacheCluster1 = new CacheFactory();

  15:              var Cache1 = CacheCluster1.GetCache(CACHE);

  16:   

  17:              return (Basket) Cache1.Get(key);

  18:          }

  19:   

  20:          public void Remove(string key)

  21:          {

  22:              var CacheCluster1 = new CacheFactory();

  23:              var Cache1 = CacheCluster1.GetCache(CACHE);

  24:   

  25:              Cache1.Remove(key);

  26:          }

  27:      }

So simple actions for Add, Remove, Get that wrap up what Velocity is doing. The rest of my code just needs to know about this class with rest of the details abstracted away. If I wanted I could use memcache rather than Velocity, as long as my memcache class implements ICache my code is not concerned, all it is concerned with is a class that implements ICache.

   1:  var cacheValue = cache.Get(basketid);

   2:  if(cacheValue == null)

   3:  {

   4:     var res = GetBasket(basketid);         

   5:     if(res != null)

   6:     {   

   7:       cache.Add(res, cachekey);                    

   8:     }

   9:     return res;

  10:  }            

  11:  return cacheValue;

Know you can use DI to inject your caching class, using the IOC this would simply be

   1:  IOC.Register<ICache, Velocity>();

Neat.

CI server wish list

I am interested in hearing folks thoughts on what they like\dislike about the current CI server offerings both commerical and OSS (Java, Ruby or .NET) and what they would love to see in a CI product? To start you off here is a few of mine.

• One click copy -  copy one build process into a new process in one click
• Pluggable Everything © - what it says on the tin.
• Support beyond XML as a meta format, both input and output
• Order the build process how I want it
• Do build process's how I want it

To fight my fire I need a MOP

I feel like I have reached a peak, I understand and use Inheritance, Polymorphism, Abstraction, Encapsulation and Parametric Inheritance (Generics) every day. They solve my computing needs but I very often I can think of better approaches to a problem and wish the compiler and CLI were not without limits.

Generic covariance and contra-variance I have covered before so I'll jump right into something else I'd like to see.

Meta Objects and Protocols - Jeremy mentioned this before and I agree but rather than bending to my will the objects defining interface I also want to work with the object systems very own protocol interface, I want MOP...

MOP (Meta Object Protocols) the Protocols of the OOP system, how Inheritance, Polymorphism, Abstraction, Encapsulation are all defined and expressed in your language. With MOP you can change all of those, picking on inheritance, how and what you inherit and if you so wish change that. So why change that? Suppose I want to have multiple class inheritance? Better yet and my own personal want, object own inheritance, that is object inheriting it's self into the same object. Not the object creating/modifying/destroying but rewriting it's self. Suppose we wanted AOP, with MOP you no longer need to weave but rather use MOP to change the protocol rules your code will use for the aspects (some of the founding MOP researchers went on to create AOP using MOP). A MOP would also release the product team from needing to change the compiler\CLI when you need new things; instead you extend the MOP for those things.

DDD voting opens

The voting for DDD opened yesterday, my submission is listed and do give it some thought if you are planning on attending. I've given a MbUnit session here in Manchester first at AgileNorth last year and again last week at the ThoughtWorks geek night, I'd love to bring the session to a wider UK audience and show you what MbUnit can do. I am up against loads of great sessions (all of which I want to see) so picking the sessions you want to see will be really tricky, hopefully this years event will get lots of space or more days (DDD weekender?).

RedGate and the Parrot

Made me smile.

Mini IOC and Static gateway logging

DI (IOC) containers are a powerful tools, the reasons why you would and would not use one I will leave to your better judgement. Which one you would use I will also leave to your judgement, however if you need a light weight, build in IOC then one of the best examples I have seen (and used) is Ken's 33 line Mini IOC. It is simple to use and simple to implement

   1:  IOC.Register<IShipping, MyShipping>();        

   2:  IOC.Register<IBasket, MyBasket>();        

   3:  IOC.Register<IView, MyView>();

   4:  var bank = IOC.Resolve<IPresenter>();

logging is a little tricky, to the rescue comes JB's static gateway logging example. This is a neat solution to the problem as we now use IOC to resolve a logging class dependency, so first we need to create a dependency class for our mini IOC.

   1:      public class IOCResolver : IDependencyResolver

   2:      {

   3:          public Interface GetImplementationOf<Interface>()

   4:          {

   5:              return IOC.Resolve<Interface>();

   6:          }

   7:      }

Next we need a logging class Factory

   1:      public class DebugLogFactory : ILogFactory

   2:      {

   3:          public ILog CreateFor(Type type)

   4:          {

   5:              return new DebugLogger();

   6:          }

   7:      }

and the logging class 

   1:       public class DebugLogger : ILog

   2:          {

   3:              public void Debug(string message)

   4:              {

   5:                 System.Diagnostics.Debug.WriteLine("DEBUG: " + message);

   6:              }

   7:   

   8:              public void Warning(string message)

   9:              {

  10:                  System.Diagnostics.Debug.WriteLine("WARNING: " + message);

  11:              }

  12:   

  13:              public void Fail(string message)

  14:              {

  15:                  System.Diagnostics.Debug.WriteLine("FAIL: " + message);

  16:              }

  17:          }

  18:      }

Now we have our various parts we first set up the Resolver which then goes looking in the IOC for our logging Factory (thus we also need to add our logging Factory to the IOC), all in all we end up with

   1:  DependencyResolver.InitializeWith(new IOCResolver());

   2:  IOC.Register<ILogFactory, DebugLogFactory>();

   3:  IOC.Register<IShipping, MyShipping>();        

   4:  IOC.Register<IBasket, MyBasket>();        

   5:  IOC.Register<IView, MyView>();

   6:  var bank = IOC.Resolve<IPresenter>();

now we can log simply by using

   1:  Log.For(this).Debug("testing")