Emad Alashi's Blog » Bunian

Beware of Static Constructors

Emad Alashi — Fri, 06 Feb 2009 22:39:22 +0000

In Bunian we needed to use a static constructor for some reason, it was all going good; we tested the code and it ran smoothly…excellent (Code Coverage anyone?!).
But when I came across this situation, it appeared that the static constructor wasn’t invoked!even when “Class.Method();” is called! so lets examine it.

I have two simple classes as an Example:

public class Parent
{
    public static string DoSomething()
    {
        return “Parent: DoSomething() called”;
    }
}

public class Child : Parent
{
    static Child()
    {
        Console.WriteLine(“Child Static constructor called”);
    }
 
    public static string DoSomethingDifferent()
    {
        return “DoSomethingDifferent() called”;
    }
}

As it may be obvious, Child inherits from Parent, Child has a static constructor that we need to be executed when ever a method is invoked by Child. Now lets check the main program executing these two lines:

Console.WriteLine(Child.DoSomething()); //This code will NOT invoke the static constructor
Console.WriteLine(Child.DoSomethingDifferent());//This code WILL invoke the static constructor

The surprise (at least to me) when calling “Child.DoSomething()” the static constructor isn’t invoked! because it is in the parent!! aaaaaah! bad!! that was serious for our architecture and we had to do lots of fixes to turns things around the right way (which I think it was for our own good for other reasons )

This brings up the Code Coverage topic as well; in our case that static constructor’s job was to create an instance of a member that is only needed once, and we check on it in other times by “if _instance != null”. It always ran ok because all the test code we created used to call an original Child before calling any other method that resided in the Parent.

bottom line: be ware of static constructors, and check your test code…it maybe hiding “surprises” for you

Get On With It!

Emad Alashi — Fri, 16 Jan 2009 15:56:35 +0000

When we started gathering requirements from the charity organizations for Bunian, it appeared that there are other kinds of people who benefit from the charity organization; there are “needy families” whose father is still alive but can’t sustain their families, and “students” who can’t afford their study.

So Bunian needs to support all these Beneficiaries in smart way; we solved the problem by creating the IBeneficiary interface. But the problem is that in order to get out with the best solution ever (damn perfectionism!), we kept coming up with different solutions, and overriding them with other solutions every once in a while, and this kept going like forever!

Though we agreed from the beginning that we shall keep it as simple as possible and then add up to it as we get out with the first phase, yet it kept sliding “ok only we have to do this, oh and that too”. Until one day I thought I came up with the silver bullet everyone talks about , and sent an email to the group about the changes I wanted to make, when a colleague caught me online and showed her objection about the new solutions, and proposed another. Only then I woke up!! “OMG…WE ARE STILL HERE!!”
Instantly, I remembered my oldest brothers comment (Mohammad, very wise brother) about Bunian “It’s great that you want to build the greatest architecture ever, but remember that Orphans are waiting!!”

So LET’S JUST GET ON WITH IT!! ship it!! do it!! let version one come out, let “customers” benefit from it, then you take your time doing your silver bullet. So this is one of the challenges facing the Project Managers, something we developers rarely think about ; today…I learned my lesson!

Importance of Documentation

Emad Alashi — Fri, 26 Dec 2008 11:25:15 +0000

Lately we have decided in Bunian to move on to NHibernate 2.0, and the contributor assigned to the move started out, only to send an email one day after: “THERE IS NO DOCUMENTATION!’.
We had errors as a result to the move which couldn’t be fixed without a documentation explaining why this happened.

After searching for a while, we found two resources of the new documentation:

a wiki help that is hosted on Google Knol:
http://knol.google.com/k/fabio-maulo/-/1nr4enxv3dpeq/21#
Not really appealing to be used extensively; no smooth flow between chapters, frames dazzle the eyes, no table of contents, but surely a great step forward for a documentation that is maintained by the community
and online ordinary documentation as HTML:
http://www.nhforge.org/doc/nh/en/index.html
which is my preferred way for documentation (or at least until the wiki proves its usability)

Neither links were included anywhere in the NHibernate zipped file.

I didn’t realize how important a documentation is until it stopped us from moving on in our project; Only after we made sure that the documentation is available we decided to move on to version 2.0. The lesson to be learned is that if you are an enthusiast developer and want to add another piece of code to the world, keep in mind that your project is not only code; it is people, resources, community, ease of use, documentation, and any other simple thing that people need while you think it’s not important.

Of course I couldn’t find developers or contributors to open source projects greater than the NHibernate team, having such a project in the first place is awesome, and I thank each and everyone of them. I hope one day I can really contribute back to NHibernate. Thanks again guys.