- Networks, Crowds, and Markets — network theory (graph analysis), small worlds, network effects, power laws, markets, voting, property rights, and more. A book that came out of a Cornell course by ACM-lauded Jon Kleinberg.
- Qu — a framework for building data APIs. From a government department, no less. (via Nelson Minar)
- Three Most Common M-Commerce Questions Answered (Facebook) — When we examined basket sizes on an m-site versus an app, we found people spend 43 cents in app to every $1 spent on m-site. (via Alex Dong)
- Phonelabs — science labs with mobile phones. All open sourced for maximum spread.
I don't want barely distinguishable tools that are mediocre at everything; I want tools that do one thing and do it well.
I’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…
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.
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.”
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…
Bezos on Business, CS Ratios, Easier Hadoopery, and AWS CLI
- 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)
- 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.
- 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.
- aws-cli (Github) — commandline for Amazon Web Services. (via AWS Blog)