Express Free Forever!!!!!!!!!

I know everyone already knows about this. (It's two days old already :)
The Express Suite of products will be FREE FOREVER!!! That's right C#, VB.Net and the Web Express kits!!! All of them!

But to make it completely clear, here is Dan Fernandez' blog entry. Believe it! You have got to take a look at the new samples and starter kits, they are really exciting!

Composite Objects

Another OO lesson:

When working with complex objects, try to view them in groups of behavior. Don't view it as one gigantic object, split it into behaviorial groups. You can then take advantage of so called 'lazy' or 'late' instantiation. For example, you might have an "Insurance Policy" object. You don't want to retrieve and build the entire object every time. That would cause poor performance and memory overhead.
Instead have a minimum set of properties that are always retrieved and then group the remaining into separate objects. For example, coverages, underwriters, auditors, etc. You can then break those subgroups into smaller late instantiated objects as well.

A little extra though now will save you a great deal of performance pain later!

Running VS2003, VS2005, SQL2000 and SQL2005 on the same machine

We have some great tools at our fingertips but not all customers can migrate to 2005 right now so we need to not only be able to develop in 2005 but support our existing customers in VS2003/SQL2000.

One solution is to use Virtual PC. I've used it since 2004 and it does work well enough. The quirks are managable but performance can be problematic. And unless you're running a Quad, you really should only run one VPC session at a time. Virtual PC Server is better, but still the same concept.
Microsoft already had this in mind when they began to prepare the 05 release. You CAN run both sets side by side. There are only a couple of minor things to do to make this a much better development environment.

To make this happen, you should install the software in this sequence:
Prerequisite: a. Make sure IIS is already installed and running.

1) Install SQL 2000 and then install the latest service pack
2) If you need Reporting Services, then install it now (along with any service packs)
3) Install VS2003 full install
4) On the installed SQL2000 go to Server Network Utility and enable just the TCP/IP protocol. If Named Pipes is also enabled, disable it.
5) Now run the installer for SQL2005 and install just the Client Tools (Workstation Tools and Documentation Option in the installer).
6) Once the client tools are installed, go to Start->Run->SQLServerManager.msc and enable the Shared Memory in the Client Protocols section under SQL Native Configuration
7) Now run the SQL2005 installer. Please ensure that the account under which the services are run is an administrator of the machine and has all rights.
8) Reboot
9) Install VS2005 full install
10) Reboot

You know have a machine that you can develop in both VS2003/SQL2000 and VS2005/SQL2005.
Note that you can swap between ASP 1.1 and ASP 2.0 using the ASPNET_REGIIS utility or even better use Denis Bauer's ASP.NET Version Switcher. It's a breeze!

Clearing the air...

A few weeks ago, I had raised the question of the validity of OO development in the current technoligical environment. It was intended to make people think and remember why we architect apps the way we do (OOA, OOD, OOP).

However, there are still quite a few people mired in the 'disposable code' mindset and as a result, I have deleted a couple of posts just to clear the air.

I still intend to make people think before they code but I won't do it so confrontationally.
For now, we're going to get back to architecture, OOD and OOP. Sorry for the interruption.

Back to the tale of two programmers...

Some time back I really stirred the pot by telling a tale about two programmers: one used datasets and flat architecture and one used full architecture and domain models. In that tale, I made it seem like it was easier for the first developer to get something out the door. In this tale, we come back to the developers a year later. Mounds of functionality has been added and many changes have been made. One day the manager comes in and says "We're converting our app from a desktop app to a web app. And the data will all come from Web Services.". The two developers are stunned. But the second developer has a good object architecture and good layer segmentation. The task is a big one but in his/her case, only the UI and the direct db access portion of the DAL are changing. In the case of the first programmer, the task is so big that the current code is almost a complete loss.

There are pros and cons to every development method. But today's developers must be of a different mindset. We must develop with the intent of creating 'living code'. Code that can adapt to today's rapidly changing environments. The only way we can do that is to develop good architectures, good OO skills and patterns and good segmentation. Refactoring is the only way to keep the code alive and growing. 'Write once and live with it' type code is no longer an option. We have to 'write, reuse, refactor, extend'. If we don't write it in such a way that we can reuse, refactor and extend, then we're just wasting time.

Back to reality...

OK, after my last post, I had to just sit down and try a few things. One of the things I had to try was to write an app the old fashioned way (code heavy form, no DOM {Domain Object Model}, no framework). Pretty much a horizontal application.

It was even more frustrating than the mountains of code I have been writing in building DOMs. I don't know if I've become completely dependent on having a good architecture to code against or if I've simply lost the patience to write such disposable code.

I know Mark Miller hates intellisense, but I live by it. I can write much more code with many less keystrokes with it. And many of my mistakes are caught by the compiler instead of in testing. And I think that's the item I'm not going to be able to do without by not building a DOM for all of my apps. If I do build a DOM, most of the problems are caught before testing. And the errors that are caught in testing are problems that are common among the objects in the DOM and can be resolved across the board.

With that said, I think that the problem is not in the architecture, but in the tools. If I had a tool to deal with the mundain DAL and the generic data portion of the BOL then most of my frustrations would be eliminated.

Someone once said, when all you have is a hammer, then all you see are nails. We need more tools to help build better apps.