Mendelt Siebenga

While cycling home from work today I was listening to the Deep Fried Bytes episode with Rico Mariani. I should have been warned by his introduction; “He has an analogy for everything”. But since he seems to be a smart person the good old “Software engineering is just like structural engineering” caught me by surprise. I thought we ditched that one together with the waterfall process.Usually this analogy is used to get people to do big up front design. “You wouldn’t start pouring concrete for the foundations when you don’t know how many stories your building should have” In structural engineering you need to finish a design before you start building.

The singleton is probably the best known of the GoF Design Patterns, it’s also the most controversial. I try avoid using singletons in my code when I can but since the singleton is a very simple but powerful pattern I sometimes sin against the decoupling gods and use one or two of them. Lots of stuff has been written about creating singletons. In this post I want to show you how properly use a singleton and contain most of the damage singletons do.

I started using Resharper again after some time. And one thing that bugs me is that it always warns me that functions can be made static. I've kinda stopped using static methods. Static methods arent injectable, static methods make code using them less modular and less testable and static methods are the devils own handywork if you want to believe some people. On the other hand they make your code simpler by not requiring an object instance to be called. This got me thinking. Do I want to use statics or just ban them completely? And if not when is it ok to use them?

Temporal coupling in code is usually not very obvious but can cause maintainability nightmares. Code is coupled not by direct dependencies but by depending on the state that left behind by another piece of code. Temporal coupling is not something that should be avoided but it should be expressed explicitly. Someone editing your code should be able to see clearly where dependencies lie.

I haven't been programming much lately, I've been playing with Windows XP embedded instead. It's a great product that's not very well know. I'll probably be posting a lot more about this version of windows in the future so I thought I might start with describing my first impressions of it.

In the previous parts of this short series (that took a long time to finish) I looked at testing code that depends on pinvoke calls. I did this by wrapping the PInvoked functions in a class and then injecting that class into the depending code. I used the wrapper class to put some checks around the platform invokes to smooth some rough edges of the calls to unmanaged land. This creates a nice reusable interface around these calls but now we have the same problem we started with, testability. In this post I'll look at adding a final layer of indirection to be able to test this code.

I had a weird problem today. For a piece of software I'm creating I had to start an executable and then poll it periodically to see if it was still living. If it didn't respond for a certain time my program had to kill it and start over. There's a neat class in System.Diagnostics that can do this. System.Diagnostics.Process. But I found sometimes it acts a little strange.

Jurgen Appleloo posted this question on his blog. He wants to know what motivates you to do your job very well. He also promised $100 in books for the best answer if that isn't motivating I don't know what is. Actually I think the question is the wrong way around. I do this work because I love doing this. I had no work I would be programming (and looking for a job, I'm not that wealthy). I don't just love the technology, I love helping people finding solutions for their problems. Here is what I answered; I'm motivated to do my job very well from the start. Actually the thing that get's me motivated is being able to do my job well. But that's not easy. It means removing obstacles that keep me from doing my job like unwelcome interruptions, unrealistic deadlines, obstacles that keep me from communicating with future users. It means enabling me to work with tools and technologies that not only look good in demo's but actually make my job easier. It means g…

Joel Spolsky of Joel On Software and FogCreek fame and Coding Horror Jeff Atwood have been kicking up a lot of dust recently with Stack Overflow. We've been able to follow the developments around the creation of this site for about half a year now on their podcast http://blog.stackoverflow.com. And the site has been open for beta testers for one and a half months. I've been hanging around there for the last two weeks too. And since the site is going to be opened to the public tomorrow I thought this might be a good idea to write down some of my experiences and ideas around the site.

Sometimes it seems Visual Studio is set up for a completely different programming style than mine. For example the context menu's in the solution explorer has an "Add Class" item that I use often but there is no "Add interface" item. It's easy to customize Visual Studio so I set about adding this. Should be easy right? Right... I even had to write VBA to get it done, I feel dirty. But I got through it so you don't have to, enjoy!

In part one of this series of posts I explained how I usually set up PInvoke calls. I showed how to hide the calls themselves from consuming code so they don't have to duplicate the pre and postprocessing that's often needed. And I briefly showed how you could make the wrapper-calls non-static so you can mock the class they're in and that way test the consuming code. In this post I'll show exactly how to do this using the new Rhino Mocks 3.5 AAA model.

I'm big on unit testing, I like to test everything and I feel uncomfortable when I'm unable to write tests for some of my code. So even though some parts of your application are hard to test I'm willing to take some extra time to make them testable. In this post I want to show you some tricks I use to unit-test code that uses platform invoked functions.

The dotNet framework is pretty smart when it comes to marshalling managed to unmanaged datatypes for PInvoke calls. When you want to pass a Guid from the managed to the unmanaged world the framework knows how to transform the .Net Guid structure to a Windows GUID without you even asking for it.

I'm doing a lot of PInvoking lately. One of the hard parts is mapping the unmanaged datatypes found in c++ include files to managed datatypes.I found a nice article on codeproject with a list of the most common mappings. I'll repeat the list here so I can find it easilly, maybe other people can benefit from it too. I'll keep the list up-to-date with my own mappings and some remarks.