(评论)
(comments)

原始链接: https://news.ycombinator.com/item?id=40318542

Jam 是一个小团队历时四年开发的创新工具。 Jam 旨在简化工程师提交清晰准确的错误报告的过程,解决了缺乏编程专业知识的产品经理面临的常见挑战。 报告错误的传统方法通常含糊不清,导致团队之间的混乱,阻碍调试阶段的进展。 为了解决这些问题,Jam 提供了一个用户友好的平台,其中包含与视频集成的开发工具。 这使得产品经理能够轻松地演示错误,而不是试图通过口头或容易被误解的书面描述来阐明它们。 此外,它还包括自动生成的重现步骤以及与 Google Chrome DevTools 等流行开发工具同步等功能。 据报道,使用 Jam 修复了超过 200 万个错误,该团队致力于提高其对用户的价值,并欢迎反馈以继续改进调试体验。 我们鼓励有兴趣加入革命性调试流程使命的工程师通过访问他们的职业网页来探索 Jam 的机会。 该公司重视通过提供免费版本的服务所获得的投入,并将继续提供此免费模型,作为其促进开发者社区内公开对话和协作的承诺的一部分。

相关文章

原文
Hey HN, I wanted to show you a product a small team and I have been working on for 4 years. https://jam.dev

It’s called Jam and it prevents product managers (like I used to be) from being able to create vague and un-reproducible bug tickets (like I used to create).

It’s actually really hard as a non-engineer to file useful bug tickets for engineers. Like, sometimes I thought I included a screenshot, but the important information the engineer needed was what was actually right outside the boundary of the screenshot I took. Or I'd write that something "didn't work" but the engineer wasn't sure if I meant that it returned an error or if it was unresponsive. So the engineer would be frustrated, I would be frustrated, and fixing stuff would slow to a halt while we went back and forth to clarify how to repro the issue over async Jira comments.

It’s actually pretty crazy that while so much has changed in how we develop software (heck, we have types in javascript now*), the way we capture and report bugs is just as manual and lossy as it was in the 1990’s. We can run assembly in the browser but there’s still no tooling to help a non-engineer show a bug to an engineer productively.

So that’s what Jam is. Dev tools + video in a link. It’s like a shareable HAR file synced to a video recording of the session. And besides video, you can use it to share an instant replay of a bug that just happened — basically a 30 second playback of the DOM as a video.

We’ve spent a lot of time adding in a ton of niceties, like Jam writes automatic repro steps for you, and Jam’s dev tools use the same keyboard shortcuts you’re used to in Chrome dev tools, and our team’s personal favorite: Jam parses GraphQL responses and pulls out mutation names and errors (which is important because GraphQL uses one endpoint for all requests and always returns a 200, meaning you usually have to sift through every GraphQL request when debugging to find the one you’re looking for)

We’re now 2 years in to the product being live and people have used Jam to fix more than 2 million bugs - which makes me so happy - but there’s still a ton to do. I wanted to open up for discussion here and get your feedback and opinions how can we make it even more valuable for you debugging?

The worst part of the engineering job is debugging and not even being able to repro the issue, it’s not even really engineering, it’s just a communication gap, one that we should be able to solve with tools. So yeah excited to get your feedback and hear your thoughts how we can make debugging just a little less frustrating.

(Jam is free to use forever — there is a paid tier for features real companies would need, but we’re keeping a large free plan forever. We learned to build products at Cloudflare and free tier is in our ethos, both my co-founder and I and about half the team is ex-Cloudflare) and what we loved there is how much great feedback we’d get because the product was mostly free to use. We definitely want to keep that going at Jam.)

By the way, we’re hiring engineers and if this is a problem that excites you, we’d love to chat: jam.dev/careers

联系我们 contact @ memedata.com