> Endpoint views break down request volume, errors, latency, and status codes. Crash and ANR detail adds the app version, device, and thread context around a failure. This is where a problematic UI transition can be connected to a backend or runtime condition.
The project README reads like a first draft straight out of Claude, and it's incredibly off-putting. The 'Show HN' post here is so much better; clearly you're capable of writing a decent explanation of what this project is, its history, and for whom you've built it. Take the time and write the damn README yourself.
If you expect human attention, put in human effort.
You're a sophomore at UT, so as a UTCS alum (:wave: from a fellow Turing Scholar) I'm not letting you off the hook. Unless things have majorly changed, I know you're taking 6 hours of writing-heavy coursework.
Wow Turing Scholars! you guys are like the navy seals of CS at UT lol. Yes I appreciate the insight and will actually hand write it (and copy some parts of this post, but it is a bit too goofy to just use the post straight up). One thing you mentioned, I've never heard of Readmes including a history of the project, because I thought Readmes were like a small intro doc with a bunch of hyper links only.
Did you look at them, or did you just tell Claude to look at them? /s
Seriously, though — if the history is valuable and interesting, include it. If it provides context in general, include it; if it’s just overconfident marketing fluff straight from the parrot’s mouth, drop it. I like my READMEs to open with the ‘why’ of the project: why I built it and why you might need it too.
This looks really interesting. I've used LogRocket a lot across a number of businesses with varying volume, mainly to try to uncover these kinds of issues. I know they have an AI layer now but I'd love to try this as an AI native alternative which gets straight to the problem solving. It could save hours of manually watching playback and a lot of effort coming up with potential problems/solutions etc.
Yep yep that's why I didn't like it when I was originally using MS Clarity. It was just summarizing stuff that was obvious (and more importantly after the issues happen). RJ here is built mainly for a single focus of being really automated. Of course, if you want the classic product analytics like replay, crashes, api, heatmaps, that also exists in the RJ dashboard but that's more for human validation of the issues spotted.
> Endpoint views break down request volume, errors, latency, and status codes. Crash and ANR detail adds the app version, device, and thread context around a failure. This is where a problematic UI transition can be connected to a backend or runtime condition.
The project README reads like a first draft straight out of Claude, and it's incredibly off-putting. The 'Show HN' post here is so much better; clearly you're capable of writing a decent explanation of what this project is, its history, and for whom you've built it. Take the time and write the damn README yourself.
If you expect human attention, put in human effort.
You're a sophomore at UT, so as a UTCS alum (:wave: from a fellow Turing Scholar) I'm not letting you off the hook. Unless things have majorly changed, I know you're taking 6 hours of writing-heavy coursework.
Wow Turing Scholars! you guys are like the navy seals of CS at UT lol. Yes I appreciate the insight and will actually hand write it (and copy some parts of this post, but it is a bit too goofy to just use the post straight up). One thing you mentioned, I've never heard of Readmes including a history of the project, because I thought Readmes were like a small intro doc with a bunch of hyper links only.
For example, I looked at the these two Readmes: https://github.com/rybbit-io/rybbit/blob/master/README.md <-- this one is lovely https://github.com/supabase/supabase/blob/master/README.md
Both include pictures, features, ect, but not really histories, unless I'm understanding your comment incorrectly.
Did you look at them, or did you just tell Claude to look at them? /s
Seriously, though — if the history is valuable and interesting, include it. If it provides context in general, include it; if it’s just overconfident marketing fluff straight from the parrot’s mouth, drop it. I like my READMEs to open with the ‘why’ of the project: why I built it and why you might need it too.
Lol. Yeah, do you have a good example I can follow and learn from? That would probably help explain well.
This looks really interesting. I've used LogRocket a lot across a number of businesses with varying volume, mainly to try to uncover these kinds of issues. I know they have an AI layer now but I'd love to try this as an AI native alternative which gets straight to the problem solving. It could save hours of manually watching playback and a lot of effort coming up with potential problems/solutions etc.
Yep yep that's why I didn't like it when I was originally using MS Clarity. It was just summarizing stuff that was obvious (and more importantly after the issues happen). RJ here is built mainly for a single focus of being really automated. Of course, if you want the classic product analytics like replay, crashes, api, heatmaps, that also exists in the RJ dashboard but that's more for human validation of the issues spotted.
[flagged]