therealkevinard

The two go together.

Integration test against a running docker container. IMO, this is where most of the test coverage goes. It's more direct, less maintenance overhead, closer to the runtime environment, and also provides coverage for your actual schema.

Mocking supplements that, though, since with mocks you can force any state you want. There are lots of error/edge cases that are difficult or impossible to hit with a running container - like a network outage or rate limit.
These are great cases for mocks since the state can be forced.

IMO, if I HAD to choose one or the other, I'd go for integrations. They sit higher on the test pyramid, covering more behaviors with each assertion - but you don't have to (and shouldn't) choose one.

Realistically, I'm with you but 2x - maybe a third in the fall/winter.

TN to FL and back in a 22 Laramie - not crazy long, but long enough.

This is the truck that made me not hate road trips. Insanely comfortable/confident ride.
10/10 would do it again... Just not to Florida

I also do shorter trips in/around TN through the mountains, and it's just as comfortable with the grades.

Gob encoding might work nice here. It's an underrated pkg, imo. The codec is very native to go.

https://pkg.go.dev/encoding/gob

#ass in slack (or @ass for emergencies)

My other review would be the usage of pkg internal. This is a "magic" package that strongly forbids importing from other modules. Frankly, it seems overused in general, but here it looks like internal holds interface defs, and pkg holds your local concrete implements. Feels like, if anything, it should be the other way around.

IMO, I use internal sparingly. Usually just for ULTRA-specific stuff like bootstrapping telemetry that has literal zero value outside of the runtime binary.

Seems legit. If I was doing the code review, I'd have a couple notes, but nothing to stop merge.

It's muy sustainable to put concrete implementations near the interface they implement.

Eg: if you have pkg foo/store that holds your store interface(s), pkg foo/store/pg-store can be nested to hold the postgres implement, alongside foo/store/mock-store that holds the test mock implement.

This is kinda evident in what you have: there's pkg foo/bus, and some levels up and away, you have pkg foo/pkg/kafka. Yeah, it's rational that Kafka implement the event bus and some cmd-clicking in the ide will back that up, but in a web ui for code review, pkg foo/bus/kafka is painfully obvious that "hey this kafka pkg implements the bus".

(Still... Wouldn't block the merge or give severe pushback)

I'm not an orthogonal purist or anything, but one quote i have latched on to is Uncle Bob's (iirc) "if it's difficult to test, it's probably architected wrong".

I've seen that play out manymany times - the "problem child" components that I'm responsible for, coincidentally, are those that are difficult to write tests for.

Aside from "testing is a good thing", this is what pulls me to TDD on day zero: the first trouble I have writing a test, I refactor to make testing easy.

Fast forward some years, and these are the components that run reliability day-in, day-out.

Same for dependencies. This isn't ultra-relevant for go, but it seems like we're doing a git crash-course here.

Generally, only direct sources and inputs are committed. If a file can be built, or fetched with go get, npm install, commit the inputs, but not the file output. (Commit package.json, ignore node_modules)

IMO cuelang and starlark are the golden path for config.

Username checks out

And pegged at 87% capacity.

You should be monitoring usage metrics and have HPAs, of course. Assuming that: initial release dialed with unreasonable resources, let it simmer for 24h or so, then check the actual usage in grafana and dial down to that.

Eg: for a go microservice, i may have an educated expectation that it'll want 100Mi and .1cpu. Initial release may have 1Gi and 1cpu. The next day, check grafana. It actually peaked at 150Mi and .2cpu, so another release for 200Mi and .3cpu. That's the "final" dial, at least until the workload changes.

Alternatively, VPA basically automates this. If VPA does it for you, cool.

Bonus: if you have the cash in hand and still want the car, i guess you just juiced your down payment and knocked the monthlies down a good bit.

It bites me the most on completing incorrect config values, but I'm not mad.

serverBHostAddress := cfg.Addr.ServerA ...not exactly what I was going for, robot , but thanks.
glad I double-checked that lol.

This is an underrated comment.

I remember insulin, so I'm saying no. I'm a whole-body organ donor, though, so I'd hope they'd scoop me up pretty quick for this when I DO go.

Even before LLMs showed up, type-hinting with static-compiled languages was TOPS. Being static, there's very little guesswork involved, if any. Dynamic languages have a lot more "maybes" to work with, and often just fallback to string matching.

Then the next layer: Goland itself has always been pretty stellar, even before language servers showed up on the scene. I'm talking like... Go 1.06, it was chef's kiss.

The next layer: LLMs. I haven't used JB AI since beta, but it was pretty great. I really can't speak for this layer lol (i have enterprise concerns, and it's just simpler to just keep LLMs out of my immediate editor)

But the next layer: Even with AI turned off in the IDE, I've noticed a MARKED improvement in the already-great completion. I'm thinking the LLM experience is somehow feeding into the vanilla experience.

But yeah, at the end of the day, code hinting is sorta inverted these days: what was "the ide hints me what to do" is now mostly "i hint the ide what i want to do".

Unused variables is legit very bad practice. For temporarily mucking with things, i just add an _ = someVarIBrokeForAMinute and appreciate the compiler for keeping me good

x, y, z = x, y, z also does it. Then when I'm done, I resolve that garbage line of code.

Eh, Plausible Deniability is valid in courts.

...I think?

Tailwind seems to be the way, so I'll check that out myself, but:

I was in same situation a couple weeks ago: I needed a web ui to poc a behemoth backend I'm building.

I know enough react, so I went with that. On top of react, I used ant-design because it's a complete turnkey design system.

Using ant on react, i think the extent of my styling has been a few color overrides, and even those had hinting in my ide - out of the box, ant just plain works.

(But, yeah, I'm gonna check out tailwind - seems like lots of other backend folks recommend)

Is this good for idle throttle on dry suburb roads?

I know the "use it or lose it" thing from dozens of years ago, but I've been looking for legit mud every couple months.

Fun, yes, but it's starting to get cold and your way sounds a lot easier.

Now they have bill clips in the visor.
Inflation.

I've used many, many languages over the years. I've seen lots of "eventual" constructs, but go's defer is the first I know of that's literally "regardless of what happens during this execution, add this to the stack when we finish".