Being Cellfish

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

Change of Address
This blog has moved to blog.cellfish.se.
Posts
  • Being Cellfish

    Open Space Party

    • 2 Comments

    Yesterday a number of my friends had organized a "reunion farewell party". Reunion since many of the guys had not seen each other for several years. Preparing for the party we had a lot of discussions on what would happen because we expected it to get pretty wild. That was when it struck me that a great party is like an Open Space:

    • Whoever comes is the right people
    • Whatever happens is the only thing that could have
    • Whenever it starts is the right time
    • When it's over, it's over

    There is no point in analyzing what is going to happen more than that... I only feel slightly disturbed just because of the fact that I'm comparing a party with an open space session...

  • Being Cellfish

    Coding Dojo 1

    • 2 Comments

    Since I moved to Redmond I've been looking for a regular coding dojo in this area but I've not been able to find one. So I first planned a number of team dojos in my team but I felt that was not enough. I think an important part of each dojo session is to meet other people and learn their TDD tricks. So since I couldn't find any dojo in the area I planned one myself and invited people on one of the internal mailing lists (also set up a separate internal mailing list for the dojo). I thought Microsoft would have more than enough people to be interested in attending coding dojos.

    So yesterday was the first dojo session I arranged open to all Microsoft employees. We did the kata I'm most familiar with: MineSweeper. For the first time we tried to build parts rather than stick to the end-to-end type of tests. It was an interesting experience and we got further toward a complete solution than I've ever seen myself. Not sure it was just because we approached the problem slightly different or the fact that the group was fairly small. The important part is that I got to learn a few small tricks and I'm pretty sure others learned some tricks too.

    So now I just have to plan the next session...

  • Being Cellfish

    Getting a drivers license in the US

    • 2 Comments

    Getting a drivers license in the US is not the same thing as in Sweden. First of all the booklet you can read to study is much shorter. At least in state Washington. The written test is 25 multiple choice questions and you need 20 correct answers. Since the test is computerized you actually only have to answer 20 questions if you get them all correct. Another nice thing is that you can skip questions and answer them last. I wasn't sure on two questions so I skipped them and since I got the rest correct I never had to answer the skipped questions. That at least makes it feel easier.

    The driving test it self took 15 minutes and included parallel parking, parking on a hillside and basically driving around a block with no traffic. Really easy if you've had a drivers license for some time. But to get top score remember to stop before any lines at stop signs (not even the front bumper may pass) and make sure you can parallel park with only three distinct turns on the steering wheel.

  • Being Cellfish

    The amazing auto woman

    • 2 Comments

    For the first time in my life I've bought a car without the feeling of getting ripped off by the car dealer. I'm not particulary interested in cars and especially not in how they work and what makes a car better than another. I select car purly on feeling. I also hate negotiating. So when I found out that there actually exists a person who finds the car you want, negotiate a good price and then delivers it to your door including taking care of all the paperwork I was surprised that this isn't more common. Now I only have to decide on what will be my second car so I ca order that too.

  • Being Cellfish

    Dangers of using Visual Studio 2008 Team System Code Coverage Tool for Native C++

    • 2 Comments

    So now you know how to get coverage reports for native C++ using Visual Studio 2008 Team System (if not - read this). There are a few things you need to know before you get excited. First of all the only metrics you get are line and block coverage. A block is basically a statement and each line typically consists of one or more blocks. Unless you have 100% coverage I think these metrics both are pretty useless when measuring quality. For example consider a function consisting of ten lines of code. There is an IF-statement checking for an error and it throws an exception if the error occurs. If the error never occurs during the test-run you still get 90% line coverage since the other nine lines are executed. I think this is pretty common in production code. Most of the code is for the common state and fewer lines are used to handle errors. So you get pretty high line coverage even if you do not test any of error cases.

    Block coverage is even worse. For example consider the following line:

    SimpleClass* o = new SimpleClass();

    That line produces two blocks of which only one is covered. And there is no reasonable way test the uncovered block since it probably has to do with when the process runs out of memory.

    Identifying functions that are not called at all is often considered an important part of the code coverage report. Here we have another problem with the visual studio tool. Functions never referenced by the code will be excluded from the report completely (I suspect this is the case since the linker will remove all unreferenced symbols as part of the optimization at link time). This means the following class will report 100% coverage it it is instantiated and only GetA is called.

    class SimpleClass
    {
    public:
        SimpleClass(int a, int b)
            : m_a(0) , m_b(b)
        { }
    
        int GetA() { return m_a; }
        int GetB() { return m_b; }
    
    private:
        int m_a;
        int m_b;
    };

    So with all these potential problems there is another tool I'd recommend you consider. It's called BullsEye. It is a more "puristic" tool so there is no way to get block or line coverage, basically since those metrics are bad. In stead you can get Decision and Condition/Decision coverage. Basically Decision coverage checks that each conditional evaluates to both true and false and Condition/Decision coverage is when each part of a boolean expression is evaluated to both true and false. Consider the following line:

    if(a || b)

    There are two different decisions (either "a || b" is true or false) but four different conditions (both "a" and "b" must evaluate to true and false). BullsEye also adds instrumentation at compile time so the GetB method in the example above will not be lost but be part of the report as an uncovered function even if not referenced anywhere in the code. In the initial example (ten lines with 90% line coverage) we would get 50% decision coverage which is a much better indicator of quality.

    And on using code coverage as a quality metric...I must insist you read one of my previous posts if you haven't done that already...

  • Being Cellfish

    Expensive fraud prevention fee

    • 2 Comments

    When you apply for a US Visa you have to pay a fee of $131 per applicant. Depending on type of visa you might also have to pay a $500 fraud prevention fee. I paid all this in advance and went happy to the US embassy this morning. It was pretty cold so standing in line outside for an hour with a one year old kid was not fun. When we reach the door to the security checkpoint the guard apologizes for not seeing we had a kid with us. If he'd known he'd let as go in before everybody else. That was the first lesson learned today.

    Second lesson learned was that I should read all instructions carefully... The $500 fee should not be paid in advance. It should be paid at the embassy. And the extra money paid in advance is lost. I don't think that had anything to do with it but we had a really short wait inside for our visa interview. At least we overtook a couple of people there...

  • Being Cellfish

    TDD and mocks

    • 2 Comments

    First of all I must remind you that I don't like mocks and mocks aren't stubs. But recently I read a very interesting story on code without getters and its consequences. The story is about a company where the developers where asked to develop their (OO) code without any getters. The brilliance of this simple, and at first glance weird constraint is that it forces the developers to design the code in a way that is generally considered "better" (i.e. don't ask objects for data, tell them what to do). It also introduces the need for mocks in a natural way. Actually mocks are not needed. A fake or stub object might work just as well.

    Let's take a look at an example. If we look at my example from I don't like mocks where I want to transfer funds from one account to another. Without getters the code would have to look something like this:

    transaction.commit(accountFrom.remove(amount), accountTo.add(amount))

    If we use a mock object we can test that this code actually changes the account values correctly. But we still have the same maintainability and focus problems I discussed in the I don't like mocks post earlier. And you might as well use a stub or fake object. Actually the use of a stub and fake will force you to focus on testing the right things in your unit test because you have to test the account.remove and account.add methods by them selfs. And when you know they work you can fake/stub that unit completely and start testing that transaction.commit does the right thing given different behavior from the account objects.

  • Being Cellfish

    Xbox Fit

    • 2 Comments

    You will probably never see an Xbox Fit because Microsoft would never get away with things like Nintendo does with the Wii Fit. You have maybe seen this comic before and if you don't own a  Wii Fit you may just laugh at it. But there is a lot of truth in that comic. I know because I own a Wii Fit. Let me tell you what I've experienced...

    Sometimes (about once every month) I get a question when I start Wii Fit: Have you noticed anything about X's body recently? "X" is the name of my wife who also uses the Wii Fit. And I have to choose one of four answers: "No change", "Gained weight", "Loosed weight", "Better posture". This is a loose-loose situation for me. Because if I answer "no change" or otherwise wrong I'll get a "maybe you're not paying attention to X". If I choose the "correct" response the Wii will tell me: "you should say that directly to X". So either way, regardless of my answer, the Wii Fit will make me feel guilty...

    My wife get another kind of questions... I tend to use the Wii Fit pretty late in the evening and then play some games. When that happens it gets close to (if not passed) midnight before I turn the Wii off and go to bed. In the morning (around 6am) I get on my Wii Fit to get the daily weight. I do this in the morning because it kept telling me, doing the fitness test at different times each day makes them less accurate. So I do it in the morning. Somehow it checks my user profile and sees that I was up late so it pretends it's sleepy. And then my wife get messages like: "You should tell Y to sleep more". Y being my name.

    Think about that for a moment... The game uses my profile to harass me and my family about my sleeping habits... The intention is good but isn't this an invasion of privacy? Now think what would happen if Microsoft released a product that tracked your habits and started to tell you (and your loved ones) that you should change... That's why I think we'll never see Xbox Fit.

    Talking about the Wii. There are however a few other cool things you can do with the Wii that I'd love to see on the Xbox too...

  • Being Cellfish

    Exit Mocks. Enter Stubs!

    • 2 Comments

    Since I'm not a fan of mocks I guess my prayers have been heard. Microsoft Research will soon release a stub framework. That's right. Stubs and not mocks! It is part of Pex that I have mentioned before. And you don't need to use Pex if you don't want. You can just use the stub framework by it self.

    The new stub framework can currently be used to stub interfaces. It creates the stubs by generating code. At first this scared me since I feared it would not regenerate the stubs when the interface changed (which might happen quite common when creating the interface using BDD). But it works just fine and detects changes in the assembly and regenerates the stubs. Very convenient.

    Another convenient thing is that it supplies default implementations for methods if I want. The default is to throw an StubNotImplementedException but I can change that and return default values (null, 0, empty string etc) if that is what I want. And the change can be made globally for all stubs created after the change or for a single stub object.

    So how does this work? Consider the following interface:

    public interface IMyInterface
    {
        int DoStuff();
    }

    I just tell the stub framework to generate stubs for the assembly containing the interface and it will generate a new namespace with the stubs. If IMyInterface is part of MyNamespace the stub framework will create a new namespace MyNamespace.Stubs with a class SMyInterface. Now we want to make a test. The test below doesn't really make since since it tests the stub instead of something using the stub, but I want to show the code that makes the stub work without the surrounding stuff so bare with me...

    void TestStub()
    {
        MyNamespace.Stubs.SMyInterface o = new MyNamespace.Stubs.SMyInterface();
        MyNamespace.IMyInterface i = o;
        Assert.Equal(42, i.DoStuff());
    }

    Now the test will fail since the stub will throw an exception since the stub is not implemented. Let's use the default implementation:

    void TestStub()
    {
        MyNamespace.Stubs.SMyInterface o = new MyNamespace.Stubs.SMyInterface();
        o.DefaultStub = Microsoft.Stubs.DefaultStub<MyNamespace.Stubs.SMyInterface>.DefaultValue;
        MyNamespace.IMyInterface i = o;
        Assert.Equal(42, i.DoStuff());
    }

    Still a failure since the stub returns zero for DoStuff(). Let's stub that method.

    void TestStub()
    {
        MyNamespace.Stubs.SMyInterface o = new MyNamespace.Stubs.SMyInterface();
        o.DefaultStub = Microsoft.Stubs.DefaultStub<MyNamespace.Stubs.SMyInterface>.DefaultValue;
        o.DoStuff = (stub) => { return 42; };
        MyNamespace.IMyInterface i = o;
        Assert.Equal(42, i.DoStuff());
    }

    Now the test passes! I think this new framework is an excellent addition to the developer's toolbox. And I think it is a better starting framework than all the mock frameworks out there. In the few cases that a mock framework is really needed (over a stub framework) you can easily extend your stub to verify behavior in the same way as a mock does. Currently the stub framework have a few limitations such as only being able stub interfaces. But I'll guess we'll have to wait and see what will be part of the release once it is available to the public (when writing this I've been using an internal release available to Microsoft staff only).

  • Being Cellfish

    The 2008 Advent Calendar situation

    • 2 Comments

    So for this year's Advent calendar I'll focus on a made up file utility object. The object is called FileUtil and it implements an interface called IFileUtil which looks like this:

        public interface IFileUtil
        {
            void Create(string content);
            void Delete();
            string Read();
            string Path { get; }
            bool Readable { get; set; }
        }
    
    I think the methods are quite straight forward but a quick walk-through:
    • Create creates a file with given content.
    • Delete deletes the file.
    • Read returns the content of the file.
    • Path returns the path to the file.
    • Readable indicates if the file is readable or not. It is also possible to change permissions (i.e. readable or not) using this property.

    The test I will write (in 24 different ways) is a test where I want to verify that the correct exception is thrown when I try to read a file that is not readable. And before I do that I want to make sure the file actually exists and is readable. So basically the test consist of the following steps:

    • Create a test file.
    • Make sure I can read that file.
    • Change the file from readable to not readable.
    • Make sure I can no longer read the file.
    • Remove the test file.
    All the tests are written using Xunit.net
Page 4 of 49 (481 items) «23456»