The more that server-side Web applications become immersive by following rich-application models and delivering personalized content, the more their architectures violate Representational State Transfer (REST), the Web's architectural style. These violations can decrease application scalability and increase system complexity. By achieving harmony with REST, Ajax architecture lets immersive Web applications eliminate these negative effects and enjoy REST's desirable properties.If you have any comments or questions on the article above, I'd appreciate if you would leave a comment to this blog entry.[Read More]
Jazz platform development
The article I recently wrote on the architectural issues of Ajax and REST is now online. Please note that this article only talks about runtime matters; I'm working on an article for next month that covers development-time and maintenance issues of Ajax applications. Here's the intro:
In response to my Ajax/REST article, Frank Staheli asked the following questions:
1. Can AJAX still take advantage of back-end database connection pooling (a huge disadvantage of client-server graphical apps, that they couldn't)? I would think so, but I'm not sure.
There is no conflict between the Ajax/REST architecture style I described in the article and database connection pooling. In fact if you're using J2EE, you can use pretty much any current J2EE facility you want, with the exception of JSP/JSF, which aren't necessary if you're doing pure Ajax/REST (although they are still relevant if your web app's a hybrid).
2. How does my AJAX app handle a server crash? Because would the readystate not change with no response from the server? Would the connection eventually time out?
First of all, I don't mess around with low-level XHR stuff. I prefer to use higher-level frameworks like Dojo or Prototype which provide relatively abstract Ajax request invocation libraries - which do time out after a period of time (and I believe this may even be user configurable in Dojo) and calls an error callback function which you control.
So how you deal with this error is purely a matter of user experience design. First remember that the only "critical time" where a server crash should affect a user is if the server is down when the user performs a gesture that causes a remote Ajax request to fire (or if a the Ajax app sends a background remote request - more on that later). With that in mind, also remember that a user using a web browser spends probably 95% of their time not interacting with the app but rather just looking at what's on their screen, so 95% of their time they're not invoking remote actions. It's entirely possible that the server could hiccup and come back between user interactions, and the user would be none-the-wiser (assuming a stateless server, which I strongly recommend).
One other corner case - many Ajax apps perform background requests that aren't caused by user interactions (e.g. Gmail checking for new mail). If one of these background operations fail because the server isn't responding you can either choose to fail silently or warn the user that the server's down. You should fail silently if there's no chance that the user may lose work if the server's down. E.g. if your application's relatively read-only, you may as well wait to notify the user of a server problem until they perform an explicit action that requires server responsiveness since the server may come back before the user performs that action. If your application allows the user to create data (e.g. sending emails, filing bugs, etc.) you may want to proactively warn the user that there's a server problem and they won't be immediately able to save any data they enter until the server comes back online (this is another great use case for 'ping server to determine when it's back up' user experience described above). If you're REALLY on the cutting edge, you can use something like dojo.storage that can store data locally for later remote replication, but this requires that the user have Flash installed, which has some consumability implications.
- Bill[Read More]
billhiggins 1000006JUS 2,364 Visits
I meant to write this a few weeks ago but got bogged down in finishing up some development. A few weeks ago I wrote a post called "writing to learn" where I talked about a point Grady once made that writing for others is (paradoxically) one of the best ways that you yourself can gain a deeper understanding of some topic. Shortly thereafter I got the following note from Grady which provided a great parallel insight:
I was talking a walk last night, and realized I needed to augment my last comment... I also learn by writing... not just words but also models and code. For example, I may have an idea of how to structure a system, but until I cut some code against it, I won't really know for certain.This is the exact same way I work w/r/t to architecture/design vs. coding. It's not a linear process of do one then do the other. I get a very rough understanding of what's necessary in a design and then try to implement the thing. Sometimes it goes smoothly and my first attempt basically works but sometimes I realize that there's a broken assumption that dooms my current thinking and then it's back to the drawing board. The reason this relates to the "writing to learn" post is that when you write about some topic you have to serialize fuzzy notions into sentences that actually (hopefully!) form coherent paragraphs. Likewise when you descend from the stratosphere of architecture/design to implementation, it forces you to discover both wrong assumptions but probably more importantly "unknown unknowns" that you simply don't fathom at the design-level.
On the other hand, if you only ever work at the code-level, you often lose yourselves in the details and hardwire your brain down a certain path that may or may not be optimal. It's important to force yourself to take a step back and move your brain back to the design-level - I do this by physically stepping away from my Thinkpad and going for a walk - and letting your mind kind of wander about the problem. With any luck you'll have one or more Archimedian "ah ha" moments where you realize insights that end up greatly simplifying your design / solving previously unsolved problems.
Then it's back to coding to validate assumptions, find new broken assumptions...
Washington Post: "Researchers See a Downside as Keyboards Replace Pens in Schools".
I've experienced this myself on the odd occasion that I have to write something longhand and can't remember how to write a cursive 'Q'/'q', 'r' or 'Z'/'z'. But really, who needs longhand if you can type 100 words a minute?
I'm still quite proficient at signing my name... thank you MasterCard :-)[Read More]
billhiggins 1000006JUS 510 Visits
A topic most web developers are familiar with is the browsers' notion of quirks mode and standards mode. I just learned a neat trick to determine which mode your page is in. On any web page, paste the following into the browser's location box and press enter and it will tell you which mode your page is in:
This may not seem like a big gain, but if you find yourself manually clearing your cache 50 times a day, 10 seconds each time, you'll quickly appreciate the time and effort you save.
Here are some links and screenshots:
To anyone reading this blog with Microsoft Internet Explorer:
Internet Explorer version 7 was released a couple of days ago. In the coming weeks, Microsoft will automatically install IE 7 on your machine unless you take steps to prevent it. Since you're going to be getting a new browser anyway, why not switch to Mozilla Firefox?
Get Firefox. Now.[Read More]
billhiggins 1000006JUS 494 Visits
A few weeks ago I wrote about the value of aggressively self-hosting on your own software and how it helps you to discover problems much earlier than in a typical waterfall lifecycle, where the customer first uses the software many moons after you started developing it. We're lucky in Rational, because since we create software development tools, we're essentially developing for ourselves. This has a funny downside.
We have a hellacious time talking about developing our own software, because we have to use terms that are both meaningful to our own development activities but also the products under development.
After a while you learn to speak slowly and clearly :-)[Read More]