HN user
yea that's an odd example to pick. expecting type conversion to add meaning to strings is a programmer problem not a language problem. really comes down to developers not thinking about types and their meaning anymore.
there are plenty of javascript examples that are actually weird though, especiall when javascript DOES apply meaning to strings, e.g. when attempting implicit integer parsing.
And a `git remote add name url` and you are setup to use another remote server.
Even if that's a concern in a doomsday scenario, self-hosting gitlab is super easy and a good (some would argue better) alternative.
It has an export function that you can scan from an old phone. And I kept the setup keys in my keepass database.
On top of that now Google backs those up for you too.
Not sure if that's actually your question, but GLSL is the language https://en.m.wikipedia.org/wiki/OpenGL_Shading_Language
Seems like a rather easy thing to go wrong in the client, no?
User sends message via client. Client fumbles the recipient id. Message ends up at the wrong recipient.
Examples: incorrect recipient ID attached to contact in list where users selects recipient. Buggy selection of multiple targets in the selection UI due to incorrect touch event handling. Incorrect deletion of previously selected and then deselected recipient from recipient array of multitarget message. Or if working low level even a good old off by one error and reading out of bounds data for the recipient list (though that one hopefully should trigger a faulty send request due to other stuff no longer matching). There is endless examples.
The server can't really safeguard against the client providing a legitimate send request even though the user intended to send it to another recipient.
I'm not sure if I missed a bit here, but I have some colleagues doing research on unikernels for HPC and the point is that this unikernel is running directly on the hardware or hypervisor and not inside another VM. The unikernel is effectively a minimal VM and the network stack is one of the things they struggle the most with due to sheer effort.
JSON for something that essentially mirrors a shell installation process? Feels like you are trying to reinvent things with a golden hammer, not like actually making it easier.
If you read closely I am not talking about the limitations of GPT, but about the limitations of the developer having to fix code of others (GPT essentially being another developer). I guess it depends on the complexity of the problem. A lot of stuff is very easy to review and for me other stuff needs more time to understand than it did to write.
You're working under the assumption that you will be able to find the errors. I personally found reviewing code always way harder than writing it and we already push tons of bugs to production in written+reviewed code.
It's more like not using semi-autonomuous driving features with the car entirely relying on your expertise to realise and correct when it's making a mistake. The main difference is risk. Your own life at stake versus bugs in some production system.
Due to the nature of my current work I haven't really used GPT for coding yet, but I keep wondering isn't it easier to write code than to read and truly understand it? So how much development time was really saved, if I still care about off-by-one errors or correct identity checks in hash maps or all those edge cases I probably should care about? Those are all things much harder to spot reading than writing the code.
So I keep wondering if we just save time by introducing more unknown bugs using GPT?
I guess this also has a lot to do with what code is written. I would be much more concerned with a system level C++ library than some JavaScript CRUD.
Fair enough. I lost track of the correct comment chain there.
According to the RFC's PUT can be used to create a resource as long as the request has a clear target. That doesn't necessarily mean an ID, but just some kind of identifier (composite key, hash of content, url, etc.). When a create instead of update happens the server should respond with a 201 CREATED, which should indicate the location or identifier of the created resource.
Aren't you basically describing that you want idempotency?
The RFC 9110 (and also the old 2616) clearly state PUT is idempotent while POST isn't.
9.3.4 PUT
"The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation. The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics, whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. Hence, the intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server."
9.2.2 Idempotent Methods
"Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection is closed before any response is received, then the client can establish a new connection and retry the idempotent request. It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ."
It's not part of RFC 9110, so why should it be included?
Yes, as a long time Thunderbird on Windows user I second this.
Until it's the German bureaucrats that ruin your day.
This is an international issue and a national answer doesn't solve it.
For what it's worth my first name is also not accepted correctly (it contains a hyphen) and I never had a problem so far. But every time an airline asks me to put my name exactly as in the passport I cringe.
The article makes that point. There is no law to put a giant banner that disturbs UX in your users face. Companies choose to do so. There only is a law that prevents companies from tracking you without consent.
I don't think we should abolish time zones, but he isn't making good points.
His points are based on conventions that exist because we use local time zones and he uses a lot of English centric bias in his argument.
His first point of am/pm is already a bad start considering a 24h clock is simply advantageous and used throughout most of the world.
Finding out if he can call his uncle would be as easy as looking up daylight times instead of time offsets/local times. And even then the cultural conventions of your country might not map to his and it was still inappropriate to call.
The problem with business hours and overlapping days is entirely made up, because he wants to stick to previous conventions that worked well with local time. If a night club opens Saturday from 19:00 to 05:00 it's perfectly clear that means it's open till Sunday 05:00. It would work similarly for business hours. The regular business hours also differ vastly in different cultures and jobs! The day name is of course UTC based and wraps at 00:00UTC.
I play an international online game that wraps days at 00:00UTC and we communicate in UTC. If I say Wednesday 14:00 UTC it's perfectly clear what that means and you get used to that very quickly. If we would change the system the next generation would grow up with that system and it would be natural. And I find it much easier to remember that my Korean friends are available from 23:00 UTC till 16:00 UTC than to remember what time it is there right now compared to here, because that requires mental math or a lookup.
I've seen ChatGPT translate English to German miles ahead of what Google translate does.
Like an English satirical poem to perfect German. Changing the literal translation to keep the meaning and sarcasm of the poem.
it's the 30 day uptime statistic displayed on the website I linked.
if you click the history it says 98.452% over 365 days.
The second one is just a standby though and not in another region. And if I recall correctly dang mentioned at an outage that the failover to the standby is manual. But I'm not sure.
Does 99.995% [1] of hackernews sound reasonable enough to you?
The reality is a lot of systems (especially simple ones) run perfectly fine on a single server with next to no downtime and all the additional redundancies we introduce also add additional points of failures and without the scale that makes these necessary you might actually end up reducing your availability.
To be fair, I would say if your task is to design a system it's your job to find out what the person actually wants and not run with assumptions you made based on a bad description. The reality is that you will usually start with a bad description. So I'm not sure if these misunderstandings actually reflect that badly on the interviewer/the question.
"So what scale are we talking about? A few million monthly users? So like hackernews? I would use a single server... "
Because primiparas describes the women that give first births and not the first births themselves. The abstract uses regular English and introduces the term. Otherwise they would have to write "women with first births" all the time.
It feels like they just tried to be concise and not just throwing them in there to sound smarter.
Nulligravida = not been pregnant
Menarche = first menstrual period
I assume it would be less about the dominance of passanger displacing freight and more about scale/distance. Germany is smaller than Texas (half the area). How often is it economical to put stuff on trains before loading them on trucks again for distances sub 1000km?
He was removed from the board though. This isn't entirely voluntary and out of the blue.