Being Cellfish

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

February, 2010

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

    Using C# properties to create a domain specific language

    • 2 Comments

    So this is nothing new really. People have been creating DSLs using methods and properties for quite some while now I think. But I recently used it to make my fakes (in the unit tests) easier to understand. And I think it turned out pretty neat. Here is an example of what a fake could look like:

    1: public class FakeDatabaseWithOneUser : IMyDatabase 2: { 3: List<User> _users = new List<User>(); 4: List<Address> _addresses = new List<Address>(); 5: List<Invoice> _invoices = new List<Invoice>(); 6:   7: public FakeDatabase() 8: { 9: _users.Add(new User("First", "Name")); 10:   11: public FakeDatabase AndTwoAddresses 12: { 13: get 14: { 15: _addresses.Add(new Address("Delivery Address")); 16: _addresses.Add(new Address("Invoice Address")); 17: return this; 18: } 19: } 20:   21: public FakeDatabase AndOneInvoice 22: { 23: get 24: { 25: _invoices.Add(new Invoice()); 26: return this; 27: } 28: } 29:   30: // IMyDatabase implementation not shown here. 31: }

    And using that fake a unit test could look something like this:

    1: [TestMethod] 2: public void SelectedUserShouldListAllAddresses() 3: { 4: IMyDatabase db = new FakeDatabaseWithOneUser().AndTwoAddresses; 5: Assert.AreEqual(2, db.SelectUser(1).Address.Count); 6: }

    But why do I use properties and not methods? I know there are people who think this use of properties violates the semantics of a property since the getter changes the state of the object. I don't agree. First of all these are not properties, these are part of my DSL. Second I think getting rid of the parenthesis (which would be there if these were methods instead) is nice and makes the code look better.

  • Being Cellfish

    Things you don't want to do with properties in C#

    • 2 Comments

    I was working with some code a couple of weeks ago and I stumbled over this "interesting" "pattern"...

    1: public class SomeApiWrapper 2: { 3: private string _method = ""; 4: List<string> _arguments = new List<string>(); 5: private string _instance = ""; 6: private string _result = ""; 7:   8: public string Method 9: { 10: set 11: { 12: _method = value; 13: ExecuteIfReady(); 14: } 15: } 16:   17: public string Instance 18: { 19: set 20: { 21: _instance = value; 22: ExecuteIfReady(); 23: } 24: } 25:   26: public string Argument 27: { 28: set 29: { 30: _arguments.Add(value); 31: } 32: } 33:   34: public string Result 35: { 36: get 37: { 38: if (_result.Length > 0) 39: return _result; 40: throw new InternalErrorException("Method not executed."); 41: } 42: } 43:   44: private void ExecuteIfReady() 45: { 46: if (_instance.Length > 0 && _method.Length > 0) 47: _result = SomeApi.Execute(_instance, _method, _arguments); 48: } 49: }

    So what is happening here? Well, first of all you need to set the arguments, the method and the instance properties and then you just get the result. Setting the properties magically executes the method and stores the result as soon as you've provided enough information for the method call to be completed. An interesting twist however is that you cannot set the arguments last since the method is executed when you have set method and instance properties. the ordering between these two are however irrelevant...

    Please don't do this. Ever. Properties should not have side effects in general and especially not side effects that are dependent of the order in which they are called. That is only confusing at best. If you read what I wrote the other day you might be confused because a DSL created using properties will have side effects. Well, no rule without an exception! Also consider properties that are lazy loaded (i.e. they do a costly retrieval of values only when asked but then remembers that value). That is also going to be OK. But the pattern you see above is not.

    Preemptive comment: No this pattern was not seen in any code created by a Microsoft employee.

  • Being Cellfish

    A new unit test framework for C++

    • 1 Comments
    Today I learned about something I did not expected. A new unit test framework for C++ called Igloo. Still a very early version but I kind of like what I see. It is simple to create new tests (much simpler than CPPUnit for example) and also it has a nice way of building asserts. Looks promising I think.
  • Being Cellfish

    Squeezing performance out of memcmp usage

    • 1 Comments

    When I wrote this the other day it made me think of another thing involving the memcmp function and the VC compiler. In the code I've seen over the years where memcmp was used it was always to find out if an area was identical or not. So the code typically looked something like this:

    1: if (memcmp(a, b) == 0) 2: doSomething(a); 3: else 4: doSomething(b);

    However another very common pattern is to write code like this:

    1: if (!memcmp(a, b)) 2: doSomething(b); 3: else 4: doSomething(a);

    Turns out the latter results in faster code when compiled (at least with the VC compiler)! How is that? Turns out the compiler recognizes that you're not really interested in if memory block a is lower or greater than block b and the key to do this is the not operator. So by using the not operator the compare operation does not need to find the first difference and calculate which block is less than the other. The compiler instead generates code that just checks if the memory blocks are equal or not, which is much faster.

  • Being Cellfish

    Taking responsibility for failure

    • 1 Comments

    So the thing I wrote the other day made me think about another thing. Toyota is doing what they should. Taking responsibility for the failure, learning from it. Toyota is not unique in this way. I think most companies today have realized that you get a better reputation when you treat customers with respect and take responsibility for failures. But it also made me remember this story I heard somewhere. It was told by some swede living in Japan. The story goes that this person was traveling using the subway and there was a twenty minute delay. Annoying but nothing special if you're used to the subway in Stockholm, Sweden. To this person's surprise, when they exited the destination train station there were subway employees at the exits personally apologizing to each traveler and handing out delay certificates. That's what I call taking responsibility for a failure. You can read more about it here.

  • Being Cellfish

    Working in war teams is great

    • 0 Comments

    One thing that came up in the retrospectives as a good thing a few times in my previous team was working in war teams. So what is a war team? To us it meant that whenever we ran into some kind of problem, a difficult bug, a big design challenge or similar we format war teams. Sometimes the war team was two people and sometimes it was the whole team. The war team focused on solving that single problem and nothing else. So what we said in the retrospects was that working in these teams was better than when everybody was working on their own tasks. I guess the explanation was that it was a great satisfaction in solving a difficult problem and also it is great working together with others. And this was in an environment where the team was sitting together in an open landscape and not in separate rooms.

    What that taught us was to do as much pairing as possible when completing tasks. To be honest, it is hard to teach old dogs to sit and I guess that is why it came back in the retrospects from time to time. So what made me think about this today was that I stumbled over this old article about war rooms. It compares teams where each team member sits in their own cubicle compared to teams sitting together. I think that is the basic start to make any team more productive (more suggestions here). But once you have your team in the same room you want the team members to scramble around a few tasks rather than working on different things. As the article about war rooms point out; the team might say they don't like it but once they try it, they will probably love it...

  • Being Cellfish

    Words, words, words

    • 0 Comments

    So I've mentioned this topic before; choosing the right words to send the message you want. But this time I just want to mention a good read on the topic of using words. The short version is:

    • At least one experiment showed that the words a person is exposed to can change behavior.
    • Agile development tend to use words with positive meaning when waterfall use words that typically are associated with negative feelings.

    That's all for now.

  • Being Cellfish

    On Toyota's recent recall of cars

    • 0 Comments

    So the company who gave us lean is recalling a lot of cars because of break problems. I don't think it is something spectacular there. Sometimes these things happen and you do what you have to do. But there is another dimension of this I just cannot resist to mention... Apparently it is a software problem. Well that in it self does not make this any more interesting I think. Because Toyota is using their own manufacturing system for software development too, right? Turns out that that is not necessarily the case. According to this report Toyota uses A more "traditional" spiral model.

    Does this mean I believe that this would not have happened if Toyota used lean in their software development? No, not really. I just think it is a fun coincident and it still raises two questions: Why have Toyota chosen a different approach to software development and would a lean approach have change things or not?

  • Being Cellfish

    Considering future performance in your database

    • 0 Comments

    Ten years ago I worked on a project where we did a lot of fancy things with a number of databases. I learned a lot during that project but I also heard a funny story a coworker told me:

    I was called in to fix a problem with an accounting system. The customer described the problem as an invalid status message. It turned out that when they did reports and searches on the master table holding all financial activities it took several minutes to complete. This was not the customer's concern. They were concerned that the status message said "hold your breath and count to a hundred", which was false since the operation typically was not completed before you could count to a hundred...

    The basic problem was that the developers never tested the database nor the accounting system with enough data to simulate several years of accounting information. You don't want to do that. There are also a number of other things you probably don't want to do. This article (register for a free account to read) covers a few good things to look out for. For example you there is usually a bad idea to do "IF (SELECT COUNT(*) FROM ... WHERE ...) > 0" when "IF EXISTS (SELECT 1 FROM ... WHERE ...)" works just as fine without the potential problem actually counting the number of rows.

Page 1 of 1 (9 items)