Introduction Most apps that work with time values eventually need to display time to a user. Go has a unique way of allowing you to specify how to display time values that is different from the C library function strftime. The strftime function tends to be the standard for languages and tooling to format time. Go developed its own format specification instead of using any existing format with the idea of being able to maintain a mental model for formatting time.

Introduction In the last video, Bill left off talking about proof of work (PoW) algorithms. In a distributed and decentralized environment, PoW used to be the gold standard for a node to participate equitably in a Blockchain. However, with PoW as the number of nodes on the Blockchain increases, the amount of energy waste increases. This is because each node is performing the same computationally heavy calculation and only one node’s energy usage is leveraged to write the next block.

Introduction In case you missed episode 4, Bill attempted to integrate current database sharing solutions to solve the “database ownership” problem his dependency manager faces. He tried providing copies of the database, implementing a load balancer and replication. While performing these experiments, Bill identified the qualities his dependency manager’s database needs to have for users to trust it. He closed episode 4 by stating that his dependency manager needs a database that is distributed, cryptographically auditable, synchronized and scalable.

Introduction In this video, Paulo shows the benefit of leveraging generic functions to write less code that does more. He starts by walking you through an API server he initially wrote that makes use of Go’s default HTTP handlers with a sprinkle of GORM to manage database transactions. He then refactors that code by introducing the concept of adapter functions. Paulo’s approach consists of decoupling his business logic with his API code.

Introduction In episode 3, Bill needed to figure out how to share ownership of his dependency manager’s database in a secure and efficient manner. Bill is the only stakeholder with full access to his dependency manager’s database. That is, he is the only person with the ability to mutate the database. This is problematic because he can freely edit the database which will make it harder for other users to confidently perform audits.

Introduction In episode 2, Bill designed a database for his dependency manager to enable Go developers to have reproducible,durable and secure builds. This database will house the hash value for each of the dependencies stored. During runtime, these hash values are compared with the dependencies a user has locally. Bill’s tool makes this comparison to make sure the user has the right version of the dependency. Each team making use of Bill’s dependency manager will have access to its database, however, his database lacked any means to reliably perform audits.

Introduction In episode 1, Bill finished by describing the dependency management conundrum Go faced in its early days. Prior to the Go team providing the module system, developers were on their own to find a solution. Engineers in the Go community did propose different solutions, but there was no general consensus on which tool to use for dependency management. In this video, Bill will begin to architect a solution to the reproducible build problem.

Introduction In this video, Bill will introduce the concepts of what a blockchain is, the benefits of a blockchain, and the network environment it operates in. Bill describes a blockchain as a single, append-only, transparent, publicly available and cryptographically auditable database. Blockchains operate using a peer to peer (p2p) network with no single node designated as the central authority. To better understand what all that means, Bill begins to work through a familiar problem of creating reproducible, durable, and secure builds that software teams face.

Introduction A blockchain is an integrated solution of different computer science problems in the form of a single, append-only, publicly available, transparent, and cryptographically auditable database that runs in a distributed and decentralized environment. I’ve heard many times that blockchain is a technology looking for a problem to solve. I disagree with that assessment because the tech and computer science behind blockchain has practical uses in everyday engineering problems. One use of this technology that comes to mind is a dependency management verification system.

Introduction In the first three posts, I explained there were four aspects of a blockchain that this series would explore with a backing implementation provided by the Ardan blockchain project. Digital accounts with electronic signatures and verification Transaction distribution and synchronization between computers Redundant storage and consensus by different computers Detection of any fraud to past transactions The first post focused on how the Ardan blockchain provides support for digital accounts, signatures, and verification.