Yeah it's not ideal, but you only need to pay the gas cost when you need to prove integrity and that's alot cheaper than having to constantly be in sync with the world.
Audit logs and Access control paper trails.
Security event logging has to be:
- Broadly accessible
- Write-protected
- offering some proof of completeness.
These three requirements are tricky and often conflicting. Block-chain might be an inefficient way to achieve these, but the glove does fit quite neatly.
Logistical paperwork
- Purchase Orders/Invoices and packing slips
- Waybills/Bills of lading and CMR's
These kinds of documents require multiple stages of matching and approval by untrusted 3rd parties. There are dozens of ecosystems of interacting systems that support processing these documents, but most people still use paper. Paper is more reliable when you need to deliver a container full of diapers from Poland to North Sudan. It's more reliable but incredibly prone to fraud and forgery. Having all of these approvals and transactions tracked on a blockchain and letting different systems interact with the same chain, would make it possible without each ERP having a rest API to each other ERP.
This is a bit of a narrow view of a very vague term. Having worked with many different sizes of organisations i can say that the responsibilities of whomever is labelled CTO are completely arbitrary. The only thing you can establish is that they are the person accountable for the technology decisions.
Sometimes that's a legacy developer, sometimes that's the first sys-admin.
Sometimes it's the VP of engineering.
Sometimes that's the person that maintains the best relationships with software vendors.
Sometimes it's the person that was hired externally to explain the tech to the CEO and let's them make informed executive decisions.
Sometimes it's just a public figure used to promote the org and maybe do DevRel.
Sometimes it's the Architect that designed the ecosystem.
Sometimes it's the ancient programmer that has kidnapped the entire codebase so that no-one else can sanely work on it.
Sometimes it's a six sigma type that setup the ticketing system, PRs and the release process.
At any size, the CTO is whatever the org needs him to be at that point.
Don't teach yourself complex software dev skills. Teach yourself complex software problems and learn how others have solved them in the past.
It's just transparent. It feels like alot of lessons were learned from the broken abstractions of older ecs engines. It might not be as powerful yet, but the foundation is solid and it's easy to implement the more complicated stuff.
Also, dotnet 6 implementation is a breath of fresh air.
A single race condition is a tragedy. A million race conditions is eventual consistency.
What I love most about Krazam is that in every video they make, you see the guy move up the usual tech career ladder xD
It's difficult problem to solve. Lemmy's stack is a bit unconventional. The rust backend is not idiomatic and the ui is based off a template of an isomorphic not-quite-react framework. Its not impossible, but it will take a while for alot of programmers come onboard.
That being said, there's more to it than writing code. Better bug reports, reproduction, updating docs and triaging/managing the issues is possibly more important than writing PRs. Don't be discouraged!
Article is a bit dated and hard to read. The gist of the author is relatable though 15 years later: redundancies have been hella annoying, especially if they are unknown. Bad abstractions, however, create dilemmas, dead-locks and chicken-and-egg situations. And it's impossible to create good abstractions unless you have no colleagues and no customers.
I would take some frustration over grinding to a halt any time.