Darwinian Economics ;)

When Darwin proposed his theory of evolution and survival of the fittest he was right in more than one way. In today's market the only businesses that survive are those that are able to adapt to the uncertain economic conditions. In such an environment we as IT Professionals share a similar fate, we must be fast, agile & able to adapt. For, it is us the IT professionals that must support the constantly changing aspects of the business. It is with these thoughts in mind that I've continuously worked towards developing those traits that would allow me to be agile and effective under any circumstances.
As a Software Architect and Technical Lead, I've tried to position myself in a way that allows me to be quickly effective in a variety of projects. Jumping from the project a to project b and now to project c, here are some of my thoughts regarding what the those traits needed for such an environment are.

1. Thinking of Reusability: When I take on any project, I always think to myself how do build it so that I can leverage it in the future. It is with this idea that I've been able to accumulate a framework and a set of proven patterns and practices that allow me to hit the ground running when I approach new projects.
2. Taking the Initiative: One of the challenges that comes with reusability is that reusability lends itself to stagnation. Therefore to avoid this fate, I'm always taking the initiative in adapting the frameworks, patterns and practices I've developed to newer technologies and patterns that would give me greater reusability.
3. Building the Right Team: Having the right team is as critical to the project as having the business requirements. Without the right team, any project would be in jeopardy. So what makes the right team? To me the right team is built around trust and mutual respect. It is composed of team members that I would trust to make the right choice in my stead. Hence, when I conduct interviews I rarely focus on candidate's particular skills. Instead I'm always focusing on the choices he would make.
4. Scope Management: When it comes to achieving success and raising the victory flag it is important to know what it means to succeed. Defining a scope that allows you succeed is what I've been stressing we strive for in the projects I've worked on. The correct feature set that gives the biggest bang for the buck to the business at the right time is what defining scope is all about.
5. Agile Development Methodologies: Agile development are methods that I've tried to follow in order to gain the most and mitigate risks associated with a changing business. These methods include the focus on building bench strength and communal ownership from the beginning of a project, as well as a focus on iterative delivery of small feature sets. The methods allow for more accurate estimation of feature delivery as well as providing the ability to shift focus should the situation arise. It also plays in very nicely with our maintenance transitioning strategy and operational risk countermeasures strategies because bench strength and communal knowledge are at the core of Agile development.

Entity Framework & Lazy Loading

For the last 2 years I've read and read the EF team swearing by their design decision to turn lazy loading off by default. Heck they even went the extra mile to change the name and obscure the option (Deferred Loading anybody?).

I just found out, that the latest CTP has lazy loading on by default and guess what? it is actually called "Lazy Loading"...

I don't know about you, but I find all this somewhat irritating. Albeit, a bit vindicated. :D

NHibernate, Oracle & Clobs

If you are starting to work with NHibernate and Oracle you will definitely go through a lengthy stressful process of denile, understanding and acceptance.

So here I will share a bit of knowledge that will make that process a bit less stressful.

If you are working with clobs/nclobs and oracle you may or may not have encountered the following error when using the microsoft provided system.data.oracleclient

ORA-01461: can bind a LONG value only for insert into a LONG column

This error is not very helpful and goggling it will most likely result in topics regarding oracle patches and the like. In reality this is a bug with the microsoft oracle client driver. The driver mistakenly infers the column type of the string being saved, and tries forcing the server to update a LONG value into a CLOB/NCLOB column type. The reason for the incorrect behavior is even more obscure and only happens when all the following conditions are met.

1. when we set the IDbDataParameter.Value = (string whose length is : 4000 > length > 2000 )
2. when we set the IDbDataParameter.DbType = DbType.String
3. when DB Column is of type NCLOB/CLOB

Unfortunately NHibernate 2.0's default behavior is to do exactly the above, making it quite more likely to run into this ugly bug when using nhibernate and oracle.

It is also unfortunate that the issue has indeed been raised with the NHibernate community but has been closed as external. http://nhjira.koah.net/browse/NH-465

I pretty much figure that since Microsoft has decided to pull their driver from the .NET framework in the future, they wont fix this external issue, so it becomes the burden of the developer to work around this ugly bug. So without much further ado here is the way I've gotten around fixing this issue.

I created a custom driver and inherited from the Oracle client driver where I override as follows.

/// <summary>
/// Initializes the parameter.
/// </summary>
/// <param name="dbParam">The db param.
/// <param name="name">The name.
/// <param name="sqlType">Type of the SQL.
protected override void InitializeParameter(System.Data.IDbDataParameter dbParam, string name, global::NHibernate.SqlTypes.SqlType sqlType)
{
base.InitializeParameter(dbParam, name, sqlType);

//System.Data.OracleClient.dll driver generates an exception
//we set the IDbDataParameter.Value = (string whose length: 4000 > length > 2000 )
//when we set the IDbDataParameter.DbType = DbType.String
//when DB Column is of type NCLOB/CLOB
//The Above is the default behavior for NHibernate.OracleClientDriver
//So we use the built-in StringClobSqlType to tell the driver to use the NClob Oracle type
//This will work for both NCLOB/CLOBs without issues.
//Mapping file will need to be update to use StringClob as the property type
if ((sqlType is StringClobSqlType))
{
((OracleParameter)dbParam).OracleType = OracleType.NClob;
}
}

I will try reopening this issue with the NHibernate commiters and see if it now warrants an update.