Friday, January 29, 2010


I have to admit to rarely having been very prescient about new technologies. I understand technology very well, but when it comes to predicting what will take off and what won’t, I’m often off the mark.

Some examples:

  • I never thought Facebook would take off the way that it did. I figured it would be very popular for a while, and then everyone would move onto something else, as they did with MySpace and the various other social networking sites that had come before it. But the Facebook API (among other things) proved me wrong, and, despite my predictions, it’s still quite popular.
  • I underestimated how popular the iPhone would be, and then overestimated how popular the Palm Pre would be. In a radius of twenty feet from where I’m currently sitting at work there are probably a dozen iPhones, but not a single Pre. (Despite the fact that the Pre keeps winning awards for being so darned great.)
  • I was initially right about the Y2K bug, but then gave in to the hype and became as wrong as everyone else. When people first started talking about the Y2K problem, I said, well, it’s no big deal; maybe some reports will be wrong, and say 1900 instead of 2000, but other than that, problems will be extremely rare. If I’d stuck with that, I could have claimed I was prescient, but eventually all of the people who claimed that the sky was going to fall got to me, and I started to think it might actually be a big problem—only to have the clock turn over at 2000, and nothing happened, as I’d originally predicted.
  • I’ve written before (I think) about the fact that I never really cared when Google was launched. Big deal, another search engine, who cares; I already have my hierarchical list of sites on Yahoo!, what do I need another search engine for? Here we are today, and Google is so useful that many if not most people use it for their default page when they load their browser.
These are some examples; there are others. And here are two more.

I’ve already written about Google Wave, and how I think it has the potential to be a paradigm-shifting technology, which might, in time, replace email. (And IM. And documents—but now I’m really dreaming.) And I’d like to be right about it—if only so that I could claim I was prescient—but everyone else seems kind of underwhelmed by it. (Someone described it to me recently as “a solution in search of a problem”—I’m not of that opinion, obviously, but I can definitely understand the sentiment.) There’s still time, don’t get me wrong. I haven’t lost hope in it. But I would feel better if others were sharing my enthusiasm, and as of yet, they’re not.

Then, yesterday, Apple launched the iPad, which is a tablet-sized device, kind of like a big iPhone. And I’m seeing a lot of hype about it, but I’m thinking… so what? It’s a tablet. Big deal. It’s an iPhone, but bigger. (Or, if you get the version without 3G, it’s an iPod Touch, but bigger.) There have been tablets before, and none of them have ever taken off, because people don’t seem to want to use their computers like that. In fact, I remember when I first heard about Tablet PC from Microsoft, and, in another case of non-prescience, was very excited, assuming that it would be the next big thing. Here we are a few years later; have you ever met anyone who had a Tablet PC? I haven’t. I just did a Google search for “Microsoft Tablet PC”, and on the first page of results, the only pages on Microsoft’s site were one in Taiwanese, and one from Microsoft Support, so it’s not exactly a feature that Microsoft is pushing hard. So I’m not seeing the big deal about the iPad, but who knows? Maybe Apple will have implemented it in such a way that people really will find it useful. But at this point, I’m thinking that I’d rather be using a netbook than an iPad.

I should mention that some people have similar feelings about “netbooks.” Who would ever want a netbook, they ask; why not use a laptop, if you want a laptop, or your phone, if you want portability? I don’t agree with them on that; I think that netbooks actually are a good idea, for a lot of situations (and am kind of excited about Google Chrome OS). I think there’s a good market for an in between device, that’s more comfortable than a phone, but just for browsing the web and checking email, therefore not requiring the power (or cost) of a real laptop. (I wasn’t prescient or non-prescient about netbooks; by the time I’d even given them any thought, they were already very popular.)

So I’m thinking that Google Wave is going to be revolutionary, but, based on my history of trying to predict the future, am probably wrong. And I’m thinking that the iPad is no big deal, but for the same reasons, am probably wrong.

Friday, January 15, 2010

Google Web Tools

A while ago I had a post in my Beautiful Code series, on Computer Generated Code. There, I was referring to things like the C pre-processor, which runs through a source code file and generates additional source code, which is finally sent to the compiler. Or, in more extreme cases, using another tool altogether, like awk, to do the same thing, but with potentially a lot more flexibility (with the power of regular expressions at hand). These days Java programmers are doing something similar with Annotations. The article also mentioned code that generates further, optimized code.

Last Fall, I came across a variation on this, in the form of the Google Web Toolkit (GWT), which is a set of tools created by Google for creating rich HTML-based applications, specifically ones that make use of JavaScript and AJAX and JSON to do complex things in the browser.

One of the disadvantages to using a scripting language like JavaScript for development is that it is not a “strongly typed” language, and neither is it compiled, so some development errors will not be discovered until the testing phase. With a compiled, strongly-typed language (such as C++ or Java), some errors can be caught at compile time and fixed quickly, which reduces the number of bugs to be discovered during the testing phase. Another issue is that things often work slightly differently from browser to browser, so often you find yourself building JavaScript code that does things like, “if Firefox do this, but if Internet Explorer version 6, do that, but if IE7 do the other…”

GWT tries to combine the benefits of using a strongly-typed language—in this case Java—with the aforementioned benefits of improved user interface via AJAX. In a GWT application, code is written in Java, and UI is built using a GWT library, very much in the same way that a Java Swing application would be built. Once the application has been built and tested, it is “compiled” into JavaScript, with versions optimized for various browsers. In other words, a version is produced that will be optimized for IE6, and another version for IE7, and another for Google Chrome, and another for Firefox, etc. When the user accesses your application, the GWT JavaScript runtime figures out what browser you’re using, and downloads the correct code (and only the correct code) for your environment.

In addition, any JavaScript which is created is also optimized, whereby extraneous whitespace is removed, comments are elided, and even variable names are shortened; by compacting the JavaScript in this manner, it’s quicker for the browser to download the code, which improves performance even more. For example, a JavaScript function that might normally be written like this

//adds two numbers together, and returns the result
function addTwoNumbers(firstNumber, secondNumber) {
addedNumbers = firstNumber + secondNumber;
return addedNumbers;
Might end up looking like this, instead:
function a(a,b){c=a+b;return c;}
Obviously the first version is easier to read, and therefore easier to maintain. As a developer, I would never write code like the second version. But because JavaScript is a scripting language (meaning that it is not compiled into machine language, it is interpreted by the scripting engine at runtime), it means that every byte from that first version gets sent across the network to the browser, comments and whitespace and all. The second version, however, is much smaller, meaning that it will take less time for the browser to download it over the wire. (In this case, the optimized JavaScript is 32 characters, vs. 177 characters for the more maintainable version—something like 82% smaller. Code with a lot of whitespace and comments, and code with long variable and function names, will end up looking a lot smaller in the optimized version, because there’s more stuff that can be stripped out and reduced.)

With GWT, we get the best of both worlds, because the developer works with easy to read, maintainable Java code, but the GWT “compilation” process spits out the more optimized version in JavaScript, to send across the wire.

A typical GWT development lifecycle will be similar to this:
  1. Developer begins developing in Java, using the Google Web Toolkit (quite probably in Eclipse, using the GWT Eclipse plug-ins)
  2. Developer tests code using the provided runtime; at this point the code is still Java code, allowing the developer to set breakpoints and debug
  3. Once the development is complete, the developer “compiles” the GWT application, to create the JavaScript, HTML, and CSS files
  4. These JavaScript, HTML, and CSS files are included in the larger web application
Of course, as development proceeds, the developer may be repeating steps 2–4.

The GWT compilation process can be controlled using normal Ant built scripts, so the overall build process for Java applications can be modified to include a build of the GWT code, and inclusion into the appropriate location in the larger WAR/EAR. For non-Java projects, you can simply “compile” your GWT code, and include the generated files (HTML and JavaScript and CSS and images) in your application.

It’s similar to what we talked about in the Computer Generated Code post; the code that you maintain, and actually work with as a developer, is strongly-typed, clean Java code, with all the comments and whitespace and readable variable names that you are used to. But the code that is actually produced for use at runtime is highly optimized, unreadable code, intended to be seen only by a machine, not a human.

The limitation will be how good GWT is at turning your Java code into JavaScript code. When I did a Proof of Concept application back in the Fall, for an AJAX application we were intending to build at work, I did two versions, one in “raw” JavaScript, and another using GWT. I found that the performance of the “raw” version was better than the GWT version—but, that being said, because of the nature of the GWT libraries, I ended up having to change how I did some things, so it’s not like the code was the same in both cases. It wasn’t a strict apples-to-apples comparison.

For the real application, we decided to use GWT anyway, though, for two reasons:
  1. Our developers are more familiar with Java than JavaScript, so the benefit of maintaining Java code instead of JavaScript was a big one. Especially since the application is a Java EE application; our Ant scripts could simply be updated to include steps to compile the GWT code, and then copy the resultant output files into the main application’s WAR file.
  2. A lesser reason is that there is a possibility that further optimizations might be introduced to GWT, improving the way it produces its JavaScript code. It’s possible that an updated version of GWT might produce even better JavaScript output. (Although it may also force us to change the way that we write our Java, so we can’t expect it to just magically make our code faster.)
GWT has been used to build numerous products/projects—including Google Wave, I might add—so it’s being used by real people to solve real problems. But there are also people who are skeptical about it, and when I was researching the best AJAX libraries to use for my project, I saw mixed reactions to the GWT way of doing things. However, I think it’s another great example of doing something similar to what we discussed in the Computer Generated Code post. Writing code in a manner that is more developer-friendly, and outputting code that is more machine-friendly (and, in this case, network-friendly).

Saturday, January 09, 2010

Google Wave

It’s been a while since I wrote a fawning post about how great Google technologies are, so it’s time I remedy that, and write a new fawning post about how great Google technologies are. Enter Google Wave. I started reading about it yesterday, and I think—I’m not sure, but I think—that I’m going to be blown away by this technology.

In a nutshell, Wave is a mashup of email, collaborative document writing (a la wikis), and instant messaging. In some ways this is simply incremental change to existing technology, but I think it’s one of those new ways of looking at things that has the potential to be a paradigm shift. To see what I mean, let’s take a very abbreviated look at the history of documents, email, and instant messaging:

  1. In the olden days, before computers were invented, people used to write documents using a pen, or with a typewriter, or using similar technologies. If they wanted to send a copy of that document to someone else, they would bring it to them, or send it by mail. That person, when they’d received the mail, could read the document, and mark it up using a pen or pencil, and mail it back to the original person. S/He could read those changes, and, if s/he so wished, write/print/type up another version of the document, incorporating any of the changes that s/he wanted to incorporate. If the people needed more immediate feedback than mail could provide, they could use a technology called the telephone to talk to each other, over great distances, for immediate feedback.
  2. Computers brought electronic versions of these technologies. Word processors and spreadsheet programs and presentation software replaced paper documents (or, at the very least, made it easier to create them—people still had a habit of printing them out, from time to time). Electronic mail, or email, replaced mail. We developed something called instant messaging for immediate communication, for those times when email was too slow, so that we can have a real-time conversation.
  3. These technologies changed how we communicate; instant messaging is largely replacing phone calls, even as it incorporates phone-like features (like voice chat) and improves on them (like video chat). Email is largely replacing physical mail, and the contempt we have for the speed of physical mail is apparent in its new moniker, “snail mail.” Email also changed the way that we correspond with each other; when you send an email, you can send it to multiple people, and when one replies to an email, the reply usually incorporates a copy of the original email, so that a conversation can be maintained. Email introduced the concept of reply all, which means that everyone can be included in the email conversation, and provide their input (if necessary). Emails can also be forwarded to others, even if they weren’t originally included, or, when replying to an email, you can simply add new people to the reply, if you think they should know about the conversation that’s happening.
  4. These technologies also changed the way that we wrote documents; with the ability to do everything electronically, we now had the ability to email a document to someone else, as an attachment, for them to read electronically, and then send a reply email back, with their comments on the document. Electronic documents made it much easier to incorporate changes, rather than having to write or type out another version of the document by hand.
  5. Soon the people making word processors and spreadsheets and presentation software started incorporating features into their products that made it even easier to do this. Things like track changes and the ability to add comments made it very easy to see what changes others were suggesting, and software got very good at merging different versions of documents together, even tracking who had made what changes.
  6. Looking for a way to keep our documents together in one place, people began creating document repositories. More than just a glorified file folder, these repositories included features like having multiple versions of a document, and workflow capabilities, and the ability to lock a document while editing it, so that nobody else can, until you’re done and you “check in” your changes.
  7. Even with these advances in editing, some people felt it wasn’t enough, and the wiki was born. A wiki was a web site that anyone could edit, and in some ways strove to replace the document. The obvious example is Wikipedia, the online encyclopaedia that anyone can contribute to, but wikis have also been used for things like documentation for software projects. (Rather than having a series of documents that must be kept up to date, the documentation for the project is a [potentially] always up to date web site, that can easily be searched and updated.)
  8. Despite the advent of the wiki, the vast majority of people were still creating documents, and emailing them back and forth as attachments, and using their track changes features to make changes. (Or they were simply replying to the original email, and saying things like, “You spelled a word wrong on page 4, paragraph 6. The diagram on page 9 is incorrect.”) Then Google came along with Google Docs, and gave us technology to put a document online, and let multiple people edit it at once, collaboratively. Google Docs turned documents into mini wikis. Now, instead of emailing a document as an attachment, for the person to edit and send back, forcing you to incorporate the changes, you would simply email (or IM) a link to the document, and the person would edit the document itself.
And this is about where we stand today. Wikis still exist, but aside from Wikipedia, they aren’t that prevalent. Despite the fact that I and others like me think Google Docs are cool, most of us (including myself) are still using applications like Microsoft Office to create our documents, and most of us are still using email to add these documents as attachments, to send to others. Interestingly even when we have a document repository—like Sharepoint, for example—we’re often still sending the documents as attachments; we could just send a link to the document in the repository, but in many cases someone doesn’t have access to the repository, and the document author usually isn’t the repository maintainer, so it’s much quicker to just email a copy of the document than to go through the red tape of getting the person granted access to the section of the repository that they need, to read the document. Email is, by far, the most prevalent means of communication, but instant messaging has also become an indispensable tool, both for work and personal use.

But still, even with the advances in technology we’re down to email (a replacement of snail mail, with some obvious improvements), instant messaging (a replacement of the telephone, with some obvious improvements), and electronic forms of documents (with some obvious improvements in how they’re created, but still, at the end of the day, are very much centred around the end product: the document.) Wikis are on the fringes, as a potential replacement for documents, but they haven’t gained traction as such.

So all of this to say, what is Google Wave? As mentioned, in some ways, it’s incremental technology, combining documents, email, and instant messaging into one technology. That was my first thought, when watching the hour and twenty minute long video where it was introduced. (Just in case that link expires, here’s the direct link to the YouTube video.) You can create a document, and multiple people can collaborate on it—just like Google Docs, you might say. You can receive notifications in your “inbox” when there are changes—just like in email, you might say (with a bit of an improvement). If people are online at the same time, you can see the changes they’re making as they make them, and you can send each other messages—just like instant messaging, you might say. Just like email, you can send someone a message, but when they respond to that message, they’re not limited to the usual message/response format we’re used to for email.

But here’s where the paradigm shift came in for me: email, documents, and instant messaging are all electronic versions of things we already used to do; with Google Wave, we have a potential replacement for email, documents, and instant messaging, creating a new paradigm that’s based on what computers can do, instead of simply trying to do the same old things we always did, with incremental improvements. (See this post on the Google Blog for an expansion on this.) With Google Wave, the line between an email and a document and an instant messaging conversation becomes blurred; what, really, is the difference between an email and a document? For the most part, just the length, and the means by which one can share it.

Today, when I want to communicate with someone, I have a few options:
  • For a quick conversation with a quick answer, I can open my IM client, see if the person is online, and start a conversation. If I want, I can include multiple people in the conversation (although most IM clients will limit this to around a half dozen people or so).
  • For something a bit more detailed, I can write an email, and send it to the person or people I want to communicate with. They can read the email, or, if required or desired, they can respond to it, and add their thoughts or make corrections on my original thoughts.
  • For something that I want to make more permanent and/or official, I can write a document, and email it as an attachment or put it in a document repository. Others can read the document, and, if required or desired, they can send an email back to me, with their thoughts or corrections. If they have permission, maybe they can edit the document itself, in the document repository, and their changes will become part of the document.
Three different ways of communicating my ideas, depending on the nature of those ideas. With Google Wave, all three of these would be something called a wave. I want to communicate something to a person or people, so I create my initial communication, it shows up in their inbox, and they can communicate back in the manner that they see fit; changes to the content, comments off to the side of the content, private messages to some people who are part of the wave but not to others… whatever makes sense. If the conversation becomes detailed/important enough, it will be shared and seen by more and more people, just like a document might in today’s world. If not, it might be a simple short communication between two people, just like an IM conversation might in today’s world.

We currently have three levels of “permanence” for our communications, from the throwaway IM conversations to the slightly more permanent emails—which are still locked in our inboxes, to be seen only by us and people we forward the emails to—to documents, which become artefacts and semi-permanent records of our thoughts or findings on a subject. Waves make these distinctions obsolete, and the only distinction in the wave world is how many people the information is shared with. (One question in my mind, however, is whether waves will have the immediacy of instant messaging; I can easily see that we might no longer need a distinction between email and documents, but when I get an IM, in today’s world, it’s something immediate, that I respond to immediately; will that still be the case, if it’s just one more wave hitting my inbox? I’m not sure.

Email has been around since the beginning of the internet, and, as mentioned, is the most prevalent form of communication on the internet. With Google Wave, we may have a serious contender for a new form of communication, with the potential to replace email. We may also have a new way of doing wiki-like things that will be more popular than wikis ever became.

It should also be mentioned that Google is doing this all open source, and creating generic protocols that can be used; this isn’t just a closed system, where you’d have to sign up with Google to get access. You can create a corporate “wave server,” similar to how we have corporate email servers today. And, just like email today, you’d have the ability to add people to your waves that aren’t on your corporate wave server (just like you can send emails to anyone on the internet), but also not give them access to waves that they shouldn’t have access to.

Unfortunately, Google Wave isn’t yet completely open to the public; you can just sign up, and they’ll let you know when you can join. So I’m going to sign up, and play with it when they let me in. Of course, it won’t really do me any good until I know someone else who uses it.