Steve Coffman StevenACoffman

Go struct Mapping options

Library	⭐
go-viper/mapstructure	8k
jinzhu/copier	6.1k
thoas/go-funk	4.9k
jmattheis/goverter	778
switchupcb/copygen	397
airplayx/gormat	312
go-playground/mold	288

How to Push to Someone Else's Pull Request

Let's say contributor has submitted a pull request to your (author) project (repo). They have made changes on their branch feature and have proposed to merge this into origin/master, where

origin -> https://github.com/author/repo.git

Now say you would like to make commits to their PR and push those changes. First, add their fork as a remote called

Simple DIY STS server Google Cloud Application Default Credential

or...how to use ADC and run your own STS token broker

An STS server will exchange one token for another. This protocol is used by GCP Workload Federation.

THis example runs your own STS server with GCP where the STS server accepts a source token, validates it and the returns a gcp access_token

For more information about STS servers, see

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://thefridaydeploy.substack.com/p/less-is-more-with-opentelemetry-spans?r=36rml&triedRedirect=true

https://github.com/GoogleCloudPlatform/kubernetes-engine-samples/blob/main/observability/distributed-tracing/main.go

https://github.com/GoogleCloudPlatform/opentelemetry-demo/blob/main/kubernetes/opentelemetry-demo.yaml

https://github.com/mterhar/otel-go-batch ( https://www.honeycomb.io/blog/exotic-trace-shapes )

https://blog.bitdrift.io/post/observability-3-0

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

	package main

	import (
	"google.golang.org/protobuf/proto"
	"google.golang.org/protobuf/reflect/protodesc"
	"google.golang.org/protobuf/reflect/protoreflect"
	"google.golang.org/protobuf/types/descriptorpb"
	"google.golang.org/protobuf/types/dynamicpb"
	)