583 karma · joined March 14, 2014
That’s a great trick to get the exact time from full screenshot
Firefox version - totally agree. We have to do it. I promise we will :)
I wonder if soon LLMs are going to be able to help us get automatic repro steps to be exactly the right level of detail for an engineer.
+1 –– when I worked at Cloudflare, the support team had to teach all of us how to export HAR files from our browsers for engineers. It's definitely a mountain to climb to get good bug reporting working internally.
And that's really nice to hear, thank you so much! Stack traces with source maps. I agree. We integrate now with logging tools like Sentry and I wonder if we can just use sourcemaps from that.
We do two things to address that:
The first is nothing gets recorded and saved (or even sent to our backend) until the user actively chooses to log a bug. So it’s like actively choosing to save a HAR file when there’s a bug.
The second is we scrub all network requests on the client side for anything that resembles PII or sensitive data. We just don’t want it on our servers.
Is there anything else you think we should do?
Definitely building on the Chrome platform there’s always API risk of something changing but I hope Chrome and other browsers will keep it possible to provide a better debugging experience through extensions like ours for people who want it.
Rather than passively record sessions like the tool you’re describing, Jam is an active model. It lets you actively choose when to record the screen. That way we’re able to avoid any creepiness!
We actually get a lot of requests for self hosting and it’s something I think would be great to add in the future.
Dev tools company with 65,000+ users in less than 2 years. $10M in funding from Vercel CEO, GitHub CTO, Cloudflare CEO, etc.
We’re building a flight recorder for web apps – so anyone can report issues to engineers in a way that's actually debuggable (w/ console, network, websockets debugger, etc).
Small, senior team – several ex-engineering directors turned ICs (mostly ex-early Cloudflare). Looking for staff-level engineers with experience building highly performant front-end apps.
Stack: React/Typescript and MobX (MST) on the frontend, and Node/GraphQL across our backend.
The challenge ahead: Scaling. Usage 10x’ed last year, and our users are in 150+ countries, on all sorts of devices, network conditions, etc. Our bar for quality is high.
As a dev tool, developers at Jam are directly connected and involved with the product. Your usage of the product will directly inform the direction of Jam’s future.
Apply here (we read and respond to every submission): https://8wvzuv0oszm.typeform.com/work-at-jam
Bug reporting hasn't changed since the 1990's. We're changing that. Here's why: https://jam.dev/blog/bug-reporting-time-for-change/
20,000+ users and growing fast.
Job description & application: https://careers.jam.dev/Senior-fullstack-engineer-ab27779e1a...
Bug reporting hasn't changed since the 1990's. We're changing that. Here's why: https://jam.dev/blog/bug-reporting-time-for-change/
18,000+ users and growing fast.
Job description & application: https://careers.jam.dev/Senior-fullstack-engineer-ab27779e1a...
Bug reporting hasn't changed since the 1990's. We're changing that. Here's why: https://jam.dev/blog/bug-reporting-time-for-change/
15,000+ users and growing fast.
Job description & application: https://careers.jam.dev/Senior-fullstack-engineer-ab27779e1a...
That's so awesome.
The Jam dev team recently shipped a major refactor of all the state handling in the app a few weeks ahead of schedule and that's because the team spent so much time upfront documenting and planning the changes. Thanks to Tony Stuck for showing us how important doing upfront planning is on the Jam engineering team!