Being Cellfish


January, 2012

Change of Address
This blog has moved to
  • Being Cellfish

    Deployment specific azure config


    I've earlier described a simple way to deal with development specific config but the larger your system is the more likely it is that you will have multiple environments you want to run against; private development, latest build deployment, stress deployment, production deployment etc. Here is a good suggestion on how to solve that problem in a pretty convenient way.

  • Being Cellfish

    Repetitive Lazy<T> to the rescue


    The other day I was doing my usual double check locking when a co-worker pointed out that without a memory barrier the typical implementation is not necessarily safe. It is described here together with several options from a singleton perspective. Also my time on the Robotics team have made me almost religious about trying to avoid any kind of manual synchronization (i.e. when I use a synchronization object explicitly in my code). The problem I was trying to fix this time involved one method that runs for a relatively long time. During this time a property must not change. Easy enough to get around I thought and made the type of the property a struct (I could have made the class IClonable too, but since the object consist only of a number of value types a struct made sense to me.

    Since assignment of structs are not atomic I needed something to make sure the struct being copied did not change at the same time resulting in a corrupt struct. Nor could I take a lock for the whole execution of this method since any thread needing to change this property would need to do so quickly without waiting for the long running method. I realized that I could use the Lazy<T> to not create my own lock and make the code look really nice. This is the essence of what I came up with:

      1: public class RepetitiveLazyUsage
      2: {
      3:     private Lazy<int> theValue = 
      4:         new Lazy<int>(LazyThreadSafetyMode.ExecutionAndPublication); 
      6:     public int UseTheValue()
      7:     {
      8:         int valueToUse = theValue.Value;
      9:         // Relativly slow code here that depends on valueToUse.
     10:         return valueToUse;
     11:     }
     13:     public void SetTheValue(int value)
     14:     {
     15:         theValue = new Lazy<int>(
     16:             () => value, 
     17:             LazyThreadSafetyMode.ExecutionAndPublication);
     18:     }
     19: }

    As you can see this looks pretty nice I think and I'm using two features to make sure this code does not have any problems in a multi-threaded environment. First I use Lazy<T> in a thread-safe mode and that way I don't need an explicit lock. Second I use the fact that reference type assignments are atomic in .Net and hence replacing the instance of theValue in the SetNewValue method does not need a lock nor when I'm getting the value.

  • Being Cellfish

    Visual studio achievements


    I guess this plugin for Visual Studio should be mandatory from now on...

  • Being Cellfish

    Avoid timeout when uploading large blobs to Azure


    If you're uploading (and I guess downloading) large blobs to Azure you might hit a timeout consistently because the ClientBlobClient have a timeout property. It defaults to 90 seconds which means that if Azure is your bottle neck (and throttling you) anything above 5400 MB will result in a timeout. In real life your connection up to azure is more likely your bottle neck (for example I experienced timeouts of files above approximately 200MB when uploading from home). So make sure you increase this timeout for large files to avoid these timeouts.

    There is however another problem with this API in my opinion. As a server I think it makes sense to have a timeout preventing clients from taking up resources by just uploading data very slowly, but this is a client API so as long as I'm uploading data I'm technically fine I think. A much shorter timeout where it only fires if no data can be sent during that period makes more sense to me personally. In a perfect world there would actually be two timeouts; the idle timeout and an overall timeout. But the default (and what I think should be there if I had to choose one) would be the idle timeout. I don't think a client really wants to timeout if transfer is slow as long as there is progress. But again, that's just me...

  • Being Cellfish

    Evolution of a hand rolled fake


    I usually hand roll my own fake objects for my tests. They have always looked a lot like what Stubs generate. I just think that it's so cheap to create them that I don't even need Stubs. In this series I'll assume an interface that looks like this:

      1: interface ITheInterface
      2: {
      3:     void DoSomething(int x);
      4:     int ComputeSomething(int a, int b);
      5: }

    When I first started to hand roll my fakes it looked something like this:

      6: private class FakeTheInterface : ITheInterface
      7: {
      8:     public Action<int> DoSomethingHandler { get; set; }
      9:     public Func<int, int, int> ComputeSomethingHandler { get; set; } 
     11:     public void DoSomething(int x)
     12:     {
     13:         if (DoSomethingHandler == null)
     14:         {
     15:             Assert.Fail("Unexpected call to DoSomething");
     16:         }
     18:         DoSomethingHandler(x);
     19:     }
     21:     public int ComputeSomething(int a, int b)
     22:     {
     23:         if (ComputeSomethingHandler == null)
     24:         {
     25:             Assert.Fail("Unexpected call to ComputeSomething");
     26:         }
     28:         return ComputeSomethingHandler(a, b);
     29:     }
     30: }

    Which gave you a test that looked something like this:

     31: [TestMethod]
     32: public void UsingFake1()
     33: {
     34:     var thing = new FakeTheInterface();
     35:     thing.ComputeSomethingHandler = (a, b) => 42;
     36:     Assert.AreEqual(42, thing.ComputeSomething(0, 0));
     37: }

    After a while I realized that I could make the fake a little nicer by doing this:

     38: private class FakeTheInterface : ITheInterface
     39: {
     40:     public Action<int> DoSomethingHandler { get; set; }
     43:     public void DoSomething(int x)
     44:     {
     45:         Assert.IsNotNull(DoSomethingHandler, 
     46:             "Unexpected call to DoSomething");
     47:         DoSomethingHandler(x);
     48:     }
     50:     public int ComputeSomething(int a, int b)
     51:     {
     52:         Assert.IsNotNull(ComputeSomethingHandler, 
     53:             "Unexpected call to ComputeSomething");
     54:         return ComputeSomethingHandler(a, b);
     55:     }
     56: }

    But once in a while I came across an interface with a method that had a method like FooHandler. "FooHandlerHandler" is just very confusing. Recently I tried a different approach that looks like this:

     57: private class FakeTheInterface : ITheInterface
     58: {
     59:     private Action<int> doSomething = 
     60:         x => Assert.Fail("Unexpected call to DoSomething({0}).", x);
     62:     private Func<int, int, int> computeSomething =
     63:         (a, b) =>
     64:             {
     65:                 Assert.Fail(
     66:                     "Unexpected call to ComputeSomething({0}, {1}).",
     67:                     a, b);
     68:                 return 0;
     69:             };
     71:     public FakeTheInterface(
     72:         Action<int> DoSomething = null, 
     73:         Func<int, int, int> ComputeSomething = null)
     74:     {
     75:         doSomething = DoSomething ?? doSomething;
     76:         computeSomething = ComputeSomething ?? computeSomething;
     77:     }
     79:     public void DoSomething(int x)
     80:     {
     81:         doSomething(x);
     82:     }
     84:     public int ComputeSomething(int a, int b)
     85:     {
     86:         return computeSomething(a, b);
     87:     }
     88: }

    Note that I abuse the naming guidelines for arguments in order to make it consistent with the method name. A test using this fake looks like this:

     89: [TestMethod]
     90: public void UsingFake3()
     91: {
     92:     var thing = new FakeTheInterface(
     93:         ComputeSomething: (a, b) => 42);
     94:     Assert.AreEqual(42, thing.ComputeSomething(0, 0));
     95: }

    So far I'm happy with this evolution. The only potential problem I see is if I need to replace the implementation half way through a test, but that can still be achieved by having a seperate variable in the test that I use and then change. So all in all it feels like this last evolution will be used (by me) for a while. Suggestions on improvements welcome!

  • Being Cellfish

    I hate software that assumes things about database instances


    I recently had to install some software that wouldn't run because I gave my SQL Server instance a descriptive name. There was no (or at least not easy) way to get it to use anything other than the default name "MSSQLSERVER". At the same time I removed my SQL Express which my Azure storage emulator used so I had to fix that one too... At least that is fairly easy: DSInit /sqlInstance:.

  • Being Cellfish

    Development specific azure config


    Over the holidays I've been starting to clean up a backlog of old RSS items I should read and one of them covered a way to deal with Azure configurationss and how they differ in development and production. While I've been using a similar approach to hide the fact if a configuration setting is read from the role configuration or web.config I've dealt with development vs production configuration in a different way. So far I've kept the configuration file that is part of the project as development specific and had separate configurations for production elsewhere. Naturally this makes me have to keep two files in sync when I add new settings and once in a while I need to use custom storage for my development like hitting a real azure storage account but not the production one.

    What I like with the approach used in the link above is that you only need one file. Drawback is however that now my configuration file now needs a few extra development only settings that override the production ones. But compared to having two files I kind of like this idea. Worth a try I think and I'll let you know how it works for me once I've tried it.

  • Being Cellfish

    New year, new team


    As of 2012 I'm no longer working on the robotics team. I'm now working on the Xbox Live team.

  • Being Cellfish

    2011 statistics


    Time for my 2011 according to this blog's statistics. As last year we'll start of with the five most read posts:

    1. Native code coverage reports
    2. CCR tips & tricks
    3. @"Tired of scrum"
    4. Upsert in SQL server
    5. Object calisthenics

    So for the third year in a row native code coverage reports is the most read article I have on my blog. And both upserts and object calisthenics made it back on the list after being gone for a year.The top ten search terms to land on this blog in 2011 were (2010 ranking within paranthesis):

    1. kanban explained (new)
    2. sql server upsert (new)
    3. mocking framework (new)
    4. upsert sql server 2008 (3)
    5. tdd tutorial (4)
    6. getting code coverage with xunit (new)
    7. memcmp performance (10)
    8. xunit code coverage (new)
    9. object calisthenics (5)
    10. php ntlm (new)
Page 1 of 1 (9 items)