Basics of Ajax 3 of 3: Events and Much More (Podcast)

Ajax Basics 3 of 3

This is the final of three podcasts on the basic Ajax patterns.

  • Podcast 1: Display Patterns and the DOM.
  • Podcast 2: Web Remoting – XMLHttpRequest, IFrame Call, HTTP Streaming.
  • Podcast 3: Dynamic Behaviour – User Actions (Events), Timing, Ajax App, Web Service, On-Demand Javascript, Richer Plugin

Podcast 3: User Actions (Events), Timing, Ajax App, Web Service, On-Demand Javascript, Richer Plugin

Click to download the Podcast. You can also subscribe to the
feed if you want future podcasts automatically downloaded - check out the
podcast FAQ at http://podca.st.

This 77 minute podcast covers all the foundational technologies not yet covered in previous podcasts. Due to some reshuffling as the book was being edited, there are now four more patterns here than previously announced:

  • User Action Using the DOM’s event mechanism to deal with user actions such as mouse clicks (02:05)
  • Scheduling Schedule one-off or continuous events – Javascript code to run in the future (15:55)
  • Ajax_App The root of all Ajax (Note: The wiki version is empty at this time). Discussion of [Ajax Deluxe versus Ajax Lite]((http://www.softwareas.com/ajax-lite-versus-ajax-deluxe). (22:10)
  • Web Service The thing what sits on your server and gets called by the browser ‘n’ stuff (Note: The wiki version is empty at this time) (31:30)
  • On-Demand Javascript Remoting via Javascript – allows cross-domain remoting and lazy loading of modules (34:35).
  • Richer Plugin “Richer Plugin is an acknowledgement that Ajax alone is not always enough” (This pattern was the subject of the recent “What Ajax Can’t Do” debacle – Quote from Digg user: “This article is total crap.”) (48:20)

Featuring Ruby music by Why.

That completes the Basics series. Once the book is out of the way (Real Soon Now), expect to hear more Ajax pattern podcasts!

As always, feedback is welcome – michael@mahemoff.com

Basics of Ajax 3 of 3: Events and Much More (Podcast)

Ajax Basics 3 of 3

This is the final of three podcasts on the basic Ajax patterns.

  • Podcast 1: Display Patterns and the DOM.
  • Podcast 2: Web Remoting – XMLHttpRequest, IFrame Call, HTTP Streaming.
  • Podcast 3: Dynamic Behaviour – User Actions (Events), Timing, Ajax App, Web Service, On-Demand Javascript, Richer Plugin

Podcast 3: User Actions (Events), Timing, Ajax App, Web Service, On-Demand Javascript, Richer Plugin

Click to download the Podcast. You can also subscribe to the
feed if you want future podcasts automatically downloaded - check out the
podcast FAQ at http://podca.st.

This 77 minute podcast covers all the foundational technologies not yet covered in previous podcasts. Due to some reshuffling as the book was being edited, there are now four more patterns here than previously announced:

  • User Action Using the DOM’s event mechanism to deal with user actions such as mouse clicks (02:05)
  • Scheduling Schedule one-off or continuous events – Javascript code to run in the future (15:55)
  • Ajax_App The root of all Ajax (Note: The wiki version is empty at this time). Discussion of [Ajax Deluxe versus Ajax Lite]((http://www.softwareas.com/ajax-lite-versus-ajax-deluxe). (22:10)
  • Web Service The thing what sits on your server and gets called by the browser ‘n’ stuff (Note: The wiki version is empty at this time) (31:30)
  • On-Demand Javascript Remoting via Javascript – allows cross-domain remoting and lazy loading of modules (34:35).
  • Richer Plugin “Richer Plugin is an acknowledgement that Ajax alone is not always enough” (This pattern was the subject of the recent “What Ajax Can’t Do” debacle – Quote from Digg user: “This article is total crap.”) (48:20)

Featuring Ruby music by Why.

That completes the Basics series. Once the book is out of the way (Real Soon Now), expect to hear more Ajax pattern podcasts!

As always, feedback is welcome – michael@mahemoff.com

Ajax Lite Versus Ajax Deluxe

Harry Fuecks suggests there are two types of Ajax apps: HTML++ and Client/SOA. This is something I’ve noticed too, and it cuts right across the Ajax architecture, impacting on the user-interface, the physical architecture (browser-server separation) and the abilities of the developers involved.

The “Ajax App” pattern addresses this as a decision. It’s the root pattern for the entire Ajax Patterns language (Ajax App is not yet on the AjaxPatterns wiki). As you might know, each pattern has a “Decisions” section, identifying the decisions you’ll have to make if you go with the pattern. In the case of Ajax App, a big decision is how far along the spectrum you go. I’ve termed them differently to Harry, but the distinction is essentially the same (there’s now a footnote to his article). Extract from the “Ajax Design Patterns” draft:

Will your application be “Ajax Deluxe” or “Ajax Lite”?

There are two archetypal architectures for Ajax, and all applications lie somewhere along the spectrum between these extremities:

Ajax Deluxe

Ajax Deluxe uses Ajax to the max: applications feel similar to a desktop in that the browser is driving the interaction – it mediates all interaction between the user and server, so there are no – or few – direct page refreshes. Similarly, there’s no – or little – session tracking in the server, because all relevant state can be managed inside the browser. The server may not know about HTML at all, and just offer generic web services. An example is the Ajax word processor, Writely.

Ajax Lite

An Ajax Lite App feels more like a conventional web app overall, but one that’s been sprinkled with Ajax here and there. For instance, Ajax might be used to validate a form before it’s submitted using standard form submission, or to reveal some instructions on the page when a user requests help. An example is Delicious, which works fine on legacy browsers, but offers Ajax Suggestions for the many browsers that support it.

Which will you use? The Deluxe approach suits a development team with more advanced web programming knowledge and access to relevant tools and cross-browser libraries, and it will generally lead to a nicer, more effective, user-interface. It also facilitates a well-partitioned architecture, since the presentation logic can be isolated inside the browser and the business logic isolated in the server. However, Deluxe applications may place a strain on the browser and network capabilities, and might not even be possible if the browser is outdated. Ajax Lite is a better answer for older browsers, since the Ajax features can usually be “turned off” to support graceful degradation.

Epilogue:Another nice way to say this: “Ajax Deluxe” (or Client/SOA) == “Ajax Application”, “Ajax Lite” (or HTML++) == “Ajax Website”. The “Application” versus “Website” terminology was mentioned by Craig in the latest Polymorphic Podcast, Architecting Ajax Applications. If you want to hear more about the Ajax patterns (and since I’m so slow to complete my own podcasts on the topic, but I promise it will happen eventually!), check out this podcast, which is mostly about Craig’s take on Ajax Patterns. He’s not just regurgitating the patterns either, as he offers many fresh ideas and examples.

Ajax Lite Versus Ajax Deluxe

Harry Fuecks suggests there are two types of Ajax apps: HTML++ and Client/SOA. This is something I’ve noticed too, and it cuts right across the Ajax architecture, impacting on the user-interface, the physical architecture (browser-server separation) and the abilities of the developers involved.

The “Ajax App” pattern addresses this as a decision. It’s the root pattern for the entire Ajax Patterns language (Ajax App is not yet on the AjaxPatterns wiki). As you might know, each pattern has a “Decisions” section, identifying the decisions you’ll have to make if you go with the pattern. In the case of Ajax App, a big decision is how far along the spectrum you go. I’ve termed them differently to Harry, but the distinction is essentially the same (there’s now a footnote to his article). Extract from the “Ajax Design Patterns” draft:

Will your application be “Ajax Deluxe” or “Ajax Lite”?

There are two archetypal architectures for Ajax, and all applications lie somewhere along the spectrum between these extremities:

Ajax Deluxe

Ajax Deluxe uses Ajax to the max: applications feel similar to a desktop in that the browser is driving the interaction – it mediates all interaction between the user and server, so there are no – or few – direct page refreshes. Similarly, there’s no – or little – session tracking in the server, because all relevant state can be managed inside the browser. The server may not know about HTML at all, and just offer generic web services. An example is the Ajax word processor, Writely.

Ajax Lite

An Ajax Lite App feels more like a conventional web app overall, but one that’s been sprinkled with Ajax here and there. For instance, Ajax might be used to validate a form before it’s submitted using standard form submission, or to reveal some instructions on the page when a user requests help. An example is Delicious, which works fine on legacy browsers, but offers Ajax Suggestions for the many browsers that support it.

Which will you use? The Deluxe approach suits a development team with more advanced web programming knowledge and access to relevant tools and cross-browser libraries, and it will generally lead to a nicer, more effective, user-interface. It also facilitates a well-partitioned architecture, since the presentation logic can be isolated inside the browser and the business logic isolated in the server. However, Deluxe applications may place a strain on the browser and network capabilities, and might not even be possible if the browser is outdated. Ajax Lite is a better answer for older browsers, since the Ajax features can usually be “turned off” to support graceful degradation.

Epilogue:Another nice way to say this: “Ajax Deluxe” (or Client/SOA) == “Ajax Application”, “Ajax Lite” (or HTML++) == “Ajax Website”. The “Application” versus “Website” terminology was mentioned by Craig in the latest Polymorphic Podcast, Architecting Ajax Applications. If you want to hear more about the Ajax patterns (and since I’m so slow to complete my own podcasts on the topic, but I promise it will happen eventually!), check out this podcast, which is mostly about Craig’s take on Ajax Patterns. He’s not just regurgitating the patterns either, as he offers many fresh ideas and examples.

The Contractors Who Waste Time

Carlos Viellas has been watching contractors waste time (emphasis mine):

As I see it, there are two positive incentives: peer pressure in justifying rates, and collecting good contacts and references. In the situations we have been witnessing, those pale next to doing whatever is possible to extend the contract, which more often than not are some incarnation of finger-pointing, back-stabbing or just plain inaction in order to make the project as late as possible. By extending the contract, they can ensure there’s always time to fix the mess created by blaming everyone else but their contracting buddies (those who’ll happily point them to new gigs) and pretending to work harder than everybody else by assuming authorship of other people’s work and ideas, while happily surfing the web all day.

Actually, there’s another positive incentive: Good contractors enjoy doing a good job. Not for contacts or references, but because they just like what they do. I’ve been fortunate to work alongside people like this and they are often highly productive precisely because they want to be productive. As it happens, there’s a very different risk here – if there’s too much obstruction, too much politics, they’ll be the first to leave.

Under good project leadership, time-wasting contractors shouldn’t be recruited, and those who slip through shouldn’t last very long.

Detecting time-wasters during recruitment:

  • Check references (amazing how rarely this happens, maybe something to do with HR policies in many places that place a gag on non-HR staff giving references).
  • Look for genuine interest in software development – hobby work, professional groups, presentations, conferences attended. If they’re not really interested in these things, they probably won’t be motivated to do a stellar job on your project either.
  • Education and experience. It would be nice if you could learn “Information Security in 60 minutes or less”, but, well, you can’t. I think this is relevant to time-wasting because there seems to be a correlation. (Recent podcast with AT&T’s Ed Amaroso touches on this topic.)

Detecting time-wasters during development:

  • Daily Scrum meeting or equivalent. And if people have problems, take them seriously and deal with them.
  • Task estimation at an appropriate granularity, e.g. tasks of several days.
  • Encourage at least some pairing.
  • Real leadership.
  • Collective ownership, or at least ensure some people know the entire code base so you can ensure work is reasonable.
  • Avoid micromanagement. Nothing will destroy morale faster.
  • Moreover, keep people motivated to avoid time-wasting in the first place. (That’s a separate post.)

The Contractors Who Waste Time

Carlos Viellas has been watching contractors waste time (emphasis mine):

As I see it, there are two positive incentives: peer pressure in justifying rates, and collecting good contacts and references. In the situations we have been witnessing, those pale next to doing whatever is possible to extend the contract, which more often than not are some incarnation of finger-pointing, back-stabbing or just plain inaction in order to make the project as late as possible. By extending the contract, they can ensure there’s always time to fix the mess created by blaming everyone else but their contracting buddies (those who’ll happily point them to new gigs) and pretending to work harder than everybody else by assuming authorship of other people’s work and ideas, while happily surfing the web all day.

Actually, there’s another positive incentive: Good contractors enjoy doing a good job. Not for contacts or references, but because they just like what they do. I’ve been fortunate to work alongside people like this and they are often highly productive precisely because they want to be productive. As it happens, there’s a very different risk here – if there’s too much obstruction, too much politics, they’ll be the first to leave.

Under good project leadership, time-wasting contractors shouldn’t be recruited, and those who slip through shouldn’t last very long.

Detecting time-wasters during recruitment:

  • Check references (amazing how rarely this happens, maybe something to do with HR policies in many places that place a gag on non-HR staff giving references).
  • Look for genuine interest in software development – hobby work, professional groups, presentations, conferences attended. If they’re not really interested in these things, they probably won’t be motivated to do a stellar job on your project either.
  • Education and experience. It would be nice if you could learn “Information Security in 60 minutes or less”, but, well, you can’t. I think this is relevant to time-wasting because there seems to be a correlation. (Recent podcast with AT&T’s Ed Amaroso touches on this topic.)

Detecting time-wasters during development:

  • Daily Scrum meeting or equivalent. And if people have problems, take them seriously and deal with them.
  • Task estimation at an appropriate granularity, e.g. tasks of several days.
  • Encourage at least some pairing.
  • Real leadership.
  • Collective ownership, or at least ensure some people know the entire code base so you can ensure work is reasonable.
  • Avoid micromanagement. Nothing will destroy morale faster.
  • Moreover, keep people motivated to avoid time-wasting in the first place. (That’s a separate post.)

“Proving” a Technology

… a blog entry in which I define the term “proving”. I’m defining it here because I needed to link to a definition and couldn’t find a suitable URL to point to.

A few years ago, we were in a meeting when an architect explained to the project manager “we’ll be spending the first few weeks of the project proving the technology”. The manager was a taken aback. He took a deep breath and pointed out that the project was already committed to the technology – J2EE Web etc – and that the project sponsors would be a smidgen disappointed to learn that the underlying technology was “unproven”. Really, everyone was committed to the technology, but it was clear that no-one in the room (me included) had a solid understanding of “prove”.

What does it mean “to prove the framework” or to “prove the MVC architecture”? Are you proving these things exist? Checking if they’re feasible? Are you offering a mathematical proof that it’s the be-all and end-all? Here’s one definition:

  1. To establish the truth or validity of by presentation of argument or evidence.
  2. Law. To establish the authenticity of (a will).
  3. To determine the quality of by testing; try out.
  4. Mathematics. To demonstrate the validity of (a hypothesis or proposition). To verify (the result of a calculation).
  5. Printing. To make a sample impression of (type).
  6. Archaic. To find out or learn (something) through experience.

The third and sixth definitions say it best. Proving a technology means bashing it around to see what works and what doesn’t. According to The Straight Dope, it derives from a medieval term, Exceptio probat regulam, which is where you get seemingly paradoxical expressions like “the exception that proves the rule”, “proving ground”, and “the proof of the pudding”. However, said article also refutes that theory completely! In any event, it’s certainly a useful way to explain the usage in a software context.

Definitions – and arguments about them – are rather boring. This post is not here to prove a point (sorry), but to lend significance to an idea. Proving technology early on is a smart strategy for reducing risks later on. It’s really the idea behind the XP notion of “spiking” and also a key jusitifcation for the more traditional idea of throwaway prototypes; prototypes can be used to prove technology, not just for user acceptance.

Server-Centric versus Browser-Centric

James Strachan: Is Ajax gonna kill the web frameworks?:

So is the web application of the future going to be static HTML & JavaScript, served up by Apache with Ajax interacting with a bunch of XML based web services (maybe using SOAP, maybe just REST etc)? If so, do we really need a web framework thats focussed on HTTP and HTML, or are we just gonna end up developing a bunch of XML based web services and letting Ajax do all the templating, editing and viewing?

While I’ve kept [an open mind](http://ajaxpatterns.org/Ajax_Frameworks an open mind), pure separation is certainly the approach I’ve been using and advocating. Perhaps server-centric approaches can work okay for some intranet apps where the emphasis is on getting up and running, and where many developers want to focus on server-side concepts like messaging, DB, business logic, etc. But the bulk of applications are better off as browser-centric.

With tools like Dojo, Mochikit, Scriptaculous, Ajax Pages, you can quite happily get the whole UI encapsulated in JS. Amid all the Ruby uptake (and for good reason), JS has also come along nicely over the past twelve months. Not just libraries, but techniques for OO design, testing, etc.

In addition, as others have pointed out, the approach goes hand-in-hand with SOA: if you’re going to expose a clean REST API on your server anyway, it’s a no-brainer to proceed with a pure-browser UI. Testing becomes a lot easier too. Separating model and presentation has always been a difficult problem in software … when you have a solution as good as this, you have to put up a very strong argument against it.

So why are people still using server-centric frameworks? The biggest force of resistance seems to be the misplaced notion that JS is a hack and we must avoid working with it at all costs. Or maybe it’s less ideological than that, and because people just haven’t had time to learn it. Fair enough – it’s hard enough to keep up with server-side technologies. But a little time learning the basics of JS would certainly ease the pain of web development.

Advanced Feature Wishlist for Ajax Frameworks

Looking at the best practice/process patterns gave me some ideas for Ajax frameworks. Here’s a few thoughts. I know some frameworks already do some of these things, though most don’t, and none do all of them.

Logging frameworks should provide a sensible default, ie log to a div, but allow for more flexiblity on the logging strategy, as in log4j. For example, it would be nice to hook into a local storage solution like AMASS. I know we can all “spy on users”, but a local storage solution lets you amass lots more data, helps solve some privacy issues, and will survive network problems … could even help restore lots data. I’m obviously thinking more of intranets than public internet apps.

Mock object frameworks should, um ,exist. As I mentioned last week, there’s definitely a good case for a JS mock object library like JMock.

Web Remoting frameworks should:

  • Provide a high-level, technology-free, interface, and then implement it in as many ways necessary to support the greatest amount of browsers possible. Gloves off – IFrames, Images, Stylesheets … whatever works.
  • Make access to 3rd-party domains virtually transparent. e.g. CPaint does this by allowing a proxy option, which points to a proxy running on your server. That aside, calls are same as normal.
  • Support simulation. Let a caller prep the remoting framework with the response it should provide to a given query. Testing in that way, I could see very little reason to ever go back to the real server if you could do this.
  • Support logging. Rather flabbergasted that I couldn’t find a framework that supports logging of remote calls. The new Network Sniffing pattern describes other tricks for logging browser-server traffic, but the JS remoting frameworks ought to take care of it.
  • Support mocking. In addition to prepping with the response, the caller should be able to say “throw an exception if you don’t get this query”. Note that this wouldn’t need to be the responsibility of the remoting framework if there was a general-purpose mocking framework available.

8 New Ajax Patterns (Diagnosis and Testing)

Cool! The Best Practices/Processes Patterns are now complete. They are the final eight Ajax Patterns for now – “final” in the sense of “the list is not yet finalised”. The patterns had been sitting there unattended for about four months now.

More details on the new patterns later, but here’s a quick summary …

First, there’s a new demo – the Ajax Patterns Reader – the best version to try is at http://ajaxify.com/run/reader/logging/realService/. The reader grabs the AjaxPatterns.org content and presents them Ajax-style. You actually queue up patterns in a playlist and click “Next” to “play” them. Yeah, a bit contrived, but it helped illustrate quite a few patterns! If I have time, I’d like to enhance it into a proper reader, and also offer an easy interface to leave feedback, which would be automatically appended to the wiki’s Discussion tab for that pattern.

BTW This further refactoring of the Ajax Patterns Reader illustrates the Scriptaculous GhostTrain tool. If you haven’t seen GhostTrain, have a look – the Javascript will track your activity and build up a test case dynamically (covered in the new System Test pattern). All within the browser. I’ve been in contact with the developers (Thomas and Jon), and discovered it’s still proof-of-concept, but if they can tie it all together, it will be an excellent way to create a system/functional test.

Next, there’s four patterns on diagnosis:

And finally, four patterns on testing:
  • Simulation Service Develop the browser application against “fake” web services that simulate the actual services used in production.
  • Browser-Side Test Create automated tests of browser-side Javascript components.
  • Service Test Build up automated tests of web services, using HTTP clients to interact with the server as the browser normally would.
  • System Test Build automated tests to simulate user behaviour and verify the results.