Likewise. Machine names are there to make your life easier. Cute names aren't fun when you have more than a couple. When your brain's as small as mine, you have to minimize your lookups.
Vistar Media is company building some neat stuff in the "Digital Out Of Home" space. Right now, it's just us three founders -- two of which are coming from Invite Media, which was acquired by Google in 2010.
We're looking to make our first few engineering hires. Specifically, someone relatively experienced to work on our backend bidding and reporting infrastructure, and someone to focus on the webapp which customers interface with.
We have a recuriterbox page at http://vistarmedia.recuriterbox.com, but feel free to contact me directly if you have questions, or would just like to know more.
Not quite a mental calculation, but still in the spirit: One rough estimation I often find myself using is that a US dollar bill is six inches long. Using either folding or flipping, you can approximate most distances in the wave-your-arms-about scale. Be it thinking about a new physical device or ball-parking blinds at Home Depot, I use this all the time.
Google does an interesting engineering interview. The best advice I can give:
1) Read the first couple chapters of Introduction to Algorithms (Cormen et. all) enough times to know it cold. Something in there will come up.
2) Dedicate a day or so to browsing pertinent Wikipedia articles. Simply read as much as you can.
The former gives you some depth. The latter, breadth. Outside of off-the-wall Wikipedia articles, you should not be discovering anything radically new. If all goes to plan, you should be able to answer the bulk of the straight engineering questions. If you're lucky, one of them will click with a Wikipedia article you've just read. See: Fragmentation, Skip Lists, Virtual Functions, whatever. Read lots. Even if emulated, breadth counts.
If you get lost on step 1, this isn't the job for you (right now).
I have been horribly burned and disfigured following this advice. It's important to keep in mind that just because it's unlikely the spot price will go above the reserve price, there's nothing from preventing that. It has in the past, and it will again.
The important take away: Don't use spot instances unless you are 100% okay with the idea that your machines will disappear without warning at some point. Let that sink in.
We've been running hundreds of instances on EC2 for a couple years, and have never seen one just "go down." However, we will get notifications of "degraded instances." When an instance is degraded, you have some window (generally a couple days) to move the services running on that instance to another one. Even at the aforementioned scale, this happens maybe once every three to four months.
Can you use this as a VPS replacement? Probably. My guess is that your uptime will be no worse than some VPS provider. However, if you're storing information on the ephemeral storage, the onus is on you to get it to the new instance. I imagine that isn't generally the case on a VPS.
You may be able to mitigate this by using EBS (required in the case of these micro instances), but I've only used EBS a handful of times, and am no expert on the subject. If I understand their layout for these micro instances, it would simply be a matter of spinning up a new instance and spinning down the degraded node.
The Linux kernel (Popular. Not hot nor trendy). Over the past 12 months, I've touched Redis, Node.js, Clojure, and a few others on this list, but nothing blows my mind more than learning a new system call or OS feature.
Learn the exact copy on write semantics of forking (What happens to file handles? Threads? How does the OS know a paged needs to be copied?), copy two file descriptors with splice, put something in shared memory, move messages over an IPC queue.
Above is an overview of how the Scala compiler attacks this exact problem. Long story short: It is able to grok just enough Java to build a basic AST and resolve circular dependencies the same way it handles one in pure Scala.
The article also hints that Groovy has similar capabilities.
A self-contained issue tracker. I switched from hand-hacked TODO lists to Ditz a few weeks ago, and haven't looked back. I'm able to organize my tasks as I would a codebase (components, releases, comments, et cetera). I saw an immediate and sustained increase in my productivity.
I had actually tried to do this exact thing. Problem A is that you can't execute very much in a clients browser at any one time. Okay, so you make the jobs smaller and fetch more. Problem B is that it turns out that by the time you've pulled the data from disk, shipped it to the browser and back, put it back to disk, and done the same cycle for the reduce, it ends up being cheaper to stream 64M HDFS blocks around EC2.
That doesn't even get in to verifying results from an untrusted client.
Obviously a bit off topic, but his graphic representation is astounding. Though not quite a Tufte archetype, I gleaned more insight from the image than the article. Very well done.