RockNUG is the newest .NET user group in the vast suburbia of Washington D.C. Their next meeting is on August 8 at Montgomery College, and I'll be there to talk about ASP.NET AJAX. I have one WF book and one Pluralsight T-shirt to give away, too.

Come for the free pizza, and stay for the asynchronous fun!

Unit testing features will now be available in the Professional version of Visual Studio 2008.

Unit testing has been to Visual Studio what Barry Bonds has been baseball – a center of controversy. First there was the Peter Provost petition to include unit testing features in all version of VS. Then there was the highly criticized TDD guidance accompanying the feature. Next came some performance issues and pain while using the shipping version, and most recently, the TestDriven.NET hullaballoo added an emotional charge to the air.

Putting all this behind us - what's new in 2008? I've been working with the latest bits, and I can say:

1. Performance has improved dramatically.
2. The context-menu command "Run Tests" is new (and context sensitive).
3. Keyboard shortcuts take away the pain of the VS2005 test runner (Ctrl+R, A to run all tests in a solution, Ctrl+R, T to run tests in the current context).

Moving the unit-testing features into the Pro edition is a great move by Microsoft. I hope the feature gains traction and brings awareness of unit testing into the mainstream (although I think we are already close, aren't we?).

Related Links

Guidelines for Test-Driven Development by Jeff Palermo
Rules to Better Unit Tests by Adam Cogan.

I wrote my first class with automatic properties in Orcas today...

... then I found myself staring at the screen.

It's an interface!
No,it's a class!
Wait, it is a class!

I'd say the syntax is still growing on me.

I'm sure some people will say – why use properties at all? If you don't need special code in the get and set methods – why not just use a public field?

The quick answer is: reflection. There are many forms of magic that will only occur if you expose state using public properties.

Related Links

• ScottGu: New C# "Orcas" Language Features
• Daniel Moth: Using C# 3.0 from .NET 2.0
• The Wandering Glitch: Semantic changes to help cope with poor syntax?

Come join Fritz Onion and myself at a Pluralsight double feature in southern California. Starting October on 22^nd, we'll cover everything from JSON spitting web services to the Sharepointy magic of ASP.NET 2.0 web parts.

It's more than a class … it's an experience (and fun, too)!

Raymond tags me in every blogging meme, which is great. If it wasn't for Raymond, I wouldn't get to play along.

The current meme is "what I will do to be a better developer in the next 6 months". Bettering is a tough topic to write about, because there are so many ways to get better.

Interviewing Skills

Not interviewing for jobs, but interviewing candidates. Although interviewing isn't strictly a development job – it is a job I am occasionally tasked to do. Good interviewing skills can help you build a great team and contribute to the success of a project and a company. The truth is – I have terrible interviewing skills. My record shows I'm too optimistic about candidates. If left to build a team on my own, I'd end up with something that resembles the 1976 Buccaneers. I need to prepare better, and have a plan in place to dig deeper in interviews.

Forge Ahead

I feel like I've spent the last 6 months playing catch up on some old technologies (these days – old technology is anything released over 6 months ago – legacy technology is anything released over 18 months ago). While I was catching up to get work done on current projects, exciting changes began to loom on the horizon. LINQ comes to mind as a technology that I think will be huge, and I want to be ready before the next application comes along.

Build Something New

I learn the most when I build working software. To forge ahead I really need to set aside some time, put together some ideas, and build something new. Actually, I do have an idea for a new web site- and one wholly unrelated to technology. The technology I'll use to build the web site? ASP.NET. It's fashionable these days to criticize ASP.NET as a leaky, heavyweight, complicated beast, but I believe it's easy to poke holes in any non-trivial platform. ASP.NET is what you make of it. If you want to swim against the current and make ASP.NET be difficult - it will be difficult. I can't leave the huge feature set, the range of extensibility, and the strong foundation of the CLR and the framework class libraries.

But enough fanboy racket – I gotta build some software, and hopefully have time to blog about it, too.

Tag

Four people, picked at random people from my techie OPML list:

Wayward LINQ Lacky Matt Warren
New and Notable Sam Gentile
Master Microsoft Interviewer Chris Sells
Carnage4Life aka Dare Obasanjo

Will they play the game, too?

If you are a heavy user of remote desktop connections, and you haven't tried Terminals, then give this free, open source utility from CodePlex a try.

"Terminals is a multi tab terminal services/remote desktop client. It uses Terminal Services ActiveX Client (mstscax.dll).
The project started from the need of controlling multiple connection simultaneously."

One of the great features in Terminals is the ability to set up a "group". One click on a group can open multiple RDP sessions at once. Terminals can also auto-scale a remote desktop to the window size, and setup a default desktop share for drag and drop operations into the remote desktop window.

Tip: If you are using a nonstandard port for RDP, don't enter the port number with the computer name (machine.foo.com:3399). This syntax doesn't work in Terminals. Instead, enter the port in the Remote Server Port textbox on the Advanced settings tab.

At the end of the last post, we looked at a function named createDelegate. The createDelegate function constructed a nested function named shim, and shim created all the magic we needed to invoke an object's method during a button click event. In this post we'll finally put the topic to rest.

First, we have to cover an important topic: scope.

Scope

A variable's scope defines where the variable can be used. In JavaScript there is really only local scope and global scope. Notice that local variables will hide global variables of the same name.

Nesting a function inside a function is essentially nesting a local scope inside a local scope. Note that functions have access to all the variables and arguments in all their ancestor's scopes (as long as the variables aren't hidden by a local variable).

The above behavior is what we expect after reading section 10 of the ECMAScript standard. JavaScript creates a new activation object for each scope. The activation object references all function arguments and variables in the scope. The activation objects become part of a scope chain that JavaScript will traverse when trying to find a variable. The following diagram is a conceptual model of all these players, with red brackets indicating scope, red circles indicating activation objects, and blue lines indicating the scope chain.

When we ask for the value of x inside function g(), JavaScript looks at activation object for the innermost scope, but doesn't find x, so it moves to the parent scope, but still doesn't find x. Finally, the runtime looks at the global scope and finds x. If the engine had found x in a nested scope, it wouldn't have gotten to the x in the global scope.

Knowing what we know now, what does the following code display?

The answer is 15. The innermost function has access to both the incoming y parameter of printIt and the global variable x thanks to the scope chain. Now, let's add a twist.

Closures

Instead of having the printIt function invoke doAlert, let's return doAlert as an object and execute the function from global scope.

Returning a function object creates a closure, which Wikipedia defines as "a function paired with an environment". Generally speaking, when a function like makePrintIt() exits, all the local variables and arguments are lost. A closure, however, closes over its environment and keeps these local variables and arguments alive. The function captures its execution environment.

Looking at our conceptual diagram above, it's easy to see how a JavaScript engine might implement a closure*. All a nested function has to do is carry a reference to its activation object, which will keep all the variables and arguments in the scope chain alive.

If you've gotten a good grip on closures, then you'll realize the last code snippet will display 15. Since doAlert captured its execution environment, it will use the y value of 5 that was passed into makePrintIt, not the y value of 20 that exists at global scope. Thanks to closures, JavaScript functions always execute with their lexical scope (where they appear in the source code).

Finally, every call into makePrintIt() creates a new closure by pairing a function object with its unique execution environment. That means the following code prints 10, then 15.

With this understanding of closures, I hope you can look at the implementation of Function.createDelegate and understand what is happening!

* The ECMAScript standard only describes how the interpreter has to behave. How scope chains and closures are actually realized is an implementation detail.