annanay

Yeah that's definitely true, a future direction would be to filter PRs as Chore/Operational/Feature/etc and only create visualisations for Feature Requests - maybe Jev can help here ;)

I checked out your website and found it quite abstract, I understand enforcing team standards on each PR but I don't see more meat beyond that for reviews. Would be keen to see what y'all do in the review space!

Every developer I've spoken to on a team >1 has complained about PR review burnout, no understanding of the codebase anymore and even a lost love for the craft. I think this is primarily happening because every PR reads like its written by a distinguished engineer. (Why say lot word when few word do trick??!!)

Everyone reviews PRs differently but I've personally started relying more on visualisations to get an initial sense of what's happening. So this is my attempt at a skill and a UI kit to help me understand PRs faster. Bugbots help find bugs, but the primary purpose of reviews is to build shared understanding! Shoutout to Blake Smith (https://blakesmith.me/2015/02/09/code-review-essentials-for-...).

I'd love to get HN's take on this :)

Every developer I've spoken to on a team >1 has complained about PR review burnout, no understanding of the codebase anymore and even a lost love for the craft. I think this is primarily happening because every PR reads like its written by a distinguished engineer. (Why say lot word when few word do trick??!!)

Everyone reviews PRs differently but I've personally started relying more on visualisations to get an initial sense of what's happening. So this is my attempt at a skill and a UI kit to help me understand PRs faster. Bugbots help but not really because the purpose of reviews is to build shared understanding! Shoutout to Blake Smith (https://blakesmith.me/2015/02/09/code-review-essentials-for-...).

I'd love to get HN's take on this :)

Overkill but clever :) reminds me of https://www.pinterest.com/pin/we-are-looking-for-graphic-des...

sweet, will use this the next time :)

Yeah I just used off the shelf base material and didn't have the eight equipment to make rounded corners, hence the current diamond shape :(

Ah yeah, I should have mentioned that in the post somewhere, but reflective would definitely be a nice next step. I have seen TheSignGuy use reflective material in his videos, I'll have to find the equivalent on the Cricut store.

Do you have sample images of what this would look like? I imagine the texture and finish won't be as smooth as vinyl but curious nevertheless.

The Parquet backend helped unlock traces search for large clusters (>400MB/s data ingestion) and over longer periods of time (>24h). It also helped unlock TraceQL (a query language for traces similar to PromQL/LogQL). There's more details in this blog post: https://grafana.com/blog/2023/02/01/new-in-grafana-tempo-2.0...

I don't have the exact CPU/bandwidth numbers on me right now but CPU usage has went up by about ~50% on our "Ingester" and "Compactor" components (you can read up about the architecture here - https://grafana.com/docs/tempo/latest/operations/architectur...). But this is optimising for read performance which improved significantly.

Grafana Tempo also switched from Protobuf storage format to Apache Parquet last year. It's fully open source, and the proposal (from April 2022) is here: https://github.com/grafana/tempo/blob/main/docs/design-propo...

The relevant code for parquet storage backend can be found here: https://github.com/grafana/tempo/tree/main/tempodb/encoding

disclosure: I work for Grafana!

This is really interesting, thanks for sharing. What's also cool was the low effort needed for this setup (Java autoinstrumentation + Clickhouse exporter + Grafana Clickhouse Plugin).

Since Tempo is a k/v store that can retrieve traces given a traceID, we need either a metric system that can store traceIDs in exemplars OR any logging framework to log traceIDs that can be copied over to the Tempo Query UI.

The semi structured nature of logs works to the advantage of Tempo, because as developers we have the flexibility to log _anything_, high cardinality values like cust-id, request latency, gobble-de-gook .. the equivalent of span tags. Instead of indexing these as tags, we get advance search features through a powerful query language landing in Loki (LogQLv2).