HN is full of noobs loudly proclaiming what they don't know is true these days. Ubiquitous HTTPS does not change the nature of private browser caches, and only nullify the proxy related cache headers if the origin encrypts traffic all the way to the client, which is quite rare in real life, unless we are merely talking about a dude serving this blog from his basement computer.
In general, your answer depends on where the TLS cert terminates. In most situation a CDN or a reverse proxy is involved, and the TLC cert you use to encrypt traffic from the origin to the proxy is different from the one the proxy uses to encrypt traffic from it to the browser. Whenever a MITM intermediary is involved, you should read the intermediary's documentation. These usually include Cloudflare, AWS Cloudfront, Akamai etc. With with exceptions, like the Vary header as pointed out elsewhere, these vendors largely follow HTTP caching semantics for proxy caches.
Oh you mean something like active file awareness and selection context? This code seems quite well architected and has websockets well integrated, both features sound like a lunch break’s worth of work if you file a ticket. Other than that, I couldn’t care less about how these capabilities are implemented or whether /ide works.
While I'm happy that simultaneously there are at least 5 known Emacs/Claude Code integration packages, with seemingly 2 or 3 battling it out on Reddit and elsewhere, I feel like the best implemented one is the quiet one that no one has ever talked about.
The UK has a petition website. It logs the signatory by constituency. Once a threshold os signatory has cross, the government has to respond and parliament will have to consider a debate on the topic.
I swear if I see another "SEO" guy or some rando web dev who joined the workforce after Covid complaining about SPAs by misrepresenting it, I'm gonna explode.
As someone who's been developing web apps since the 2000s, let me tell you the origin of SPA has few things to do with the "false promise of SPAs" he listed, but largely due to companies in the late 2000/early 2010s wanting to go "mobile first". This usually meant they still had a desktop second somewhere, which implied they were architecting the entire system to completely separate the frontends and the backend.
Before, what web devs meant by frontend was essentially server-side rendered HTML templates with perhaps a little bit of jQuery running on the client-side. Now, since mobile and desktop web apps are to share some business logic and the database somehow, people had to rediscover REST by reading Roy Fielding's Phd dissertation that inspired the original HTTP. This meant now every company was moving to service-oriented architecture and started exposing their backend APIs onto the open internet so their mobile apps and SPAs running in the browser can share the same APIs. This was a cost saving measure.
This period also coincided with the steady decline of full-stack webapp frameworks like Ruby on Rails and Django because for a couple of years, these frameworks had no good ways to support an API only applications. Django hadn't even reached 1.0 back then. This was a time when NodeJS was really starting to pick up momentum. Once people had started being more comfortable with JS on the server-side, lots of people suddenly realized they could push a lot of business logic to increasing powerful desktop browsers and phones, application hosts people now call "edge devices".
This is the true impetus of SPA. How is CSS going to kill this need?
Most developers weren’t deploying simple stateless functions. They were building full-stack apps: apps that talk to a database, that almost always is located in a single region.
I wonder if this is true in general for most people on serverless these days. If so, whether this is what the original intention of this movement and whether these people just don't want to deal with docker/k8s.
An equally important but opposite problem with pipes getting stuck is pipes getting broken because some commands at the front of the pipe expects buffering down the pipe. Some years ago I was scratching my head trying to figure out why
curl ... | grep -q
was giving me a "Failed write body error". I knew "grep -q" would close stdin and exit as soon as a match is found, and therefore I needed a buffer in front of grep but I was on a Mac, which to this day still doesn't come with "sponge" (or stdbuf and unbuffer for that matter), so I had to find a cross-platform command that does a little buffering but not too much, and could handle stdout being closed. So I settled on:
curl ... | uniq | grep -q
To this day people are still confused why there's not a "sort" in front of uniq and the comment about this cross-platform buffer thing I put in the script.
iPhone since 12 has not used the Intel modem, and while newer iPhones supports Beidou, it’s not clear which chip supports it and whether it is used outside of China, or even iPhones sold outside of China has support for Beidou. Even if it does, its civilian frequency only has a 10 meter accuracy outside of APAC, so it’s not clear to me it is used globally in the sense that GPS is.
Also, Loongson and OpenATOM lol. Are they industry standards?
Let me know when you have an example of an open source Chinese industry standard, essentially subsidized by the Chinese government. The only example I can think of is Beidou, which nobody uses.
Is that still the case tho? Recent Deno releases have obscured how well it's Node compatibility mode is, I was just wondering if you have more details.
There is this thing called stretch goals in OKR that is supposed to be really hard to achieve. So if you meet all 100%, you either don’t have these stretch goals or the team is lying.
Now of course, whether OKR works depends on culture as well. Sometimes, asking people to stretch amounts to asking them to work harder, so naturally the system will be gamed in that context.
It’s even funnier when it’s apparent that company isn’t really doing OKR. First of all, the Os are supposed to be somewhat resistant to change in direction. Second of all, you shouldn’t be doing KPI on top of OKR. If you set the OKRs right, you’ll set stretch goals so ambitious, even if you game the completion percentage, the simple answer to whether you are doing the right things or performing should still be immediately answerable.
It appears to me this is another case of the slow evolution of European businesses and management practices.
There exists a practice called OKR. Intel has been using it since the early 70s, Google since year 2, and pretty much everyone in SV has switched over since around the time that John Doerr book came out. It’s designed to solve exactly all the problems of KPI. You shouldn’t spend much time figuring out what to measure and whether you are measuring the right thing or how to put what you measured into context. You should be defining simple objectives and key results what will give you a binary answer at regular intervals. Practicing KPI solely is putting the cart in front of the horse. You should know your objectives and milestones before you figure out how to measure them.
I’m pretty sure your contact in a major company will be even more shocked if they knew what all these European FinTech companies do with their customer’s data.
All the important things such as purchasing habit that used to require indirect guesses are now directly available in their databases as essential functions.
In general, your answer depends on where the TLS cert terminates. In most situation a CDN or a reverse proxy is involved, and the TLC cert you use to encrypt traffic from the origin to the proxy is different from the one the proxy uses to encrypt traffic from it to the browser. Whenever a MITM intermediary is involved, you should read the intermediary's documentation. These usually include Cloudflare, AWS Cloudfront, Akamai etc. With with exceptions, like the Vary header as pointed out elsewhere, these vendors largely follow HTTP caching semantics for proxy caches.