jazzdan
Joined 15 years ago
Karma
241
Submissions
31
Member since
Aug 31
Recent submissions
Comment · 4 years ago
Yeah, exactly. Or even just not listed in `earthly ls`, maybe you'd still want to be able to call them manually for debugging purposes.
Comment · 4 years ago
+1 on `earthly ls`. I've also thought it would be valuable to have "public" and "private" targets. When looking at a new codebase it can be hard to know which targets I should use when developing, and which are purely for internal use. Good docs help with this too, but they are not always there.
Comment · 5 years ago
As someone who worked on this it was exciting to get Replay working on three platforms (macOS, Linux, Windows), hopefully proving that our strategy[1] for recording and replaying programs works.
[1] https://medium.com/replay-io/how-replay-works-5c9c29580c58
Comment · 5 years ago
(Replay engineer): Kind of! In the code viewer's left hand side gutter, the one that shows line numbers, if a line of code was never executed it is greyed out. Otherwise if you hover over it we show you how many times that code was executed, and from there you can set a logpoint/breakpoint.
Comment · 5 years ago
(Replay engineer): Yes, replit has been working on adding similar functionality (https://blog.replit.com/debuggest).
In fact: we've been collaborating with them on it! :)
Comment · 5 years ago
Self-hosted is on the roadmap, but getting this to be a universal technique is definitely going to be hard, no arguments there. Gotta start somewhere though!
Comment · 5 years ago
Replay deterministically replays the recording, so if the state of the application when you recorded it caused a network call, then when replaying it we will also "make" a network call _but_, instead of actually going out to the network we will instead return the exact data that was returned when you recorded it.
You can learn more about how Replay works here https://medium.com/replay-io/how-replay-works-5c9c29580c58
Can you expand more on what you mean by a race condition in network calls? If it's a series of network calls that the browser could make in any order than we will make them in the order that they occurred when you recorded it. If it's a race condition that occurs in your backend, then the Replay browser won't really help there (though it will show you the responses you got from your backend when you recorded it).
For help with that, you might want to use Replay on the backend. Right now we have Node support (https://github.com/RecordReplay/node), but other runtimes are on the roadmap.
Comment · 5 years ago
(Replay engineer): Yes it does!
Comment · 5 years ago
(Replay engineer): In the long run we'd love for Replay to prove to the major runtimes that they should build support for this in to the runtime itself, rather than us maintaining many forks. The API that we designed for recording a runtime is open source and available here https://replay.io/driver and could serve as a good starting point.
Comment · 5 years ago
(Replay engineer) Google is currently the only way unfortunately. We wanted to support secure logins at launch, with SSO and Multi-factor Authentication, and focus most of our efforts on the core product. As a result we just went with Google for launch.
We don't currently have any plans to add additional authentication mechanisms but we've heard this feedback from a couple folks and we'll sit down to prioritize it after the excitement of launch has died down. Sorry about that!
Comment · 5 years ago
(Replay engineer): we basically record all the inputs and outputs to a program. In the example of an HTTP request: when recording we'd record that a request was made, and the response. When replaying, rather than make the HTTP request, we return the response that was recorded.
If you're interested you can learn more about how Replay works here: https://medium.com/replay-io/how-replay-works-5c9c29580c58
Comment · 5 years ago
(Replay engineer): re: Windows, we have an alpha build out now, with a wider beta release coming later this year.
re: on-prem, it's definitely something we plan to support, and something we have engineered in to the infrastructure. If you're interested email [email protected], we'd love to talk more.
Comment · 5 years ago
(Replay engineer): We're big fans of RR and pernosco, I love to see those tools get their due. Replay is also designed to support backend programs. We [support Node](https://github.com/RecordReplay/node) today with more runtimes coming soon.
Comment · 5 years ago
(Replay engineer): We support all the debugger features (breakpoints, step in to, step over) and more (step back). We emphasize console.log because we found that time traveling console.logs makes for a good demo, and engineers immediately grok what is it capable of, rather than think that they need to adopt a whole new debugging workflow to use Replay.
Comment · 5 years ago
(Replay engineer): Hey davidten, thanks for trying Replay, sorry about the confusion. You definitely shouldn't need an invite. We're on it, getting a fix out now.
https://dmiller.dev
[ my public key: https://keybase.io/dmiller; my proof: https://keybase.io/dmiller/sigs/DA0FPzfKmhNW7vLwwYypikDjgGY1y0ntd9A5o0aRl58 ]