Mocks, Stubs, Dependency Injection, and … XMLHttpRequest

“A Mock Is Not So Stupid After All!”

Dave Crane’s been talking about Mocking the Server-Side:

A Mock Object is a stand-in for the real thing. Few modern programs are really standalone, and enterprise apps require a very complex context in order to operate; containers, databases, directories, web services, etc. This can make testing difficult, because to set up the test and run it, one needs to provide all the necessary context. Mock objects can be thought of as really dumb implementations of a contextual element, one that would never be useful in production, but provides the predictability and ease of setup required for a test. A mock database might always return the same four rows of data, whatever the WHERE clause. A mock web service might always serve up the same XML document.

So the idea is to create a simulation XML document (or plain-text document) to be retrieved with XMLHttpRequest.

Dave’s followed up with some good tips to that end. All good timing as I’ve recently been working on a demo for the final lot of patterns – the process patterns – and one of the refactorings uses a canned plain-text document to illustrate The Pattern Currently Known As “Server-Side Simulation Stubs” (who said alliteration had no place in software writing?).

Worth noting the terminology used, and here I’ll be pedantic. Dave refers to a Mock what I call a Simulation Stub. In the past couple of years, the terms “Mock” and “Stub” have often been used interchangeably, but I think the distinction is worth keeping, because otherwise the original meaning of Mocks is lost. I don’t really care what things are called, but when two concepts become one name, at least one of those concepts is going to get hurt. It’s a testament to the creators of Mocks that they managed to produce a name so evocative that it’s come to consume a much older concept. (“Stub” and “Shunt” have always been pretty vague terms anyway.)

Under the original definition, a Mock is an object that verifies how it’s being used by a tested object, and by inference, how things like it will be used by the class being tested. Yes, it might spit out simulation data, and it might even have a fancy interface that lets you tell it how to respond. However, those functions are only there to help verify how it’s used. It’s what goes into the mock that counts, not what the mock pumps out. Corollary: a Mock is not stupid. It might not win a Nobel Prize anytime soon, but it’s smart enough to know what to expect and how to check if that expectation’s been met. The mixing of terms has carried over to some parts of the Ruby/Rails community, as Aslak recently observed during a RubyConf presentation. (Podcast on mocks, Fowler’s Mocks Aren’t Stubs.)

In a web context, what might the distinction mean?

  • A Simulation Web Service (or a “Stub Web Service”, but I prefer “Simulation”) is typically some XML or plain-text document that’s been written manually. It could also be a bit more sophisticated, offering a means for the server-side developer to tweak its output.
  • A Mock Web Service is a server-side script that’s been configured to expect a certain sequence of XMLHttpRequest messages, and will carp as soon as the sequence is broken.

As Dave’s articles explain, a Stub Web Service is certainly a useful thing, and I suspect quite a few developers follow that practice. (Please tell me about it if you do!)So how about Mock Web Services? That’s pure speculation!! I could see the benefit, but I’ve not done it, haven’t heard of anyone doing it, and I seriously doubt there are any frameworks that facilitate it.

A variation on Simulations and Mocks would be a completely browser-side approach, in which you adopt an XMLHttpRequest wrapper, and make it output a dummy document while in “testing” mode. This raises further questions:

  • How are mocks handled in Javascript? Well, William Taysom recently noted that you can approximate method_missing, and a Mock library like the awesomely useful JMock library is clearly feasible. There are a few JUnit equivalents out there, so why not a mock lib? (Would you use such a thing?) If you say that would be over-engineering, then the same charge could be made about JS testing in general, since mocks are really a natural consequence of unit testing and TDD … any time you find yourself testing an event mechanism, a mock might be a good idea.
  • How to switch context in Javascript? Okay, so mocks are a big reason for the rise of Dependency Injection and “lightweight” ((http://www.almaer.com/blog/archives/000846.html)) containers in Java/J2EE/JEEWhiz. Well then, doesn’t Javascript need the same thing? Again, I know, “you’re over-engineering it, Mahemoff”. So maybe I am. It’s been said that Dependency Injection doesn’t do much for Ruby, and maybe the same’s true for JS. So how then, do you make your browser app switch between a mock web service and a production service? The answer is not, “change the source code”, because to achieve continuous integration, you want to keep an automated test around that calls the mock service. Maybe the best thing to do is rely on DI – or some other context-switch mechanism – in the server, so that the Javascript that it spits out will differ according to the environment.

Podcast Interview with Alexander Kirk (Blummy, Bandnews)

This 47-minute podcast is a discussion with Alexander Kirk, creator of the recently released Blummy (which I mentioned last week) and also Bandnews.

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.

A few things we discussed:

  • The design behind Blummy. (Interestingly, I was incorrect to guess it uses XHR – basically, the Blummy is like a Greasemonkey script – it uses DOM manipulation to alter the page you’re on, building up the container of all the Blummlets, and interacts with other sites using standard HTTP requests.)
  • Plans for Blummy, its use of Lazy Registration, security issues.
  • Developing for cross-browser compatibility.
  • Passing data from another domain with JSON.
  • The design behind Bandnews. Most band websites don’t bother with RSS, so Bandnews creates its own RSS feed, which is what the browser script reads.
  • Why some Ajax apps are slow and what can be done about it.
  • Libraries mentioned: dojotoolkit, prototype.

Basics of Ajax 1 of 3: DOM and Display Manipulation (Podcast)

The Basics of Ajax: A 3-Part Podcast Series

I’m beginning to podcast about specific Ajax patterns. To start with, a three-part series on the basics of Ajax development, covering all the Foundational Technologies patterns:

  • Podcast 1: Display Patterns and the DOM.
  • Podcast 2: Web Remoting – XMLHttpRequest, IFrame Call, HTTP Streaming.
  • Podcast 3: Dynamic Behaviour – Events and Timing.

These will be useful if your familiar with basic forms and CGI-type web development, and wanting an overview on Ajax development techniques.

If you do know enough Ajax to at least write the obligatory Ajax chat application, there’s probably not much new info here. The most interesting pattern will be HTTP Streaming, covered in the next podcast.

Note that the pattern names and structure are subject to change, but the basic ideas will remain valid.

Podcast 1: Display Patterns and the DOM

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 42 minute podcast covers the DOM and the following patterns:

  • Display Morphing: Morph display elements by altering styles and values in the DOM, such as text and colour properties.

  • Page Rearrangement: Add, remove, move, and overlay elements by manipulating the DOM.

Credits and Production Notes

  • The podcast concludes with the world’s first HCI Rap, “We Got It”, from the multi-talented team at OK-Cancel (the website with the funniest usability cartoons around).
  • The theme, My Morning Jacket’s “One Big Holiday”, is back too.
  • For the podcasters among you, the podcast was produced on a Powerbook running the excellent Audio Hijack Pro, with Bias SoundSoap and Apple’s new AUAudioFilePlayer plugin to cue audio. For the podcasters among you, this is a nice, easy, setup: allows recording directly to MP3, real-time noise reduction, ability to cue up sound clips, tag the MP, run a script at the end (which could FTP the file somewhere). In theory, you could have a podcast up a few minutes after you’ve clicked the stop button. Rogue Amoeba, creators of Audio Hijack Pro, know how to make software that’s intuitive and seriously useful. There’s detailed instructions for podcasters in the manual and also a blog entry on podcasting with Audio Hijack Pro.

Pros and Cons of Ajax

I just updated the ajaxpatterns.org “What’s Ajax” page to include more info on Ajax Benefits, and added a new section on Downsides. Have I missed any?


Benefits of Ajax

  • Web as a Platform: The web is no longer just about websites that expose some information; it’s increasingly being used for full-blown applications. These applications demand richer styles of interaction.
  • User Frustration: The standard “click-and-wait” form-based model no longer suffices. Most people are now au fait with the basics of the web and are ready for something more.
  • Web 2.0 Zeitgeist: Ajax sits well in the “Web 2.0″ umbrella, with many of the Web 2.0 poster-child projects – such as flickr and technorati – incorporating Ajaxian features (having started before the “Ajax” term came about). Web 2.0 is about new ideas and the $$$ to make them happen, and Ajax is certainly creating opportunities for new breeds of applications, as well as fodder for improving existing systems. Ajax is the “web” in web 2.0.
  • Multiple Access Points: Many people use more than one computer. People are using computers at home, at work, at school, in cafes. Laptops and portable hard drives offer one solution, but they are inconvenient, at risk of theft, and often not able to be plugged in. Hosting the data online is a more straightforward solution and accessing it from a rich web application is a natural fit.
  • Web as the only Platform Thanks to the widespread adoption of public internet access, the so-called technology gap between countries and between socioeconomic groups is closing. Many people don’t actually own a PC, but do have regular access to the web at internet cafes or schools or friends’ homes. For this diverse category of user, there’s no point installing applications and keeping their data locally. The web is their only platform.
  • Better Infrastructure: Many homes now have broadband, and server capacities have continued to improve in the past few years. Due to frequent back-and-forth between client and server, Some Ajax applications can be hungry for both bandwidth and server capacity. Furthermore, server-side storage is cheap enough for many individuals and companies to prefer holding data online, which makes it feasible to access via a web application.
  • Productive Development: For developers a web programming model can be far more productive than a the conventional GUI alternative. Developers only have to produce a single product for all platforms, they can upgrade the application frequently rather than in “big bang” style (have you ever seen a website version number?), they can choose whatever programming language and libraries they care for.
  • Browser Improvements: While the basics of Ajax have been present for several years, browser improvements in areas such as XML-processing and debugging support, as well as adherence to standards, have eased the pain for the Ajax development style.
  • Security Concerns: As security concerns have heightened, companies are now quicker to lock down desktops and forbid browser plugins. Web applications hosted on a company’s intranet are therefore a boon for security, and allow for tighter monitoring and access control.
  • Platform Diversity: The rise of Apple, combined with the ever-present desktop Linux, means that many applications must be developed in a portable way, and choosing the web platform is one popular way to achieve portability.
  • Browser Diversity: Flock, Safari, and Firefox have joined Mozilla and Opera in offering serious alternatives to Internet Explorer which can no longer be ignored by mainstream developers. Most Ajax techniques, being based on standard browser features – albeit more modern ones – can generally be applied on all the recent browsers.

It’s also worth noting why this information has spread through the community so quickly:

  • The ‘G’ Factor: Several prominent Google projects have been thoroughly Ajaxian, including Google Maps and GMail. When Google talks, people listen.
  • Simple Message: Ajax is a straightforward message: all you have to do is point someone at Google Maps. It’s a lot easier than explaining “the long tail” or “the folksonomy” :-P.
  • Rapid Dissemination: Due to RSS, blogs, and podcasts, any worthy information is rapidly disseminated. For the reasons above, Ajax struck a chord in the community. Once a name was there for this desirable style of development, everyone wanted to talk about it.

Downsides of Ajax?

Ajax is a trade-off. Any developer considering its adoption should be aware of the downsides, such as:

  • Limited Capabilities: Some Ajax applications are certainly doing things people never dreamed were possible on the web, but there are still substantial restrictions of the web platform. For example: multimedia capabilities, local data storage, real-time graphics, interaction with hardware such as printers and webcams. Support for some of these are improving in recent browsers, some can be achieved by delegating to Flash, but many are simply not possible, and if required, would rule out Ajax.
  • Performance Concerns: Constant interaction between browser and server can make an application feel unresponsive. There are, however, quite a few well-known patterns for performance optimisation such as browser-side caching. These usually suffice, even for fast-paced applications like stock trading, but Ajax still might not work for really time-critical applications such as machine control.
  • Internet Access Required: The user can’t access an Ajax application in the absence of a network connection.
  • Second Programming Language: Serious Ajax applications require some knowledge of Javascript. Many developers are discovering that Javascript is actually a more capable language than at first assumed, but there is nevertheless an imposition to use a language different to that on the server-side.
  • Easily Abused: As with any powerful technology, Ajax concepts can be abused by careless programmers. The patterns on this site are intended to guide developers towards more usable solutions, but the fact remains that Ajax isn’t always be used in a manner that supports usability.

Google Base = Flickr + Odeo + Typepad + …

Google Base: It goes beyond classifieds. The popular view today seems to be that Google Base is all about classifieds, but as mentioned earlier, it’s much more than that. (Incidentally, still smarting I missed the “All Your Bases” happy fun humorous moment opportunity.)

If Google Base lets you tag entries, you could easily create a podcast feed by just uploading MP3s and giving each the same tag. Likewise, you could create a blog by uploading text entries with the same tag, and a vodcast with videos. Google could easily offer a wiki interface to let you manage all your content, and a feed to go with it.

From a programming perspective, what’s nice about all this is the prospect of a common API for all sorts of content.

So while Craigslist ought to be watching closely, so should many others. This is Google’s answer to Flickr and just about everyone else who’s hosting microcontent.

Google’s Microcontent Engine

Google’s apparently releasing base.google.com. While some see it as a Craigslist play, it’s a lot more than that: Google has seen the future, and the future is one big mashup of microcontent. “A” microcontent is a small chunk of information, typically with its own URL, but not actually a web page. It’s not a web page because it’s raw content, without being wrapped in navigation, disclaimers, etc. As some of the Ajax portals show, there’s a confluence here: Ajax allows for easy manipulation of microcontent. Tiddlywiki is based around the idea of microcontent, and allows you to conjure up some microcontent by clicking on a Microlink.

Classified advertising is the most obvious path to revenue, so the screenshot emphasises commercial applications. But a classified ads is just one special case of Microcontent. As they say: “Google Base is Google’s database into which you can add all types of content”. Sounds a lot like a repository of general-purpose microcontent.

Ladies and Gentlemen, get your mashup on! I’m betting on a Maps-Base mashup about 90 seconds after Base goes live. Google probably won’t bother integrating Maps themselves – they may as well sit back and see what works before buying one or developing their own solution.

In other Google-Ajax news, Jonathan Boutelle points out that Google’s foray into mobile is full-on motivated by Ajax: being offline is a big objection to migrating desktop apps, so Google wants to render that a non-issue.

Blummy: The Mother of All Bookmarklets

Check out Alexander Kirk’s new website: Blummy. A blummy is a kind of bookmarklet that opens up a kind of pop-up portal, giving you access to various web services. Just like a portal is made up of Portlets, a Blummy is made of Blummlets, which essentially do the kind of things bookmarklets do. e.g. A blummlet can let you subscribe to this page with Bloglines, change the browser location, or show an image. Where the blummlet is interactive, the action takes place within the popup as a Live Form.

Here’s a few interesting things about the site:

  • Because the Blummlet lives in a bookmarklet, XMLHttpRequest can access any domain. Scott Isaacs recently suggested it would be worth the risk for browsers to drop the same-domain policy, though it’s unlikely to happen anytime soon. A bookmarklet, I’m guessing, gets around that constraint.
  • The site lets users share Blummlets, which might lead to Cross-Site Scripting (XSS) attacks like the now-famous myspace effort. Alexander’s well aware of this risk, which is why there’s a “Report Concern” checkbutton. It will be interesting to see how this kind of moderation works out. I still think users might need something stricter, like a whitelist approach, where Blummlets have to be explicitly approved by “the community”, i.e. guilty until proven innocent. (This is still vulnerable, but I think it’s a better trade-off overall.)
  • There are shades of yubnub here, as well as the widget/gadget/startlet idea seen on start.com. Leading to a repository of Blummlets. I mentioned to Alexander it would be nice to see an RSS feed, where users could somehow drag or a Blummlet into their existing Blummy.
  • Speaking of gadgets/widgets, the popup feels something like Dashboard and Konfabulator. Another example of tha Ajax Desktop, and a pretty useful one in this case. There are various popup bookmarklets like JSCalc, which offer one particular function. They are convenient , but there’s no central management point, and a lot of duplication and inconsistency in how the manage the popup experience. So Blummy does to the browser what Dashboard does the windows system: provide a common structure for individual applets. I haven’t looked into the programming model, but there’s probably good scope for a JS util library to further facilitate Blummlet development.

New “Ajax” Category in this Blog

I’ve been posting Ajax entries under “HumansAndTech” or “SoftwareDev” or both and holding off on a special category. I’m grateful that the Ajaxians included me in their planet.ajaxian.com feed, and that’s the tipping point for me: I still want to write about agile, OO, etc., without polluting the Ajax sphere. Hence, a new “Ajax” category on Software As She’s Developed, with all previous entries marked as such. So if you only want Ajax-related blog articles and podcasts, point your browser to http://www.softwareas.com/category/ajax/rss2 and your aggregator to http://www.softwareas.com/category/ajax/rss2.

Ajax Myths (Podcast and Text)

It’s that time in a technology’s lifecycle when myths abound and someone wheels out a collection of “myths” and retorts. Here’s my contribution to that time-honoured genre. Nine myths in 37 minutes.

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.

Myth: “AJAX”
Reality: Ajax

Myth: Ajax is rocket science
Reality: It’s an incremental progression

Myth: Javascript sucks
Reality: It doesn’t

Myth: The URL’s always the same
Reality: Unique URLs are possible

Myth: Ajax==XMLHttpRequest
Reality: There are other remoting technologies, and some Ajax apps don’t need any at all

Myth: The server must output XML
Reality: Server can output plain-text or specialised formats like JSON

Myth: Ajax lets websites spy on users.
Reality: The same “spying” techniques have already been possible using images and form submissions.

Myth: Ajax will crush Flash.
Reality: Flash can augment Ajax.

Myth: Ajax will rule the world!
Reality: Ajax still has many challenges ahead: usability, accessibility, portability, scaleabiity …

State of the Ajax Frameworks

The publicly-editable Ajax Frameworks Page got a nice kick along in the past few days, presumably due to a recent link from Ajaxian. If this list is anything to go by, the most common language is pure-Javascript, and Java is, as you might have guessed, highest on the server-side, followed by .Net and PHP. Sections for Python and Perl were opened up during this time. Thanks for your contributions!

1 Pure Javascript: Application Frameworks

  • 1.1 Isomorphic (Commercial RIA Toolkit)
  • 1.2 Bindows (Since 2003)
  • 1.3 BackBase (from 2003)
  • 1.4 DOJO (Under development; from September, 2004)
  • 1.5 Open Rico (Under development; from May, 2005; based on earlier proprietary framework)
  • 1.6 qooxdoo (Under development; from May, 2005)
  • 1.7 Tibet (Under development; from June, 2005)
  • 1.8 AJFORM (Since June 2005)
  • 1.9 ThyAPI (Under development; Since end of 2004)

2 Pure Javascript: Infrastructural Frameworks

  • 2.1 AjaxCaller (Alpha; from May 2005)
  • 2.2 Flash JavaScript Integration Kit ()
  • 2.3 Google AJAXSLT (Released June 2005)
  • 2.4 HTMLHttpRequest (Beta; from 2005)
  • 2.5 Interactive Website Framework (from May 2005)
  • 2.6 LibXMLHttpRequest (Released; June 2003)
  • 2.7 MAJAX (Released; August 2005)
  • 2.8 RSLite (x)
  • 2.9 Sack (In development; from May 2005)
  • 2.10 Sarissa (Released; from February, 2003)
  • 2.11 XHConn (Released; from April, 2005)

3 Server-Side: Multi-Language

  • 3.1 Cross-Platform Asynchronous INterface Toolkit (May 2005)
  • 3.2 SAJAX (Workable but not 1.0; from ?March 2005)
  • 3.3 Javascipt Object Notation (JSON) and JSON-RPC
  • 3.4 Javascript Remote Scripting (JSRS) (from 2000)
  • 3.5 Bitkraft for ASP.NET

4 Server-Side: Python

  • 4.1 CrackAJAX

5 Server-Side: Java

  • 5.1 WebORB for Java (from August 2005)
  • 5.2 Echo 2 (from March 2005)
  • 5.3 WidgetServer (2004)
  • 5.4 Direct Web Remoting (DWR) (2005)
  • 5.5 SWATO (2005)
  • 5.6 AJAX JSP Tag Library
  • 5.7 AJAX Java Server Faces Framework
  • 5.8 ThinkCAP JX: RAD Environment for AJAX, J2EE, and Open Source (Commercial Framework)
  • 5.9 Struts-Layout

6 Server-Side: Lisp

  • 6.1 CL-Ajax

7 Server-Side: .NET

  • 7.1 MonoRail (from May 2005)
  • 7.2 WebORB for .NET (from August 2005)
  • 7.3 Ajax.NET (from March 2005)
  • 7.4 ComfortASP.NET (from August2005)
  • 7.5 AjaxAspects (from August 2005)

8 Server-Side: Perl

  • 8.1 CGI::Ajax – Export perl methods to javascript for AJAX

9 Server-Side: PHP

  • 9.1 AjaxAC (From April, 2005)
  • 9.2 JPSpan
  • 9.3 XAJAX
  • 9.4 PEAR::HTML::Ajax
  • 9.5 CPAINT

10 Server-Side: Ruby

  • 10.1 Ruby On Rails