Matthew makes the announcement in a blog post:

So, you may ask yourself, there are already groups out in the DC area, such as CapArea.NET, RockNUG, CMAP, DC XP Users group among others. They are great user groups that put on a lot of great events that I have attended time and time again and at some point presented at one of them. It's my belief that this group can supplement them nicely and help each other out. Many of these groups spend a lot of time talking about the new things coming from Microsoft. That's a very good thing, but that's not what we're aiming for. The goal of this group is to form very active discussion groups and find new and better ways to develop software. This group practices the Open Space Technology and encourages people to bring topics to talk about.

First meeting is this Thursday, Dec 13th.

Join the mailing list, and watch for the roaming meeting to reach a location near you in the D.C. / Baltimore metropolitan area.

... is choosing the right names.

Local variables need names. Instance variables need names. Methods need names, too, as do classes, columns, delegates, events, files, forms, parameters, projects, products, services, styles, tables, and of course – namespaces. Namespaces are nothing but a name! So many names, and so few words to use.

I was thinking about the amount of mental effort I expend in basic programming activities – like picking control structures (foreach versus do-while), or data structures (stacks versus lists), versus the amount of effort I expend to name all the abstractions in the simplest piece of software. Loops and structures are easy – naming requires a great deal of time and thought.

After all these years of thinking about names, I still struggle to pick the perfect name. Naming is a skill I need to improve - because names are important. I can use all the right patterns, have 100% test coverage, exceed every performance requirement, and still feel like I've failed if the names produce a piece of software that looks amorphous carbon:

Bad names kill good software by making the software un-maintainable.

Here are some interesting reads on naming:

• Hacknot – Naming Classes – Do It Once and Do It Right
• Tim Ottinger – Ottinger's Rules For Variable and Class Naming (note: I don't believe in #8 as a default).
• Jeff Atwood – I shall call it ... SomethingManager
• Jeremy Miller – SomethingManager Classes
• W3C Style Naming Tips – Use class with semantics in mind
• Roy Osherove – Naming standards for unit tests

I'd like to find more. Know of any others good ones?

In my last post, I looked at using managed code in Silverlight as a replacement for JavaScript and offered the following code as an example:

In my opinion, the managed code API offers a sub-optimal experience relative to the plain and simple JavaScript that would implement the same functionality. To be fair, Silverlight's mission isn't to replace JavaScript, HTML, web browsers, and motherly love (as yet, I guess), but I wanted to explore the idea.

In an ironic twist, Microsoft's Live Labs released a preview of Volta this week with the following key messages:

• Volta automates certain low-level aspects of distributing applications across multiple tiers, allowing programmers to devote their creative energy to the distinguishing features of their applications.
• Via declarative tier splitting, Volta lets developers postpone irreversible design decisions until the last responsible moment, making it faster and cheaper to change the architecture to accommodate evolving needs.
• Through MSIL rewriting, Volta follows developer's declarations to turn a single-tiered application into a multi-tiered application, generating boilerplate code for communication and serialization.

The first two bullet points make me uncomfortable. "Declarative tier splitting" sounds a lot like a movie I saw during the COM+ days. In that movie a hero by the name of "Location Transparency" was killed by 10 million chatty microbes from the Andromeda galaxy. It was a slow death, and a sad ending.

Two things sparked my interest in Volta, however. Seeing Erik Meijer at the helm of Volta was one, and MSIL rewriting was the second. There are MSIL re-writing tools available today (see the profiling API and Mono.Cecil as examples), but mainstream MSIL re-writing can bring many benefits to the CLR. One only has to look into Java land where bytecode modifications yield interesting possibilities for aspect oriented programming, inversion of control scenarios, application optimizations, and more.

The result was that I downloaded the new bits and gave Volta a spin. Volta can run client applications in the browser, so I continued the "how to kill JavaScript" bit by trying my C# code using the Volta programming model:

... much closer to the model I was looking for, and it works in IE and FireFox, too.

Wait! What about the Document.GetByID method? Is that a static method on a static class just waiting to plunge a knife into the heart of a unit test? No – it turns out Document is a property on the Volta Page class that implements an IJavaScriptObject interface (hooray!). You can almost taste the testability, except that Document is a read-only property (boo!). I hope that the MSIL re-writing in Volta will give us the ability to inject mock Documents for testing.

It will be interesting to see how project Volta progresses.

Some say DOM scripting will end in fire,
Some say in Silverlight.
Still others say with much desire,
That either will suffice.

(apologies to Robert Frost).

The arguments I hear go like this: if a developer can build on a cross-platform CLR with a diverse selection of languages and still interop with the browser, than why would the developer stoop into the primordial ooze of HTML and script against a document object model that has more eccentricities than the city of San Francisco?

In other words, if I can write the following in C#:

... then why bother doing dynamic HTML using JavaScript? The tools built for C# code are far, far superior to anything written for JavaScript. Even when running a bare Visual Studio with no plugins - I have better refactoring tools, a better debugging experience, and (even in 2008) – better Intellisense when using C#. There are class diagrams, code snippets, and code browsers. Not to mention the support of a base class library that includes many features you won't find all in one place with JavaScript – real meat and potatoes stuff like string formatting and collection classes.

Certainly paints a bleak picture for JavaScript, doesn't it?

Well, one reason Silverlight doesn't replace JavaScript is that Silverlight doesn't run everywhere. If you want to reach the widest possible audience, including cell phones with a script interpreter - you'll still be giving JavaScript some love.

Let's take the best Silverlight scenario, however:

You are a hard core C# / VB.NET developer. You don't like JavaScript and you never want to work inside a paired set of <script> tags. You are writing an application that you will deliver to users who have the Silverlight 1.1 plugin installed, and all the boilerplate JavaScript code needed to bootstrap the plugin is encapsulated in a control (like the ASP.NET Futures Xaml control).

Do you ever need to touch JavaScript?

My answer is ... maybe (I'm hedging my bets because I don't know where Silverlight will be one year from now in terms of features).

There are some actions you can only perform in JavaScript (throwing up an alert box is one example that comes to mind). Reviewing the earlier code -  is the code isolated from cross-browser quirks? No. Is the API pretty? No - at least not when (in my eyes) compared to JavaScript and not even if we take away all the hard coded strings.

The real question is: are we gaining anything by writing this code in C# instead of browser's native JavaScript? I have to wonder. Funneling everything through a single type like HtmlElement feels awkward.

There are two things that could happen to Silverlight that would make me say - "certainly yes".

1. Silverlight gets a full-fidelity, cross-browser DOM API. Something along the lines of:

   document.getElementByID<HtmlImage>("id").src = "https://odetocode.com/odetocode.png";

   I doubt this is actually in the game plan for Silverlight, as in a way doesn't serve to further the main purpose of Silverlight, and it's already been done by many other libraries (that are mostly written in JavaScript!).
   

2. I get the ability to effortlessly unit-test the browser integration code.

#2 would be a great feature – (and by unit test I mean tools that are easy to run and integrate with a build engine like NUnit and MbUnit, and not tools that require a browser and some amount of integration pain, like Selenium or JsUnit). The former tools are still important as Silverlight does not yet offer an automation API so the runtime testability story is still weak. For unit-testing I know Jamie has already written a "Test With Silverlight" option to TD.NET, but its still only adhoc testing as I can see. If Microsoft makes it easy to host the runtime outside the brower, and provides some built-in fakes for the DOM objects, we could be off to the races.

The current Silverlight 1.1 alpha will eat exceptions. I’m not sure if the final version will behave similarly, but if you are working with the alpha don’t let this behavior surprise you.

For example, consider the following event handlers that listen to a shape’s mouse events:

The left mouse button goes down and … nothing happens. There is no indication of an error.

When the left mouse button goes up … the shape will grow in size. Silverlight is still running with the attitude of a Broadway director. Despite the setback - the show must go on.

If you have some mysterious behavior and are not catching exceptions inside event handlers, a good start might be to go into the Visual Studio Exceptions dialog (Debug -> Exceptions) and configure the debugger to break as soon as code throws an exception (the default setting is to only break on a user-unhandled exception). This might help locate the problem.

There is one area where an unhandled exception will stop the show. Consider the following user control:

If we place this faulty user control into the Page.xaml file that the plugin loads – Silverlight will tell us there is a parser error. This tends to make one look inside the .xaml file for malformed XML, when in fact the problem is that Silverlight can’t instantiate the object requested in XAML because of an exception throws from inside the default constructor.

Ajaxian linked to a reference implementation of ECMAScript 4 today. ECMAScript 4 (a.k.a JavaScript) is still a work in progress. When the work is finished, the new standard will be the first major update to the language since 1999.

The language overview whitepaper is 40 pages of ambition – iterators, pragmas, packages, namespaces, serialization, generics, annotations, non-nullable variables - and the list goes on.

Here is some code I was toying with:

Here is the code running in the reference implementation:

PS> .\es4
>> intrinsic::load('Point.es4')
>> var p = new Point();
>> p.x = 10;
10
>> p.y = 15;
15

Note that the following lines will create errors:

>> p.foo = "error: cannot add property to a non-dynamic object";
>> p.x = "error: incompatible types";

Wow! This is not the small, dynamic language that I've grown fond of this year. JavaScript is everywhere now – and I wonder how long it will take the various implementations to work out all the kinks in this standard.

ECMAScript is going from 0 to C++++ in a single release.