The Jason Salas Experience

I've been racking my brain over the last few hours trying to determine the best format(s) to save data into for a fairly large project I've got coming up. Basically, I need to export data sitting in a caching tier I built from scratch in C# into some sort of structure that will populate an Excel spreadsheet that constitutes the data source for a separate application that reads tabular data and generates dynamic TV graphics. The centralized caching tier is used to ensure synchronicity across multiple, diverse platforms that have clients calling the data repeatedly. (See my MSDN article on this very topic for more.)

Since this is an internal utility, I've got an admin control panel on my machine running Office XP, with the separate machine on the network share onto which the Excel data will sit using Excel 97. I'm torn between just programming against the Excel API and writing the data file to the mapped drive on my LAN; or writing an XML file locally to disk (much easier programmatically) and having the spreadsheet read the remote data source across the network share; or using the Office Web Toolkit and having the spreadsheet routinely make asynchronous SOAP calls to generate fresh data via a web service. (I've got to figure out a polling mechanism for this latter approach, though.)

Each has its ups and downs and levels of complexity, and none is too far out of reach. I'm just going nuts trying to figure out the most-right fit. Me and my perfectionist syndrome.

It's been a long time coming, but I'll be debuting a new weekly podcast, tentatively called "KUAM Insider: A Look Behind the Scenes of Guam's Source for News, Entertainment and Information". (At production time it'll most likely be truncated down to everything before the colon.) It's essentially a raw look at bloopers, horror stories, funny tales and an honest look at who we are and how we do things here.

I've finally convinced my co-workers that (1) podcasting is a legit medium, and (2) we need to get into it from the aspect of producing original programming we distribute exclusively over syndicated MP3 feeds. Ironically enough, it was one of my other colleagues who attended an industry conference that said all the rage for broadcasting companies this year was podcasting and citizen journalism that did it. It took long enough for everyone to come around, but by any means necessary, I guess.

Each Wednesday I'll join one member of the KUAM staff and talk about what they do and how they fit into our role here at Camp Happy. The inaugural episode features my dear friend Marie Calvo-Monge, who many of you will remember from my "Digital Pontification" podcast days.

I'll post the URL to the RSS/Atom feed once it's up. Enjoy!

A couple of nights ago I was thinking about optimizing my AJAX-enabled utilities. One of the major sources of latency (not catastrophic, but still a concern) is extraneous bytes being passed across a network or the Internet due to verbose XML. Too often the payload I need to work with, even when filtering a view of a subset of a larger data structure, contains stuff I don't need and can thus avoid. Enter JSON.

JavaScript Object Notation is a perfect solution for getting performance increases for asynchronous remote scripting, being a lightweight alternative to XML, the same way XML continues to be a lightweight alternative to managing database communications. But with so many systems already storing their data in XML, either in memory or on disk (and possibly for use in other implementations), we don't need to re-architect entire apps to use JSON. Enter XSLT.

You can easily use XSLT logic to reformat XML data as valid JSON strings, thereby reducing the payload passed down to a web client in an AJAX call. I worked up a quick demo of an existing app I'm running on my company's site, displaying grouped contact lists. This is an example of how to leverage JSON without breaking in-place systems.

• View the demo contact list
• Download the files in this tutorial

The demo uses 6 files:

• client.html - main interface through which users will interact with the system
• employeelisting.css - basic styling rules
• employeelisting.xml - data store for the app
• employeelisting.xsl - transformation templates that take a parameter specifying the group to display
• ajaxGetEmployeeListing.js - JavaScript library of functions required for asynchronous call and DOM scripting
• convertXMLToJSON.aspx - the server-side remote script to be called that stiches it all together - a .NET program that loads the XML data and passes the required parameter to the XSLT process, caching the data on the server and sending the output to the browser

Since the data is fairly static, the ASP.NET page caches the data on the server to further reduce the latency that may arise due to data transmission, making the load a bit smaller. An additional efficiency is gained by the remote script programmatically clearing all HTTP headers before adding and setting the "Content-Cache" header to a value of "no-cache". This ensures the client doesn't inadvertantly cache the data in the event it changes.

Weird things I learned after this project:

• I already knew XSLT's generate-id() function guarantees a unique ID on that instance of a page, but not across page refreshes, typically naming nodes something like "ID{some_arbitrary_string}". But when run through the ASP.NET process, the IDs "XSLT{node_name}{arbitrary_numerical_string}".
• Despite the JSON string needing to be only text returned to the client (and set as such in XSLT), the "ContentType" HTTP header still needs to be "text/html" in the ASP.NET page. Initially I set the header to "plain/text", which forced the browser to prompt to user to download or save the served file through the Windows "File Download" dialog.
• In ajaxGetEmployeeListing.js the "url" variable pointing to the remote script is globally scoped, and reflects a root-relative path on the server. I ran into JavaScript errors when initially using an absolute path, and people would try to navigate to the page without typing in the "www." in the URL. (Thanks Jonah)

Realistically, converting XML to JSON in this particular implementation, given the small set of data not changing with great frequency likely won't return significant performance gains. This would be a heckuva undertaking just to squeeze out a few hundred milliseconds. I ran some tests and the AJAX app calling JSON data ran about 1/8 of a second faster than its XML equivalent. However, in applications where the XML is filled with unnecessary downstream clutter (case in point: about 95% of the metadata in most SOAP calls), this would be an effective solution.

Hopefully, I've inspired you to use JSON creatively and how to really get the most speed out of your AJAX apps. Plan your code, code your plan!

I broke the news a couple of days ago about Guam's cable company moving towards an all-digital platform, and my larger interest, the introduction of Guam's first DVR.

This is a big challenge for us way out here in the Pacific: how to provide live (or near-live) programming while sticking to the same airing time as our friends in the mainland, while accounting for the time difference. MCV's got a pretty neat business plan - time-shifting the content such that the programming is aired locally at the same time as it would air on the U.S. West Coast, but the next day.

It hasn't been without its glitches since launch, but overall, I'm pleased with what I've seen. HDTVT right around the corner!

(And...ESPN Classic - finally! I watched a bit of the 1979 NCAA Championship game between a pre-Magic Michigan State's Earvin Johnson and Indiana State's Larry Bird. Cool as hell.)

I was sorta pissed this morning to get more than just a few e-mail/RSS/verbal affirmations that my favorite show, ABC's 'Grey's Anatomy', is moving to Thursday nights. Great - Thursdays are normally the nights where I do my "death march" nights, working 17+ hours to get the lead out before the weekend lethargy kicks in.

So from now on - no blogging, no podcasting, no streaming on Thursdays.

I had a rare opportunity to enjoy some free time this past weekend, so I dedided to fall back into what's now become an unfamiliar behavior pattern: watching Saturday Night Live. I was pretty stoked in that (1) I actually had some time to myself, and (2) I could get some guffaws in. I swear, it's been at least a 18 months since I've watched my 10:30pm standard. Plus, SNL was hosted by Tom Hanks with Red Hot Chilli Peppers as musical guest. Instant winner, right? Nope.

I was shockingly disappointed as how un-funny the show was. Good Lord, the crowd was so out of it. You could have heard a pin drop during the spoof on "Sanford & Son" with a Collin Powell theme.

Now, I work for an NBC affiliate and I'm a company guy, so let's get that out of the way. And I would never call for the show to be cancelled. That having been said, I've been a devout viewer of SNL for a lot longer - since the very beginning. But the comedic institution seems to be cyclical in having lulls. We'll wade through 2 maybe 3 seasons until another Will Ferrell emerges or another Dana Carvey comes on the scene. Eddie Murphy was one of a kind.

But it seems like this is a down-year for one of my favorite shows.

I'll be posting some technical articles and podcasts I'm developing in the next few days, but a co-worker of mine inadvertently stumbled upon a rather annoying error just now. He navigated to a web app I did using an Ajax remote scripting call without typing "www." in the domain name.

Oddly, MSIE 6.x threw a JavaScript error, saying 'Permission denied'. However, the app as designed works perfectly as long as the predicate is in the URL. Anyone know what/s up with this?