The post How Functional Programming Shaped (and Twisted) Frontend Development from four days ago provides great broader context about the history and concerns. It ends with what this post seems to primarily concern itself with: The alternatives, improvements, innovation, and opportunities we may be missing / should evaluate.
In what way is this !programming@programming.dev? I don't think "I made this" should quality, or we would lose programming focus/scope of the community. This would be a better fit in gamedev or gaming or personal project communities.
Enable squash commits. Each PR should be squashed to a single commit. This makes the master branch linear and simple. This ensures each individual commit on master has been reviewed and is in a working state.
In non-minimal changesets, I would miss information/documentation about individual logical changes that make up the changeset. Commit separation that is useful for review will also be useful for history.
I prefer a deliberate, rebase- and rewrite-heavy workflow with a semi-linear history. The linear history remains readable, while allowing sum-of-parts changesets/merges.
It's an investment, but I think it guides into good structuring and thoughts, and whenever you look at history, you have more than a squashed potential mess.
Squash-on-merge is simpler to implement and justify, of course. Certainly much better than "never rebase, never rewrite, always merge", which I am baffled some teams have no problem doing. The history tree quickly becomes unreadable.
Do you see downsides to learning it?
If you can, do it. It's common enough to be [potentially] useful. If you don't have a concrete need, then it's not necessary, though.
For comparison, "amazing" occurs six times.
It's in a process of development and testing in Europe as an official currency/payment technology.
taler.net has a post about that - NGI Taler - too.
We may be seeing much more concrete news and use in and from two years from now.
Maybe all bunnies are actually snails with a fur coat on.
I recently watched a presentation (on YouTube from a conference/offline presentation) about Systemd which also went into its focus/baseline of Linux, not Unix, and how NT supported a stronger service concept from the beginning. It was quite interesting to learn about the differences and the presenter's assessment and reasoning of the necessity of Systemd or something else that replaces or extends init and rc.d.
People regularly change email addresses. Listing that as an example is a particularly bad example in my opinion.
I hope the demo starts soon…
(What a bullshit correlation/equation to start with.)
Personally, I like to call catched exception variables up, so for a rethrow I can throw up;.
Kissaki
joined 2 years ago
Microsoft pushes cloud and AI with increasingly negative side-effects. Eventually, EU regulation steps in to require offline-capable OS with fair and obvious choice. Microsoft tries to argue security, but ultimately fails.
Microsoft continues to push and connect their services as one, with synergy effects. Eventually EU regulation and prosecution steps in, requiring a neutral OS that must not pre-install software or point to other products in OS settings and apps, etc. Integrations must be openly standardized first, before implementing their own.
Despite all this, and despite a move from EU and EU-national institutions to sovereignty through shared open source solutions, Microsoft retains their strong/prevalent market position because the market as a whole is not as strategic and concerned, and Microsoft products like office, onedrive, Teams, and their other business software and services remain a predominant and grab-first choice, and the security promise of big enterprise software, battle-tested, with strong established auth etc remains a big selling point for them.