به بهانه‌ی این مطلب چند تا نکته در مورد خوندن کد بگم:

۱- خوندن کد خوبه و هر کدی هم باشه کلا خوبه. مثل کتاب خوندن. از نظر من کد خوندن مثل رمان و کتاب خوندنه.

۲- با خوندن کد بیشتر و بهتر، کدهای بهتری هم خواهید نوشت. یادگیری دیزاین پترن و اصول کد تمیز خوبه ولی دیدن اینکه در عمل چه چیزی باعث خوب شدن کد می‌شه یه چیز دیگه‌ست و اگه کد بخونید از بقیه جلو می‌افتید.

۳- همونطور که وقتی الفبا رو یاد گرفتیم نمیشه انتظار داشت که آثار شکسپیر رو بخونیم، قاعدتا اگه اولین کدی که می‌خونیم کد لینوکس باشه، خیلی چیزاشو متوجه نمی‌شیم. می‌شه اول از چیز‌های ساده‌تر شروع کرد.

۴- یه سری پروژه‌ها (مثلا minix) به هدف اینکه سورس کد قابل فهمی داشته باشن نوشته می‌شن و یه سری دیگه به هدف پرفورمنس و کاربردی بودن و ... شروع کردن از اونایی که سورس کد مرتب تر و ساده‌تری دارن قطعا توصیه می‌شه. مخصوصا اگه ایده‌ی کلی از اون سیستمی که پیاده‌سازی می‌شه نداریم. مثلا اگه نمی‌دونیم سیستم‌عامل چطوری کار می‌کنه بهتره اول کتاب در موردش بخونیم. بعد یه کتاب یا منبعی که سورس‌کد رو توضیح داده بخونیم (یا همین مینیکس که سورس کد ساده و با کامنتی داره). و در نهایت می‌تونیم (شاید بتونیم) سورس کد یه سیستم‌عامل واقعی رو بخونیم.

۵- خوندن کد خیلی وقتا مثل کتاب نیست که از اول شروع کنیم تا آخر بریم، بلکه به شکل چرخیدن تو یه جنگل بزرگه. می‌چرخیم و جاهای جالبش رو نگاه می‌کنیم. مثلا همین که فایل cgroupش رو باز می‌کنیم. گاهی هم سعی می‌کنیم ساختارمندتر کار کنیم مثلا main رو باز می‌کنیم و از اونجا می‌ریم جلو. (البته اگه mainی در کار باشه!)

۶- (شاید نظر نامحبوب) خیلی وقتا نیازی نیست همه‌ی کد رو خونده باشیم یا حتی فهمیده باشیم تا بتونیم یه contributionی انجام بدیم. برای انجام یه تغییر کافیه بدونیم کلیت داستان چیه (مثلا main چطوری کار می‌کنه، قسمتی که کد من رو کال می‌کنه چطوریه و معماری و پوشه‌بندی کلی چطوریه) و تغییرمون رو در جای درستش اعمال کنیم. مثلا اگه می‌خوایم کوئری بهینه‌تری برای دیتابیس بنویسیم خیلی وقتا نیاز نیست که بدونیم تو dockerfile چه خبره یا مثلا تو http handler دقیقا چه اتفاقی می‌افته. یا در مثال لینوکسش، اگه می‌خوایم در مورد cgroup بیشتر بدونیم قاعدتا نیاز نیست در مورد درایورهای گرافیک چیز زیادی بدونیم. مخصوصا اگه معماری کد خوب باشه و الکی چیزا رو به هم متصل نکرده باشه.

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

امروز کلا بحث runC بود. از docker و containerd شروع شد. و در نهایت من کل روز رو صرف خوندن همین یک دونه فایل در کرنل کردم. cgroup. سعی کردم یه شهود کلی بگیرم. یه سری پیچیدگی‌ها رو از فهمیدنشون دست کشیدم ولی خب واقعا مفید بود. برای بار هزارم درود بر torvalds.

این مطلب به زبان ساده توضیح میده jwt چیه و چه کاربردی داره و چطوری کار می‌کنه.
https://dev.to/manav-1011/jwt-explained-19o6

دوست دارید به ویم سوییچ کنید ولی بار اول و دوم ناامید شدید؟
این دوستمون هم همینطور ولی بلاخره به cool kids club پیوست.
https://emanuelcepoi.com/preview/66785dd2d3170dd0332a47d9

در مورد طراحی code testable این مطالب خیلی جالب بود:
به کسی که از کد شما استفاده می‌کنه و میخواد کدشو تست کنه هم فکر کنید.

https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/en/thing_35

چطور به عنوان یک دولوپر، مراقب چشم‌هامون باشیم؟

https://mykola-harmash.medium.com/developer-tip-to-save-your-eyes-f83135baa64c

در مورد دستور git restore که یکی از دستورهای جدید گیت و به نوعی جایگزین برخی قابلیت های checkout و reset هست بیشتر بخونیم:
https://www.git-tower.com/learn/git/commands/git-restore

برای ثبت نام این دوره اگه خواستین با ده درصد (برای فقط ۵ نفر متاسفانه) ثبت نام کنید از این کد تخفیف استفاده کنید.
RSHQBC8

چه ایمجی برای استفاده در پروداکشن خوبه؟
آیا باید از دیسترو ها استفاده کنیم یا ایمج scratch هم جواب میده؟
https://sam.gleske.net/blog/engineering/2022/10/25/guide-to-production-docker-images.html

خیلی وقتا برای ما پیش میاد که تو یه برنچی کار میکنیم که میخوایم با main/master مرجش کنیم ولی کس دیگه‌ای اول مرج میکنه برنچشو و ما conflict می‌خوریم.
حالا وقتی میخوایم کانفلیکت‌ها رو حل کنیم می‌تونیم برنچ main رو با برنچ خودمون merge کنیم یا برنچ خودمون رو rebase کنیم به main جدید.

اینکه کدومش خوبه کدومش نه، جوابش بستگی داره‌س!
تو تیم‌هایی که جونیور زیاد دارن توصیه می‌شه مرج کنید و تموم. اینطوری تاریخچه پیچیده‌تری دارید (چون چرا یهو main تو یه برنچ مرج شده) ولی مجیک خاصی اتفاق نمی‌افته.
از طرفی rebase باعث می‌شه که یه تاریخچه شبیه‌سازی شده و جدید به وجود بیاد که توش کامیت‌های برنچ جدید شما انگار بعد از آخرین کامیت main به وجود اومدن! برای کسی که بعدا نگاه کنه فهمش راحت تره ولی نکته اینه که چنین چیزی اصلا وجود نداشته و ممکنه مشکل لاجیکی تو کد ایجاد کنه.
تو این ویدیو این بحث رو خیلی خوب در قالب یه مکالمه توضیح دادن. توصیه می‌کنم ببینید.
https://www.youtube.com/watch?v=7gEbHsHXdn0

در کنار مهندس نرم‌افزار و DevOps و SRE
خوبه بدونیم platform engineer چیه و چه کاری می‌کنه.

https://platformengineering.org/blog/what-is-platform-engineering

آیا گوشی هوشمند ما به ما گوش می‌کنه؟
احتمالا بله.
https://news.itsfoss.com/ad-company-listening-to-microphone/

(یه مقدارم عنوانش کلیخور و زرده ولی حالا ببینیدش ضرر نداره)

امروز، ۹ سپتامبر، سال‌روز تولد دنیس ریچی است.

دنیس مک‌آلیستر ریچی، دانشمند کامپیوتر آمریکایی بود که بیشتر به عنوان خالق زبان برنامه‌نویسی C و مشارکت‌های زیادش در توسعه و خلق سیستم‌عامل یونیکس به همراه کن تامسون، شناخته می‌شه. ریچی و تامسون در سال ۱۹۸۳ جایزه تورینگ که ارزشمندترین جایزه در حوزه علوم کامپیوتر هست رو به دلیل پیاده‌سازی یونیکس می‌گیرن. دنیس ریچی همچنین در سال ۱۹۹۹ مدال ملی فناوری رو توسط رییس‌جمهور وقت آمریکا، کلینتون دریافت می‌کنه. جسد ریچی در ۱۲م اکتبر ۲۰۱۱ در سن هفتادسالگی‌اش در خونه‌اش که به تنهایی در اون زندگی می‌کرد پیدا شد. هیچ‌گاه زمان دقیق مرگ دنیس مشخص نشد. اعلام فوت ریچی یک هفته بعد از مرگ استیو جابز بود اما پوشش رسانه‌ای قابل توجه‌ای در مقایسه با جابز براش ایجاد نشد. امروز ۸۳مین سال‌روز تولد دنیس هست. بدون مشارکت‌های او، احتمالاً هیچ کدوم از ما نمی‌تونستیم به شکل کنونی از کامپیوترها، نرم‌افزارهای پیچیده یا حتی اینترنت مدرن استفاده کنیم.

https://en.wikipedia.org/wiki/Dennis_Ritchie
hadi @geekalerts

روز اونایی که ایده‌های انتزاعی رو با کمک زبون‌های صوری به شکل قابل اجرا توسط اجسام بی‌جان می‌نویسن مبارک باشه.

چرا جدول اسکی خوب است؟
https://danq.me/2024/07/21/ascii/

ثبت نام هکتوبرفست شروع شده.
یادتون باشه که جا نمونید.

به طور خلاصه:
توی اکتبر، ۴ تا مشارکت کدی یا غیرکدی به ریپوهای گیت‌هاب انجام میدین (به شرطی که تگ مربوطه رو داشته باشن) و بعد براتون تیشرت می‌فرستن. کار هیجان انگیزیه.

ادیت: امسال تیشرت نمیدن انگار.

It's Hacktoberfest time! Here's everything you need to know! 🥇

https://itsfoss.com/hacktoberfest-guide/

چرا سورس کد بیشتر بد است؟

https://huly.blog/source-code-is-poison

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