Being Cellfish

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

July, 2012

Change of Address
This blog has moved to
  • Being Cellfish

    My daughter have no parents or why would the data be normalized


    A Swedish friend who just had twins here in the US asked me about the passport troubles we had with my daughter (who is also born in the US) so that they could avoid it. It's quite a fun story so here it is.

    First a little background; in Sweden everybody gets a "personal number" (kind of like social security here in the US). It consist of your birth date (YYMMDD) followed by 4 digits here the third digit indicates sex (odd=male, even=female) and the last digit is a check-sum digit calculated from the other 9 digits using a simple algorithm.

    When my daughter was born we registered her with the Swedish authorities through the consulate so that she would be a Swedish citizen. Since my daughter never actually never lived in Sweden she did not get a personal number but a coordination number (same format and algorithm except the birth date have a number added to it).

    On her first trip to Sweden she traveled on her US passport but we thought it would ba good to have a Swedish passport for her too so we went to a police station to get her passport. But they couldn't do anything because the person with our doughter's coordination number did not have any parents according to the computer. When they looked at me and my wife we did have a daughter with the same name, but the personal number listed was our daughter's birth date followed by four zeros (which is never a valid personal number). Hence she couldn't get a passport.

    I went back to the Swedish IRS (who owns the personal number registry) and they just sighed... Apparently this happens a lot to people having kids while living abroad; the consulates add the correct information into one system, but not two as they should. They could however provide me with screen shots from their system that kind of proved we were parents to our daughter but I could just have made those myself... Back at the police station we finally got our daughter's passport using these screen shots as proof of parenthood...

    Next time we are in Sweden we can resolve this situation by bringing our daughter to the IRS and show them in person she exists. Until we do that they do not update the database so as far as that goes my daughter have no parents.

    The thing that really intrigues me is that Sweden is a country with about nine million people. Even given a certain history there should be no problem to keep this in a single database. So no need to go all NoSQL and have non-normalized data. It would make perfect sense to have this data normalized and I think parent-child relations is a pretty obvious example form any text book on database design. But no, apparently that is not the case because that would have been too easy I guess.

  • Being Cellfish

    Working with threads


    I co-worker of mine stumbled over a nice collection of helpful information when working with threads in C#. Once you start using .net 4.5 with its async/await patterns you might be using multi-threading more than before and it's good to understand the basics.

  • Being Cellfish

    Ten Commandments of Egoless Programming


    I recently saw this post with ten tips on how to be a better developer. It made me think of the Viking Laws again. The Viking Laws covers a few more aspects than the Ten Commandments which essentially just tell you to be a good person and point out a few different aspects of being a good person. So I think the title should really be Ten Commandments for Teams since I think the advice is applicable to any group of individuals working together towards a goal.

  • Being Cellfish

    Listening to port 80 without being admin


    If you're writing integration or so called end-to-end tests for web services you typically need to spin up a service locally just for a few tests. Or maybe you're just interested in doing some manual testing locally. In both cased you likely need to be an administrator to be able to listen to the desired port and/or URL prefix (I'm assuming HTTP here). Or you need to configure HTTP.sys to allow you to listen to the desired prefix without running as an administrator. Both options are bad. Relying on configuration is always a pain and running as administrator is typically a bad idea since your service most likely will not once deployed. There is however a third option that is kind of a cheat on the configuration approach. For a few versions of windows (I honestly don't know when it started, but was in Vista and is still in Win8 beta) there has been a preconfigured HTTP prefix for this exact purpose, i.e. spinning up a temporary listener.

    If you run: "netsh http show urlacl" from a command prompt you'll notice this one: http://+:80/Temporary_Listen_Addresses/.

    The only thing you need to think about in order to use this is to make sure you can easily configure your service to use this HTTP prefix for whatever it does. And having a test configuration you probably need anyway so this shouldn't be too much of a problem. And you don't have to configure HTTP.sys and can run your tests as a regular user rather than an admin.

  • 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: }
Page 1 of 1 (9 items)