As far as I know we have no Persian sources for the batte of Thermopylæ. Historians also agree that Xerxes couldnt possibly have had a million man strong army.
Does this mean the war is entirely fictional? Ancient sources tend to be strongly mythologized, but “entirely fictional” is a very strong claim.
The point of art (like music and litterature) is the art itself. Code is a craft, it is means to an end. It can still be beautiful and impressive and creative, but it is a different thing.
It is not a value judgement. Art can be bad or bland and code can be a work of genius. But the moon lander or a handmade watch are beautiful because they actually work. It can’t really be compared to music.
Best solution: Learn SQL and understand the relational model. Learn data modelling and normalization. Then choose a good ORM which does not get in the way, but saves a bunch of boilerplate code.
The article refers to the astronomical calendar, which is differnent from the gregorian by having a year 0, which makes calculations simpler. After year 1 the years have the same numbers, but before 1 they are off-by-one.
Years before 0 is indicated with negative numbers, e.g -50 corresponds to 51 b.c.
Depends. If the abstraction is just a level of indirection, then it is usually pretty simple to eliminate - just hit “inline function” in the refactoring tool a few times.
On the other hand it is pretty difficult and error prone to consolidate duplicated code which have drifted apart over time.
If in doubt, chose the approach which is simplest and least risk to revert if you discover in the future you made the wrong choice.
I do agree a bad abstraction can cause huge problems. But it’s usually not the kind of abstractions introduced to eliminate code duplication, but the kind of top-down “architecture astronaut” abstractions, where a model is chosen which does not fit the complexity of the problem.
You are kind-of both right. The spec defines a subset of cross-domain requests called “simple requests” - basically such requests as has always been supported by a plain html form. These are not affected by same-origin or CORS. So you can post url/form-encoded data to a different domain - but you cant access the response.
But CORS affect all other requests, e.g POST using JSON or XML content type, and all other methods like PUT, DELETE, PATCH.
So you can do an unsafe POST using form-encoded data, but if a server supports this, they hopefully mitigate CSRF, since this has always been a risk.
Servers certainly can (and probably should) check request origin. But it is not something they usually do, since cross-domain requests from JavaScript wasn’t possible before CORS.
If support for cross-domain request were introduced in browsers without requiring opt-in from servers, most sites would not be prepared against this new risk. It would open massive security issues across the web.
Yes, the original CSRF attack using a plain html form does not even require JavaScript. CORS does not address this scenario.
But cross-domain post is only allowed if the payload is form data encoded. A Json payload from JavaScript would be blocked by default, as would other methods beyond get and post. Therefore you usually don’t have to worry about CSRF for a JavaScript API.
CORS is a a way to enable cross-domain calls from JavaScript without introducing the CSRF issue.