In my mind the single most important aspect of any system is usability.  Unless the context states otherwise, when I use the term "optimize" or "efficiency" I am always always talking about usability optimization and efficiency.  Things can be fast with a small footprint, but if you can't figure out how to use it right away or continually confuses your methods for your fields, then it doesn't really matter.  Fortunately, Microsoft agrees with this.  The days of every company writing their own coding-guidelines are gone and we .NET developers been unified under the great Framework Design Guidelines ("FDG") that Krzysztof Cwalina and Brad Abrams have so graciously given us.

To help further the unity in the community, Krzysztof recently posted a lecture on his blog entitled "Framework Engineering: Architecting, Designing, and Developing Reusable Libraries".  Here is the abstract of the lecture:

This session covers the main aspects of reusable library design: API design, architecture, and general framework engineering processes. Well-designed APIs are critical to the success of reusable libraries, but there are other aspects of framework development that are equally important, yet not widely covered in literature. Organizations creating reusable libraries often struggle with the process of managing dependencies, compatibility, and other design processes so critical to the success of modern frameworks. Come to this session and learn about how Microsoft creates its frameworks. The session is based on experiences from the development of the .NET Framework and Silverlight, and will cover processes Microsoft uses in the development of managed frameworks.

This video is, of course, not the only video on such an incredibly critical topic.  Many years ago, Brad Abrams (and friends) gave a lecture series to Microsoft employees on the topic of framework design guidelines.  These videos don't just cover the critically important topic of name guidelines, but also CLR performance topics, interopability guidelines, security topics, as well as various others.  It's a video series that's essential to serious .NET development.

More importantly then these videos though, is the classic work produced by Krzysztof and Brad entitled "Microsoft Framework Design Guidelines".  At the time of this writing, this book has 28 Amazon.com customer reviews and is still at five stars.  Look at a few of the review titles: "A must have for any C# Developer or Architect", "For the individual who wants to rise above the masses", "If you only ever buy one .NET book, make it this one", "AWESOME * 10 = MUST HAVE;" and my personal favorite: "Passionate About Quality?"  These reviews give you a good idea of the level of community acceptance that the framework design guidelines have.  One reviewer even said "I would pay $5 per page for this book, and have found it to be, by far, the most outstandingly useful technical book I've read."  This book covers in detail many of the aspects (and often times more) that have been covered in the videos.  In fact, the videos are actually on the DVD that comes with the book.

The book is also not simply a set of laws.  Throughout the book Microsoft architects and major Microsoft community leaders like Jeffery Richter make comments on various aspects of the framework.  Sometimes they explain why a rule is stated in a certain way and other times they emphasis how crucially important a rule is.  A few of the comments in the book explain problems in the .NET framework stemming from the fact that the guidelines were still in development (people used to say C# looked like Java-- well, many people used Java's nearly obfuscated coding standard!)  At one point in the book one of the authors explains a usability study for .NET streamed and right-out admitted what most of us already know: .NET streaming is extremely non-intuitive!

Many times I hear people say that the success of the .NET framework comes from it's extremely efficient garage collection model, it's flexible common language runtime (in contrast to Java's platform runtime) and it's powerful JIT model.  All those things are crucial, but ease of use is even more at the heart of .NET.  Abstraction in framework design can be defined as the increasing of the semantic value or usability of any entity and it's at this point where we can see .NET far outshine Java and PHP.  I've all but forgotten how to work with pointers, but it's when I forgot my coding standard that I'll start to become obsolete.  It's been said that the success of Windows was driven by the very open nature of the Win16/Win32 API.  Similarly, I highly suspect that it's the the beautiful abstraction with extremely high usability that explains .NET's sheer success.  There's only so much marketing can do; at some point a product has to stand on it's own (even then, Programmers can see though marketing!).  This beautiful abstraction and extremely high usability if course due to the existence and enforcement of the FDG.

To be clear, when I talk about FDG, I'm not simply talking about FXCop rules.  I typically break the .NET framework rules down into three levels: CLS-compliance, FXCop compliance, FDG compliance, and the iDesign standard.  If you do not strictly enforce CLS-compliance, then you may very well be completely stuck in the next version of .NET.  Who knows how non-Microsoft compilers will become.  FXCop will catch problems in your CLS-compliance and it will also catch many of the FDG violations as well.  The FDG rules, however, also cover various aspects of security and performance that only a human can check.  Lastly, when people often mention the FDG, many times what they really mean is the iDesign standard, edited by Microsoft Software Legend Juval Lowy.

In fact, I often use the terms "Framework Design Guidelines" and iDesign standard interchangeably.  They aren't the same thing, but in some contexts it's acceptable to mix them.  Whereas the FDG is primarily for the public interface of a framework, the iDesign standard covers both the public and internal.  The term "iDesign standard" may not be familiar to all, but what represents is.  It's been the .NET coding defacto standard since 2003.  In fact, when you crack open any APress, Wrox, or Sam Publishing book, you will probably be looking at code following the iDesign standard.  Further, the default settings for Visual Studio is the iDesign code layout. 

Every .NET developer knows it and just about everyone follows it.  Some may think the iDesign standard is optional and since it covers private code and in a sense it is optional, but, to be sure, if you are following the FDG rules and the iDesign standard, you have immediately chopped the learning curve of your system by an enormous factor.  Also, if you ever go public with your application (i.e. go open source), you will need to make sure you follow the FDG standard (which includes CLS and FXCop compliance) and the iDesign standard.  Otherwise, your system will probably have virtually no acceptance.

In closing, I should mention that Krzysztof Cwalina and Brad Abrams are releasing the 2nd edition of their famous book, due September 29, 2008.  You can, of course, pre-order on Amazon.  You can be sure that I will!

Links

• Framework Engineering: Architecting, Designing, and Developing Reusable Libraries Video
• Framework Design Lectures
• Framework Design Guidelines Book
• Framework Design Guidelines 2nd Edition Pre-order
• iDesign Coding Standard

In my overview of Dojo, I mentioned that Dojo provides a nice service abstraction layer in the form of dojo.rpc.  This is an absolutely astounding feature, yet it's so simple.  Instead of making all kinds of functions and setting up and XHR object, Dojo allows you to call server methods using a very simplified syntax.  The model should be familiar to anyone who has worked with SOAP services.  In these types of services, you are given a scheme and, depending on what client you are using, you can create a client-side proxy for all interaction with the service.  This is how the dojo.rpc feature works.  When you want to access a service, give Dojo the appropriate service metadata it needs to create a proxy and just call your service functions on the proxy.

Using dojo.rpc

In Dojo, this schema is called a Simple Method Description (SMD) and looks something like this.

var d = {
  'methods':
    [
      {
        'name':'getServerTime',
        'parameters':[
          {'name':'format'}
        ]
      },
      {
        'name':'getServerTimeStamp',
        'parameters' :[
        ]
      }
    ],
    'serviceType':'JSON-RPC',
    'serviceURL':'/json/time/'
}

With this SMD data, you create a proxy by getting and instance of the dojo.rpc.JsonService object setting the SMD in the constructor, like this:

var timeProxy = new dojo.rpc.JsonService(d);

From here you can call methods on the proxy and set a callback:

timeProxy.getServerTimeStamp( ).addCallback(function(r) { alert(r); });

Upon execution, this line will call the getServerTimeStamp method described in the SMD and route the output through the anonymous function set in the addCallback function.  If you would like, however, you can defer the callback by calling the service now and explicitly releasing the callback later.  In the following example, the first line calls the server immediately and the second releases the callback.

var deferred = timeProxy.getServerTimeStamp( );

deferred.addCallback(function(r) { alert(r); });

This is great, but what about the server?  As it turns out, Dojo, sends JSON to the service.  You can see this for yourself by taking at keep at the Request.InputStream stream in ASP.NET:

StreamReader reader = new StreamReader(Request.InputStream);
String data = reader.ReadToEnd( );

Below is the data that was in the stream.  As you can see, this is extremely simple.

{\"params\": [], \"method\": \"getServerTimeStamp\", \"id\": 1}

Providing Server Functionality

Since we are working in .NET, we have at our disposal many mechanisms that can help us deal with various formats, some of which that can really help simplify life.  As I explained in my XmlHttp Service Interop Series, providing communication between two different platforms isn't at all difficult, provided that you understand the wire format in between them.  In part 3 of that same series, I explained how you could use XML serialization to quickly and powerfully interop with any XML service, including semi-standard a SOAP service.  Furthermore, you aren't limited to XML.  Provided the right serializer, you can do the same with any wire format.  For our purposes here, we need a JSON serializer.  One of my favorites is the Json.NET framework.  However, to keep things simple and to help us focus more on the task at hand, I'm going to use the .NET 3.5 DataContractJsonSerializer object.  If you are working in a .NET 2.0 environment with a tyrannical boss who despises productivity, you should check out Json.NET (or get a new job).

To begin our interop, the first thing we need is a type that will represent this JSON message in the .NET world.  Based on what we saw in the ASP.NET Input Stream, this should be easy enough to build:

[DataContract]
public class DojoMessage
{
    [DataMember(Name = "params")]
    public String[] Params;

    [DataMember(Name = "method")]
    public String Method;

    [DataMember(Name = "id")]
    public Int32 Id = 0;
}

Having that class in place, we can now deserialize ASP.NET's InputStream into an instance of this class using out DataContractJsonSerializer:

DataContractJsonSerializer s = new DataContractJsonSerializer(typeof(DojoMessage));
DojoMessage o = (DojoMessage)s.ReadObject(stream);

That's it.  Now you have a strongly typed object where you can access the method and parameter information as you need.  From here's it shouldn't be too hard for anyone to use this information to figure out what to do on the server.  After all the logic is in place, the only thing we have left to do is to return the data, which isn't really that big deal at all.  The return data is basically plain text, but you can definitely send JSON back if you like.  If you would like to use JSON, you can even the DataContractJsonSerializer to serialize an object to the ASP.NET Request.OutputStream object:

Object r = GetSomething(o);
s.WriteObject(context.Response.OutputStream, r);

What about a more high-level approach that will allow me to simply write my core functionality without messing with mechanics?  Anyone using ASP.NET AJAX has this already in both their ASMX and WCF/JSON abstraction, but I wanted this functionality for Dojo (and for direct AJAX access).  My requirements were that I wanted to be able to define an attributed service, register it and move on.  Therefore, I build a Dojo RPC .NET 2.0 library called Dojr.NET (short for Dojo RPC, of course).  Dojr is probably the worst project name I've come up with to date, but it saves me from potential legal stuff from the Dojo Foundation.

Using Dojr.NET

To use Dojr.NET, create a class that inherits from DojoRpcServiceBase and apply attribute DojoOperationAttribute on each publicly exposed method.  Be sure to also set the dojo.rpc operation name in it's constructor, this is the name the Dojo client will see.  Since .NET uses PascalCased methods and JavaScript uses camelCased function, this is required.  Here is a complete sample class:

namespace NetFX.Web
{
    public class CalculatorService : DojoRpcServiceBase
    {
        [DojoOperation("add")]
        public Int32 Add(Int32 n1, Int32 n2) {
            return n1 + n2;
        }

        [DojoOperation("subtract")]
        public Int32 Subtract(Int32 n1, Int32 n2) {
            return n1 - n2;
        }
    }
}

After this, all you have to do is register the class as an HttpHandler in your web.config file.

<add verb="*" path="*/json/time/*" type="NetFX.Web.TimeService" />

At this point our Dojr.NET service is up and running, but how do we call it?  Actually, the same way you always do with dojo.rpc; nothing changes.  Believe it or not, this is a complete functional example:

var calcProxy = newdojo.rpc.JsonService('json/calc/?smd');
calcProxy.add(2, 3).addCallback(function(r) { alert(r); });

Automatic Service Method Description

But, how did the proxy obtain the required dojo.rpc metadata?  If you look closely at the address given to the proxy you will notice that it's suffixed with ?smd.  When a Dojr.NET service is suffixed with ?smd, it will automatically generate and return the service metadata.  This is similar to putting ?wsdl at the end of an ASMX URI.

Take a look at the metadata that's being automatically generated on the server via the ?smd suffix:

{
  "methods":[
    {
      "name":"add",
      "parameters":[
        {"name":"n1"},
        {"name":"n2"}
      ]
    },
    {
      "name":"subtract",
      "parameters":[
        {"name":"n1"},
        {"name":"n2"}
      ]
    }
  ],
  "serviceType":"JSON-RPC",
  "serviceURL":"http://localhost:3135/Dojo/json/calc/"
}

As you can see, Dojr.NET provides all the metadata required.  Literally all you have to do is inherit from DojoRpcServiceBase, apply the DojoOperationAttribute, and register the class to ASP.NET.  Everything else will be done for you.

Links

• Dojr.NET on CodePlex
• NetFX Harmonics Dojo Overview
• Dojo Download
• XmlService Interop Series

(This is a sequel to my Coders and Professional Programmers article)

I'm fairly sure the year was 2001. It was before I did my transition from coder to professional, but it was long after I became a real web developer (1994).  This was the year that the web became severely corrupted by an influx of thousands of MFC/VB developers thinking they were web developers simply because they knew how to drag-n-drop a control onto a canvas and make something appear in a web browser. The influx was, of course, due to the release of ASP.NET. These people were not web developers and that same coder-mill continually throws out unprofessional after unprofessional today.  This was the year I got so upset with the pragmatic, unprofessional web developers running around taking my work that I retired for 3 years to go back to college.

So, what is a web developer?  Surely is at least one definition per person in the entire industry, but I must say that, at root, it's a person who understands and can proficiently interaction with web technologies.  What web technologies?  Today, these include, at a minimum, semantic XHTML, CSS, and Modern JavaScript.  In a sense, you could easily mark these as the pillars of web programming.  Without academic and hands-on knowledge of these technologies, there is no web devolvement (yes, both are required-- and despite what the pragmatists think, the former is critical). Furthermore, this technology list changes over time.  If I were to retire today, I have no right to come back in 5 years claiming to be a web developers.  To be a web developer at that time, I need to learn a new X, Y, and Z in including their guidelines and best practices.  You must keep up or be left behind.

Having said that, PHP, JSP, and ASP.NET developers often inappropriately call themselves web developers.  Not all PHP, JSP, or ASP.NET developers are like this, especially PHP developers! Respect, respect!  In any case, I can kind of see the confusion here, but even still, a quick realization of what these technologies are should have killed any thoughts of this a long time ago.  These people work with server-side technologies, not web technologies.  The same CGI model used 15 years ago is the same model today.  The only thing these people are doing is creating code that runs on a server and shipping the output.  Period.  That's not web development; this is the same work you would do if you were to build an Excel report.  It’s just work behind the scenes that may or may not touch a web browser.  Even then, just because it hit a web browser, doesn’t mean its web development.  There’s no client-side technologies involved at all. Without deeply interacting with client-side technologies, there is no web development.  In fact, the inanimate object known as a web server is more of a web development than server-side-only people.

Web development begins at the point when you begin to ponder the technologies and implementation from the perspective of the client-side.  I'm sure most people won't believe me when I say this, but I did web development for my 4 years of high school before I even knew that you could use server-side software to dynamically create pages.  Everything I did was in pure JavaScript and fancy frame manipulation.  This was web development.  I didn't need CGI or Perl.  PHP, JSP, and ASP.NET simply sends out a stream and it just so happens that a web browser may be the one making the request.  The output may be for a web browser, but that in absolutely no way makes it web development.  That's like going to a foreign country and using a translator device and saying because you have that device, you speak the language.  You in absolutely no way speak the language!  Worst, some people will defend, virtually to the death, the idea that they do speak the language simply because they know a few words to "fix" the translation!  We see this in server-side-only developers who, because they know a few HTML tags, think they know the technologies.

Most of the time, however, server-side-only developers really think they are web developers. So, this simple and obvious explanation won't do.  Therefore, we are forced to make a distinction between web 1.0 and web 2.0 developers.  We often think of web 2.0 as being quick, dynamic, and smooth client-side dynamics.  This is from a marketing perspective, but it's hardly a definition that satisfies the computer scientist.  The distinction I use is actually a bit more straightforward: web 2.0 development is development from the client-side perspective.  This definition actually reminds me of the definition of a series I learned in my Real Analysis class in college: a mapping from N to R.  How in the WORLD is that a series!? Isn't a series a set of entities or something?  Well, somehow it's a mapping from N to R (I've yet to hear another professor give this same definition, but the point is that "formal definitions" in mathematics rarely look like their application in reality).

When I talk about web 2.0 to a colleague or a client I'm talking about web-specific design and implementation from the perspective of the client. From this perspective calls are made to various services for interaction with outside data.  In other words, web 2.0 is a client-service model for the web.  In this sense, what is web 1.0?  Just the opposite: development from the server-side perspective.  This is ASP.NET development, for example.  When you are working with ASP.NET, you are working from the perspective of the server and you send data out.  In this model, you have a logically central system with entities accessing it. In reality, this isn’t web development—it’s development of something that may or may not do web development for you. Web 1.0 is a server-client model for the web (notice the word server, instead of service—as seen in the web 2.0 model)  If you are a deep Microsoft developer you recognize the web 2.0 paradigm: WPF/WCF allows you to easy create a client-service model bypassing the client-server model all together.  You create your client interfaces in WPF and access WCF servers as you need them.

In this perspective, what does this mean in terms of the actual technologies?  Well, almost all my web applications are done using the web 2.0 model.  That is, all my programming is done from the perspective of being inside the web browser.  I'll directly modify the DOM and access data via AJAX calls as required.  Some of my applications are pure-AJAX. That is, not single postback in the entire system (like meebo.com-- meebo is a prime example of a web 2.0; everything is from the perspective of the client with communication via AJAX services.)  In fact, my controls are very Google-ish.  Google is also deep into this model.  See their AdSense, AdWords, or Analytics controls; insert a declarative script and it does the rest from the perspective of the client.  As you can see here, you don't even need the XHR object for web 2.0!

What does ASP.NET AJAX bring?  In this model, ASP.NET AJAX is as web 1.0 technology that gives you the dynamics of web 2.0.  This was actual the entire point behind creating it.  Web 1.0 developers (who are often not web developers at all!) can use their existing server-side perspective and paradigms to implement dynamics on the remote system (in a web 1.0 model the client is the remote entity-- whereas in web 2.0 the services are remote).  ASP.NET AJAX very much allows for a web 2.0 model, but that's not how it's primarily marketed.  As a side note, I should mention that, this model for explaining web 1.0 and 2.0 is only a logical representation and therefore can not be right nor can it be wrong.  The fancy marketing representation kind of works too, but it's often too abstract to have real meaning.

Personally, I think the web 1.0 model of development is counterproductive and encourages sloppy priorities.  The user experience is the point of the system. Without that, the entire point of the web site is dead.  One of my problems with ASP.NET AJAX is how it's marketed.  The server-perspective model of development encourages development that seems backwards.  Furthermore, because of this, the aforementioned so-called "web developers" continue to spread their disease of pragmatism all over the world further aiding in the disintegration of quality.  As I've originally stated, most of these people don't understand even the basics of semantic XHTML, which is the single most fundamental aspect of web development, which can be seen in their use of div-soup or <br/> mania.  These people may be awesome server-side professionals putting my enterprise architecture skills to absolute shame and run circles around me in just about any algorithm or design pattern implementation, but they are only coders when it comes to the web.

After years and years of dealing with people like this, I've come to notice a few signs of web 1.0 coders:

• If someone says "Firefox?  How's that better than IE?", it goes without saying that this person not only hasn't the first clue about web development, they don't even understand the tool which represents the core purpose of web development: the web browser.  People like this are almost always helpless.  You could try to explain the true power of CSS, the fact that SVG, HTML5, and Canvases are in every web browser except IE, or talk about how Firefox has the architecture of an operating system with its console, it's own registry (about:config), as well as the ability to install apps (extensions), but you're probably only going to get the same pragmatic blank stare of a coder. Fortunately, I haven’t heard say this in at least 3 years.
• If someone says "I know CSS, here..." and shows you how they used font-size, color, and font-weight on a few elements contained in a table embedded in a table embedded in yet another table, then you have your work cut out for you, because you met a person who thinks HTML is the latest cool technology on the block and hasn't the first clue what CSS really means.  As I've stated in my article "CSS Architecture", CSS is not just a styling technology.  Furthermore, we web 2.0 developers realize that CSS is to be used in harmony with semantic XHTML and therefore understand the dangers of using a table.  These people obviously don't.  Of course, the minute their boss asks for mobile support, they come running to you because they now realize "DOH! Tables are too wide! AHH! Tables make the page size too big!" They will have to learn their lesson eventually.
• If someone says "I know JavaScript, here... " and they show you a validation function, then you need to explain to them that JavaScript isn't merely a scripting language, but is rather a very powerful object-oriented/functional programming language which often puts strongly-typed languages to shame.  It includes closures, namespaces, an extremely rich object system, object-oriented access levels, multi cast events, and a boat load of core JavaScript objects.  Yet web 1.0 developers haven't the first clue. This problem isn’t nearly as bad as it used to be, though. MSDN magazine devoted some time to the topic in the May 2007 issue and the number of JavaScript experts in the Microsoft community is growing very rapidly.
• If someone says "Hmm... I don't see the control you are talking about in my toolbox", then you know you are dealing with a coder.  Not only that, you're probably dealing with a person who has never, ever learned what semantic development even is.  Typically people like this will use the dead concept of a WYSIWYG designer to drag-n-drop controls and set properties with their mouse.  Clearly, these people focus more on how something seems to look at the moment, not how the page is actually built.  Pragmatists.  Personally, I’ve never designer support into anything, ever. If you can’t program it, don’t develop it! I personally find it extremely unprofessional to even allow designer-support. The target audience typically has absolutely no concept of the difference between a semantic <h1></h1> and a pragmatic <div id="myHeader"></div>.  Not only will their code cause problems down the road, your code will never integrate with it, which, of course, means you will be rewriting everything. Anyone who understands the importance of semantic XHTML understands the sheer severity of this problem.  You will break a page's structure by relying on a designer.  A designer should only be used by a professional who knows how to fix it's flaws.  Since only a professional would be able to fix the flaws, it follows that only a professional should do web development.  Duh?  For more information on semantic XHTML, see any modern web 2.0 book or my mini-article here (a quick note-- when I was formatting this post in WLW, every one of my list items would start a new list-- if I didn't understand semantic XHTML, I would have been completely stuck [also notice I'm using the semantic term "list item" not the syntactical term "<li />"-- focus on what things ARE, not what they DO-- try focusing on what something IS using a WYDIWYG designer!])

I know I've written about this topic before, but it's is just such a critically important topic.  Just because someone does something, that doesn't mean they are in that profession.  I change my own oil and change my tires, but this doesn't make me a mechanic.  A few months ago I was talking to a guy who actually said that he doesn't care about what he produces, because "it's just a job".  Just a job!?  Why don't you just get another one!  These people need to stop masquerading as web developers, stop undercutting my professional company by offering $3.75/hour unprofessional "development", start upping their own standards and start showing a little respect to us that were here first.  To a lot of us professionals this isn’t just a “job”; it’s actually become part of us! Unfortunately, I've learned years ago that people don't change.  Not for their marriage, not for their family, and especially not for their careers.  It's hopeless.  Moving on.

One of the most horrendously thing about ASP.NET 1.1 was that the developers confused a web site and a project.  All that did was allow a severe influx of desktop developers into the web world that had no right to call themselves web developers.  ASP.NET 1.1 even added resx files for web forms and of course since the file was there, many developers (senior level!) actually thought they were required files.  That didn't stop me drop regularly going into CVS and DELETING them.  Worthless.

Fortunately, ASP.NET 2.0 fixed this problem by making sure that people realized that a web site was NOT a project.  This made everything so much easier to work with.  Furthermore, now we had the beautiful CodeFile page directive attribute so that we didn't have to rely on VS for everything.  There was also no need for absolutely ridiculous and redundant designer or resources files for web forms.  The ASP.NET guys were finally conforming to the preexisting conditions of the web, instead of trying to come up with a new [flawed] paradigm.

HOWEVER! Apparently the ASP.NET 3.5 team fell asleep at the wheel because I'm having horrendous flashbacks to the slop of ASP.NET 1.1.  First of all, when you add a web site, you are adding a project.  I don't WANT a csproj file for my web site!  Secondly, web forms have returned to using the completely useless CodeBehind attribute.  It took me QUITE a bit of debugging to finally realize this.  Third, every single web form now has a completely meaningless X.designer.cs file.  This also took me a while to realize.

I realized this when I kept getting an error telling me that type X.Y didn't match type X.Y.  What?  Yes it does!  After I finally fixed that error (can't even remember how), I kept getting that one stupid error telling you that your type is in two separate places.  HOW?  This was a new project!  I haven't done anything yet!  It turns out that the designer.cs file had become out of date between the time I typed up my added my custom control to the page and ran it.  Err... what?  This is beyond frustrating.

There's good news though.  The ASP.NET team wasn't completely asleep.  You can add an ASP.NET web site or an ASP.NET web application.  Yes, I realized there's no REAL difference, but for some reason they decided to make a whimsical split (I suspect it was a political or PM decision-- the ASP.NET team is smarter than that).  Perhaps they wanted to aid the old VB developers, who I would argue have no right to put things on the web anyhow (i.e. they are web coders, not web development professionals!)

If you add a ASP.NET web application, you get the old ASP.NET 1.1 style of hard to use nonsense.  On the other hand, if you add a ASP.NET web site, you get the appropriate ASP.NET 2.0 style.  Personally, I say forget both.  I always just create a folder and then "open web site".  Done.  Most of the time, however, I just start a project by checking my continually changing solution template out of subversion.  Again, DONE.  This is why it took me 8 months to finally notice this.  I don't even want to think about how many sloppy intern or VB6-developer created applications I'm going to have to clean up based on this painfully flawed design.

In response to Meebo's popular "JavaScript Ninja" interview questions, I created a JavaScript Quiz for beginning, intermediate, and advanced JavaScript developers.  Feel free to use it in interviews, quizzing, or for your own personal edification.  I will admit one or two portions are a bit obscure, but the same could be said of a couple of Meebo's questions.

// JavaScript Quiz
// Created by David Betz @ http://www.netfxharmonics.com/

// What is the purpose of this first line? (easy)
var A = window.A || { };
A.B = { c:4, d:function(x) { return { e:A.B.c*x, f:4 } } };

function M( ) {
  this.p=8;
  return {
    c: function( ) {
      // How can you return the value of M::p? (medium)
    }
  }
}

function N( ) {
}

///////////////////////////////////////////////////////

// Why is this function syntax here? (medium)
(function( ) {
  var addEventListener = function(e,f) {
    if(window.addEventListener) {
      window.addEventListener(e,f,false);
    }
    else if(window.attachEvent) {
      window.attachEvent('on'+e, f);
    }
  };

  addEventListener('load', function( ) {
    var v = 2;
    var w = 4;
    (function( ) {
      var v = 8;
      w = 16;
      })( );
   
    // What are the values of v and w? (easy)
    alert('v:'+ v);
    alert('w:'+ w);

    ///////////////////////////////////////////////////////
   
    var t = A.B.d(3).e*A.B.d(3).f;
   
    // What is the value of t? (easy)
    alert('t:'+ t);

    ///////////////////////////////////////////////////////

    var a = new N( );
    N.prototype.B = function(y) { return { q:Math.pow(4,y) } };
    var b = new N( );
    var r = a.B(2).q;
    var s = b.B(2).q;

    // What are the values of r and s? (easy)
    alert('r:'+ r);
    alert('s:'+ s);

    (function( ) { r = s; var s = 3; })( );

    // What is the value of r? (hard)
    alert('r:'+ r);
    alert('s:'+ s);

    ///////////////////////////////////////////////////////
    
    (function( ) {
      var m;
      var n;
     
      var a = function(o,f,a) { f.call(o, a); };
      a({ y:4 }, function(x) { m=this.y*x; }, 3);
     
      a = { x:1, y:2, z:4 };
      (function(r, s, t) { n=this.x*r+this.y*s+this.z*t; }).apply(a, [1, 2, 3]);
     
      // What are the values of m and n? (medium)
      alert('m:'+ m);
      alert('n:'+ n);
    })( )
  });
})( );

If you regularly work with Modern JavaScript, need to make sense of the code that Microsoft ASP.NET AJAX throws out, want to make sense of what your AJAX framework is doing, would like to understand the mechanics of AJAX application, or would like to being creating rich, powerful, and efficient AJAX applications, then there is only book that I can recommend: AdvancED DOM Scripting: Dynamic Web Design Techniques by Jeffery Sambell.  This book is phenomenal.

It covers all the intermediate and advanced JavaScript required to interpret the above JavaScript code as well as all the training you would need to create your own powerful AJAX framework.  This is an incredibly exhaustive book that is perfect for anyone who desires to dramatically increase their JavaScript, DOM scripting, and AJAX skills.  I've been pushing this book for quite a while now and for good reason.  Seriously, buy this book!