Sam Gentle.com

Everything is dollars

dollars

There's a great trick I used to use when doing unit conversions using Google's calculator. It's great for asking natural questions in units it knows about, like how long it would take to download 1 gigabyte on dialup or how many years before the Opera House is underwater. But sometimes you have an important question where you want to refer to a unit it doesn't know about, like how many sneezes it takes to fill the Goodyear Blimp.

It turns out the answer is 4.78 million dollars or, uh, 4.78 million sneezes. Dollars make a great "generic standin" unit. They're readily available, easy to remember, and don't accidentally cancel with any other units leaving you with some funny number in megahertz per square nanofarthing or something. Unfortunately, at some point Google added the "unit" unit, which works even better but doesn't feel as clever.

But something occured to me along the way: the dollar really is the perfect everyunit. There isn't a good way to convert, say, degrees celsius into metres, or seconds into kilograms. But there are tonnes of great ways to convert degrees, metres and seconds into dollars. I've sometimes run into the issue of explaining or justifying decisions to people who have decisionmaking oversight but very little knowledge of the decision domain. Or, to put it in another way, they have to check my numbers but they don't know the units.

Maybe you start off explaining that bigger monitors make programmers more productive, or that you need to buy better servers to keep the site up. But as soon as you start talking quantities you immediately run into lots of domain-specific units. How big are these monitors? How much more productive? What's the productivity per inch? You want me to pay x dollars for y servers with z IOPS? What's an IOPS again?

The dirty secret is that you can save yourself a lot of trouble if you can convert everything into dollars and cancel out the units. Figure out dollars profit per IOPS, multiply through by IOPS per dollar cost. You end up with the wonderfully unitless dollars per dollar, which is very easy to reason about.

Everything is dollars. All praise the everyunit.

Friend Compass

friend compass

Here's a nifty idea I had a while back. I've occasionally had that issue where you're meeting up with someone and can't figure out where they are, particularly at big events. Sometimes there's a landmark we can refer to, but other times I really just want something that can just tell me which direction to walk in.

My idea for solving that is called Friend Compass. It just displays a simple compass but instead of (or, I guess in addition to) showing you which way is north, it shows you which way someone else with the app is. You pick a friend from your contact list, they get a message asking them to install/open the app if they want to be found. Once the pairing is done both apps would show where the other is relative to you.

There might be some tricky stuff to get good results in crowded areas with bad GPS reception, but hopefully with not too much effort Friend Compass could eliminate the entire class of "Where are you? I thought you said near the tree. No, I meant the other tree!" problems for good.

Stack trends

stack trends

I've been running the "which web framework is everyone using now?" gauntlet again for a project, and finding the whole thing pretty exhausting. I'm sure at some point we'll figure out the right answer and stop making new web technology stacks, but not any time soon. While it's nice to see so much developer effort going into making the web better, it is tough to stay on top of.

What would be really helpful is a website to catalogue and track the stack trends in web development. For example, one of the biggest up-and-coming frontend stacks is Webpack + Flux + React. I would call that the early-2015 trend. The 2014 equivalent is Browserify/Gulp + Angular + Bootstrap. The 2013-ish era was Grunt + Backbone + jQuery. I think there are a few candidate late-2015 trends on the rise. Maybe Om or one of the Web Component-based systems (Polymer seems like the front-runner but I quite like the hybrid model of RiotJS).

A lot of this you can figure out by just paying attention to what you read on Hacker News or hear recommended by other developers, but it sure would be nice to have a concrete reference for the generations of web technology. Often each generation is a refinement or a reaction to technologies from the previous generation, so you can learn a lot from finding out why those technologies changed. Different components of the stack usually complement each other, too - advances in one area lead to new tools in another.

And aside from being able to share a common language of stack trends, probably the greatest benefit would be just having a single place to look for a complete list of new hotness to evaluate when starting a project.

Eat Your Vegetables

carrot.app

Today the topic of unpopular services being forced on you by popular services came up. Like Apple with iTunes Ping, Facebook with Messenger and, of course, Google+.

Obviously, the temptation to use one of your popular services as a lever to get people interested in an unpopular service makes sense, especially if you think people will come around once they give it a try, but the danger is that you end up suffering from what I call the Eat Your Vegetables problem.

These companies obviously think they're giving people something that will be good for them in the long run, like a delicious plate of greens. Problem is, before you've eaten vegetables you don't know whether you'll like them, so you take your cues from how they're presented. "Eat your vegetables or you won't get dessert!" is a strong signal that vegetables aren't tasty enough to stand on their own.

Sometimes a new service genuinely just isn't very good, in which case it was probably dead, vegetables or not. But sometimes it can make things worse for a decent product. By all accounts, Facebook Messenger is fairly good, but there was still a big backlash when users were forced to install a separate app. Of course, Facebook also owns WhatsApp and Instagram, but nobody's complaining about having to install them. That's the power of not having to Eat Your Vegetables.

Context table

context table

Following on from my other voice idea, it would be kind of fun to make a context table. That is, a device that listens to your conversation, pulls out keywords and searches for them, displaying a kind of passive live-updating screen with information relevant to the context. You'd need to do a bit of processing to figure out what words tend to be searchworthy (proper nouns, stuff outside the top N most common words etc), but it wouldn't have to be terribly accurate to work.

In fact, most of what you'd need to build a simple web version is just the Web Speech API generating AJAX requests to Wikipedia's API.

Obviously, the coolest thing would be if you could then turn that into a table that automatically displays relevant things to what you're talking about but, hey, gotta start somewhere.