‘Flow’ – day 7 – My Twitter thousands

Day 7 – The flow rises, but as it gets faster I just want more… I wonder what Scoble‘s flow is like…

Here are my previous flow entries so you’re up to speed:

Volcano Magma

I’m visiting my in-laws this weekend so haven’t been spending much time in the flow this weekend. However, even with short stints I’m finding a recurrent issue. Each day I think I’m going to hit a maximum number of people I can pay attention to. Each day I’m proven wrong. There’s an adaptation that takes place.

I’m following almost 3,400 and it’s working very well. I could imagine 5,000 being more than comfortable. Even on a standard IM client, the data flow is manageable. Most IM clients don’t smooth scroll, so it’s annoying to have each incoming tweet snap prior tweets upwards.

I’ve been thinking of the outline for a high-traffic Twitter client spec:

  • XMPP for tweet flow.
  • Web Services harnessed for contact management.
  • RSS/Atom integration for pulling articles from Twitterer.
  • Caching of existing Twitter contacts to embed information in to the XMPP traffic.
  • Search and real-time filtering.
  • Ability to only show tweets with links.
  • Additional filters based on: Age of Twitter of account, Location, number of tweets, ratio of following/friends, has non-default avatar, has non-default twitter design… with real-time color-coding of tweets.
  • Ability to favorite a tweet that came through XMPP.
  • Auto-pull of a Twitterer’s most recent blog entries (requires a scan for RSS feeds on the Twitterer’s home page, then pulling/parsing those items).
  • Auto-addition of Twitterer’s RSS in to Google Reader or other items.

With the above, one would have a complete Twitter news-room. One could immediately see what’s flowing and have access to a Twitterer’s additional information. This may be possible with a Flash or Java application, though I’d prefer a highly portable objective-C or C++ app. Maybe even ported to mobile clients (maybe, maybe).

Sharing the love with Google Shared items

Google Reader ImageLove

Google Reader has a great feature for sharing articles. It’s been a terrific way to share interesting and pertinent information affecting iofy and to give like-minded folks easy access to my favorite RSS feeds.

You can access my shared page here.

Or pull the feed here.

And with any luck, a drop of the most recent items will be on the sidebar of my blog… Sharing is caring.

iPhone SDK – Favorite question in the press Q and A – Apps easy to get on the iPhone

CHiPsI was very pleased by a question in today’s press Q&A at Apple’s iPhone SDK release announcement. I posted the other day about the iPhone SDK being in development since before WWDC ’07. The question pertained directly to my thoughts, “Why did you change your mind about the iPhone open SDK? How long will apps be vetted before being published?” (actually, two questions).

Steve answered, “We change our minds a lot. The web apps have worked well, but developers wanted to do more. And we heard that. Creating an SDK is a lot of work, you want to make it something you can live with for 20 years, and yet update it without breaking apps. This is an elegant and clean system.”

I’m certain Apple had the SDK in development since before WWDC ’07. As Steve said, it takes a long time to develop an SDK. They just weren’t ready to announce it yet last year and covered by offering web apps. Their marketing machine and product release practices entice us to want more. We hated Apple last summer for it!

The remainder of the question was handled by Phil, “Second question. Electronic submission will be very fast, and this is a whole new process.”

A lot of people are screaming bloody murder about Apple controlling this process. While I don’t really like the idea of only getting Apps installed via Apple’s system, it could be a lot worse. Apple will be CHiPs, not the DMV. There will undoubtably be apps which make it possible to download and install while being untethered anyway.

The impression I got during the sign-up process to develop for the iPhone and download the SDK was impressive. Not because of the smoothness of the process (I hit terrible snags due to the server congestion), but because it’s obvious they’re going to allow developers to easily publish apps. What I got out of it is they’re making it better and easier to write software for the iPhone than for Windows Mobile or other handhelds. Apps will be as easy to publish as an album of music… Same model.

Dave Winer has been leaning towards the negative side of Apple’s plans, but he likes the idea of an untethered podcatcher. I’d love to talk to him about that… It’s something I expect iofy to work on.

iofy is hiring

iofy

We need a PHP programmer to join the dev team at iofy corporation. This is a full-time, based in Philadelphia, position.

The corporate version of the ad is on Craig’s List (also available after the jump).

If you’ve read this far you’ve probably laughed your ass off double-taked, “Philadelphia!?” … You’re right to do so. But seriously, we’ve grown in to a fast and agile web technology company in the heart of 19112.

Our work environment makes for a great life experience. We hire intelligent people capable of solving problems and enhancing the skills of those around them. People working at iofy are treated very well, with plenty of snacks and gadgets to keep mind and body entertained. The challenges we address both answer a need to paying partners and expand the knowledge of our teams.

In case you haven’t been following my blog, iofy builds web services to deliver media on the web. We harness our own services with AJAX and client applications on nearly every platform.

Drop a note with your resume and a unique statement of talent to developer@iofy.com if you’re the right fit. We love smart people.

Continue Reading

RESTful Documentation

iofy

As promised (but late as a post), we released iofy’s RESTful documentation. This is extremely exciting for both our development and management teams. We now have an open account management API enabling others to offer iofy’s account management and access to a customer’s digital libraries of downloaded audiobooks.

I’m proud of this accomplishment.

The iofy RESTful API covers the features for partner or reseller to offer downloadable audiobooks. These RESTful web services use standard REST calls, are language agnostic, retrieve RSS 2.0 feeds and enable:

  • product listing and search
  • account management
  • financial management
  • purchase and checkout

One can receive dynamic product feeds from ws.iofy.com/product/, where search parameters can include title, author, publisher, narrator, ISBN, and more. These feeds come complete with thumbnail image enclosures, MP3 audio sample enclosures, and all the metadata.

Via account management, described last week, customer accounts can be created, modified, password reset, and most importantly the customer’s prior purchases become available in a library. One can offer this digital library and account management solution without building it (or maintaining it). Just harness it.

The fulfillment API allows assignment of a digital download in a single call. We included PHP sample source code, but it could just as easily be harnessed in any other language.

JavaScript and PHP sample code is available which allows complete harnessing of both APIs. To learn more, email developer@iofy.com.

iofy td: RESTful API
iofy td: Fulfillment API