ENTRIES TAGGED "amazon"

What Amazon, iTunes, and Uber teach us about Apple Pay

Truly disruptive services don’t just digitize the familiar. They do away with it.

Pay_Steve_Snodgrass_FlickrSomething’s been nagging at me about Apple Pay, and the hype about it.

The Apple-Pay web page gushes: “Gone are the days of searching for your wallet. The wasted moments finding the right card. The swiping and waiting. Now payments happen with a single touch.”

What’s wrong with this picture?

It’s describing the digital facsimile of a process that is already on its way to becoming obsolete. But truly disruptive new services don’t just digitize the familiar. They do away with it.

I never search for my wallet when I take an Uber. I never search for my wallet when I walk out of a restaurant that accepts Cover. I never search for my wallet when I buy something from Amazon. I don’t even search for my wallet when buying a song from iTunes — or, for that matter, an iPhone from an Apple Store.

In each of these cases, my payment information is simply a stored credential that is already associated with my identity. And that identity is increasingly recognized by means other than an explicit payment process. Read more…

Comments: 22

The Amazon whisperer, invisible interfaces, FDA vs 23andMe, and robots usher in a new polical order

A backchannel look at what's on our radar.

The Radar team does a lot of sharing in the backchannel. Here’s a look at a selection of stories and innovative people and companies from around the web that have caught our recent attention. Have an interesting tidbit to contribute to the conversation? Send me an email or ping me on Twitter

Comment: 1
Four short links: 7 November 2013

Four short links: 7 November 2013

Help Searching, Offline First, AWS Tips, and Awesome Fonts

  1. Learn to Search — cheeky but spot-on help for people running conferences.
  2. Offline Firstno, the mobile connectivity/bandwidth issue isn’t just going to solve itself on a global level anywhere in the near future. THIS!
  3. 10 Things You Should Know About AWS — lots of specialist tips for hardcore AWS users.
  4. The League of Moveable Type — AWESOME FONTS. Me gusta.
Comment
Four short links: 5 November 2013

Four short links: 5 November 2013

Time Series Database, Cluster Schedulers, Structural Search-and-Replace, and TV Data

  1. Influx DBopen-source, distributed, time series, events, and metrics database with no external dependencies.
  2. Omega (PDF) — flexible, scalable schedulers for large compute clusters. From Google Research.
  3. GraspJSSearch and replace your JavaScript code based on its structure rather than its text.
  4. Amazon Mines Its Data Trove To Bet on TV’s Next Hit (WSJ) — Amazon produced about 20 pages of data detailing, among other things, how much a pilot was viewed, how many users gave it a 5-star rating and how many shared it with friends.
Comment: 1
Four short links: 3 October 2013

Four short links: 3 October 2013

USB in Cars, Capture Presentations, Amazon Redshift, and Polytweeting

  1. Hyundia Replacing Cigarette Lighters with USB Ports (Quartz) — sign of the times. (via Julie Starr)
  2. Freeseerfree, open source, cross-platform application that captures or streams your desktop—designed for capturing presentations. Would you like freedom with your screencast?
  3. Amazon Redshift: What You Need to Know — good write-up of experience using Amazon’s column database.
  4. GroupTweetAllow any number of contributors to Tweet from a group account safely and securely. (via Jenny Magiera)
Comment: 1
Four short links: 1 October 2013

Four short links: 1 October 2013

Ploughbot, Amazon Warehouses, Kickstarting Safety, and The Island of Dr Thoreau

  1. Farmbot Wikiopen-source, scalable, automated precision farming machines.
  2. Amazon’s Chaotic Storage — photos from inside an Amazon warehouse. At the heart of the operation is a sophisticated database that tracks and monitors every single product that enters/leaves the warehouse and keeps a tally on every single shelf space and whether it’s empty or contains a product. Software-optimised spaces, for habitation by augmented humans.
  3. Public Safety Codes of the World — Kickstarter project to fund the release of public safety codes.
  4. #xoxo Thoreau Talk (Maciej Ceglowski) — exquisitely good talk by the Pinboard creator, on success, simplicity, and focus.
Comment
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)
Comment

Podcast: ratings, rankings, and the advantage of being born lucky

A conversation with Sean Taylor, Hilary Mason, and John Myles White about how ratings affect our thinking

Outcomes following random exogenous upvotes and downvotes on message board posts. Image via Sean Taylor.

Researchers randomly upvoted some posts and downvoted others on a popular message board. The upvoted posts became substantially more popular over the long run. Image via Sean Taylor.

Is popularity just a matter of simple luck–of some early advantage compounded by human preference for things that are already popular? A paper published today in Science offers some insight into the way that popularity emerges in online ratings. Lev Muchnik, Sinan Aral, and Sean Taylor were able to set up a randomized experiment on a popular Reddit-like message board in which they gave some posts a one-point upvote on publication and others a one-point downvote. Posts that were “born lucky” ended up with 25% higher scores on average than those without modification.

In our latest podcast, Renee DiResta and I are joined by Sean Taylor, Hilary Mason and John Myles White to talk about Sean’s findings and about ratings, rankings and reviews in general. Bits and pieces that come up in the podcast:


Subscribe to the O’Reilly Radar Podcast through iTunesSoundCloud, or directly through our podcast’s RSS feed.

Comments: 2
Four short links: 14 June 2014

Four short links: 14 June 2014

UK Gov 2.0, Remote Work, Git + App Engine, and Amazon Sells 3D Printer Goodies

  1. How Geeks Opened up the UK Government (Guardian) — excellent video introduction to how the UK is transforming its civil service to digital delivery. Most powerful moment for me was scrolling through various depts’ web sites and seeing consistent visual design.
  2. Tools for Working Remotely — Braid’s set of tools (Trello, Hackpad, Slingshot, etc.) for remote software teams.
  3. Git Push to Deploy on Google App EngineEnabling this feature will create a remote Git repository for your application’s source code. Pushing your application’s source code to this repository will simultaneously archive the latest the version of the code and deploy it to the App Engine platform.
  4. Amazon’s 3D Printer Store — printers and supplies. Deeply underwhelming moment of it arriving on the mainstream.
Comment

What Is the Risk That Amazon Will Go Down (Again)?

Velocity 2013 Speaker Series

Why should we at all bother about notions such as risk and safety in web operations? Do web operations face risk? Do web operations manage risk? Do web operations produce risk? Last Christmas Eve, Amazon had an AWS outage affecting a variety of actors, including Netflix, which was a service included in many of the gifts shared on that very day. The event has introduced the notion of risk into the discourse of web operations, and it might then be good timing for some reflective thoughts on the very nature of risk in this domain.

What is risk? The question is a classic one, and the answer is tightly coupled to how one views the nature of the incident occurring as a result of the risk.

One approach to assessing the risk of Amazon going down is probabilistic: start by laying out the entire space of potential scenarios leading to Amazon going down, calculate their probability, and multiply the probability for each scenario by their estimated severity (likely in terms of the costs connected to the specific scenario depending on the time of the event). Each scenario can then be plotted in a risk matrix showing their weighted ranking (to prioritize future risk mitigation measures) or calculated as a collective sum of the risks for each scenario (to judge whether the risk for Amazon going down is below a certain acceptance criterion).

This first way of answering the question of what the risk is for Amazon to go down is intimately linked with a perception of risk as energy to be kept contained (Haddon, 1980). This view originates from more recent times of increased development of process industries in which clearly graspable energies (fuel rods at nuclear plants, the fossil fuels at refineries, the kinetic energy of an aircraft) are to be kept contained and safely separated from a vulnerable target such as human beings. The next question of importance here becomes how to avoid an uncontrolled release of the contained energy. The strategies for mitigating the risk of an uncontrolled release of energy are basically two: barriers and redundancy (and the two combined: redundancy of barriers). Physically graspable energies can be contained through the use of multiple barriers (called “defenses in depth”) and potentially several barriers of the same kind (redundancy), for instance several emergency-cooling systems for a nuclear plant.

Using this metaphor, the risk of Amazon going down is mitigated by building a system of redundant barriers (several server centers, backup, active fire extinguishing, etc.). This might seem like a tidy solution, but here we run into two problems with this probabilistic approach to risk: the view of the human operating the system and the increased complexity that comes as a result of introducing more and more barriers.

Controlling risk by analyzing the complete space of possible (and graspable) scenarios basically does not distinguish between safety and reliability. From this view, a system is safe when it is reliable, and the reliability of each barrier can be calculated. However there is one system component that is more difficult to grasp in terms of reliability than any other: the human. Inevitably, proponents of the energy/barrier model of risk end up explaining incidents (typically accidents) in terms of unreliable human beings not guaranteeing the safety (reliability) of the inherently safe (risk controlled by reliable barriers) system. I think this problem—which has its own entire literature connected to it—is too big to outline in further detail in this blog post, but let me point you towards a few references: Dekker, 2005; Dekker, 2006; Woods, Dekker, Cook, Johannesen & Sarter, 2009. The only issue is these (and most other citations in this post) are all academic tomes, so for those who would prefer a shorter summary available online, I can refer you to this report. I can also reassure you that I will get back to this issue in my keynote speech at the Velocity conference next month. To put the critique short: the contemporary literature questions the view of humans as the unreliable component of inherently safe systems, and instead advocates a view of humans as the only ones guaranteeing safety in inherently complex and risky environments.
Read more…

Comment: 1