With Hackday.TV almost upon us I decided to spend the day building an app on our (shelby.tv) newly minted (v1 at least) data and player API.
To jump to the punchline you can see the app here: http://eleanor.herokuapp.com
The app, Eleanor, is designed to show you your recent unwatched video from Shelby. A simple task. That video could be coming at you from Twitter, Facebook or Tumblr while the video itself could be coming from YouTube, Vimeo, College Humor, Blip.TV, Dailymotion, TechCrunch, or Hulu.
There are several components that are down in this app: authorization, accessing the data, and displaying the video.
1) Our attempt was to implement a vanilla three legged OAuth procedure. I had some issues with rails 3.1, heroku, and the Omniauth Ruby gem playing nice with each other, so in the end I improvised, code snippets found here (Gist by Dan)
2) Our data API is very well documented with a live Web console to test authed API calls (great job Myles). Again, wrapped up the code from Eleanor into another code gist that can be found here.
3) The last piece to this app is the Shelby JavaScript player API that allows us to programmatically play individual videos as well as control volume and toggle the playback state of the currently playing video. This all happens client side and is what I think is the most interesting.
The Eleanor App can load video from any of the video providers listed above and with one set of calls can control that video. Load it, play it, pause it, mute it, and load another video all over again, from a totally different provider if need be.
This is one video player to rule them all.
eleanor.herokuapp.com : It’s not the prettiest app but it pulls from the shelby data api and serves up that video which is from multiple providers, all in one video player experience!
<eom>
I recently spent some time learning a bit of node.js, OAuth, and several well know API’s (twitter, tumblr, and more). Learning a “new” language or framework is hard enough, but when you throw in dealing with authorization and responses from 3rd parties (AND shoddy internet) things get really messy!
Case in point: In working with the newly released v2 of the Tumblr API, I repeatidly kept getting 401/unauthorized responses whenever I tried accessing my Tumblr Dashboard. I tried several things, all turned up nothing :(
Even more frustrating: I went back to my roots, Ruby, and everything worked fine! I could get my dashboard, post things, the works! Something was wrong in the node-oauth module and its communications with the Tumblr OAuth Provider.
After days of messing with things (oh so many things!), I found myself diving into the oauth headers that the node module created and compared them to the ruby oauth headers. It turned out that there was a whitespace after the comma the ruby implementation and not the node implementation. A !#!?!’ing WHITESPACE. All other API’s I tested didn’t require that whitespace but Tumblr did. Argh!
Fork. Update. Push. Test. IT WORKED!
I also have recently spent some time building an OAuth provider. The “provider” is responsible for creating consumer key’s and secret’s for 3rd party applications to begin the “dance” that allows 3rd parties access to a users data via an API. Building this, I definitely appreciate the complexities surrounding small details such as commas in headers.
Tumblr did a great job in pushing a fix for this within a few days after I let them know. And I now know to check out for this in the headers my OAuth Provider generates. Sometimes being SOOOO strict is not a good thing… especially when you want people building with your shit!
Stay tuned to learn about the “building an OAuth provider” adventure. That was a doosie! (yes I just used that word!)
Uber powerful looking Ruby gem
This is AWESOME! What a great way to learn and play with AJAX!
