Inert Detritus The Internet's dust bunnies

19 February 2009 @ 5pm

Comments Off on Hitmen and Smash Hits

Hitmen and Smash Hits

My Tumblr post earlier today reminded me of something John Gruber discussed a couple of years ago:

The iPod Mini was a smash hit product.

And when Apple debuted the Nano, they killed it.

There was no hesitation, no reluctance. The Nano came out, and the Mini was dead. The manufacturing lines were stopped, it was pulled from the shelves, and it was purged from the website.

Apple stood up and said, “Yes, the Mini was wonderful. But now, it’s not even worth discussing its existence: here is something better. Trust us, you’ll like it.”

11 February 2009 @ 1pm

Comments Off on Google Gears and Webkit Nightlies

Google Gears and Webkit Nightlies

I’ve been using Google Gears with Safari the past few weeks, primarily for WordPress 2.7’s “Turbo Mode” (useful on low-bandwidth or high-latency links), and secondarily for Gmail’s offline mode.

The currently released build ( of Google Gears isn’t compatible with the latest Webkit nightlies, however. Good news, though: it’s a piece of cake to build it yourself.

Check out the source, and build it locally on your machine. I had no hiccups with OS X 10.5.6 and Xcode 3.1.2, everything Just Worked The First Time.

10 February 2009 @ 9pm

Comments Off on G1 vs. iPhone: All in the Design

G1 vs. iPhone: All in the Design

I’ve posted a couple of times to Tumblr about the G1.

I used a friend’s G1 for about a half hour a few weeks back: it was my first non-iPhone cell phone use since I got my 3G in June. Over Christmas, I also used my brother’s LG Dare, and I suddenly realized how spoiled the iPhone interface has made me:

The iPhone is all touch, all the time. If you’re in an application, any application, you will only use the touch screen. Every single action you’ll perform involves the screen: taps, drags, pinches, swipes. You’ll go to a hardware button if you want to quit the app, or if you want to change the volume. That’s it. Not for text entry, not for answering or making a call, not for anything else.

This changed the way I use my phone. I’m now lost on new phones, because I suddenly remember I have to input things via software (touch) and hardware.

There’s a fundamental mismatch with Android on the G1:

The problem with generalizing the software to such an extent is that while it works with many devices, it doesnt work perfectly with any device.

This quickly leads down the path mentioned above. To support all the user interaction methods that Android sets forth, some Android units will have to introduce dedicated hardware inputs to handle them.

Aside: how does no one get angry at HTC for these hardware shortcomings:

  1. No charging/sync and music or calls at the same time. What? That’s insane.
  2. No A2DP. I think Apple has been excoriated on every message board and review of the iPhone ever for this. This is the first review of the G1 that I’ve seen mention it.

3 February 2009 @ 5pm

Comments Off on Cheep Cheep!

Cheep Cheep!

Chyrp: a lightweight blogging engine..

Chyrp: my personal blog.

I’ll be leaving the longer, more thought out, well-written content for this WordPress-backed blog. Personal writing of public interest will appear on chyrp. Update your feeds, bookmark the page, your new TV Guide will appear in next Sunday’s paper, etc

10 January 2009 @ 11am


Hacking iScrobbler for multiple iPods

I’ve been on since 2004. I love music, and I love statistics and data analysis, so when the site launched and I saw what they had planned, I immediately set up an account.

I’ve long used iScrobbler for a Mac client to submit plays to it’s lightweight, supports running in a menu bar-only mode, and has given me zero grief over the years. iScrobbler watches iTunes to detect and scrobble1 songs played as they happen. This obviously isn’t possible with iPod plays, so iScrobbler asks you to use a Recently Played playlist that it watches: after you sync an iPod, iTunes updates that playlist with all the tracks played while you were out, and iScrobbler diffs the playlists to know what to submit.

Until this summer, I used both my 2nd gen nano and my iPod photo to play music: the photo fit nearly everything I had, while the nano was great for the gym. I now use the nano, my iPhone 3G, and an iPod classic for playing music on the go, so my #FirstWorldProblem of making sure all iPod2 song plays get scrobbled to hit a bit of a speed bump. I started interleaving plays on the devices: I’d listen to my iPhone on the bus ride in, use the nano at the gym, then listen some more on the iPhone before syncing them back to iTunes.

To support the iPod, iScrobbler takes snapshots of the iTunes Library, and compares the Last Played and Play Counts in a playlist you configure3 to figure out what songs you listened to.

After an iPod update, iScrobbler will take the last played time of the last played song, sets this as the new “iTunes Last Played Time”, and scrobble everything played since the previous iTunes Last Played Time.4 With interleaved plays, this quickly becomes a problem: when you sync iPod A, iScrobbler bumps the iTunes LPT; any plays on iPod B that happened before that time are now “lost”, since that iPod hasn’t been synced, and they fall before that timestamp. Those plays are very difficult to get back later, so this is a problem worth avoiding5

Playlist snapshots let iScrobbler work around an iTunes/ problem: iTunes only stores the Last Played time, but wants a timestamp for every song play. If iScrobbler sees a song which incremented Play Count by more than 1, it has to “synthesize” the play. The song must have a timestamp for submission, so iScrobbler finds gaps in the play times where no songs were playing, and invents reasonable timestamps for any songs needing a time.

So, for the past few months, I’ve been closing iScrobbler before syncing my iPods. This let me sync both iPods with iTunes, which updated all the songs’ metadata, then launch iScrobbler and tell it to manually update from the iPod playlist.

A few weeks ago, instead of just closing iScrobbler before an iPod sync, I started running iTunes with iScrobbler completely closed. All my plays on the desktop go into the same playlist6 as any tracks my iPods play, so they would get picked up like the rest of my iPod plays.

iPods don’t cross-fade playback, so the Start Time of one song7 perfectly adjoins the Last Played time of the track before it. is very particular about track lengths and timestamps, and won’t let you submit plays that overlap, so if that happens, iScrobbler drops the second track to avoid API issues.

The writing on the wall is clear: if you have cross-fade playback enabled in iTunes and play songs with iScrobbler closed, 50% of your desktop plays will be dropped by iScrobbler as overlapping. I haven’t filed a bug against the API on this yet8. You can work around it by turning off cross-fade playback in iTunes; that makes iTunes behave identically to iPods with playback, and you can keep iScrobbler closed for days at a time with no adverse effects.

Postscript: the iPhone 2.0 bug where Play Counts and Last Played times weren’t updated just about killed me. I had to exhibit extraordinary self-control to only play music on the nano, since it was the only device that properly updated the song metadata.

Yes, I think a play count will fall through the cracks if you play it once on both devices; iTunes will crush of the device’s play count with the other’s. I haven’t tested this to confirm or deny it, however.

  1. Submit, in iScrobber/AudioScrobbler/ speak []
  2. For the sake of brevity, “iPod” includes iPhones. []
  3. This is best set to a “Recently Played” smart playlist []
  4. It does this so takes less time and work to avoid duplicating submissions. Duplicate submissions are bounced by the API with great prejudice. []
  5. I typically resort to leaving a playlist running overnight to fake them. []
  6. “Recently Played” captures anything played in the last few weeks []
  7. iScrobbler always has it, so iTunes must be bookkeeping it somewhere. As far as I can tell, this is stored behind-the-scenes and not exposed in the iTunes UI []
  8. There needs to be a few second “grace period” for device clock skew and cross-fading playback []

26 December 2008 @ 6pm

Comments Off on Property Rights

Property Rights

As I read The Economist’s articles on developing nations, whether it be in Asia, Africa, or Europe, a common thread jumps out at me:

Property rights are the key to economic development. People want to own their property, and not have to worry about how to keep it or who’s going to take it.

Property rights, in the form of land ownership, banking, and lack of corruption, all lead to domestic and foreign investment in the country: people know that their property is secure and not subject to random and unjust repossession by officials or armed forces.

22 December 2008 @ 9pm

Comments Off on Addendum: Logitech Control Center software

Addendum: Logitech Control Center software

So, I tried the Logitech software. I really gave it a shot, I swear. It did well for the most part: it didn’t brick my machine at boot, or break any apps that I could tell in the few hours it was installed.

But there were some glaring bugs.

First, what’s the most typical thing to do to a mouse with two scroll wheels and five buttons? You customize the buttons and scrolling to do certain things by default, across the system. You’re allowed to do that, but as soon as you make some custom setting set for, say, Firefox (using that side, snap-back wheel for switching tabs is amazing), you have to re-do your other button settings.

SteerMouse gets this one right. You set your system defaults, and then on a per-app basis, it has an extra option for each button: “Same as Default”, or whatever action you want. Bravo, I say.

Second, scrolling speed was busted in Firefox. There was some weird conflict between the software, the OS X default scrolling speed, and Firefox’s idea of scrolling. When I slid the scrolling speed slider toward “Slow”, it moved more lines per single click of the wheel. Yet, counterintuitively, when you spun the wheel fast, you got less movement than a single click. Busted like a cheap piata, I say.

Third, and maybe this was just me, I couldn’t get the tracking speed and acceleration to behave. It just felt “off”, even after multiple minor tweaks.

So, after an uninstall of LCC and a reboot, I installed SteerMouse (after another reboot, jeez). I love it. It does a fantastic job of customizing the buttons, nailed the tracking speed (different acceleration curve, perhaps?) and even lets me control the free-wheel vs. click-wheel engagement speed of the main scroll wheel (albeit, after running a defaults write command, followed by a logout). I’m going to give it one more day of testing to make sure there’s no deal-breaking bugs, and I’ll be happily paying for a copy of the app.

21 December 2008 @ 7pm


Attack of the Mice!

I just went out and bought a Microsoft Bluetooth something something 5000, and a Logitech MX Revolution. I’ve grown tired of this old Logitech two buttons plus scroll wheel, corded optical mouse, and wanted to retire it.

The first reaction when I talk about mice, especially with Mac owners, is “Why not Mighty Mouse?” There’s two big reasons I hate it:

  1. The ergonomics. The mouse is too flat for my hand to be comfortable when I pick it up to move it. I eyed the Targus mouse @lapcat tweeted about a few days ago, but it seemed too flat to be usable, and the store’s return policy didn’t let me open it and return it if I didn’t like it.

  2. The right-click. On normal mice with two buttons, you can leave your hand as-is, and depress the right mouse button to get a right click. Not so with the Mighty Mouse: if you leave your finger on the left side of the mouse, the hardware decides that you meant to left click. This means you have to LIFT your left button finger up, and click with your right button finger, to get a right click. What a ridiculous way to operate a mouse.

I’m blackballing the Microsoft Bluetooth mouse. While Bluetooth is nice, the mouse is much too small (see #1 above), so it’s out.

I’m loving the MX: it’s got more buttons than most keyboards, the scroll wheels (there’s two, and the main one even does side-to-side scrolling!) are fantastic, and it fits my hand like a glove. It runs on an internal rechargeable battery, and comes with a desktop charger, so I don’t have to screw around with a AA or AAA battery charger.

I’m about to install the Logitech software (which I’ve heard very mixed reviews about), since I’m really looking to program the other scroll wheel and the forward and back buttons (USB Overdrive just doesn’t cut it for me). I’ll update this later with some information on how the install goes.

Edit: here’s the post on the Logitech software. It didn’t go well.

13 November 2008 @ 1pm

Comments Off on Tumblr


An aside: some of my writing is going into Tumblr instead of here: things that are too long for Twitter, but don’t seem to warrant a full blog post. The Tumblr feed includes my blog feed, so subscribe to that instead if you want to read both.

13 November 2008 @ 11am


iPhone Apps: TwitterFon

At Tuesday’s NSCoder SF (an icon for which I have a good, but clichd, idea for), I met @thekarladam, who showed me a few new Twitter iPhone applications. I’ll focus on TwitterFon, since I downloaded it last night and played with it a bit.

Bear in mind, I’ve been a Twitterrific user since The Early Days of Twitter, back in early 2007. It was a no-brainer to download and pay for Twitterrific for the iPhone. I have a few niggling complaints, but overall, it’s been good to me.

TwitterFon does a few things well. First, scrolling performance is, in the words of the Macintoshian Achaia forum on Ars Technica, “teh snappay”. It’s a joy to scroll through the list, which is good, because you’ll be scrolling through it a lot. TwitterFon has, as both Karl and Anne mentioned on Tuesday, no sense of your “place” in your timeline. Twitterrific lets you tap on a tweet to select it, an idea brought over from the desktop application, and when you load new tweets, it remembers where you last were. TwitterFon attempts to remedy this with a very, very light blue background behind new tweets, but I’ve yet to convince it that I’ve read those, and it can stop marking them for me. It also doesn’t autoscroll to this location, which is a pain when more than a couple of screenfuls of new tweets have loaded.

TwitterFon sidesteps the text formatting support currently in the API by parsing out @usernames and links in tweets. When you tap a tweet containing either of those, it lets you jump down a chain of replies, or browse to the link in a built-in Safari-style view.

So, well done, TwitterFon: you accomplish great scrolling performance that I get to enjoy far more than I would like, and you adopt a novel approach to some poor iPhone APIs. Now, the bad part.

I tried favoriting a tweet for reading the link later on my desktop, and I’m still not sure if I favorited it or not. I tapped it, nothing happened, so I tapped again. Still nothing, so I tapped a third and fourth time. On the fourth tap, it turned yellowand then back to clear. Not sure if it was waiting for an asynchronous API call to return, but in either case, poorly done.

I tweeted last night about the lack of API paging in TwitterFon: with the number of people I follow, it lets me load a few times during the day and still catch everything that’s been said since the last refresh. When I refreshed last night just after putting in my Twitter credentials, it only loaded 20 tweets. I tried closing and relaunching the appand nothing changed. Ok, I thought, it doesn’t do paging.

On my walk to the shuttle stop this morning, I opened it back up, having just caught up with my timeline before leaving, so only loading the 20 latest wouldn’t cost me any missed tweets. The app proceeded to load more than a hundred: paging, plus some @replies to me, I assume. Apparently, TwitterFon supports API paging, but didn’t feel like showing that off when I first used the app last night.

The embedded Safari view, which I saw for the first time in Twitterrific, is a great feature for Twitter, and a real necessity for a Twitter iPhone client in my mind. TwitterFon gives you forward and back buttons, and a URL-looking bar that shows you the current URL. There’s no option to stop or reload the page, something often necessary when my phone quickly flips between cell and WiFi on campus: annoying, but not life-threatening. I tapped on the URL displayed at the bottom, in an attempt to perhaps reload the URL or edit it in some way; TwitterFon exited, and loaded the URL in Safari. This is great to have, especially if it’s a longer article or something I want to bookmark, but this was not what I expected from the UI. Twitterrific and NetNewsWire both do something more expected: they either use a Safari-style icon, or a button labeled “Open in Safari” to tell you what’s going to go down when you tap.

I think I would switch to TwitterFon full-time if it fixed the “remember where I was in the timeline prior to a refresh” issue. The other things I mentioned are annoying, and will cost them users (many people will assume it just doesn’t support opening links in Safari, for example), but I can live with them.

Addendum: just found TwitterFon’s webpage. To all application developers: I shouldn’t have to read your webpage to learn all the things your app does. UI Design: You’re Doing It Wrong.

 ← Before  After →