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
result.Add(obj);

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: http://stackoverflow.com/questions/2454914/system-string-why-doesnt-it-implement-parameterless-constructor.
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 ;)).

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.

UPDATE

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.

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
    Logger.Log("bar");
}

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
    logger.Log("bar");
}

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.

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?

Developer checklist

Every book about project managament in software industry starts with some sad statistics that sound something like this:

According to the Standish Group in 1995, only about 16% of software projects are successful, 53% challenged (that is cost overruns, budget overruns or content deficiencies) and 31% cancelled.

http://www.projectsmart.co.uk/why-software-projects-fail.html

Sometimes I think that it's just an excuse for incompetent project managers but let's assume that's sad true about software industry.
However, I must say that most software projects I worked on were successful in terms of customer paying for delivered software. I must admit that I've worked only in software houses and even if a client wasn't delighted he had to pay for the product.
As a developer, I'm not responsible for selling the product, I'm responsible for software architecture, maintainability and so on. From this point of view, many projects were huge failures. I don't have recipe for making successful software, but I know what leads to failure. If you don't follow this simple rules you will inevitably have lots of problems.
The rules are kind of best practices. I divided them in several sections ordered by their importance.

MUST-FOLLOW rules

1. Use version control system and more importantly learn how to use it.
   For example, if you work with SVN learn how to create branches, add properties, always write comments when commiting changes.
2. Create centralized error/exception handlers.
   I've seen so many projects that don't utilise this functionality. Distinguishing mark of such project is the need that every developer has to remember to catch exceptions in their routines, even though they mostly don't know what to do with them.
3. Log information about errors.
   This is connected with previous point but I want to emphasize proper error logging facility. Too many times I've seen code like this:
   

   public void LogException(Exception ex)
   {
       Logger.Error(ex.Message);
   }
   

   or:
   

   try
   {
       /* some code */
   }
   catch (Exception ex)
   {
       Logger.Error("Something bad happened");
   }
   

   If you don't know what really happened, you won't be able to deal with it. Remember, most errors will occur when application goes to production environment, not during debugging sessions.
   
4. Keep security in mind.
   If you work with sql database never ever let sql injection be possible in your app. If you work with directory service watch out for ldap injection. If you create web service - secure it. Never trust user input and never assume anything about the environment your app will be working in (or assume the worst).
5. Understand SOA if you really want to use it
   Service oriented architecture is very hard to implement properly. Many times people end up creating service that has thousands of completely unrelated methods or service that can take every argument and return every result. This is a real maintaince nightmare. What is more, if you publish your service definition it is almost impossible to change it without making breaking change. Services should be really well defined and many times it is just not the way to go. If you really don't need to publish some services to third parties don't do it.
6. Create good testing environment.
   If you don't have testing environment that is very similar to production environment you will fail. Deployment in production environment will be a nightmare and you will not meet your deadlines. I assure you.

SHOULD-FOLLOW rules

1. Don't mix presentation layer with application logic.
   It is repeated over and over but it seems that people will never learn. Sometimes it seems to be easier to put some logic in presentation layer but it is always bad decision.

MAY-FOLLOW rules

1. Unit testing / automated tests.
   Personally I consider it to be very important, but I've seen many projects that were well-written and had great architecture even though they didn't contain single unit test. What is more, they had almost no bugs. That's why I put unit tests only on "may" list.

These are my rules of creating software that has smaller chance of failure. Every time I forget rules from my "must" list I have serious problems. To be honest, few times I tried just to forget these rules and tried to create some workarounds because I considered implementing e.g. central error handling a breaking change to the code. However, I always ended up fixing it because breaking the rule had such a bad impact on the application. I've learnt from these examples that creating workarounds is just a waste of time. Unfortunately, it was learning the hard way. I hope you will find the list helpful.
Happy coding.

Coolest video games (ever)

I have love / hate relationship with computers and computer software.
I love beautiful code, I hate shitty code.
I hate hardware. All of it. Every piece of computer hardware is broken in some subtle way (if it works ok, it means that it hides its flaws from our eyes ;)).
On the other hand, I just love video games. Almost all of them. If it wasn't for Stalker I would probably say that I love all video games ;)
I play almost only pc games so I cannot include some great (at least I think so) titles such as God of War or Shadow of the Colossus because I haven't played them.

So here is my comprehensive list of best games (alphabetical order):

• 1942 (Atari)
• Beneath a Steel Sky
• Call of Duty
• Call of Duty 4: Modern Warfare
• Colin McRae Rally 3
• Command & Conquer
• Destruction Derby 2
• Discworld
• Doom 2
• Fallout 3
• FEAR
• Gears of War
• GRID
• Grim Fandango
• GTA III
• GTA IV
• Half Life 2
• Machinarium
• Max Payne
• Metal Slug (Arcade)
• Mirror's Edge
• Montezuma's Revenge (Atari)
• Mortal Kombat 2
• Portal (ok, it is on the list because of the Portal Song)
• Prototype
• Settlers 2
• Tomb Raider 3
• Warcraft 2

And the best game evar is Final Fantasy VII.




PS.
Few years ago I've beaten all the weapons, yay.
It took some hours of levelling up on Sunken Gelnika but it was so worth it ;)

PS2.
The list will be updated when other great titles come to my mind.