Go back a little bit further to another Morgan Freeman movie - Se7en (1995) and a big plot point was that it is unthinkable for big brother to be keeping records of what library books people are checking out. Times sure have changed...
I don't disagree with the advice (especially for long lived tokens), but query parameters are encrypted during transit with https. You still need to worry about server access logs, browser history, etc that might expose the full request url.
It is definitely a new frontier. How do you review a game that isn't reproducible? Similarly how do you do play testing? You don't get the same "shared experience" outside of multiplayer and people experiencing it together. It is taking current generation procedurally generated games to the next step, but where do you find a threshold of "this blob of constraints is _the_ game"?
I'm not saying that video games should be confined to today's paradigms, I'm just happily curious to see what will happen with it.
Or similarly the difference between reading/listening to a foreign language vs. writing/speaking one. Knowing how to read code or learn algorithms or design is different than actually writing it. The difference between the theory and practice.
> "Underlying ideas" means cherry-picking opinions that suit your fancy while ignoring those that don't.
Yes, that is how terminology evolves to not meet a rigid definition that was defined in a different era of best-practice coding beliefs. I'll admit I had trouble mapping the DDD OO concepts from the original book(s) to systems I work on now, but there are more recent resources that use the spirit of DDD, Domain Separation, and Domain Modeling outside of OO contexts. You're right in that there is no single recipe - take the good ideas and practices from DDD and apply it as appropriate.
And if the response is "that's not DDD", well you're fighting uphill against others that have co-opted the buzzword as well.
You can remove JSON fields at the cost of breaking your clients at runtime that expect those fields. Of course the same can happen with any deserialization libraries, but protobufs at least make it more explicit - and you may also be more easily able to track down consumers using older versions.
The request / data fetching is interesting in how "easy" it is to write. I did basic perusal of the examples, but I'd be interested to see what it looks like with rate-limited endpoints and concurrent requests.
Another tangentially related project is https://steampipe.io/ though it is for exposing APIs via Postgres tables and the clients are written using Go code and shared through a marketplace.
I felt the same - have to relearn/lookup everything every time I went back to a project or wanted to do some operations that are simple to describe in SQL but I couldn't wrap my mind around e.g. using multi-indexed dataframes & aggregations properly. These days, I always jump to Polars instead of Pandas - much more intuitive and consistent API. Tons of props to Pandas for all that they did (and continue to do) in the data space, but their API did not evolve very well IMO.
I've also been wanting to play with Ibis[1] recently, but Polars has been sufficient for me.
I do the same, though my muscle memory is `1=1` instead of `true`.
Of course then you get editors/linters/coworkers that always point out that the 'true' is unnecessary. This also doesn't work with ORs (just swap to false), but in practice it seems it is always ANDs that is being used.
Sharding, pre-allocating leases of blocks of tickets across available resources, and eventual consistency. You don't need to keep the UX transactionally correct; you are able to say "0 tickets remaining" and then a minute or hour or day later say "100 tickets remaining". For something as popular as Taylor Swift, the fans will keep checking.
I would also say that could account for the download count differences between the projects. Django may still be used for more monolithic applications whereas Flask and FastAPI may be the choices for smaller-scoped microservices resulting in 10x downloads.
No negative connotation is intended here for "monolithic". On the contrary, if the above assumption is at all true, it highlights a overhead cost of individual microservices.
This type of stance is what de-popularized the Elm language.
Don't get me wrong - I wish the best for both languages and am thoroughly impressed by the work of their creators. I can see that it must be a hard thing to balance.
Java Mission Control [0] has a button to toggle for displaying the profile as thread roots or method roots for this purpose. I am not imaginative enough to come up with a visualization that shows both (maybe utilize background color or another indicator to show the leaf function's relative frequency in the other direction?). Either way, both directions have their use case when investigating.
As a university project I created a Morse code transmitter and receiver circuit that used the same type of LED on both sides. It worked pretty well up to a few inches apart.
I assume this is a good spot to give a shout-out for the Grimm, Grimmer, Grimmest podcast - kid-friendly story-telling podcast great for long car rides. The author likes to point out deviations between original stories and later re-tellings. I believe the first 2 seasons are free.
I would say the reverse is true though - great teachers are able to spark interest on a subject that students may otherwise not care about. But I agree that that expectation shouldn't be the baseline.
Pieter Hintjens who started ZeroMQ, advocated for 'optimistic merging' as a strategy to encourage community & project building [1] (prev discussed in [2]). For all of the benefits listed it does open it up to lower quality or malicious merges.