Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
kiitos
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
43 ms
·
751.
▲
by
kiitos
3y ago
There are well-defined interfaces for specific sub-classes of telemetry data. Prometheus provides a set of interfaces for metrics which are pretty battle-tested by now. There are similar interfaces for logs and traces, authored by various d
752.
▲
by
kiitos
3y ago
General-purpose observability systems serve two use cases: presenting a high-level summary of system behavior, and allowing operators to inspect telemetry data associated with a specific e.g. request. The former use case is often solved b
753.
▲
by
kiitos
3y ago
I've been deeply involved with OTel from even before it was a CNCF jam. My experiences with the project, over time, have made me basically abandon the project as unsound and infeasible since a year or two. Those experiences also inform
754.
▲
by
kiitos
3y ago
I have no reason to do so, because I don't believe that OpenTelemetry is a project that was created, or is maintained, in good faith to its stated goals.
755.
▲
by
kiitos
3y ago
Sampling is fine at the query layer, but if you sample at the ingest layer -- and therefore drop a majority of your telemetry data outright -- that's a total hack, and I can't see how the resulting system is anything but unsound.
756.
▲
by
kiitos
3y ago
Instrumentation isn't solved by any single specific thing. It's a praxis that you apply to your code as your write it, like I guess error handling; it's not a product that you can deploy, like I guess Splunk or New Relic or w
757.
▲
by
kiitos
3y ago
OpenTelemetry is a marketing-driven project, designed by committee, implemented naively and inefficiently, and guided by the primary goal of allowing Fortune X00 CTOs to tick off some boxes on their strategy roadmap documents. It's not
758.
▲
by
kiitos
3y ago
After more than 30 years of professional software engineering experience, I have to say that the software model described by this document is applicable and/or useful to only an extremely narrow subset of software in general. I would
759.
▲
by
kiitos
3y ago
Likewise.
760.
▲
by
kiitos
3y ago
What an insane way to think about programming. A service should never crash in response to a runtime error, or any kind of business logic conditional! Crashes are not normal, they signal critical problems and/or programmer errors. A se
761.
▲
by
kiitos
3y ago
If you allow arbitrary code to terminate the process, then the control flow of the program is effectively non-deterministic, and impossible to model, or even really understand. Software written in this way is fundamentally unreliable.
762.
▲
by
kiitos
3y ago
An error is an error. The immediate caller is always responsible for detecting and handling errors in whatever way is appropriate for their calling context.
763.
▲
by
kiitos
3y ago
Panic doesn't reliably abort the program. And, in any case, arbitrary code doesn't have the right to abort the program in the first place! Only func main is allowed to terminate the process. Errors in any other context should alwa
764.
▲
by
kiitos
3y ago
Nope. Panic isn't an ersatz error reporting mechanism, it's a tool of absolute last resort. Any function or method that can fail should return an error, and should signal failure via that error. Callers that invoke any fallible fu
765.
▲
by
kiitos
3y ago
> But my argument was about errors that can't be dealt with locally, where the origination and ultimate handling are very far apart. A given flow will encounter these errors relatively rarely compared to the happy path (and if it&#x
766.
▲
by
kiitos
3y ago
Not exactly -- you should only fmt.Errorf wrap errors which are non-nil. See my sibling comment: https://news.ycombinator.com/item?id=37234455
767.
▲
by
kiitos
3y ago
Every error should be annotated at the call site. fmt.Errorf("...: %w", err) isn't litter, it should be a basic expectation of any code which passes code review. > Errors are akin to exceptions in C++/Java: no happy p
768.
▲
by
kiitos
3y ago
If your application models a remote API in terms of endpoints which are either read-only/GET or read-write/POST, then you're subverting your own interests. There's no reason to constrain yourself in this way.
769.
▲
by
kiitos
3y ago
func bar() error { err := baz.Transmogrify() return fmt.Errorf("bar: %w", err) } This is broken. If baz.Transmogrify() returns a nil error, bar will return a non-nil error. Also, annotations like this
770.
▲
by
kiitos
3y ago
Order should be preserved up to the Handler. Some Handlers e.g. JSONHandler produce output with key order explicitly undefined.
771.
▲
by
kiitos
3y ago
Shared understanding + bus factor. Everything else is marginal.
772.
▲
by
kiitos
3y ago
+1, every PR should ideally be reviewed within a day, and certainly within a week.
773.
▲
by
kiitos
3y ago
Stable? Maybe. Maintainable in a business-continuity sense? Possible but unlikely. Code review is an essential part of shipping sound software.
774.
▲
by
kiitos
3y ago
OK, so we're talking about allowing PR merges without a +1 from a reviewer? That's less-bad, but still a red flag :grimacing:
775.
▲
by
kiitos
3y ago
Reviewers are responsible for not just pointing out issues, but also providing (at a minimum) some form of direction, or (more ideally) one or more explicit suggestions as to how to resolve those issues. This is an essential component of
776.
▲
by
kiitos
3y ago
Merge conflicts to the main branch? I've never even heard of an org where it's OK to force-push to main. That's wild! And a huge red flag, that ought to be fixed at priority zero. Wow.
777.
▲
by
kiitos
3y ago
Echoing sibling comments, feature flags are about managing the deployment of new product capabilities, and should always be short-lived. They're not an appropriate choice for any kind of long-lived capability, like anything that's
778.
▲
by
kiitos
3y ago
An essential property of a feature flag is that it is short-lived, existing only for the duration of the roll-out of the feature. In the language of your linked article, feature flags are 1-to-1 with "release toggles" and not real
779.
▲
by
kiitos
3y ago
You've probably heard this before, but it's worth repeating: code review doesn't have to be a "flawed process" that is "nit-picky" -- if it is, there's a problem in your organization that needs to be
780.
▲
by
kiitos
3y ago
Yeah, diagramming with ASCII in a text editor is actually quite virtuous! I wonder if it would be useful to publish a series of screen-capture videos demonstrating how to build these kind of diagrams. It's really not difficult!
More ›