The AP is increasingly starting to use software with no human intervention to write basic news stories, but Kevin Roose says that we shouldn’t be alarmed about it. From his article Why Robot Journalism Is Great for Journalists:

Robot assistance may even spur human reporters to do our jobs better. With software producing the equivalent of old-school “clip files” for us, we’ll essentially have full-time research assistants. The information in our stories will be more accurate, since it will come directly from data feeds and not from human copying and pasting, and we’ll have to issue fewer corrections for messing things up. Plus, with our nuts-and-bolts reporting out of the way, we’ll be able to focus on the kinds of stories that educate and entertain readers in a deep way, rather than just dragging simple information from Point A to Point B.

Maiz Lulkin has a great overview of one of the most important and most misunderstood issues in software development in his post Technical debt 101:

In software development, the dreadful consequences of sacrificing quality are widely misunderstood by non technical managers. They underestimate how detrimental it is to continued productivity and morale, and ultimately, to the overall strategy of the company.

He goes on to explain why…

Ashley Feinberg in Razr Burn — My Month With 2004’s Most Exciting Phone:

It may be hard to remember now—or to believe at all, if you’re under 20—but at the time of its release the Razr was the final word in mobile technology. For the first time, you got a sleek, powerful, and wildly expensive bit of metal to call not only your cellphone but your status symbol, too. A couple of years and a few slashes into the $700 price tag later, you could barely go outside without seeing someone flip open a Razr. In four years, Motorola sold 130 million of them, a record that wouldn’t be touched until well into the iPhone’s run.

This sounds like a terribly painful experience. Like she accurately points out in the beginning: don’t try this at home…

I’m not sure if I should really link to Kids Don’t Care About Cars because there are very few things more annoying than old people pontificating about what “youngsters” like and don’t like. Still, this part did get me thinking:

The basic premise is you’ve got to go. How you get there is irrelevant. Furthermore, the costs of car ownership… the insurance and the gas, never mind the maintenance, none of them appeal to a youngster who believes all costs should be baked in.

I’m not convinced the conclusion that car ownership is a thing of the past is accurate1, even though this is not the first time the argument has been made — see Zipcar, Uber And The Beginning Of Trouble For The Auto Industry. But as an old guy myself, I do see the product opportunities that are created by this idea that how you get places is irrelevant as long as you can get there.

One of my favorite examples of companies taking advantage of this right now is car2go. It’s a network of smart cars that you can pick up anywhere, drive anywhere, and leave anywhere when you’re done. And it’s all done through a smartphone app (or the web — if you’re old and lame of course). No matter how much I think about this, I can’t get over how magical this idea is. What a great way to fill an unmet user need.

---

1. Try not having a car when you have kids… ↩

Conor Friedersdorf talks about the differences between recommendations provided by people and algorithms in Would You Rather Get Tips from an Expert or an Algorithm?

The Amazon.com algorithm is very good at using what you’ve just bought to recommend things that you’ll want to buy, [David Weinberger, a senior researcher at the Berkman Center for Internet and Society] observed, but it can be hard to tell why. Perhaps you’ll be attracted to the content of the recommendation — or perhaps it’s the fact that the cover is also green, or that the print is in Helvetica font. 

In contrast, a skilled librarian is usually going to recommend a book solely because of its intellectual value, without any lurking, contentless variables. The librarian is therefore likelier to send a person in a direction they wouldn’t otherwise have gone in a way that will advance their thinking, education, or aesthetic taste, because they’re not just meeting needs that have already been expressed.

We’re seeing this divide come out in products as well, and some are starting to use their “humanness” as a differentiator. Whereas most music recommendation systems like Pandora, Spotify, and Rdio use algorithmic approaches, Beats touts the power of human curation on their product.

Go Book Yourself is a Tumblr site that publishes curated recommendations for books you might like based on other books you read and liked. Their tag line is Book recommendations by humans, because algorithms are so 1984.

The humans are coming.

I have no idea if anyone else will find this helpful, but I’m so excited about it that I have to share it1. One of the most time-consuming and repetitive tasks in blogging is uploading images to my Amazon S3 account, generating the CDN link, and inserting it into the post. But I’ve now cobbled together a recipe that makes this really easy, and I’d like to tell you about it. First, here are the ingredients you’ll need:

1. An Amazon S3 account for image storage (optional: Cloudfront CDN)
2. TextExpander to handle the repetitive typing
3. Hazel to automate the upload to S3
4. Dropbox isn’t technically necessary, but it makes everything just a little bit smoother.

With that said, here are the steps in the recipe:

Step 1: Set up a Hazel workflow to upload new files to S3

First, we need to set up Hazel to watch a folder and upload any new files to your S3 bucket. The Macdrifter article Upload to Amazon S3 from Dropbox using Hazel is extremely helpful for this. I basically copied that script with some minor adjustments. Here’s what it looks like:

Note that you have to change the type of shell script you run to /usr/bin/python. The script I use looks as follows (again, see the Macdrifter article for the whole story):

import boto
from boto.s3.connection import S3Connection
import os
import sys
import urllib
from datetime import date, datetime
import subprocess

# This is how Hazel passes in the file path
hazelFilePath = sys.argv[1]

# Obviously, you'll need your own keys
aws_key = 'YOUR_KEY'
aws_secret = 'YOUR_SECRET'

# This is where I store my log file for these links. It's a Dropbox file in my NVAlt notes folder
logFilePath = "/Users/~YOUR_COMPUTER_NAME/Dropbox/Notational/Link_Log.txt"
nowTime = str(datetime.now())

# Method to add to clipboard
def setClipboardData(data):
    p = subprocess.Popen(['pbcopy'], stdin=subprocess.PIPE)
    p.stdin.write(data)
    p.stdin.close()
    retcode = p.wait()

# This is the method that does all of the uploading and writing to the log file.
# The method is generic enough to work with any S3 bucket that is passed.
def uploadToS3(localFilePath, S3Bucket):
  fileName = os.path.basename(localFilePath)

# Determine the current month and year to create the upload path
    today = date.today()
    datePath = today.strftime("/%Y/%m/")

# Create the URL for the image (Add your own path here)
    imageLink = 'https://cdn.elezea.com/images/'+urllib.quote(fileName)

# Connect to S3
    s3 = S3Connection(aws_key, aws_secret)
   bucket = s3.get_bucket(S3Bucket)
   key = bucket.new_key('images/'+fileName)
   key.set_contents_from_filename(localFilePath)
   key.set_acl('public-read')
   logfile = open(logFilePath, "a")

try:
       # %% encode the file name and append the URL to the log file
       logfile.write(nowTime+'  '+imageLink+'n')
      setClipboardData(imageLink)
   finally:
      logfile.close()

Here’s what the script does in my case: Whenever I add a new file to the Img folder in Dropbox, it uploads the file to S3, copies the URL to the clipboard, and also adds that URL to a Link_Log text file in my nvALT folder for later access if needed (or if I add multiple images in one go).

Step 2: Set up TextExpander shortcuts

Once the image is added to S3, the rest is handled with TextExpander. When I want to add an image to a blog post I type:

,img

That expands to:

<p><img style="display: block; margin-left: auto; margin-right: auto;" title="%fill:image title%" src="%|%fill:image source%" border="0" alt="%fill:image title%" /></p>

It asks me to give the image an alt tag, and then it places the cursor where I’m going to add the source file. Since the source URL is already in my clipboard, I then just ⌘-V and I’m all set.

They call it magic

That’s it. It might seem like a lot of work, but now that everything is set up my workflow is extremely simple:

1. Add new image to the Img folder
2. Type the TextExpander shortcut and paste the Image URL where I want the image to appear

I think it’s going to save me at least as much time this year as it took to write this blog post.

Oh. Wait.

---

1. It also gives me an opportunity to pretend I’m Dr. Drang, but I digress. ↩

I don’t quite get the style of John Herrman’s Internet, Why So Blue?1, but this bit about why hyperlinks started out blue is quite interesting:

The man who invented links2 was writing them to a grayscale screen. The first popular browser, Mosaic, later turned links blue because it was the darkest color available at the time that wasn’t black; they needed to stand out, but only just. Blue was the best alternative. Blue always survives the focus group. Blue wins the a/b test. Which is convenient, because blue is usually already there.

---

1. It’s probably, once again, because I’m old. ↩

2. AKA Sir Tim Berners-Lee. ↩

Two recent articles about technology and our perception of time make some interesting related points. From the clickbaity (yet surprisingly good) Feeling More Antsy and Irritable Lately? Blame Your Smartphone1:

Our gadgets train us to expect near instantaneous responses to our actions, and we quickly get frustrated and annoyed at even brief delays. I know that my own perception of time has been changed by technology. If I go from using a fast computer or Web connection to using even a slightly slower one, processes that take just a second or two longer—waking the machine from sleep, launching an application, opening a Web page—seem almost intolerably slow. Never before have I been so aware of, and annoyed by, the passage of mere seconds. […]

More interesting is [a recent study of online video viewing’s] finding of a causal link between higher connection speeds and higher abandonment rates. Every time a network gets quicker, we become antsier. As we experience faster flows of information online, we become, in other words, less patient people.

Turns out this phenomenon isn’t new — technology just makes it worse. We’ve always adjusted to our circumstances quickly, and we respond by wanting more. From Elizabeth Kolbert’s No time:

“Most types of material consumption are strongly habit-forming,” Gary Becker and Luis Rayo observe in their contribution to Revisiting Keynes. “After an initial period of excitement, the average consumer grows accustomed to what he has purchased and … rapidly aspires to own the next product in line,” they write. By Becker and Rayo’s account, this insatiability is hardwired into us. Human beings evolved “so that they have reference points that adjust upwards as their circumstances improve.”

The more we have, the more we want. The faster the internet gets, the faster we want it. What can we possibly do with 1000Mbps that we can’t do just as well with 50Mbps? It doesn’t matter. 50Mbps is the standard now. We’re adjusted. And so up we go…

---

1. This is at least better than the original title, which was — I kid you not — You are an impatient monster—but you weren’t born this way. Guess what’s to blame? ↩

Tom Jacobs discusses some new research that shows people are more comfortable sharing their medical information with virtual people in I’d Never Admit That to My Doctor. But to a Computer? Sure. The implications are interesting:

When it comes to fixing our healthcare system, very few people would agree that part of the answer lies in less human interaction. Patients generally want more, not less, contact with health professionals. Yet this study suggests that, at least for the intake interview, a little less of the human touch — and a little more perceived privacy — may be precisely what the doctor ordered.

Two articles on the color yellow caught my eye this week.

The first is Object of Interest: The Yellow Card — Rob Walker’s history of the yellow card as it’s used in soccer. In a 1966 World Cup game a referee apparently failed to adequately communicate a penalty warning, which resulted in the birth of the card:

As objects go, it doesn’t look like much. It’s, you know, a yellow card. But when theatrically brandished by an official, almost literally in the face of a player who has done something uncool, it has wild power. It sets off a stadium-full of whistling, and cartoonish arm-flailing from the carded player and his colleagues. A yellow card has real consequences: Possession, a free kick, and the possibility that if the carded competitor blunders again he’ll leave his team understaffed for this match, and will sit out the next. […]

The cards are a such a brilliant solution to the problem of making sure a penalty has been adequately signaled — they transcend language; they’re clear not just to everyone on the field, but in the stadium, or watching on a screen — that it’s hard to imagine the game without them.

The second is Dan Saffer’s ode to a ubiquitous object in cities: The Hidden Genius and Influence of the Traffic Light.

The yellow light is by far the most sophisticated and cognitively challenging part of any traffic light. Red and green lights have had to consider timing, namely: how long should one side of the intersection remain green, the other red. This creates the “capacity” of a signal: how many vehicles can move through on a single change of the light. […]

The yellow light doesn’t really control capacity, but instead creates an ephemeral Zone of Decision around the intersection. When a light turns yellow, nearby drivers have a choice to make, quickly: do I speed up and drive through the yellow light, or do I slow down and stop? Driving instructors will of course always tell you that a yellow light means slow down and prepare to stop, but on the street, that’s not always how it works. Sometimes it really would be more dangerous to stop than to run the yellow. And sometimes those driving instructors are right: running the yellow is a terrible, dangerous idea. How do you know which is which?

So here we have two yellows, the one extremely clear (“I’ve made a huge mistake…”), the other an object of anxiety (“Should I stay or should I go?”). And yet we all know what the color means based on history and context and common understanding. I don’t know why that strikes me as fairly remarkable, but it does.

Also, apropos of nothing, does anyone else remember this?