Joris Dresselaers

I want to know God's thoughts... the rest are details. - Albert Einstein
Keeping track of your personal projects

I'm sure a lot of you know the drag of keeping track of personal ToDo-lists. You write down some stuff on a piece of paper and the next day, this paper has mysteriously vanished. Or you save them in an excel sheet, which is probably only available on your home PC. As I currently have a lot going on, I began a search for an online system that could fulfill my needs. Nothing fancy, just some basic functionalities. In my search, I landed on Tada List. This is a very basic online ToDo-list system. This article compares a few online systems. The Tada list comes in first and I can see why. It's a good tip to keep your personal life a little more organized.

Greetings.

Posted: Jun 24 2008, 08:30 AM by Jokke | with no comments
Filed under:
Assemble your own Ajax progress image

Hi,

I was looking for a nice loading image to show the progress of my page when making an Ajax call.

I found a nice website on which we can assemble our own progress images to use in combination with the UpdateProgress Ajax control.

An example below:

 

Regards,
Joris. 

Posted: May 14 2008, 03:33 AM by Jokke | with no comments
Filed under: ,
BMW M3 with M-DCT Available!

Hi People.

I wanted to share this with you guys, as it is quite cool.

The M-DCT system is a next generation transmission system, following the SMG system from the M5/M6. It is a double clutch transmission to make transitions between gears (7 of them) smoother and to reduce the 0-100 km/h time.

Below are pictures of this new transmission system.

M3 M-DCT


 

 

Not everyone was always as positive when talking about the SMG transmission. As the first M3's with M-DCT are shipping out, we can read the early reviews by the owners. Here is an example

 

And for those of you who can't get enough of this amazing car. Here is another link with pictures of just about every available configuration. 

 

It'll be a few more years until I place my order ;-)
Cheers.


[One more picture to stop]

Posted: Apr 02 2008, 06:59 AM by Jokke | with no comments
Filed under:
Exclude unwanted code from code coverage

Hi,

This is the solution for a problem I encountered a while ago.

When writing tests with Visual Studio, we frequently want to use the Code Coverage tool to evaluate our created tests. Though this is a good tool, we don't always want all of our code to be included in the coverage result. Let me give you an example.

I have created 2 projects:

  1. A class library [MyProject] with 2 classes: ClassToBeTested and MyException
  2. A unit test project [MyTestProject] for which I kept the default class. I renamed it to MyProjectUnitTest



The classes from the class library look like this:

public class ClassToBeTested
{
private const int MaxParameterLength = 5;
public int MethodToBeTested(string someParameter)
{
// Validate the parameter
if (someParameter.Length > MaxParameterLength)
{
throw new MyException("The length of the parameter was too large.");
}
return new Random().Next();
}
}
[System.Serializable]
public class MyException : Exception
{
public MyException() { }
public MyException(string message) : base(message) { }
public MyException(string message, Exception inner) : base(message, inner) { }
protected MyException(
System.Runtime.Serialization.SerializationInfo info,
System.Runtime.Serialization.StreamingContext context)
: base(info, context) { }
}

The Unit Test Class looks like this (I did snip some generated code): 
[TestClass]
public class MyProjectUnitTest
{
    [TestMethod]
public void ClassToBeTestedTest()
{
int expected = 0;
ClassToBeTested classToBeTested = new ClassToBeTested();
int actual = classToBeTested.MethodToBeTested("abc");

Assert.IsTrue(actual > expected);
}

[TestMethod]
[ExpectedException(typeof(MyException))]
public void ClassToBeTestedExceptionTest()
{
ClassToBeTested classToBeTested = new ClassToBeTested();
int actual = classToBeTested.MethodToBeTested("abcdef");
}
}

When we run the unit tests with code coverage used for MyProject, we get a code coverage result of  62,50% which is not as much as we would expect in such a small project.
Below, we can see that the reason for this low score, is the Exception class we use.

Now, if we create a project with many Exception classes, we do not want to write tests for all of these classes. I want to exclude this class from code coverage. If we search the net, we will find that there is no specific solution for this problem. There is a workaround though.
This workaround comes in the form of attributes. We have 2 possibilities:
 
1. [System.Diagnostics.DebuggerNonUserCode()]
2. [System.Diagnostics.DebuggerHidden()]

The first attribute we can use for both classes and class members. The second one, we can only use for class members: constructors, methods, properties and indexers.

As we want to exclude the whole class from code coverage, I will opt for attribute 1. We just place it on the MyException class (or any class you want to exclude).
We run the tests again, and take a look at the result:

Not only is our code coverage raised to 100%, the class on which I put the attribute has also disappeared from the results.

Important note
As you may have guessed, there is a drawback to using these attributes.
If you use the DebuggerNonUserCode or DebuggerHidden attribute, the code will be ignored completely; you won't be able to step into the code anymore. Also, any breakpoints you will add, will be ignored completely.

Make sure you don't just start adding the attributes for the sake of raising your code coverage score. Use this approach carefully as you might be excluding code from your results that needs to be tested!

 

Good luck.

Posted: Mar 28 2008, 01:35 PM by Jokke | with no comments
Filed under: ,
Thread-safe caching mechanism using a Hashtable

Hi. I wanted to start my first (real) blog post with some interesting material ;-)

On our current project we have been struggling with the following problem. We need a custom caching system that uses a static Hashtable to cache its items. As we work in a multi-threaded environment, this solutions needs to be thread safe. Which was off-course the difficulty.

Down the road we bumped into a few possibilities:

1. Using the lock() mechanism Visual studio provides

This was not a good solution as the creation of the instance was happening within the lock() statement. This had a really bad influence on performance. All threads would be in a waiting state whenever a new instance was created. So we moved on.

 

2. Using the ReaderWriterLockSlim class

This class is new in the .NET Framework 3.5 and is an improvement on the ReaderWriterLock class in previous versions of the framework. This young man wrote quite a good blog post on this topic. And this guy also came up with a thread safe Dictionary implementation (easily convertible into a Hashtable).

This solution was still no good as we were in need for a finer grained locking mechanism. This means that a lock can only occur when 2 threads are asking for the same object. When ThreadA is waiting on object X to be created, and ThreadB is also asking for object X and ThreadC asks for an instance of object Y, there may not be a waiting period for ThreadC. ThreadB though will always have to wait until ThreadA has completed its work and will then get a reference to the same instance created by ThreadA.

Close, but no cigar. We moved on again. 

 

3. The solution

After brainstorming with a few colleagues, we came up with a solution.

Instead of maintaining one Hashtable with the instances, we will maintain 2 Hashtables: one for the instances and one for the storage of locking objects. This way, we would only have to lock the instanceLocks Hashtable whenever we would instantiate a new object. The instance Hashtable would remain untouched during the creation period. The Instance Hashtable would still get locked afterward, but only to add the newly created instances to its collection. You might also recognize the double-check locking pattern to make sure the object being locked didn't change while locking it.

Voila, we found what we were looking for. Below is the code to accomplish this.

By the way: if you are wondering why the delegate is declared in the namespace; we did this so we can pass the method - which we call to actually create the object - to the Get method. This way, the creation of the objects is separated from the caching mechanism.

Hope this is of relevant use to you. Enjoy.

 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Collections;

namespace CustomCaching
{
public delegate TContract AnonymousDelegate<TContract>();

public class HashtableCache
{
private static Hashtable instances = new Hashtable();
private static Hashtable instanceLocks = new Hashtable();

public TContract Get<TContract>(AnonymousDelegate<TContract> anonymousBuildUpDelegate)
where TContract : class
{
string key = typeof(TContract).FullName;
TContract contract = default(TContract);

// See if the instance already exists, without taking a lock on it.
contract = TryGetInstance<TContract>(key);
if (contract != null)
{
return contract;
}

object instanceLock;

// The instance wasn't found on the first try. Now we take a lock on the hashtable.
lock (instances)
{
// Some other thread might have accessed the hashtable already,
// so do a second check.

contract = TryGetInstance<TContract>(key);
if (contract != null)
{
return contract;
}

// We still haven't found the instance, so let's create it.
// We keep a dictionary of creation locks per key;
// this is our fine grained locking mechanism.
lock (instanceLocks)
{
// If the lock is already created by another thread, use it. If not
// create one ourselves and add it to the locks hashtable.
if (instanceLocks.ContainsKey(key))
{
instanceLock = instanceLocks[key];
}
else
{
instanceLock = new object();
instanceLocks.Add(key, instanceLock);
}
}
}

// Now we take a lock on the finer grained object.
lock (instanceLock)
{
// Check again if the singleton was already created. If so return it,
// after removing the creation lock.
contract = TryGetInstance<TContract>(key);
if (contract != null)
{
RemoveInstanceLock(key);
return contract;
}

// We can now call the provided delegate to create our contract for us.
contract = anonymousBuildUpDelegate();

// Take a lock on the instances hashtable and add the created instance.
lock (instances)
{
// Double check: if the key does exist,
// something has gone wrong.

if (instances.ContainsKey(key))
{
throw new ApplicationException(
string
.Format("A duplicate key {0} exists in the hashtable.",
key));
}
instances.Add(key, contract);
}

// We remove the lock object from the locks hashtable
RemoveInstanceLock(key);

return contract;
}
}

private static void RemoveInstanceLock(string key)
{
// Remove the locking object from the dictionary if it exists.
lock (instanceLocks)
{
instanceLocks.Remove(key);
}
}

private static T TryGetInstance<T>(string key) where T : class
{
if (instances.ContainsKey(key))
{
return (T)instances[key];
}
else
{
return null;
}
}
}
}
Posted: Feb 15 2008, 09:26 AM by Jokke | with 1 comment(s)
Filed under: ,
Blog code formatting

Hi guys,

While writing my first blog post, I stumbled on the following problem: how do I format the code that I want to publish on the blog? It seems that when I paste my code in the blog editor, I lose all formatting (except for the coloring).

My good friend Wesley told me that a website exists for creating formatted C# code. In my google search (the first link I came across actually) I found a website that will do exactly that.

This site can transform C#, vb and some other code types into the correct format. Jaj!

I will give a before-after example of a testclass I created. Please don't mind the code, just mind the formatting.

Before:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace Reflection

{

public static class Class1

{

public static void SomeMethod(params string[] stackParams)

{

Class2.SomeOtherMethod();

}

}

}

 After:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Reflection
{
public static class Class1
{
public static void SomeMethod(params string[] stackParams)
{
Class2.SomeOtherMethod();
}
}
}

 

Best formatting wishes to you ;-)

Posted: Feb 14 2008, 06:37 AM by Jokke | with 1 comment(s)
Filed under: ,