به نظرم آقای 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 کردم که جالب شد

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

توی این قسمت، فصل چهارم کتاب با عنوان Architecture Characteristics Defined رو بررسی می‌ کنیم، فصلی درباره ویژگی ‌هایی مثل کارایی، مقیاس‌ پذیری، دسترس‌ پذیری، امنیت و ... که موفقیت یک سیستم رو تعیین میکنه.
همچنین درباره ‌ی Trade-offهای معماری، ویژگی‌ های پنهان سیستم، و این موضوع صحبت می‌ کنیم که تلاش برای پشتیبانی از قابلیت‌ های بیش‌ از حد چگونه میتونه یک سیستم رو پیچیده و ناکارآمد بکنه.
این قسمت رو میتونید از وب‌ سایت Engineering Approach گوش بدید:

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

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

کتاب آقای Alex XU مثالای خوبی داره
- URL Shortener
- Youtube
- Twitter
- Rate limiter

و سیستم های دیگه ...

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

there is no best design in architecture, only a least worst
collection of trade-offs

- Fundamentals of Software Architecture

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

توی این قسمت، فصل پنجم کتاب با عنوان Identifying Architecture Characteristics رو بررسی می‌ کنیم، توی این قسمت درباره این صحبت میکنیم که دقیقا چطور میتونیم Architecture Characteristics های یک پروژه رو تشخیص بدیم و اینکه بتونیم به خوبی requirementهایی که stakeholder ها میدن رو ترجمه کنیم به Characteristicsهای سیستم.
این قسمت رو میتونید از وب‌ سایت Engineering Approach گوش بدید:

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

داخل این سرفصل به architectural katas اشاره شد که لینک سایتش رو اینجا میزارم:

https://www.architecturalkatas.com/

از آخرین فعالیتم ۳ هفته ای تقریبا میگذره و بابت مشغله زیاد کاری که برام پیش اومده بود
با کیفیت بالاتر برمیگردم

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

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

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

این سوال رو از خودتون بپرسید که اگه همین الان دیتای دیتابیس شما از بین بره و شما بک آپتون رو برگردونید شما چقدر از دیتارو از دست دادید؟

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

وقتی اسکیل بالایی رو داریم کمی داستان فرق میکنه

اینجا Microsoft یه مقاله داره که درباره استراتژی های معماری برای disaster recovery رو توضیح میده که پیشنهاد میکنم بخونید

https://learn.microsoft.com/en-us/azure/well-architected/reliability/disaster-recovery