امروز توی صف خرید نون بربری بودم. دو بار تنور کامل پخت، اما هنوز نوبت من نشده بود. در حالی که من کلا یک دونه نون بیشتر نمیخواستم.

همونجا توی صف داشتم به این فکر میکردم که آیا میشه این سیستم رو طوری Optimize کرد که آدم ‌ها در کمترین زمان ممکن نونشون رو بگیرن و برن.

اول بیاید ببینیم سیستم فعلی چطوری کار میکنه.

معمولا یه نفر مسئول آماده کردن خمیرهاست. بعد خمیر میرسه دست شاطر، شاطر خمیر رو شکل میده و آماده میکنه که بره داخل تنور. بعد از پخت هم نون ‌ها از تنور خارج میشن و در نهایت به مشتری ‌ها فروخته میشن.

اگه بخوایم خیلی ساده بهش نگاه کنیم، سیستم چیزی شبیه اینه:

مشتری → فروشنده → تنور → شاطر → خمیرساز

خب حالا سوال اصلی اینه که اصلا هدفمون از این بهینه ‌سازی چیه؟

هدف اینه که مدت زمانی که مشتری توی صف منتظر میمونه رو تا جای ممکن کم کنیم.

برای اینکه بتونیم هر سیستمی رو Optimize کنیم، اول باید Bottleneck اون سیستم رو پیدا کنیم. یعنی بخشی که سرعت کل سیستم رو محدود میکنه.

توی نونوایی چند تا بخش میتونن Bottleneck باشن:

- آماده‌سازی خمیر
- شکل دادن خمیر توسط شاطر
- قرار دادن خمیر داخل تنور
- خارج کردن نون از تنور
- فروش و تحویل نون

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

چرا؟

چون شاطر عملا چند تا کار مختلف رو همزمان انجام میده:

- آماده کردن خمیر
- قرار دادن خمیر داخل تنور
- خارج کردن نون ‌های آماده

یعنی مدام بین چند وظیفه مختلف در حال جا به ‌جاییه.

اینجا به نظرم میشه سیستم رو یه مقدار بهتر کرد.

به جای اینکه یک شاطر همه این کارها رو انجام بده، میشه وظایف رو بین دو نفر تقسیم کرد.

شاطر اول فقط مسئول آماده‌سازی خمیر باشه:

- گرفتن خمیر
- شکل دادن خمیر
- آماده کردنش برای ورود به تنور

شاطر دوم فقط مسئول تنور باشه:

- خارج کردن نون ‌های آماده
- جایگزین کردن فوری خمیرهای جدید
- مطمئن شدن از اینکه ظرفیت تنور هیچ ‌وقت خالی نمونه

مزیت این کار اینه که هر نفر روی یک وظیفه مشخص تمرکز میکنه و هزینه جابه‌جا شدن بین کارهای مختلف کمتر میشه.

ضمن اینکه تنور هم همیشه نزدیک به حداکثر ظرفیت خودش کار میکنه.

اما حتی اگه این بخش رو هم بهینه کنیم، هنوز یه مسئله دیگه وجود داره.

نحوه توزیع نون بین مشتری ‌ها.

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

بنابراین مسئله اصلی تفکیک صف ‌ها نیست.

مسئله اینه که نون ‌های آماده شده با چه نسبتی بین این صف ‌ها توزیع بشن.

فرض کنید همیشه اولویت با سفارش ‌های بزرگ باشه.

در این حالت ممکنه کسی که فقط یک نون میخواد مدت زیادی منتظر بمونه.

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

به نظرم راه بهتر اینه که یک سیاست توزیع متعادل داشته باشیم.

مثلا:

- دو نفر از صف تک ‌نان
- یک نفر از صف چندتایی

و این روند به صورت متناوب تکرار بشه.

البته این عدد احتمالا نباید ثابت باشه.

بهتره داده جمع بشه و بعد براساس رفتار واقعی مشتری ‌ها تنظیم بشه.

مثلا بشه فهمید:

- هر مشتری در صف چندتایی به طور میانگین چند نون میگیره
- زمان انتظار هر صف چقدره
- در ساعات مختلف روز الگوی خرید مردم چطوریه

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

ممکنه در نهایت مشخص بشه نسبت ۲ به ۱ بهترین انتخاب نیست و مثلا ۳ به ۱ یا حتی یک نسبت کاملاً متفاوت نتیجه بهتری بده.

نکته مهم اینجاست که هدف این نیست که همه مشتری ‌ها دقیقا در یک زمان نون بگیرن. هدف اینه که میانگین زمان انتظار مشتری ‌ها تا جای ممکن کم بشه و ظرفیت سیستم هم به بهترین شکل استفاده بشه.

به نظرم اگه بخوایم فقط روی دو تغییر تمرکز کنیم، بیشترین تاثیر رو این دو مورد دارن:

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

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

ولی از روی چیزی که من توی نونوایی دیدم، به نظر میرسه بخش قابل توجهی از تاخیرها از مدیریت تنور و نحوه توزیع نون بین مشتری‌ها ایجاد میشه.

حواسمون به tradeoffها هم باشه
اضافه کردن شاطر جدید ینی هزینه جدید در سیستم
اما آوردش میتونه این باشه که مشتری های بیشتری رو هم میتونیم پردازش بکنیم

به اشتباه گفته میشه استمرار به معنی ادامه دادنه
بلکه استمرار ینی هنر برگشتن به مسیر

قسمت سوم پادکست Fundamentals Of Software Architecture منتشر شد.

وقتی اسم Software Architecture میاد، معمولا ذهن ما میره سمت نمودارها، الگوهای معماری یا انتخاب بین Monolith و Microservices. اما هر چقدر بیشتر در این حوزه مطالعه می‌کنیم بیشتر متوجه میشیم که معماری خیلی فراتر از اینهاست.
توی این قسمت از پادکست، قسمت آخر فصل اول از کتاب Fundamentals of Software Architecture رو مرور می‌کنیم، جایی که کتاب درباره نقطه تلاقی معماری با DevOps، Agile، Engineering Practices و حتی فرهنگ و ساختار تیم‌ها صحبت میکنه.
یکی از نکات جالب این بخش برای من این بود که بسیاری از قابلیت‌ هایی که امروز بدیهی به نظر میرسن، مثل Elastic Scaling، نتیجه سال ها تجربه، شکست و یادگیری در صنعت نرم‌افزار هستش. همچنین درباره این صحبت می کنیم که چرا هیچ تصمیم معماری «کاملا درست» وجود نداره و تقریبا همه چیز در معماری یک Trade-off هستش.

این پادکست رو میتونید از وب سایت Engineering Approach گوش بدید:

https://engineeringapproach.ir/podcasts/fundamentals-of-software-architecture

Mimo رو برای کد نویسی امتحان بکنید
جالب بوده تا اینجا که باهاش کار کردم
عکسی که گذاشتم در مقایسه با sonnet 4.6 هستش

لینک ریپازیتوری برای نصب:

https://github.com/XiaomiMiMo/MiMo-Code

کتابخوان چیزیه که من همیشه همراه خودم دارم، تقریبا روزی یک ساعتی من تو مترو هستم، ایشون برای تایمی که تو مترو هستم خیلی کمک میکنه بتونم این تایم رفتو آمد رو درست استفاده بکنم

هر از گاهی از خودم این سوال رو میپرسم

من میخوام کی بشم؟

به نظرم خیلی سوال مهمیه، چون تعیین میکنه دقیقا زمانمون رو چطوری بگذرونیم. چرا اینو میگم؟

در طول روز حواستون به اون یکی دو ساعت خالی که دارید باشه. خودتون رو monitor بکنید و ببینید اون یکی دو ساعت رو چطوری استفاده میکنید. مثلا میدونم یه سری ها چون نمیدونن چیکار بکنن میرن سراغ کارهایی که مربوط به شرکتی هستش که درش کار میکنن و شروع به انجام اونا میکنن

مثلا همین الان به خودتون یک ساعت وقت بدید. توی این یک ساعت چه کاری انجام میدید؟ آیا کاری که انجام میدید در راستای چیزی هست که قراره بهش تبدیل بشید؟

برای مثال یکی از دوستان من که میخواد یکی از contributor های Linux Kernel بشه، وقتی یک ساعت وقت خالی داره نمیشینه یه فریم ورک جدید یاد بگیره. میدونه که باید بره کدهای Kernel رو بخونه، روی مفاهیم سیستم عامل عمیق تر بشه و توی پروژه های Open Source مشارکت کنه. چون مقصدش مشخصه، میدونه اون یک ساعت رو دقیقا کجا سرمایه گذاری کنه.

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

قسمت چهارم پادکست Fundamentals Of Software Architecture منتشر شد.

توی این قسمت درباره ی Architectural Thinking یا تفکر معماری که مربوط به فصل دوم هستش صحبت میکنیم که کتاب به چهار مورد اشاره میکنه که شامل موارد زیر هستش:

- Architecture Vs Design
- Technical Breadth
- Analyzing Trade-Offs
- Understanding business drivers

از مهم تریناش از نظر خودم Analyzing Trade-Offs هستش که با مثال جالبی از کتاب بررسیش میکنیم

این پادکست رو میتونید از وب سایت Engineering Approach گوش بدید:

https://engineeringapproach.ir/podcasts/fundamentals-of-software-architecture

من فایل صوتی رو هم اینجا قرار میدم واسه عزیزانی که از خارج از کشور به من گفتن که سایت براشون باز نمیشه.
دنبال راه اندازی castbox هم هستم، انجام شد اطلاع میدم

توی این مدت خیلی روزای شلوغی رو گذروندم و اصلا فرصتی نداشتم بتونم فعالیتی داشته باشم ولی الان stable شدم، دوباره محتوا رو شروع میکنیم

از ایلان ماسک پرسیدن که فکر میکنید بدترین اختراع بشر چی بوده؟

میگه: short videos

همین ویدیوهای کوتاه چند ثانیه ای که پلتفرم هایی مثل instagram, tiktok و ... دارن

به نظرم آقای Andrew Huberman نکات جالبی رو راجب این موارد میگه که پیشنهاد میکنم ببینید:

https://www.youtube.com/watch?v=UKF9ChjZuSw

چیزی که این تصویر نشون میده از دو الگوریتم load balancing هستش:
سمت چپ، الگوریتم Least Connection تقریبا تعداد برابری اتصال به هر سه سرور میده. نتیجه؟ دو تا سرور کوچیک خیلی زود پر میشن، ولی سرور بزرگ هنوز حدود دو سوم ظرفیتش خالیه. یعنی یکی از سرور های شما که قدرت بیشتری داره بخش زیادی از توانش اصلا استفاده نمیشه.
سمت راست، Weighted Least Connection بار رو جوری تقسیم میکنه که هر سه سرور تقریبا به یک اندازه درگیر باشن، چون سرور بزرگ قدرت بیشتری داره، طبیعیه که حدود سه برابر بار بیشتری هم بگیره.
به این شکل سرورهای کوچیک فشار زیادی رو تحمل نمیکنن و همینطور سرور بزرگ الکی بیکار نمیمونه.
توی Weighted Least Connection فقط یه فرمول داریم و کل تصمیم‌گیری بر اساس همونه:
Score = Open Connections / Weight
بعد درخواست جدید به سروری فرستاده می‌شه که کمترین Score رو داشته باشه.
Server A
- Weight: 1
- Open Connections: 4
- Score = 4 ÷ 1 = 4.0

Server B
- Weight: 1
- Open Connections: 5
- Score = 5 ÷ 1 = 5.0

Server C ✅
- Weight: 3
- Open Connections: 9
- Score = 9 ÷ 3 = 3.0

Winner: Server C (lowest score)

در نگاه اول شاید عجیب باشه که C با ۹ تا Connection انتخاب می‌شه، ولی دلیلش اینه که وزنش ۳ هست؛ یعنی این سرور نسبت به بقیه ظرفیت بیشتری داره. پس وقتی تعداد Connectionها رو بر وزن تقسیم می‌کنیم، می‌بینیم که فشار واقعی روی C کمتر از بقیه است.

قسمت جدید پادکست راجب Modularity هستش، کتاب میگه همه درباره خوبی های ماژولار بودن صحبت میکنن اما کمتر کسی درباره این صحبت میکنه که چطوری میتونیم به ماژولاریتی دست پیدا کنیم که بخش مهمیه و میتونه دشوار هم باشه

تعریف ماژولاریتی هم از اون تعریف هاییه که هر کی برای خودش یه تعریفی داره و سخته یه چیز واحد پیدا کردن، که کتاب اینجا تعریف خودش رو هم میده که بهش توی پادکست اشاره میکنم

قسمت جدید رو دارم تموم میکنم به زودی منتشر میکنم

اینا موضوعات مربوط به AI هستش، شما چندتاشو بلدید:

- Harness
- Temperature
- Embedding
- Prompt Injection
- Zero Shot
- Logits
- Softmax
- Beam search

قسمت پنجم پادکست Fundamentals Of Software Architecture منتشر شد.

توی این قسمت درباره ی Modularity که مربوط به فصل سوم هستش صحبت میکنیم که کتاب توضیح میده ماژولاریتی چی هست و ما چه متریک هایی داریم تا بتونم به ماژولاریتی دست پیدا کنیم، سه تا از متریک هایی که کتاب بهش اشاره میکنه رو بررسی کنیم:

- Cohesion
- Coupling
- Connascence

این پادکست رو میتونید از وب سایت Engineering Approach گوش بدید:

https://engineeringapproach.ir/podcasts/fundamentals-of-software-architecture

چند دقیقه آخر این قسمت رو به خاطر محدودیت هایی که روی اکانتم داشتم نتونستم کامل منتشر کنم
پیشاپیش عذرخواهی میکنم

خوشحال میشم نقد و پیشنهادی برای بهبود دارید بهم پیام بدید

@MrAmirSalehi

چند سال پیش یکی از دوستام گفتش که وقتی وارد دنیای software میشی باید بپذیری همیشه یه حس ناکافی بودن باهات هست

هر چقدر میخونی، یادمیگیری و تجربه کسب میکنی باز کمه

اینو برای گولنگ generate کردم که جالب شد