Being Cellfish

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

September, 2008

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

    Sleep less than one millisecond

    • 1 Comments

    On windows you have a problem you typically never encounter on Unix. That is how to get a thread to sleep for less than one millisecond. On Unix you typically have a number of choices (sleep, usleep and nanosleep) to fit your needs. On windows however there is only Sleep with millisecond granularity. You can however use the select system call to create a microsecond sleep. On Unix this is pretty straight forward:

    int usleep(long usec)
    {
        struct timeval tv;
        tv.tv_sec = usec/1000000L;
        tv.tv_usec = usec%1000000L;
        return select(0, 0, 0, 0, &tv);
    }

    On windows however, the use of select forces you to include the winsock library which has to be initialized like this in your application:

        WORD wVersionRequested = MAKEWORD(1,0);
        WSADATA wsaData;
        WSAStartup(wVersionRequested, &wsaData);

    And then the select won't allow you to be called without any socket so you have to do a little more to create a microsleep method:

    int usleep(long usec)
    {
        struct timeval tv;
        fd_set dummy;
        SOCKET s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
        FD_ZERO(&dummy);
        FD_SET(s, &dummy);
        tv.tv_sec = usec/1000000L;
        tv.tv_usec = usec%1000000L;
        return select(0, 0, 0, &dummy, &tv);
    }

    All these created usleep methods return zero when successful and non-zero for errors.

     

  • Being Cellfish

    Yet Another Tale from an Interview

    • 1 Comments

    There seems to be a lot of myths around the interview procedure at Microsoft. I had my interview a little more than a year ago and coming from Sweden it was a big difference to have the interview in the US. The interview is (as described in the myths) basically two parts. First half is number of people asking you to solve a number of programming problems on a white board. Since I flew in the day before and was severely jet-lagged this was a tough start. If the first guys thinks you're good enough you'll spend the second half of the day talking to different managers. At least this is what happens when you're interviewed for a software engineering position.

    Another nice thing is that you're pretty good prepared for the interview by the recruiter. And there is no dress code. Actually they stress that since it is a long day of several hard interviews you should come wearing something you feel comfortable in. They're hiring you for your brain, not for what you're wearing. 

    So what kind of problems do they make you solve? Personally I prepared going over this list but don't expect to get any of those questions. I did not get a single question on that list. I have also (inspired by that list) added a few personal favorites that I use whenever I have to interview somebody.

    Actually there is not much more to be said about the interviewing process I think. You have to experience it to know what's it like. And it is different for every person. Microsoft really tries to give you a challenge during your interview (at least my division does). So one thing I can tell you is that you feel pretty pleased with your self once you pass and get an offer.

    So why is this filed under relocate? Well, I thought this would be a good start on a series of stories about my experiences relocating from Sweden to the US...

  • Being Cellfish

    My new favorite .Net unit test framework

    • 1 Comments

    I recently had a chance to really sink my teeth into xUnit.net. Since I've been stuck with CPPUnit for quite some time and working with xUnit.net was a relief. Compared to NUnit I find xUnit much easier and convenient to work with (and compared with CPPUnit it's in a class of it own).

    I feel I must give you four good reasons (no particular order) for why I prefer xUnit.net:

    • xcopy install makes it incredible easy to use it anywhere it is needed and in any form. Even different versions.
    • No need to mark up fixtures and test suits with attributes. A test method can basically be put anywhere.
    • No weird assertion names that feels like just a tick in the feature list. A small set of useful asserts.
    • Testing for exceptions is an assertion and not a test method attribute.

    So earlier I suggested you to take a look at xUnit. Now I'm telling you. You won't be disappointed!

  • Being Cellfish

    A summary of an Agile 2008 summary

    • 0 Comments

    I didn't have the opportunity to attend the recent Agile 2008 conference in Toronto but I attended a summary presentation a few weeks ago. These are the key points that excited me.

    Celebrate your failures!

    People typically feel bad when they fail at something. But if nobody knows you've failed you don't feel so bad. But if nobody knows you're hiding something and that is not good for your agile project. But what if you celebrated every failure? Then you wouldn't feel so bad about it. And a failure is really something you should celebrate because a failure revealed means you can learn from it and improve. And improvement is definitely something to celebrate.

    This reminds me of a story Tobias Fors told. In order to make people understand that it is OK to throw an index card/post-it away he sometimes let everybody on the team write something on an index card. And then without revealing it to anybody they must tear it apart and throw it away. Apparently some people refuse... I guess that is related to fear of failure in some way...

    BDD without BDD-framework

    Dan North a.k.a. the inventor of BDD had a session where he showed how you develop behavior driven with a regular unit test framework. I think this is extremely interesting since I have always been convinced that BDD is just another name for TDD done right. Exactly how this is done will have to be a future article.

    Iteration-less agile

    When you think about an agile project a lot of people think of an iterative process. But there are an increasing group of people who start looking at methods where the agile principles are used but without iterations. Kanban boards is one way of doing this that I mentioned earlier. I think this is a very interesting development.

    "Trading game"

    I was also introduced to a new way of prioritizing items that was both fun, fast and effective even in large groups. I don't know under what name this was first described but I like the name trading game that was used during the summary. This is how it works:

    • Everybody writes one different thing on five different index cards.
    • All cards are collected and shuffled. Everybody is then given four cards at random.
    • The remaining cards are laid out on a table.
    • Now everybody may trade any of their four cards with a card from the table or from another person. The purpose of trading is to try and get four cards you find important.
    • Create small groups of three persons each. Each three person group must now decide on which three cards are most important. They may only choose from the twelve cards they have in their possession.
    • Each group's three cards are collected, shuffled and put on the wall. This is the starting point for further discussions.
    Each of these phases are suitable for time boxing. The numbers used can also be modified to suit your team's size. I find this trading game quite interesting since it can be used both in retrospects and prioritizing sessions.
  • Being Cellfish

    Sleep does not sleep for a specified period

    • 0 Comments

    I recently described how you can create your own usleep method when there isn't one to use. one thing that people however tend to forget is that the sleep methods (sleep, usleep, nanosleep) only guarantees that the calling thread will be suspended for at least the given time. There is absolutely no guarantee that the thread will resume its execution immediately after that time. On most platforms you don't really see the difference but there are exceptions. HPUX for example, even on an otherwise almost idle system I typically experience a delay of a few milliseconds even though I sleep for only a single microsecond.

    So if you want your thread to sleep for an exact amount of time you have use a different approach than sleep. Even if you use some sort of synchronize mechanism (an event) and a timer (to trigger the event) there is no guarantee that the blocked thread will execute immediately when the event is triggered. This approach is more likely to work as expected than the use of sleep, but it is not fool proof since you never know what other processes execute on the system affecting your process' execution.

    The closest thing you can come to exact sleep times is also the ugliest solution. You can always have a busy loop checking if enough time has passed over and over again. This will however change the behavior of the sleep into a busy loop which is rarely a good solution to a problem.

    Since only a minimum time can ever be guaranteed with a sleep method, regardless of implementation you should not write your code so that it depends on an exact sleep method. I think you're actually addressing the wrong problem if you try getting an exact sleep. Instead try figuring out why you need an exact sleep and remove that reason because you'll never be able to get it to work exactly right. Maybe good enough for now but you never know what will happen in the future so it's just a bad design choice.

Page 1 of 1 (5 items)