"APIs" entries

Do one thing…

I don't want barely distinguishable tools that are mediocre at everything; I want tools that do one thing and do it well.

350px-Pudu_jail_west_wallI’ve been lamenting the demise of the Unix philosophy: tools should do one thing, and do it well. The ability to connect many small tools is better than having a single tool that does everything poorly.

That philosophy was great, but hasn’t survived into the Web age. Unfortunately, nothing better has come along to replace it. Instead, we have “convergence”: a lot of tools converging on doing all the same things poorly.

The poster child for this blight is Evernote. I started using Evernote because it did an excellent job of solving one problem. I’d take notes at a conference or a meeting, or add someone to my phone list, and have to distribute those files by hand from my laptop to my desktop, to my tablets, to my phone, and to any and all other machines that I might use.

But as time has progressed, Evernote has added many other features. Some I might have a use for, but they’re implemented poorly; others I’d rather not have, thank you. I’ve tried sharing Evernote notes with other users: they did a good job of convincing me not to use them. Photos in documents? I really don’t care. When I’m taking notes at a conference, the last thing I’m thinking about is selfies with the speakers. Discussions? No, please no. There are TOO MANY poorly implemented chat services out there. We can discuss my shared note in email. Though, given that it’s a note, not a document, I probably don’t want to share anyway. If I wanted a document, even a simple one, I’d use a tool that was really good at preparing documents. Taking notes and writing aren’t the same, even though they may seem similar. Nor do I want to save my email in Evernote; I’ve never seen, and never expect to see, an email client that didn’t do a perfectly fine job of saving email. Clippings? Maybe. I’ve never particularly wanted to do that; Pinboard, which has stuck to the “do one thing well” philosophy, does a better job of saving links. Read more…

Comments: 36

Helping Things in the IoT speak the same language

We need to build APIs for Things that are interoperable — we need an application layer for the IoT.

Register for our free webcast “Building IoT Systems with Web Standards,” which will be hosted by Vlad Trifa and Dominique Guinard on December 8, 2015, at 10 a.m. PT.


When the term “IoT” was first coined, the idea was to move from a model where data is generated by humans bridging media gaps between the physical and the virtual worlds to a model where data is gathered by the Things themselves.

Fifteen years later, we’re moving in the right direction to make this a reality, but we still have several challenges ahead. One major challenge is interoperability: many Things do talk using the Internet, but they don’t talk the same language. Having been involved in the IoT for about as long as it’s been around, I’m pretty sure of one thing: a universal networking protocol for the IoT will never exist — and for a good reason! The IoT is a vast world where the needs of one field (e.g. Industry 4.0) to another (e.g. the smart home) are fundamentally different. As a consequence, the list of automation protocols is actually growing, not shrinking.

A consequence of these different needs is the focus on the connectivity aspect of the IoT. This is not unusual, but as we ascend the pyramid of IoT needs, we must think about the data interoperability of Things. We need to build APIs for Things that are interoperable; in short, we need an application layer for the IoT.

Read more…

Comment: 1
Four short links: 4 May 2015

Four short links: 4 May 2015

Silicon Valley Primer, GraphQL Intro, Quantum Steps, and Complex Systems

  1. Silicon Valley Primer — a short but interesting precis of what made the Valley great, with stories of the nobility. From a historian. All these new people pouring into what had been an agricultural region meant that it was possible to create a business environment around the needs of new companies coming up, rather than adapting an existing business culture to accommodate the new industries. In what would become a self-perpetuating cycle, everything from specialized law firms, recruiting operations and prototyping facilities; to liberal stock option plans; to zoning laws; to community college course offerings developed to support a tech-based business infrastructure.
  2. Introduction to GraphQLWe believe that GraphQL represents a novel way of structuring the client-server contract. Servers publish a type system specific to their application, and GraphQL provides a unified language to query data within the constraints of that type system. That language allows product developers to express data requirements in a form natural to them: a declarative and hierarchal one. The nightmare of the ad hoc API morass is a familiar one …
  3. Critical Steps to Building First Quantum ComputerThe IBM breakthroughs, described in the April 29 issue of the journal Nature Communications, show for the first time the ability to detect and measure the two types of quantum errors (bit-flip and phase-flip) that will occur in any real quantum computer. Until now, it was only possible to address one type of quantum error or the other, but never both at the same time. This is a necessary step toward quantum error correction, which is a critical requirement for building a practical and reliable large-scale quantum computer.
  4. Five Short Stories About the Life and Times of Ideas (Nautilus) — In the following five short chapters, David Krakauer, an evolutionary theorist, and president elect of the Santa Fe Institute, haven of complex systems research, examines five facets of chain reactions, each typifying how ideas spread through science and culture. Together they tell a story of how the ideas that define humanity arise, when and why they die or are abandoned, the surprising possibilities for continued evolution, and our responsibility to nurture thought that might enlighten our future.
Four short links: 6 March 2015

Four short links: 6 March 2015

Design Fiction, 3D License, Web Funding, and API Magic

  1. Matt Jones: Practical Design Fiction (Vimeo) — the log scale of experience! Fantastic hour-long recap of the BERG thinking that he’s continued at the Google Creative Lab in NYC. (via Matt Jones)
  2. 3dPL — public license for 3d objects. (via BoingBoing)
  3. Google Contributor — when the web’s biggest advertiser tries alternative ways to fund web content, I’m interested.
  4. Templaran HTTP proxy that provides advanced features to help you make better use of and tame HTTP APIs. Timeouts, caching, metrics, request collapsing, …
Four short links: 17 February 2015

Four short links: 17 February 2015

Matthew Effects, Office Dashboards, Below the API, and Robot Economies

  1. Matthew Effects in Reading (PDF) — Walberg, following Merton, has dubbed those educational sequences where early achievement spawns faster rates of subsequent achievement “Matthew effects,” after the Gospel according to Matthew: “For unto every one that hath shall be given, and he shall have abundance: but from him that hath not shall be taken away even that which he hath” (XXV:29) (via 2015 Troubling Trends and Possibilities in K-12)
  2. Real Time Dashboard for Office Plumbing (Flowing Data) — this is awesome.
  3. Working Below the API is a Dead End (Forbes) — Drivers are opting into a dichotomous workforce: the worker bees below the software layer have no opportunity for on-the-job training that advances their career, and compassionate social connections don’t pierce the software layer either. The skills they develop in driving are not an investment in their future. Once you introduce the software layer between ‘management’ (Uber’s full-time employees building the app and computer systems) and the human workers below the software layer (Uber’s drivers, Instacart’s delivery people), there’s no obvious path upwards. In fact, there’s a massive gap and no systems in place to bridge it. (via John Robb)
  4. The Real Robot Economy and the Bus Ticket Inspector (Guardian) — None of the cinematic worries about machines that take decisions about healthcare or military action are at play here. Hidden in these everyday, mundane interactions are different moral or ethical questions about the future of AI: if a job is affected but not taken over by a robot, how and when does the new system interact with a consumer? Is it ok to turn human social intelligence – managing a difficult customer – into a commodity? Is it ok that a decision lies with a handheld device, while the human is just a mouthpiece? Where “robots” is the usual shorthand for technology that replaces manual work. (via Dan Hill)
Four short links: 4 June 2014

Four short links: 4 June 2014

Swift on GitHub, HTTP APIs, PGP in Gmail, and Comments vs Community

  1. Swift on GitHub — watch a thousand projects launch.
  2. HTTP API Design Guideextracted from work on the Heroku Platform API.
  3. End-to-End PGP in Gmail — Google releases an open source Chrome extension to enable end-to-end OpenPGP on top of gmail. This is a good thing. As noted FSF developer Ben Franklin wrote: Those who would give up awkward key signing parties to purchase temporary convenience deserve neither.
  4. Close Your Comments; Build Your Community (Annemarie Dooling) — I am rarely sad when a commenting platform collapses, because it usually means the community dissolved long before.
Four short links: 28 April 2014

Four short links: 28 April 2014

Retail Student Data, Hacking Hospitals, Testing APIs, and Becoming Superhuman

  1. UK Government to Sell Its Students’ Data (Wired UK) — The National Pupil Database (NPD) contains detailed information about pupils in schools and colleges in England, including test and exam results, progression at each key stage, gender, ethnicity, pupil absence and exclusions, special educational needs, first language. The UK is becoming patient zero for national data self-harm.
  2. It’s Insanely Easy to Hack Hospital Equipment (Wired) — Erven won’t identify specific product brands that are vulnerable because he’s still trying to get some of the problems fixed. But he said a wide cross-section of devices shared a handful of common security holes, including lack of authentication to access or manipulate the equipment; weak passwords or default and hardcoded vendor passwords like “admin” or “1234″; and embedded web servers and administrative interfaces that make it easy to identify and manipulate devices once an attacker finds them on a network.
  3. Postman — API testing tool.
  4. App Controlled Hearing Aid Improves Even Normal Hearing (NYTimes) — It’s only a slight exaggeration to say that the latest crop of advanced hearing aids are better than the ears most of us were born with. Human augmentation with software and hardware.

Searching for the software stack for the physical world

Very much a work in progress, the stack for IoT will require rethinking every layer of the protocol stack.

When I flip through a book on networking, one of the first things I look for is the protocol stack diagram. An elegant representation of the protocol stack can help you make sense of where to put things, separate out important mental concepts, and help explain how a technology is organized.

I’m no stranger to the idea of trying to diagram out a protocol space; I had a successful effort back when the second edition of my book on 802.11 was published. I’ve been a party to several awesome conversations recently about how to organize the broad space that’s referred to as the “Internet of Things.”IoT Stack

Let’s start at the bottom, with the hardware layer, which is labeled Things. These are devices that aren’t typically thought of as computers. Sure, they wind up using a computing ecosystem, but they are not really general-purpose computers. These devices are embedded devices that interact with the physical world, such as sensors and motors. Primarily, they will either be the eyes and ears of the overall system, or the channel for actions on the physical world. They will be designed around low power consumption, and therefore will use a low throughput communication channel. If they communicate with a network, it will typically be through a radio interface, but the tyranny of limited power consumption means that the network interface will usually be limited in some way.

Things provide their information or are instructed to act on the world by connecting through a Network Transport layer. Networking allows reports from devices to be received and acted on. In this model, the network transport consists of a set of technologies that move data around, and is a combination of the OSI data link, networking, and transport layers. Mapping into technologies that we use, it would be TCP/IP on Wi-Fi for packet transport, with data carried over a protocol like REST. Read more…

Comments: 2
Four short links: 5 September 2013

Four short links: 5 September 2013

Bezos on Business, CS Ratios, Easier Hadoopery, and AWS CLI

  1. Bezos at the Post (Washington Post) — “All businesses need to be young forever. If your customer base ages with you, you’re Woolworth’s,” added Bezos.[…] “The number one rule has to be: Don’t be boring.” (via Julie Starr)
  2. How Carnegie-Mellon Increased Women in Computer Science to 42% — outreach, admissions based on potential not existing advantage, making CS classes practical from the start, and peer support.
  3. Summingbird (Github) — Twitter open-sourced library that lets you write streaming MapReduce programs that look like native Scala or Java collection transformations and execute them on a number of well-known distributed MapReduce platforms like Storm and Scalding.
  4. aws-cli (Github) — commandline for Amazon Web Services. (via AWS Blog)

Upward Mobility: Overly Defensive Programmer

Sometimes, the best defense is a good offensive core dump

By now, most meme-aware internet surfers have encountered Overly Attached Girlfriend  (and the Rule 63 counterpart, Overly Attached Boyfriend.) What isn’t as well known is that they have a brother, Overly Defensive Programmer (ODP, for short.)

ODP is a mobile developer who lives in the constant fear that the server-side folks are going to subtly change an API out from under him, making his app crash. To avoid this, he puts in code like this:

We’ve all seen code like this. The developer didn’t want to accidentally cause a fatal error by trying to get the objectId parameter if the payload was missing, or to try accessing the objectId if it was missing. And if objectId is an optional field, this is totally the way to go.

The thing is, objectId sounds like it is probably a critical piece of data, without which the application will fail to operate properly. You want the application to crash if it goes missing, because that means it will crash during QA testing, rather than silently ignoring the problem and possibly malfunctioning in a way that QA misses.
Read more…