nibblebit

@nibblebit@programming.dev

• ⁨Comment⁩ on ⁨What do you think would be an actually good use of blockchain/smart contracts? What kind of problems (big or small) is it a good tool for?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  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.

• ⁨Comment⁩ on ⁨What do you think would be an actually good use of blockchain/smart contracts? What kind of problems (big or small) is it a good tool for?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Audit logs and Access control paper trails.

  Security event logging has to be:

  1. Broadly accessible
  2. Write-protected
  3. 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 all interracting that support these documents, but most people still use paper, because its 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.
• ⁨Comment⁩ on ⁨What does a CTO actually do?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  This is a bit of a narrow view of a very vague term. Working with many different sizes of organisations whomever is labelled CTO is the person accountable for the technology decisionmaking. Sometimes that’s a legacy developer, sometimes that’s the first sys admin. Sometimes it’s the VP of engineering. Sometimes that’s the guy that maintains the best relationships with software vendors. Sometimes it’s the person that was hired internally to explain the tech to the CEO. Sometimes it’s a guy that is just a public figure used to promote and maybe do DevRel for the org. 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.

• ⁨Comment⁩ on ⁨How to Write Code Without Having to Read It⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Explain to me how this isn’t code golfing.

• ⁨Comment⁩ on ⁨Trying to get release and testing in sync⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  It depends… The myriad of reasons to have a dedicated release day have often to do with synchronizing marketing, support and the other departments.

  My question is what does QA mean for your org? Does it mean defect detection? Testing? Acceptance? Those are all different things. The teams i see that are able to release every day have a strict separation of Quality Control and Functional Acceptance. QC used to detect defects and regression and is handled by highly automated processes accounted for by engineering. Then acceptance is done by a dedicated product/quality team that figure out if the new functionality actually is built to spec and solves the customer problems. This also involves blogs, documentation, customer contact, release notes, tutorials and workshop for the support team etc… This second part is handled by feature flagging, so that the product teams can bèta test, run a limited release and track adoption.

  It really depends on what kind of software youre running and what your relationship is towards the end user and the rest of the org. Something that is the same in all cases is that your requirements and acceptance criteria need to be very clear from the start and regression resting needs to be fully automated.