Over the past few weeks it seems that Twitter has been moving to drastically redefine what the service is about. Moving to limit API connections and placing restrictions on how third parties interface with it.

This has limited the usefulness of third party tools that others love and risks damaging the ecosystem that has built up around the service – although, as I have remarked in the past, building a business around a single third party service is asking for trouble.

Now, there must be sound business reason why the folks at the big blue bird decided to do this but I can’t help feeling that they’re missing an opportunity to reach out to these developers.

Twitter is more than a messaging service, it’s a protocol. It’s a way of loosely connecting services together without having to write a specific connection mechanism, for example, this is how I get IFTTT updating my todo list.

It would be a real shame to see the utility of this sacrificed in order to turn Twitter into just another eyeball engine for adverts. Thankfully, other systems exist, and my hope is that we will see a more distributed ecosystem evolve.

Update 20/9/12: Got an email from IFTTT today, and it seems that they are being forced to remove all Twitter triggers from their service. Which means no more archiving, or traffic updates among other things. I’m sure this must all make sense from a business point of view, but it seems a crying shame to systematically make the service less useful to people.

Image “Fail Whale” by Yiling Lu

I got bored one evening, so I hacked together the beginnings of an API library for latakoo Flight. Currently it’s available in three four tasty flavours – PHP, Python, Ruby and C# .NET / Mono.

The libraries are minimal but functional; they let you perform both anonymous and authenticated queries against the latakoo API endpoint, but I’ve only had time to add method wrappers for a few of api calls. Feel free to fork the project to help flesh these out!

Hopefully these libraries will make it easier to get the power of latakoo behind your project, and be sure to check out Latakoo to find out how to share video on the Internet.

Happy hacking!

» API Documentation
» Github Project Page

I like feeds and APIs.

Feeds and APIs provide ways for others to access a service and to recombine the data in new and unexpected ways. Ways that have consistently been proven to be beneficial to both parties (which makes google’s increasing antipathy towards them an interesting, not to mention short sighted, trend).

Anyway, it was one morning when I was attempting to find a route to work for my girlfriend which bypassed the numerous arterial route crashes that had happened that morning and I found myself pondering thus

… wouldn’t it be cool if roads and junctions had permanent URLs, and better yet if you could get a data feed on them?

This would let you do many cool things, for example you could enter your route to work and get a status of the traffic en route – or at the very least attach a particular traffic blackspot (in our case the 13 bends of death on the A4074) to ifttt and get SMS alerts if there was a problem.

Giving roads and junctions addressable urls would be an obvious extension to the google maps API, but given that Google won’t even let you embed a map in a page if it contains a traffic data overlay it seems unlikely they’ll provide such access to their data. Other sources such as the Yahoo’s traffic API has long since been shut down.

So, what alternative traffic data sources could we use?

One possible data source we could use would be to parse a twitter search for the road in question. We both currently use ifttt hookups to get alerts for certain key roads, so the basic concept is sound.

This isn’t perfect, for example there is no understanding of the context of a message – so for example a message saying “No traffic problems on the A4074” and “Terrible crash on the A4074” would both trigger the alert, but only the latter would indicate a problem.

The other problem of course is that it also relies on people tweeting, but in effect this would actually pull in quite a diverse range of secondary sources – in my case, for example, it also pulls in any source that feed into the local radio station – which includes reports from their traffic spotter plane.

As an individual without access to data from traffic sensors, or any ability to collect data directly (unlike, say, google who can use position reports from android phones), we are pretty much limited to collecting data from secondary sources as far as I can see.

What other sources could we use?