.Net Ramblings

Construx recently wrote a white paper about software development’s most common mistakes. These mistakes are often called classic mistakes because they happen so frequently and have such predictable results. You can read the full white paper here (you’ll have to register to download it).

Of all the classic mistakes, the most frequent one is having an overly optimistic schedule where not enough time is given to complete a project. As I reflected on this it didn’t take me long to realize that it is also one of my personal classic mistakes.

In my first job I didn’t have much control of this mistake. Upper management personnel were the ones that set the deadlines for projects, and although my teammates and I regularly fought back and said we needed more time, the deadline was rarely extended. We were always able to meet the deadline, but many times we spent the next two to four weeks working out the bugs that were missed, and it didn’t make a good impression on our clients.

Currently I’m working at a place where I’m the only software developer, and although I am now the one that sets the schedule, I find that I also have the tendency to be overly optimistic on the deadlines, and I don’t have anyone to blame but myself. So I got to thinking why I have the tendency to be overly optimistic on project deadlines.

One of the causes I’m most prone to use is thinking in terms of how long it will take to create a working prototype of the application instead of creating production ready code with test coverage and clean, organized code. Many times I can get an application up and running within a day or two, but it doesn’t have any unit tests and the code is sloppy. It can take another week or two to clean up the code and write unit tests to get it production ready.

Another reason I find myself making overly optimistic schedules is because I base the schedule out of being able to work on it full time. However, I’m never fully able to actually work on the project full time because I get pulled into other projects and tasks.

I love playing with new tools and libraries, but I find that they are also another cause for this classic mistake. Tools usually save time on a project, but the learning curve when first learning a tool can drastically add time to the project, and I often times forget to factor in the learning curve time when deciding on deadlines. /For example, NHibernate has been a great tool I use and saves a ton of time, but the learning curve is large and it took me quite some time before I was up to speed with it.

I often like to think that I’m too good a software developer to fall into making classic mistakes, but it is evident that I’m not much different from others and have the same tendencies. But now that I know this mistake is one of my weak spots, hopefully I can be mindful of it in the future and not fall into making the same classic mistake.

I resonated with the following article by JP Boodhoo: http://blog.jpboodhoo.com/FocusOnFunAndStepIntoFreedomInYourCareer.aspx

I must admit I have lost the “fun” in programming lately and desire to get it back. One thing I’ve always wanted to do was be part of an open source project but I’ve been too timid to do so. I’ve also been overwhelmed by all the open source projects and not knowing which one I should commit to. So this past weekend I committed to working on the Fluent NHibernate project. This project allows you to make NHibernate mappings in the code, where it is compile-safe and has refactoring ability, instead of using the hbm xml files. I’ve used it in a couple of my projects and its fluent interface is very welcomed over the xml files.

So here’s to having fun programming once again.

I’ve been working on my LinqToExcel open source project over this Christmas vacation, and currently I am trying to allow method calls to be used in the Linq statement like the example below shows

private int GetLargeEmployeeCount()
{
  return 200;
}

public Company[] GetLargeCompanies()
{
  IExcelRepository repo = new ExcelRepository("companies.xls");
  var companies = from c in repo.WorkSheet()
                  where c.EmployeeCount >= GetLargeEmployeeCount()
                  select c;

  return companies.ToArray();
}

Let’s take a quick look at the created ExpressionTree.

Now let’s look at the method that handles getting the value from the GetLargeEmployeeCount() method. The SQLExpressionVisitor class is responsible for converting the ExpressionTree created from the Linq statement into the SQL statement that will be used. SQLExpressionVisitor inherits from the common ExpressionVisitor class to aid in walking through the ExpressionTree.

The pertinent node that deals with the GetLargeEmployeeCount() method is highlighted in blue above. The return value from GetLargeEmployeeCount() is retrieved in VisitMethodCall().

protected override Expression VisitMethodCall(MethodCallExpression m)
{
  if (m.Method.Name == "Where")
  {
    _sql.Append(" WHERE ");
    this.Visit(m.Arguments[1]);
  }
  else if (m.Method.Name != "Select")
  {
    object methodObject = ((ConstantExpression)m.Object).Value;
    object methodValue = m.Method.Invoke(methodObject, GetMethodArguments(m.Arguments));
    _params.Add(new OleDbParameter("?", methodValue));
    _sql.Append("?");
  }
  return m;
}

VisitMethodCall() is responsible for dealing with ExpressionTree nodes that contain method calls. It turns out that the where in a Linq statement is actually a method call, so we append a “WHERE” to the string sql statement. _sql is a private StringBuilder object that is used to construct the sql statement based on the ExpressionTree.

But the code we’re really interested in is contained in the else if code block. The select Linq statement is also a method call and we’re not interested in that, so we ignore it in the else if condition.

Now we’re interested in getting the return value of the method. Let’s take another closer look at the Expression node for the GetLargeEmployeeCount() method.

This node contains all the information we need to use reflection to get the method return value. The first thing we need to do is get the object that contains the method, which we can get from the m.Object property with some casting of types.

object methodObject = ((ConstantExpression)m.Object).Value;

Now that we have the method object, we can use reflection to invoke the method and get the return value. I first tried to use type reflection to invoke the method.

object returnValue = methodObject.GetType().InvokeMember(m.Method.Name, BindingFlags.InvokeMethod, null, methodObject, GetMethodArguments(m.Arguments));

However, this only works when the method is public. If it isn’t then a MissingMethodException is thrown. Of course, only being able to use public methods is not acceptable, so we need to use Invoke() on the MethodInfo object to invoke the method.

object returnValue = m.Method.Invoke(methodObject, GetMethodArguments(m.Arguments));

The rest of the code block (_params and _sql) deals with generating the sql from the ExpressionTree.

One last point of interest is the GetMethodArguments(). This is a helper method that takes ReadOnlyCollection<Expression> and returns an array of corresponding objects. You can check it out in the SQLExpressionVisitor class if you’re interested in its implementation.

It turns out that it only takes a couple lines of code to get the return value for a method used in a Linq statement, but I spent a couple hours researching how to do it, so hopefully this article will be of help to others who are creating custom Linq providers.

I am continuing to play with NHibernate and wanted to use MS Access as the database back end. I thought it would be an easy migration that required only a couple NHibernate configuration settings being changed below.

<property name="dialect">
  NHibernate.JetDriver.JetDialect, NHibernate.JetDriver
</property>
<property name="connection.driver_class">
  NHibernate.JetDriver.JetDriver, NHibernate.JetDriver
</property>
<property name="connection.connection_string">
  Provider=Microsoft.Jet.OLEDB.4.0;Data Source=db1.mdb
</property>

But when I started up NHibernate, I received the following error:

System.IO.FileNotFoundException: Could not load file or assembly ‘NHibernate.JetDriver’ or one of its dependencies. The system cannot find the file specified.

File name: ‘NHibernate.JetDriver’

It turns out I needed to add the NHibernate.JetDriver DLL to the project. This DLL is not part of the main NHibernate project. It is located in the NHibernate Contrib project on Source Forge.

Building the NHibernate.JetDriver

1. Checkout the source code from Source Forge
   1. url: https://nhcontrib.svn.sourceforge.net/svnroot/nhcontrib/trunk
2. Build the NHibernate.JetDriver project
   1. Directory Location from trunk: /trunk/src/NHibernate.JetDriver
   2. The easiest way to build it is using the NAnt script included in the project (default.build)
      1. the NAnt script creates a “build” folder and places the driver in there
   3. You can also open the project and build it from there
      1. The driver will be located in: NHibernate.JetDriver\bin\Debug

Once you create the NHibernate.JetDriver all you need to do it copy it to your project directory and reference it from your project and then you should be good to use MS Access with NHibernate.

Oren Eini posted his results from typealyzer which determines your personality profile by reading your blog. So I thought I would see what the typealyzer said about me based upon my blog.

INTJ - The Scientists

The long-range thinking and individualistic type. They are especially good at looking at almost anything and figuring out a way of improving it - often with a highly creative and imaginative touch. They are intellectually curious and daring, but might be pshysically hesitant to try new things.

The Scientists enjoy theoretical work that allows them to use their strong minds and bold creativity. Since they tend to be so abstract and theoretical in their communication they often have a problem communcating their visions to other people and need to learn patience and use conrete examples. Since they are extremly good at concentrating they often have no trouble working alone.

I would have to say that description fits me pretty well.