This article is somewhat misleading. Although the image caption says Nominal GDP, the bottom of the image says the GDP is in PPP terms.
AFAIK the most optimistic estimates make India the second largest economy in nominal terms measured by exchange rate no earlier than 2050.
India is expected to be growing pretty fast. But nowhere close to the rate which would be needed for this to be true in currency exchange rate terms. PPP terms really doesn't mean much.
The NoSQL hype happened because people wanted to explore and promote alternatives. The NoSQL name happened since there was a need to provide a moniker to the alternatives. Since this was a hype and movement based on otherwise real need, it is likely to have happened even if the name was something completely different say FreeQL (or whatever other catchy name). The post isn't arguing there shouldn't be a name. All it is attempting to point out is that it should be a meaningful and appropriate name - else what you think (when you hear the name) and what you get (when you actually dig into the details) are very different. The current name actually makes it harder for newer participants to properly grok these storage systems - which wasn't perhaps the goal in the first place.
Yes indeed, I totally agree that there is a feedback. Something starts to be interesting, then people start to talk about this thing and it's comfortable to name it in some way. Then some name will arise and the discussion will move even faster. Eventually the field gets names for every important concept, and so on...
Still there is something "magic" in this process. Once you get a name for one thing, it starts to get much more obvious. For instance think at the "web 2.0" or "Ajax" cases. NoSQL, in the name itself, is the negation of something else, and this allowed to collect a number of different projects under this name.
I think the blog post clearly mentions that there is indeed one standardised resource management service for REST over HTTP, and given its simplicity and ubiquity, that particular standardised service orientation is uninteresting and largely ignorable.
When I find someone disagrees with me I tend to either try to elaborate on my point or present a counter point to their argument. Not just quote what I've already said. You should try it
You introduce aspects orthogonal to the post argument which is why the post does not even attempt to address them and you seem to think the author doesn't grok them.
HTTP method + a Unique URI are the essence of the Uniform interface constraint of REST. They are very much a part of REST. How the real world uses them has no bearing on their validity. This has to be managed by better informing the real world not by questioning the very notion itself. Linking via hypermedia is an essence of the HATEOAS constraint of REST. Both are orthogonal yet complementary aspects of REST. A discussion can be had about one without necessarily talking about the other as this blog post does.
On the other hand transparency vs. opaqueness has nothing to do with REST API design per se. All REST recommends is that clients shouldn't design themselves to assume specific semantics into the URI substructure nor should the services guarantee them. However structured design URIs do not at all fall foul of REST from an API design perspective, and help both development and debugging substantially.
I suspect you've introduced both issues related to Client API usage and used them to question serverside API design. The issues are not incorrect but the level of abstraction at which you choose to address them is something I would differ with.
And I'm sure I nailed first three but have no clue about the fourth. tried characters and numbers. Not sure if numbers should be attempted forward or reverse.
I have the deepest respect for you and your writings, but exactly how much maximum code coverage have you achieved and sustained for at least a month using automated unit tests ?
Just wondering how long you've visited the region you're writing a travel review about.
Unit tests are about confidence in the software. Automation is the mechanism for sustained confidence. Engineering (and / or fad as you put it) is a vehicle to get there.
You can have 100% code coverage, and still not be testing anything. Unless you're testing thoroughly the right parts, they're a false sense of security.
I agree with that. Its just an (imperfect) proxy measure of the depth / extent of unit testing. Asking how much code coverage is likely to give a better reflection of the effort behind unit testing rather than just a - "have you done unit testing".
Ok. Here's a hypothetical (actually no longer such a hypothetical scenario). The shareholders are the tax payers in a financial institution where the employees have been quite handsomely paid till now. Who gets paid first - employees or shareholders ?
AFAIK the most optimistic estimates make India the second largest economy in nominal terms measured by exchange rate no earlier than 2050.
India is expected to be growing pretty fast. But nowhere close to the rate which would be needed for this to be true in currency exchange rate terms. PPP terms really doesn't mean much.