شاید خبرش به گوشتون رسیده باشه که سیستم‌های مبتنی بر ویندوز و آژور در سراسر جهان، دیروز ترکیدن و کار و زندگی مردم فلج شده.
به عنوان کسی که این ترکیدن رو لایو تجربه کرد (داشتم روی یه تیکت تو پرتال شرکت کامنت می‌ذاشتم. بعد از سیو، کل سامانه غیب شد. 😬) بیاین با مفهومی به اسم SLA آشناتون کنم.

فرض کنین که شما از یک سرویس‌دهنده سرویسی رو دریافت می‌کنین. این سرویس‌دهنده باید به شما برای محصولش تضمین کیفیت بده. تو دنیای کامپیوتر و نرم‌افزار، یکی از معیار‌های کیفیت، در دسترس بودنِ سرویسه. این که اون سرویس قطع و از دسترس خارج نشه. شما نری یه وب‌سایت بخری، بعد مشتریت نتونه بازش کنه.

مثلا شما به مایکروسافت می‌گید یک ترابایت حافظه ابری می‌خوام که عکسای عروسیمو بریزم روش. مایکروسافت به شما می‌گه این عکس‌ها ۹۹ درصد مواقع در دسترس هستن. یعنی شما ۹۹ درصد مواقع اگر تلاش کنین عکسا رو باز کنین، باز می‌شن. اون ۱ درصد رو می‌ذارن تا برای مشکلات احتمالی دست خودشونو باز بذارن. اگر برقی رفت، هکی اتفاق افتاد، سروری سوخت، کسی نتونه بیاد یقه‌شونو بگیره که چرا سرویسی که به من فروختی خرابه.

این توافق بین شما و مایکروسافت اسمش می‌شه Service Level Agreement یا SLA. یعنی شما با مایکروسافت توافق کردین که سرویسی که ازش می‌گیرین چند درصد مواقع قطعا سالمه. برای مصارف شخصی شاید ۹۹ درصد خیلی عدد خوبی به نظر بیاد، ولی این عدد یعنی توی یک سال جمعا حدود ۳ روز ممکنه سیستم بهتون ارائه نشه. پس برای بیزنس‌هایی که مشتری دارن ۹۹ هم به اندازه کافی خوب نیست. ممکنه نیاز داشته باشن سرویسشون در سال فقط یک ساعت داون باشه، و براش ۹۹.۹۹ درصد تضمین بگیرن. یا درخواست کنن که بیش‌تر از ۵ دقیقه در سال سیستم خراب نباشه، و تضمین ۹۹.۹۹۹ بگیرن.

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

اگر بی‌کارین، می‌تونین توی سایت uptime.is هی درصد وارد کنین، ببینین با هر درصد چند ساعت در روز سیستمتون داون خواهد بود. 😁

درسته کدک h265 یا HEVE خیلی بهمون کمک میکنه حجم ویدیوهای با کیفیت کمتر بشه، اما یه کدک دیگه هم هست که نسبتا جدید تره و compression بسیار بهتری داره. اونم av1 هست که پارسال شرکت متا برای استوری های اینستاگرام ازش استفاده کرد.
یه نکته خیلی جالب اینه که چون encode کردن ویدیو ها با این کدک منابع بیشتری نیاز داره و زمانبر تر هست، یوتیوب فقط برای ویدیو هایی که در مدت زمان کم وایرال میشن ازین کدک استفاده میکنه.
جزییات بیشتر این کدک رو اینجا میتونید ببینید
https://www.youtube.com/watch?v=BMAccTJBDjE

من از این سایت/پروژه khoj خیلی خوشم اومد. یه پروژه‌اس که رابط وب و واتساپ و ... داره و امکان این رو می‌ده که با agentهای مختلف هوش مصنوعی‌ش ارتباط برقرار کنید، فایل اپلود کنید و بگید بر اساس اون (و نوتهای obsidianتون) و ... بهتون جواب بده.
نکته مهمش اینه که می‌تونید self hostش کنید و لوکال بهش بگید که از ollama استفاده کن یا api chatgpt
رابط کاربری نسبتا خوبی داره و نسخه رایگانش که خودشون هاست کردن هم به خوبی کار می‌کنه ولی محدودیت تعداد پیام داره قاعدتا.

https://github.com/khoj-ai/khoj

نکته: رابط کابریش بهترین نیست ولی اینکه اینقدر امکانات داره و باگ‌هاشم مانع استفاده ازش نمیشه و قابل استفاده و open source و eslf hostئه باعث می‌شه مشکلات رابط کاربریش به چشم نیاد.

دوست دارید با گیت پوش، کدتون رو روی سرورتون دیپلوی کنید؟
ابزارهای مختلفی برای اینکار هستن که یکی از کوچک ترین هاش پیکو هست:
https://github.com/piku/piku

اگه دوست دارید در مورد کرنل لینوکس و زمان بندها و pidها بیشتر بدونید این مطلب رو توصیه میکنم:
چه پروسسی در کرنل، pid 0 داره؟
https://blog.dave.tf/post/linux-pid0/

یه مطلب خوب در مورد معرفی وب اسمبلی
https://vrgl.ir/g268k

توضیح بسیار خوب و روونی داره و مدل ذهنی خوبی ایجاد میکنه

یکی هم مقاله فیگما راجع به همین موضوع رو کامنت کرده بود که به نظر جالب میاد

https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/

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

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

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

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

۴- یه سری پروژه‌ها (مثلا 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/

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