Being Cellfish

Stuff I wished I've found in some blog (and sometimes did)

Change of Address
This blog has moved to
  • Being Cellfish

    Stress testing with Fiddler


    If you're developing REST based services, Fiddler should not be news to you. But there might be a little trick you can use to do some simple stress testing. If you select one or more sessions in the Web Sessions pane and then hit shift+R you get a little dialog asking for number of times to replay the selected requests. There is no obvious way to find this in the UI as far as I can tell, but holding down shift as you click on Reissue Requests in the context menu does the same thing.

  • Being Cellfish

    Netflix's new take on APi design


    The Netflix blog recently had an interesting post on how they are transitioning into a new approach for API design. The basic idea is that instead of just exposing a number of generic operations each client type have their own adapters where instead of making a number of network calls to get data for one view the client just makes one call and the distribution if calls is done on the server, as is any client specific packaging. I found this intriguing for a number of reasons. First of all this reminds me of something I was exposed to in a project 1999. In that project we had most of our business logic in stored procedures (give me a break; it was the 90s and seemed like a good decision at the time) but each form in the UI had a single stored procedure it called to get all data it needed. That part actually worked quite well since our UI developers could write simple stored procedures. Ever since I've been a big fan of providing both the building blocks a client can use if needed but also convenience APIs, which happens to have another name; service facades.

    I guess the most interesting thing about Netflix's approach seems to be that they generally drop support for the publicly available, building block APIs and forces each client team to implement their own service facade that suit their needs. I strongly suspect there is a common library to implement a facade that handles the building blocks but that is not important. Bottom line is it looks like Netflix going to be using a service facade pattern and in them doing so highlight the importance of good abstractions so that the same service can be accessed both through REST, raw TCP and maybe even RPC calls.

  • Being Cellfish

    Evolution of a hand rolled fake - part 4


    Another hard problem when it comes to creating fakes is when the interface contain overloads (i.e. same method name but different parameters) like this:

     1: public interface IYetAnotherInterface
     2: {
     3:     int DoSomething();
     4:     int DoSomething(int x);
     5: }

    The Fakes utility in VS11 will generate properties like DoSomethingInt32 and DoSometingInt32Int32. Not great names IMHO. So there are three ways I deal with this types of interfaces. The first way, if I have control over the interface and the overloads or more for convenience than anything else, then I avoid overloads in the interface. I make the overloads extension methods on the interface instead. In the example above I would only have the last method. If I have an asynchronous and synchronous method on the same interface I try to just have the asynchronous one and then make the synchronous one an extension method. This way my fakes can be implemented the same way as before.

    The second way to deal with it is to let my fake just have one handler and make the overloads with fewer arguments just call the one with most arguments. This works in a lot of cases but makes the fake a little smarter than it should really be in some cases. Here is an example of this approach:

     6: public class FakeYetAnotherInterface : IYetAnotherInterface
     7: {
     8:     public Func<int, int> DoSomething { get; set; }
     10:     int IYetAnotherInterface.DoSomething()
     11:     {
     12:         Assert.IsNotNull(this.DoSomething, "Unexpected call to DoSomething");
     13:         return this.DoSomething(0);
     14:     }
     16:     int IYetAnotherInterface.DoSomething(int x)
     17:     {
     18:         Assert.IsNotNull(this.DoSomething, "Unexpected call to DoSomething");
     19:         return this.DoSomething(x);
     20:     }
     21: }

    My third option to deal with this is still to have one one handler for all my overloads but at the same time make sure I can easily know which one is being called. In this case I use a special class for the arguments:

     22: public class FakeArgument<T>
     23: {
     24:     private T value;
     26:     public FakeArgument()
     27:     {
     28:     }
     30:     public FakeArgument(T value)
     31:     {
     32:         this.Value = value;
     33:     }
     35:     public bool HasValue { get; private set; }
     37:     public T Value
     38:     {
     39:         get
     40:         {
     41:             Assert.IsTrue(this.HasValue, "Argument not set");
     42:             return this.value;
     43:         }
     45:         private set 
     46:         { 
     47:             this.value = value;
     48:             this.HasValue = true;
     49:         }
     50:     }
     52:     public static implicit operator T(FakeArgument<T> arg)
     53:     {
     54:         return arg.Value;
     55:     }
     56: }

    And this is the fake using that class:

     57: public class FakeYetAnotherInterface : IYetAnotherInterface
     58: {
     59:     public Func<FakeArgument<int>, int> DoSomething { get; set; } 
     61:     int IYetAnotherInterface.DoSomething()
     62:     {
     63:         Assert.IsNotNull(
     64:             this.DoSomething, "Unexpected call to DoSomething()");
     65:         return this.DoSomething(new FakeArgument<int>());
     66:     }
     68:     int IYetAnotherInterface.DoSomething(int x)
     69:     {
     70:         Assert.IsNotNull(
     71:             this.DoSomething, "Unexpected call to DoSomething({0})", x);
     72:         return this.DoSomething(new FakeArgument<int>(x));
     73:     }
     74: }

    And last a test using that fake:

     75: [TestMethod]
     76: public void UsingFake5()
     77: {
     78:     var fakeThing = new FakeAnotherInterface
     79:         {
     80:             DoSomething = arg =>
     81:                 {
     82:                     Assert.IsFalse(arg.HasValue, "Wrong overload called");
     83:                     return 42;
     84:                 }
     85:         };
     86:     IAnotherInterface thing = fakeThing;
     87:     Assert.AreEqual(42, thing.DoSomething());
     88: }

    This is however my last resort to deal with overloads in the interfaces needing faking. The first two options are definitely my preferred method.

  • Being Cellfish

    Evolution of a hand rolled fake - part 3


    So how do I fake an interface with properties?

     1: interface IAnotherInterface
     2: {
     3:     int SomeProperty { get; }
     4:     int SomeOtherProperty { get; set; }
     5: }

    Most of the time I just let my fake have the property implemented. This works most of the time but only really well if the interface properties are truly just data carriers. If there is a chance the properties can throw exceptions or if a property needs to be initialized specifically for each test I might go with the property method approach. Here is an example of both:

     6: public class FakeAnotherInterface : IAnotherInterface
     7: {
     8:     public int SomeProperty { get; set; }
     10:     public Func<int> SomeOtherProperty_Get { get; set; }
     12:     public Action<int> SomeOtherProperty_Set { get; set; }
     14:     int IAnotherInterface.SomeOtherProperty
     15:     {
     16:         get
     17:         {
     18:             Assert.IsNotNull(
     19:                 this.SomeOtherProperty_Get, 
     20:                 "Unexpected call getting SomeOtherProperty");
     21:             return this.SomeOtherProperty_Get();
     22:         }
     24:         set
     25:         {
     26:             Assert.IsNotNull(
     27:                 this.SomeOtherProperty_Set, 
     28:                 "Unexpected call setting SomeOtherProperty {0}", value);
     29:             this.SomeOtherProperty_Set(value);
     30:         }
     31:     }
     32: }
  • Being Cellfish

    Evolution of a hand rolled fake - part 2B


    While the last version I showed is very flexible I have experimented a little more. Why would you ever have a public getter on the fake handler properties? Maybe if you had a fake that needed to wrap existing fake behavior but this is probably pretty rare. So this is what it would look like with no public getters. Again this is just to declutter the fake API surface.

     1: public class FakeTheInterface : ITheInterface
     2: {
     3:     private Action<int> doSomething;
     5:     private Func<int, int, int> computeSomething;
     7:     public Action<int> DoSomething
     8:     {
     9:         set { this.doSomething = value; }
     10:     }
     12:     public Func<int, int, int> ComputeSomething
     13:     {
     14:         set { this.computeSomething = value; }
     15:     }
     17:     void ITheInterface.DoSomething(int x)
     18:     {
     19:         Assert.IsNotNull(this.doSomething, "Unexpected call to DoSomething");
     20:         this.doSomething(x);
     21:     }
     23:     int ITheInterface.ComputeSomething(int a, int b)
     24:     {
     25:         Assert.IsNotNull(
     26:             this.computeSomething, "Unexpected call to ComputeSomething");
     27:         return this.computeSomething(a, b);
     28:     }
     29: }
  • Being Cellfish

    Evolution of a hand rolled fake - part 2


    In a recent discussion at work I realized that the main reason I started with the constructor based fakes descried here was not to clutter the object with properties called SomethingHandler. By having my fake implement the interface explicitly I could create a fake like this:

     1: public class FakeTheInterface : ITheInterface
     2: {
     3:     public Action<int> DoSomething { get; set; }
     5:     public Func<int, int, int> ComputeSomething { get; set; } 
     7:     void ITheInterface.DoSomething(int x)
     8:     {
     9:         Assert.IsNotNull(this.DoSomething, "Unexpected call to DoSomething");
     10:         this.DoSomething(x);
     11:     }
     13:     int ITheInterface.ComputeSomething(int a, int b)
     14:     {
     15:         Assert.IsNotNull(this.ComputeSomething, "Unexpected call to ComputeSomething");
     16:         return this.ComputeSomething(a, b);
     17:     }
     18: }

    And this way I can write a test like this:

     19: [TestMethod]
     20: public void UsingFake()
     21: {
     22:     var fakeThing = new FakeTheInterface
     23:                     {
     24:                         ComputeSomething = (a, b) => 42
     25:                     };
     26:     ITheInterface thing = fakeThing;
     27:     Assert.AreEqual(42, thing.ComputeSomething(0, 0));
     28: }

    Please disregard the "cast" to the interface in this test. It's because it's a stupid test. Any real test would take this fake object as a dependency somewhere so it would be used in the context of the interface. But the real beauty is that when working with the fake and setting it up you do not get intelli-sense cluttered with the methods and properties of the interface itself, just the things you need to setup the fake.

  • Being Cellfish

    Adding a timout to a task


    Remember how I added a timeout to an existing Choice in CCR? Well with the new Task based world in .Net 4.5 you will probably want to do the same thing with a task returned by somebody else. Good for me this time is that somebody else already figured out how to do it. I especially like the approach under A Different Approach, especially if modify to deal better with some edge cases.

  • Being Cellfish

    Identifying IIS worker processes


    The other day I had to debug a running IIS process. There was a nifty little command to figure out which process to attach to:
    C:\Windows\System32\Inetsrv\appcmd list wp
    Apart from the terrible fact that I had to debug a running IIS process this was a useful command.

  • Being Cellfish

    Federated login relies on target site to be secure


    I attended an interesting talk in the last week that was based on a paper from MSR. It was interesting to hear that in this day where federated logins where you use your facebook, google or live credentials to login to some 3rd party site is very convenient but a lot of these 3rd party sites are not validating the security tokens correctly so they're open to attacks. Definitly worth a read if you're planning on using somebody else to authenticate your users on your web site.

  • Being Cellfish

    Office pranks


    One thing that happens more or less often when somebody is on vacation at Microsoft is that their office might get redecorated. A former co-worker of mine decided to move down to California and work at Microsoft there and his team decided to help him get the office packaged for the move. This is what it looked like...

Page 9 of 49 (482 items) «7891011»