Trading Ideas from #futureruby

2009-07-15 20:00:00 -0400

I’ve been meaning to get a post up about Future Ruby, the fantastic conference hosted by Unspace last weekend in Toronto, but I haven’t had a chance. Since we got back our team has been playing catch-up, so I wanted to pause quickly to highlight some interesting developments since the conference.

I got to chatting with Dan Grigsby about a possible means of offsetting the iTunes App Store’s negative review bias, and he went and made it a reality, with sample code and all. Very cool.

There were a number of inspiring and challenging presentations that have inspired post-con discussion and debate. If you search on the #futureruby hash tag on Twitter you’ll find all sorts of links to discussions, comment threads, summaries and even video. Looks like even BoingBoing took notice! Many of the attendees (including myself) have taken to watching the tag to keep up and keep in touch with each other.

More thoughts to come tomorrow, there’s more testing to do this afternoon on Tempo for the maintenance update.

IE users on Tempo have been dropping off

2009-07-15 20:00:00 -0400

Like most web programmers out there, we’ve wasted spent some “kwality” time trying to get our page layouts for Tempo to work and look good in Internet Explorer 7 (we don’t support IE6). The advent of IE8 has made this a bit easier by providing a compatibility mode for going back and forth, helping us to identify needed fixes for our ie7.css file.

As we delayed another over-due set of updates in order to fix some IE issues, I started to wonder what percentage of our users actually use IE, and if that percentage justifies spending all this time. According to Google Analytics, only 10.25% of our visitors (which is a larger group than our active subscribers) in the last two months were using some form of Internet Explorer.

Tempo Analytics Browser S

Ten-odd percent of our users certainly warrants us taking the time, but it’s still a surprising metric. Furthermore, it’s down 1% from July of 2008 when IE clocked in at 11.28% of our users, despite the fact that our traffic and active users have climbed substantially from that period. I’m not sure if this indicates a preference on the part of our customers and our would-be customers, or if it means we haven’t provided IE users with the kind of interface they really want.

That said, we’ve been hard at work on a number of adjustments to Tempo’s interface to tidy things up, and many of these adjustments specifically address some display issues in IE7. We’re working on it, dear customers!

The Case for Strip-ing

2009-07-14 20:00:00 -0400

When people ask us if we have any iPhone apps in the iTunes App Store1 and we tell them, “yes,” they invariably get excited. Their expectations of some cool, new, game-changing technology seem to dampen when we tell them about Strip (unless they are cryptography enthusiasts). However, we often hear back from many of these same folks a few months later, telling us that they use Strip all the time, and can’t live without it.

Homer Oh NoOur friends and colleagues are starting to get worried about the bazillion sites on which they’ve set the same password. Maybe I’m preaching to the choir here, but we all do it from time to time. There’s just too many to track: car insurance websites, bank accounts, social networks,newspaper site, some online community where you registered to leave comments, some new online tool you want to try out, a thing here, a thing there. You probably sign up for something new on the Inter-tubes at least once a day.

As far as settings passwords go, you really have two options:

  1. Set something different for each one and actually remember them all (good luck with that).
  2. Use some clever ‘p4ssw0rd123’ or variant for all of them (e.g. p4assw0rd-facebook).

Choosing option 1 is the most secure, and the most difficult. Option 2 leaves you exposed to massive risk – one good guess, a password cracker, or a break-in on a site that didn’t hash your non-unique password could allow an attacker to get into your online bank account. Many sites e-mail your password back to you – then your ‘p4ssw0rd123’ has gone through quite a few tubes and machines in clear text by the time it arrives in your inbox. Which is also on someone else’s computers, isn’t it?

The basic work-flow of Strip was designed to fix this very problem, and it seems to get people hooked. Say you want to sign up for some new web service to try it out, but you don’t want to use that bank account or email account password. You hit the sign-up screen, you get to the password field and you fire up your iPhone (or Palm, for the Old School-ers), open up Strip, create a new entry, and generate a random password. Save it in Strip, set it on the site, and you’re done. Sure, it introduces an extra step, but now your brain isn’t filling up with garbage and you’ve drastically reduced the risk to your online information and identity.

Strip Generate Palm Strip Generate iPhone

Obviously, Strip itself could be a point of potential failure. If you left your iPhone (or Treo) in a taxi like many of our customers have done, you wouldn’t want the cabby or the next occupant to have access to private networks and mail servers. To mitigate this we use high-grade, peer-reviewed open source cryptography to make it very unlikely that anyone will ever unlock your copy of Strip before the heat death of the universe (so long as you set a strong password!) At this point we’ve got 12 years of experience under our belt, and the code is out there for anyone to see, improve, and criticize. We will continue to update Strip’s encryption engine, SQLCipher, to stay on top of the latest encryption updates, protocols, and techniques. We’ve even strengthened SQLCipher since we launched Strip in the App Store. Don’t take our word for it, have a look yourself.

1 Overheard snark last week at FutureRuby: “They managed to build an App Store without actually building an App Store.”

Tempo Maintenance Tonight

2009-07-06 20:00:00 -0400

Starting at 11pm EDT tonight, Tues July 7th, Tempo may be briefly unavailable while we update the application. We’re moving the beta to production!


2009-07-06 20:00:00 -0400

I have somewhat consistently maintained that the Apple Push Notification Service for iPhone developers is a really bad kludge. I still stand by that! It’s a poor stand-in for the local system scheduler that’s already on the device.

That said, there’s a proper tool for every job, and APNS is absolutely perfect for Prowl:

Prowl is a Growl client for the iPhone. Notifications from your Mac can be sent to your iPhone over push, with a full range of customization and grace you expect…. As soon as a Growl notification pops up on your Mac, Prowl will forward it to your iPhone or iPod Touch over the push notification service found in iPhone OS 3.0. Which notifications are pushed is configurable, allowing only the important messages to be delivered.

The possibilities there are really huge. Not to mention that it’s a geek’s dream, and perfect for sysadmins. Now you never need to miss those sweet nothings your desktop whispers in your ear when you’re out and about tolerating the company of other fleshy ones. Imagine:


  • unix box: OMG disk is full!
  • mail server: OMG OMG OMG I/O SPIKE!

All kidding aside, this is a nice bridge to between web/internet services on a dedicated connection and mobile devices, and it in no way involves text messages. Anything that cuts into the bottom line of the Text Message Tax Collectors makes me smile.

Another recent innovation with APNS is the arrival of the first middleman, Urban Airship, which handles the details of maintaining state with APNS so you don’t have to construct the infrastructure yourself.

Image snagged from the Prowl website.