qw

It's also missing a tutorial.

I have the same experience as you. I have probably worked with a few dozen SOAP services in my time, so perhaps I have been "lucky", but WSDLs have not been an issue for me.

WSDL is in some ways more user-friendly than openapi schemas. They have a rich set of types that mostly just work as expected. When I try to generate models from an OpenAPI JSON file, I often find myself either overriding the models or making scripts/plugins to rewrite the json to fix types. An example of this is using proper decimals instead of doubles, which is crucial in my line of work.

From what I can tell it is a library for standardising return values that is independent on the transport medium. A HTTP service may return a particular http code or body, and gRPC would have its own representation.

I think this library maps the different representations into a single representation. The business logic, metrics, logging etc. will use the single representation instead of being tightly coupled to the transport medium

Example from the docs where the "PAYMENT_DECLINED" state is mapped from protocol specific responses:

  PAYMENT_DECLINED
  |
  +-- HTTP 422
  +-- gRPC FAILED_PRECONDITION
  |
  --> logs/metrics keep PAYMENT_DECLINED

And to make it more interesting, Sweden also has the letter "å", but it's in the 27th place in the alphabet (followed by "ä" and "ö"). In the Danish/Norwegian alphabet, the letter "å" is the last letter of the alphabet.

> Anyone still feel the pain when Google discontinued its RSS reader?

Yes, but mostly because of a lost opportunity.

I was working on my own web based reader when Google made a significant upgrade to their reader. It was similar to what I had made, so I thought it would be foolish to compete with Google and stopped working on it.

I wonder where RSS would be now if Google had not discouraged potential competitors.

Looking at the site it seems to be a (static?) HTML and shared "main.css" and "main.js" files. Both files can be cached by the browser, so it only needs to download a few KB of compressed HTML for each page. I don't think we would notice much of a difference in the navigation from one page to another if they used content preloading

It's how we used to make websites before SPA, and it's refreshing to see that it still makes a noticeable difference even on today's powerful CPUs and high speed networks.

What if FTL is not possible? In that case the attack will take a long time to reach us, and in the meantime we will be much more advanced technologically and could potentially defend ourselves.

In sci-fi we see warp drives, worm hole travel, phasers, photon torpedos and energy shields around ships. But what if none of that is possible? In that case, we might even have the technology to defend ourselves today if we manage to detect the attack in time.

It's a huge risk for a civilization to attack us. Even if they have capabilities that are beyond our technology, there might still be limitations based on the laws of physics. And if they attack us, they risk a response.

Originally, the "o" on top of the letter "Å" was a lower case "a", because the sound could be written as "AA". Over time it transformed into a circle.

Some names today still use the double a, like the Norwegian football player Martin Ødegaard. In that case it is pronounced the same as the "å" sound. (not too far from how an American might pronounce the "o" sound in "for")

> The client then searches through the list to see if the desired email is in the list or not.

The initial prefix check would probably reduce the amount of lookups necessary, as it would only be necessary to do a deeper search if the prefix matches.

It is my recollection as well. Most applications used VB, Delphi, MFC etc. that all had the "native" OS look and feel. There were some exceptions like WinAmp and others, but from what I can remember most applications were more consistent than today.