[HN Gopher] Show HN: A web debugger an ex-Cloudflare team has be...
___________________________________________________________________
Show HN: A web debugger an ex-Cloudflare team has been working on
for 4 years
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
Author : thedg
Score : 571 points
Date : 2024-05-10 13:08 UTC (9 hours ago)
| thedg wrote:
| *engineers I work with are telling me that some of you are going
| to argue that types don't exist in real javascript and that web
| assembly isn't assembly
| nolok wrote:
| Well it's bytecode, so if you consider java or dot net bytecode
| assembly then it's assembly, if not then not. If we want to be
| pedantic, assembly is usually defined as being close to the
| architecture machine code, which web assembly is not.
|
| Yeah, I fell into that trap, but it's a holiday here.
| thedg wrote:
| Haha I knew this would happen!
| Rapzid wrote:
| I'm on holiday so I'll have a go and join the pedantic train.
| It's not as you say close to the hardware so it's
| intermediate code. And nobody argues .Net IL is assembly.
| neonsunset wrote:
| A lot of people get confused by _assembly_ in WASM
| unfortunately, which leads them to claim that it is
| performant and if it 's not, then fixing it is a trivial
| exercise of _just_ making a fast WASM JIT compiler. Where did
| I hear this before?
|
| They really should have gone for JSVM IR or something, but
| that would sell it to no one.
| liamkinne wrote:
| Nice looking landing page. Small bug, when I scroll down the page
| and then click "pricing" it doesn't take me to the right spot on
| the page until I click again. On Firefox 125.0.3
| iglio wrote:
| Can you use https://jam.dev/ to file the bug report?
|
| Joking aside, this looks really cool!
| thedg wrote:
| Ahahaha thank you!!
| thedg wrote:
| On it! Thanks for letting me know!
| alt227 wrote:
| They dont even support Firefox with thier browser extension
| product. Looks like this team give Firefox very little love :(
| nbrempel wrote:
| We've started using this. It's fantastic! Great work. Thank you
| :)
| thedg wrote:
| Ah that makes me so happy to hear!! Thank you. If ever you have
| feature requests or anything, I'd love to hear: dani@jam.dev
| skaterkid wrote:
| A little under 10 years ago I used a product that was designed
| for improving the website by providing heat maps, but also let
| you drill down to individual sessions. You could see everything,
| from console to UI to mouse movements. It was actually pretty
| neat and incredibly useful for debugging.
|
| It was so neat and useful that as an engineering team we had to
| hide it from the rest of the company because we were worried it
| would be used to "spy" on employees. (Id like to note that it was
| only ever installed on internal tooling that was custom built)
|
| How has jam addressed this concern?
|
| Also, is there self hosting?
| greenavocado wrote:
| Very cool; I use Yandex Metrica for this on public sites
| thedg wrote:
| That sounds super useful!
|
| 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.
| qa-guy wrote:
| I think you should expand the bug report with classic fields like
| Preconditions, Expected and Actual Result...
| thedg wrote:
| Yes! And we wonder also whether LLMs will get good enough soon
| to reliably auto-fill those. That would be amazing.
| Thaxll wrote:
| "network tab" isn't it a security concern to record API calls?
|
| Also how future proof it is with Google changing Chrome addons
| permissions / API etc...?
| thedg wrote:
| Great concern!
|
| 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.
| nightpool wrote:
| Some kind of end-to-end team encryption would be great, I
| could generate a local passphrase using 1Password or
| something and put it in the team vault. Then you wouldn't
| have access to the request metadata (maybe outside of
| hostnames?) on your servers. Alternatively, an option to
| simply download local replays and then a desktop/electron
| viewing client instead of having to upload them to a server
| would be great too
| thedg wrote:
| I like that idea a lot, we should do that
| floobertoober wrote:
| Maybe scrub cookies and authorization headers by default, but
| make them an opt-in for bugs where they're relevant?
|
| Edit: it looks like this is already the case!
| dewey wrote:
| > but make them an opt-in for bugs where they're relevant?
|
| The tool seems to be built for people who don't know what
| to include in a proper bug report (As they are maybe not
| technical enough), so not sure how helpful that choice
| would be for them.
| Bilal_io wrote:
| I see in the Security page [0] that you filter out headers
| that you think are PII or tokens. And I see that you're
| willing to receive feedback via email. I don't think this
| approach is scalable, for the main reason that sometimes we
| use custom headers to pass tokens.
|
| My suggestion is to have a setting that lists default headers
| you think should be obfuscated, and the user/team can remove
| and add to them as they like.
|
| 0. https://jam.dev/docs/product-features/dev-tools/security
| irtefa wrote:
| [disclosure: I work at Jam]
|
| Yes! I think that's a great idea.
| cxr wrote:
| > we scrub all network requests on the client side for
| anything that resembles PII or sensitive data
|
| Hopefully not the same way that atrocious HAR "sanitizer"
| that Cloudflare released works.
| rjmunro wrote:
| I can't see anything on jam.dev/careers about where in the world
| you are located, or if you are open to remote applicants.
| irtefa wrote:
| Hi! I work at Jam. We are 100% remote.
| dbarbarito wrote:
| Looks very useful for developers but I am not a fan of being on a
| website that has a keylogger installed onto it. I know this is
| not the first tool to do this, but the thought of every single
| thing I do getting stored by some third party tool is a bit
| scary.
| noman-land wrote:
| Every single website is a keylogger. Act accordingly.
| nwsm wrote:
| See: PostHog (YC W20)
|
| https://news.ycombinator.com/item?id=22376732
| toekneestuck wrote:
| [disclosure: I work at Jam]
|
| I generally agree with you. I think there's a few important
| things to note:
|
| - Since Jam is a browser extension, its functionality only
| applies to the user that installed it (i.e., only you, not
| everyone that visits website X) - All captured data stays
| locally in your browser until _you choose_ to submit a bug and
| its details* - You can choose which sites the extension is
| enabled on if you want to further limit the scope of
| functionality - We have some user preferences to enable/disable
| certain functionality of Jam already, and I'm confident we'll
| add more over time!
|
| * to be fully transparent: we _do_ collect application
| telemetry so we can identify bugs and performance issues, but
| we take great care in reporting information that is centered
| around what our application is doing, not what it is capturing.
| duxup wrote:
| JUST in time for me man thank you. I'm going to try it.
|
| Our company has just grown to where it isn't just some engineers
| and a few sales guys. Now we're trying to keep engineers working
| efficiently. / accurately, and the support team is ramping up.
| Making it easy for the sales or support guys to log a good ticket
| or bug is a never ending challenge. This looks like a great
| option.
|
| I worked in support for ages and later moved to an engineering
| role, it's a mountain to climb to get good communication /
| reproducing things accurately enough for the engineers to really
| take action effectively.
| thedg wrote:
| That is really awesome to hear. Thank you for such a nice
| message!
|
| +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.
| gkiely wrote:
| Nice work, looks like you've got some big names using it too,
| congrats.
|
| I have some feedback on your homepage & messaging.
|
| Initially scrolling the home page I thought it was a tool for
| viewing customer bug sessions, similar to TrackJS or Sentry.
|
| Reading this post it became clear this is for product managers
| and/or team members to file bugs. The line "Built for everyone"
| on the home page threw me off.
|
| I think if you make the distinction that this is an internal tool
| for teams vs. an external tool for tracking customer issues it
| might help make this messaging clearer.
|
| I'm not sure of your plans (perhaps you also intend for external
| users to use it) this was just my first pass impression.
|
| I think this is a great tool. The structured format combined with
| the information provided by the extension are what make it
| valuable to me. The last minute feature is also nice as re-
| creating bugs can be a PITA.
|
| As a dev, I would ideally also want to be able to view stack
| traces with source maps, but having a consistent structured
| format combined with the extension data is enough of a value prop
| to start using it.
| thedg wrote:
| I agree with your comment on messaging, that is fantastic
| feedback-- reading through the comments here in the HN thread,
| it seems like that's a common understanding from our landing
| page. I appreciate you flagging that, we should find better
| wording to make it more clear.
|
| 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.
| franze wrote:
| Landingpage tip: Show your real product at least once, in a
| screenshot, in a video. Currently all images, videos are stylized
| which makes me think you are hidding something or at least I do
| not know what I will get.
| thedg wrote:
| That's good feedback!
| sergeyski wrote:
| Looks similar to replay.io
| Bilal_io wrote:
| What I don't like about replay.io is that it requires you to
| use their custom browser.
| acemarke wrote:
| Hi, I work at Replay.io. There's a very good reason for that
| "custom browser" requirement.
|
| Session replay tools like LogRocket or Jam do capture a lot
| of information, but they can only capture what's _in_ the
| page, and are thus limited by the JS execution environment
| and permissions. This is still very useful for seeing what
| the user did in the page, and you do get a good amount of
| detail (video, DOM, network).
|
| Replay.io works by capturing the browser's calls into the
| operating system. (This is really complicated! Our fork of
| Chromium has thousands of lines of custom C++ and JS
| modifications in order to capture the runtime information and
| make it queryable.) That enables actually _debugging_ any
| line of code that ran at any time. That's something that
| session replay tools _can't_ do.
|
| So, yes, both Replay.io and session replay tools let you
| _see_ what happened, but only Replay.io lets you _debug_ the
| code _as it ran originally_. And that's only possible because
| we do capture the _entire_ browser's execution.
|
| We've got some sections in our docs that dive into this in
| more detail:
|
| - https://docs.replay.io/time-travel-intro/what-is-time-
| travel...
|
| - https://blog.replay.io/how-replay-works
|
| - https://docs.replay.io/comparison/session-replay
|
| Not only does Replay.io let you _debug_ recordings of bugs,
| we've got a Test Suites dashboard that lets you record
| Playwright or Cypress E2E tests _as they ran in CI_. This is
| possible because we can run your E2E tests with our own
| browser, and thus record them as they're running.
|
| Finally, a sneak peak: we're currently prototyping some new
| advanced functionality that would actually _diff_ passing and
| failing E2E tests to figure out where a failing test went
| wrong, surface that info to developers, and help them
| identify common failure reasons in their tests ("27% of your
| failures in the last month were due to Apollo Client failing
| to connect"). Still very early, but we've got the core
| functionality working! Again, this is only possible because
| we've recorded the _entire_ browser's execution, and can then
| replay that browser at will and query for every bit of JS
| execution that happened.
| modern-sapien wrote:
| IDK.
|
| Sanitizing chrome for testing makes a lot of sense as
| different versions of chrome have been proven to be
| unreliable.
|
| Playwright uses a sanitized chrome version.
|
| And Cypress does not, and allows users to use their own
| browsers which may be a reason for some not insignificant
| portion of flake. They definitely had multiple instances
| where a particular chrome version was unstable leading to
| lots of customer complaints regarding their reliability.
| ltbarcly3 wrote:
| I wouldn't use "cloudflare" as a selling point. People that have
| used cloudflare know how good the engineering work they do
| actually is.
| wizzwizz4 wrote:
| Afaik, only Cloudflare's "checking if the site connection is
| secure" pages are rubbish. And while those are _really_ rubbish
| (as a web user), the stuff they talk about on their devblogs
| seems quite solid. I don 't think your generalisation is valid.
| CafeRacer wrote:
| I think SAML should be available for business tier as well.
| thedg wrote:
| +1, great feedback
| 0xbadcafebee wrote:
| Is there any reason 'enterprise' features can't be purchased
| a-la-carte if your org is <X size? Or for a team of X people
| in a bigger org? Like, if our company has 10,000 people, but
| only 15 people are ever going to use your tool, we cannot
| justify the Enterprise pricing... I run into this all the
| time :(
| horacemorace wrote:
| This is very cool! One of the hardest things in tech is to teach
| non tech people to write decent bugs. Our team wouldn't be able
| to use this because HAR records at L7 only, after browser
| content-decoding. A lot of the problems we find end up with
| symptoms revealed by the encoder or decoder.
| Ankhers wrote:
| Are there extensions planned for other browsers? It seems right
| now when you click on "get jam" button, it takes me to the chrome
| web store.
| AnonC wrote:
| I wanted to know the same and had to dig into the Docs section
| on the website to find that it currently supports all Chromium
| based browsers. Support for other browsers is said to be coming
| in the future.
| thedg wrote:
| Yeah! Right now Jam works on Chrome, Brave, Edge, Arc and
| Opera. We need to build a Safari and Firefox version. It's a
| must do!
| tiffanyh wrote:
| Too cheap.
|
| It seems extremely inexpensive.
|
| Even though it's not a direct comparison, look at
| https://www.hotjar.com/pricing/ (and switch to the "pay by month"
| pricing view)
| jsheard wrote:
| "Suspiciously cheap" is on-brand for an ex-Cloudflare team
| YetAnotherNick wrote:
| I would have easily paid for any of their best in class DNS,
| DDoS protection or CDN, but I get all of those free
| unmetered. Generally when this happens, I get suspicious that
| they are just trying to kill the competition and then
| increase price, but cloudflare has been free for almost like
| forever.
| jsheard wrote:
| It's no secret that those products are free* with a big
| asterisk, if you hit some unspecified combination of total
| bandwidth usage, attracting DDoSes, serving the wrong types
| of files or moving too much data in regions where bandwidth
| is expensive then you get an email from sales asking you to
| pay up or leave. Even if you're on a paid plan, beyond a
| certain (also unspecified) amount of usage they will ask
| you to pay more, until you end up on an Enterprise plan
| where you pay-per-GB just like every other CDN.
|
| They are _currently_ quite generous with how much you can
| use for free or cheap, but the limits being so vague means
| they are subject to change without any transparency,
| potentially pulling the rug on you at any time. That 's
| what I mean by suspiciously cheap.
| YetAnotherNick wrote:
| Do you have any source? I was initially suspicious of the
| same but found few content in reddit/other forums where
| multiple users said they have free plan and get millions
| of requests per day[1]. And I couldn't find a consistent
| reason for all the sites that cloudflare banned.
|
| [1]: https://www.reddit.com/r/programming/comments/lfa1il
| /why_you...
| garretcharp wrote:
| Cloudflare does not have any bandwidth limits or request
| limits in any way. They generally do monitor high usage
| users on lower plans to try and upsell them to enterprise
| but you dont ever have to actually upgrade.
|
| The reddit post you linked seems to not really have any
| content anymore, but I would be willing to bet they broke
| TOS given you are only really supposed to serve html
| content over CDN when on lower level plans when you are
| not using the developer platform to host the content such
| as videos/images/etc.
|
| Fwiw though, if you are a business you probably should at
| the very least upgrade to business for the SLA and to
| create support tickets if needed.
|
| edit: figured out why the article doesnt exist the OP
| removed it because it was an issue on his end not
| Cloudflares. (Using bot fight mode on a route supposed to
| be used by bots)
| https://news.ycombinator.com/item?id=26072153
| dotBen wrote:
| Looks like the Jam team have some great investors who will
| steer them correctly but the founders need to consider whether
| they can raise the amounts needed the same way Matthew and
| Michelle (founders of CloudFlare) could back in the day - which
| enabled the generous CF freemium model and turned the company
| into the $25bn company it is today.
|
| From a funding perspective things are very different than when
| CF started.
| garretcharp wrote:
| Cant really compare these at all. Hotjar is for tracking
| heatmaps and recordings from your regular site visitors.
|
| Jam is for your employees to download an extension and manually
| submit the recordings when they have issues and is a pay per
| employee based model.
|
| Jam will generally have very low volume compared to Hotjar
| which is where the price difference really is
| alt227 wrote:
| I got really excited before I saw there was no firefox support.
| Thats a deal breaker for my team :(
|
| I really like this idea and if Firefox support was added I would
| purchase it in a heartbeat.
| toekneestuck wrote:
| [I work at Jam] We do have an internal build for Firefox.. it's
| coming :)
| alt227 wrote:
| Awesome, I will check back regularly.
|
| This looks like one of those tools that is genuinely really
| useful. I would love be able to tell my users to just fireup
| a browser extension and record a bug, rather than having to
| step them through how to capture all that data manually.
|
| Well Done!
|
| Bookmarking this page for the futuere:
| https://jam.dev/docs/downloads-and-browsers/browser-support
| mattl wrote:
| How about Safari? This would be very useful as not every
| developer has Apple hardware
| toekneestuck wrote:
| Yes! Safari is also on the roadmap.
| jeffhuys wrote:
| Orion could make this easier - basically a Safari fork with
| Chrome / FF plugin support (use it as my daily driver,
| pretty good and uBlock Origin in Safari? Yes please!)
| mattl wrote:
| Consumer facing stuff so nobody in my use case is running
| much other than a few versions of Safari or Chrome on
| desktop or really Safari on mobile. (87-92% iOS on
| mobile)
| dijit wrote:
| I need this, but for Unreal Engine. :(
| orliesaurus wrote:
| I got ya :)
| pknerd wrote:
| Is it something similar to Userback?
| Narushia wrote:
| Haven't heard of this before, seems very useful!
|
| God I wish there was something like this for mobile apps, though.
| Or a website running on the user's mobile device browser. I know
| Firefox Android does support extensions, but most people on
| Android use Chrome. And I think on iOS the browser extension
| situation was miserable the last time I read about it. Either
| way, an app would probably be the best way to do it.
| thedg wrote:
| Yeah! Looks like iOS safari might be the only mobile browser
| which supports extensions at the moment which is too bad,
| because the bug reporting problem is very real for mobile
| aftbit wrote:
| Firefox on Android too, though probably ~nobody uses that.
| giovannibonetti wrote:
| I do!
| jeffhuys wrote:
| Also check Orion!
| brianbreslin wrote:
| This looks incredible. Congrats on launching this.
| thedg wrote:
| Thank you so much!! So kind of you
| utku-0 wrote:
| nice work, love the landing page design, messaging/copy could be
| improved slightly. I was confused on how it was supposed to help
| me without going deeper if that makes sense.
| thedg wrote:
| Thank you! That's great feedback, a few other people mentioned
| the copy could be clearer in the HN thread. That's so important
| for us to know, appreciate you saying so!
| williamstein wrote:
| I wish there were a way to trigger the bug reporter right on
| their landing page, so I can try it out from a user's point of
| view.
|
| Edit: never mind - I see this is a browser extension, so kind of
| a non-starter.
| mark242 wrote:
| The thing I love the most about Sentry/Bugsnag/Honeycomb/etc is
| that it is essentially automated observability. That is, I don't
| need to do a huge amount of integration to have, basically, a
| prioritized list of bugs along with severity and overall
| application health.
|
| I like the idea of the browser extension being able to offer
| these kinds of tools where you wouldn't need to install a heavy
| Javascript snippet -- but I do think that taking the manual steps
| out of debugging wherever you can is the most efficient. With
| Bugsnag et al, I don't need to wait for a user to contact me. I
| shouldn't have to wait for someone to submit a Jam report in
| order to see how healthy my app is.
| wjdp wrote:
| I see these tools as complimentary. Sometimes Sentry &al don't
| capture a user session (blocking, didn't consent &c) and this
| tool acts as a nice fallback you can instruct the user to use
| rather than having to explain how to open dev tools and
| screenshot the console.
| gbalduzzi wrote:
| I think they serve different purposes.
|
| Sentry/Bugsnag etc track _code errors and exception_. But
| sometimes for an user an error is not a code exception, but the
| software having the wrong behaviour.
|
| Some examples:
|
| > "The button brings me to the wrong page"
|
| > "I filled out the whole form but the submit button is not
| enabled"
|
| > "The video should autoplay but is stuck loading"
|
| Those things do not show up in Sentry logs.
| a_t48 wrote:
| Sentry has session replay that should catch all of these
| things - it doesn't look any higher friction than this tool.
| vertis wrote:
| This looks really interesting, but I want to walk you through the
| journey I just had on your pricing page.
|
| 1. This looks really cool and it has a free tier. 2. Okay you
| have to pay for bug trackers...oh cool they support Linear and
| it's only $8. Maybe I'll just put that on my creditcard and get
| the founders to pay for it once it's proven itself. 3.Oh wait
| that's for two users and I have 2 founders (non tech), 3 techs
| and then 1.5 designers. Oh the business tier is $50, well I guess
| I'll maybe discuss it with the founders.
|
| My contact details are on my profile if you want further
| feedback, I have to run to a meeting.
| thedg wrote:
| Appreciate your feedback!
|
| Feel free to reach out and we can give you some free credits to
| your account: dani@jam.dev
|
| We really just care that we can help you streamline bug
| reporting, we don't want the pricing to get in the way.
| sandstrom wrote:
| Some thoughts:
|
| - Make the scrubbed headers configurable (if it isn't already).
| For example, our token header is called `X-Session-Token` and is
| passed on every request. Would your current regex scrub this?
|
| - Maybe clarify that the seat (pricing) is for recorders, not for
| people viewing them (which I think is a reasonable choice).
|
| - Would be nice to configure auto-deletion of Jams after X days.
| We'd probably go with 180 days.
|
| - Would be neat if the Sentry integration had configurable fields
| (at the team level set which ones are visible, and set fixed
| values for some of them). For example, I don't want anyone to set
| the project (that's the triage step in Linear), and I want only
| some teams to be selectable, I'd like to skip the 'effort'
| altogether, etc.
|
| - Make it possible to configure the text body of the Linear
| issue, with placeholders for content. For example, we'd like to
| skip the full-screen (non-cropped), maybe show window size or add
| other metadata that is often relevant to us.
|
| One question:
|
| - For integration with Linear, you are asking for write access to
| the workspace. Maybe explain why that's needed, and what it
| means? Same for read (though this seems more reasonable, an
| explanation would still be useful)
| toekneestuck wrote:
| [I work at Jam]
|
| - Yep, your header would be scrubbed by our default definition.
| And also: yes definitely, configurable scrubbing is on our
| radar/an inevitability. Sensible defaults has been our goal,
| but we're definitely aware that any given keyword may be
| sensitive to one company but not be to another! (e.g, an
| address in the context of a healthcare org's patients may be
| sensitive, but likely wouldn't be considered sensitive for an
| MLS search product)
|
| - Re: Sentry -- Makes sense! There's likely a lot of team-level
| configuration we can add for integrations over time
|
| - Re: Linear -- that's a good question. We used to have much
| deeper integration with some third parties, so I think we may
| be able to tighten up some of those scopes. I created a ticket
| for us to follow up on this, thank you!
| toekneestuck wrote:
| Quick follow up on the integration with Linear: just
| confirmed that we do not need write scopes on the workspace.
| The fix will be in production by next week :)
| TacticalCoder wrote:
| > but the important information the engineer needed was what was
| actually right outside the boundary of the screenshot I took
|
| Ah ah. At one gig we had trained the users to _always_ send a
| screenshot of the entire screen. People reviewing the tickets
| would dump them if the screenshot was cropped and the user
| warned: _" No full screenshot, no ticket"_.
|
| Why? The most important info was the _time_ at which the error
| happened (which, for users who were on Windows, was in the bottom
| right of the screen).
|
| With the time we could look in the logs and the error/bug was
| usually obvious.
| thedg wrote:
| Ha! Right, totally!
|
| That's a great trick to get the exact time from full screenshot
| VoidWhisperer wrote:
| This seems like it would only work if the applications in
| question didn't contain any PII - as soon as you get into
| applications or flows within an application that contain some
| form of PII, either displayed or the user entering it, having
| them send a screenshot of the entire screen is asking for the
| user to accidentally leak their PII to the person reviewing the
| ticket.
|
| Where I work (in which the above would be a problem), we make
| sure to log enough information that given a relative timeframe
| of when the user had the issue, we can usually narrow down to
| where the issue was using context and some querying of the logs
| (splunk is incredibly helpful for this)
| freedomben wrote:
| Indeed, that's a great rule. Another one is "What URL was the
| browser on?" which is rarely ever in cropped screenshots but is
| visible in full screenshot
| mattl wrote:
| Don't many browsers hide the full URL now?
| freedomben wrote:
| Oh maybe, I do remember hearing about that. Mine don't
| (Firefox & Chrome on Fedora) but maybe that's a default
| setting (on Linux) or maybe I changed the setting and
| forgot about it?
| EMM_386 wrote:
| > Why? The most important info was the time at which the error
| happened (which, for users who were on Windows, was in the
| bottom right of the screen).
|
| Except it isn't in UTC and it doesn't show an offset.
|
| Even if you stored the user's timezone, that doesn't mean
| that's where they were working from.
| jojohohanon wrote:
| oooh. you got them. Like figuring out which timezone the user
| was in is impossible. What if the user intentionally set
| their clock wrong to mess with support.
|
| You are being silly.
| avarun wrote:
| No, the people requiring a screenshot to include the time
| instead of just asking the user for an ID and time of error
| are the ones being silly. Have you ever heard of log
| filtering?
| ale42 wrote:
| Or, some users might have hidden the taskbar, or the clock.
| Or have several screens, and only one of them has the
| clock...
| magicalhippo wrote:
| For us it's not the time but the id of the thing they're
| working on, but users tend to like to crop to just the dialog
| or subsection they're having issues with.
|
| It's infinitely easier to help the customer when we can take
| our own look at things.
|
| Good tip, will pass it along to support and see what they say.
| stevage wrote:
| Seems nice but I hate sharing my whole browser window with
| anyone. I don't care to let other people see which plugins I
| use or my bookmarks toolbar etc.
| langsoul-com wrote:
| Can this be added to electron apps?
| orliesaurus wrote:
| I dont work at jam but I built one in electron to debug
| electron apps...desktop apps...all apps - wanna chat?
| e63f67dd-065b wrote:
| I would love it if you could bundle this into electron, there's
| so many random electron apps for which the bug reporting workflow
| is still stuck in the 90s as you say.
| thedg wrote:
| That will be really awesome!
| n00bskoolbus wrote:
| Nice! I remember when this tool launched and I checked it out.
| It's really nice to use with easy to setup integrations. The
| instant replay feature especially is super cool! My biggest
| request would be to please add a Firefox extension!
|
| The Jam team seems like a talented and good group of people. I
| applied a while back and while I was turned down I got an actual
| human response from the team. They also did a push to ask for
| input on improvements for Jam maybe a year ago and offered to
| donate $25 (iirc) to St Judes for every person who responded.
| thedg wrote:
| Thank you so much!! And so kind of you to say, you just made my
| day.
|
| Firefox version - totally agree. We have to do it. I promise we
| will :)
| tharkun__ wrote:
| Looks awesome, thanks for sharing. I definitely am also fighting
| with this. Common complaints "where is the video?" "where is the
| HAR file" etc. Their repro steps are usually bad.
|
| So automatic repro steps sound great.
|
| Looking at the homepage on that though it seems way too detailed
| and will fall prey to how I see our support and PM staff
| reporting bugs via videos they record today already: too many
| clicks and steps that are not necessary and when I try the exact
| same thing it works correctly.
|
| The hard part of proper steps to reproduce is to reproduce it
| with a minimal set of steps that are also actually reproducible
| "from zero".
|
| (of course there are some bugs that are _very_ specific to some
| specific customers data you won 't be able to repro but they are
| in the minority at least for us)
|
| How do you solve that part?
| thedg wrote:
| It's a super interesting problem
|
| 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.
| babelfish wrote:
| Also ex-Cloudflare, have been following Jam for awhile, great
| product!
|
| Something I would love is a way for customers to use this without
| having to install a Chrome extension. It would make debugging
| customer issues much faster - for example, if clicking 'Report a
| bug' on a website automatically triggered the recording flow and
| asked the user to reproduce it.
| croshan wrote:
| Stay tuned! We're building this out soon. :)
| irtefa wrote:
| Hello! Would love to learn more! Can you send me a note at
| i@jam.dev?
| rathboma wrote:
| Do you think this would work as a bug reporting solution for a
| desktop app using electron?
|
| I make beekeeper Studio and struggle with bug reports being very
| vague
| orliesaurus wrote:
| I'd love to chat to you - what's a good email to get in touch?
| rathboma wrote:
| Hey! I'm Matthew (at) beekeeperstudio.io
| decide1000 wrote:
| Why isn't this opensource?
| randomgiy3142 wrote:
| We'd call these non reproducible non errors (200 for GraphQl) as
| "usefully wrong." You see this in AI a lot where they spent
| millions in market research or ask MBA types how to recommend a
| product and it turns out that someone buying a new laptop tends
| to also want to buy new shoes. You'd get people like executives
| not happy they looked bad for spending money on one thing only to
| find out they were way off. Good news is more revenue makes
| people look good, so that's not a hard problem. What's hard is if
| a contact us form stops working (bad example), people stop using
| it but still use the app the same way and spend as much is the
| form and the people behind it necessary or are people brand loyal
| and willing to put up just with a minor bug? Similarly if we get
| something not working and can't reproduce it did a network card
| have a low level error that propagated in such a way even our
| monitoring couldn't pick it up?
|
| I thought this was a new error in complex systems we have now
| with hundreds of clusters creating basically non-deterministic
| problems. But fine I remembered before kernels became better at
| talking to things like drivers and external hardware we'd see
| weird bugs outside our boundaries that were really hard to track
| down and often never manifested themselves in the same way. This
| is when you'd go to the weird guy no one talked to and in a week
| he'd have some piece of odd C code with a hex value doing logic
| no one understood that bypassed whatever error we were having.
|
| It is too bad those guys that I'm pretty sure didn't do much
| largely fell victim to the MBA thinking of the 90s. Now we
| usually will have one team go well we are calling the code right
| and the other saying they are sending it right and both aren't
| wrong except it isn't working so they are. We've reached a point
| where we have contracts with every vendor because the problem
| usually is actually like a Cloudflare :) but I'd argue it'd be
| far easier to just fix or create a work around and file a bug
| with them then spend more time on daily calls working with
| someone like you and knowing your progress. So I know what you
| mean by tools companies use. Unless it has hit industry standard
| we won't even evaluate open source as we couldn't blame someone.
| grodriguez100 wrote:
| I have now read this comment three times and still don't know
| what it is about.
| orliesaurus wrote:
| I read it twice and I don't want to read it a third now.
| ore0s wrote:
| I've definitely felt this problem! Web app development can feel
| like 'playing detective' and chasing down lines more than problem
| solving. I'd download right now but will it help debug chrome
| extensions?
| RomanPushkin wrote:
| I thought I should know that your main page is lagging super
| badly on machines without GPU acceleration
| doctorpangloss wrote:
| > It's actually really hard as a non-engineer to file useful bug
| tickets for engineers... So the engineer would be frustrated, I
| would be frustrated
|
| While I have been in this scenario before, saying something along
| the lines of, "If I don't get 100% bug reports, I can't do 100%
| bug fixes," 9 years of experience and maturity later: no, I
| wouldn't use this. It wouldn't engender me more respect, power or
| efficacy in the organization if I "just" "educated" PMs on how to
| file bugs, or if I "just" used some tool for them.
|
| I should have just not asked non-engineers to ticket bugs or do
| QA. If that is happening, you are already failing in terms of
| leadership and organization. Most products fail, so that's not
| saying much, and they rarely fail due to bugs, which is also not
| saying much. That said, the best technical solution is clearly
| comprehensive tracing, and the best cultural solution is that
| engineers responsible for an end user experience must manually QA
| all paths.
| dpe82 wrote:
| That's all well and good, but even a halfway engaged PM is
| going to play with the product while it's in development, and
| they will tell you about what they discover along the way. It
| may not strictly be their job but they're going to do it. If a
| tool exists to help them capture more information that makes
| their inevitable reports more useful, is that a bad thing?
| captcanuk wrote:
| Any chance you can create a cypress test or selenium test out of
| your repro steps? It looks like you are pretty close in the text
| description. Not that I want 1000's of UI tests but a UI test is
| a bug repro that never needed to happen.
| JacobCarlborg wrote:
| Had a quick look. Seems like an interesting tool. I know there
| are many companies in Europe that, for regulations and compliance
| reasons, cannot have their data leave Europe. As far as I can see
| from the documentation, the data is stored in the US. Would be
| nice to have an option to store the data in Europe. Or not having
| to upload any data at all. But instead have the option export an
| artifact that can be processed later. But perhaps that defeats
| the business.
| orliesaurus wrote:
| I am building a version of this that lets you store the data on
| your computer, you can export it and send it to your team
| (manually) so you can use any data hosting you want. Let me
| know if you're interested!
| fudgefactorfive wrote:
| Looks great!
|
| Heads up, for the `Backend Tracing` screenshot there's a typo, it
| reads "enviroment" with the missing 'n' and on the AI debugger
| page on narrower screens the bubble for the "Learn more about
| JamGPT" text doesn't fit the text.
| kernal wrote:
| Sorry, but the need to create an account was an instant
| uninstall.
| steviee wrote:
| Awesome! Will definitely give it a try!
| whoomp12342 wrote:
| do you have a hipaa compliant version?
| gwbas1c wrote:
| > 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).
|
| > ... Like, sometimes I thought I included a screenshot, but the
| important information the engineer needed was what was actually
| right outside the boundary... 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...
|
| > ...the way we capture and report bugs is just as manual and
| lossy as it was in the 1990's
|
| That's because bug reports are primarily communication among
| people, and the problems you describe are _people problems,_ not
| _technology problems._
|
| Bug reports work when engineering can state what they need, and
| management is willing to support engineering's needs. Otherwise,
| bug reports devolve into the situation that you describe above.
|
| In your case, this looks like a great tool for browser
| applications; but it only works if the people submitting the bug
| use the tool: I could easily envision a situation where a lousy
| manager ignores engineering's pleas to use Jam.
| camhart wrote:
| Would love it if this supported more than web. Android, ios, etc.
| 0xbadcafebee wrote:
| Okay, so, stupid question; could you replace this with this
| screen recorder[1] and browsers' built-in web dev tools[2] ? The
| screen recorder lets you record and download a session (nothing
| is uploaded), and the dev tools lets you capture any errors the
| browser sees, the network connections & errors, the source,
| browser data/steps, yadda yadda.
|
| The built-in web dev tools have a _Recorder_ function to record
| what the browser is doing while also recording video[3]. You can
| export the recording in a number of formats. It can replay it,
| let you edit steps, even simulate a slow network. Seems like a
| product person could follow a simple guide to record and export a
| session, and send it to a dev?
|
| [1] https://toolbox.googleapps.com/apps/screen_recorder/ [2]
| https://developer.chrome.com/docs/devtools/ [3]
| https://developer.chrome.com/docs/devtools/recorder
| jchanimal wrote:
| Is anyone using this as the eyes and mouse of an AI copilot yet?
| orliesaurus wrote:
| Yes - sort of!
| aleksiy123 wrote:
| Really cool product.
|
| One of those ideas/things that seems to just be "obvious" after
| the fact. Especially in the realm of bug reports which are very
| tedious to submit.
|
| Kinda inspiring me to try and look around me for similar problems
| to solve.
| mr_cyborg wrote:
| This is a really cool tool! I wanted to ask - you mention HAR
| files - how do you ensure tokens and secrets don't end up in them
| / stored on your end or anywhere else they may end up?
| fagrobot wrote:
| super duper!
| paustint wrote:
| We have been using Jam on our team for a long time (~2 years) and
| it is awesome! Everyone on our team is posting jam videos to
| report bugs, explain and walkthrough issues, add a demo on every
| PR with a demo of what frontend changes are included in the
| ticket so that QA can get a jump start on understanding the scope
| of what to test.
|
| I normally just record the jam and get a link and paste it
| wherever, but I love the ability to have Jam create jira tickets
| for me. And THANK YOU for making it easy to choose the sprint!
| the Slack Atlassian plugin makes it impossible to find the sprint
| and shows all the closed sprints that cannot be used for new
| tickets.
|
| Really an awesome tool. I have been using it to report bugs for
| any random open source project I am working on.
| Lorin wrote:
| Might want to fix the typo in the feature list "Om-premise data
| storage" :)
| orliesaurus wrote:
| Not to steal your thunder but we're building the same tool [1]
| but for the WHOLE desktop experience, not just the browser - if
| anyone has any feedback I'd love to talk to you!
|
| [1] https://www.dashcam.io
| suresk wrote:
| Kind of funny, I was just looking at adding similar functionality
| to an internal Chrome plugin I built because we struggle to get
| enough useful info in bug reports (being able to look at the HAR,
| in particular, is useful, but difficult to get users to do
| correctly).
|
| Two questions -
|
| 1) Any way to customize which headers/cookies get scrubbed?
|
| 2) Is there a way to get something like the lower-level export
| you can get by going to chrome://net-export/?
| wedwin53 wrote:
| Great work!
___________________________________________________________________
(page generated 2024-05-10 23:00 UTC)