if I could stay later when there’s broken things in prod

In general, or on this instance?

Do you have team retrospectives? That's where I would bring it up in my team. Raise my concerns, explore and understand what team consensus is around this topic, around risks, quality, etc.

If the team consensus and/or management consensus is YOLO - then I try to protect myself from personal investment and going beyond contractual obligations. Because I already know what will come and how it will negatively affect me personally.

It's possible a honest discussion with management about goals and risks could lead to clarified guidelines, requirements, and goals. If it doesn't, I'd probably be looking for a better job/environment. Because I'll be miserable if colleagues YOLO, no matter how careful I am personally.

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.

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.

For comparison, "amazing" occurs six times.

those are terms, this is substrings within words

I haven't seen branches or variables being called arse

Then again, I do like to catch exceptions as up so I can throw up

What a mess.

URL is still advanced-custom-fields, but then named Secure Custom Fields. Translations and source repo still map to the old name. It definitely is a takeover, not a "fork" in the classic, established sense.

The problem with the takeover is, of course, that the original publisher still develops, publishes, and sells their original plugin. Their official website now serves their own version with their own update source.

So you kinda don't but also have to rename it to avoid confusion.

I think a rename to something different is wrong and confusing though. It should add a disclosing addition, like "(Taken Over)" or "Adjusted" or "WPorg edition".

A supposed, partial rename is confusing. No information in the README is confusing, intransparent, and disingenuous. No clarity in the release notes is confusing.

Simply freeing previously and still sold pro features, without disclosing that fact, is very questionable. Not fair to the developers and certainly not transparent to the community.

Clearing the changelog and release log documentation, removing previously available information, is questionable as well.

I see in the readme.txt file that the plugin is licensed under GPL.

So the changes are permissible. And being able to do so is certainly a strength of the FOSS license.

My biggest issue is that they remove information, and rename without indication. It should be transparent and, within context and concerns, fair. Not like this.

Looking at the commit log:

6 days ago, 6.3.6.1 was tagged with

Security - ACF defined Post Type and Taxonomy metabox callbacks no longer have access to $_POST data. (Thanks to the Automattic Security Team for the disclosure)

14 hours ago, 6.3.6.2 and rename

• Security - Harden fix in 6.3.6.1 to cover $_REQUEST as well.
• Fork - Change name of plugin to Secure Custom Fields.

It also removes is-pro and pro-license-active checks, but fails to disclose so in the release notes.

Effectively, it frees pro functionalities.

It also removes all previous change log and release information.

The items don't seem concise and always clear. But seems like a good, inspiring resource for things to consider.

If it is expected that a method might fail, then it should fail, either by throwing an Exception or, if not - it should return a special case None/Null type object of the desired class (following the Null Object Pattern), not null itself.

I've never heard of evading null with a Null object. Seems like a bad idea to me. Maybe it could work in some language, but generally I would say prefer result typing. Introducing a result type wrapping or extending the result value type is complexity I would be very evasive to introduce if the language doesn't already support result wrapper/state types.

I find LINQ query syntax less readable than SQL. I like LINQ method syntax for simple, linear queries.

The linear method syntax is somewhat like the idea of piping SQL operations.

People regularly change email addresses. Listing that as an example is a particularly bad example in my opinion.

A patch from January and MFA prevents account takeover.

If you're not updating gitlab for over three months, across max severity security patches, you're negligent.

Personally, I like to call catched exception variables up, so for a rethrow I can throw up;.