> So what we have is writings written hundreds of years later documenting an event with no earlier writings verifying that documentation.
Unfortunately, this is the case for much of ancient history. Doesn’t mean nothing happend, just that it can be difficult to figure out what is myth and what are actual events.
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.