Month: January 2008

In the name of Twitternomics and style

Posted on by Sol Young with 1 Comment

http://twitter.com/solSo I got to thinking the other day about all the peeps on Twitter who have slick, short, names. Most I follow on Twitter follow this convention (ev, al3x, jack, biz, dick, iofy, to name a few). It’s not just a status symbol on the service, but also a matter of resource utilization.

I switched from solyoung to sol. Easier to remember and less to type (special thanks to the Twitter guys for help with that.)

Each message on Twitter is limited to 140 characters. As of yet there isn’t a Twitter application which handles the @user feature. Thus, a response to a longer name both costs time and characters. Another Twitterer I follow (you should too, he’ll change your life) is braverydanger. That’s thirteen characters (or fifteen including the @ and a space.) A response to jack or iofy with the @user feature costs six total characters, allowing 6.7% more room for a response.

This becomes even more important on a mobile phone when typing the extra characters could cost an additional twenty or more seconds (assuming a typical numeric keypad w/out T9 input.)

The switch meant losing all my previous followers (name changes are bad news for brand recognition.) It also meant getting my tweets over to the new account. Both are worth it since I’m young in the game of blogging.

(note: Twitter’s API saved the day. To copy the tweets from the old account to the new account I screen-scraped the old posts and wrote a shell script that imported the scraped posts in reverse order with do/curl/while. Fifteen minutes of coding.)

Now… If only the guys at sol.com would let me pick up that domain for less than the quarter million they quoted last time ;)

Posted in Blogging, Etiquette, Twitter

XMPP stands for scalability

Posted on by Sol Young with 3 Comments

XMPPCart sent me a link to Matt Tucker‘s latest blog entry over at Jive Software, “XMPP (a.k.a. Jabber) is the future for cloud services.” Matt is right. Cloud architectures and large systems are moving away from the current HTTP / web services integration.

M1 AbramsMonstrous servers and clusters banging on each other, effectively pulling web pages in order to deliver another web page elsewhere, is like having M1 Abrams tanks outfitted with BB guns instead of cannons.

At iofy we’re using web services with HTTP. We don’t like SOAP, but we’re RESTfully clean. Our web services API is unintentionally somewhat like Twitter’s API. However, there is a key difference. We use callbacks.

Callbacks allow partners to integrate with iofy’s web services without having to poll for updates. Both Yahoo! and Flickr do this for integrating customers.

We’re similar to Yahoo! in that the stores we power, such as The Language Stop, do not require persistent connections and would be inconvenienced by needing to implement anything larger than web service integration.

In order to keep things simple and fast (and not destroy your architecture with a polling only API) offer callbacks on top of polling. Any mid to large partner, or technically savvy smaller partner, will prefer the callbacks.

Posted in iofy, Software Development

Performance is everything

Posted on by Sol Young

The recent debates about Twitter’s performance has me thinking about iofy this weekend…

Way back when I started at iofy we had the challenge of creating PC and PocketPC applications that played secure audiobook content, displayed table of contents meta data and bookmarked. The applications needed to be under 200k, run on a 200MHz processor and be stable.A latent requirement was that the applications, to satisfy our reliability requirements, had to be statically linked so they could run from a chip without handling varying customer system configurations. Statically linked Microsoft libraries and our code within 200k in a real application. What?


Optimize, optimize, optimize.

iofy download iconNow we’re launching our download service which takes our original offering from a single chip on a single computer (or player) to a service which offers downloadable audiobook content.

There are more performance areas to optimize than you can shake a stick at (client, servers, db access, feed syncing, backups, etc). We’ve stuck to standards and performance as principle design requirements (and we’ve swung intelligently with big sticks.)

As we roll out iofy’s download technology I’ll touch on standards we’ve stuck to and how they may apply to you. I’ll be touching on performance considerations we’ve addressed, especially with feed synchronization. There will be pointers on how you can best integrate your eCommerce system with iofy’s API to offer downloadable content.

This is an exciting time for our engineering team at iofy. We’re seeing our latest hard work make its way to the mainstream.

Posted in iofy, Software Development