barumi

Just because a company managed to do stuff a certain way that does not mean that way is the right way or adequate or good.

Enough with this cargo cult bullshit approach to technical problems.

>I think this only solves the problem for the API owner, not the consumer, right?

The only problem this solves is their need to sell their product.

This so-called "schema-driven development" approach was already tried in the past and failed miserably. Call it SOAP or OData, the world already gave that a try, saw all the mess and operational and productivity problems it creates, and in spite of the gold mine it represented for tooling vendors and consulting firms, it was a collosal mess.

It's very weird how their selling pitch is based on veiled insults on hoe "the industry is still twenty years behind", but they failed to do their homework to learn the absolute mess that their so-called "schema-driven development" approach left behind.

It's as if they are totally oblivious to why the whole world shifted to "free-form" APIs, which worked far better than the SOAP mess, and their are hell bent on betting on a rehash of the bad old days.

That freedom of Linux comes at a cost that people aren't paid to take care of the level of details other OS have.

What do you mean "take care of the level of detail"?

I can download Debian right now, install it on hardware in about 10min, and get everything to work rock solid without any hitch.

I can't say the same about either Windows 10 or macOS.

In fact, I had mojave crash and reboot more times in the last month than Ubuntu 18.04 since it was released, and mojave is preinstalled in its own target hardware, which is supposed to be high-end, while Ubuntu is installed on a cheap laptop that cost between a third and a fourth of my apple laptop.

What exactly do you mean by level of detail?

The amount of weird issues is about constant.

But linux is free both as in free beer and in free speech, windows required you to pay the Microsoft tax to use, and lastly macOS required you to pay a premium on hardware.

While those prices seem pretty good for first world countries, many of the people in my country don't make more than $1000 per month, so it'd still be a substantial investment.

That price is just the benchmark for that specific combination of CPUs and RAM.

There are plenty of used servers in the market that are being sold for less than 200€.

VIM is ideal for people who find it worthwhile to spend the time building their configuration out.

I've been using VIM for over a decade and currently my customized config consists of a half a dozen tweaks, such as YAML-specific settings stashed in ./.vim/after.

But in academia, and I suppose in a criminal gang, everyone has the same skillset. PhDs are notionally being trained with the specific abilities necessary to become a professor.

They really aren't. First of all, scientifically speaking each PhD is unique as it focuses on specific venues of research. Thus within the same research group you often have an extremely diverse crowd doing independent research on multiple projects at the same time.

Then there's the fact that the assertion about "being trained (...) to become a professor" makes no sense. PhD students are trained to conduct independent research on a specific subject, and rarely also on how to apply to research grants. Being a professor, which is more of a supervisor/administrator role, is not factored into the equation, and the teaching component is a very small and tangential aspect of being a professor.

The truth of the matter is that graduate schools are effectively diploma mills to entice prospective workers to work long hours for low wages in exchange for a qualification and shot at a research career. Their work is focused on learning how to do research while focusing on a specialized topic, which arguably has no parallel with what a professor does.

Because it's a stupid statement when there are companies that are making more money (...)

Again, that makes zero sense and is another blatant red herring. If the discussion is about taxing WFH to support vulnerable jobs, it makes absolutely no sense to waste time playing the whole whack-a-mole whataboutism game.

If you don't want to discuss the topic under discussion, please refrain from commenting at all. You'll only end up adding noise to an otherwise interesting discussion.

Sounds to me like taxing WFH fits the description of "ruining everything good with taxation".

I mean, there's already a progressive income tax. Why should society create incentives to commute to work?

From the article:

But when I showed off my build on /r/homelab, reddit’s homelab subcommunity, they mocked me as a filthy casual because I used consumer parts. The cool kids used enterprise gear.

It should be noted that you can purchase used enterprise servers for peanuts.

I'm looking right now at an ad for a used Dell PowerEdge R730xd SFF 24x which packs two Intel Xeon E5-2680 v3 and 64GB of RAM which is on the market for about $1200, and it was literally the first search result.

A Dell PowerEdge R720 8x 2U LFF with the same CPU/RAM/HDD combo is on the market for less than $1000.

A Dell Precision T7610 workstation, with dual Xeon ES-2670 and 64GB of RAM, can be purchased by around $600.

On the other hand, with marriage, it's generally (hopefully) safe to assume that both parties trust each other fully before entering into the agreement. Whether and how that plays out in practice is another story, but IME, very few people enter into marriage prepared for the case in which it ends.

Sounds to me you're describing the whole point of marriage as a contract, as it specifies the default set of conditions and requirements that are applied to both parties, and also the rights and obligations of both parties in case of a contract resolution and even breach of contract.

This is why prenuptial agreements can sometimes be a touchy subject, since it breaks that assumption of complete trust.

Again, it sounds like you're describing the whole point of marriage as a contract, as its the original (and baseline) prenuptial agreement.

They can't help but penalize change.

I don't believe it has anything to do with change.

I believe it has everything to do with isolating a vulnerable subset of society to exploit them. Divide and conquer. They want a bigger chunk of your hard earned money, thus they fabricate a tall tale of entitlement to vilify and turn the peole against you, and proceed to rob you of your paycheck because they want your hard earned money.

Examples of large, modern societies flourishing without the use of taxation?

This is a disingenuous red herring.

It's one thing to claim that some amount of taxes to finance public spending can be benefitial to society.

It's an entirely different thing to claim that taxing remote work brings any benefit to society.

I would gladly contribute a larger share of my income as taxes to ensure my community doesn't suffer (...)

I would too, which is why I vote with my wallet and buy local, even at a premium, whenever I can.

However, income tax is the exact opposite of helping out the community, as it's designed to fatten up the central government's revenue which is then used up to feed the state's current expenditure.

Deutsche Bank placed number one in money laundering.

How does that ad hominem refute or support the claim that remote workers should be taxed to subsidize vulnerable jobs?

Even though they're technically different concepts, I've found in practice they're almost always coupled together.

Not really. Event sourcing is typically implemented with CQRS, mainly due to how ES relies on streams of command messages and as CAP-related requirements already require mutable and immutable commands to be processed differently. However, CQRS has zero requirements other than segregating interfaces.

Hell, in languages like C++ you already get CQRS out-of the-box by following const-correctness.

>I'm saying that REST also separates reads from writes in almost identical capacity.

Not really. REST just models everything as resources that are targetted by requests. REST states nothing about how rewuests should be segregated by commands and queries.

CQRS+ES is more about event sourcing and not as much about CQRS. The hard part about the scheme is the CAP theorem stuff, not how operations are segregated into commands and queries.

The biggest drawback I've seen to CQRS - particularly in an event driven architecture - has been increased complexity, usually in exchange for increased scalability.

I fail to see how CQRS is a factor in increased complexity. After all, CQRS boils down to separating the interfaces for queries/reads/immutable operations and commands/writes/mutable operations. Unless you're bolting on unrelated concepts, like event sourcing, then CQRS is not a significant source of increased complexity in non-trivial applications.

Can you shine some light on which aspects led to higher complexity in your use of CQRS?

A dog whistle for what? There's an awful lot of cagey presumption going on in every reiteration of this claim.

I'm not a US citizen nor I ever set foot in the US, and even from afar the quasi-fanarical displays of support for the US armed forces is a hallmark of supporters of the Republican party.

There is a difference between being in bad taste and being illegal.

It's called "letter of the law" vs "spirit of the law",

Purposely violating the principle of the law by abusing loopholes, and proceeding to claim that technically violating the spirit of the law is not illegal because you came up with a loophole that you believe is not incompatible with the letter of the law just goes to show the level of dedication that you have to break the law without being punished for your transgression.

"The intention behind the rules" is a thing that lives in your imagination.

No, it's pretty straight-forward. There's no healthy democracy that believes that a blatantly partial and biased individual counting the votes generates confidence in the elections being fair and democratic. The whole idea that you can violate such a fundamental principle in such a blatant way is something that goes totally against basic democratic principles.

The main feature of git flow is having multiple redundant branches for no reason. Namely a separate develop and master.

This statement is simply wrong and ignorant.

The reason why mainline and develop branches exist is due to the fact that production-ready code and unstable code are not the same ops-wise.

Nowadays, with the dissemination of CICD practices, that difference has been shifted away from the source code repository and into the Delivery/Deployment phase of a CICD pipeline. Yet, the overall principle is the same, and arguably its still here. Calling those differences "redundant and for no reason" is just ignorant at multiple levels, from software engineering to the fact that the sofware lifecycle process for commercial software projects, the kind that had to "go gold", had very specific requirements.

The author of "GitFlow Considered Harmful" put out a simpler workflow that achieves all the upsides of GitFlow with none of the downsides:

I see no relevant difference between that workflow and GitFlow, besides the rebranding of old concepts and some unexplained focus on merging options.

I've also revisited the author's old rant from 2015 regarding gitflow and the only tangible criticism he had was the separation of the master/mainline and development branches, which is extremely shortsighted and miopic as it fails to acknowledge the reality of non-CICD/old-fashined software release lifecycles.

GitFlow has one main concept: using feature branches to do develop work, use release-specific branches to integrate changes, establish and enforce upstream/downstream relationships between branches. The rest is just rebranding and nit-picking over semantics.

I don't know what you think git-flow is, but a linear history it is not.

Your statement makes no sense at all. Gitflow is a workflow. What do you believe it's supposed to be? It's irrelevant how you see commit histories, because with regards to the master/mainline branch it's always linear, isn't it?

What do you personally believe gitflow is?

Quoting the original git-flow post:

I don't know what you expected to show, but you are only describing a workflow. Changes are made in dedicated branches, and later these changes are merged back into the master/mainline branch in a single commit, which is expected to have been validated and tested and working. That's a workflow. How the log ends up looking is entirely indifernet or irrelevant, isn't it?

Again, what do you personally believe is the whole point of a workflow like git flow, specially in light of allowing large teams to continuously integrate their work ? I mean, what do you believe is the whole point of getting devs to work on branches independent of what changes go into master/mainline, and leave merging as a last step that's the responsibility of the developer prposing a change?

It's not git-flow, as all commits are rebased on top of master to make the history of master linear.

I fail to see how that is relevant. I mean, the only possible impact that has is if individual commits within a feature branch are recorded or not, which is arguably irrelevant. You wouldn't get a different workflow if instead of reading you simply did a squashed merge.

It is one of the more standard workflows, and it's a concise overview of how the maintainer of curl does their job.

It's gitflow, and leaving out feature branch commits doesn't make a difference.

No interviewer has demonstrated anything but perfunctory interest in my open source work, popular or not.

In he past when I did candidate screening I used floss work extensively to evaluate a candidate. To me, personal projects are an excellent way to assess skillsets at multiple levels.

Perhaps you've been interviewed by people who place a greater focus on soft skills, or HR headhunters who can only read CVs?

Seems pretty standard to me. Anything notable here?

I agree, it's pretty vanilla git usage. I was curious to see any insightful take of whimsical twist, but it boils down to a basic take of good old git flow, which is git 101 for a long time.

https://nvie.com/posts/a-successful-git-branching-model/

The only surprising thing in the article was the refusal to use git stash, which can't really be explained on a rational level.

My take is that this is a "correlation does not imply causality" case.

It was possible to positively identify a reinfection because the two infections were due to different strains. That was just the means of positively and objectively identify a reinfection. However, nothing was asserted regarding if the patient was immune to the first strain the first time around. In fact, it seems that the hallmark of reinfections is that they are far more critical than first infections. This also means that the first infections is far milder than the second one. Well, the thing about the immune system is that it is able to fight mild infections without developing immunity if they are too mild to trigger a full response from the immune system.

This would contradict the one-fits-all immunity argument.

I don't think that argument is being made at all.

In fact, you only need to consider that the max efficiency that's advertised is 90% to acknowledge that this vaccine is not a silver bullet.