Readit News logoReadit News
pondidum commented on Printf debugging is ok   polymonster.co.uk/blog/pr... · Posted by u/thunderbong
pondidum · a year ago
I also think that printf debugging is fine, but there are better tools [1] - however they might be more involved to setup, or not be available in your codebase.

[1]: https://andydote.co.uk/2024/11/24/print-debugging-tracing/

pondidum commented on Htmx 2.0.0 has been released   htmx.org/posts/2024-06-17... · Posted by u/lsferreira42
wruza · 2 years ago
Htmx users, can you please share your backend stacks and approaches? Me specifically interested in templaters for node (+ts) and your thoughts on endpoint management, but all ideas are welcome I guess.
pondidum · 2 years ago
Go: go templates and fiber for http serving. I have a mini framework for adding some structure to the templates (folder per feature: contains controller, templates, etc, and some naming conventions)
pondidum commented on Show HN: I made a HTMX Playground 100% in the browser   lassebomh.github.io/htmx-... · Posted by u/bitterblotter
quickthrower2 · 2 years ago
Thankyou for the awesome library! I have a question.

Is there a way to use HTMX with minimal server side changes. Specifically if I have an existing page that you fill in a form and submit and response is of course the entire page. I think it would be cool to tell htmx that the whole page is being returned BUT I only want to update #my-form and that way you don’t need any “if htmx request” kinda stuff on the server.

This is for people who care about their site working without JS. But also it allows you to have a single backend endpoint to handle multiple things (for example comments, sign up to email, like button, all in one)

pondidum · 2 years ago
If I understood correctly, you can achive this with `hx-target` and `hx-select` - I'm doing this in an app to replace an editor content based on which link is clicked.

- https://htmx.org/attributes/hx-select/ - https://htmx.org/attributes/hx-target/

pondidum commented on Tracing: Structured logging, but better   andydote.co.uk/2023/09/19... · Posted by u/pondidum
lambda_garden · 2 years ago
Couldn't this be injected into the runtime so that no code changes are required?

Perhaps really performance critical stuff could have a "notrace" annotation.

pondidum · 2 years ago
Yes, and itel has instrumentation libraries which do this.

However, no automatic instrumentation can do everything for you; it can't know what are all the interesting properties or things to add as attributes. But adding tracing automatically to SQL clients, web frameworks etc is very valuable

pondidum commented on Tracing: Structured logging, but better   andydote.co.uk/2023/09/19... · Posted by u/pondidum
jasonjmcghee · 2 years ago
I really enjoyed the content- it's a great article.

Note to author: all but the last code block have a very odd mixture of rather large font sizes (at least on mobile) which vary line to line that make them pretty difficult to read.

Also the link to "Observability Driven Development." was a blank slide deck AFAICT

pondidum · 2 years ago
They all look fine in "mobile view" in firefox, and on firefox in android.

It's all statically rendered html, and I don't see anything weird in the html either.

Do you have a screenshot and some device info so I can look a bit more? Thanks

pondidum commented on Tracing: Structured logging, but better   andydote.co.uk/2023/09/19... · Posted by u/pondidum
zoogeny · 2 years ago
One thing about logging and tracing is the inevitable cost (in real money).

I love observability probably more than most. And my initial reaction to this article is the obvious: why not both?

In fact, I tend to think more in terms of "events" when writing both logs and tracing code. How that event is notified, stored, transmitted, etc. is in some ways divorced from the activity. I don't care if it is going to stdout, or over udp to an aggregator, or turning into trace statements, or ending up in Kafka, etc.

But inevitably I bump up against cost. For even medium sized systems, the amount of data I would like to track gets quite expensive. For example, many tracing services charge for the tags you add to traces. So doing `trace.String("key", value)` becomes something I think about from a cost perspective. I worked at a place that had a $250k/year New Relic bill and we were avoiding any kind of custom attributes. Just getting APM metrics for servers and databases was enough to get to that cost.

Logs are cheap, easy, reliable and don't lock me in to an expensive service to start. I mean, maybe you end up integrating splunk or perhaps self-hosting kibana, but you can get 90% of the benefits just by dumping the logs into Cloudwatch or even S3 for a much cheaper price.

pondidum · 2 years ago
As other posters have mentioned, the incument companies rebranding to Observability definitely are expensive, because they are charging in the same way as they do for logs and/or metrics: per entry and per unique dimension (metrics especially).

Honeycomb at least charges per event, which in this case means per span - however they don't charge per span attribute, and each span can be pretty large (100kb / 2000 attributes).

I run all my personal services in their free tier, which has plenty of capacity, and that's before I do any sampling.

pondidum commented on Tracing: Structured logging, but better   andydote.co.uk/2023/09/19... · Posted by u/pondidum
koliber · 2 years ago
Does this naive approach work for anyone to allow a log to be read like a trace:

1. At the start of a request, generate a globally unique traceId

2. Pass this traceId through the whole call stack.

3. Whenever logging, log the traceId as a parameter

Now you have a log with many of the plusses of a trace. The only additional cost to the log is the storage of the traceId on every message.

If you want to read a trace, search through your logs for "traceId: xyz123". If you use plain text storage you can grep. If you use some indexed storage, search for the key-value pair.

This way, you can retrieve something that looks like a trace from a log.

This does not solve all the issues named in the article. However, it is a decent tradeoff that I've used successfully in the past. Call it "poor man's tracing".

pondidum · 2 years ago
Yes, but going to this effort, why not move to tracing instead?

A migration path I could see might be:

- replace current logging lib with otel logging (sending to same output) - setup tracing - replace logging with tracing over time (I prefer moving the most painful areas of code first)

u/pondidum

KarmaCake day231November 25, 2018View Original