On Thursday I presented at the DC API meetup alongside Gray Brooks of GSA, Tim Herzog of the World Bank, Kin Lane of API Evangelist, and former White House Innovation Fellow Ben Balter. Our panel was moderated by Alex Howard of O’Reilly Media.
Ben’s slide deck is here: all the code he referenced is open source. Kin Lane also did a writeup on API Evangelist.
My talk was some high-level points we learned, sometimes the hard way.
On Wednesday, Codecademy launched a full track of lessons on web APIs, and NPR was a launch partner with a course on the NPR API. There was a bit of media coverage.
This entailed weeks of nights and weekend work but it was a ton of fun. For me, it started last November when I met Codecademy’s Sasha Laundy at DC Week. When she said they were about to pilot a track on APIs, I jumped at the chance.
I’ve been a big fan of what Codecademy is trying to do since it launched. The world has a dire shortage of geeks, and they’re trying to make more. I’ve heard a few people scoff that you can’t learn to code just by spending 30 minutes here and there on Codecademy. To be clear — you can become a good programmer *many* ways as long as you’re willing to put in the time and struggle through difficult problems.
But even my argument misses the main point. By removing all of the friction in working with a new technology, Codecademy is betting that a lot of folks who would never have tried programming in the first place will give it a shot. And some of them will fall in love and might even major in computer science.
I have similar aspirations for the NPR API course on Codecademy. Perhaps the next generation of public radio listeners — those who don’t have radios and aren’t yet listening — will fall in love with this quirky open API that allows one to dabble with world-class content in the public interest. It’s important for us to be open and it’s important for us to be out there. Public radio has enough inspiration to share, we need the next generation of coders to help us realize our mission.
I was recently interviewed by Lee Dumond (@leedumond), Nick Berardi (@nberardi), and Dustin Davis(@prgrmrsunlmtd) for the latest Mashthis.io podcast. It was an interesting conversation in content syndication, app development, and using APIs to supercharge a content and platform strategy. 48 minutes is big commitment though, so I timecoded our discussion topics and added a few links for context. My favorites are bolded.
You can listen here. The audio is a bit choppy because of Skype difficulties. If you hear the same thing mentioned more than once, it’s probably one of our retakes.
Update 10/23/12
Nick Berardi asked a really important question on document databases vs. relational databases, and I didn’t answer it as well as his question deserved.
Nick noted the trend that organizations tended to have one relational database but that the document DB trend was “pick the best one for the job.” This is a hugely important insight, and there are two intertwined reasons: the intrinsic nature of the tools themselves, and the shift away from traditional client-server architecture to SOA/API-based architecture.
Document databases have so much variability between one another that you really have to pick the best tool based on the capabilities you need vs. the tradeoffs you’re willing to make. They differ by query capability, ACID compliance, clustering, retrieval speed, etc. On the other hand, traditional SQL databases might have 95% overlap, and you’d think that would make it easier to switch between them, but that last 5% has been so relied upon traditionally that it made lock-in the logical choice. Proprietary SQL syntax, stored procedures, or in the case of SQL Server DTS have traditionally been important features for querying and transforming data, and if you wanted to take advantage of them, you needed homogenous architecture.
That’s a good segue to the transition to data services — in our case, RESTful APIs. With standard interfaces you can untether yourself from uniform infrastructure. Your data services may not actually run as fast as if you were syncing databases with proprietary services, but you’ve given yourself more flexibility to pick the best tool and move quickly. Every shop has its favorite tools, but we’ve already used both CouchDB and Redis on small internal services and can see us picking up another document DB here and there as needed.
Beyond flexibility, there’s a lot to be said about developer happiness and productivity. Both come from exploring new tools and picking the right tool for the job. That’s worth a lot.
2:00 – Is NPR a truly digital system or a radio system with a digital presence?
4:14 – Getting 100+ local stations into the API
7:20 – What kind of APIs are under the hood in a mobile app?
9:50 – The challenges of streaming audio to mobile apps
13:00 – How has the API changed over the years….
16:40 – How do you decide when to write a new API?
19:40 – How do you keep up with documentation.
20:55 – Technology: hosting and programming languages
23:00 – Would we stay on PHP? How do we get more API speed?
25:50- What is this drupal project?
29:00 – ElasticSearch + Document database.
31:15 – More on NoSQL databases
32:42 – The future of connected cars. Will there be a standard among manufacturers?