I did a presentation on Indigo to the VBUG London group last night.  The turn out was pretty good, although it was obvious that many English football fans were missing (though they probably would have enjoyed the User Group more than the humiliating defeat).

Off the top of my head, here are the things that keep standing out for me about Indigo:

• The power of separating choices about the binding from the code that a developer writes.  Being able to switch from the tcp with a binary encoding, to reliable messaging over HTTP, to MSMQ just by changing the configuration file is great.
• The simplicity of the programming model.  The majority of the functionality that required Enterprise Services, such as Instancing and Sessions, are available using attributes on either an interface/class or a method such as ServiceBehavior or OperationBehavior.
• The fact that the details of the protocols are hidden under the covers.  Instead of focussing on the WS-* protocols, the focus is on the functionality required.  This has taken me a while to get my head around after having used WSE, which is powerful, but involved having to understand a lot of the details of the underlying protocols.

I'm looking forwad to some of the Level 400 sessions at the PDC, such as Kenny Woolf's presentation on Channels.

As Mehran noticed, I couldn't help but show off the Refactor! tool that's shipping for free in Visual Basic 2005.  This was in response to an attendee who believed that Visual Studio was 'a multi-megabyte bloated version of notepad'. 

Mike Taulty has a sign-up page for UK PDC Attendee Bingo.  I'm going to be at PDC and it would be great to catch up with others, especially those from the UK.  There's already a very interesting bunch of people heading over from the UK whom I look forward to catching up with.

Strong bodily reactions are a great way to measure the impact of new technologies.  While many US technical conference crowds like clapping when they see new features demoed, I think the best reaction is a more modest bodily reaction. I'll never forget the time I shivered after seeing Eric Gamma demonstrate the Refactoring support in Eclipse a couple of years ago.  One area of .NET 2.0 that is generating strong bodily feedback is ASP.NET 2.0's support for Custom Build Providers.

First there was Fritz dropping his jaw when he created a custom build provider that took his custom XML metadata file which he dropped into the app_code directory that automatically generated the strongly-typed classes for him.  Tonight I discovered that Kirk Allen Evans had a similarly-sized bodily reaction when he created a Custom Build Provider that automatically created XmlSerializer classes that allows you to drop a schema into the app_code directory and automatically generate the XmlSerializer class.

I'm with these guys: Custom Build Providers are cool (bodily reaction: light goosebumps).  I'm passionate about finding ways of driving application development through the use of metadata files and the Custom Build Providers are an innovative way that ASP.NET provides to support this kind of development.  The only downside I can see is that the creation of these classes is slightly 'automagical' and requires that developers understand what the framework is providing under the covers.  However, I think this initial learning curve is more than compensated for by the productivity that Custom Build providers enable.

Kirk Allen Evans has an interesting post about proposing a distributed architecture for a client where he finds, after doing performance testing, that the speed difference between different transports reduces as the amount of work done within each call increases.  Based primarily on this finding he's recommending ASMX web services as a better strategy than using COM+/Enterprise Services for his client.

I remember coming across this arguement at TechEd 2004 in Amsterdam where Christian Weyer spoke about some Thinktecture research which showed that the difference in speed between Web Services and other distributed technologies (remoting, enterprise services/COM+) was significant if the work done in the distributed call was minimal, but once a reasonable amount of work was being done the performance difference became less and less important.  Worrying about the speed of the transport without thinking about the amount of work done in each call is a little bit like worrying how fast a car can rev if you have it in neutral.

Of course, this is all keeping with the long-known guidance from the Indigo team, which is to start with ASMX and only go to other options if you need specific features that they provide.  Richard Turner's recent white paper provides more details.

Save the date - Saturday 22nd October 2005 is the next DeveloperDeveloperDeveloper day!.  We're planning another free community-driven day of talks on developer-related topics.  Craig Murphy has more details.  Jonathan Hodgson has updated the event website (including a countdown ... 84 days to go!).  There's a form you can fill in if you'd like to present a session.

For now, feel free to join in the discussion on the Channel 9 site.

I observed two minutes silence in Trafalgar Square in London today to remember the victims of last week's bombings.  I enjoyed being part of a public display of solidarity by gathering in a large crowd in the streets again.  My thoughts go out to those where were affected by the events.  It was strange experience to be in the centre of London and have relative silence as the only sound was of some vehicle's engines on idle as all of the traffic was stopped.  I felt very proud that London is a place where so many people from different countries, with different religious beliefs can get along together. 

You can see the Kalido offices on the fifth floor of the building shown below (from the BBC News website) and if you looked hard enough you could see me in the crowd.

Bill Wagner, fellow RD, and author of the excellent 'Essential C#' has an article on Code Project that debunks the conventional wisdom that String.Equal is better than Operator == for strings:

... for the string class, Operator == and String.Equal() will always give the same result. Period. You can use either interchangeably without affecting the behavior of your program. Which you pick will depend on your own personal style, and the compile-time types you're working with.

The == operator is strongly typed, and will only compile if both parameters are strings. That implies that there are no casts or conversions inside its implementation.  String.Equal, on the other hand, has multiple overloads.  There is a strongly-typed version, and another version that overrides the System.Object.Equals() method. If you write code that calls the override of the Object version, you will pay a small performance penalty. That penalty comes because there is a (slight) performance hit for the virtual function call, and another (slight) performance hit for the conversion. Of course, if either operand has the compile-time type of object, you'll pay for the conversion costs anyway, so it doesn't much matter.

The bottom line on equality and strings is that if you use the method that matches the compile time types you're working with, you will certainly get the expected behavior, and you'll likely get the best performance. If you want all the details, see Item 9 in Effective C#.

I'm posting this because I've had this discussion a few times and believe that Bill's explanation is the best I've seen.