Linux Journal Editor’s Choice Award, Development Book – Ajax Design Patterns

 

Just discovered Ajax Design Patterns has received the 2006 Editor’s Choice Award from Linux Journal for books on software development. It’s a personal honour, but it’s also a sign of the groundbreaking role Ajax has played in 2006.

Ajax Design Patterns, published by O’Reilly, assumes that you have a good idea of how HTTP, HTML, the DOM and CSS work (although it does help you brush up as necessary), and it shows you how to combine the basics into sophisticated applications. You can almost think of it as an Ajax cookbook, but with the underlying theory and advice that you need to make interesting applications.

Thanks to Jason Salas for passing on the news (Jason followed the book’s progress as it evolved and recently wrote a positive review on his blog.)

Ajax Functionality and Usability Patterns – Podcast 3 of 4: Visual Effects

This is the third in the four-part series on Ajax functionality and usability patterns (Book: Part 4, pp 327-530). An audio discussion of visual effects is ideally short and sweet, so this podcast is but 13 minutes long.

This 13-minute podcast covers ten patterns of Ajax Architecture (Book: Chapter 16, pp 445-472):

How Much Docs?

Nate’s talking about functional specs.

How much doco happens on a project is one part opinion and one part “what do you want to optimise for?”. I generally find there’s a dichotomy in attitude to software documentation.

1. Definitive (aka normative, exhaustive, complete, bureaucratic, rigourous, formal). The ideal here is that everything should be covered in documentation – the docs are a snapshot of every activity, plan, and state of the project. The aim is: (a) to let you carry on unhindered if “(stakeholder/worker) is run over by a bus” for all instances of (stakeholder/worker); (b) affect payments and provide legal evidence/cover. 2. Informative (aka agile, pragmatic, informal, half-hearted). Use docs pragmatically, to help explore ideas, reach consensus, remember what we said, etc. You cannot reconstruct a project from docs like this – if everyone is “run over by a bus” at the same time, there will be a delay and a subsequent divergence in the project direction.

That’s a clear distinction – in the Informative mindset, the docs are only there to reach a better quality result; in the Definitive mindset, we’re compromising some productivity for the sake of risk management (both (a) at a tactical level, i.e. if someone leaves; and (b) at a strategic level, i.e. upper management can theoretically be comfortable about how much is exposed and how much they’ll get back as a penalty if things slow down, etc.).

Both Definitive and Informative have a range of approaches. In particular, Informative use of docs can range from none at all, up to a project resembling a Definitive project, but when you look closely, the docs are lightweight and only subject to informal reviews rather than full-on inspections and audits. They may also the use of less conventional “documentation”:

  • Whiteboards
  • Post-it notes
  • Flashcards
  • Wikis and blogs.

As an agile proponent, I’d generally favour the Informative approach, but software isn’t developed in a vacuum. Organisations understandably want to be reassured about what gets delivered, which pushes them to rely on Definitive methods. The problem here, of course, is that Definitive-style docs require an almost impossible task of pinning down requirements, and furthermore, fixing requirements runs counter to the modern organisation’s goal of being agile.

There’s obviously no one solution, but one essential ingredient comes from multi-talented people. Too often, requirements are penned by business people on the assumption that software developers are left playing with their compilers. That’s changed a lot over the past five years, and organisations will do well when they hire business people who have an interest and competency with software, and software developers (fast becoming the majority) who can empathise with the business’s needs and are actually literate as well.

(I hope it doesn’t go unnoticed that Software As She’s Developed has actually posted about software development. That’s so ’04.)

Ajax Functionality and Usability Patterns – Podcast 2 of 4: Ajax Page Architecture

This is the second in the four-part series on Ajax functionality and usability patterns (Book: Part 4, pp 327-530).

The guest for this week is Dave Johnson of Nitobi (the Ajax component developers formerly known as E-Business Applications), widget guru and author of the upcoming Enterprise Ajax book. Dave helps me walk through the patterns and offers plenty of great insights along the way. We mention Dave’s recent presentation a couple of times; here’s the PDF.

This 54-minute podcast covers ten patterns of Ajax Architecture (Book: Chapter 15, pp 389-444):

Ajax Functionality and Usability Patterns – Podcast 1 of 4: Widgets of the Web

And so, a new series begins, based on the Ajax functionality and usability patterns (Book: Part 4, pp 327-530). We’ve already looked at the technical details, now we’re looking at what Ajax can do for users and how to implement these features.

I’m asking guests to join me for most of the remaining Ajax Pattern podcasts. Seeing patterns from someone else’s perspsective will make the discussion richer and hopefully cover more questions you might have as you’re listening to the podcast. The guest for this week is Andre Charland of E-Business Applications, widget guru and author of the upcoming Enterprise Ajax book.

This 83-minute podcast covers nine patterns of Ajax widgets:

Ajax Programming Patterns – Podcast 4 of 4: Performance Optimisation Patterns

The fourth and final podcast in this series of Ajax Programming Patterns. As always, the patterns are online at AjaxPatterns.org and covered in the book too, now available at Amazon. This 33-minute podcast covers seven patterns of Performance Optimisation:

(Note that the last two are recent additions to the wiki and just stubs at this stage.)

Okay, here endeth the series. I will soon be starting up a new series on the next group of patterns (Part 5 in the book): Functionality and Usability Patterns. There will be a change in the format, one I hope you’ll enjoy!

Ajax Programming Patterns – Podcast 3 of 4: “DOM Population” and “Code Generation and Reuse” Patterns

The third podcast in this series of Ajax Programming Patterns. The 29-minute podcast covers five patterns. As with the previous podcast, there is reason for concern about the audio quality herein. Firstly, three patterns on DOM population – taking server response data and displaying it or storing it in the DOM:

The second group of patterns (representing a different chapter in the Ajax Design Patterns book) are a couple of generic Javascript patterns to make the code more maintainable and portable:

Ajax Programming Patterns – Podcast 2 of 4: Browser-Server Dialogue Patterns

Continuing from the previous podcast (cough 12 weeks ago), more programming patterns. Unfortunately, this recording (and the next one) went pear-shaped. Sorry. I do, however, recommend them to those of you who’ve been wondering what an Ajax talk would have sounded like in crackly 1930s recording technology, and one in which the speaker has a severe cold. FYI The level was too low and it didn’t correct very well…maybe one day, I’ll re-record, but for now I’d prefer to just get them out there as they have been sitting in the libsyn archive for many weeks.

The 40-minute podcast covers the following patterns:

  • Call Tracking Accommodate busy user behaviour by allocating a new XMLHttpRequest object for each request. See Richard Schwartz’s blog entry.Note: Pending some rewrite to take into account request-locking etc.
  • Periodic Refresh The browser refreshs volatile information by periodically polling the server.
  • Submission Throttling Instead of submitting upon each Javascript event, retain the data in a local buffer and upload it periodically.
  • Explicit Submission Instead of submitting upon each Javascript event, require the user to explicitly request it, e.g. submit upon clicking a button.
  • Distributed Events Keep objects synchronised with an event mechanism.
  • Cross-Domain Proxy Allow the browser to communicate with other domains by server-based mediation.

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 podcast covers six patterns on Browser-Server Dialogue: Call Tracking, Periodic Refresh, Submission Throttling, Explicit Submission, Distributed Events,

Thanks for your feedback since last time. Good, bad, or ugly, it’s all welcome – in the comments for this podcast or michael@mahemoff.com.

Guard Clause Considered Helpful

Apparently, PragDave recently questioned the conventional wisdom about GOTO considered harmful (does this mean all “X considered harmful” articles will be retrospectively struck off the record?). Ivan Moore’s given an example as to why the rule of “a single exit point” sucks, and I agree.

Another reason for multiple exit points is guard clauses. Code units, like classes or functions, ought to look right at a high level. Just like with a piece of writing, it’s important that the overall structure gives you the big picture. Guard clauses help here. You can say, “Okay, let’s get the cruft out of the way – the trivial cases, the exception cases – and now we can focus on the main thing the function’s meant to do.”

  1. void foo() {
  2.   if (nothingToDo) { return; }
  3.   // Implement typical behaviour of foo()
  4. }

is much more readable than:

  1. void foo() {
  2.   if (!nothingToDo()) { // Hold my breath until the end
  3.     // *ugh* The typical behaviour buried in an if-clause
  4.     // And adding insult, we're now indenting more than we need to
  5. }

Steve Freeman points out, Ivan’s particular example could be refactored nicely into a single ternary operator statement. While they don’t scale to larger, more complex, functions, ternary operators are a very handy tool for the reason he explains.

Ajax Programming Patterns – Podcast 1 of 4: Web Service Patterns

Whereupon a new podcast series begins …

As promised, a new series of Ajax pattern podcasts. This is the first of four podcasts on the Ajax programming patterns.

In this 73 minute podcast, we look at the seven patterns of web services as they relate to Ajax clients.

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.

  • RPC Service Expose web services as Remote Procedural Calls (RPCs). (Note: In the book and wiki, REST appears before RPC.) (6:55)
  • RESTful Service Expose web services according to RESTful principles. (13:25 )
  • HTML Response Have the server generate HTML snippets to be displayed in the browser. (44:45)
  • Semantic Response Have the server respond with abstract, semantic, data. (49:00)
  • Plain-Text Message Pass simple messages between server and browser in plain-text format. (56:05)
  • XML Message Pass messages between server and browser in XML format. (57:20)
  • JSON Message Pass messages between server and browser in Javascript Object Notation (JSON) format. (59:55)

Thanks for your feedback since last time. Good, bad, or ugly, it’s all welcome – in the comments for this podcast or michael@mahemoff.com.