Yes, a lot of people like a large screen. So since they're doing two sizes, why not make one of them small, or at least medium, instead of one large and one ridiculously large?
If by 'people' you mean English speaking North Americans, then you're probably right. In (all?) other English speaking countries, Autumn is the term used, and fall is only heard on American and Canadian TV shows and films.
Congratulations. I just don't speed or run red lights. Simpler, safer, cheaper and less restrictive.
The rules of the game are clear. Malfunction voids all games. That works BOTH directions. That means neither side whens in the case of an error in the machine.
So they will be refunding money to everyone who lost money on this machine?
My six year old *Vista* PC
Get out. *taps foot impatiently*
Differences between DynamoDB and GAE Datastore
One major difference between GAE Datastore and DynamoDB is that GAE supports single and multi property indexes while Dynamo does not support indexes at all aside from a table's primary key. GAE datastore supports efficient queries that use the indexes (if you try to run a query that does not use an index it will fail) along with some basic predicates like equality, inequality, greater than and less than expressions, etc. In DynamoDB, if you want an index, you have to build it yourself in a supplementary table.
GAE Datastore Self-Merge Joins
GAE datastore also supports what they call "self-merge joins" which are super powerful. I don't know if any other schema-less datastore has this.
DynamoDB Purpose
The main reason one would use DynamoDB is when they need scalable throughput; in other words, when your needs for write and/or read speeds fluctuate drastically and when you know you will occasionally spike to extremely high throughput requirements. For times when you expect to have huge throughput for writing, you can pay to scale for that small period of time and then you can reduce your costs by throttling down to a more sane limit. You can run MapReduce jobs over DynamoDB tables using Amazon Elastic Map Reduce. And you can also copy a DynamoDB table into an Amazon Redshift "warehouse"; once the data is copied into Redshift you can run efficient SQL queries over it and Redshift can efficiently do that over petabytes worth of data.
MongoDB
MongoDB, on the other hand, is a "schema-less," document oriented database that is good for organizing clumps of information as a single "item" in the datastore. So for example, you can have a single book document which contains nested information about its authors, keywords, reader reviews, and statistics about word usage in the book....all in a single mondodb "record." This is essentially impossible in DynamoDB (unless you do what the previous article's author did by storing an object graph as JSON within a single column but this is kind of misuse). Mongo also provides indexes on properties in those documents (even nested properties) similar to traditional RDMS indexes on table columns. It has very good support for clustering and it's very easy to setup. MongoDB is very fast therefore it is good for applications that intend to be very write-intensive. I believe this is one of the main reasons that people compare it to Dynamo. However, it is easier to scale Dynamo since you don't need to standup any additional servers yourself. MongoDB does not support transactions; operations on a single document are atomic but the database does not provide any native mechanisms for performing an atomic modification to two or more documents (you would basically have to implement 2 phase commit yourself). MongoDB has a powerful query language based on javascript/json but personally, I find it extremely painful to use compared to SQL.
For the TLDR-crowd:
I am not familiar with CouchDB but I think it would belong in the MongoDB family.
The key elements in human thinking are not numbers but labels of fuzzy sets. -- L. Zadeh