I had forgotten how much I hate dealing with web projects in Visual Studio 2003, until today.  I went to open up one of our companies VS 2003 web projects and didn't have a virtual directory configured before hand, so when it tried to open it complained it couldn't find the path to the csproj file.  OK, no big deal, open up inetmgr and create a virtual directory.  Well that was a good though, except I entered the incorrect path for the virtual directory.  Try again, change the virtual directory to the correct path and try an open the project again.  No good, I get this error now, "Unable to get the project file from the web server."  What the?

The fix: delete *.* from c:\documents and settings\sneal\VSWebCache.

I moved my little demo application (aka FoodBankTracker) that I use for demoing tech over to Visual Studio 2007 / .NET 3.5 today without much hassle.  The only real hassle I had was with log4net version/strong key mismatches between MonoRail RC2 and NHibernate 1.2 GA, but that's entirely another story.  The main reason I wanted to move it over to the new platform was to really try out the new language integrated queries (LINQ).  I ended up using the LINQ -> NHibernate criteria adapter being maintained by Ayende for several reasons:

1. My NHibernate mapping files are complete.
2. I like the unit of work NHibernate provides.
3. Its always good to have some abstraction between the domain and the database layer.
4. I'm familiar with NHibernate and already have infrastructure in place for it.

I grabbed the latest code from subversion for the LINQ -> NHibernate adapter and was up and running in no time.  The only change I had to make was to upgrade the NHibernate version from 1.2 beta3 to 1.2GA.  The hardest part was figuring out that I needed to add an assembly reference to System.Core for .NET 3.5 in my project.  Anyway, here's the one test I have working with LINQ and for comparison I'm also showing the original test without LINQ which does the same thing.

My little demo/test application that I monkey around with from time to time got a major revamp today.  Nothing fun or exciting, just a lot of infrastructure cleanup that I've been needing to do for some time.  I was hoping this would only take me an hour, but in reality it took me 3 times longer than that.  All I needed to do was:

1. Upgrade NHibernate from 1.2 beta3 to NHibernate 1.2 GA.
2. Separate out my shared core library into a separate folder/solution structure.
3. Stop using GAC'd Castle and NUnit assemblies and use a local libs folder to facilitate building on a clean box.

Nothing fancy, but I ran into some serious issues with log4net.  You would think that because most open source projects use log4net, integration of multiple open source products that use log4net would be a breeze right?  Well, Castle RC2 uses log4net 1.2.9.0 while the latest NHibernate release uses log4net 1.2.10.0.  That seems fine, just add an assembly binding redirect to have castle using the newer log4net version right?  Well that's fine until you realize that the log4net team unexplicablly changed their signed key between those releases, which means you can't use a binding redirect.  Oops, I doubt the log4net team intended that to happen.

To get around this version mismatch I ended having to grab the latest code from the Castle subversion repository which included log4net 1.2.10.0 and build my own assemblies that would play nicely with  NHibernate.

The moral of this story is don't change your keys between versions if they're binary compatiable/incremental updates.  Especially for something so commonly shared as log4net.

Anyone who's programmed in VB for a while will find this article interesting: http://www.codinghorror.com/blog/archives/000860.html

I didn't realize (or maybe truly understand) VB.NET had a background compiler in Visual Studio 2005 like Eclipse does for Java.  When I was programming in Java/Eclipse the background compiler literally saved me 20 minutes or more a day, its hard to believe C# doesn't have this even in Visual Studio "Orcas". 

The one thing I really from miss from VB is the with statement.  The with statement is very fluent and readable. In C# we could have something like the using statement:

Person user = new Person();
with (user)
{
   .FirstName = "John",
   .LastName = "Doe",
   .Age = 18,
   .PhoneNumber = 5555555,
}

The one thing we will have in .NET 3.5 is property initializers which are pretty close to the with statement, but the one difference is that the with statement would work anywhere.  Property initializers only work on construction of the object and really only save you from having to declare a bunch of overridden constructors.  Property initializers look like this:

Person user = new Person()
{
   FirstName = "John",
   LastName = "Doe",
   Age = 18,
   PhoneNumber = 5555555
}

Now what happens if I need to reuse an instance and assign different values?  Well, hopefully you won't need to, and in likely hood its very unlikely you would.  When I was programming in VB I generally only used the with statement to initialize an object.  What do you think?

I was reading this post by Jeremy Miller and came across this golden nugget of wisdom that seems to be very applicable:

"Oh, and the people out there swearing up and down that giving the business end users a screen to configure a business rules engine themselves will save the day?  BS.  Drawing workflow's with pictures is coding -- with every bit of the risk and danger that coding brings.  Only now you're making noncoders code in the production system.  Think about that last sentence. "

Bingo!  Allow me to elaborate on this:

• There are no unit tests surrounding the changes, which imply legacy “code”.
• No verification step.  QA is completely out of the loop, I doubt they would appreciate that.
• Engineers will need to be brought in to fix problems when something unexpected happens.  This is a reactionary situation which causes people to work over time and under stress, both of which I know I like to avoid.
• There is no formal change control surrounding the process.  This sounds bad, breaking the law kind of bad.
• Who wants to code through Visio or some one off custom UI anyway?  Last I checked Visio didn’t have a debugger, and if Visio doesn’t have a debugger certainly your one off custom UI won’t.  Good luck tracking a problem down without full disclosure to the system code and infrastructure.

These issues are not just merely applicable to business rules engines; they are also applicable to highly customizable applications with lots of admin screens.  Do you really want end users to be able to go in and add/remove workflows, user accounts, test points?  Do they really need these features?  Probably not, and this could potentially open up all kinds of data integrity issues.  Who really wants to restore a database from tape because some user made a change they didn’t truly understand?  This is why it’s important to have someone own the change process, like a development team or business rules expert.  Someone needs to be accountable for the integrity of the system.

On top of all this we need to take into account all of the extra work that will need to be done just to create the hellish user interface to the back end of the system.  Add documentation, testing, and training to the mix and you just doubled or tripled your system cost, and what have we gained?  We gained: lots of extra work, bugs, and data integrity issues.

Having the system be highly end user configurable makes the business feel more comfortable because they believe they’ll have ultimate control and flexibility.  Probably a far better solution (and more cost effective) would be to work on your trust issues with the business.  Put them at ease about the system by making them feel like they are part of a cooperative team rather than just a customer.  When release 1 hits they need to know the development will still be there to add additional features and fix any issues that crop up in a timely and predictable fashion.

In manufacturing wastes are well documented and generally understood, however in software development waste is acknowledged but usually misunderstood, especially by Microsoft Project Project Managers.  In many circumstances (especially in waterfall shops) the common root of all software waste is deemed to come from not planning enough, or not documenting enough.  Basically, all this effort is expended up front trying to ensure that the cardinal sin is not committed.  What is this sin?  Throwing code away. 

In reality we want to throw away code, as much code as possible.  I'm not saying we should generate code just to throw it away, but we should always be looking for opportunities to trim back the code base.  Less code is easier to maintain and test. 

Developers often think through tough business problems and technical problems by coding.  Coding is not just a statement of some requirement, coding is a mental exercise performed by programmers to better understand the problem domain.  It’s through coding we arrive at greater understanding and insight.  Coding allows us to make logical connections between entities, rules, and requirements.  During this research phase should the code be thrown away?  Not necessarily, but in all likelihood all this code will be thrown away as understanding of the problem domain changes over time.

If what I say is true, then throwing away code is not a waste, in fact throwing away code is quite productive.  Waste in software development comes from other areas.  Mary and Tom Poppendieck make the case that waste in software comes from the same areas as manufacturing, however with a slightly different software twist:

Manufacturing                             Software Development

---

In-Process Inventory          Partially Done Work
Over Production               Extra Features
Extra Processing              Relearning
Transportation                Hand Offs
Motion                        Task Switching
Waiting                       Delays
Defects                       Defects

An entertaining quote from the book I'm reading, "It is better for developers to be surfing than writing code that won't be needed."

They aren't referring to technical spikes or learning opportunities, they are talking about features to a real product.  In other words do option 1*, its cheaper.  Adding unneeded features to your code base will cost you more money over the lifetime of the product than paying the developer to do nothing at all.  Each feature you add complicates the code base making each additional change more costly.

* There are always 3 options to any decision, and option 1 is always "do nothing."

Right now I'm reading Implementing Lean Software Development by Mary and Tom Poppendieck, and something about the Toyota Production System caught my eye.

"Both Toyodas had brilliantly perceived that the game to be played was not economies of scale, but conquering complexity."

I translate this to mean, RAD code generated goo from Visual Studio versus elegant loosely coupled code based solutions (the kind most often found in OSS).

Thank you Google for providing with all kinds of useless, but entertaining, information.  From the Urban Dictionary...

A sneal is not quite a snack, nor is it quite a meal. A sneal lies somewhere in between the two, and snealing is most commonly practiced by college students. When confronted with the question of what the healthiest methods of eating are, it has been said that regular "snealing" is more beneficial to the individual than regular "mealing." A sneal, in most cases, is equivalent to 2/3 of a meal (This also means that 2 sneals equals roughly 1 1/3 meals). To date, the most common snealing plan involves a regular breakfast, a regular lunch, and two sneals in the evening (one typically at 5 p.m., the other typically at 8 p.m.). Though the average "snealer" eats two sneals a day, it is quite possible, and perhaps more beneficial, to eat three in a single day to support the growing minds of college students. Another part of the sneal involves 2 - 8 oz. glasses of the choice beverage. Though milk is encouraged to be at least one of these drinks, it is not absolutely necessary for a healthy sneal. If we sneal now at 5:30, we will still have time for another one before the cafeteria closes.

HTML textarea controls do not support the maxlength attribute like the text input control.  Doh!  The nice easy way around this is to add an ASP.NET regular expression validator with the following regex: ^[\s\S]{0,25}$

The only slight problem with this approach is that it is possible to input more than X number of characters, but the validator will display an error and disallow the page to be submitted.

Here are two sources of documentation for Rhino Mocks:

Articles

• http://www.codeproject.com/useritems/Rhino_Mocks_22.asp - This provides an integrated overview of how to use Rhino Mocks including examples.
  
• http://blogs.giffordconsulting.com/archive/2007/02/17/9949.aspx
• http://blogs.giffordconsulting.com/files/RhinoMocks%20QuickRef.pdf
• http://groups.google.com/group/RhinoMocks

Documentation

• http://www.ayende.com/wiki/(S(a00bey3wmfmvxc55ipic4kng))/Rhino+Mocks+Documentation.ashx -This provides more examples of the Rhino Mocks API beyond the article.
• If you are looking for “Cheat Sheet” type of help then look at:
• Methods: http://www.ayende.com/wiki/(S(a00bey3wmfmvxc55ipic4kng))/Rhino+Mocks+Method+Options+Interface.ashx
• Properties: http://www.ayende.com/wiki/(S(a00bey3wmfmvxc55ipic4kng))/Rhino+Mocks+Properties.ashx

Thanks Ray!

I converted my main .NET solution I'm working on from Visual Studio 2005 to Visual Studio Orcas without any problems.  I did the conversion so that I could play around with LINQ, and more specifically the LINQ to NHibernate adapter, and as such I chose to run everything under .NET 3.5.

I thought for sure I would get at least one conversion error or compiler error, but no.  My solution even included NHibernate and Iesi.Collections.  Better yet and possibly even more suprising is that I can still run and debug the web project which is using MonoRail RC2.