daliwali

This is expected in some fields such as embedded programming, it's reasonable to look at source code just to figure out how hardware works. Or web front-end where you shouldn't be sending huge payloads to the browser anyways. You don't always need to look at the lowest level, just direct dependencies.

I'd settle for consistent, predictable, and cheap. Generic doesn't matter if it solves my specific problem and ubiquity is a social problem. Enterprise pays a lot for bespoke solutions as well.

A very good reason to write your own software is if the problem is novel enough to warrant it. I'm not advocating that there should be n+1 JSON serialization libraries.

The point was more about popularity having no correlation with anything else. There is tons of unpopular code that is really, really good, these are hidden gems. Likewise, there is popular code that is quite bad or mediocre regardless of number of contributors.

To rephrase: PHP is the most widely used server-side scripting language on the web. That does not make it good.

Popularity is not an indicator of anything other than popularity. McDonalds is the most popular burger sold in the world, that does not make it good.

Length is an important consideration and most never consider it, partly why software is notorious for getting bloated over time. At some point it would be easier to rewrite code from scratch with less complexity and overhead.

Here's an overlooked one: your dependencies.

Every programmer should read the (presumably open source) code they depend on, but almost nobody does it. Some look at documentation, but not everyone even does that. What you may find is that some of the code you depend on is garbage, and may even motivate improvements.

This may be less feasible for giant messes such as most front-end tooling and frameworks that exist today.

A practical benefit for using JSON-LD in API development is being able to link every field in the response directly to a definition, ideally a shared one such as schema.org. This overlaps a bit with definition formats like OpenAPI (Swagger), RAML, et al, but to completely replace those, you'd need a media type that documents the API semantics.

It's possible to use JSON-LD in an opaque fashion by remapping all of its reserved keys to whatever your JSON looks like, i.e. from "@id" to "href" which is more familiar. It doesn't have to look like an ugly mess of "@" prefixes, for example: http://micro-api.org/#finding-resources

(disclosure: I am the author of Micro API)

Nobody has brought this up: why should we trust proprietary software running on the vendor's server? And more practically, how can we expect this service to be reliable in the future (related: Parse shutdown). I think this is a disturbing trend that more and more things that used to be open and on premises, are moving to the cloud/serverless/microservices hype.

The biggest anti-pattern of all: marketing your API as RESTful, when it is really more RPC-like.

I agree on all points of this article. The only nitpick I have is that tunneling through GET/POST is strictly necessary for HTML forms, since they do not support other verbs.

REST actually has nothing to do with HTTP. It happens to map nicely to HTTP, but what it really is, is a set of architectural constraints.

I double checked my codebase and it looks like it's just JSONB, which CockroachDB also doesn't support [0]. Sorry to bother about missing features, but there are really some things that prevent a smooth transition from Postgres.

[0] https://github.com/cockroachdb/cockroach/issues/2969

CockroachDB looks like a great alternative to PostgreSQL, congrats to the team for doing so much in such a short time. The wire protocol is compatible with Postgres, which allows re-using battle-tested Postgres clients. However it's a non-starter for my use case since it lacks array columns, which Postgres supports [0]. I also make use of fairly recent SQL features introduced in Postgres 9.4, but I'm not sure if there are major issues with compatibility.

[0] https://github.com/cockroachdb/cockroach/issues/2115

I think abstract, non-empirical knowledge can be useful. For example, all of mathematics. It is unreasonably effective at modeling nature, there is no reason why nature must adhere to abstract mathematics. For example the invention of the imaginary number preceded its explanation of alternating currents.

I disagree with the claim that "pseudo-science" as you call it is used to discredit the establishment. Rather it is exactly the opposite, the establishment uses the label to discredit outlandish ideas. Every scientific theory starts off as hypothesis and maintains falsifiability, to accept it as dogma is worse than not exploring other ideas.

A variation of this already exists, called the Cognitive-Theoretic Model of the Universe (CTMU) [0]. It is dismissed by critics as not being based on empirical methods or pure reason, which is what it's getting at: science isn't the answer to everything. Some questions can't be answered by reason alone, mind-body dualism for example.

[0] http://www.ctmu.org/

I hold a degree in mathematics. Small-minded HR drones have told me I'm not qualified to do programming since I'm not formally trained in computer science. I have been doing this since I was a kid.

Don't listen to them. Every professional will at some point in their career be judged by those less capable.

I was interested in learning Rust as a safer alternative to C a few years back, and have been observing its progress from afar. I'm much less optimistic about it now, though I only have a layman's understanding of it. The language seems to be more cumbersome to write than many other languages due to its design choices. It may be safer, but not as "ergonomic" subjectively, which ultimately affects productivity. It's hard to think of a good reason to use it, other than the safety features.

Every single one of those websites use HTML, a common media type, with semantics defined in that standard. What's missing are the application-level semantics like what's a "flight search" and "flight booking", which can be solved with linked data. In fact, this already exists! [0]

In theory, using a common media type and linked data vocabulary, one can make this hypothetical scenario of an automated machine-to-machine flight booking system happen. In practice, it requires either changing how people think, or build APIs to begin with. It's a steep uphill battle to change how people think, making this happen is much easier.

[0]: https://schema.org/FlightReservation

APIs defined in XMLRPC, CORBA, SOAP, et al, can have clients and servers implemented by anybody.

Programmers don't seem to learn from history and struggle with thinking over time. These formats worked well in a time when a single party (or second party) controls the server and client, when services were very consolidated. Now that the web is becoming more and more centralized and closed, it follows that RPC is making a comeback: widespread interoperability is not much of a concern.

A good rule of thumb is that if a REST API has an SDK, then it's not really RESTful in the first place.

SDKs are an enormous effort to create and maintain for every HTTP API, I think it's a malpractice that is all too common.

Browsers (and by extension, websites) are not good examples of REST in practice? I don't know what world you're in.

Actually gRPC is about the same as other HTTP based APIs, it is just a more efficient RPC. All of them are lacking what made the web scalable in the first place.

- HTTP APIs are worse than websites of the 90s. At least a browser could be expected to view a few websites. HTTP APIs require a custom client for each one.

- Document media types, not APIs. This isn't such a novel concept, browsers (fancy HTTP clients) work because HTML is a standard.

- Standards at the application layer, not specifications. You mentioned specs only.

Let me just clarify that RPC is a great fit if you are constrained to a single vendor and don't care about third-party clients. On the web, every browser is a third-party. For HTTP APIs to take off, they need to be built more like websites, or else vendor specs will fill every niche.

I made a small mistake in the first point, got downvoted to oblivion and people seemed to stop reading there: the binary serialization indeed has backwards and forwards compatibility. However, the textual serialization lacks this compatibility. I can't remember a petty detail of a vendor specification apparently. Pedants with encyclopedic knowledge of Google are out in full force today!

I should have stopped at "coupled server and client", the point is that they both rely on an agreed upon external schema since the messages are not self-descriptive.

RPC has its own set of limitations, which if your application qualifies, might be a good fit:

* Coupled server and client. gRPC uses protocol buffers which have zero backwards compatibility.

* Zero discoverability. The client knows in advance what the server can do.

* No standards to follow. You make up your own specs, like Google did.

These constraints are orthogonal to REST, the architectural principles behind the web. What they're doing is tunneling RPC over the web, which is what most HTTP APIs are doing already. There are only superficial differences like the use of protobuf, lack of verbs and URIs, etc.

Most servers don't need to handle anywhere close to Google traffic and some downtime is acceptable -- the network is more unreliable. Sacrificing 0.001% uptime and "scalability" (whatever that means) is worth it.

Many important concepts start as unknown, and then once explained in great detail, seem plainly obvious. It took a lot of reasoning to convince people that in fact zero is a number (but zero doesn't exist!) and now it's taken for granted.

>...until employers start asking you to work on every buzzword of the month.

This is absurd. Do you do everything your boss tells you to?

It's incredible that some employers survive long enough to chase the next fads, which only proves my point.

I think all of this serves to highlight how valuable information technology is right now. People can get away with massive inefficiencies, producing tons of garbage code, not-invented-here habits, horrible performance, and still run a profitable company. I agree that hype-driven development is bad, but instead of complaining about it, just don't do it. Run circles around those who do.

I have my own theory about why hype-driven development is prevailing: it's social signaling. Probably none of the hyped up stuff is as good as they claim, but nothing is cool without hype. It's a good way to attract younger developers in job postings, who lack the experience to evaluate their own career decisions.

I'm also not sure about the solutions proposed. Spikes and hackathons are useless if it's already determined that a hyped technology will be used, then it just serves as a training exercise. A strong technical background and experience comes with age, and this industry is heavily biased against older programmers.

More sophisticated ways to reject connections rely on heuristics and may result in denying legitimate requests. I don't have all the answers, I'm just suggesting a way that doesn't consider all requests equal.

Every CORS pre-flight request uses the OPTIONS method. It is also used to advertise which methods are available on a route.

One could limit concurrent connections per address. The idea is that an OPTIONS request which doesn't take much resources at all could be treated with a different weight than a POST which costs the server time to process.

I think rate limiting is the wrong idea. Say for example, a client wants to re-fetch everything that it has cached, it may send a burst of requests in a short amount of time, and some of those requests may be wrongly rejected due to rate limits. This is what happens when a browser refreshes a page for example.

A better approach I think is delaying request handling based on resource allocation. If one client is disproportionately using up more time than others, then processing that clients' request will be queued up to process later, while well behaving clients will get their requests handled quickly. I think this is a more realistic approach and imposes less arbitrary restrictions.

This seems to be a thin wrapper for the actual Lua VM implemented in Go: https://github.com/yuin/gopher-lua

I both agree and disagree with the premise that programming is a creative process. Donald Knuth calls programming “an aesthetic experience much like composing poetry or painting.” The most creative work can be done when it's not clear if something will work or not, that is it might fail, and it requires the ambition of a mad scientist to succeed. The individual programmer must have autonomy and not be micro-managed or ruled by a committee, otherwise they will resort to being creative in ways that are petty and insignificant, like naming conventions, syntax formatting, arbitrary rules, etc.

99% of programming jobs are not creative jobs. Most problems aren't that unique, and most programmers work within well-established boundaries and frameworks. Step out of line or take unconventional risks, and you may find yourself unemployed. This is not necessary bad, it brings stability, but also stagnation (it is why enterprise IT culture is so soul-draining, from first-hand experience). Not only enterprise but many startups operate this way. There is overwhelming cognitive bias towards doing what other people are doing, which will only lead to the same results.