Software Reality

Book Review: jQuery Pocket Reference

jQuery Pocket Reference
by David Flanagan
O'Reilly Media
Published: December 28, 2010  

Buy at: Amazon.com   Amazon.co.uk  

Concise but information-rich: an introduction rather than a reference book.

jQuery is popular with good reason: it really does simplify the way you write JavaScript. I'm all for the "less is more" approach (as my own book on smarter unit testing will confirm): less code usually means more maintainable code - as long as the code's intent is still clear, of course.

It seems fitting that for a lightweight library like jQuery, there should be a lightweight manual perched next to your keyboard. And jQuery Pocket Reference does the job perfectly. Its author David Flanagan (of the Java In A Nutshell fame) does a remarkable job of distilling the details into the book's 130 or so pages, while keeping the whole thing readable.

And the paperback's diminutive size has some unseen benefits...

Acceptance Testing - Expanding Use Cases using Structured Scenarios

Chapter 7 of Design Driven Testing just went onto the Sparx Community website as a free download. (Sparx are the creators of Enterprise Architect, nowadays the *only* real choice for enterprise analysis and design modeling).

Somewhat uniquely, the book features a real production system as its teaching example. A worldwide interactive hotel mapping (GIS) application, designed with the ICONIX Process, built using Java, Flex, and the ESRI ArcGIS Server mapping software, that we call "Mapplet 2.0", which is in production use on the VResorts.com travel website.

Here's how the chapter is introduced on the Sparx site:

This chapter focuses on Acceptance Testing, and leverages EA's Structured Scenario editor heavily to accomplish something we call "use case thread expansion" where all of the sunny day / rainy day permutations of a use case are expanded out into a complete set of tests.

In test driven approaches to development, unit testing often gets most of the attention.  However, unit testing is generally most useful in discovering "errors of Commission" (more poetically, "whoops, I coded that wrong").  Unit testing is of much less help in discovering "errors of Omission" (more poetically, "whoops, I didn't think of that").  In general errors of Omission are much trickier to detect, and there is very little automated support for detecting them.  We worked very closely with the development team at Sparx as they developed the "use case thread expander", and it brings a very unique and useful capability to the industry.

As you read this chapter, make sure you don't miss the discussion at the end of the chapter called "And the moral of the story is..." where we describe some actual "errors of Omission" that were caught and fixed before the release of our mapping software using these acceptance testing techniques, and how fixing these errors improved the user experience.

Here's the book excerpt over at Sparx.

In case you're still undecided about whether to buy a copy of DDT (or like me, if you just like reading free chapters!), Chapter 4 is also available for download. This chapter presents the full ICONIX Process design of the Mapplet project, starting from functional requirements and use cases, all the way down to reverse engineered class diagrams from the final code.   One of the unique virtues of using a production example as a teaching example in a book like DDT is that it's possible for readers to look at the use cases in the attached chapter, and then compare them to the released software as deployed on VResorts.com.

Behind the Kindle, under the iPad: an unholy alliance

Here's my latest at The Register - some thoughts based on my recent trip to the Frankfurt Book Fair:

If some of the speakers at this year's Frankfurt Book Fair are to be believed, your life — or at least the part of it that involves snuggling up in bed with a good book and mug of hot cocoa — is about to be turned upside down.

Sure, we've heard plenty on books going electronic, but the coverage mostly focuses on the devices — Kindles, iPads, et al. — rather than the books themselves.

I've written a number of books on software development, and recently began my own publishing company, Fingerpress. I therefore approached this event from the perspective of an upstart book publisher trying to figure out how our published works should fit into the e-publishing space.

I expected the answer to be a bewildering mix of grey areas, but surprisingly — despite the diversity on offer — the answer turned out to be quite clear-cut.

Der Frankfurter Buchmesse 2010's crowded halls feature several so-called technology Hot Spots. The Devices Hot Spot is oddly named because it isn't about devices. Instead it features advances in content creation and delivery — that murky zone in between the device and the customer. One company inhabiting this area is exhibitor Stilo, which specialize in converting content into XML and EPUB formats. Smashwords, which wasn't at the show, converts to a much broader range of platforms for free — provided you use their distribution service, of course.

The Mobile Hot Spot was exactly that, while the Information Management Hot Spot supposedly bought together "the latest developments in workflow processes, content management systems, multimedia integration and advanced content delivery platforms."

There were also Hot Spots for publishing services, literature, special interest (top shelf, sir?), and education.

The predominant message behind almost all of the tech exhibitors at each Hot Spot was this: e-books are here, they're cool, and we should all be using them. Whether that's actually true or not is a different matter.

. . .

The problem is that books — novels especially — are entrenched in our habits and expectations. People love a good novel, and that's unlikely to change. They don't want the formula to be messed with too much. And as for fragmentation? It's always been easier to print a leaflet than a novel, but novels still sell by the million, whereas "short-shorts" don't.

What is changing, and rapidly, is the way that books are delivered to us, along with the medium the words are displayed on. From the Apple iBookstore to Kindle to Kobo, it's never been easier to buy a book and be reading it a few seconds later. And while the device is where the excitement is, the real war is to potentially own the e-publishing "middle tier" — the site that readers go to in order to buy their books.

>> Read the full article at The Register.

Click the Install button

Oh boy, this sort of thing really fills me with confidence:

Even better though, there's no Cancel button (aka "Just Say No")... It's like the worst kind of software registration dialog:

"Please may we spam you with daily special offers and sell your details on to a slavering army of evil third-parties, some of whom have wings and fangs?
Yes | Remind me again in 30 days"

Code Bubbles and Porky Visual Studio

Here's my latest article at The Register:

The latest incarnation of Visual Studio had a difficult gestation, with critics pointing to the slowness and instability of the beta release...

... This isn't just a criticism leveled solely at Visual Studio; it's against all the modern IDEs out there - VS in day-to-day use is not so different from what we were doing with the first version of Visual Basic 19 years ago. Somehow, Microsoft managed to fatten Visual Studio up to porcine levels and yet using the product feels like you're trapped in the 1990s.

Java IDEs suffer from the same problem, to an extent. IDE evolution has become a game of feature creep, each new release touting bold new features, drawing in concepts well outside an IDE's core competency - half-baked UML support springs to mind - and packing it all into a single frame. The notion of "doing one thing, and doing it well" has been laughed out the window.

And the reason for this stagnation of innovation in the IDE space? The industry leaders have become portly, comfortable, and middle-aged. Eclipse is smoking its logical representation of a pipe, content to let plug-in developers pad out its ecosystem. NetBeans plays perpetual catch-up while its fate is decided for it. IntelliJ no longer sells itself on productivity, having fallen into the "feature checklist" trap.

The time is ripe for a brand-new contender to stroll in with something fresh and steal developer mindshare from beneath the leaders' pipe-yellowed moustaches - just as a young Eclipse once did to NetBeans.

The bubblicious Code Bubbles IDE could be just that new contender. It puts a leash around Eclipse to do the donkey work for it, but invents an entirely new front-end so that programming becomes more like playing with Matey in the bath. A prototype from Brown University in New England and video about Code Bubbles has passed the frothy developer test, with viral emails flying around the workplace.

>> Read more at The Register

User Story != Use Case - but User Story != Story, Either

A user story is not a use case.

That might seem as obvious as saying "A door is not a cat", but there's enough scope for confusion - not just in the similar names - that user stories and use cases are often used interchangeably (when describing what to do next in a software project) when they probably shouldn't be.

Alistair Cockburn sums it up nicely: A user story is to a use case as a gazelle is to a gazebo.

But also:

A user story is not a story.

In other words - this is not a user story:

"The user types in a story and clicks Submit. The system publishes it to the website so that other users can read it."

It's really a use case. But it also doesn't help that there are many definitions of "use case", and many opinions on how much detail should go into one. But generally, the one consistent aspect of a use case is that it's a narrative: a description of a user's journey through the UI, and the system's responses as he clicks and types his way along: "The user does this or that; the system displays XYZ data in response. Next, the user does this... etc." In other words, the text of a use case is really a story.

A user story, meanwhile, is anything but a narrative. And this, I think, is the main source of the confusion. The name "user story" implies a story - a narrative. And it really doesn't help matters that the name is often shortened to "story". But a user story is anything but a story - at least in the narrative sense. I could see people starting to call narrative-based requirements "stories", but it's a false etymology, as they say.

Oracle should cannibalize JavaFX Frankenstein

My latest article at The Register:

The biggest coup for JavaFX three years after its unveiling at JavaOne is its integration into Vancouver2010.com, in a spinning-wheel app that shows countries' medal counts dating back to 1924. It's a nice use of data visualisation, a cross between tag clouds and a time-traveling version of Risk. But oh my word, the jaggedness of the text. Don't these people know that Java can do antialiasing very nicely? Even the "Powered by JavaFX" logo has embarrassing color bleed.

The Winter Olympics app is a rare moment of fame for JavaFX, in an otherwise bleak and underperforming history. The brazenness of JavaFX.com suggests otherwise. It's all flashing lights and bold headlines, as if the marketing team are standing around Frankenstein's [monster's] corpse sending shockwaves of electricity into it and insisting: "Look! Look! It lives! No, really, it does!"

Read more...

What I like most about Google's Chrome is...

... Firefox can be made to look just like it.

Let’s face it, we’re all shallower than we like to admit when it comes to our web browsing experience. The web itself is mostly words and pictures painted across a million miles of surface gloss. Of anyone who tried the beta of Google’s Chrome browser, I bet you all initially rushed to install it because of the concept of each tab running in an isolated sandbox, and the prospect of V8, the powerful new JavaScript engine... but what really wowed you about Chrome when it revved onto your screen? Yep, its cool streamlined appearance. Don’t know about you, but that more than anything tempted me to switch from Firefox and make Google’s stealthy new beast my main browser.

The isolated processes stuff sounds important, but it solves a problem I didn’t know I had (aside from Firefox eating up resources and needing the occasional restart). And the other touted big advantage of Chrome, its faster JavaScript engine, may already have been left in the dust by Firefox's in-the-pipeline TraceMonkey engine. So for all the hype and excitement (which has admittedly died down considerably now) around Google’s new browser, what’s the main attraction of Chrome? Its looks.

Continuing the JavaFX Theme...

Over at The Register:

Sun Microsystems recently released the JavaFX Preview SDK. I decided to revisit what is Sun's last, best hope to recapture both the desktop and the browser in the face of stiff competition.

The big question with Java FX is why anyone would want to adopt it when they've already got Adobe Systems' Flex and Microsoft's Silverlight, which is doing rather well in presenting the Beijing Olympics.

On paper, the most compelling feature could be the most difficult one for Sun to pull off: the ability to run the same JavaFX app unaltered on both Java Standard Edition (Java SE) and Java Micro Edition (Java ME) runtimes.

The Laszlo factor

To achieve this, Sun is taking a Laszlo-like approach - Laszlo allows the same program to run in the browser using a JavaScript base or a Flash base. The Java SE runtime renders using Swing components, for example. It would truly be a top achievement from Sun if the same JavaFX program could run unaltered on your mobile phone and desktop.

Whether this pseudo-multi-platform approach turns out to be practical in the long run is another matter. Any program of a significant size is bound to step outside the rosy JavaFX garden and make use of the "core" Swing and Java APIs, shackling it to your desktop. We won't find out to what extent Sun can achieve their lofty ambition until Java ME support appears, which at the last estimate is Spring 2009.

Full article at The Register...

Sun's JavaFX must tool up against Adobe - pronto

Here's part two of my look at the Rich Internet Application world that JavaFX is being breach-birthed into:

Sun Microsystems lost the first Rich Internet Application (RIA) war when Macromedia (now part of Adobe) ate its applets for lunch following a schoolyard brawl. Now Sun has a second chance.

But, to succeed in such an unforgiving market, Sun needs something special. A mature, powerful platform, a buzzing community, some seriously talented people with an eye for visual design, and some butt-kicking WYSIWYG tools so that non-programmers are invited to the party as well.

JavaFX ticks some of these boxes, and it has tools on the way. These tools, though, are going to make or break its chances. And they're a little late, to be honest. Spring 2008 was mentioned for the visual development environment. Spring has given way to glorious summer.

[...] If Sun's goal is to compete with Adobe's Flash or Silverlight from Microsoft, then a Matisse-based visual editor should have been one of the first toys to be pulled out of the box. It should be right at the center of the rich client development experience rather than a "potential add-on some time", leaving third-party vendors to pick up the slack. [...]

Read the full article at The Register...