Thursday, November 30, 2006

Why Ruby rocks

Just for honks & giggles, I've been messing around with rewriting/refactoring some of the code samples I've done over the years in my favorite languages to compare syntax verbosity. Ruby totally kicks ass. Consider the following method to print image filenames on disk, using most best practice conventions for indenting, bracketing, etc.:

def get_all_photos
    Photo.find(:all).each { |p| puts p.filename }

def get_all_photos():
    photos = Photo.find_all
        for p in photos:
            print p.filename

function getAllPhotos() {
    var photos = Photo.find();
    for(var i=0;i<photos.length;i++) {

private static void GetAllPhotos()
    string p = Photos.find();
    for(int i=0;i<p.Length;i++)

Wednesday, November 22, 2006

Upstream data caching in AJAX applications

To date, the obvious implementation of server-side caching has been to store frequently-accessed data downstream - archiving information in a memory-based container to reduce expensive roundtrips to a formal data store like a database server or XML file. This makes read-only requests for HTTP-GET transactions efficient in providing fast access while conserving server resources for other operations. But I'm going to now discuss a reverse condition: employing caching for upstream situations - specifically managing data for AJAX web applications utilizing form submissions via HTTP-POST.

I was hacking together an internal utility to generate real-time scores for sports broadcasts, which will serve as the feed source for TV graphics. (A variation of this app is discussed here.) The user interface is a simple HTML form with text fields and input buttons to increment/decrement score values, modifying the value of a DIV via DOM manipulation. This is coupled with an AJAX process periodically submitting the form in the background to an ASP.NET script that reads the POST values and uploads the data to a database for storage. What I noticed is that despite the nature of a live sports data to change rapidly, the AJAX operation is called quite often (about every 10 seconds), but the DB doesn't need to be updated every single time. So the app becomes more efficient by making such updates conditional.

Using the .NET Cache API, I store the form's text field values in a custom object and place this in the Cache. Then, when the AJAX gradual upload process sends data across the wire, I do simple string comparison, testing the equality between the items in Cache and the current values of the scores from the form. If the values are the same, any modification operation is canceled and resources aren't unnecessarily wasted. If there's new data, the Cache entry is invalidated and rehydrated with the fresh data, and an UPDATE SQL statement via a sproc is executed.

More and more, models of this kind are becoming popular with people doing clever things with AJAX and responsibly wanting to manage server memory, disk space and bandwidth. It also proves there are many more uses for sever caching that just downstream.

Code forthcoming...

Wednesday, November 15, 2006

Book Review: "AJAX Design Patterns"

"AJAX Design Patterns" by Michael Mahemoff
Published by O'Reilly

Michael has quickly staked his claim as a major driving force in the world of software design, most notably in the vein of AJAX development, and his outstanding work on "AJAX Design Patterns" is certainly testament to that. Despite the book's title implying a heavy lean towards application development via asynchronous remote scripting, it's actually is more accurate in its subtitle, being applicable towards the trendier Web 2.0 movement (but given the mixed reactions to Web 2.0, I can see how such might want to be played down.)

The book's organization is logically laid out, providing a historical and academic profile of the technological foundations that gave rise to modern-day asynchronous programming. Michael then leads into the actual patterns, being grouped by function. Probably the most relevant to web developers are those related to into the various forms of web remoting, DOM manipulation, and next-gen visualization (i.e., drag-and-drop effects); while programming patterns geared for performance enhancement and code generation will whet the appetites of even the most advanced coders.

(Among my favorite patterns are those dealing with HTTP streaming (a field of which Michael's a pioneer), on-demand JavaScript, and content refreshing.)

If, for no other reason, you buy this book it should be for any developer considering themselves to be cutting-edge should buy this book for the section on Chapter 9 on REST applications development. This in my opinion is the most well-rounded discussion of what RESTful production is(n't), and how to incorporate such architecture into your own web projects. Being a .NET developer, that platform's framework serves to both abstract my kind away from having to directly deal with such concepts, or Microsoft blatantly neglects to mention it at all. After scouring the Web for months looking for good content on REST, Michael lays it all out in easy to understand lingo and examples. I'm having the REST chapter photocopied and bronzed for my desk. It's that good.

The one thing I didn't dig too much about the book is its exclusive lean towards PHP for examples where server-side logic was needed. While other platforms like J2EE, .NET, Ruby on Rails and Cold Fusion are keenly cited for their contributions and capabilities, the vast majority of the code is in PHP. But this is just a personal quirk…I'm obviously not big on PHP.

But that minor preference aside, I've followed this book's development since its days as a wiki. It's an invaluable resource as your online development begins to get more complex in a demanding world expecting web apps with rich UIs and multifaceted formats (e.g., JSON, SOAP, XML, et al.). I find it to serve equally well as programmer's reference and architecture guide. I rarely rate any books a perfect score, but this certainly is deserving of such a nod.

This is truly a masterpiece, and one that no developer doing Web 2.0 work should be without.

Tuesday, November 14, 2006

How did YOUR station do election results?

Jacob Kaplan-Moss of Django fame has a neato write-up on his blog about how 6News in Lawrence, Kansas generated their scrolling election results graphics for TV. We did something similar for integrating election data here at, just not with Python.

I ran a similar system of disparate devices calling a centralized tier of election data for my station's web site out here in Guam. Our big challenge is that we publish data multiplatform, exacerbated by the fact that in addition to being the main architect for all of our systems, I'm also co-anchor of our coverage and newscasts, so I can't be the guy to physically work on the systems.

Basically, I wrote a .NET sub-application that integrates with an Excel spreadsheet which holds vote tallies. These tallies are, sadly, faxed to us from the tabulation center, since our local election commission can't find a more automated way of distributing the data. I built a component that reads-in the information into a C# caching tier that does most of the math, sorting, numeric formatting, etc. and then writes an XML structure to disk. This XML is incorporated into various clients via a series of XSLT processes - our web site, our mobile framework, and our Pinnacle TV graphics system.

FXDeko software within Pinnacle reads the data from a URL and dynamically creates graphics based on templates. So while it's not as technically-impressive as 6News' system, it does work for us and lets us get results out in near-real time in a whole bunch of different platforms and formats.

Monday, November 13, 2006

Django book available (as beta)

There have been some delays in the much-anticipated release of the Apress book on Django (which was supposed to have been out by now. Fortunately, the boyz put up a beta site to give a glimpse of what's coming out. Believe the hype!

Sunday, November 12, 2006

Book review: DOM Scripting

DOM Scripting: Web Design with JavaScript and the Document Object Model

One thing that's tragically happened to many web developers wanting to be on the cutting-edge over the last several years is letting go of JavaScript due to features backed-in to server-side frameworks like ASP.NET, JSP, PHP and custom content management systems. These sorely forgotten skills were once thought to be a key arrow in any developer's quill. Well, now with AJAX and rich UIs being all the rage, it's almost mandated that developers will need to have a masterful knowledge of client-side programming for online apps. Many developers are now coming back to JavaScript, realizing that it's nearly a completely new language.

Author Jeremy Keith lays out a wonderful book about how easy it is to get (back) up to speed with DOM coding with JavaScript, CSS, XHTML and other related technologies and techniques. This is a wonderfully written title with a very friendly voice - neither intimidating to the newbie just picking up web development nor insulting to the experienced dev looking for a refresher.

The book's highlights are proper, best practices programming wrapped around a practical image gallery application. Graceful degradation, defensive coding and cross-browser compatibility are enforces throughout the book's many source code examples. The book's while the title implies heavy concentration on the DOM, is actually a thorough look at how to properly structure, format and control behavior in hyperdocuments. The book is a little light on AJAX, dedicating a single chapter to it but providing only a terse look at asynchronous programming. But the reference section more than makes up for it, being well stocked with JavaScript API members.

This is a fantastic work that any developer should pickup and make part of their library of in-quick-reach titles.

Wednesday, November 01, 2006

The future of book publishing: blogging

I just now realized that the two books I'm currently in the middle of, "AJAX Design Patterns" and "The Long Tail" both started out as online collections of articles on sites, with Michael Mahemoff's wiki and Chris Anderson's blog, respectively. They're basically aggregated, bound and sold for profit. I for one don't mind shelling out $$$ for such publications, as I loathe the concept of the e-book for longform reading.

Could this signal a sea change in how books get published? Is this the new generation of the graphic novel? I'm in.

This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]