Blog integration of Twitter starred items

Dave Winer has been asking in Twitter for a way to incorporate specific twitters/tweets in to his blog over at scripting.com. My suggestion is to use the starred items feature (Favorites) on Twitter.

I too would like to integrate Twitter more selectively in to my blog. Twitter’s API, under “Favorite Methods” allows you to set specific tweets to be starred, or favorites.

If you want to want to have a set of targeted tweets which you’ll highlight in your blog, star your own tweets and pull the feed (here’s their RESTful documentation for how to do that):

favorites

Returns the 20 most recent favorite statuses for the authenticating user or user specified by the ID parameter in the requested format.

URL: http://twitter.com/favorites.format

Formats: xml, json, rss, atom

Parameters:

  • id. Optional. The ID or screen name of the user for whom to request a list of favorite statuses. Ex:http://twitter.com/favorites/bob.json or http://twitter.com/favorites/bob.rss
  • page. Optional. Retrieves the 20 next most recent favorite statuses. Ex: http://twitter.com/favorites.xml?page=3

In other words, with the above documentation, you would just pull the RSS feed for your favorites and have it rendered on your blog. This method works best for me since it allows after-the-fact selection, addition, and removal.

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

iofy account management – Really Simple Development

 

iofy software

My dev team is prepping the release of our REST / RSS / JavaScript based account management this week. It marks the completion of building, then harnessing, a suite of RESTful RSS 2.0 feed based web services. The idea has been “avoid people wasting time, working on stuff they suck at focus developers on code they enjoy and excel at.”

We had problems with our 1.0 account management. User interfaces were tied too tightly to the back end. Heavy hitting framework and server programmers were working out UI kinks while artistic graphic designers were figuring out database calls. This was a huge waste. The site looked heinous and didn’t work the way we wanted it to.

Graphic designers don’t think in OO, let alone big-O. Server programmers don’t communicate visually.

Serial

It seems easy to fix, right? Just have heavy hitters do hard stuff and then have graphic designers make it look pretty? Make it look pretty first, then tie in the hard stuff? Not exactly. It requires a lot of planning and effort to coordinate and manage people’s time like that. It also requires serial development where people are waiting before they can start. All of which is a waste – this needs to be automatic and parallel. Don’t waste time trying to manage this if it can be done for you.

Enter REST. Enter RSS.

RSS (Really Simple Syndication) came first. Dave Winer, back in ’98, grew it from XML. It allows for simplified packaging of data. One can package and list blog entries, offer an MP3 playlist, send table-of-contents information, or transport code via codecast. At iofy we use it as a container to package web service responses.

RESTful development is also based on simplicity (here’s a great doc on REST). Get things done in an HTTP packaged call. With a very simple request in JavaScript, the web service is queried and you’ve got an RSS feed as a response. Our designers have their functionality via web services. Our server coders don’t touch the front end.

The server developers make the RSS feeds. This makes them happy and gives them time to build the critical server components. The graphic designers use JavaScript to call iofy’s RESTful Web Services API (link coming Monday). We use jQuery as our base JavaScript library. It’s damned fast to dev.

This simplified my project management. Tasks became clearly defined. In the beginning I was worried the approach would put a wedge between roles, but it worked in reverse. People understood the importance of their own functions and became reliant on each other for success.

Parallel Development.

Parallel

While the design team determined a desired look and feel, the back end team planned architecture and database schema. As feeds were developed and APIs took shape, so did the layout of the site. When feeds became ready for harnessing, pages were ready. Management of the nitty-gritty became unnecessary.

We launch account management this week. You too can harness it in your language of choice (we’ll provide JavaScript code which lets you do this simply by dropping some .js on your page and a script on your server). iofy’s services are controllable from your own site.

iofy’s development team builds client software, web sites, and web services powering audiobook content delivery. We move content securely from server, to client, to iPod, and SD chip. 

Yahoo! – components that matter to me after no search

YGMThe news of the week (month/year?) is the $44.6 billion offer from Microsoft to acquire Yahoo!. Robert Scoble blogs the intelligence of Google’s email and Dave Winer drops thoughts on Yahoo’s options based on TechCrunch blogger Mike Arrington’s analysis. Mike Arrington’s latest news is a bit disheartening. Either sell to Microsoft or sell their search to Google.

Yahoo! has a lot more than search to offer – it shouldn’t be their primary business. As Scoble and Winer both pointed out, the wars are being fought on platforms – Especially the mobile platform. Yahoo!’s Go service synchronizes calendars, contacts, etc, from phone or PC and runs on Windows, OS X, BlackBerry, Symbian (Nokia), and Windows Mobile. Heck, it runs on almost every phone out there and OS X has Yahoo Sync built in. It’s been over a year since I’ve synchronized my phone by wire and I’m able to keep three phones and two laptops in sync.

Dave Winer shares insight from past technology wars while asking which platform will be adopted as the standard for synchronization of contacts, social networking, etc. I argue it could be Yahoo!. They’re embracing OpenID and offering Pipes. The Go service has plugins which tie in to MySpace and other social networking sites. They’ve got an identity system, a delivery method, and a decent reach in to the mobile market.

Finally, Yahoo’s two destinations – Yahoo! Music and Yahoo! Finance. These two are both number 1 in their class. Numero Uno. Why? They have content. Google offers search – when you’re looking for content. Yahoo!’s Music and Finance (and other sites) have that content.

These are the Yahoo! products that matter to me and the reason I’m a Yahoo! shareholder. If the sale goes through I’ll happily cash out with a profit and start looking elsewhere for services that satisfy consumer need.

Harnessing a web service API with JavaScript – use the three-peat to avoid DNS failures

iofy download serviceWe’ve recently done work harnessing our iofy RESTful web services in JavaScript, especially the account management sections. Typically, in old-school fashion, an account management system is done server side with PHP, PERL, Ruby, etc, interacting with a database.

<sarcasm>That’s great when you want your heavy hitting developers to do design work or when you want your designers to do low-level work (or if you want to add a layer of management to your project where you need to separate out what parts of a page are owned by what developer/designer.)</sarcasm>

Why give yourself that headache? I had that headache for a while and have a direct solution. REST + JavaScript. My heavy hitters delivered RESTful functionality for our API that can be harnessed by pretty much anything capable of HTTP. My webmaster and designers can now, purely in JavaScript, harness this API and deliver all the functionality they need with all the gorgeous style they possess.

You can too (drop us a note and sign up as a reseller.) Our API is REST and we’ve got JavaScript libraries for harnessing it. The JavaScript queries the web service and receives an RSS 2.0 response. Parse it, and you’ve got everything you need for account management, content delivery, sales, and reporting.

Now for the difficulty in JavaScript web service API harnessing… The big surprise we ran in to initially was with the failure rate of HTTP requests from client-side JavaScript calls. DNS stinks. We would make requests and randomly get failures. As it turns out, DNS will fail between 1% and 3% of the time on a typical DSL connection. You need to retry that connection…

I recommend the three-peat for failed connections. In your JavaScript (or any other language), use asynchronous calls to a function which will repeat the HTTP request up to three times before erroring out. This reduces the likelihood of failure to a cube of the failure rate.

The worst DNS providers fail 3% of the time. Therefore the first request has a 3% chance of failure. The second has 0.09% chance since the 3% that failed are 3% likely to fail again (3% multiplied by another 3%.) The third try won’t fail unless something bigger is going wrong, drops the chance to 0.0027%. This is far more acceptable than 3 in 100 and effectively removes the DNS issue of web service connections.