75MB/5 sec benchmark results (using internal AWS network to pull from S3!) sound dubious. You can get 4Gbps+ down from S3 within the same region in my experience, that's 30x faster than these numbers.
I've built this page since I often just want to pick a spot instance type that gives me biggest bang for the buck. Amazon's own pricing page is still very confusing, and ec2instances.info is great but it is a static website and adding spot prices there is nontrivial.
I've also fixed a few minor things that annoyed me, such as correct sorting by instance type (so that r3.16x goes after r3.4x) and added a mode to display spot savings vs on-demand.
> Another mistake was that when originally released Python 3 did not offer enough shiny new things to convince people that going through the pain of upgrading was worthwhile.
This is the core issue, but you're putting cart before horse a bit: if there's not much to gain from switching, why would any reasonable person switch? And, most importantly, why is it a problem that needs solving at all?
That one sounds fairly similar to manslaughter, no?
My understanding is that logically there's that basic framework of required specific intent, then there are a few crimes that allow prosecuting for negligence, then very few crimes with strict liability.
I'm originally not from US so I'm probably still getting used that the latter two categories are quite common in US law (and that strict liability is even possible).
Come on, if that was true they would never be able to hire tens of thousands of engineers. They do have high false negative rate (by design) but it is far from impossible to pass. I personally know a ton of people who were hired by Google after standard interview process.
So of course I'm generalizing, not everyone is like that, not everyone's CS degree is like that, etc. etc. Also, more true for recent grads.
But in my experience people with advanced "pure CS" degrees seem to be focused on the process not the result. I mean, they went to CS because they like to tinker with type systems, elegant algebraic concepts, nice abstract problems -- and not just as a hobby, they like it so much so they commited several years of their lifes to do that. Not that this is bad area of research, but generally when you look for a software engineer you look for someone not only smart but also pragmatic, who can get stuff done in a simple and efficient way, and this is kind of the opposite.
Of all PhDs, in my experience people who have degrees in areas that use programming as a tool not the goal in it self, e.g. physicis/EE, make the best software engineers.
Frankly it is a bit weird way to describe it. It is not some quirks of liquidation preferences that "ruined" it.
It is ruined by a simple fact that this hypothetical startup earned just 50 cents for every dollar raised -- I don't think anyone should expect a nice payout here.
Google/Facebook/Apple may not be as concerned by this as you may think; strategically, they would probably be happy if slow decline of advertising income on desktop would eventually make every publisher to move to walled gardens of mobile platforms, completely controlled by them.
You may end up with a world with nearly unblockable, more creepy ads, and no more open web as we know it today.
You can't really use KD trees with lat/lon coordinates, at least you can't use euclidean distance there for nearest neighbor search.
First, longitude wraps from -180 to +180 at antimeridian, meaning distance calculations will fail there; second, and I'd say more importantly, one degree longitude length in meters differs a lot depending on latitude; meaning this library will be heavily biased towards longitudal neighbors when using it for locations far from equator.
As an engineer with ten years of software dev experience who interviews quite a lot of candidates for my current team, I'd say don't overthink this.
BigO, data structures and having a good idea how computers work, what matters for performance both from theoretical and practical perspective, matters infinitely more to us that knowing how to play object-oriented BS bingo or subversion usage patterns.
If you know what MVC stands for, you're know enough about OO patterns to me.
Not going to argue that we got it right way(tm), just wanted to give you another perspective.
While all maps like this tend to make little practical sense since they inevitably over-generalize and over-simplify things, I'd still like to point out that they got "columnar" category quite wrong: neither HBase nor Cassandra are columnar stores in a way this term is commonly understood.
HBase and Cassandra still store data in rows, however rows can be partitioned into column families which may be stored separately. Columnar databases are usually also relational (Vertica and Redshift) and support SQL or SQL-like query language.
Anyway, I think regardless of how you define columnar, HBase and Redshift shouldn't end up in the same category as they are quite different in a way they work, throughput/latency and read/write balance and use cases.