simplotek

> Being an OAuth 'provider' (emphasis) is not open source

Being an OAuth provider is precisely what everyone expects from a self-described "open source authentication service". If Supertokens does not support that out of the box, it should not really be called an open source authentication service.

I understand you want to capitalize from your work, but I feel this is a gross misrepresentation of a project.

> My personal pet (non scientific) theory is that repeated infections over-sensitize the immune system, almost like an allergic reaction or something.

There have been a few variants that have a markedly change in their ability to spread and also their severity. They might be hitting people differently. I mean, if the same person is getting infected multiple times with carrying degrees of severity, something is changing in the infection.

You are oblivious to the point of this approach. Scaling has nothing to do with it. It has everything to do with not imposing useless and detrimental constraints that buys you nothing but problems. You specify interfaces, and keep implementation details from leaking by encapsulating and insulating them. This is terribly basic stuff.

> How can you get any work done like this?

People get work done by knowing what they're doing, which I'm not sure you are able to tell.

There is plenty of literature that explains quite thoroughly the process of software architecture. Basically all major software architecture styles from the past four decades reflect the need to encapsulate and insulate implementation details, including the need to specify a domain model and how it should be specific and exclusive to each project.

Somehow, you are oblivious to basic principles but still feel entitled to insult others based on domain knowledge you clearly lack.

> Should both my service and Galactus have full, individual copies of this data structure?

Yes. I recommend you read "Domain-driven design" by Eric Evans, specially the part explaining the concept of a bounded context.

> Alternatively, if Galactus has a published schema that I refer to, isn't that a shared data structure?

No, that's the interface.

> not only we deduplicate code

You don't. You just needlessly add a constraint for no reason at all, and in the process make your life a mess.

> They recommended I use "modern infrastructure" which means Docker.

It looks to me they recommended to never consider Datadog for anything whatsoever, ever again.

> but I agree, this is not something that i've ever considered when filtering CVs.

As a proficient LaTeX user, this is the stupidest take I ever saw on resume tips. I mean, your skills and experience do not vary with the document system you used to generate your CV. Some hiring managers swear by MS Word templates, other hiring managers ask for Europass, others ask you to fill in a form and request a cover letter. It would be stupid to assess the suitability of any candidate on this sort of bullshit.

> LaTeX for your resume?! If someone sumgly sends me a .TEX (...)

I'm not sure you got it right. You still have a LaTeX doc if you compile it to generate a PDF. LaTeX can have a very unique and peculiar look and feel that pops up to those in the know.

It seems you are confused. You're pointing out observations from the very onset of the COVID pandemic, which were immediately adopted as policy.

This is stuff that precedes other policies like placing ICU patients prone/lying face down to improve breathing.

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8864017/

It makes absolutely no sense at all to fabricate conspiracy theories based on the assumption that everyone in the world was systematically subjected to a procedure which was rejected right from the start.

> That's only true if you are limited to two options

What other options do you think there are?

And consider that you're already talking about people which are fainting and suffocating.

> Early COVID-19 research found that most patients with optimum levels of vitamin D did not require ICU or breathing assistance and survived the infection.

Some sources point out that only 10-20% cases of covid are admitted to intensive care unit, and 80-90% of cases are mild.

I seriously doubt that up to 90% of the population has "optimum levels of vitamin D".

How teams interact is a function of the team/org, not the software architecture.

What microservices easily provide in this scenario that is far harder to pull off with a monolith is that with microservices the service owners are able to roll out a dedicated service as a deliverable from that dialogue. Whether the new microservice implements a new version of the API or handles a single endpoint, the service owners can deploy the new service as an extension to their service instead of a modification, and thus can do whatever they wish to do with it without risking any impact on their service's stability.

> If team A needs a new endpoint from team B, what would a typical dialogue look like under microservices and a modular monolith, respectively?

> Also, does ccache work with MSVC?

Technically it works, but it requires some work. You need to pass off ccache's executable as the target compiler, and you need to configure the settings in all vsproj files to allow calls to the compiler to be cacheable, like disabling compilation batching.

Using cmake to generate make/ninja projects and use compilers other than msvc is far simpler and straight-forward: set two cmake vars and you're done.

> Maybe, but after the next CEO comes in, those groups would be reorganised anyway :-/

That's perfectly fine, because microservices excel in that scenario: just hand over the keys to the repo and the pipelines, and you're done.

> (...) like using microservices on a system that gets 1k users a day.

This sort of specious reasoning just shows how pervasive is the fundamental misunderstanding of the whole point of microservices. Microservices solve organizational problems, and their advantages in scaling and reliability only show up as either nice-to-haves or as distant seconds.

Microservices can an do make sense even if you have 10 users making a hand full of requests, if those services are owned and maintained by distinct groups.

> But they should consider whether this matches the size/scope of the problem being solved

In professional software development projects, specially legacy projects, often times the complexity is not justified by the problem. There is always technical debt piling up, and eventually it starts getting in the way.

> Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain?

The main misconception about microservices is that people miss why they exist and what problems they solve. If you don't understand the problem, you don't understand the solution. The main problems microservices solve are not technical, but organizational and operational. Sure, there are plenty of advantages in scaling and reliability, but where microservices are worth their weight in gold is the way they impose hard boundaries on all responsibilities, from managerial down to operational, and force all dependencies to be loosely coupled and go through specific interfaces with concrete SLAs with clearly defined ownerships.

Projects where a single group owns the whole thing will benefit from running everything in one single service. Once you feel the need to assign ownership of specific responsibilities or features or data to dedicated teams, you quickly are better off if you specify the interface, and each team owns everything begind each interface.

> I hadn't considered it as a build speed optimization, though that seems somewhat obvious in hindsight.

Some build systems like cmake already support unity builds, as this is a popular strategy to speed up builds.

Nevertheless, if speed is the main concern them it's preferable to just use a build cache like ccache, and modularize a project appropriately.

> Another nice feature of unity builds is that I don't need to declare functions twice and keep the declarations synced.

What exactly leads you to have multiple declarations in sync, and thus creating the to "keep [multiple] declarations synced"?

> But this also reduces the opportunity to parallelize compilation across multiple files because they have been concatenated into fewer build units (...)

Irrelevant. There is always significant overhead in handling multiple translation units, and unity builds simply eliminate that overhead.

> and each unit now requires more memory to deal with the non-header parts.

And that's perfectly ok. You can control how large unity builds are at the component level.

> For some build systems and repositories, this actually increases build time.

You're creating hypothetical problems where there are none.

In the meantime, you're completely missing the main risk of unity builds: increasing the risk of introducing problems associated with internal linkage.

"probable cause" means the same thing as "associated with", but establishes a specific hypothesis and stresses the fact that it is yet to be verified.

> It's a breakthrough but this research doesn't establish the claim in the title of the article.

What claim would that be? The only claims made in the article was that a) it's a breakthrough, and b) "Researchers say certain strains of gut bacteria are the likely cause of Parkinson's disease."

The article also refers to the bacterias as "probable causes".

Everything you pointed out supports these observations.

Isn't "isomorphic javascript" a buzzword referring to a server-side rendering technique?

https://en.wikipedia.org/wiki/Isomorphic_JavaScript

> For instance, a major selling point of Node was running JS on both the client and server so you can write the code once.

What? No.

The whole point of Node was a) being able to leverage javascript's concurrency model to write async code in a trivial way, and b) the promise that developers would not be forced to onboard to entirely different tech stacks on frontend, backend, and even tooling.

There was no promise to write code once, anywhere. The promise was to write JavaScript anywhere.

> Every time you increase compliance through force (...)

Enough with this disingenuous bullshit. Public health officials specified basic public health measures to fight a pandemic, like washing your hands, practice social distancing, and wear a mask. That's it. What do you expect to achieve by putting up these pathetic strawmen? Do you actually expect to gaslight everyone who lived through the pandemic?

What are you talking about? OP did not mentioned any example remotely involving Guantanamo bay. Are you trying to move the goalpost out of ignorance or cynicism?

> The US police are killing people all the time.

Your comment sounds awfully disingenuous. I seriously doubt you do not see the huge difference between implementing official policies of extrajudicial imprisonments and having a random person murder people for their own personal reasons.

Enough with this bullshit.

This brand of disingenuous whining reads like someone complaining the police pull them over for no reason when they were actually crossing a red light, and they still have the gall to play the victim card.

> Generated lexers are still worth it but handwritten RD won on the parsing front.

Packrat parsers make a very compelling case. I'm not sure the debate is over.