-
Presentation originally given by Matt Jones at Frontiers Of Interaction V, Rome, Italy on 8th June 2009
-
I'm Thomas Thwaites and I'm trying to build a toaster, from scratch – beginning by mining the raw materials and ending with a product that Argos sells for only £3.99. A toaster.
-
Immaculate Telegraphy
Could humans at any point in history, given the right information, construct an electronic communication network? To test this hypothesis, Substitute Materials will attempt to build a functional electric battery and telegraph switch from materials found in the wilderness, using no modern tools except information from the internet. The telegraph will be a first step towards an ahistorical internet.
-
I saw the wonderful arduino/processing scope, and thought of many improvements, including:
* logic analyzer mode that shows 1's and 0's clearly.
* pause frame
* save frame
* configurable pin-count
* use as many pins as will fit on screen (tested with 12 at 800×800, seems ok)
* use scope class in your own thing, easy to reuse, and setup any kind of GUI
* shows volts, based on scaling settings -
This software allows you to get a visual representation of an analog signal using Arduino and Processing. The resolution is 10 bits so this is not like a real oscilloscope but it is still pretty useful. It works by sending values read from the Arduino board (pin 0) to Processing through serial communication.
Archive for June 2009
-
Hal Varian, Google’s Chief Economist, was interviewed a few months ago, and said the following in the McKinsey Quarterly:
“The sexy job in the next ten years will be statisticians… The ability to take data—to be able to understand it, to process it, to extract value from it, to visualize it, to communicate it—that’s going to be a hugely important skill.”
-
Arduino Xcode template
-
"For those of you attending our Wednesday night greywater workshop at Good and for those of you who can't, here's a list of resources for using your washing machine as a irrigation source:"
-
JCF's BDD workshop notes
[cross-posted from the Headshift blog]
That’s a question I was asked a few days ago by a client. It’s a fair question, too – there’s no point in building features into systems unless they provide some benefit, so why would you want to spend time and effort doing this? And for that matter, what exactly IS an API?
The acronym stands for “application programming interface”, which is a typically over-engineered way of saying “means of putting information in and getting information out of your system without having to type it yourself”. Typically you’ll provide the API with some information, and in return the system will process and spit back some other data. There’s any number of analogies that you can use, but one of my favourites is the cash machine. That’s pretty much an API for your bank – you put in your card and enter your PIN, ask the bank for money, and it then dispenses cash. The information you’re providing is the data on your card and your PIN, while the bank is supplying you with cash and a little paper slip telling you how big your overdraft is.
An “API” for a bank is a good thing if you want to get at your money, but why is it such a big deal for a piece of software?
To start with, very few software systems these days exist in isolation. If it’s an accounting package, you’ll probably want it to hook up to your bank so you can send and receive payments automatically. If it’s an ERP system, you’ll find it useful if you could send your purchase orders electronically to your suppliers rather than relying on the steam telephone. And if you want to tell your customers where your outlets are, you can embed a Google map into your website to plot their locations so that your customers can find you.
All of these are examples of systems using APIs, but it doesn’t stop there. Increasingly, systems are providing APIs without necessarily having a clear idea of what they’re going to get used for. In some ways, that’s a violation of my sweeping statement about there being no point building features without having returns – but the point here is that there’s no guarantee that you’re best placed to know *what* those returns might be.
Take Moo, for example. They print things – stickers, business cards, postcards and so on. They’ve also got an API. So what the hell would a printing company do with an API?
The answer is, suprisingly, quite a lot. Former Headshift colleague Tom Armitage created an application that takes a set of Flickr photographs, calculates their average colours and creates stickers. They’re very tangible, suprisingly beautiful and almost completely pointless – unless, that is, you’re Moo who make money for every sticker that they print. Another example is Barcode Sticker-o-Matic that lets you create QR code stickers. Previously, creating QR codes was a pain, and creating QR code stickers was even more of a pain – but mashing up the two things creates something very much easier and useful.
Another example (and bear with me while I unashamedly pimp some of my own creations) is Twitter. Their API enables you to create tweets with code, rather than the website. So I’ve used this to create Twitter bots that tweet the high and low tides of the River Thames; and tweet the values of various stock markets every hour. The first example is something of a play thing (although as an aside, I actually think you can gain some value to be gained by providing an inanimate object with a “personality”), but the second could conceivably be useful if you needed a peripheral update of how badly the markets were doing.
So much for the entertainment value, but what about the potential business value for providing an API?
There are two things to consider. The first is that you could potentially make it easier for your customers to deal with you. If your clients can place orders directly onto your system through your API, that’s going to speed things up. It’s also going to cut down on errors and duplication, particularly if you can give them information about lead times and stock levels there and then. And on the assumption that the easier it is to deal with you, the more people will, that should translate through to the bottom line.
The second thing – and to me, the most powerful – is that your customers may want to interact with you in ways that you’d never thought of. It’s fairly unlikely that Moo realised that they’d end up printing QR codes when they wrote their API, and I’m absolutely sure that Twitter weren’t expecting me to come along and impersonate the River Thames. And the same probably goes for for huge numbers of other organisations as well. Imagine if Sainsbury provided an API for their home shopping service. How long do you think it would be before someone created an iPhone application that allowed you to scan the barcode on the last tin of beans in your cupboard, and automatically add that into your basket, which would then be automatically ordered as soon as the value triggered their free delivery option. Oh, and interrogated your Google calendar to find the slot when you weren’t planning to be out for evening? I don’t work for Sainsburys – and they’ve certainly never tried to ask me about what I want from them – but if they provided an API for me to play with, then I’d definitely be having a go at it.
I’m going to make a wild prediction that no corporate software system will ship WITHOUT an API in three years time, and that organisations that can’t provide an interface for their customers are going to find that an increasingly difficult omission to justify. So the question is not so much, “what’s an API and why do I want one”, as “what’s my API going to do and when can I have it”…
