Reporter's Notebook

#MakeEveryWeek: A Series for Inventors
Show Description +

Andrew McGill is chronicling the devices and apps he’s creating this summer and invites readers to join him. Are you an inventor and want to share a project? Please drop him a note:

Show None Newer Notes

There’s a whole literary subgenre devoted to inventions that ultimately destroy their inventors. Frankenstein didn’t turn out so well for Frankenstein himself. As I recall, The Strange Case of Dr. Jekyll and Mr. Hyde ended with neither Jekyll nor Hyde still standing. Within all of us lies the potential to create the agent of our destruction.

With that in mind, let me introduce you to my own downfall: a button that, when pressed gently, orders a Sweetgreen salad. Here it is, pinned above my desk, next to a jaunty Election Day hat:

Sweetgreen is a salad chain that got its start in Washington, D.C., and specializes in delicious green stuff. It’s a go-to lunch choice for me, with a restaurant conveniently located near the The Atlantic’s Watergate offices (and thankfully, a few steps closer than the burger-and-milkshake joint). But I’m not the only one who loves it. Around lunchtime, the place gets mobbed. It’s at the point where you’re surprised when the line isn’t already out the door:

One solution? Order online ahead of time and pick up the salad when you show up. Their app is simple enough, but I wondered—how hard would it be to hook up another Amazon Internet of Things button that would automagically complete my order with one press?

Turns out, not so hard. I had to do a bit of hacking around Sweetgreen’s ordering system (technical post here, raw code here), but in the end, I coded the button so it randomly orders one of my three favorite salads and bills my account. Now, whenever I want a salad, I just tap the button and walk out the door. It’s there when I arrive.

It’s funny—this is sort of what the Amazon button was originally intended to do. So why is this a bad thing that’s destined to destroy me? Well, if you follow my love of Sweetgreen and how darn easy this button is to use to the natural conclusion, I will soon have no money.

Reader Bob Williamson argues that my solution for coworkers forgetting their key fobs was too “Epimethean”—it requires users to make a mistake first. In mythology, Epimetheus accepted a cursed gift (Pandora and her box) without giving thought to its future consequences. Compare him to his brother, Prometheus, who stole fire from Zeus knowing he’d be punished harshly but would reap a long-term gain. A Promethean solution, Williamson says, would protect my colleagues from forgetting their keys in the first place:

Pandora offers jar to Epimetheus (Wiki)

Efficient error recovery is important in engineering systems, but prevention is better.

How about an IoS button on the inside of the door that sends you a reminder to take your keys before you lock yourself out, again? At first I thought it could go on your chair and trigger when standing, but it would be nice to serve more than one distracted user. Could you identify the recipient by proximity to the exit? Ideally you’d get the message just before the  door closed, but that timing could be part of the training impact of the system.

You could call this one dumbbellbot. ;-)

A good point! It’s a challenging engineering problem—getting a “do you have your keys?” notification every time you approach the door sounds a bit overwhelming—but there must be some way to make this work. Thoughts? Update from reader Wes:

I like the idea of the proximity sensor-based reminder, but I think it is predestined for failure in real use. I am reminded of various plane crashes and nuclear accidents where repeated—and therefore quickly ignored warning notices—paradoxically were contributing factors in the issue they were designed to avoid. I don’t know how the relevant safety agencies solve the problem, but it might take you down a fruitful path.

My suggestion off the top of my head is to combine the key with something you would never forget. For your house key, for example, you might velcro it to your shoes. I personally put my office key card inside my cell phone cover.

A design schematic of the bike rack sensor. Courtesy of Richard Smith

A few weeks back, I wrote about building a smartwatch app that finds open Capitol Bikeshare docks while in transit.

Richard Smith, 17, did me one better. (Disclosure: His sister, Rosa, is a new assistant editor at The Atlantic.) Last year, in Portland, Oregon, the teenager built a device that attaches to conventional bike racks and monitors how often they’re used, building a online heat map. It was a team effort with other classmates through Portland State University’s Innovation Challenge, an engineering contest for high school students. Here’s Richard:

People can lock up their own bikes with their own locks completely for free. The system would collect data about how often people lock and unlock their bikes, where they do so, and when. This would allow the system to build a “heat map” of the most popular locations around town, and at what times these lock up locations are most active. It would also provide live information on how many spots are open at any given location. All of this information can be accessed 24/7 via a smartphone app or a website.

To build the device, Richard used a Raspberry Pi and an Arduino—two credit card-sized computers—along with pressure sensors and a solar-powered battery:

Courtesy of Richard Smith

I’m planning to use my own Raspberry Pi for some upcoming projects. Their invention fit well with the challenge’s prompt, writes Richard:

The prompt for our challenge was “Smarter Cities.” We were inspired to work on transportation because of how bad the traffic has become in Portland over the last decade. Because Portland is already a very bike-friendly city, we wanted to figure out a way to encourage people who don’t bike very much to do so more often—and not charge them for it either.

Awesome stuff.

How did a Department of Motor Vehicles become a national symbol of government incompetence? There are plenty of theories: uninterested employees, inflexible rules, interminable wait times. But one in particular caught my eye:

DMVs have an atrocious problem with uneven demand. EVERYBODY shows up at the DMV in about 3 days at the end of the month, and the first two or three days of it. Go to a DMV in the middle of the month, and you will likely find far shorter lines. But unlike many private companies, DMVs can’t easily scale staffing up and down.

This offers a window of hope. If you time your visit right, you can beat the rush and save yourself from the soul-grinding sandpaper rasp of a normal DMV experience. But how can one understand the mysterious rhythms of America’s most-visited bureaucracy?


In this week’s project, I think I’ve found a way. The DMV in Washington, D.C., kindly provides webcam feeds of its centers, like this one in Georgetown. They’re updated every minute to show you the size of the crowd before you schlep down there.

A programming concept called computer vision could help here. Computers aren’t good at intuitively understanding images—that’s why so many of those online human-checks you fill out before buying concert tickets or something involve deciphering a line of text in a picture. But they’ve gotten exponentially better at recognizing patterns. And in this case, the DMV long ago made a decision that will make determining the relative number of people in this photo very easy: They bought those goofy blue chairs.

It’s a color that doesn’t exist anywhere else in the picture. And as the waiting room fills up with people, there’s less and less blue in the photo. By downloading the camera footage at regular intervals and counting how much of the image is colored that shade of blue, I can estimate how many open seats are still available. Here, the computer has run its analysis and colored all the blue seats bright red:

Pretty good, huh? I’ve written the code (technical blog post here), and I’m now going to let the script run every minute for a few weeks so I can gather multiple datapoints for every time slot. Once I’ve built up enough information to puzzle out DMV traffic trends, I’ll visualize the results and post in this Notes series.

No one likes to feel left out. And you know what’s just as bad? Getting locked out. But the very worst is getting locked out and awkwardly waiting for someone to let you back in, a diabolical combination of both fears that plays out at least once a week in the offices of The Atlantic.

We’re a modern, security-conscious workplace: Our office doors require employees to wave a fob over a reader before letting them into the main office. That means every time an Atlanticker heads to the elevators or uses the restrooms—both of which are outside the secured zone—they have to remember to take their keys along.

And I, for one, often forget. So I’m locked out. And then comes the awkwardness. Sometimes I pretend to be on my phone until someone leaves the office, at which point I’ll theatrically end my conversation and grab the door. But when that fails, there’s no getting around it: I’m reduced to knocking on the glass and sheepishly waiting for a coworker to fetch get me.

My second #MakeEveryWeek project seeks to solve this. The Atlantic essentially needed a doorbell. But not an actual doorbell; I fear that the incessant ringing of the Westminster Chimes would drive nearby coworkers to fits. My solution instead connects to Slack, our workplace chat client, and alerts a special channel that someone needs to be let into the office.

That this was easy to do is largely thanks to Amazon’s new Internet of Things Button, a customizable variant of their Dash buttons (which are hard-coded to order specific products) that connects to WiFi and sends instructions over the internet. My code (technical explanation here) includes a random quote about doors to Slack message—not only does the variety liven things up, but it also makes it easier to tell door requests apart.

Here’s what the doorbell looks like:

This project won’t protect me from forgetting my keys. But it will save me the embarrassment of admitting I forgot my keys.

I’ll probably use an Amazon IoS button for another project at some point—any suggestions?

If you live in the Washington, D.C., area, you’re probably familiar with Capital Bikeshare. And if you don’t, I bet the nearest American city might have something like it: A system of public bicycles available for rent, strategically placed throughout town for point-to-point trips. If you have a membership or a credit card, you can check out a bike at a kiosk, ride it to your destination and re-dock it at the nearest Bikeshare station. It’s one of my favorite things about the D.C. area.

But! There are few things more annoying than wrapping up a satisfying ride and pulling into bikeshare dock ... that is completely full.

It’s also a bummer to walk up to a station and discover that all the bikes have been taken.

Ilya Naymushin / Reuters

It’s never been easier to be a mad scientist. Back in the day, it took so much work: You had to rent a dungeon, fashion your own Tesla coils, and spend half your life reading cracked leather tomes written your equally deprived predecessors.

Not so anymore. Computers are small, fast and cheap, allowing a D.I.Y. types to slap a microprocessor on pretty much anything, and for less than $50. The internet can deliver a tutorial in an instant and any electronic component within a few days. And easy-to-program platforms have made controlling physical objects with code not only possible, but practical.

All this is great for a would-be inventor. Unless, like me, your drive to work on a project (which seemed so strong in the morning!) somehow gives way to an evening of Alias reruns night after night. Life gets in the way.

So here’s my resolution: Following the lead of WNYC journalist James Keefe, I’m resolving to buckle down and make a new thing every week this summer. It’ll ideally be a real thing—something you can see and could hold, not just ephemeral code powering an app. (Though I’m still keeping the ephemeral code door open if I hit a rough patch.) I’ll document what I’m doing through this thread, as well as more technical write-ups on my own blog. So far, I’ve built a smartwatch app that searches for nearby public bicycles and a silent doorbell for when my coworkers get locked out of the office.

Are you a time-crunched tinkerer? Please join me this summer by sharing your projects: What have you built in the past? What are you working on now? And what should I build next?