iofy has a subscription to the O’Reilly Safari. It allows complete online access to O’Reilly’s entire line of books, as well as books they still have in the works. As a tech company, we thrive on this.
Lately I’ve hooked up bookmarks on my iPhone to titles I like. At any time, a single click lands me in the book I left off on. It’s far more convenient to have books in a pocket, on a device one already keeps on hand, than to carry around a Kindle or hardback.
Continue for full-size screenshots…
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.
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.
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.
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.
Kevin Schelkun finished the first in a series of how-to videos for iofy’s new hardware player. Check it out and see how easy it is… 30 seconds. The video makes me want to find one and listen to something.
We’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.
Wow, what a week to be in the media industry. Yesterday with Amazon picking up Audible, and today with Microsoft’s bid for Yahoo!. It’s consolidation-for-growth time.
Audible is Apple’s provider for Audiobooks. Having Amazon, a primary competitor to Apple, pick up the company makes for some interesting times ahead of us. Will Apple continue to use Audible as its audio backbone? How about Amazon’s plans for Audible content and its distribution? What is the industry response? The conversations amongst my team and co-workers didn’t stray far from those questions yesterday.
And now today, with Microsoft finally taking the plunge and offering real money for Yahoo!, Inc, we’re in for some more great questions. Yahoo! has more users than any other service on the Internet. That part is interesting and you’ll see plenty of articles on the sale being all about Microsoft trying to compete with Google, but I’m more interested in Microsoft’s use of Yahoo! Music and their massive amount of users for that service.
Ian Rogers heads up Yahoo! Music and is accurate and honest about the direction the music industry is headed. If Ian’s views are as accurate as I think they are, and if the rumors of Yahoo! Music moving towards offering music for free are true, there are certainly more game changers coming.
I’m excited as hell for this to come true (if and when it comes true.) iofy corporation is a technology company which builds the backbones for delivering content. These changes are going to offer great opportunities for us as a small and agile company.
What a great way to end the week!