I’m working on the rich UI of a small web application which has a problem I need to solve: the data from the server which the UI is presenting could change at any time. The first iteration of the UI has a refresh button. Clicking this button sends an Ajax request to a resource on the server which responds with a JSON data structure, and the UI is updated with any changes in the new data. My business partner doesn’t like the refresh button; he questions why it’s there and states how annoying it is to press the button all the time. His suggestion is the rich UI should smartly poll the server for changes to the data, and update the UI automatically.
Intrigued by his idea, we continued our discussion leading to a definition for what it means to smartly poll a server’s resource:
- Use conditional GET requests
- Retain the most recent Etag and Last-Modified date of the polled resource
- Disable polling when the browser window is inactive
Implementing a smart polling process in our application’s rich UI gives us some desired benefits:
- Removal of the refresh button
- Automatic updating of the UI when the resource on the server has changed
- Less repainting of the page since the DOM is touched only when the data has changed
- Changes to the UI only happen when the window is active (the user sees them) as polling is paused while the user is doing something else
Creating a reusable component to achieve a smart polling process feels like the correct approach as I foresee a need to use this functionality in future projects as well. Continue reading ‘Smart Polling’
Sun Microsystems now has a cloud-based computing business. Not only are they going to start offering cloud-based services similar to that of Amazon AWS and Rackpsace Mosso; they’ve also released a Cloud API specified with RESTful HTTP and JSON. Maybe more interesting than the technology choices, is that Sun is releasing it as an open-source project licensed with Creative Commons Attribution.
Tim Bray, the Director of Web Technologies at Sun Microsystems, blogged about his involvement developing the API:
The Sun Cloud: “This is a unified view of the storage and compute and networking services. It’s built around the notion of a ‘Virtual Data Center’ (VDC), which contains networks and clusters of servers and public IP addresses and storage services. The idea is to give you the administrative and operational handles to build something really big and ambitious. The VDC notion is really slick and I think something like it is going to be required in any serious cloud API going forward.
At the bottom level, the interface is based on HTTP and tries hard to be RESTful. All the resources—servers, networks, virtual data centers—are represented in JSON. [Don’t you mean XML? -Ed.] [Nope, JSON is just right for this one. -Tim]”
(Via ongoing.)
After reading Tim’s post, I went directly to the Cloud API project site on Kenai and read all the docs for the API specification. Reading the specs raised some questions, most of which others were already discussing in the forums. I’m really digging the RESTful HTTP with JSON APIs. It just feels more natural then the Amazon AWS APIs.
Sun is retaining the separation between the APIs and the implementations and encouraging other cloud providers to also implement their APIs. Potentially allowing a client to have interoperability between CSP (Cloud Service Providers). I feel similarly about CSPs adopting Sun’s Cloud APIs as I do with JavaScript libraries adopting the Sizzle JavaScript Selector Library; i.e. Amazon AWS should provide an implementation of Sun’s Cloud APIs, or someone should write an adapter.
While the Cloud APIs are still in-flux, they are defiantly on the right path here. Sun is listening to the community while taking the feedback seriously; great to see from a big company with their open source project. Sun is stepping up the game by providing not just cloud-based resources, but an API built on current technologies (RESTful HTTP and JSON) and allowing any cloud-based service provider to use it.
Great news for YUI3: Matt Sweeney, a YUI Developer, has integrated the Sizzle JavaScript Selector Library in a branch of the YUI3 code-base on GitHub. There has been interest from the community about this integration for quite some time. I personally was hoping for Sizzle adoption into YUI3; this now appears to be the case.
Using the Selector utility in YUI2 I would find myself hitting bugs and roadblocks where my expectations weren’t matching the outcomes. I’ve felt since first using the selector engine in YUI that it didn’t compare in speed, robustness, or completeness to jQuery’s. With the Sizzle project, there’s a narrow focus and distinct vision: To make the best damn selector engine. Since a selector engine is an essential component to any modern JavaScript library, why not make one really good one for all libraries to use? That’s the route the Sizzle project has taken.
Once Sweeney’s branch is merged into the YUI3 Master Head, I’ll be doing a git pull and give it some exercise.
Bazaar has become a tool I’m using all the time. Using Bazaar as a version control system means using a command line interface. I haven’t found a feature-rich Bazaar GUI tool like the ones that exist for Subversion. I feel alright with using a command line interface for executing commands; but it is frustrating to edit text, review diffs, and manage merges in a command line environment. It just sucks! I want something better: a work-flow that keeps me productive, and an appropriate interface for the task at hand. Specifically, I want my version control system to be integrated with my Mac and the existing tools I use; I want to be able to:
- Manage my files and folders using Finder
- Write commit messages, view diffs, and manager merges in TextWrangler
Continue reading ‘Using Bazaar On a Mac’