• What’s important (and what’s not important) about HTML 5
• The increasing ubiquity of JavaScript
• Java-to-JavaScript translation technologies (e.g. GWT and JDojo)
• Ajax, RPC, and REST
• The nirvana of mobile devices plus cloud-based data
• I recommend Nick Carr’s “The Shallows“

Happy listening!

In our Jazz UIs, we tend to use “hover previews” quite a bit. That is, if you hover over a link, after a second or so it will show a small preview of the resource at the other end [1]. Jazz style guide example below (copyright IBM).

This was always broken on the iPhone’s Mobile Safari browser because I couldn’t figure out how to perform a mouseover action on a mouse-less interface.

I just noticed that the iPad seems to support onmouseover. I believe I’ve observed the following behavior:

• If a link has no “on mouseover” actions (e.g. hovers), a tap follows to the link.
• If a link has an “onmouseover” action, a tap activates the onmouseover action and a double-tap follows the link.

Obviously this implies that you should provide visual indications to your user whether the links provide onmouseover actions or not. For the Jazz links with hover previews we immediately decorate the link on mouseover (different color, double-underline, with a small chevron) and if the user remains over the link for a second or two we then show the preview.

[1] I realize that onmouseover actions attached to links represent a UX minefield. A page with too many / too aggressive hover actions can feel like an actual minefield!

To add a custom scripts directory to your path, do the following:

In your root directory, create a file called .bash_profile.sh with something like the following:

if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

Then in .bashrc, put something like the following:

export PATH=$PATH:~/Scripts

For extra credit, create a softlink from your Dropox folder to your scripts folder and you can have the same scripts on all of your computers!

ln -s ~/Scripts ~/Dropbox/Scripts

Setting the Stage

I got a MacBook Pro in early 2009. I buy audiobooks from Audible.com and store them in iTunes. From iTunes I sync the audiobooks to my iPhone so that I can listen to them while driving, cleaning, etc. The audiobooks are DRM-protected (urgh), so the first time you try to play an audiobook in iTunes it asks you to enter your Audible user ID and password. It then validates your Audible user ID and password and verifies that you have purchased the audiobook file. Once you have authorized your Audible.com account in iTunes, you never have to enter your Audible.com user ID and password again. Also, once you have authorized your Audible.com account in iTunes, you can sync audiobooks to your iPhone.

The Symptoms

Recently IBM got me a new 2010 MacBook Pro for work (thanks IBM) so I gave my 2009 MacBook Pro to my wife. So that I wouldn’t have to set everything up from scratch, I backed up my entire 2009 MacBook Pro to an external drive using Time Machine and then restored this configuration onto the new MacBook Pro. After a couple of hours of data transfer both ways, my new MacBook Pro was a clone of my old MacBook Pro, or so I thought.

Unfortunately I realized quickly that something was wrong with my Audible.com audiobooks. The first symptom was that none of my Audible.com Audiobooks were on my iPhone. I tried to play one in iTunes and it asked me to authorize my Audible.com account. This was a surprise because I would have expected the Time Machine backup / restore to have made this unnecessary (since my iTunes configuration was already authorized), so I typed in my Audible.com user ID and password, hit sync, and sure enough the ebooks synced successfully to my iPhone.

Later that week I noticed that the audiobooks had disappeared from my iPhone again!

The Bug

To make a long story short (too late), after some experimentation and support discussion with Audible.com, I discovered the following steps to reproduce the problem.

1. Start iTunes
2. Double-click an Audible.com audiobook
3. iTunes prompts you to authorize your computer for your Audible account by asking you to enter your Audible.com user ID and password
4. Enter Audible.com user ID and password and successfully authorize
5. Sync iPhone
6. Audiobooks copy successfully
7. Close and re-open iTunes
8. Sync iPhone
9. Books are deleted from iPhone

Basically anytime I closed iTunes, my Audible authorization was lost. This indicated that authorization was succeeding but was not being persisted to disk. I sent the steps to reproduce to Audible customer support.

The Solution

As I suspected, it was a persistence problem. The Audible support person pointed me to the file /Library/Preferences/com.audible.data.plist (a Mac property list file) where (apparently) the Audible / iTunes code persists your Audible authorization information (I peaked in the file and it contained a single ‘data’ property whose value was 4 KB of encrypted something or other). Interestingly, even though I’d at this point authorized my Audible account in iTunes many times this week, the file’s date stamp was from last year, indicating the file wasn’t getting updated and thus my authorization went *poof* whenever I closed the iTunes application and its process died.

The Audible customer support rep first suggested to check the file’s permissions to make sure that my user account was authorized to modify the file. No problems there – I had read/write access to the file. Her second suggestion was simply to close iTunes, delete the Audible property file, open iTunes and reauthorize the computer. I did this and sure enough when I reauthorized the computer, a new property file was created with the current time as the timestamp and I was able to close and re-open iTunes without having to re-authorize.

Lessons Reiterated

This experience reinforces two software principles I already believed.

• DRM sucks ass
• Data persistence is hard

Solution Proposal

I sent the following suggestion to the Audible.com support person:

Thank you <redacted>. It’s working now.

FYI, it was not a permissions issue – the permissions were correct. I had to delete the com.audible.data.plist file and restart iTunes / reauthorize Audible to create a new version of the file.

I suspect this is related to my restore from Time Machine on to a new computer. I would suggest your engineers who work on the Mac iTunes integration test this case:

1. On a Mac, authorize to read Audible content via iTunes

2. Backup a Mac onto Time Machine

3. Restore from Time Machine onto a new Mac

4. Attempt to play Audible content

I’m not sure what the ideal behavior is (e.g. just working or requiring a single authorization of the new machine) but I know what should not happen is what happened to me

Thanks again for your help.

- Bill

Here is the magical incantation:

tell application “Safari”

activate
set the bounds of the first window to {0, 0, 1280, 720}

end tell

Run this application in AppleScript Editor (/Applications/Utilities/AppleScript Editor) and your browser will be the perfect size for recording movies. You can save the script to a folder for later reuse.

—–

Hi <redacted>,

You are correct that as of Jazz Foundation 1.0.x (shipped this year), one contributes “viewlets” (a Jazz-specific widget mechanism comparable to OpenSocial Gadgets and iWidgets) to Jazz Dashboards via a server-side Eclipse extension point.

However, the Jazz extensibility story is more complex than OSGi bundles and Eclipse extension points. I will explain this below, with the assumption that you are interested.

Original Extensibility Mechanism Based on Bundles and Extension-points

When we first started the Jazz server work in 2005 we made a design decision that the Jazz server would be based on Java/OSGi and you contribute capabilities to the server by adding additional OSGi bundles. I’m guessing you’re very familiar with this architecture; it’s of course very similar to the Eclipse workbench except instead of contributing actions and views (e.g. to implement a Java IDE) you contributed web services and data definitions (e.g. to implement a bug tracking system). We went so far as to enable this style of programming for Dojo-based Ajax code so that developers could add “web bundles” and have the Jazz Web UI framework discover and surface their web capabilities in the Jazz Web UI. The Dashboard viewlets are one example of an extension-point-based extension. There are other extensions also enabled by extension-points (as in Eclipse, this extensibility model is open-ended).

Shift Towards a RESTful Architecture

Around 2007 we came to the conclusion that the “extend the server” model wouldn’t enable us to achieve our broad goal of “enabling integration of heterogenous tools across the software lifecycle”. There were several blocking problems with this architecture. I will list a few below:

We came to the conclusion that the RPC style service APIs were too fragile over time and would make it difficult to allow for independent upgrades of different tools in an environment containing many tools.

We could only support a narrow range of technologies (i.e. OSGi-ified Java and JavaScript code built on top of our server architecture). This limitation is readily apparent when you compare it to something like OpenSocial Gadgets or iWidget where you need only specify a gadget/widget URL to achieve integration.

This caused us to take a step back and ultimately decided to use the REST architectural style to achieve integration across tools. For instance this year we enabled several integrations between our Requirements Composer, Team Concert, and Quality Manager products using RESTful protocols and APIs. For an example of these integrations, see this video on Jazz.net that demonstrates how we use REST and Discovery to drive linking and “picker” integration between two tools.

Implications of RESTful Architecture on Extensibility Model

The shift to the RESTful architecture left a gap w/r/t extensibility. I.e. how do we meet extensibility needs if we can’t assume a homogeneous OSGi/Java/JavaScript-based programming model? The solution we came up with was something that we generically call “Discovery” (an overloaded term, I know). Basically each tool in a Jazz environment has a single “root services” document that describes the basic capabilities of the tool and has pointers to other documents that contain more details about a specific service. You configure tools to know about each others’ service documents, and from there they can discover and (if appropriate) consume each others’ capabilities using spec’d protocols (as opposed to physically installing code from Tool A within Tool B’s environment).

For instance, we have a “viewlet provider” service type that announces that the tool in question has viewlets that can be embedded in Dashboards. Here’s an example of how it works:

• Tool A has Jazz Dashboards capabilities
• Tool B claims to be a “viewlet provider”
• Tool A is configured to connect to Tool B (this includes specifying Tool B’s root URL and configuring an OAuth consumer / provider relationship)
• Tool A is now able to host Tool B’s viewlets in its Dashboards

The interesting thing about this is that Tool A and Tool B could be implemented in wildly different ways… e.g. OSGi/Java vs. PHP.

* As an aside, we are currently working to deprecate Jazz Viewlets and adding the ability to host iWidgets and OpenSocial gadgets in Jazz Dashboards. This is in plan for 2010.

Going Foward

Even though we have moved to a REST-centric architecture, OSGi and Extension Points are still important, but less so than they used to be. We will continue to ship and use the OSGi and Extension Point-based Ajax frameworks and building blocks for the near future, but our major development investments and the Jazz SDK‘s focus will only assume fundamental web technologies like HTTP, HTML, JavaScript, and CSS and provide optional higher-level frameworks around emerging web standards like OAuth and OpenSocial.

I hope this was useful for you.

- Bill

Luckily, tech publishers are starting to publish more and more ebooks. Here’s some of the good and bad points of reading tech ebooks.

Tech Ebooks: The Good

• My Macbook Pro‘s multi-touch trackpad makes it very easy to zoom and scroll so I end up with huge font that I can read without glasses from several feet away.
• I can carry all of my ebooks on both my computer and iPhone.
• Publishers like O’Reilly and Pragprog have relatively mature ebook stories; DRM-free, mobile integration, and available in both computer-friendly (PDF) and mobile-friendly (EPUB) versions and notification for free updates of new printings.
• I can quickly search across all ebook content using Spotlight and quickly open ebooks using Quicksilver and Preview.
• They’re significantly less expensive than their dead tree counterparts and you can acquire them instantly vs. a trip to the bookstore or, more likely, a two day wait for an Amazon Prime delivery.
• Using Dropbox you can easily replicate your ebooks across all of your computers while easily staying under Dropbox’s 2GB free account max.

Tech Ebooks: The Bad

• Can’t (ethically) lend to friends; can’t give away when done with a book.
• I have a 1st gen Kindle I never use. While I love the selection, price, and integration with Amazon.com, I hate the hardware design, the user experience, the $@#! DRM, and the fact that I can’t (easily/legally) view the books on my computer. Don’t buy a Kindle.
• The selection of ebooks is relatively small vs. all books I’d want to buy. For instance, no How Buildings Learn ebook (though I’ve sent the publisher an email on this).
• Many ebook-selling publishers still insist on using DRM. This is stupid. As the argument goes, honest people like me will gladly pay for quality IP and a good user experience. DRM-selling publishers: please learn from O’Reilly and Pragprog.
• You need a different account for each publisher. Luckily password management apps like KeePassX simplify this, but it’s still a pain.

Tech Ebooks I’ve Recently Bought

Now, for your reading pleasure, are the ebooks I’ve bought in the past few months (updated 25 Oct. 2009).

• Agile Web Development with Rails, 3E
• Ambient Findability
• bash Cookbook
• Behind Closed Doors: Secrets of Great Management
• Classic Shell Scripting
• Clean Code
• Cloud Application Architectures
• Core Java Vol 1 8E
• Design Patterns
• Designing Web Interfaces
• Designing Web Navigation
• Effective Java 2E
• High Performance Web Sites
• How to Break Web Software
• HTTP The Definitive Guide
• iWork 09 The Missing Manual
• JavaScript: The Good Parts
• JavaScript the Definitive Guide 5E
• Just a Geek
• Mac OS X for Unix Geeks 4E
• Mac OS X Internals
• Mac OS X Snow Leopard the Missing Manual
• Making Things Happen
• Manage It!
• Mastering Dojo
• Photoshop CS4 The Missing Manual
• Pragmatic Thinking and Learning
• Programming in Objective-C 2.0
• Programming Python 3E
• Programming Ruby 1.9
• Release It!
• RESTful Web Services
• Scaling Lean & Agile Development
• Secrets of the JavaScript Ninja
• slide:ology
• SSH The Definitive Guide 2E
• TextMate
• The Art of Community
• The Design of Things to Come
• The Myths of Innovation
• The Passionate Programmer
• The Productive Programmer
• The Ruby Programming Language
• The Twitter Book
• Ubuntu Kung Fu
• Unit Test Frameworks
• Unix Power Tools 3E
• Using Google App Engine
• Web 2.0 – A Strategy Guide
• Web 2.0 Architectures
• XMPP The Definitive Guide

if(window !== top) {
   var mode = "frame";
}

‘window’ of course is the global object in which your code is running. If you’re running in a frame, your window object is actually a child in a window hierarchy. ‘top’ refers the to the top-most window in the hierarchy. Therefore if window and top are the same, then you are in a top level page; conversely if they are different, then you are in a frame (or iframe).

This works great on Firefox but on IE, the window !== top expression never evaluates to true. That is, even if you’re the top window, ‘top’ and ‘window’ aren’t considered equal. I’m not sure why this is. My current fallback code is this:

try {
    if (top.location.href !== window.location.href) {
        var mode = "frame";
    }
} catch (e) {    
    // if you're in an iframe in a different domain, the top.location check
    // results in a security exception
    mode = "frame";
}

This code has two problems:

1. There’s a small possibility that you could have the a frame with the same URL as the outer page. This is very unlikely because there’s no scenario I know of where you want to nest a page, but it’s still a latent bug.
2. You have to deal with the exception in the cross domain case. Not a big deal but unclean.

I’m curious if anyone has a better solution for detecting whether or not you’re in an IFrame.

• A nice component model based on OSGi bundles and the Dojo module system
• Request-time “building” of many fine-grained JavaScript files into monolithic files for faster download based on the introspected relationships between the files – i.e. no developer effort required for fast code loading other than writing good application code
• Making a subset of the Eclipse extension registry available in the web page and queryable via JavaScript APIs modeled off of the org.eclipse.core.runtime extension registry Java APIs, allowing for open-ended extensibility using the Eclipse extensibility model
• A simple framework for demarcating UI states that made the back button, history, and page titles work seamlessly within the Ajax page, even when a user gesture resulted in crossing a component boundary (e.g. loading and displaying a new virtual “page” from a different component)
• Dynamic, transparent loading of missing code in response to a user gesture that required it

We did a fairly good job of keeping our Ajax framework decoupled from the rest of the Jazz Platform both for the purpose of design cohesiveness but also to allow for possible future use by teams who weren’t building full-blown application lifecycle management applications like Jazz SCM or Iteration Planning.

Over time, other IBM teams heard about some of our capabilities and saw the positive results in our Rational Team Concert web UIs (1) and contacted us to explore whether they could make use of our code in their products. Each conversation went like this:

1. We gave a demo and talk about the capabilities and architecture of the framework
2. The other team said “that’s really nice, that’s really useful, that would be great to have”
3. The other team said “we’re not sure we want to live within your framework, we’ll get back to you”
4. The other team didn’t get back to us

Initially this didn’t really bother me – after all my job was to deliver the foundation for our Jazz web user interfaces, not to create a general purpose Ajax framework for IBM, but as I’ve thought about it more over time and seen this anti-pattern from other teams and other frameworks, I’ve decided that we should make a conscious effort to make our useful functionality available as simple building blocks (in the form of libraries) and then provide frameworks that layer on top of these building blocks.

Let me take a step back and explain what I mean.

A library is a set of reusable functionality where your application uses parts of the library as necessary. For instance, most programming languages have a library for creating and manipulating dates. Frameworks also provide functionality to the application programmer, but instead of the application programmer making simple function calls, the framework runs the show and calls into the application at well defined hook points. For example, GUI frameworks provide ways to wire up code to run in response to users clicking on buttons.

Both the library and the framework provide useful functionality intended to make the application developer more productive. Though it’s dangerous to make a general statement, it feels to me that the big difference between the two is that frameworks generally provide more power, but require you to make a bigger commitment to the framework’s way of working, while libraries provide generally less power, but make few (if any) demands about how you structure your application.

What’s unfortunate is when you’ve got some useful bit of functionality that could be made available as a simple library but it’s only available in the context of a framework. This is where we were with our Ajax framework. This stuff is too abstract, so here’s an analogy: Imagine that you heard about a new refrigerator which provided every feature and characteristic you ever dreamed about having in a refrigerator. The catch however was that you couldn’t just buy the refrigerator – you had to move into a house on the other side of town that included the new refrigerator. After about 10 seconds of thought you realize that even though it’s the fridge of your dreams, you’re sure as hell not going to move into a new house across town in order to get it. This situation (switching back to software from refrigerators) is shown in the diagram below.

Useful building blocks locked inside a framework

My recent realization (which seems obvious in hindsight) is that the useful functionality provided by frameworks and libraries need not be mutually exclusive. For instance, in our Ajax framework’s dynamic build system, rather than requiring applications to run within our framework to enjoy this capability, we could have created a simple callable library to perform dynamic optimization on a set of files, and then created a framework that simply used this same library. This approach is shown in the diagram below:

Useful building blocks used by a framework but also available independently of the framework

Over the past month or so we’ve been refactoring our Ajax framework to extract the useful building blocks into simple callable libraries and making the framework proper smaller by delegating to these libraries. We’ve done this in the hopes that our code will be useful to other IBM teams but as a result of the exercise, we’ve gained a deeper knowledge of our software and the software’s quality has improved as we’ve decoupled the framework aspects from the building blocks aspects.

Going forward, it’s my intention that our team will generally start with building blocks first and then consider if we should provide some higher-level framework that uses these building blocks. I only wish we had taken this approach from the beginning but you know, live and learn.

Footnotes

1) You can see our Jazz web UIs built on top of this framework in the development section of Jazz.net if you register.

Updates

Changed “other than writing good code” to “other than writing good application code”