Configuration of the tests

I find myself in the dilemma of having to run my tests in a new database with a new set of data. This should not be an surprising event, but it does require that I "update" my tests to the new reality. Cause I cant use the same keys, as before.

So how does one solve this problem. I thought up two different solutions, where one is pretty nifty but time consuming, and the other is more slow, but probably the one I am going for.

The first one, is to circumvent the util being tested, and access the database directly, and auto generate the needed row keys ect. here, one could use the loved (and hated) datasets of .NET

The second more boring one is simply to make an xml file, containing all the configuration- the key to be used for testing get methods, the search critia for the list search, and the expected size of the result, ect. For this solution one misses the ease of java's properties library.

After surfing the Net, I found this article on CodeProject "Managing configuration settings persistence in .NET applications", which describes how to read a xml file into a dataset. I will try that solution.

This post will be updated...

logging in client proxy

I have found myself wondering what is a good logging strategy. There are several levels to consider, when you are implementing a client/proxy for an existing server. So far there are two major scenarios, where its interesting to log, one can be said to be sub case of the other.

-Regular logging where you are just interested in logging the fact that there is been send a request to the server, when, what and who.

-Debug logging where its interesting to look at the execution path through the client code. which will pinpoint anything strange. This can of cause also be done just by stepping through the code, but I would be much easier if one were able to insert enough debug writes to support an easy identification of the exceptional behavior.

Since the regular logging of the 3 w's is included in the debug logging, my plan is to include this info as a normal debug output, and then just filter it, to make the prober log file which is an requirement.

The overall strategy (using log4net) is the following levels:

- log fatal if the client losses the connection to the data source
- log error if there is thrown an exception or an err code is returned.
- log info when a workflow is finished. (for example the data written in a dump file)

More posts will follow of how to set up everything...

removing spyware

Once again has the "Coding Horror" blog written a very useful blog. As a computer scientists I am always expected to know how to save virtually any system from virus and stupid users. One of the top problems, I always run into is people which have allowed spy ware onto their computers, making them slow and unpredictable.

In the linked blog, there is a description of how to remove spyware. (link)

Enjoy cleaning...

Reflection

Reflection is the mechanism of discovering class information solely at runtime. Reflection has been introduced with the .NET framework, and its usage of metadata.

Metadata is data about data, and in .NET framework it is contained along the code, to allow, among others reflection. The Metadata consists of class names, method signatures and the like, to enable both for runtime lookup of a class (i.e reflection) but also to enable the cross language execution. When the compiler compiles code, it always create the metadata along with the compiled code, and puts it in the assembly.

Reflection means being able to get instantiate a class of a type, just by providing the name of the class at run time or invoke methods just by presenting their name.

The use of reflection is slow and should only be used when absolutely necessary (link).

Maybe more later

Software developer you are you owne worst nightmare

Stop writing code, its just more lines where bugs and errors can hide. The following is snippet I have copied from one of my own favorite bloggers Coding Horror, which writes about "the best code, is no code at all" where he actually references another blog written by Wil Shipley who argues that we should rein in our natural tendencies to write lots of code:

The fundamental nature of coding is that our task, as programmers, is to recognize that every decision we make is a trade-off. To be a master programmer is to understand the nature of these trade-offs, and be conscious of them in everything we write.

In coding, you have many dimensions in which you can rate code:

* Brevity of code
* Featurefulness
* Speed of execution
* Time spent coding
* Robustness
* Flexibility

Now, remember, these dimensions are all in opposition to one another. You can spend three days writing a routine which is really beautiful and fast, so you've gotten two of your dimensions up, but you've spent three days, so the "time spent coding" dimension is way down.

So, when is this worth it? How do we make these decisions? The answer turns out to be very sane, very simple, and also the one nobody, ever, listens to: Start with brevity. Increase the other dimensions as required by testing.

Which is some very clever words. You cant have everything, and the things you want, always comes at a cost of something else.

Now go coding and remember to use the KISS principle (Keep It Simple Stupid)

Properties in C#

All good programmers have spend hours made getters and setters. So Microsoft have decided to make it a bit harder (I think now, I might change my mind later).

Heres an example of old time code

public class MyClass
{
private int x;
public int getX()
{
return x
}
}
ect.
In you application you can get x with the following code:
mc.GetX();

Now C# provides a built in mechanism called properties to do the above. In C#, properties are defined using the property declaration syntax. The general form of declaring a property is as follows.

<acces_modifier> <return_type> <property_name>
{
get { }
set { }
}

This means that I can do the top example the following way:

Where <access_modifier> can be private, public, protected or internal. The <return_type> can be any valid C# type. Note that the first part of the syntax looks quite similar to a field declaration and second part consists of a get accessor and a set accessor.

For example the above program can be modifies with a property X as follows.

class MyClass
{
private int x;
public int X // property
{
get
{ return x;}
set
{ x = value;}
}
}

The object of the class MyClass can access the property X as follows.

mc.X(10) // setter.
y = mc.X // getter.

I think its a step in a good direction, but splitting the attribute and the property is in my view, just as bad as not having them.

equal types in vb.net and c#

Even though c# and vb.net uses the same libraries, there is some differences in what name identify the classes, below I will make a list.

vb.net	c#
Boolean	bool
Date	System.DateTime
String	string
int32	int

And keywords:

vb.net	c#
Shared	static
Friend	internal
ReadOnly*	const*

*)
const:

- Can't be static.
- Value is evaluated at compile time.
- Initiailized at declaration only.

ReadOnly:

- Can be either instance-level or static.
- Value is evaluated at run time.
- Can be initialized in declaration or by code in the constructor.