niedziela, 21 marca 2010

I've become a PS guy

Rcently, I've bought a Playstation 3 console.
It is my first modern game console that I've bought. I also own Nintendo WII, but it was a gift and the only real game that I have is Zelda (some also may say that WII is not a modern game console). When I was a kid, I had Pegasus - it was some kind of NES clone. I played Contra, Dig Dug and other great games. Then I bought a PC (yep, I'm a PC ;)) and felt superior to my playstation / sega saturn / amiga friends ;) At school we were talking about number of polygons and comparison of benchmarks between Playstation and Voodoo. Not to mention, I always felt that PC's are far better that any consoles.
Currently, I'm not so religious about it. Three years ago I upgraded GPU in my PC and most games still run quite smoothly. However, I was thinking about buying a game console. For me decision was quite easy. Imho, Playstation 3 has far better games compared to Xbox (the only game I could be missing is Gears of War). Before buying PS3, I waited for one of this games to be realeased: Heavy Rain, God Of War 3 and Final Fantasy XIII. I've already finished Heavy Rain and currently I'm playing GOW3. I've got only one thing to say: PC guys - buy yourself a PS3! ;)

System.String and new() constraint

Few days ago, my colleague was dealing with code that was loading a list of objects from DataReader. Basically, for every record, a new object was created like this:
T obj = new T();
//set some properties using reflection
Of course, the method had new() constraint for type T. The method name was pretty generic, however the method couldn't handle scalar values like ints, floats, etc. (because it tried to set some properties through reflection). My colleauge changed the code and if the value was a scalar value (IsPrimitive seemed ok for us) the value from reader was casted to T and assigned to obj. My colleague mentioned that this method won't work for String because String doesn't have public parameterless constructor. To be honest, I didn't know that because I have never needed to write something like String str = new String(). I've always written String str = String.Empty. However, it seems really odd that you can't just say new String(). I asked about this issue on stackoverflow:
I suggest you read this post. Discussion in answers is really interesting.

I asked this question and thought about this issue for few hours. In our particular case, the code was clearly wrong. We created another method for scalar values without new() constraint. However, I still think that lack of public parameterless constructor for System.String is a .NET flaw (yet, as I said, I have never had a need to use it ;)).

środa, 17 lutego 2010

A project with that name is already opened in the solution

If you open visual studio 2008 and get error message "A project with that name is already opened in the solution" for one of your projects, and you have AnkhSvn installed it is quite probable that AnkhSvn is the cause of your problem.
After uninstalling AnkhSvn the problem disappears.


After receiving comment from AnkhSVN team, I installed AnkhSVN once again and the solution opened without any problems. If you had similar problems and you think it is connected to AnkhSVN, try reinstalling it, and the problem may be solved.

piątek, 22 stycznia 2010

Pai Mei's Second Lesson: How to eliminate dependencies on static utility classes?

Good design is very hard to achieve. It is even harder to come up with a good design before starting to implement the application. We often end up with one big project that has lots of inner dependencies on its own classes. The problem arises when classes rely on concrete implementation of logger class or some static configuration class. Code in these classes looks like this:
public void FooBar()
    string foo = Settings.Default.Foo;
    // some code
When you need to move some logic to another project (the most common case is creating a library that implements some specific functionality), you have to break these dependencies. Unfortunately, it will take some time and you will have to change a lot of code.

However, it is possible to avoid this kind of dependencies. You could use some IoC container such as Ninject, without relying on specific implementation of utility classes. Unfortunately, you have to rely on specific IoC container. However, it is very likely that you will use the same IoC container for every project in your solution, so it shouldn't be a problem. After changing the code, it looks like this:
IConfigurationProvider configurationProvider = KernelContainer.Kernel.Get<IConfigurationProvider>();
ILogger logger = KernelContainer.Kernel.Get<ILogger>();

public void FooBar()
    string foo = configurationProvider.Foo;
    // some code
Obtaining concrete implementation this way may not be the best pattern (compared to just marking properties or constructor with Inject attribute); however, this is the easiest change to make, without the need to instantiate every class through service locator.
Relying on interfaces and not depending on concrete classes will allow you to easily extract parts of your logic to external class libraries.
This style of coding has many more advantages that will be discussed in future lessons.

It's the wood that should fear your hand, not the other way around.

czwartek, 14 stycznia 2010

Pai Mei's First Lesson: How many method parameters is too many?

Welcome to Pai Mei's programming tutorial ;)

Lesson One: How many method parameters is too many?

Many times I see people struggling with maintaining their code because they have too many method parameters. They have lots of methods that take the same list of e.g. 8 parameters, and when it comes to adding another one, they have hundreds of places to change.

If your method has up to 3 parameters, it's probably ok.
If your method has between 4 and 6 parameters, consider creating a class which holds parameters that have something in common (thus limiting number of parameters).
If your method has more than 6 parameters, you have to find a way to limit their number. Creating a parameter object (as mentioned above) is the best way to achieve it.

Sticking to these rules will help you design better methods. They will be much easier to maintain.

And one more silver bullet. If you see methods that share common list of parameters, and what is more, all parameters create one logical object, consider creating a class that implements these methods. Remove the parameters by replacing them with class properties.

These two techniques are very easy to implement and dramatically improve your code design.

Since your arm now belongs to me, I want it strong. Can you do that?