Only in Canada …

Every year, York University personnel assist a gaggle of geese in making the passage from a quad to the outside world. This year’s passage has been captured and is available for viewing at YouTube:

Enjoy!

Synced-Data Applications: The Bastard Child of Convergence

At the Search Engine Strategies Conference in August 2006, in an informal conversation, Google CEO Eric Schmidt stated:

What’s interesting [now] is that there is an emergent new model, and you all are here because you are part of that new model. I don’t think people have really understood how big this opportunity really is. It starts with the premise that the data services and architecture should be on servers. We call it cloud computing – they should be in a “cloud” somewhere. And that if you have the right kind of browser or the right kind of access, it doesn’t matter whether you have a PC or a Mac or a mobile phone or a BlackBerry or what have you – or new devices still to be developed – you can get access to the cloud. There are a number of companies that have benefited from that. Obviously, Google, Yahoo!, eBay, Amazon come to mind. The computation and the data and so forth are in the servers.

My interpretation of cloud computing is summarized in the following figure.

Yesterday, I introduced the concept of Synced-Data Applications (SDAs). SDAs are summarized in the following figure.

SDAs owe their existence to the convergence of the cloud and the desktop/handheld.

Synced-Data Applications: The Future of End-User Software?

I recently asked: Is desktop software is dead?

Increasingly, I am of the opinion that desktop software is well on its way to extinction.

In its place, Synced-Data Applications (SDAs) have emerged.

One of the best examples I’ve recently run across is Evernote. Native Evernote applications exist for desktops (as well as handhelds) and for the cloud (e.g., via a Web browser). Your data is replicated between the cloud (in this example, Evernote’s Webstores) and your desktop(s)/handheld(s). Synced-Data Applications.

And with Google Gears, Google Docs has also entered the SDA software paradigm.

With SDAs, it’s not just about the cloud, and it’s not just about the desktop/handheld. It’s all about the convergence that this software paradigm brings.

A revised version of the figure I shared in the previous post on this thread is included below.

Once again, it emphasizes that interest is focused on the convergence between the isolated realm of the desktop/handheld on the one hand, and the cloud (I previously referred to this as the network) on the other.

It’s much, much less about commercial versus Open Source software. And yes, I remain unaware of SDA examples that live purely in the Open Source realm …

Is Desktop Software Dead?

When was the last time you were impressed by desktop software?

Really impressed?

After seeing (in chronological order) Steve Jobs, Al Gore and Tim Bray make use of Apple Keynote, I absolutely had to give it a try. And impressed I was – and to some extent, still am. For me, this revelation happened about a year ago. I cannot recall the previous instance – i.e., the time I was truly impressed by desktop software.

Although I may be premature, I can’t help but ask: Is desktop software dead?

A few data points:

• Wikipedia states: “There is no page titled “desktop software”.” What?! I suppose you could argue I’m hedging my bets by choosing an obscure phrase (not!), but seriously, it is remarkable that there is no Wikipedia entry for “desktop software”!
• Microsoft, easily the leading purveyor of desktop software, is apparently in trouble. Although Gartner’s recent observations target Microsoft Windows Vista, this indirectly spells trouble for all Windows applications as they rely heavily on the platform provided by Vista.
• There’s an innovation’s hiatus. And that’s diplomatically generous! Who really cares about the feature/functionality improvements in, e.g., Microsoft Office? When was the last time a whole new desktop software category appeared? Even in the Apple Keynote example I shared above, I was impressed by Apple’s spin on presentation software. Although Keynote required me to unlearn habits developed through years of use Microsoft PowerPoint, I was under no delusions of having entered some new genre of desktop software.
• Thin is in! The bloatware that is modern desktop software is crumbling under its own weight. It must be nothing short of embarrassing to see this proven on a daily basis by the likes of Google Docs. Hardware vendors must be crying in their beers as well, as for years consumers have been forced to upgrade their desktops to accommodate the latest revs of their favorite desktop OS and apps. And of course, this became a negatively reinforcing cycle, as the hardware upgrades masked the inefficiencies inherent in the bloated desktop software. Thin is in! And thin, these days, doesn’t necessarily translate to a penalty in performance.
• Desktop software is reaching out to the network. Despite efforts like Microsoft Office Online, the lacklustre results speak for themselves. It’s 2008, and Microsoft is still playing catch up with upstarts like Google. Even desktop software behemoth Adobe has shown better signs of getting it (network-wise) with recent entres such as Adobe Air. (And of course, with the arrival of Google Gears, providers of networked software are reaching out to the desktop.)

The figure below attempts to graphically represent some of the data points I’ve ranted about above.

In addition to providing a summary, the figure suggests:

• An opportunity for networked, Open Source software. AFAIK, that upper-right quadrant is completely open. I haven’t done an exhaustive search, so any input would be appreciated.
• A new battle ground. Going forward, the battle will be less about commercial versus Open Source software. The battle will be more about desktop versus networked software.

So: Is desktop software dead?

Feel free to chime in!

To Do for Microsoft: Create a Wikipedia entry for “desktop software”.

Book Review: Google Web Toolkit

Automagically convert Java to JavaScript. 

Thus begins the seemingly curious proposition of the Google Web Toolkit (GWT). 

Of course, it’s about a lot more than that. 

For one thing, GWT addresses a key gap in the rapid delivery of the Asynchronous JavaScript and XML (AJAX) based applications that are driving eyeballs and mindshare to Google’s Web site.

By the time you’ve read Prabhakar Chaganti’s book on the GWT, you’ll be significantly wiser on at least two fronts. You’ll know that:

1. There’s a broad-and-deep software engineering ecosystem around the GWT that is fueling progress and delivering highly significant results. 
2. Chaganti is an excellent guide with the ability to negotiate this ecosystem and drive you towards tangible outcomes.

Using a task-oriented approach, the book proceeds as follows:

• Chapter 1 rapidly places the GWT in context, and gets you started by downloading, installing and working with the samples provided. Available for Apple Mac OS X, Linux and Microsoft Windows, the GWT only requires the Java SDK as an installation prerequisite. The GWT is made available via the Apache Open Source license; this allows for the development of commercial and Open Source applications. 
• With the Java SDK, the GWT and the Eclipse IDE, the developer has a well-integrated and powerful platform on which to develop applications. After illustrating the development of the obligatory “Hello World!” application at the outset of Chapter 2, attention shifts rapidly to use of Eclipse. Google’s Web-wired DNA is evident in everything they do, and the GWT is no exception. The GWT leverages the Java SDK and Eclipse to the fullest, while closing the gaps in developing AJAX-based applications in a very organized way. By the end of this Chapter, the reader knows how to develop a simple application with both client and server-side components and execute the same in both hosted (i.e., non-deployed) and Web hosted (i.e., executing within a Web-hosted Tomcat servlet container). Made explicit in this latter deployment is GWT’s ability to support a variety of Web browsers – i.e., Apple Safari, Microsoft Internet Explorer, Mozilla Firefox and Opera.
• The creation of services is the focus of Chapter 3. To quote from this Chapter, and in the GWT context, service “… refers to the code that the client invokes on the server side in order to access the functionality provided by the server.” The author is quick to point out that this is a separate and distinct notion from that used in the context of Web services. True to its billing, this Chapter works the reader through the creation of a service definition interface (a client/server contract that defines the service’s functionality and establishes rules of usage) and service implementation. Particularly important in this Chapter is the creation of an asynchronous service definition interface, as this facilitates remote calls in the background to the server, and capitalizes on the AJAX support in the GWT. With definition and implementation taken care of, the remainder of the chapter focuses on use (i.e., consumption of the service by a client). Conceptual illustrations compliment screenshots to effectively convey this content. 
• Whereas the previous chapter delivered a prime number service, Chapter 4 introduces no less than six services that really showcase the capabilities of this application paradigm. With ample explanation and illustration live searches, password strength checks, auto form fills, sorting tables, dynamically generated lists and Flickr-style editable labels are each considered. Not only does one recognize these as design patterns that are already in everyday use (e.g., Flickr, Google Docs, Maps and Search, etc.), one also realizes their potential for re-use in one’s own projects. 
• Chapter 5 introduces five interfaces that are more complex than those presented in the previous chapter. These interfaces are pageable tables, editable tree nodes, log spy (the GWT spin on the UNIX tail utility), sticky notes and jigsaw puzzle. To reiterate, one recognizes these as design patterns already in everyday use, and the potential for re-usability.
• Browser effects are the subject of Chapter 6. Here the author introduces the JavaScript Native Interface (JSNI) as a vehicle that allows JavaScript libraries (e.g., Moo.Fx and Rico) to be accessed directly from Java classes. A wrapper-based approach, independent of JSNI, is also introduced to leverage the Script.aculo.us effects. Although compelling effects can be achieved, cautionary words are included in this Chapter, as the impact may be diminished by browser-level incompatibilities.
• By the end of Chapter 7, impressive calendar and weather widgets have been created, and readied for re-use. 
• In Chapter 8, JUnit is introduced in the context of unit testing. Standalone tests plus test suites are given consideration; this includes tests involving asynchronous services.  
• Although this is only the second book I’ve ever seen from Packt Publishing (the first I’ve reviewed elsewhere), I’ve become accustomed to expecting bonus content towards the end of the book. Chapter 9, which addresses internationalization and XML support, falls into this bonus category. Of course, it’s no surprise that Google expertise on internationalizations ranks high, and this is evident in GWT support for the same. The author provides an hors d’oeuvre of the possibilities. XML support is of particular personal interest, so I was delighted by the degree of support for creating and parsing XML documents. I share the author’s sentiments with respect to XML support wholeheartedly: I too hope that future releases of the GWT will provide broader and deeper support for XML.  
• In the final chapter (Chapter 10), attention is given to increasingly automated methods for deploying GWT-based applications. Starting with a manual deployment in Tomcat, then an automated deployment with Ant, and finally an Ant-based deployment from within Eclipse. 
• A single appendix details how to access and execute the examples provided throughout the book.

With the possible exception of a concluding chapter, page, paragraph or even sentence(!), to provide some sense of closure to the book, I am at a loss to report any omissions, oversights or errors of any consequence. And although it will have to wait for a follow-on contribution of some kind, additional discussion might be given to topics such as Google Gears or even Google Android.

Even though the book I reviewed was a complimentary copy provided by the publisher, I would happily pay for my own copy, and heartily recommend this book to others having interests in the GWT. 

By the way, Packt has an articulated scheme when it comes to Open Source projects:

Packt Open Source Project Royalty Scheme Packt believes in Open Source. When we sell a book written on an Open Source project, we pay a royalty directly to that project. As a result of purchasing one of our Open Source books, Packt will have given some of the money received to the Open Source project.In the long term, we see ourselves and yourselves, as customers and readers of our books, as part of the Open Source ecosystem, providing sustainable revenue for the projects we publish on. Our aim at Packt is to establish publishing royalties as an essential part of the service and support business model that sustains Open Source. 

I cannot suggest that Packt is unique in this approach. Regardless, their approach is certainly welcome.

DICtabrain: “Voice Powered Ideas”

In a recent post, I blogged:

… Jott goes a lot farther than my low-tech solution:

• You call their toll-free number
• You leave a message – your reminder, to-do, idea, etc.
• Jott transcribes your message, and delivers the corresponding text to your phone and email

“Obscenely simple … incredibly clever” (Christopher Null, Yahoo! Tech). I couldn’t agree more!

Unfortunately, I cannot attest to how well this actually works.

I live in Canada, and the public beta only supports US-based cell phones

Fortunately, there’s great news for us Canucks as DICtabrain is developing a similar solution

Although I expect to have more to blog about soon, it’s worth noting that DICtabrain:

• Makes an explicit connection to blogging
• Is looking for alpha-trial participants
• Has their own blog

Some may be nonplussed by services like DICtabrain’s or Jott’s.

As DICtabrain’s James Woods blogs:

Some people will never understand the benefits of voice powered writing while others seem to be waiting for it with baited breath.

I think the reason for this disconnect is the creative process itself.

Some people need to internalize their creative process by working things through inside their heads.

Others need to externalize it. And its for the externalizers that frameworks like GTD and solutions like DICtabrain’s make complete and total sense. In DICtabrain’s words: “Good ideas are only valuable if they can be remember[ed] and then actioned.“

With Jott and DICtabrain appearing on the scene with similar solutions within the past 3-4 months, it’s clear that there’s something interesting happening.

Perhaps Jott and DICtabrain have glommed onto a disruptive innovation.

What are they disrupting?

How about the dictaphone + analog/digital voice recorders + voicemail + technology for action management methods.

Collectively!

That’s an impressive disruption, and one of the reasons why companies like DICtabrain and Jott are likely to draw attention from the likes of:

• Traditional dictaphone companies – ??
• Consumer electronics companies – Apple, Sony, etc.
• Telcos/Networking companies – Cisco, Nortel, Skype, etc.
• Software companies – Google, Microsoft, Nuance, etc.
• And others

With unified messaging a key deliverable of enterprise-class traditional PBX and VoIP solutions, injecting the DICtabrain or Jott solution into the mix could be quite interesting. For example when you have robust IP connectivity, you have the networked equivalent of Nuance’s Dragon NaturallySpeaking in Skype + (DICtabrain or Jott) … and potentially more!

To re-quote Christopher Null, Yahoo! Tech: “Obscenely simple … incredibly clever”.

Let me close (again) with a small dose of realism:

I haven’t been particularly impressed by speech-to-text conversion in the past. This will be the gating factor for me.

The Top Ten Reasons You’ll Want GMail on Your Blackberry

I’ve blogged a lot about the GMail client for the Blackberry over the past few weeks.

There’s been enough interest to warrant a Top Ten list – something along the lines of “The Top Ten Reasons You’ll Want GMail on Your Blackberry”.

Before I release my Top Ten, I thought I’d consult the collective wisdom of those who happen by my blog.

Please share a comment to this post, or drop me an email (ian DOT lumb AT gmail DOT com), and let me know what you think should be on this Top Ten list.

I’ll summarize and share in about a week.

With thanks in advance.

Google Office for the Blackberry: Coming Soon?

In a recent post, I blogged:

Now picture this: A J2ME client application for Google Docs & Spreadsheets.

This is interesting on a number of levels:

• It’s feasible! Google Docs & Spreadsheets is likely written in
  some variant of Java (J2*E) already, so paring it down to J2ME is (in
  principle) possible.

Alas, Google Docs & Spreadsheets (GD&S) isn’t based on some variant of J2*E.

It’s based on JavaScript. To see this, open a document or spreadsheet in GD&S and then look at the document source (“View \ Page Source” in Firefox) and/or the DOM (“Tools DOM Inspector” in Firefox). Or, try to open a document or spreadsheet in GD&S on your Blackberry. You’ll soon find out about the dependence on JavaScript.

More precisely, GD&S is based on AJAX (Asynchronous JavaScript + XML). AJAX is behind the wonderful user experience afforded by most of Google’s offerings. (There’s an outstanding explanation of how AJAX achieves this experience available from Adaptive Path president and founder J. J. Garrett .) AJAX is a multi-tier platform or framework for developing and delivering Web-centric applications. (And many refer to it in the same breath as Web Services.)

In striking contrast, the GMail client for the Blackberry is a stand-alone Java application that executes within a J2ME container under the Blackberry operating environment.

Clearly AJAX and J2ME are completely different environments/platforms.

Thus it would seem that Google has the options summarized by a two-dimensional platform versus motivity grid.

On the vertical axis, platform ranges from self-contained to service-oriented.

Motivity is a bona fide word that is synonymous with locomotion (the power or ability to move). I intend here to coin a slightly different meaning, a juxtaposition of mobility and connectivity. More precisely, I propose to use motivity as a semi-quantitative measure of the degree of mobility relative to the degree of connectivity. As mobility increases, connectivity decreases, and motivity therefore increases. This is illustrated by the horizontal axis of the two-dimensional grid. It is also important to note that connectivity is itself a proxy for bandwidth and latency. More precisely, high connectivity is taken to imply high bandwidth, low latency connectivity.

Thus the options in taking GD&S to the Blackberry are:

• Port GD&S to the Blackberry operating environment (i.e., develop a native J2ME client version of GD&S) – the lower-right quadrant of the 2D-grid

or

• Port the client-side aspects of AJAX to the Blackberry operating environment (JavaScript and the AJAX engine) and interface this in real time with the server-side components – the upper-right quadrant of the 2D-grid

There is one other possibility that originates in the lower-left quadrant. GD&S could be written as a Java application. A pared down version could be relatively easily be made available for the J2ME-based Blackberry operating environment. (This was my naive suggestion that’s been revisited in this post.) In parallel, through use of the Google Web Toolkit (GWT), the same Java version of GD&S could be converted to AJAX as “… the GWT compiler converts your Java classes to browser-compliant JavaScript and HTML.”

Thus a revised two-dimensional grid of the possibilities is shown below.

Either way, it may be some time before Google Docs & Spreadsheets makes it to the Blackberry.

Google Apps for Lakehead University

According to IT Business, Lakehead University is the first Canadian institution to migrate to Google Apps for Education (GAFE). At 38,000 strong, Lakehead’s deployment is of similar size to that of Arizona State’s.

If GAFE experiences significant adoption, one wonders what might follow. For example, might Google acquire an online learning environment like Moodle or Sakai?

And of course in the bigger scheme of things, this is another interesting competitive volley directed at Microsoft, as Google continues to build online communities and garner mindshare.

Licensing Commercial Software for Grids: A New Usage Paradigm is Required

In the Business section of last Wednesday’s Toronto Star, energy reporter Tyler Hamilton penned a column on power-based billing by datacenter services provider Q9 Networks Inc. Rather than bill for space, Q9 chief executive officer Osama Arafat is quoted in Hamilton’s article stating:

… when customers buy co-location from us, they now buy a certain number of volt-amps, which is a certain amount of peak power. We treat power like space. It’s reserved for the customer.

Power-based billing represents a paradigm shift in quantifying usage for Q9.

Along with an entirely new business model, this shift represents a calculated, proactive response to market realities; to quote Osama from Hamilton’s article again:

Manufacturers started making the equipment smaller and smaller. Customers started telling data centre providers like us that they wanted to consolidate equipment in 10 cabinets into one.

The licensing of commercial software is desparately in need of an analogous overhaul.

Even if attention is restricted to the relatively simple case of the isolated desktop, multicore CPUs and/or virtualized environments are causing commercial software vendors to revisit their licensing models. If the desktop is networked in any sense, the need to recontextualize licensing is heightened.

Commercial software vendors have experimented with licensing locality in:

• Time – Limiting licenses on the basis of time, e.g., allowing usage for a finite period of time with a temporary or subscription-based license, or time-insensitive usage in the case of a permanent license
• Place – Limiting licensing on the basis of place, e.g., tieing usage to hardware on the basis of a unique host identifier

Although commercial software vendors have attempted to be responsive to market realities, there have been only incremental modifications to the existing licensing models. Add to this the increased requirements emerging from areas such as Grid Computing, as virtual organizations necessarily transect geographic and/or organizational boundaries, and it becomes very clear that a new usage paradigm is required.

With respect to the licensing of their commercial software, the situation is not unlike Q9’s prior to the development of power-based billing. What’s appealing about Q9’s new way of quantifying usage is its simplicity and, of course, its usefulness.

It’s difficult, however, to conceive such a simple yet effective analog in the case of licensing commercial software. Perhaps this is where the Open Grid Forum (OGF) could play a facilitative role in developing a standardized licensing framework. To move swiftly towards tangible outcomes, however, the initial emphasis needs to focus on a new way of quantifying the usage of commercial software that is not tailored to idealized and/or specific environments.