Steve Coffman StevenACoffman

https://www.honeycomb.io/blog/structured-events-basis-observability
An event is a conceptual abstraction and a structured log is one possible representation of that abstraction. The interesting part of the conversation is where to draw the lines around that abstraction; the technical implementation part is how to represent that event.
Explicit propagation requires explicitly passing the active context from function to function as an argument (Go).

For distributed context propagation, OpenTelemetry supports several protocols that define how to serialize and pass context data:

W3C trace context in traceparent header, for example, traceparent=00-84b54e9330faae5350f0dd8673c98146-279fa73bc935cc05-01.
https://www.w3.org/TR/trace-context/#version-format

// ProtoDiff generates an indented summary of the diff between two protos'
// YAML representations. See ProtoToYAML for documentation on rewrites.
func ProtoDiff(a, b protoutil.Message, args DiffArgs, rewrites func(interface{})) string {
	toYAML := func(m protoutil.Message) string {
		if m == nil {
			return ""
		}
 str, err := ProtoToYAML(m, false /* emitDefaults */, rewrites)

Clean Architecture (2022 H2)

Good architecture:

good architecture = allow changes w/ flexibility + delay decision

Business rules:

Entities: pure; small sets of critical business rules. Should be most independent & reusable. Can be an object with methods or data structures & functions
Use case: not as pure; is an object. contains data elements & operations.
Entities are lower level than (don’t depend on) use cases since use cases are closer to inputs/outputs.
Entities & use cases are 2 layers

If you have several tools that are very closely related, you can make them easier to use, discover, and distribute by combining them into a single tool (and a single executable binary artifact).

If you’ve got a tool that’s sufficiently complex, you can reduce its complexity by making a set of subcommands. This is also useful for sharing stuff—global flags, help text, configuration, storage mechanisms.The above guidance doesn’t help you to decide when something is unrelated and should be separated, BTW.

It is worth comparing this advice to the Command Pattern from the “Gang of Four” “Design Patterns” book, where you encapsulate an an action or a request as an object that can be parameterized. Usually, in the Command Design Pattern the invoker doesn’t know anything about the implementation details of the command or it’s receiver, it just knows the command interface and its only responsibility is to invoke the command and optionally do some bookkeeping of what commands are possible and/or valid. There are

Random AST and SSA Helpers

	package main

	import (
	"fmt"
	"log"

	"context"

	"cloud.google.com/go/storage"

	package main

	import (
	"fmt"
	"io/ioutil"
	"log"

	"context"

	"cloud.google.com/go/storage"

	package main

	import (
	"fmt"
	)

	var (
	ones = []string{
	"zero", "one", "two", "three", "four",
	"five", "six", "seven", "eight", "nine",

	package main

	import (
	"fmt"
	"go/ast"
	"go/parser"
	"go/token"
	)

	func main() {