Thursday, June 01, 2006

Rolling Your Own AJAX (Part 2)

I left off talking about some of the perceived UI benefits of using AJAX. What I'd like to cover now is how I modeled the AJAX client library for this project. I did some research into some of the existing solutions, and there is some good stuff out there. Dojo is a very robust client-side library that goes way beyond simple AJAX functionality, and there a couple of .Net frameworks available, too (Ajax.Net and Atlas come to mind...I'm sure there are many more). For the project at hand, I decided to construct a framework from scratch--a direction I almost always lean toward.

Here is the object model I came up with, and the general rolls each would play:
  • AjaxMessage: This object encapsulates a single callback to the server, and contains the request details, response details, and handling details (a reference to the callback function). It also contains the actual HTTP request (which I will most likely decouple when I refactor this puppy).

  • MessageBuffer: This object is essentially a traffic controller, and determines how messages will be handled in the context of the page. When going through possible AJAX use-cases, I felt like we needed a lot of control here. In the project at hand, the user had the ability to request information faster than it could be processed. The MessageBuffer object can be set up to send messages immediately or in batches, and can filter duplicate messages.

  • MessageCache: This is a repository for "cachable" messages. If a message is deterministic (will return the same results with the same inputs), it can be cached and the return data accessed later without going back to the server. This object manages cache settings including capacity, threshold, and expiretype (messages can be set to expire after a given amount of time, or via a least-frequently-used algorithm.)

  • CacheObject: This is simply an AjaxMessage object with cache meta-data.

  • Request Pool: OK, this was something I coded before had fully researched it. The idea was to create a pool of HTTP Request objects when the AjaxFramework is initialized to avoid the overhead of object creation for each request. Great idea in theory, right? The problem is the HTTP 1.1 specification says that only two request objects can be open by a browser simultaneously. IE adhere to this by default (although it can be changed in the registry) while Firefox has a default of eight. Oh well, if this changes in a future release, I'll be ready ;)

Here's what the model looks like for you UML folks out there:



Next, I'll get into some of the implementation details and specific features of the framework.

Saturday, May 27, 2006

Rolling Your Own AJAX (Part 1)

As AJAX has grown as a programming paradigm for the web, there has been an emergence of platforms to support development. I was lucky enough to work for a company that got into the web 2.0-game fairly early and was tasked with designing and creating a client-side framework along with some new form controls (the code I’m going through here was written about a year ago). Today, I’ll talk a little about some of the benefits and challenges of using AJAX in web user-interface design.

This was one of those rare projects where we were given adequate time to do a good job, so I spent a lot of time thinking about what some of the challenges were going to be, both for this and future implementations. AJAX creates an illusion of immediacy to the user by bypassing many of the redundant processes of a typical postback. Think about the lifecycle (we’ll do a simplified version) of an HTTP page request on the web.

  1. The user makes a request by clicking a link or submitting a form

  2. The browser makes a request to the destination web server

  3. The browser receives the response as a text stream

  4. The response is de-serialized into a document object

  5. The page artifacts (images, video files, JavaScript and CSS files, etc) are identified, and latent HTTP calls are made for objects that are not available in the browser cache.

  6. The browser paints the HTML page based on the document object and page artifacts


In an AJAX model, steps 4 - 6, are bypassed and the data from the request is simply inserted into the existing DOM. Three fairly expensive and unnecessary processes (because they were handled with a prior request) have been replaced with a lightweight operation. So how does an intrepid developer take advantage of this technological wizardry? Basically, the same object that is used by the browser to make server request is exposed and can be accessed through JavaScript.

It looks like this could get a bit long, so I think I’ll make it a trilogy. In the next part, I’ll dig into the hows and whys of the framework I put together for the aforementioned project, and see where it goes from there.

Wednesday, May 24, 2006

The Skills that Don't Pay the Bills

The other day I was asked a question by a friend/co-worker about what skills are important to have for a developer today. Reflecting on the question, I think he wanted to know what skills make somebody a more attractive candidate on the job market. Of course rather than answer the question, I went off on a tangent regarding a recent pet peeve of mine.

More and more, I'm finding that .Net developers are losing touch with how things work. Microsoft has abstracted many programming functions to such a high-level, many people in the industry have forgotten (or no longer bother to learn) what's going on under the hood. I suppose this is a natural and necessary evolution; the growth of the talent pool doesn't come close to the expansion of software development and implementation needs. By dumbing the work down with every release, Microsoft expands the pool of workers while fostering a need for the latest software and training.

The result is an increasing gap between programmers/engineers and coders. So my answer to the original question was--try to be the former rather than the latter. In many ways the distinction is subjective, but if I wanted to gauge somebody's programming abilities, here are some of the things I might ask.
  • Write a function that sorts an array. Describe it in big-O notation.

  • Write the pseudocode for a simple XOR encryption algorithm

  • You have a table in a database with 1,000,000 rows and need to extract a single-specific record. What is the maximum number of records that will need to be evaluated to return the required row if the column you're looking at has a clustered index vs non-indexed with unique values.

  • Write your own string-builder

  • Design a custom cache mechanism

From what I've seen of the job market of late, it's unlikely these things are going to help one command a higher salary, but I think this depth of understanding is becoming a lost art in business software development.

Sunday, May 14, 2006

So This is a Blog...

So I've been reading a lot of these blogs lately and figure it's time to throw my hat in the ring. My name is Jeff, and I'm a web software engineer currently living in San Diego, having recently moved from the Boston area. I've been a web developer for the past 8 years or so and have mostly worked in Microsoft technologies on the server side.

Some of the topics I plan to tackle are architecture and design, coding practices, hiring and interviewing, and emerging technologies. I'll also try to reflect on projects and jobs I've had in the past, and compare and contrast working on opposite coasts. With any luck, I'll stick with it for a while. Who knows, maybe somebody will even read it from time to time.