Monday, November 15, 2004

Notes from VS Connections

I am writing this blog entry, after the fact. I wish that I could have blogged "live", like so many other bloggers, but there just wasn't enough time. These are not all the events that I attended, just the ones that I took notes during.

Day One

The Keynote

The speaker was the product manager for Visual Studio. I wasn't particularly shocked by anything that was said in the keynote. The main point of the keynote seemed to be that they were opening up Developer Studio to more than just the coder role, so that other team members ( project manager, architect, tester ) could find a home there as well.

One neat feature: Visual Studio may now import .VSI files, which contain application templates. Various third parties will be supplying templates for common problems. This is integrated into a search facility, which you may execute from the "New Project" dialog.

Introducing Indigo

Nothing new here since any of the previous Indigo demos that I have seen. I did get a kick out of Indigo's composability, as this has been something for which I have aimed in recent designs. In my case, I am coding in C++ and add new functionality using the Strategy pattern. In Indigo, you can weave in new functionality with .NET attributes.

Windows Forms

90 minutes of dragging controls on to forms. Okay...I get it!

Web Services

It seems like everything is just an attribute that you slap onto a class. I often have a hard time believing that it is simple as adding [webservice] or whatever to a class.

Day Two

.NET


The presenter gave a more general talk about the biz value of moving to .NET CLR.

Generating Windows Forms Interfaces

Some interesting stuff, regarding code generation, databases, and user interfaces, but I think that the fundamental premise, using code generation to automate the building of CRUD forms is flawed. Dialogs should represent business actions.

The presenter did throw out an interesting aside: generating unit tests from method comments. I thought this was pretty cool. I'd love to be able to do this:

/*
multiply
x y retval
10 20 200
-10 20 -200
*/

int multiply( int x, int y ) {}

And automatically build unit tests from the comments.

Whitehorse

Whitehorse is a RAD tool for designing distributed systems. I was impressed with its potential and I very curious to see how far Microsoft can take it.

Day Three

Permission Based Security

.NET allows you to define required permission as attributes. Principal information is stored on a per thread basis. The presentation did not cover authentication, which I would have been a much thornier topic. I would really have liked to have seen the whole thing presented from end to end, as I think that Code Access Security is an incredibly important feature in .NET.

C# Generics

Way cool. A lot like C++ templates, except that you can define constraints on template parameters, which are expressed as required interfaces.

One of my favorite things about C# is that, like Java, it elevates interfaces into first class citizens. I have always found this to be serious deficiency in C++.

Thursday, November 04, 2004

Evolution

I have spent most of my professional life developing traditional Win32 applications in C++. Sometimes, I wonder how relevant this sort of application will be in the future.

Don't get me wrong. There will always be room for that sort of development, but in this increasingly interconnected world, smart clients and web-based apps make more sense.

Adam Bosworth states that web-based apps or services can evolve more quickly.

Well this is where the comment about evolution in action comes in. Things that breed rapidly more quickly adopt through natural selection to a changing environment. Services can typically deploy changes every month or even more rapidly because they only have one single configuration on a set of machines whose OS, storage and networking they totally control and which they manage in their data centers. These days Microsoft gives birth to new products at a pace that makes an elephant seem quick, about every 60 months, that means in the time that a service can make 60 adaptions to its customer's needs, Microsoft makes one. It used to be that they shipped every 12 months. Then 18. Then 24. And so on. The creep is driven by the ever increasiongly complexity of features, hardware, os variations, and backward compatibility of the API's so ably designed to lock developers in. They locked the developers in all right. The Microsoft ones. This alone to me has been a compelling argument that when a product can be delivered as a service, it should be.

Reading this makes me question some of the architectural decisions that I have made recently. The main virtue of a smart client is that it support off-line capability. If you eliminate this consideration, it would seem that a web-based client is always the way to go. I think the only remaining question, is whose tool chain to use?

Next week, I head off to VS Connections, where perhaps the trade-offs will become more clear to me.

Wednesday, November 03, 2004

Unreflective Actions

This morning on the Subway, I read Brian Marick's paper, Methodology Work Is Ontology Work in which he says:

I'm particularly interested in unreflective actions, actions people take because they are the obvious thing to do in a situation, given the way the world is.

I think this is a fantastic observation. Brian goes on to build a whole methodology "toolkit", covering a lot of ground from how we learn best practices to what is the best number of core values in a methodology (4), but I think this one quote makes the whole paper.

I cannot count the number of times that I tried to engineer a situation so that the only choice is the correct choice. This one concept may be applied to user interface design, architectural design, and code construction. It reminds me of manufacturing's poka-yoke, a device intended to prevent mistakes.

I wonder what changes I can make in my personal and professional life, so that I choose the correct action without reflection?

Tuesday, November 02, 2004

Re-usable Code

Keith Ray blogged about code re-usability as a set of rules.

I will summarize the rules that I like:
  • Write your class to avoiding depending on other classes (etc).
  • A class should have one responsibility, delegating other responsibilities to other classes.
  • A class should not depend on other concrete classes [except the most basic types like String].
  • To further allow substitution of concrete types, avoid using "new ConcreteClass" within your class -- particularly the constructors.
He goes on to say:

The user of your class may want to subclass-and-override. Make that possible by avoiding static, final, or non-virtual methods, and private methods. Private methods either need to be declared protected, or should be moved to another class and made public, with the original class using an instance of that other class.

And provides a set of rules for making classes easily extensible.

I strongly disagree with this sentiment. Making everything overridable may seem to increase the likelihood that your class will be reused, but it also makes it likely that the implementation of a class will be spread across several classes in your hierarchy. In the long run, this makes maintenance increasingly difficult, particularly if you choose to employ the Template Method Pattern.

I think it makes more sense to prefer containment to inheritance, and to mix in new behaviors with the Inversion of Control pattern.