Archives for category: Uncategorized

I had a fun chat today with Coté on his “make all” podcast. Here are some of the topics I remember discussing:

  • 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!

Update: I’ve created a test page for this scenario, but I haven’t had a chance to test it yet on my iPad.

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!

I know this is total n00b stuff but I always forget the particular so I thought I’d write it down in a blog entry.

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

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

if [ -f $HOME/.bashrc ]; then
        . $HOME/.bashrc

Then in .bashrc, put something like the following:

export PATH=$PATH:$HOME/Scripts

Make both scripts executable:

chmod +x .bash*

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

ln -s $HOME/Scripts $HOME/Dropbox/Scripts

I hit a very annoying issue using on my Mac with iTunes and my iPhone. I thought I’d document it in case others hit it.

Setting the Stage

I got a MacBook Pro in early 2009. I buy audiobooks from 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 account in iTunes, you never have to enter your user ID and password again. Also, once you have authorized your 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 audiobooks. The first symptom was that none of my Audiobooks were on my iPhone. I tried to play one in iTunes and it asked me to authorize my 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 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, I discovered the following steps to reproduce the problem.

  1. Start iTunes
  2. Double-click an audiobook
  3. iTunes prompts you to authorize your computer for your Audible account by asking you to enter your user ID and password
  4. Enter 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/ (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 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 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

Occasionally I need to produce YouTube HD videos showing me doing something in a web browser. Up ’till now I’ve had to painfully, manually resize the browser window to 1280×720 so that the video didn’t get unnaturally shrunk or expanded by my screencast rendering software. Tonight I figured out a way to automatically resize my browser window to the exact dimensions using AppleScript.

Here is the magical incantation:

tell application “Safari”

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.

I used to read a lot of tech books, like a an hour or two a day. Several years, several promotions, two kids, and one deteriorating eye later, I realized I wasn’t reading much anymore. The combination of work commutes / / iPod helped me keep up with novels and non-techy non-fiction, but I still had trouble keeping up with tech books.

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, 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).

As my dear colleagues Simon Johnston and James Branigan have mentioned in various blog posts, on the Jazz project that I work on, we’ve (finally) fallen in love with the web/REST story. Because of this, we spend a lot of time in technical conversations using the standard REST alphabet soup vocabulary you’d expect – HTTP, XML, JSON, REST, URL, URI, etc.

One funny thing I’ve noticed is that there’s a certain conversational dance that goes on when the topic of URLs/URIs come up. For 99.9% of the web developers out there the distinction between “URL” and “URI” doesn’t matter, as the Wikipedia entry on URL points out:

In popular usage and many technical documents, [URL] is a synonym for Uniform Resource Identifier (URI).

However, some people who are a bit more pedantic than others care about the distinction (not me!) and tend to use “URI” in favor of “URL” when talking about REST stuff. People who are a bit new to the REST stuff on the other hand tend to use “URL”, since this term’s a bit older and a bit better known.

I’ve observed that when a REST newbie talks with one of the REST pedants, the newbie says “URL” while the REST dude uses “URI”. But as the conversation continues the REST n00b eventually uses “URI” – essentially deferring to and adopting the more knowledgeable person’s terminology.

I’ve also observed that when I talk with one of our REST dudes, if I continuously say “URL” (usually out of spite – I’m KIDDING!), they usually eventually start saying “URL”, I think just to bring more harmony to the conversation and because they realize that the distinction isn’t that important – probably simple mirroring at play.

I think in a future experiment, I will use the opposite term of whatever the other person (newbie or pedant) uses and as soon as they adopt my terminology I’ll switch back to the other term, and see what happens.

Should be fun.