Wednesday, April 25, 2012

Tools of the CityGrid Los Angeles Hackathon

We have a pretty awesome line-up of tools, platforms and APIs for people to use when building their local web and mobile apps this weekend at the CityGrid Los Angeles Hackathon:

3Scale (@3Scale) - A Plug & Play Cloud based API Management Infrastructure for Developers, Startups, SMBs and Enterprises to securely open, control, manage and monetize their API to 3rd parties.
CityGrid (@CityGridAPITeam) - Places, offers, reviews APIs and mobile, web and custom advertising with places that pay.
Factual (@Factual) - Places, Products, Health, Education, Government and Entertainment accessible via database and API, with a Resolve API providing places intelligence and Crosswalk API identifying places across multiple systems like Foursquare, Yelp and Facebook.
GeoCoda (@GeocodaHQ) - Simple Geocoding API providing information about any U.S. address via an HTTP API, and a spatial database to store and manage location-based information.
IPGP (@IPlookup) - IPGP is a site that lets users lookup the location of their site's visitors based on their IP addresses.  
Iron.io (@Getiron) - Iron.io provides massively scalable cloud application services:  IronWorker, a massively parallel worker platform and IronMQ is an elastic message queue as a service.
Jeppesen (@JeppesenJP) - Jeppesen Journey Planner is a cost effective way to integrate public transit information into your own website or mobile application.
Socrata (@Socrata)- Open Data Services for federal, state, and local governments to dramatically improve the reach, usability and social utility of their public information assets.
Spire.io (@Spireio) - A real-time messaging service as the first in a set of hosted, secure, and scalable APIs built for mobile and web application development.
Tiggzi (@Exadel) - Cloud-based Builder for HTML5, jQuery Mobile, and PhoneGap Apps, allowing connection to REST APIs, and Export for Android, iOS, or Mobile Web.
Verious (@Veriously) - A marketplace for mobile application components, enabling iOS and Android developers to license pre-built, pre-tested libraries to accelerate time-to-market, access 3rd-party platforms and increase in-app monetization.

The CityGrid Los Angeles Hackathon is sold out, but you can follow the event on Twitter using the hashtag #citygridhackathonLA.




from Kin Lane http://feedproxy.google.com/~r/KinLane/~3/pjUqKqHnIvo/

Tools of the CityGrid Los Angeles Hackathon

We have a pretty awesome line-up of tools, platforms and APIs for people to use when building their local web and mobile apps this weekend at the CityGrid Los Angeles Hackathon:

3Scale (@3Scale) - A Plug & Play Cloud based API Management Infrastructure for Developers, Startups, SMBs and Enterprises to securely open, control, manage and monetize their API to 3rd parties.
CityGrid (@CityGridAPITeam) - Places, offers, reviews APIs and mobile, web and custom advertising with places that pay.
Factual (@Factual) - Places, Products, Health, Education, Government and Entertainment accessible via database and API, with a Resolve API providing places intelligence and Crosswalk API identifying places across multiple systems like Foursquare, Yelp and Facebook.
GeoCoda (@GeocodaHQ) - Simple Geocoding API providing information about any U.S. address via an HTTP API, and a spatial database to store and manage location-based information.
IPGP (@IPlookup) - IPGP is a site that lets users lookup the location of their site's visitors based on their IP addresses.  
Iron.io (@Getiron) - Iron.io provides massively scalable cloud application services:  IronWorker, a massively parallel worker platform and IronMQ is an elastic message queue as a service.
Jeppesen (@JeppesenJP) - Jeppesen Journey Planner is a cost effective way to integrate public transit information into your own website or mobile application.
Socrata (@Socrata)- Open Data Services for federal, state, and local governments to dramatically improve the reach, usability and social utility of their public information assets.
Spire.io (@Spireio) - A real-time messaging service as the first in a set of hosted, secure, and scalable APIs built for mobile and web application development.
Tiggzi (@Exadel) - Cloud-based Builder for HTML5, jQuery Mobile, and PhoneGap Apps, allowing connection to REST APIs, and Export for Android, iOS, or Mobile Web.
Verious (@Veriously) - A marketplace for mobile application components, enabling iOS and Android developers to license pre-built, pre-tested libraries to accelerate time-to-market, access 3rd-party platforms and increase in-app monetization.

The CityGrid Los Angeles Hackathon is sold out, but you can follow the event on Twitter using the hashtag #citygridhackathonLA.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/ZOMsSWwr7AU/

Monday, April 23, 2012

Developers, Take 10 Seconds to Respond When Your API Evangelist Reaches Out

The best thing about owning API Evangelist is I get to write about whatever I want. I have full editorial control, and because of my unique view on the API space I tend to write about APIs from three separate perspectives:

  • API Owner
  • API Service Provider
  • Developer

These are the three main actors in the API game. There are others, but these are the three viewpoints I write about the most. I tend to rail on API owners a lot, and today I think I will rail on API developers.

Currently I’m doing a lot of reaching out to my developers. I personally email everyone who registers for CityGrid APIs. Sure I use template emails, but I customize them and send the email one by one so I can profile my API developers and understand what they are doing.

So far, my findings are that many developers don’t have any sort of verifiable online persona, and even more don’t bother responding when I email or tweet at them. Its not my business to police the CityGrid APIs, but I definitely apply a grade to every developer I look at, and make recommendations based upon this grade, where online persona and responsiveness are two big factors.

We hear a lot of developers (me included) complain about API owners not being responsive, but remember there is another side to the coin. If you're using someone’s API for FREE, and they take time out of their day to email you or tweet at you, it might be cool if you took 10 seconds to respond and say hello, and let them know you're an actual person.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/N5WS9eAYE5Q/

API as the Deliverable at the Hackathon

At most hackathons, the end goal is building a web or mobile application, using various platforms and APIs. Even though I’ve seen this evolve to data visualization, or mashing up SaaS platforms at some events, the app really tends to be the primary deliverable at hackathons.

So this week I’m spending time thinking of unique and interesting ways to present my sponsors for the CityGrid Hackathon this weekend in Santa Monica at CoLoft. One of our sponsors is 3Scale, one of my favorite API service providers, and while we see many of the API service providers including Apigee and Mashery involved in many of the hackathons you really don't see anything built using their platform. (I know they’ll ping me and say they do, but really your building using their clients.)

So for the CityGrid Los Angeles hackathon, I want to encourage developers to come up with ideas for APIs, develop the API and using 3Scale, deploy the building block that are essential that enable other developers to build on top of the API.

Not only do we need more, high value APIs, we need developers to be fluent in not just developing and deploying mobile and web apps, developers need to be fluent in designing, developing, deploying and managing APIs.

So if you have a great API idea and are in the Los Angeles area this weekend, come down to the CoLoft in Santa Monica and form a team and build your API, and deploy it using 3Scale, and you just might have a chance at winning $5,000.00 for your API.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/mCcMo44HCKo/

Friday, April 20, 2012

APIs Are Forever, Wait No...They Can Go Away at Any Time!!!

One of my self-appointed roles in the API industry is to shed light on, and discuss the business of APIs when many other API owners and evangelists tend to keep their strategy and business closer to their chest.

Many API owners don’t discuss their roadmaps, either because they feel they will be giving away their secret sauce, or quite possibly because they don’t have a clue where they are going with it. I think it’s more the latter, as we are all making this shit up as we go along.

One subject you don’t hear API owners discuss often, is when their API will be deprecated or shuttered, leaving developers and tech bloggers to speculate on the subject. Because of this you tend to hear just the extreme views on the subject. Popular perspectives on API life-span tends to be:

  • APIs Are Forever - Once you put an API, you have to support it forever
  • APIs Can Go Away Anytime - There is no stability whatsoever when it comes to APIs

I’ve written on this subject several times including What Happens to Instagram API Developers After Facebook Acquisition and Building Your Business Around Google or Any Other APIs.

Even with my stance on the subject I fall prey to the hype sometimes. I saw the post from Google today called Changes to deprecation policies and API spring cleaning, and I immediately thought oh no, here we go again. After reading deeper I realized they are updating their API deprecation policy for many popular APIs. As they state:

The new policy simply states that we will strive to provide one year notice before making breaking changes.

Google is setting a clear window, for which they will make sure and give developers a heads up before deprecating an API. This allows you to know that you can count on an API being around, until you hear otherwise, and then, you still have a year to figure out what you are going to do.

I know this is something other API owners do, but it rarely is something you hear any news about, giving the API extremists free range to use page view grabbing headlines about APIs owners being no better than satan, and eat their developers for dinner.

I’m going to work on a more formal post about API deprecation policies, and how API owners can put them to use, setting better expectations around API life cycles.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/39Hl6ewJlCg/

Thursday, April 19, 2012

Supporting Encrypted Cloud Storage for Modern Web Languages

As more of our lives move online, into the clouds, encrypted backup and storage of not just our vital data, but our personal photos, files and streams is becoming critical--this responsibility to provide secure cloud storage and backup solutions is up to developers of the software, people use every day.

IDrive is working to provide these solutions for developers by delivering two interfaces for developers to integrate encrypted storage into their applications:

  • Command Line Utility - Develop highly scalable, reliable and fast applications to manage your storage on IDrive EVS. Best for desktop applications and also ideal for CRON jobs.
  • REST APIs - An interface designed to allow developers to easily build web and mobile applications to manage storage on IDrive EVS.

To help support our REST APIs users, IDrive has developed three new libraries supporting modern web languages:

Using these libraries, web and mobile applications developers can provide secure cloud storage and back-up, that works with the IDrive platform. In addition to providing users with secure storage within their own apps, developers can also leverage the entire IDrive ecosystem of consumer web and mobile tools already developed for users to manage their data.

There is no reason to leave users data unencrypted, while storing in the cloud, something security experts warn everyone about, but developers can only do with IDrive. Take advantage of the IDrive web client libraries, and use a secure REST API for storing and backing up files in your PHP, Python or Ruby web application.




from Kin Lane http://feedproxy.google.com/~r/KinLane/~3/u3KuNou5zqI/

Delivery Encrypted Cloud Storage for Ruby Applications

IDrive just finished a set of Ruby samples complete with full library you can use when developing your encrypted, versioned cloud storage for your web application, using IDrive EVS REST API.

With the introduction of the web application framework Rails, the popularity of Ruby for building web apps has skyrocketed. To support Ruby developers, IDrive has added samples to each of the 19 REST API Methods:

You can also visit the download center, where you will find links to Github repositories containing entire Ruby libraries for integrating your web application with all the functionality available via the IDrive EVS REST API.

Using IDrive EVS, Ruby developers can deliver encrypted storage and backup within their web applications, providing security and privacy not available with Amazon S3 and other cloud providers.




from Kin Lane http://feedproxy.google.com/~r/KinLane/~3/Um2QgOc6Lec/

Encrypted Cloud Storage with Python

IDrive now has a set of Python samples complete with full library you can use when developing your encrypted, versioned cloud storage for your web application.

Python is one of the fastest growing, interpreted, interactive, object-oriented, extensible programming language--embraced by giants like Google. IDrive has added samples to each of the 19 REST API Methods:

 

You can also visit the download center, where you will find links to Github repositories containing entire Python libraries for integrating your web application with all the functionality available via the IDrive EVS REST API.

As more of our daily lives move online, encrypted backup and storage will be critical to Python developers, building the next generation of secure web applications in the cloud. Take advantage of the IDrive EVS platform for securing your users data storage and backup.




from Kin Lane http://feedproxy.google.com/~r/KinLane/~3/Fz_UZvihqLo/

Build Secure, Encrypted Cloud Storage Solutions with PHP

IDrive now has PHP samples complete with full library you can use when developing your encrypted, versioned cloud storage for your software solution.

PHP is widely is in many web applications today, so it’s a language we couldn’t ignore. We’ve added samples to each of the 19 REST API Methods:

 

 

You can also visit the download center, where you will find links to Github repositories containing entire PHP libraries for integrating your web application with all the functionality available via the IDrive EVS REST API.

IDrive is the only fully encrypted cloud backup and storage provider, which is a huge opportunity for PHP developers to deliver secure storage and backup for their users.




from Kin Lane http://feedproxy.google.com/~r/KinLane/~3/icjcxR718dQ/

Tuesday, April 17, 2012

Will a Self-Service API Area Ever be Enough?

One of the essential ingredients of a successful API, is a self-service area to support your API developers. In my opinion this is a no-brainer. You have to have registration, documentation, code samples, forum and other essential API building blocks available to developers in a self-service way--so they can engage with your API 24/7 without asking for access.

I’ve worked hard to make sure the CityGrid API area has a logical navigation, taking developers to the essential information they will need to learn about and integrate with the APIs:

With those 13 links you can get to everything you need to know about the CityGrid Places, Offers, Reviews and Mobile, Web and Custom Advertising APIs.

I keep a regular flow of information going through the blog to make sure there is excellent SEO content, so developers can search for anything at Google, and the blog will support linking to whats relevant in the CityGrid Developer Center.

Even with all of this, I still get some pretty basic questions like:

  • I need PHP code samples? - Immediately available on the code samples page.
  • What does the API cost? - Says that it is FREE on Getting Started and FAQ.
  • Can I save your data in my database? - Says it on the Usage Requirements
  • Do I have to show your logo? - Says it on the Usage Requirements

That is just the tip of the iceberg. I’ve posed this question before...are there enough doers in the world to make this whole API vision work? It’s hard to tell if its just my view, while in the pit of despair, or if it is just the way it is.

It seems like there will always be some users who need hand holding, and they refuse to read the self-service material available in the API area. When I’m hacking on an API, I always make sure I search exhaustively before I ask a question, but I’m discovering a new breed of developers who won’t search, won’t ask questions--then when you reach out to them they’ll ask for what they need, no matter how basic.

It seems, that self-service API resources are essential, but there will always be a segment of our audience who aren’t quite doers, they need more hand-holding and information presented to them before they get what they need.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/EpMiRYzGFvM/

Profiling API Developers

For the last couple weeks I’m neck deep in getting to know the developers who already use the CityGrid APIs. I want a better understanding of who a developer is, what kind of business they have and what they are looking to get out of the API.

To find this out I start out profiling them socially using Rapportive (which I plan on automating using the Full Contact API as soon as I have more time) for the following information:

  • Twitter Profile
  • LinkedIn Account
  • Facebook Profile
  • Google + Profile
  • Github Profile

Usually I know the URL of their website, but if I don’t, I can extract from their email address or sometimes Rapportive will provide for me. I visit each developer’s site and look for:

  • Blog w/ RSS Feed
  • Business Contact Email
  • Business Contact Form

Next I build a quick one sentence description, telling me who they are and what they do. I also assemble a comma separated list of keyword and key phrases that best represent what they do.

Before I’m done looking around their site I take a picture of their home page, so I have a visual reference to go with the developer profile. The home page image can go further than just a logo sometimes.

I take all of this information, put it into a database, and connected it to a JQuery Carousel that allows me to watch a slideshow that walks me through the world of my developers, and watch like a TV channel.

This process not only gives me a 100K understanding my developer ecosystem, but helps me remember as much as I can about each developer. From this I hope to better engage them on a daily basis as well as provide feedback to the CityGrid API roadmap based upon quality API developer segmentation.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/HcITpGDzhBo/