Senior backend engineering definitely doesn’t see 99% windows adoption rate.

Well, they do it Japanese style - by forcing developers to leave due to burnout.

I’m working with a legacy codebase for the last few months, where a simple PR often ends up crossing a 1000 lines count due to testing and commenting, and I can’t stop apologizing for those.

Yet there are people out there bragging about 10x changesets.

I made my statement as a BDD/TDD practitioner.

The code goal of software engineering is not to deliver said code, but to deliver it in a framework that lets others—and consequently me in a week’s time—to contribute easily. This makes both future improvements and bug fixes easier.

Dumping a ~25000 lines changeset with a git history that’s almost designed to confuse is antithetical to both engineering and open source.

The size of that changeset means that it’s inherently unreviewable.

The commit history is something I’ve seen only in the PRs that even the most dysfunctional companies would demand a rewrite for.

Also, 2-3 weeks review? PostgreSQL support could be added in that time without the need for a damn „vibe check”. Hell, it would probably take less time than that.

Deadbeef

Cue sheets are important.

Every bit of code a maintainer accepts becomes their responsibility to maintain. Considering that half the time „improvements” don’t even have tests to help maintaining them, feel free to maintain your own fork.

„How do you know” is such a powerful question.

I especially like the Electrolux one. It’s simple, memorable, and once you see a butt and bikini, you can’t unsee it.

Thanks, I hate it!

If you guessed it right, your inflexible implementation becomes an advantage against other inflexible implementations.

There, I generated an AGI (actual grumpy ignoramus) summary for y’all.

Power users rebase with squashes and fixups multiple times a day. Especially if the job’s integration process isn’t enforcing long living branches.

Reflog is useful then, because you literally rewrite history every rebase.

However you like, REST doesn’t dictate anything there. Just be consistent and use hypermedia.

JSON APIs almost never follow REST because they almost never use JSON as hypertext. Worse, no complete stable hypertext JSON standard exists. There’s JSON-HAL, but it lacks a way to represent resource templates (think HTML’s <form>).

Therefore, with JSON APIs ignoring one of the most basic idea behind REST, why would anyone expect them to follow another idea of REST - consistency?

REST is a deceptively simple concept. Any time you build an HTML website a human can navigate without consulting documentation, you’re doing it better than vast majority of swagger documented corporate APIs.

JSON API almost always means “not REST”. In other words, it works as intended.

I can’t muster any sarcasm out of sheer disappointment. You win this time…

I’d probably add that for something like nextcloud granted scopes can be an „orthogonal”–for the lack of a better word–subset of requested scopes.

The set of requestable scopes has to be defined by the system itself, not its specific configuration. E.g. „files:manage”, „talk:manage”, „mail:read” are all general capabilities the system offers.

However, as a user I can have a local configuration that adds granularity to the grants I issue. E.g.: „files:manage in specific folders” or „mail:read for specific domains or groups only” are user trust statements that fit into the capability matrix but add an additional and preferably invisible layer of access control.

It’s a fairly rare feature in the wild and is a potential UX pitfall, but it can be useful as an advanced option on the grant page, or as a separate access control for issued grants.

https://oauth.net/articles/authentication/

That aside, why is nextcloud asking for scopes from remote API in the diagram? What is drawn on the diagram has little to do with OAuth scopes, but rather looks like an attempt to wrap ACL repository access into a new vocabulary.

Scopes issued by the OAuth authorization server can be hidden entirely. The issuer doesn’t hold any obligation to share them with authorized party since they are dedicated for internal use and can be propagated via invisible or opaque means.

I really can’t figure out what’s going on with that diagram.

As a Ruby fan having a blast with Elixir, where the hell is anything BEAM related?

The compass is truly political.

Why did you mention git twice?

It’s all about being comfortable with not knowing when you need to act. Believing that you can learn everything upfront is pure hubris, and once you hurt yourself enough times, you just drop the pretense.

In other words, life is Bayesian, not frequentist.

I can often implement 80% of a new feature without ever running the code.

I really love how they then go and invent their own TDD acronym to justify this. Types are proofs, and they replace a whole category of borderline superficial tests with useful assertions, but claiming that you implement a <random number>% of a feature when you haven’t once verified it is… a reason I regularly cuss at code and remain employable. Keep it up.