Made me think. Every time I see a “Postman collection” or similar artifacts, my heart skips a bit. Use curl. Run it interactively in the terminal. When it works, move it into a shell script where you can simply check the status code. Voilà, magic! you’ve got yourself a simple but valuable integration test.
Instead of juggling dashboards and collections of requests, or relying on your shell history as Matklad mentions, you have it in a file that you can commit and plug into CI. Win-win.
At some point, that testing shell script can be integrated into your codebase using your working language and build tooling.
I run into that too. Someone sends me a Postman, and I sit there fiddling with the UI five or ten times instead of just putting it into a loop in a real program. then realize how much time i spent fiddling and pull it into a program, then spend some copying the auth or whatever over, then realize i should've been doing real work.
People like Postman because it's easy to share credentials and config, and easy(ish) to give to less technical people, but the cliff for pulling that stuff into code is often annoying.
"Postman but actually it's a jupyter-style notebook with your credentials" would be cool, although I don't know exactly what that would look like.
I think the biggest hurdle with curl is its syntax. The original HTTPie CLI [1] has a really great syntax that closer resembles something like making a "Postman collection". About the only thing I'm missing these days in httpie that my Postman (and Insomnia) preferring colleagues have is a good plugin for OAuth2/OIDC auth flows.
First. Love that more tools like Honeycomb (amazing) are popping up in the space. I agree with the post.
But. IMO, statistics and probability can’t be replaced with tooling. As software engineering can’t be replaced with no-code services to build applications…
If you need to profile some bug or troubleshoot complex systems (distributed, dbs). You must do your math homework consistently as part of the job.
If you don’t comprehend the distribution of your data, the seasonality, noise vs signal; how can you measure anything valuable? How can you ask the right questions?
> On the one hand, at lower-levels you want to exhaustively enumerate errors...
> On the other hand, at higher-levels, you want to string together widely different functionality from many separate subsystems without worrying about specific errors...
I feel like the Rust ecosystem of crates has naturally grown to handle these two ideas pretty well. `anyhow` for applications, `thiserror` for libraries.
Jokes aside, I liked the idea of listing things by level of detail.
One related issue I run into all the time is how context gets lost when moving between layers. You start with host metrics, then Kubernetes wraps the host and overrides the tags, and suddenly you can’t filter host metrics by node anymore. Watch out.
My first thought: Controlling allocations and minding constraints... honestly, that's engineering stuff all services should care about. Not only "high-volume" services.
I'm definitely in favor of not pessimizing code and assuming you can just hotspot optimize later, but I would say to avoid reusing objects and using sync.pool if it's really not necessary. Go doesn't provide any protections around this, so it does increase the chance of bugs, even if it's not too difficult to do right.
I mean, do it if it's worth it. But the parent seemed to imply everyone should be doing this kind of thing. Engineering is about tradeoffs, and sometimes the best tradeoff is to keep it simple.
Your initial judgement of using sync.Pool is quite overboard. The average go dev would wind up goroutines without much thought and pull in mutexes to avoid trouble. That's a hard thing to manage, using sync.Pool is comparatively easy.
For me it looks like the general sentiment is that go enabled concurrency, which should be leveraged, it also did simplify memory management, which should be ignored. But memory management has an direct impact on latency and throughput, to simply ignore it is like enabling concurrency just because someone said it's cool.
Everyone can talk and give opinions. The real question is if you can actually make a difference. I tell people there's a gap between knowing how to do something and actually doing it. And that gap is a big part of our engineering skills.
If I'm not going to change something, I'd rather not talk or give opinions.
I’m in the situation the article is talking about where I’m both suggesting advice and willing to do the work. But it requires me to have some allotted time and the boss says we don’t have the resources even 1 hour a week.
It’s like we’re moving chopped wood from the forest to the village and I suggest building a wheelbarrow but the boss says what we don’t have time for that we gotta move all this chopped wood. It’s crushing to have a job that could be very interesting but the tooling and processes sap all of that out.
> Any time you are making decisions based on information that you know at compile time, you could apply this technique
I’d go further. Most business requirements are known at compile time.
Take the simplest example, dispatching a function based on a condition. If A then do_X, if B then do_Y.
People often reach for elaborate design patterns, dependency injection, or polymorphism here. But why?
If the decision logic is static, don’t turn it into a runtime problem.
Inline the code. Move the ifs up. Write clear, specific functions that match your domain knowledge instead of abstracting too early…
Instead of juggling dashboards and collections of requests, or relying on your shell history as Matklad mentions, you have it in a file that you can commit and plug into CI. Win-win.
At some point, that testing shell script can be integrated into your codebase using your working language and build tooling.
reply