Steve Coffman StevenACoffman

From https://www.reddit.com/r/golang/comments/1kwklgf/comment/mui4zkq/

Without a tool like buf, it's a lot of work for the consumers.

Let's say you leave the project layout exactly as in your question:

my-library/
└─ directory1/shared.proto

so downstream code can keep writing

https://jeremymorrell.dev/blog/a-practitioners-guide-to-wide-events/

All events can be represented as structured logs, but not all structured logs are events. An event contains information about what it took for a service to perform a "unit of work". Treating an event as a "unit of work" lets you adjust what it means depending on the goals of the observer. An event is a conceptual abstraction and a structured log is one possible representation of that abstraction. I like the idea of a "Arbitrarily wide structured events" / "canonical log line" collecting all possibly relevant key-values like a lint roller collects dust. Putting all the important telemetry data in a single log line makes it easy for everyone to query for answers, without the need for complex joins or manual piecing of things together with request IDs, especially during production outages. Arbitrarily wide structured events that describe the request and its context, one event per request per service

// 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",