Tim Jeanes: Microsoft TechEd (Tuesday)

Today we saw a few more nice features that have been added to VS2008's javascript support.

First of all are the documentation-style comments you can add to your functions, just like in .NET. These are recognised by VS2008 and so appear in intellisense when you're writing your javascript, indicating the purpose of each function and any parameters. If you know that one .js file depends on another, similar comment tags can instruct intellisense to include the functions from that other file.

Also nice to see was how much easier it is now to call web services from within javascript, including catching the asynchronous result or failure. All with intellisense support, of course.

There was a point I missed yesterday about debugging javascript. When you debug a javascript file, Visual Studio grabs the javascript file from the browser: it doesn't assume that the .js file you had at compile time is what actually arrives there. Once you're debugging javascript, VS lists all the javascript files present in the browser and lets you put breakpoints in any of them. However, Visual Studio is clever enough to the map breakpoints from your compile-time javascript to what's found in the browser (and vice versa).


We also saw a whole load of more features of LINQ, this time focussing on LINQ To SQL. (That's SQL as in SQL Server, by the way. There'll be support for other SQL-driven databases such as Oracle with LINQ To Entities - due for release some time next year.)

Using LINQ to map your database to classes is ludicrously easy. VS2008 gives you a design surface onto which you position your database tables. ... and that's about all you have to do. That's sufficient for Visual Studio to create a class to represent each table in the database, properties between them to represent the joins, and a database context class to handle all your database transactions. This is very parametrisable: if you don't want to use the automatically-generated SQL to send data between your application and the database then you can easily wire up your own stored procedures.

If you don't like what the designer produces, you can take complete control yourself and build your own LINQ-enabled classes simply by adding attributes: there's a [Table] attribute for classes, a [Column] attribute for properties, etc.

This all fits in beautifully with the way we already work at Compsoft and we can't wait for LINQ to go live. It'll be a lot cleaner than the Gentle-based libraries we already have and will give us a whole lot more flexibility.

There's one issue that concerns us somewhat though: we find that our customers frequently want their databases to change. We're forever adding and removing fields, tables and joins. Though it's easy to regenerate your classes from the updated database structure, if you've done any customisation to that table (such as using stored procedures for the database transaction, or if you've changed how any of your fields will be represented as properties), those changes will be lost.

Most likely we'll be using the default settings for pretty much everything pretty much all of the time, so mostly this won't be an issue; however it's those tricky exceptional cases that could trip us up and take us by surprise when we change the database six months later. We'll have to see if we can catch someone at the "Ask The Experts" stand to get some guidance on this.


Though we're very excited about getting our hands on LINQ To SQL, LINQ To Entities will provide us with some nice further functionality. LINQ To SQL is limited in that you always get exactly one class for each table you're mapping to in the database.

LINQ To Entities will give you a load more flexibility and control over this. You can have your Customer class, for example, include fields from the CustomerContact table (so long as you provide the rules for how to do this). This will be beautiful - removing the hackiness of properties like Customer.DefaultContactName that we'll have to put up with in LINQ To SQL.

Conversely you can miss tables from your object model altogether, even though you're using them behind the scenes. The best example of this is that of a many-to-many relationship. Though you have a CustomerAddress table in the database, your object model can have just the properties Customer.Addresses and Address.Customers.


Moving away from the beauty of the upcoming backend language innovations for a bit, I took a look at what's coming up in SilverLight 1.1. This isn't so much my kind of thing - I'm much better at coding than at drawing - but it's nice to see how the next version of SilverLight will accommodate full C# support when it comes to altering it dynamically. Also, though in 1.0 javascript in your html can affect things in SilverLight, version 1.1 allows that relationship to be reversed: objects in SilverLight have access to all the controls on the rest of the page.

These two innovations give us a nice flexible model to work with. Our partners in the newly-formed BlueSulphur can focus their efforts on making beautiful-looking SilverLight objects, and we (the coders) will be able to control them from the page and also receive feedback from the SilverLight object to affect other controls on the page.


It takes a certain kind of courage to run a seminar entitled "Why Software Sucks" at a developer conference. It takes a certain kind of optimism to run it over the lunch break, and it takes a certain kind of genius to make it one of the fullest and most entertaining seminars so far. "Know thy user, for he is not thee" is what it all comes down to and is so true: it's far too easy to focus on writing great code rather than to focus on making a great user experience, and this is why - in terms of the number of complaints registered annually - software development fares worse than both debt collection and used car sales.


One gripe though: why must so many presenters insist that they "go ahead and..." do something instead of just doing it? Today I counted 21 "go ahead and"s in five minutes, peaking at four in thirty seconds.


Seminars today: WEB304 (Omar Khan); TLA308 (Luca Bolognese); LNC01 (David Platt); WEB302 (Jesse Liberty); WEB307 (Neil Padgett); DAT201 (Carl Perry)