Thursday, September 27, 2012

Just a Few of the People Speaking at the API Strategy & Practice Conference

The API Strategy & Practice conference added 15 speakers to their API industry event November 1st and 2nd in New York City:

Jakub Nestril from Apiary (@jakubnesetril)
Mike Reich from Cumula (@therealreich)
Matt Bishop of ElasticPath
Travis Reeder of (@treeder)
Miko Matasumura of Kii (@mikojava)
Tyler Singletary of Klout (@harmophone)
Amit Jotwani from Mashery (@amit)
Irakli Nadareishvili, NPR (@inadarei)
Mike Swift of Sendgrid (@SwiftAlphaOne)
Andrew Mager ♫ of Spotify (@mager)
Ross Boucher of Stripe (@boucher)
Tony Tam from Swagger (@fehguy)
Jason Loup from Temboo (@jasonjloup)
Max Katz of Tiggzi (@tiggzi)
John Bunting from (@codingjester)
Mehdi Medjaoui from Webshell (@webshell_ )

It's a nice lineup of API providers across industries from payments to API automation.

from API Evangelist

Tuesday, September 25, 2012

Tumblr Launches New Github Site

The Tumblr engineering team has been hard at work on a new Github page, showcasing the open source projects they've released.  

Tumblr has also added a coming soon section, highlighting open source projects they are planning on releasing in the near future.

What's interesting is they have also included select presentations from conferences and events Tumblr has presented at

The Github implementation by Tumblr is pretty unique, and to go even further, Tumblr has also open sourced their whole approach to deploying it on Github.

Tumblr's use of Github is worth showcasing.  I think it's an innovative approach that other API owners could follow to showcase the open source project they are working on, as well as valuable event presentations.

I'm really impressed with the number of innovative uses of Github I'm seeing lately.

from API Evangelist

API Strategy & Practice + Defrag

When you spend a lot of time going to conferences, hackathons and events, you start really getting picky about which events you go to. To disrupt my regular routine, I need an event that will always add value to my professional career, but also be a good time!

When it comes to the latest in Internet technolgy, I always make time each year for the Gluecon and Defrag conferences. Gluecon is usually in the spring and Defrag is in the fall--both occurring at the Omni Interlocken in Broomfield, CO.

Defrag is coming up November 15th and 16th--right after November 1st and 2nd for the API Strategy & Practice in NYC.

API Strategy & Conference is psyched to be partnering with Defrag in our first year. If you register for API Strategy & Conference, you will get 10% off of your registration for Defrag.

The event combination will make November a great time to immerse yourself in the API industry, with API Strategy & Practice Conference, then two weeks later, go further with Internet technology discussions at Defrag.

I look forward to seeing you at both API Strategy & Practice Conference and Defrag in November! 

from API Evangelist

The Best Team Page Ever!!

When it comes to any business, you want to showcase your team, and the value they bring to the table.  

One of the things I do here at API Evangelist, is showcase great examples of technology across the API industry.  

With this in mind I wanted to showcase the Singly team page.  When you visit and click on team in the footer, you get immediately see a team member photo carousel:

Which isn't very unique, but next you get 3 things that are unique:

  • Average number of hours each Singly team member slept this week
  • Number of Github commits in the last 7 days
  • Distance walked by Singly team members

Singly team members provide this data using Quantified Self (QS) data from products like Fitbit and Runkeeper, and social programming networks like Github--driven by APIs.  

Next Singly shows a map of their neighborhood in the San Francisco mission district:

Then they wrap up with Instagram photos from team members:

The Singly team page is the best company team page I have ever seen.  It shows extremely personal data from their Fitbit and Rukneeper devices, as well as the day to day business of code pushes via their Github accounts. The team page also shows you where the team is located and some Instagram photos to help you get the vibe of the team.

What does your website team page tell about your companies team?

from API Evangelist

Sunday, September 23, 2012

API Issue Management With Github

Github should be the center of your API operations, with the most obvious use being for SDK repositories, but Github offers a lot of other valuable tools that you can use to help manage your API platform.

One great use of Github is as an API issue management tool.  The Github issue management system allows you to easily accept issue reports from your API community and apply labels to organize them into appropriate categories.

To setup Github Issue Management for your API, just create a new repository, but you won't actually being pushing any code, you will just be using it as a container for running issue management.  Think of it as repository for your API itself.

Once setup, you can link the issue management page directly from your API area, allowing users to actively submit issues, comment and potentialy be part of the API product development cycle.

Along with API Issue Management with Github, you can link issues with the milestones portion of Github, providing deeper roadmap integration, but I will cover that in a separate post.

from API Evangelist

Friday, September 21, 2012

Pulling a Federal Agencies Digital Strategy

Back in May, when the White House CIO has released a strategy, entitled "Digital Government: Building a 21st Century Platform to Better Serve the American People", which directs all federal agencies to publish HTML, JSON and XML versions of their digital strategy, I wrote a PHP script to monitor the progress. 

To date, 25 federal agencies have successfully published their digital strategy, and I have been updating my script regularly to keep up. And while a few of the agencies still have querks with their HTTP Codes and with JSON formatting, the code is starting to stabilize.  So I decided to start sharing it on Github, allowing others to put it to use.

The first sample script I'm publishing is a basic example of how to pull the JSON version of a single agencies digital strategy.  Once it pulls the JSON, it then loops through each item and field on the strategy, and renders to screen.  It doesn't make any assumptions on what you wish to do with data.

Next I will publish a more sophisticated version that stores values in a database.  Here is the pull federal agency digital strategy PHP script:

from API Evangelist

Tuesday, September 18, 2012

Simple API Developer Tracking Framework

When you have an API, you track two things: 1) Number of Developer Registrations and 2) Number of API requests. This is how we determine a successful API, right?

You should track those two things, but those metrics alone do not define a successful API. You should go much further. Each API owner will have their own definition of success, thus their own set of metrics to measure success.

With this in mind, there is no single framework for measuring your API, but here is one suggestion for a basic framework to think about when tracking your API developers.

First establish some buckets to put users in:

  • New - Brand new developer
  • Active - Developer actively using API (come up with number)
  • Inactive - Developers who go below the "active" number threshold for X number of days
  • Billable - Developer who is paying you $$
  • Partner - A developer who are working closer with than rest of developers
  • Internal - Your staff or contractors who actively use your API, even for testing

Then make sure and flag each user with a timestmap when they change status:

  • 5/2/2012 - New
  • 5/2/2012 - Active
  • 7/9/2012 - Billable
  • 8/15/2012 - Inactive

I like to generate daily, weekly and monthly counts for each bucket, plus see numbers on the churn between buckets.

Looking at developers in buckets, and tracking on their transitions between buckets allows you to start seeing the big picture, when large groups of users are migrating between status, or the individual picture, like why a single developer just went inactive.

I don’t see much to learn from just watching new registrations and number of API calls, but by creating meaningful buckets to place developers in, then understanding their evolution between these buckets, I think you can learn a lot with a pretty simple set of metrics.

from API Evangelist

Will Your Company Be Found In a Siri Search?

I’m currently processing several discussion I’ve had with folks about APIs and the future of search when it comes to voice enabled apps, like Apple’s Siri.

It started with a discussion with the Webshell folks about their blog post, Webservices supply chain management : the SIRI case. Next I was reading a presentation from Pat Cappelaere(@cappelaere) CEO of Vightel Corporation. called Building Tomorrow’s Web Services API.

Pat has an interesting image in his deck, showing who the next generation consumer of your API will be:

These conversations reflect a whole new area of consideration for the future of web APIs. Will voice be the dominant way to search via our mobile devices? If so, how do we expose our companies resources, in a way that makes them easily consumed by voice enabled apps?

At the simplest, we need to discuss where REST fails us in this scenario, and at the most complex we need to discuss what “activities” will be consumed by voice apps and what types of “supply chain management” processes or framework will we need to manage all of this.

All of this will feed into to whether or not your company, its products and services will be found in a Siri-like search, when voice enabled apps become the default.

from API Evangelist

Generate API Server, Docs and Client Code Using Swagger

We all have our own approaches to API design and development, many of which will never see the light of day. In the API space we hear a lot about API management and API success stories, but not much about the process of designing, developing and initial deployment of APIs. I just had a little taste of how the Wordnik team approaches it, using Swagger.

Often when you hear about Swagger in the industry, you hear about the UI portion. You know the sexy interactive documentation that is fast becoming a standard with APIs, but it’s just the tip of the iceberg--there is a whole lot more power to Swagger, than just interactive docs.

“The heart of Swagger is the specification, and from that, cool shit can get done!”, say Tony Tam Wordnik CEO and technical co-founder.

To demonstrate, Tony walked me through Wordnik’s approach to designing, developming and deploying a new API driven iPad app, using a team of 3:

  • One person driving an editor writing JSON files, which are the Swagger spec for the needed API
  • The all three discussed the operations, parameters, while adding them to the JSON, and re-running the swagger spec validator after each meaningful change
  • When they were happy with the specs, they loaded the JSON files into the UI through apache installed on a local machine
  • After they inspected each API and operation again, they wrote the models in the spec files, and reviewed again to make sure everything was good
  • Then they ran the Swagger Codegen and generated a Scalatra (Scala) server from the spec files
  • Then they ran the Swagger Codegen and generated an Objective-C client from the spec files
  • The server developer went off and wired the server to the business logic
  • The front-end guy went and wired the UI to the objective-c library

The process took 2.5 hours in total, from API to interface--a technique they call interface-driven development, which focuses on modeling the perfect interface for the problem they are trying to solve using an API.

To solve this particular problem, they needed a scala server for the back-end. they could have just as easily generated a Node.JS server, a Rails Sinatra server or any other based upon simple mustache templates. Additionally they could generate JavaScript, Scala, PHP or Python clients, but for this project they only needed Objective-C.

The Wordnik approach to API design and development using Swagger is interesting. For me, it demonstrates that a clean API spec should not be an afterthought, and a means by which you generate interactive API documentation, or when API discovery becomes an issue. Your entire design, development and management process should center around a meaningful API spec, which will then allow you to deploy your API server, interactive documentation, client code, while also providing API discovery.

from API Evangelist

Monday, September 17, 2012

An API Driven Quantified Self

I’m immersing myself into the fascinating new world of the Quantified Self (QS). If you are not familiar with what QS is, according to Wikipedia:

Quantified Self is a movement to incorporate technology into data acquisition on aspects of a person's daily life in terms of inputs (e.g. food consumed, quality of surrounding air), states (e.g. mood, arousal, blood oxygen levels), and performance (mental and physical).

As I do with other areas, I start my research by doing a roundup of companies who offer QS products and services--which helps me define the space. Within an hour I easily found 50+ QS device manufacturers, some of which were complete with API driven integration platforms-- way too many to list in a single roundup, but here are a couple of better known companies:

  • Fitbit - Fitbit is a health and fitness tracking device
  • RunKeeper - Runkeeper is a device for tracking, measuring, and improving your fitness
  • Withings - Withings provides connected body scales, blood pressure and baby monitors
  • Zeo - Zeo has sleep tracking and management devices and apps

These QS platforms represent a whole new opportunity for the API industry, one that will drive the next generation of healthcare innovation. Self-quantification starts with data collection, followed by visualization, then cross-referencing and the discovery of correlations--all three opportunites for APIs.

Devices can use APIs via cell and wifi to transmit data for collection and storage, while also allowing app developers to use the same APIs to help end-users manage and visualize their data. Then, when appropriate, use the same APIs providing access to other systems and providers who can then cross-reference and discover correlations within individual or groups of users.

It is exciting to think about the possibilities around QS. New ways to gather data about our health and the environment around us in real-time, but also be able to understand this data in the most meaningful way possible, in a way that impacts the most important thing to us--our health!

Devices + APIs + Cloud = Exciting Opportunities!

from API Evangelist

YouTube Moves API QA to Stack Overflow

YouTube has decided to cease support for Youtube API QA via dedicated Google Group, and exclusively use Stack Overflow for developer QA support.

Every developer knows that Stack Overflow is where you go to get the best answers for your programming issues, and API providers are taking notice too.

Stack Overflow has always been something I recommend paying attention to for any API evangelist, but more API providers are considering it be the place where all API developer QA should exist.

Facebook, Foursquare, and Salesforce have all moved their API developer QA to Stack Overflow.

These API providers are still maintaining other API support building blocks like bug ticket systems, email and Twitter accounts, but when it comes to public developer forums they feel that Stack Overflow is enough.

While I think having a active presence on Stack Overflow is a critical part of any API evangelism strategy, I’m not 100% sure eliminating a dedicated forum is the right way to go. I worry you will push developer community completely out on the open Internet, reducing interactions that happen under your brand.

With the size of their developer community, larger APIs often have canyon that exists between them and their developers, and it’s easy to widen this canyon by moving general QA exclusively into an open Internet forum.

I don’t think it’s that much more work to monitor and respond to your community forum as well as Stack Overflow, and even add in Quora, Reddit, StumbleUpon, Google Alerts, and other ways of monitoring the API and developer landscape.

from API Evangelist

Thursday, September 13, 2012

Fireside Chat with Albert Wenger at API Strategy & Practice

We are at an exciting time right now with the API Practice & Strategy conference, where we get to orchestrate the best lineup of speakers, sessions and panels possible.

I just added Steve Klabnik to our speaker line-up and now we are excited to announce we’ll be having a fireside chat with Albert Wenger (@albertwenger) of Union Square Ventures (USV).

Albert combines over 10 years of entrepreneurial experience with an in-depth technology background. As an entrepreneur, he has founded or co-founded five companies, including a management consulting firm (in Germany), a hosted data analytics company, a technology subsidiary for Telebanc (now E*Tradebank), an early stage investment firm, and most recently (with his wife), DailyLit, a service for reading books by email or RSS.

Albert also served as the president of through the company's sale to Yahoo. His technology background goes back to winning the German national computer science competition at age 18. Albert graduated summa cum laude from Harvard College in economics and computer science and holds a Ph.D. in Information Technology from MIT. He has managed technology projects for organizations as diverse as Tacoda (startup) and Telebanc (leading Internet bank).

USV invests in companies that have large networks of engaged users, differentiated by user experience and defensible by network effects, so USV has a vested interest in understanding developer communities, how APIs will evolve, what types of businesses are best suited to an API driven strategy.

The API Practice & Strategy conference fireside chat with Albert Wenger will reflect the tone of the conference, which is a blend of both the technical and business of APIs--providing what is essential for companies to be successful with their API driven strategies.

from API Evangelist

Steve Klabnik Added to Speakers at API Strategy & Practice

I’m stoked to announce that Steve Klabnik will be speaking at the API Strategy & Practice conference, November 1st & 2nd in New York City. I just added him to the homepage and speaker line-up.

Steve is a highly respected Ruby developer, software craftsman, and an aspiring digital humanities scholar. He spends most of his time contributing to Open Source projects, and maintains both Hackety Hack and Shoes, while also teaching and helping develop curriculum for Jumpstart Lab.

Steve has has written book on Designing Hypermedia APIs. Well it’s better than a book. I’d call it a "living digital book". One where you can constantly come back and get fresh content and interact with the books community and author. Much better than the old-school programming book, which you buy once and it sits on your shelf.

What intrigues me about Steve, is that his perspective is very technical, but in his own words, “I've found a place between the sciences and the humanities.” Which is a point of view we need to give a platform to, and everyone in Silicon Valley needs to listen.

Steve is exactly the fresh perspective we want to get at the API Strategy & Practice conference. I hope you can join us for the two day event in November and be there in person for Steve’s talk.

from API Evangelist