در مورد مصاحبه شغلی به عنوان برنامه‌نویس، این سایت رو دوست داشتم. نظراتش رو خودمونی و دوستانه نوشته و توصیه‌های خوبی ارائه می‌ده. اگر درگیر این فضا هستید توصیه می‌کنم بخونید.
چیزی که تو فصل های اول جالب بود این بود که کار سختیه آفر گرفتن و قرار نیست با تلاش های اول به دست بیاد ولی به این معنی نیست که من ناکافی‌ام.

https://interviewguide.dev/

پسرم برنامه‌نویس سیستمی لینوکسه، پسرش:

کامند معروف sudo یه فیچر بامزه داره. قضیه از این قراره که وقتی که شما پسورد رو اشتباه می‌زنید در حالت عادی میگه try again و اینا، ولی یه فیچر داره به اسم insults که می‌تونید فعالش کنید و به این صورت می‌تونه به هر کسی که پسورد sudo رو اشتباه زد متن توهین‌آمیز نشون بده.

هدفم از این، این نیست که بگم برید روشنش کنید چون که کاربرد خاصی نداره، ولی به نظرم یه تنظیم نسبتا بی‌خطره برای بازی کردن با تنظیمات sudo.

تو این آموزش هم در مورد اهمیت کاربر root و دستور sudo و هم این فیچر بخونید و هم آموزش تغییر دادن تنظیمات sudo رو با visudo ببینید.

https://www.techtarget.com/searchsecurity/tutorial/Use-sudo-insults-to-add-spice-to-incorrect-password-attempts


شاید بپرسید متن‌های اینا از کجا میاد؟ حتما یه جا توی سیستم منه؟ ولی خب خیر به شکل متنی در اختیارتون نیست. توی یه فایل .so قرار داره. با کامند strings می‌تونید رشته‌های داخلش رو از فایل باینری استخراح کنید (که خروجی به درد بخوری نمیده البته)
https://askubuntu.com/questions/837558/where-are-sudos-insults-stored

برای کار با io توی لینوکس از سیستم کال استفاده می‌کنیم. یه دسته از این سیستم‌کال ها io_uring نام دارن که به ما امکان پروسس async رو می‌دن. خلاصه‌ش به این شکله که دو تا صف حلقوی مشترک بین user space و kernel space داریم که توی یکی درخواست های io رو می‌نویسیم و نتیجه توی یک صف دیگه قرار می‌گیره.
نکته جالب اول اینه که میتونیم چند تا درخواست رو بنویسیم و بعد به kernel بگیم همه رو پردازش کن و یه حالت batching پیش میاد.
نکته جالب دوم اینه که میتونیم به کرنل بگیم که خودت به شکل polling صف درخواست‌ها رو بررسی کن و خودت کار رو شروع کن، بدون این که حتی نیاز باشه سیستم‌کال بزنیم. البته که برای همه‌ی برنامه‌ها می‌تونه مناسب نباشه چون پردازنده رو درگیر می‌کنه.

https://unixism.net/loti/what_is_io_uring.html

توسعه فیچر، سرعت رشد رو برای فیچر های آینده میگیره. این طبیعیه؟ بله. مطلوبه؟ قاعدتا نه.

پس چیکار کنیم؟ گاهی باید برگردیم عقب و ساختار کد رو درست کنیم.

https://tidyfirst.substack.com/p/why-does-development-slow

چرا در git، عملیات squash کردن بد است
و کمی در مورد نحوه کار git

https://dev.to/wesen/squash-commits-considered-harmful-ob1

چرا فیچرفلگ ها بد هستند و باید باهاشون چیکار کنیم؟

https://newsletter.manager.dev/p/feature-flags-are-ruining-your-codebase

این قسمت درس شبکه معمولا تو امتحان نمیاد، ولی شما اگه دوست داشتید بخونید
https://digiato.com/internet-network/from-ixp-to-bgp-internet-cuts

مستند "پریدن از روی دیوار آتش"

https://www.aparat.com/v/8s6Yy/

یکی از بهترین مطالبی که خوندم:
چطور کد جدید رو ببریم روی پروداکشن؟ چقدر تست کنیم؟ محیط تست داشته باشیم؟ برای همه کاربرها فعال کنیم یا برای تعداد کمی؟
اگه تجربه پروداکشن نداشتید یا فقط تو شرکت های سایز مشخص کار کردید (یا فقط کوچک یا فقط بزرگ) بهتون توصیه میکنم بخونید.

دیپلوی در چهارشنبه (روز آخر هفته) مجاز باشه یا نه؟
این مطلب چیزهای خوبی میگه در این که کی خوبه مجاز باشه و کی نباشه و در نهایت تصمیم با خود تیمه.

یه نکته و طرز فکری که داشت و من دوست داشتم این بود که دیپلوی فریز نشون میده ما پذیرفتیم که باگ هایی هست که ما نمی‌تونیم در زمان تست پیدا کنیم و می‌ره رو پروداکشن، و به جای حل مشکل، سعی میکنیم بهش چسب زخم بزنیم تا اثر منفیش رو کم کنیم.

https://charity.wtf/2025/12/24/on-friday-deploys-sometimes-that-puppy-needs-murdering-xpost/


و در ادامه این مطلب:
https://www.linkedin.com/posts/michael-davis-7033548_friday-deploy-freezes-are-exactly-like-murdering-activity-7408181339444707328-8GjS

چه زمانی ریفکتور کنیم و چه زمانی بازنویسی کامل؟با یکسری مثال و ایده این مطلب بهتون کمک می‌کنه.

https://herbcaudill.com/words/20190219-rewrite-refactor-reinvent