این دو تا هم درمورد آداب کد ریویو و مرج رکوئست زدن بودند که بنظرم مفید هستند.
Do the pre-work
Help challenging code reviews go smoothly by reaching out to prospective reviewers before writing any code. Describing the problem and your approach ahead of time reduces surprise and provides an opportunity for early input. Ensure the decisions resulting from these exchanges, as well as the reasoning behind them, are accessible to others (e.g. via bug or design doc).
Mind your reviewer
Make choices that spare your reviewer time or cognitive load, such as preferring a series of short changes to a massive one, or uploading separate patches to isolate rebases during review.
https://chromium.googlesource.com/chromium/src/+/master/docs/cl_respect.md
Find an end
If you like things neat, it‘s tempting to go over a code review over and over until it’s perfect, dragging it out for longer than necessary. It‘s soul-deadening for the recipient, though. Keep in mind that “LGTM” does not mean “I vouch my immortal soul this will never fail”, but “looks good to me”. If it looks good, move on. (That doesn’t mean you shouldn‘t be thorough. It’s a judgment call.) And if there are bigger refactorings to be done, move them to a new CL.
Don't bikeshed
Always ask yourself if this decision really matters in the long run, or if you‘re enforcing a subjective preference. It feels good to be right, but only one of the two participants can win that game. If it’s not important, agree to disagree, and move on.
https://chromium.googlesource.com/chromium/src/+/master/docs/cr_respect.md
Do the pre-work
Help challenging code reviews go smoothly by reaching out to prospective reviewers before writing any code. Describing the problem and your approach ahead of time reduces surprise and provides an opportunity for early input. Ensure the decisions resulting from these exchanges, as well as the reasoning behind them, are accessible to others (e.g. via bug or design doc).
Mind your reviewer
Make choices that spare your reviewer time or cognitive load, such as preferring a series of short changes to a massive one, or uploading separate patches to isolate rebases during review.
https://chromium.googlesource.com/chromium/src/+/master/docs/cl_respect.md
Find an end
If you like things neat, it‘s tempting to go over a code review over and over until it’s perfect, dragging it out for longer than necessary. It‘s soul-deadening for the recipient, though. Keep in mind that “LGTM” does not mean “I vouch my immortal soul this will never fail”, but “looks good to me”. If it looks good, move on. (That doesn’t mean you shouldn‘t be thorough. It’s a judgment call.) And if there are bigger refactorings to be done, move them to a new CL.
Don't bikeshed
Always ask yourself if this decision really matters in the long run, or if you‘re enforcing a subjective preference. It feels good to be right, but only one of the two participants can win that game. If it’s not important, agree to disagree, and move on.
https://chromium.googlesource.com/chromium/src/+/master/docs/cr_respect.md
Armon technical logs
https://www.redhat.com/sysadmin/introduction-ed-editor
از ویم مینالی ؟ با ed اشنا شو
Armon technical logs
از ویم مینالی ؟ با ed اشنا شو
سلطان میخوای همه راز های لینوکس رو رو نکنیم 😉
Armon technical logs
سلطان میخوای همه راز های لینوکس رو رو نکنیم 😉
یکی دیگه هم دارم
دیدین روی کامند cp suid ست شده و میخواین باهاش فایلی که اونرش روته رو بخونین
Armon technical logs
https://www.youtube.com/@CodeVault/playlists
پیشنهاد میکنم پلی لیست unix Process in Cرو ببینید دید خوبی به رفتار لینوکس بهتون میده بعدشم یه کورس inter process communication این دوتارو ببینید دیگه تقریبا میتونید شبا پیش کرنل بخوابید
👍1