Dot Net What Not Posts

A while back I blogged about a situation where thinking out of the box helped me write some code more quickly. In a nutshell, I needed to extract an exchange rate from an XML feed, and found that by using F# to do it, then translating the code back to C#, it was much easier than trying to write the code in C# in the first place.

I thought it might be interesting to revisit this in both languages, and compare the two experiences. I found this to be a significantly better sales pitch for F# than anything else I’ve seen.

Having finally given up with dasBlog, and decided to join the rest of the world using WordPress, I was left with the painful job of transferring all my old blog posts across. One advantage this gave was the opportunity to re-read some of my old posts, and see how much (or not) my opinions have changed.

One of my older posts was written when I first started learning F#, and was hugely frustrated at the blatant lies told by a lot of the community in an attempt to convince C# developers to use F#. Whilst I was enjoying F#, and felt it had something fresh to offer, I was (and still am) really annoyed at some of the rubbish being written.

Well, it’s now over two years later, and not much has changed.

Not my invention, and not that new, but I’m surprised at how many developers haven’t come across these.

Read about the disappearing Heisenbug, the reliable Bohrbug, the complex Mandelbug, the frustrating Schrödinbug, the disastrous Hindenbug and the elusive Higgs-bugson!

Like many, our database has rather a lot of naughty nullable columns that really should be non-nullable, so we end up with null data issues all over the place. One way to avoid this is to modify the property in the .edmx file to add a default value. However, this is slow and painful, and easy to forget.

As there is no use case we can foresee where you would want a null string property, we have taken the step of adding a constructor to the entity (generated in the T4 template) that initialises every string property to an empty string. This means that whenever you create a new entity, any string properties will be initialised, avoiding any null values.

However, this leaves you with a problem if you want to set a (non-empty) default value for a string.

Many of the extension methods that we use have a signature that takes an Expression<Func<TSource, bool>> rather than just a Func<TSource, bool>? Ever wondered why? Do you even know what the difference is? No, nor do most people, but it’s worth getting to know, as it can be useful.

If you’ve ever had to write or read a regular expression, you won’t need any convincing that a tool to make this easier would be useful!

If you aren’t familiar with regexs (as they are colloquially known) then it’s worth getting to know, as they can be amazingly useful at times. Sadly, they can also be amazingly difficult to write, and impossible to read afterwards!

Here are a few tips for taking away the pain.

Does this sound familiar…

User: Your app just crashed
You: What happened?
User: It crashed
You: (sigh) What were you doing at the time?
User: Using the app
You: (sigh) What specifically were you doing?
User: I was clicking in that box
You: Which box?
User: You know, the one on the window you get when you click the other button
…and so it goes on

Read how we managed to get useful information about errors without having to suffer speaking to the users!

Not a common requirement, but as it can happen, and was an interesting one to solve, I thought it worth documenting. The scenario is this: For a medical system, there are a number of treatment sites (ie bits of the human body) that must be checked. For each treatment site, there will be a number of check types that need to be done. We needed to display this information in a grid like this (this is a prototype, so only shows True and False, rather than having checkboxes that can be altered)… The treatment sites are listed in the first column, and are pulled from a database table. The interesting bit here is that the 2nd column onwards are not fixed, these are also pulled from a database table, making the grid dynamic. We don’t know in advance what columns will be needed (other than the first one of course).…