-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc(llnode): add user journey guide #587
Conversation
Why this structure? My idea was to slowly bring the reader from basic theoretical concepts to basic usage of WDYT? |
Love it!! I am a big fan of this exploratory style of tutorial. If I could suggest a finesse: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The diagnostics documentation is around the User Journey. We normally try to simulate a real-world use case, for example: https://github.com/nodejs/diagnostics/tree/main/documentation/poor-performance#my-application-has-a-poor-performance and then use the steps to fix that.
So, overall the content seems pretty good. But, I believe we'll need to elaborate on the user journey as well.
Thanks for your feedback @No9 & @RafaelGSS 🙌
Could you give me an example? Something like an OOM? Where the size of an object is causing the crash.
The journey we decide to follow here is the "post-mortem debugging," and The journey through these events:
|
My idea is line with what @RafaelGSS suggested. |
Thanks again @No9 :) I have exactly the same vision, it's also what I try to accomplish in that one https://nodejs.org/en/docs/guides/diagnostics/memory/using-gc-traces/ Here is what we could do to move forward:
WDYT? |
Hey @No9 @RafaelGSS 👋 - I added a few lines and updated the structure. Let me know if it fits your expectations 🙌 |
|
||
## Concepts | ||
|
||
### What is post-mortem debugging? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is needed. Even being important, I don't see beginners going to this document as a first reference. I see this document as a tutorial on a specific workflow, in this case, using llnode to diagnose application crash.
So, for instance, I'd replace the sections of What is ***
to Finding function using llnode
or Get crash report using llnode
Does that make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is needed. Even being important, I don't see beginners going to this document as a first reference. I see this document as a tutorial on a specific workflow, in this case, using llnode to diagnose application crash.
I agree to delete the What is post-mortem debugging
; it seems too broad. But for the two others (core dumps & lldb) it could be relevant IMO. What we could do is invite people that are familiar with these concepts to go to the next chapter. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM
## Concepts | ||
|
||
> ✋ If you familliar with the concept of core dump and `lldb`, | ||
> please skip this chapter, and start [here](#explore-your-firstcore-dump) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
> please skip this chapter, and start [here](#explore-your-firstcore-dump) | |
> please skip this chapter, and start [here](#explore-your-first-core-dump) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch
Context
This pull request aims to document
llnode
user journey.Ref: nodejs/llnode#401
Ref: #502
Update