Non-violent resistance

Some time ago I said that Pragmatic Programmer, The: From Journeyman to Master is quite a kitschy title.
How would you call this dedication?

This book is dedicated to all who teach peace and resist violence

JavaScript: The Definitive Guide by David Flanagan

How to uninstall Visual Studio 2010 Beta 1?

Few days ago, I decided to install vs 2010 beta 2. In order to do that, I had to uninstall vs 2010 beta 1 first.

After installing vs 2010 beta 1 there are many new applications in Add/Remove programs. Unfortunately, you cannot just choose vs 2010 beta 1 and uninstall all the applications. You have to manually uninstall all the components.

After first try, I ended up without ability to remove .NET Framework 4.0 Beta 1 and when I tried to start vs 2008 or vs 2005 I got error message saying that msvcr100.dll couldn't be found.
Cool, not only vs 2010 beta 1 was not fully uninstalled but also previous versions of visual studio stopped working.

After some searching I found this post: Uninstall Visual Studio 2010 Beta 1.
Well, it didn't work for me. However, it's quite interesting that you can find turorials how to uninstall vs 2010 beta 1 ;)
Here is mine. After reinstalling and trying to uninstall vs 2010 beta 1, I found out that following steps work for me:

1. Uninstall TFS Object Model (This step is Visual Studio 2010 Team Suite only)
   From Add/Remove, uninstall Microsoft Team Foundation Server 2010 Beta 1 Object Model
2. Uninstall .NET Framework 4 Beta 1
   From Add/Remove, uninstall in this order:
   Microsoft .NET Framework 4 Extended Beta 1
   Microsoft .NET Framework 4 Client Profile Beta 1
3. Uninstall Visual Studio 2010 Beta 1
   From Add/Remove, uninstall Visual Studio 2010
4. Uninstall C++ 2010 Redistributable
   From Add/Remove, uninstall Microsoft Visual C++ 2010 Beta 1 Redistributable

As you can see, steps are similar to steps from Scott Hanselman's tutorial, but the order is different.

If you struggle with uninstalling vs 2010 beta 1 maybe these steps will help you.

I am the key to the lock in your house or some thoughts about reflection and Singleton pattern

I wanted to present some thoughts about the Singleton pattern and assumptions you can make about it. This post also shows that using reflection is like going to the darkside ;)

Say, we have a class SingletonFoo that manipulates some PreciousResource. Access to PreciousResource must be synchronized and manipulation should be performed in critical section.

public class SingletonFoo : ObjectWithIdentifier
{
    private static int instancesCount;
    private static PreciousResource preciousResource = new PreciousResource();
    private static SingletonFoo instance = new SingletonFoo();        

    // Explicit static constructor to tell C# compiler
    // not to mark type as beforefieldinit
    static SingletonFoo() { }
    
    private SingletonFoo()
    {
        instancesCount++;
    }

    public static SingletonFoo Instance { get { return instance; } }        

    public void ManipulatePreciousResource()
    {
        // no need for locking, we are in a singleton!            
        Console.WriteLine("{0} is accessing the resource {1}", this, preciousResource);
        preciousResource.Manipulate();
    }

    public override string ToString()
    {
        return String.Format("{0} [instances count: {1}]", base.ToString(), instancesCount);
    }
}

For clarification here is ObjectWithIdentifier:

public class ObjectWithIdentifier
{
    private Guid uniqueId = Guid.NewGuid();
    public Guid UniqueId { get { return uniqueId; } }

    public override string ToString()
    {
        return String.Format("{0}, id: {1}", this.GetType().Name, uniqueId);
    }
}

ObjectWithIdentifier is only necessary for giving more meaningful output from the application.
We have a situation when someone creates Singleton and assumes that he may be sure that only one instance of this class exists in the system, so he doesn't have to synchronize access to some PreciousResource:

public class PreciousResource : ObjectWithIdentifier
{
    public void Manipulate()
    {
        //do something
    }
}

However, here comes the evil doer:

public static class EvilBar
{
    const int REPEAT_COUNT = 2;

    public static void BeNice()
    {
        Console.WriteLine("Now I'm nice");
        for (int i = 0; i < REPEAT_COUNT; i++)
        {
            SingletonFoo.Instance.ManipulatePreciousResource();
        }
    }

    public static void BeEvil()
    {
        Console.WriteLine("Now I'm evil!");
        for (int i = 0; i < REPEAT_COUNT; i++)
        {
            ((SingletonFoo) Activator.CreateInstance(typeof(SingletonFoo), true)).ManipulatePreciousResource();
        }
    }
}

When EvilBar is nice we get following output:

Now I'm nice

SingletonFoo, id: 7dbccd1c-4e74-4e1d-b762-104f4cbcb82b [instances count: 1] is accessing the resource PreciousResource, id: c2b4a8b7-80e8-46cf-b616-a3f45f0612d7
SingletonFoo, id: 7dbccd1c-4e74-4e1d-b762-104f4cbcb82b [instances count: 1] is accessing the resource PreciousResource, id: c2b4a8b7-80e8-46cf-b616-a3f45f0612d7

But what happens if EvilBar is trully evil:

Now I'm evil!

SingletonFoo, id: 5a829a65-580f-4cc2-b17b-2650f68e464b [instances count: 2] is accessing the resource PreciousResource, id: 8417a76b-a40b-4221-bd73-0b507ff059c9
SingletonFoo, id: 744eba58-9aa9-4ee2-97aa-ffd815c3832f [instances count: 3] is accessing the resource PreciousResource, id: 8417a76b-a40b-4221-bd73-0b507ff059c9

We have three instances of our Singleton class. One for singleton and two instance created with Activator.
Ok, the class was intentionally written to be evil. But was XmlSerializer written to be evil? Let's add another method to EvilBar:

public static void BeUnwittlinglyEvil(SingletonFoo foo)
 {
    Console.WriteLine("Now I'm unwittingly evil");
    Console.WriteLine("Foo before operations: {0}", foo);

    XmlSerializer serializer = new XmlSerializer(typeof(SingletonFoo));

    StringBuilder serialized = new StringBuilder();
    using (StringWriter sw = new StringWriter(serialized))
    {                
        serializer.Serialize(sw, foo);
    }

    SingletonFoo result;
    using (StringReader sr = new StringReader(serialized.ToString()))
    {
        result = (SingletonFoo) serializer.Deserialize(sr);
    }

    result.ManipulatePreciousResource();
}

After executing the method EvilBar.BeUnwittlinglyEvil(SingletonFoo.Instance), we get following output:

Now I'm unwittingly evil

Foo before operations: SingletonFoo, id: 5c4724bb-ac02-4300-9be6-70c86c5629fc [instances count: 1]
SingletonFoo, id: 58612540-6d6a-458a-8c0c-1f723117f9b6 [instances count: 2] is accessing the resource PreciousResource, id: e7a55b7f-4e62-4d1f-878c-499ec0387a31

The implementation looks weird, but that just an example what happens if someone serializes this class and then unserializes it. If the code is executed in different threads, you will run into synchronization issues.
In Pragmatic Programmer there is a nice quiz. Which of these things should never happen (answers are presented below the post):

1. A month with fewer than 28 days
2. stat("." ,&sb) == -1 (that is, can't access the current directory)
3. In C++: a = 2; b = 3; if (a + b != 5) exit(1);
4. A triangle with an interior angle sum \u8800 180°
5. A minute that doesn't have 60 seconds
6. In Java: (a + 1) <= a

I'm adding another thing to the list: singleton with more than one instance ;)
The point is, you always have to think about the things you can be sure about your code and about the ways people are using your code. The less you assume, the better.


List of things that should never happen:

1. September, 1752 had only 19 days. This was done to synchronize calendars as part of the Gregorian Reformation.
2. The directory could have been removed by another process, you might not have permission to read it, &sb might be invalid—you get the picture.
3. We sneakily didn't specify the types of a and b. Operator overloading might have defined +, =, or ! = to have unexpected behavior. Also, a and b may be aliases for the same variable, so the second assignment will overwrite the value stored in the first.
4. In non-Euclidean geometry, the sum of the angles of a triangle will not add up to 180°. Think of a triangle mapped on the surface of a sphere.
5. Leap minutes may have 61 or 62 seconds.
6. Overflow may leave the result of a + 1 negative (this can also happen in C and C++).

Syntax sugar, aop and things that mess up with you behind the scenes

The more I play with reflector, the more my head aches ;)
Suppose we have a simple class like this one:

class TestClass
{
public void SomeMethod()
{
Console.WriteLine("doing something");
}

public void SomeMethodWithArgs(int arg)
{
Console.WriteLine("doing something with arg {0}", arg);
}

public string SomeMethodWithArgsAndReturn(int arg, string str)
{
Console.WriteLine("again doing something");
return String.Format("result ({0} + {1} = <foobar>", arg, str);
}

public IEnumerable<int> SomeIteratorMethod()
{
int counter = 0;
while (counter++ < 3)
{
yield return 2 * counter + 3;
}
}
}

When I look at SomeMethodWithArgsAndReturn, in reflector it looks like this:

public string SomeMethodWithArgsAndReturn(int arg, string str)
{
Console.WriteLine("again doing something");
return string.Format("result ({0} + {1} = <foobar>", arg, str);
}

Cool, huh?
First three methods look the same in reflector and in code. But what about SomeIteratorMethod? It has that fancy yield statement. Well, it looks like this:

public IEnumerable<int> SomeIteratorMethod()
{
<someiteratormethod>d__0 V_0 = new <someiteratormethod>d__0(-2);
V_0.<>4__this = this;
return V_0;
}

I also have a new class:

[CompilerGenerated]
private sealed class <someiteratormethod>d__0 : IEnumerable<int>, IEnumerable, IEnumerator<int>, IEnumerator, IDisposable
{
// Fields
private int <>1__state;
private int <>2__current;
public TestClass <>4__this;
private int <>l__initialThreadId;
public int <counter>5__1;

// Methods
[DebuggerHidden]
public <someiteratormethod>d__0(int <>1__state);
private bool MoveNext();
[DebuggerHidden]
IEnumerator<int> IEnumerable<int>.GetEnumerator();
[DebuggerHidden]
IEnumerator IEnumerable.GetEnumerator();
[DebuggerHidden]
void IEnumerator.Reset();
void IDisposable.Dispose();

// Properties
int IEnumerator<int>.Current { [DebuggerHidden] get; }
object IEnumerator.Current { [DebuggerHidden] get; }
}

I've hidden implementation but that's just an implementation of an iterator. However, that's a lot of code compared to my simple yield statement.
Some time ago my friend said that he doesn't like most of the new c# 3.0 features (ok, yield was added in c# 2.0 but that's not the point) because that's just syntactic sugar and he wants to know what happens behind the scenes. My opinion was that I don't maintain msil/byte code so I don't care what happens behind the scenes.
BUT maybe i DO care? This post by Eric Lippert clearly shows that I care or at least I should ;)
Ok, that's an example of a compiler doing something behind the scenes, but what if we want to mess up with the code ourselves? Concept of aspect oriented programming and aspect weaver is this kind of messing up with code.
Let's look at PostSharp and create a basic example of logging of entry and exit to the method body. I've created a simple trace attribute using PostSharp:

[Serializable]
public class TraceAttribute : OnMethodBoundaryAspect
{
private void LogMethod(string beginning, MethodExecutionEventArgs eventArgs)
{
StringBuilder result = new StringBuilder();
result.Append("== ");
result.Append(beginning);
result.AppendFormat(" {0}.{1}(", eventArgs.Method.DeclaringType.Name, eventArgs.Method.Name);
//imma charging mah oneliner ;)
result.Append(String.Join(",", (from arg in eventArgs.GetReadOnlyArgumentArray() ?? new object[0] select String.Format("[{0}]", Convert.ToString(arg))).ToArray()));
result.AppendFormat(") -> [{0}]", eventArgs.ReturnValue);
result.Append(" ==");
Console.WriteLine(result.ToString());
}

public override void OnEntry(MethodExecutionEventArgs eventArgs)
{
LogMethod("Entering", eventArgs);
}

public override void OnExit(MethodExecutionEventArgs eventArgs)
{
LogMethod("Leaving", eventArgs);
}
}

I've added TraceAttribute to SomeMethodWithArgsAndReturn:

[TraceAttribute]
public string SomeMethodWithArgsAndReturn(int arg, string str)
{
Console.WriteLine("again doing something");
return String.Format("result ({0} + {1} = <foobar>", arg, str);
}

In the end when I run my app with:

(new TestClass()).SomeMethodWithArgsAndReturn(11, "twelve");

I get nice output:

== Entering TestClass.SomeMethodWithArgsAndReturn([11],[twelve]) -> [] ==
== Leaving TestClass.SomeMethodWithArgsAndReturn([11],[twelve]) -> [result (11 + twelve = <foobar>] ==

But now my simple method in reflector looks completely different:

public string SomeMethodWithArgsAndReturn(int arg, string str)
{
string ~returnValue~1;
MethodExecutionEventArgs ~laosEventArgs~4;
try
{
object[] ~arguments~3 = new object[] { arg, str };
~laosEventArgs~4 = new MethodExecutionEventArgs(<>AspectsImplementationDetails_1.~targetMethod~1, this, ~arguments~3);
<>AspectsImplementationDetails_1.PostSharpTest.TraceAttribute~1.OnEntry(~laosEventArgs~4);
if (~laosEventArgs~4.FlowBehavior == FlowBehavior.Return)
{
return (string) ~laosEventArgs~4.ReturnValue;
}
Console.WriteLine("again doing something");
string CS$1$0000 = string.Format("result ({0} + {1} = <foobar>", arg, str);
~returnValue~1 = CS$1$0000;
~laosEventArgs~4.ReturnValue = ~returnValue~1;
<>AspectsImplementationDetails_1.PostSharpTest.TraceAttribute~1.OnSuccess(~laosEventArgs~4);
~returnValue~1 = (string) ~laosEventArgs~4.ReturnValue;
}
catch (Exception ~exception~2)
{
~laosEventArgs~4.Exception = ~exception~2;
<>AspectsImplementationDetails_1.PostSharpTest.TraceAttribute~1.OnException(~laosEventArgs~4);
switch (~laosEventArgs~4.FlowBehavior)
{
case FlowBehavior.Continue:
return ~returnValue~1;

case FlowBehavior.Return:
return (string) ~laosEventArgs~4.ReturnValue;
}
throw;
}
finally
{
~laosEventArgs~4.ReturnValue = ~returnValue~1;
<>AspectsImplementationDetails_1.PostSharpTest.TraceAttribute~1.OnExit(~laosEventArgs~4);
~returnValue~1 = (string) ~laosEventArgs~4.ReturnValue;
}
return ~returnValue~1;
}

Wow!
Once again, I've got much more code but it's not in my source code. And once again do I maintain that code? Do I have to be aware of it? How much do I have to know about it?
So the answer can be: don't use any syntactic sugar, don't use aop. You're fine with your strings, ints and simple stuff. You understand how they work and you're cool with it. Are you? Did you know e.g. about this: String interning and String.Empty?
Eric Lippert's blog Fabulous Adventures In Coding is full of these stories. And just wait for c# 4.0 - Evil code of the day.

Time for final remarks or maybe just my opinion on this topic.
I really like syntactic sugar and I'm keen on learning aop concepts. The things I wrote about in this post are scary to me but I think we just have to deal with the fact that computer languages are complicated (even if they try to hide it) and concepts that are simple in everyday work hide their complexity behind the scenes. Look at c#. You've got transformation between c# and msil, you've got jit, clr executing all that stuff and somewhere deep, deep below the code you've written there are pure assembly instructions. Syntax sugar doesn't introduce that much complexity compared to all the other stuff that happens implicitly and we don't (have to ;)) know about.
Remember, there's no such thing as free lunch ;)

Stay away from these rocks we'd be a walking disaster

Some time ago my friend wrote a post about open - close principle - Open – Close principle / Object – Orientated Design in PHP. I hate to say that but there is something fundamentally wrong about the example in this post. I thought about it for a while and here are my thoughts on it.

Open - close principle doesn't encourage particular design - e.g. it doesn't say that it should be achieved through inheritance. Unfortunately, when you're into OOP, sometimes classes and inheritance and all that stuff cover the real solution. Imho, in example provided Image content type should not be hard-coded in particular classes. For me, content type is just a resource. For example, if you want to implement different language versions, you do it using resources, not through inheritance. You don't implement abstract Caption class and then EnglishCaption, FrenchCaption or PolishCaption. The same goes with content type of an image.
If you create base classes and mark methods as virtual (or you don't mark them as virtual because they are virtual by default like in Java), the point of doing it is to implement different behavior in particular classes. If you do it just to return different string and you don't implement any different logic, then maybe there is something wrong with the design.

Ok, that's the most important problem with the given example, but there also some more:

• abstract class is called AnImage, ImageBase or sth similar would be far better
• in every SendFileHeader in every derived class you are forced to write header("some type"), GetContentType as an abstract method and implementing SendFileHeader in abstract class as header(GetContentType()) would allow avoiding logic duplication
• and there is that SendToBrowserFunction that was better before the refactoring than after the refactoring, I'll describe it in more details below

Before the refactoring SendToBrowser looked like this:

public function SendToBrowser()
{
$strFileExtention = $this->GetFileExtention();
switch ( $strFileExtention )
{
case ‘gif’ :
header("Content-type: image/gif");
break;
case ‘jpg’ :
header("Content-type: image/jpg");
break;
}
$strFileContent = file_get_contents($this->fPath);
echo $strFileContent;
die();
}

and after the refactoring it looks like this:

public function SendToBrowser()
{
$this->SendFileHeader();
$strFileContent = file_get_contents($this->fPath);
echo $strFileContent;
die();
}

Before and after refactoring it has this nasty echo and even worse die. Yep, there is also that header function, but I guess changing these methods would be scheduled for further refactoring, because the author writes:

Our first implementation of Image class did not follow one other object orientated design principle. The Single Responsibility Principle.

Ok, let's get back to that switch that didn't follow open - close principle. Am I wrong or the switch logic looks for me like:

header("Content-type: image/" . $this->GetFileExtention());

What is more, the author states:

Why this class breaks the open-closed rule? If we need to send PNG image, we would need to change behaviour of SendToBrowser method and add new case to our switch statement.

Well, if we got rid of switch statement, the above code would also work for PNG. And if we came up to the conclusion that it doesn't work for some particular extension, I still think it should be implemented as a resource (some config file), not using inheritance.
Furthermore, GetFileExtension should be moved to File class, not completely removed.

I would also like to share some general thoughts. Imho, interfaces provide much better decoupling than abstract classes, especially in languages where you can inherit only one base class. Creating abstract class is more risky than creating interface. Also, too many abstract methods in abstract class lead to derived classes that have empty implementation of these methods. Creating interfaces is easier and more flexible.
Interfaces are also essential to loose coupling and technology that has been a real buzzword for some time now - dependency injection.

Eventually, I want to say that this post is not criticism of the author of the Image example. I'm quite sure that he understands open - close principle really well, but he just chose a wrong example. Or maybe I'm totally wrong and the cure is worse than evil? If so Hit me! Come on, hit me!

Programming - It's hard

I've just finished Martin Fowler's Refactoring: Improving the Design of Existing Code.
Great book with even better examples. That's the best one:

double getSpeed() {
switch (_type) {
case EUROPEAN:
return getBaseSpeed();
case AFRICAN:
return getBaseSpeed() - getLoadFactor() * _numberOfCoconuts;
case NORWEGIAN_BLUE:
return (_isNailed) ? 0 : getBaseSpeed(_voltage);
}
throw new RuntimeException ("Should be unreachable");
}

Imho, this book shows the most important thing about code that I have learnt during three years of working as a full-time programmer - quality of code DOES matter.
Heck, it matters a lot.
For me, the real revolution started after reading Ron Jeffries' Extreme Programming Adventures in C# or some time around it. I don't clearly remember if I was first into XP techniques and then read that book or whether I became a fiend of it after reading the book.
Clean, object oriented, readable code is my definition of pretty code.
When I read something like...

Use short names (like i, x) for variables with a short, local scope or ubiquitous names. Use medium length for member names. Use longer names only for global scope (like distant or OS interfaces). Generally: the tighter the scope, the shorter the name. Long, descriptive names may help the first time reader but hinder him every time thereafter.

... I just cannot understand how variable name "x" can do anything good. I really don't like variable names like i, x, var1, result11. They clearly show that someone wasn't thinking about the purpose of a variable. Imho, when you create a loop, call a variable index if it's index or at least idx. If you do that and begin to think about every variable name, you will improve your code. If you can't find appropriate name, maybe you should substitute it with a method call or change the way of thinking about solving a given problem.
The excerpt I quoted is from Seven Pillars of Pretty Code by Christopher Seiwald. I can't fight the feeling that the author tries to find a complicated solution instead of naming things appropriately and extracting functions. When I look at jam.c example, I can find many adjectives describing that code, but adjective pretty just can't come up to my mind.
The article by Christopher Seiwald is more than ten years old and it's not my aim to criticize the author. Maybe this article shows the way people were thinking about source code 10 or 15 years ago. I just wanted to show another view on code structure and other conventions that people follow.
In my opinion, source code should show programmer's intention. And here is another great example by Eric Lippert C# Round up.

Ok, but let's get back to refactoring. Martin Fowler says that before you start to refactor, you should have good unit tests. I cannot disagree with him, but I often find writing good unit tests really hard. Most systems I'm working with have architecture that makes unit testing a real pain. What is more, I often look at source code, and I see that it is properly designed and I can understand the author. The real reason is that unit testing is very very very hard and requires lots of experience. Here's a nice example - unit tests for Microsoft Enterprise Library (link).

Data — 56 tests will fail if you do not have Oracle installed. If you do happen to have oracle installed, you’ll need to manually open the Data\Tests\TestConfigurationContext.cs file and change your oracle connection settings.
Logging — EmailSinkFixture.LogMessageToEmail will fail, since you do not have access to our internal mail server. You can fix this by changing Logging\Tests\EnterpriseLibrary.LoggingDistributor.config on line 22 to reference different smtpServers and to and from addresses.
Security.ActiveDirectory — Tests will fail because you cannot access our Active Directory server. There are instructions about how to set up ADAM in Security.ActiveDirectory.Configuration.ADAM Setup. You’ll also need to change line 53 in Security.ActiveDirectory.Tests.TestConfigurationContext to reflect your ADAM setup.
EnterpriseLibrary — It is normal for several of the tests to occasionally fail. There are a few unit tests that are timing-dependent, especially in Caching and Configuration. These tests are testing whether or not something happens during a particular time interval, and sometimes the system delays the actions too long and those tests fail. If you rerun the test, it should work the next time. Additionally, our tests write to the event log, which occasionally fills up. If you begin to see a number of tests failing, check that your application event log is not full.

That's a nice suite of unit tests. Some DO fail, some don't. Run them if you like it...
Ok, it sounds like I'm making fun of Microsoft guys, but the point is that I also can't write good unit tests. The biggest problem I have is isolation of datasources, such as database of some kind or directory service.
Maybe using some kind of IoC would solve the problem, but it would require redefining the project design just because I want to write unit tests.
Currently, I'm refactoring without unit tests. I don't have confidence that I don't introduce new bugs or break existing functionalities. Sad but true. I cannot isolate directory service to some interface (without big changes in design) and I also don't have time to create and maintain domain controllers just for the sake of running unit tests on build server.
I hoped that I could find some unit test examples on Directory Programming .NET (especially here: http://directoryprogramming.net/files/3/csharp/entry24.aspx) but there are no interesting examples. Maybe because it's an example of CRUD and it would require integration tests, not unit tests.

When I started programming I thought it was simple. When I started working as a programmer and met real-life applications, it became clear that I didn't know anything about programming. Then there was some time when I thought that I learnt a lot and I really knew a lot about writing code and design, not about every possible technology, but I thought that technologies are similar.
Today, I feel that I have so much to learn and I see so many things that I should improve. I feel a bit overwhelmed, but, first of all, I feel excited and eager to learn all that stuff. Maybe "Programming - It's hard" should be changed to something as kitschy as "Programming - A quest for perfect code" ;)

Tomorrow I'm going on a two-week vacation. It's been a while since I last had a vacation and it could be hard not to think about programming at all (what bad could possibly happen?). Especially, when I'll be reading Pragmatic Programmer, The: From Journeyman to Master (talking about kitschy titles...) ;)

Don't add uninitialised data or check if it is not in md_rand...

Recently I blogged about static code analysis. I am learning more about it and when I have some more experience with nDepend I'll share some knowledge on this blog.
More than a year ago there was THAT story about random number generator in debian. Well, it was pretty funny and pretty serious. For me mostly funny ;)



And this is the famous revision: diff.
In comments the developer claims that Purify made him do it ;) I'm not saying that this is the effect of code analysis, it's just a funny story. Still...
The funniest part for me is that this bug existed for about two years before it was spotted.

For your consideration ;)