bazoom42

This article is not about null but about NaN, a special case floating-point value which is the result of diving by zero.

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.

Try applying the same criteria to say the battle of Thermopylae. What does the Persian sources say?

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.

How so? Are the Greek the sea people then?

We dont know that.

Whould would you have preferred?

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.

Ah, that sounds like a classic mistake - rewriting a system from scratch without fully understanding what the system actually does.

Are you referring to some particular projects, or to the early stages of every project?

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.

YAGNI is not about things you know you need, because then you wouldn’t write any code ever.

How so?

Stalk their children? What policy are you referring to?

Very charitable to call it a “grey zone” to stalk and dox children of politicians you dislike.

Usually it is not a secret, but currently the prime minister and her family live at a secret address.

Probably, but note that cross-domain GET-requests have been supported since the beginning of the web, since this is literally how links works.

So while a badly implemented GET handler can indeed cause security issues, this is old news and unrelated to CORS.

(Besides, why measure response times? Can’t you just check if api/users?name=john returns a resource or a 404 not found?)

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.

It is the difference between opt-in and opt-out.

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.

CORS allows JavaScript to make requests to different domains than the origin of the page. By default (without CORS), JavaScript can only communicate with the origin domain.

“Can still talk to, but cant read the response” is a bit too simplied. You can’t post a json payload for example, which is how a JavaScript client would usually talk to a backend. You can only post using form data encoding, since this is already possible using a plain html form without any JavaScript. Anything beyound that, like json/xml payloads or methods other than post and get are blocked by default.

Example: I post “fungame.com” on Show HN, you visit it, and in the background the JavaScript calls Facebook on your behalf (using your Facebook authentication cookie) and adds me as friend.

By default such cross-domain requests from JavaScript are disallowed, but CORS allows it if the server specifically opt-in. But the check happen in the browser, since the purpose is to protect the user of the browser.

There are some weird exceptions to this, for example a client can always GET and POST data to another domain under certain constraints, since this have always been possible using HTML forms. So it is not obvious what is possible and what isnt.

CORS is counter intuitive. I don’t think there is a better way to solve the problem, it is just a difficult to understand problem.

CORS errors occur when JavaScript in the browser attempts to call a server which is not configured to allow it. But the check is purely client-side. You can circumvent it entirely by using curl or whatever outside the browser.

For example the server sends a header indicating which domains it allows requests from, but it does not actually check if requests are from those domains. It is the responsibility of the client to check its domain is allowed.

All this make it seem like a pretty useless security feature, unless you understand the very specific kind of attack this protects aginst.

Not questioning the particular finding, just wondering in general. E.g when linear B or hieroglyphs were cracked, you could check angainst other untranslated texts and see if the translation still made sense.

I wonder how you would even know if you have “cracked” it, given the corpus is so small?

Still comes off as rather condescending, honestly.

Why not just explain the thing that needs explaining.

The comic explains it better: Don’t act surprised if sombody doesn’t know something - even if you are genuinely surprised.

I think it's generally best to be open in communicating with others

I’m pretty sure you wouldnt blurt out “you sure got fat” in a buisiness meeting, even if it genuinely was the first thought which popped into your head. Not every thought or feeling need to be communicated.