Friday, December 14, 2007

What the Heck is JSON!?!

That was my question when I first came across JSON. What the heck is JSON, and why didn't I know it?

The quick definition is that JSON stands for JavaScript Object Notation. Of course, that doesn't really tell you much. Now you know what JSON stands for, but what does it really mean?

Come on, man, tell us. What does it mean?

The bottom line is that JSON is a lightweight data-interchange format. In English, that means that JSON is an simple and elegant method of moving data from one point to another.

Sound familiar? Are all you XML enthusiasts standing up, pumping your fists and screaming "Mother of God! My power....my power...it's slipping away. What's wrong with this world? Dear God, what's wrong with this world..."?

Well, sit down and take a deep breath. JSON isn't going to replace XML. JSON isn't going to go away, either.

JSON's strength is in it's simplicity. It is essentially either an unordered set of name/value pairs, or it is an ordered collection of values. That's it. Nothing more. The JSON clan claims that this is set in stone. There will never be anything more. No schema. No comments. No headache. Just simple data that you can move from point a to point b.

Ah, simplicity, I love you so....

I hear you. You want me to stop the yapping and show JSON in action. Well, here you go. We're going to use some code from a VE implementation. The code below is a server-side code snippet for getting some search results from MapPoint. This data will be consumed on the client so our job is to convert the data to JSON and send it upstream as a string. Ready? Okay!

/*...remember, this is inside a method on the server...most likely in a web service or a library called by the web service*/
FindResults fss = this.findService.FindAddress(fas);
JavaScriptSerializer s = new JavaScriptSerializer();
string json = s.Serialize(fss);
return json.ToString();


Whew! That JSON sure is hard work! The key is using the JavaScriptSerializer. That bad boy takes my collection of results objects and serializes it into a JSON collection of objects. Bing, bang, boom. Done.

Now let's see how we consume it on the client.

function WebMethodCallback(result, eventArgs)
{
var data;

try
{
data = eval('(' + result + ')');
var numberFound = data.NumberFound;

}
catch(e)
{
//handle this exception
}
}


Again, that's it! We eval the string into an object we called data. From that point forward, data is used just like any other object. Notice on the next line we set an local variable to a property off of the data object. Shazam! JSON in action, baby.

Tuesday, December 11, 2007

Virtual PC Virtually a Requirement for Any Developer

Virtual PC is a fantastic tool for the developer. I've used this Virtual PC in the past for everything from a Hong Kong version of Windows XP to Sharepoint development.

One of the things I like to do is have a "vanilla" installation of XP and Windows Server 2003 at the ready. When a new project comes down that requires installation, such as Sharepoint or Team Foundation Server, I'll copy the vanilla and begin my installation.

Virtual PC is easy to use. Simply install the client and then create a new VPC. The wizard will walk you though the steps.

One tricky item is getting network connectivity to the VPC. The easiest method is to select Settings for your newly created VPC, click on Networking, and then select Shared networking (NAT) as your adapter. This will use your host computers external network access for your VPC. Very easy. Very slick.

I can't say enough about the advantages of Virtual PC. If you need to test installations or web-based applications on different platforms, Virtual PC makes this a snap.

Wednesday, December 5, 2007

Microsoft Sponsored Architect Council in Bellevue

I went to the Architect Council Tuesday. I was able to get a preview of IIS 7.0, SQL 2008, and Visual Studio 2008. I'll be discussing VS2008 in much more detail later. The big news with IIS 7.0 (at least for me) was shared configuration. This is a single file, called the applicationHost.config, which has all of the configuration information for IIS. If you went to IIS Manager in IIS 6.0 to configure something, you'd find that in the applicationHost.config file for IIS 7.0.

Having a single file to house this information means that you can host it on your network and have your IIS boxes in your web farm all point to the single file for configuration. No longer will you run the risk of having a box or two in your farm not match the configuration of your other boxes. This is a huge win.

The boxes using this applicationHost.config file are watching it for changes. Once a change is saved, the boxes pick up the change and recycle at the appropriate level. For example, if you were to make an IIS-wide change, IIS would recycle, but if you were to make a change to an application pool, only that app pool would recycle.

Another big win for IIS is the integrated pipeline. This is important for static content that needed to be served up through asp.net before to take advantage of things like membership or caching. Now you can just select the components you want in your pipeline. I'll go into this in more detail in a future post, too.

One last win is the failed request tracing. This allows you to set up an XML dump based on whatever criteria you specify. For example, you could set up your site to watch for 500 errors and dump to XML whenever the error occurs. This gives us better investigation opportunities when things go wrong.

All-in-all a good day. Well worth the time. I made a few important contacts and I learned a couple of items.