Being Cellfish

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

April, 2009

Change of Address
This blog has moved to
  • Being Cellfish

    Merging coverage reports with Bullseye


    I've previously recommended Bullseye. And there is another nifty feature with Bullseye you should know; the ability to merge reports. This is pretty useful when you have one report from your unit tests and one from some other type of test run. Use this command to merge reports with Bullseye:

    covmerge.exe -c -fMergedData.cov file1.cov file2.cov
  • Being Cellfish

    Kanban vs Scrum

    Yesterday Henrik Kniberg published this draft on Kanban vs Scrum. I think it is a great article describing the differences (and similarities) between Scrum and Kanban so you should take the time and read it since there are times when a Kanban approach is better than a non-Kanban approach (and vice versa). I also like the fact that Henrik ends his article by pointing out the importance of retrospects. And if you wonder about when to have retrospects in a team using the Kanban approach I suggest reading this.
  • Being Cellfish

    A reminder if you want to read/write your file in non blocking mode (in C(++))


    Sometimes you might want to read a file non-blocking. It could be /dev/random because waiting for entropy might take very long. Also when you have to read device files on unix you sometimes have to read them non-blocking. A common pattern is to open the file non-blocking using the open method: open(..., O_NONBLOCK, ...)

    This however may be a problem. This type of open will typically succeed (because the system is opening the file non-blocking) and when you then start reading (or writing) you get a failure. The failure can be anything from permission problems to unavailable devices. This is how non-blocking I/O works and something you're well aware of if you're using sockets for communication but since "this is files" you might forget to take non-blocking into account.

    So there is a really easy way to work around this. Files, unlike network sockets completes the open operation very fast. So making the open call non-blocking generally does not make so much sense. Instead I suggest you open the file in blocking mode and then change it to non-blocking one opened. And this is how you do that:

    1: int fd = open(..., 0, ...); // Filed open in blocking 2: int fd_flags = fcntl(fd, F_GETFL); 3: if (fd_flags < 0) { // Get any flags set on the fd. 4: close(fd); 5: return error; 6: } 7: if (-1 == fcntl(fd, F_SETFL, fd_flags | O_NONBLOCK)) { // Add non blocking to the fd flags 8: close(fd); 9: return error; 10: }

    But there is (at least) one situation where a non-blocking open might make some sense. That is when you open a file on a remote server and you cannot afford the waiting of an open call. And in this case you must treat the file descriptor like any other file descriptor used for network communication and use select to make sure the file descriptor is ready before you start using it.

  • Being Cellfish

    Status board example


    So I previously showed how I used a taskboard at home. Just to give you another example I wanted to show you what I did last week to keep track of the customer issues I was working with together with the customer.

    Status Board 

    I guess the "who" and "what" fields are pretty easy to understand. The last three columns I used to track the status. A magnet in the "wait" column meant I  was waiting for customer feedback on some question I asked them. "Work" meant I could work on the issue in some way. At a minimum ask a new question. The "WI/D" column was used to track work item number (WI) and once issue was resolved it was "D" as in done.

  • Being Cellfish

    Fixing disk configuration/statistics mismatch on HPUX


    I recently was involved in troubleshooting a problem on a HPUX system.It turned out that the system command iostat showed one disk and the configuration (/etc/lvmtab) showed another disk. Yet another symptom was that lvdisplay didn't work at all. Since there had been a bunch of activity on that system it took some detective work to find out that the reason for the problem was that the raid controller had been replaced.

    So this still amazes me. The configuration said one thing and the monitoring tools another but still the host worked just fine. Actually it was a little slow but apparently the mix-up of disk devices didn't matter. So when other systems have their hardware changed you need to rescan it so how do you do that on HPUX? Well this is how you fix your disk configuration if you have one volume group named "vg00":

    In multiuser mode:
    #/sbin/vgexport -m / -s -p -v vg00
    Reboot the system and go to maintenance mode:
    #shutdown -ry 0 [Esc]

    Main Menu: boot pri isl
    Interact with the IPL?> y
    ISL> hpux –lm

    #/sbin/vgexport -v vg00
    #/sbin/mkdir /dev/vg00

    Create the special device file (SDF), use the next available minor number:
    #/sbin/mknod /dev/vg00/group c 64 0x##0000
    #/sbin/vgimport -m / -N -v -s vg00 vgchange -a y vg00

    Reboot the system to multiuser mode again.

    Preemptive comment response: No I don't know why the system was not reconfigured immediately after replacing the RAID controller. Probably because everything seamed to work after booting.

  • Being Cellfish

    What is a good team size?


    Your favorite Scrum book will say "seven - give or take two". If you look at group theory (such as FIRO) you'll see things like "five through eight" or "if the group is more than ten people you'll have smaller groups forming within the group". Another interesting way to decide on team size I read about is the "two pizza rule"; If you can't feed your team on two pizzas or less the team is to big.

    I think this a great way to describe maximum team size since it's funny and I guess it sticks. There might be a problem though since pizza size may vary. Two typical Swedish pizzas would not feed more than two or three hungry developers. If you go family size (or a typical US pizza I guess) you easily feed around five hungry developers. But I guess that is over analyzing the two pizza rule... Don't do that... Just buy two pizzas!

  • Being Cellfish

    Team Coding Dojo 1


    Today we had our first coding dojo in our team. We did the MineSweeper kata and once again the dojo ended up doing the same thing as usual; got to focused on the end to end tests and string parsing. During the retrospect we concluded that event though we had a short design session in the beginning we didn't really use that design for anything else than naming conventions. We also recognized that the first test written kinds of sets the key for the session. If the first test is testing end to end, then it is easy to continue on that path since you need a second test to refine the design. Instead a better approach is probably to pick some part from the design and start testing that. The school book BDD with outside in demands faking things underneath and if you don't do that you should probably not start outside in - you should to it the classical TDD way; create building blocks as needed - inside out. Or my favorite; middle out...

    But all in all (as usual) I think it was a fun experience and I'm already looking forward to the next session.

  • Being Cellfish

    Cash register feature

    A funny thing I've experienced here in the US is how the cash register systems at Fred Meyer and QFC (two large food store chains which apparently have the same owner). Most stores have offers where you get a discount when you buy more than one item (2 for $5 or $3 each). The funny thing about Fred Meyer and QFC is that you get the discount even if you buy only one item. So obviously their cash register software does not handle "group discounts" or they do not know how to configure it. Or it is a hidden feature which benefits the observant shopper. Either way; I like it.
  • Being Cellfish

    When to write passing tests before fixing a bug


    If you're a BDD/TDD practitioner you're probably used to create a failing test whenever you have a new bug reported and you want to fix it. But sometimes a situation arises where you have to do the opposite; creating a passing test before you fix a bug.

    Let me explain with an example. Let's say that you have code that uses date and time to calculate something. It all works fine. Then you go into daylight savings time and the test fails. Your first reaction might be to change the code to work but since you only have one test you might end up changing the code so that in half a year when you stop using daylight savings time the test fails again. So a better approach to handle this problem is to first create a test that passes before you change the code. Once that is done you have your (old) failing test and you fix the problem. Now you know you have code that works both with and without daylight savings time.

  • Being Cellfish

    Taskboards in virtual reality


    Jeff Sutherland tweeted about scrum boards in virtaul reality yesterday. An interesting idea in my opinion but I don't think it is for all teams. But it will defenitly work for some teams. It also reminds me of one thing I heard in the late 90's. The military experimented with virtual reality to have commanders from all around meet in a virtual room when they were given their orders. Since the military knows; giving orders in person is better than not. And virtual reality is as close as it gets I guess...

Page 1 of 2 (14 items) 12