خب. راجب Neetcode System Design Interview:

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

همه مصاحبه های سیستم دیزاین شامل چهار بخش میشن.

Background
پیش زمینه های مورد نیاز راجب سیستم رو توضیح میدید. اینکه چی هست، چه چیزی به کاربران ارائه میده.
البته تو ویدیو های NeetCode این بخش با Non-Functional Requirements ممکنه کمی قاطی بشه.

Functional Requirements
سیستمی که میخوایم طراحی کنیم چطور کار میکنه. فیچر هایی که سیستممون باید داشته باشه.
مثلا تو مثال توییتر مثل news feed یا like یا dislike. هر چیزی که مرتبط با کاربر هست.

Non-Functional Requirements
هر چیزی که Functional Requirements نیست. ولی خب دقیق تر بخوام بگم.
هر چیزی که مربوط به scalability هست. مثلا چقدر سرویس ما یوزر خواهد داشت. هم تو لانچ و همینطور در آینده (باید آینده نگر باشیم تا اگر نیاز شد مقیاس سیستم ما بالاتر بره بدون مشکل ارتقا رو انجام بدیم).
دیتابیس ما چقدر read یا write انجام میده و نسبتشون چقدره؟
چقدر فضای ذخیره سازی نیاز داریم؟ چقدر availability (دسترسی پذیری) میخوایم؟
سرویسمون چقدر تاخیرش باید پایین باشه.
نکته: معمولا تو محاسبات تخمین زده میشه. بنابراین لازم نیست دقیق بدست بیارید.

High Level Design
طولانی ترین بخش مصاحبه این بخش هست.
تو این بخش تمام اطلاعات قبل رو به کار میبندید تا یک دیزاین مناسب این سیستم ارائه بدید.
یادتون باشه که مصاحبه گر دنبال پاسخ خاصی نیست.
مصاحبه گر میخواد بدونه که شما توانایی تحلیل یک سیستم رو دارید؟

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

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

همینطور انتخاب دیتابیس هم مهم هست. SQL باشه یا NoSQL. حتی NoSQL ها هم با هم متفاوت ان. مثلا Cassandra دیتابیسی مخصوص سرعت write بالا هست (از اونجایی که از LSM-Tree و SSTables استفاده میکنه).

تو مصاحبه میتونید راجب تفاوت های ظریف هم صحبت کنید. مثلا میتونیم از فلان چیز استفاده کنیم و سیستم رو سریع میکنه ولی موجب مشکلات دیگه میشه. گفتن اینا مصاحبه کننده رو آگاه میکنه که میتونید گزینه ها رو سبک و سنگین کنید و مزیت و عیب های هر روش رو تشخیص بدید که خیلی اهمیت داره.

همینطور از بخش Caching قافل نشید. یک سری سیستم ها حتما نیاز به Cache دارن که تا بتونن تجربه کاربران رو بهتر کنن و تاخیر متوسط رو پایین بیارن. جدا از اون این بخش خیلی کیف میده و مطمئنم مصاحبه گر ها هم کیف میکنن.

تو مثال هایی هم استفاده از WebSocket خیلی سرعت رو بالا میبره و تاخیر رو پایین میاره.
تو دیسکورد مثلا از WebSocket برای ارسال پیام و نوتیفیکیشن هاش استفاده میکنه.

یادتون باشه شما Domain Expert نیستید تو همه اینا.
قطعا از شما نمیخوان که از جزییات همه این بخش ها سر دربیارید.
شما فقط دارید سیستم طراحی میکنید.

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

1. How to Approach:
تو ویدیو اولش راجب اینکه چطوری مصاحبه های سیستم دیزاین رو هندل باید بکنید صحبت میشه.
تو پست قبلی راجب این موضوع هم خودم صحبت کردم.

2. Design a Rate Limiter:
راجب دیزاین یک Rate Limiter صحبت میشه. در واقع Rate Limiter ای که دیزاین میشه جنریک هست. یعنی برای هر سیستمی با هر مقیاسی در نظر گرفته میشه.
و اینکه بله. Rate Limiter میتونه یه سیستم با چندین کامپیوتر باشه. برای منم جالب بود.

یک جایی Rule ها ذخیره میشن (دیتابیس). یک بخشی هم Memory Store (Cache) باشه.

همینطور الگوریتم های مختلفی که یک Rate Limiter میتونه داشته باشه مثل Fixed Window یا Sliding Window.

3. Design TinyUrl:
در نگاه اول فکر میکنید که دیزاین این موضوع خیلی خنده دار و ساده هست.
اما کامل در اشتباهید. وقتی که scale بالا بره هر چیز ساده ای تبدیل به چالش میشه ;)
تو این سرویس read به شدت بالا هست و سر همین دیتابیس کاملا درگیره. سر همین باید لینک هایی که آزاد برای استفاده هست رو یک جای دیگه ذخیره کنید و ...
تازه یه worker هم باید برای حذف لینک های منقضی شده هم باید گذاشت.

4. Design Twitter:
بخش Feed هر کسی میتونه با یه سرویس Message Queue ساخته شه که شامل Cluster هایی هستن که feed ما رو جنریت میکنن و داخل یه Cache بزرگ ذخیره میکنن.

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

جدا از اون دیتابیس توییتر جای NoSQL میتونه GraphDB باشه. البته که من شخصا راجب محدودیت های GraphDB اطلاعات ندارم ولی خب آپشنی هست که میتونه بررسی بشه.

5. Design Discord:
اینجاست که WebSocket میدرخشه و اینکه اونقدر نسبت write به read بالاست که حتی دیتابیس های NoSQL معمول هم جواب نمیدن.
باید سمت دیتابیس های مخصوص write بالا رفت. مثل Cassandra یا حتی ScyllaDB که سال پیش روی اون سویچ کردن.

البته که دیسکورد قبل از اینکه روی Cassandra سویچ کنه از MongoDB استفاده میکرد. بنابراین همون اول هم نیاز نیست مقیاس عظیم بسازید. اول زنده بمونید و راه رو برای مقیاس های بزرگ تر باز بزارید.

6. Design YouTube:
قاعدتا یوتیوب نیاز به Object Storage داره. در غیر اینصورت چطور میخواد این همه ویدیو سنگین رو ذخیره کنه؟
جدا از اون نیاز به یه لشکر worker عظیم و Message Queue داره که ویدیو ها رو انکود کنه و باز داخل Object Storage ذخیره کنه. و خود ویدیو های هم روی CDN باید باشن که دسترسی بهشون خیلی سریع باشه.

تو این سیستم از WebSocket استفاده نکردن و صرفا ویدیو ها رو قطعه قطعه میفرستن.

و راجب دیتابیس هم واقعا از NoSQL استفاده نمیکنن. بلکه از MySQL استفاده میکنن و شاید بپرسید چطور؟ با اون دیتای عظیمی که دارن دیتابیس رو چطوری shard میکنن؟
با استفاده از ابزار خودشون. و قبل از این هم منطق sharding رو روی بخش کد های سرورشون پیاده میکردن.

7. Design Google Drive
دو حالت واسه دیزاینمون داریم. یکیش Distributed File System و دیگری Object Storage.
با Distributed File System دیزاین خیلی پیچیده تر میشه و به اندازه Object Storage مقایس پذیری نداره.
ولی خب تو این آموزش چون بخش ادیت در نظر گرفته نشده سراغ Distributed File System نمیره. ولی خب خواستید بررسی کنید ابزار هایی مثل Apache Hadoop هست.
جدا از اون اگر بخوایم با Object Storage بریم باید دیتا رو بلوک بندی کنیم و همین به ما اجازه deduplication میده. یعنی میتونیم فایل های تکراری یا بخش های تکراری رو فقط یک بار ذخیره کنیم.
واسه حذف هم یه سرویس Garbage Collection میتونیم بزاریم که یه بار میگرده و بخش هایی که استفاده نمیشن رو حذف میکنه.

8. Google Maps:
اینجا متوجه میشید که چقدر domain knowledge مهم هست تو دیزاین سیستم ها.
الگوریتم های مسیریابی، نحوه ذخیره سازی نقشه ها. اطلاعاتی مرتبط با نقشه و ...
سرویس مسیریابی و مکان یابی جدا ان و بخش مکان یابی میتونه برای ارائه گزارشی از ترافیک های محل از یه Message Queue استفاده کنه و پردازش رو روی دیتا های محل کاربران انجام بده و داخل دیتابیسی به اسم ترافیک ذخیره کنه.

9. Design a Key-Value Store:
اینجا قشنگ با مفاهیم پیچیده بمبارون میشید.
به قولی ادامه مباحث NoSQL تو آموزش قبلی هست ولی در فرمت مصاحبه.

10. Distributed Message Queue:
یه Message Queue ساده که روی یک کامپیوتر پیاده میشه بلاخره محدودیت هایی داره.
ولی بیشتر وقتی معماری رو توزیع شده بسازیم میتونیم محدودیت ها رو دور بزنیم.

بخش Discussion اضافه شد.
Have fun ;) and behave

سلام دوستان.
چند وقت پیش میخواستم راجب OOP و Design Pattern و کلاً معایب و مزایای OOP پست بزارم.
ولی خب گفتم که شاید دوستان با مفاهیم درگیر و پیرامون OOP آشنایی کامل نداشته باشن.

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

از طرفی هم نمیتونم بگم که تجربه زیادی دارم حتی با وجود اینکه با Qt یا PySide6 و لایبرری های کاملا OOP محور کار کردم باز فکر میکنم خیلی جا برای یادگیری دارم.

سر همین تو پست بعدی اول به مفاهیم مهم دنیای OOP میپردازم مثل SOLID و همینطور OOP Design Pattern هایی که تو آموزش neetcode یاد گرفتم رو مختصرانه توضیح میدم و سپس نقد رو انجام میدم.

و حال در این مدت چه گذشت.

یادتون بود راجب آموزش PyTorch صحبت کرده بودم که استارتش رو زدم. تقریباً تا ½ اش رو تموم کردم. نزدیک 340 قسمت هست ولی خب بخوام نظرم رو راجب این دوره بگم. اگر میخواید سمت یادگیری عمیق برید. صد در صد اینو پیشنهاد میکنم.

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

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

جدا از اون یک آموزش گیت هم دیدم. از SuperSimpleDev.
نه اینکه گیت بلد نبودم (هر روز rebase و reflog انجام میدم از بس که خرابکاری میکنم و درست میکنم) ولی خب میخواستم که یه مروری بر مفاهیم اولیه بشه و از اونجایی که تو ویدیو سومش به feature branch workflow اشاره میشه سر همین گفتم حتماً ببینمش.

خیلیا git رو یاد میگیرن و ذهنیت گیت ندارن. همش داخل یه برنچ کامیت میکنن و نمیدونن چه وقتی باید برنچ بزنن.
همینطور رفع conflict های PR به صورت لوکال رو هم بخش خیلی جالبی بود که نمیدونستم ممکنه.
اگر گیت بلد نیستید این بهترین آموزش برای شروع هست.

خلاصه از git غفلت نکنید.

آموزش PyTorch تو کانال پین شده هست

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

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

سر همین قواعدی به وجود اومد به اسم SOLID که کد های OOP باید رعایت کنند. و این قواعد تو بیشتر کد های OOP که امروزه میبینیم جا افتاده.

اسم SOLID کوتاه شده 5 قانون هست که به ترتیب:

1. Single Responsibility Principle
2. Open-Closed Principle
3. Liskov Substitution Principle
4. Interface Segregation Principle
5. Dependency Inversion Principle

Uncle Bob’s SOLID Principles Made Easy 🍀 - In Python!

The SOLID Principles of Object-Oriented Programming Explained in Plain English

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

#OOP
#SOLID

1. Single Responsibility Principle:

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

چرا اینکارو انجام میدیم؟ اولین فایده‌اش اینه که کدبیسمون ماژولار تر و تمیز تر میشه و امکان تغییر بدون خرابکاری کمتر میشه. که برای یک تیم خیلی مهمه.

دوم اینکه تو سیستم کنترل نسخه مثل گیت راحت‌تر میشه تغییرات رو بررسی کرد. مثلاً میخواید git blame بزنید گیج نمیشید چون که این بخش از برنامه فقط برای یک دلیل و فقط توسط یک نفر تغییر کرده.

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

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

#OOP
#SOLID

2. Open-Closed Principle:
اینجاست که abstract class و interface ها معنی پیدا میکنن.
اگر بخوام این دو رو تو یک کلمه خلاصه کنم: قرارداد. (بله فقط مسائل حقوقی رو کم داشتیم که تو برنامه نویسی اضافه شد)

این قانون برای این به وجود اومده که اجازه بده که بدون اینکه کد قدیمیتون رو تغییر بدید برنامتون رو توسعه بدید.
اینطوری احتمال اینکه به باگ بخورید کمتره. به عبارتی Open برای اضافه کردن و Closed برای دستکاری کردن.

بعضی وقتا میبینید که نوع های مختلفی از کلاس دارید که رفتار مشابه دارن ولی تو جزییات تفاوت دارن. تو بخش‌هایی از برنامه هم میتونن جای هم استفاده بشن.
اینجاست که از abstract class یا interface استفاده میکنید تا رفتار های مشترک رو به عنوان یک قرار دادی بسازید که تمام کلاس‌های فرزند ازش پیروی میکنن.

اینطوری اگر خواستید که جایی از هر کدوم از کلاسا به عنوان ورودی استفاده کنید میتونید از کلاس قرارداد (abstract class) یا interface استفاده کنید.

فرق این دو هم تو اینه که abstract class مثل یک کلاس میمونه که میتونی متد های قراردادی که باید پیاده بشن رو بنویسی، همینطور میتونی متد های معمولی هم همراه تعریف داشته باشی که ازش تو کلاس‌های فرزند استفاده بشه.

اما تو interface متد ها بدون تعریف هستن و باید توسط فرزند پیاده‌سازی بشن.
تو هر زبانی ممکنه اسم مفاهیم ها یکم متفاوت باشن. مثلاً تو پایتون یا سی پلاس پلاس interface نداریم.
اما مفاهیم مشابه مثل virtual methods تو ++C و ABC (abstract base classes) و Protocols تو پایتون هستن که برای همین کار ساخته شدن.

#OOP
#SOLID

3. Liskov Substitution Principle:
هر کلاس فرزندی باید بتونه جایگزین کلاس والد بشه و مشکلی برای برنامه پیش نیاد.
این قانون گیج کنندست. و ایرادات اینطوری رو تو کد ها به وضوح نمیشه پیدا کرد.

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

#OOP
#SOLID

4. Interface Segregation Principle:
بعضی وقتا یه interface یا abstract class کافی نیست.
چون وقتی که interface یا class ات بزرگ و کلی باشه تو کلاس‌های خاص ممکنه متد هایی رو پیاده کنی که اصن برای اون کلاس نیستن.
سر همین بهتره که سلسله ای interface یا abstract class بسازی که کارو ساده‌تر میکنه.

#OOP
#SOLID

5. Dependency Inversion Principle:
کل قاعده Open-Closed برای این بود که بتونیم از کلاس‌های جدید که از کلاس‌های فعلی جدا هستن استفاده کنیم تا برنامه رو بدون تغییر کد قبلی توسعه بدیم.
اما اگر بخوایم اینکارو انجام بدیم باید متد های ما جای اینکه یک کلاس خاصی رو قبول کنن کلاس‌ قرارداد رو قبول میکنن که تضمین میشه کلاس های ورودی حاوی متد های مشخص شده هستن.

اینجا بود که گفتم Liskov Substitution Principle مهمه.
چون آبجکت هایی که قرارداد رو میپذیرن ممکنه که هر جایی که اون کلاس قراردادی رو بپذیره استفاده بشن.
سر همین می‌بینی که این کلاسه یه جا کار میکنه و جای دیگه درست کار نمیکنه.

#OOP
#SOLID

منابع تورنت مشکلات کپی رایت دارن.

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

Tensorflow Playground
عجب چیز باحالیه

https://playground.tensorflow.org/

توی این هفته freecodecamp دوتا دوره عالی گذاشته؛ این دو مورد ربطی به پایتون نداره اما بدرد خیلیا میخوره بخصوص :
@pytens, @pyrust

اینکه دارم پست رو اینجا میذارم چون متوجه شدم خیلی از بچه ها این کانال فوق العاده رو نمی شناسند و باهاش آشنا نیستند؛ بهونه کردم برای معرفی کانال.

دوره ها کدوم موارد هستند ؟


1- Cuda Programming Course (in C)

2- Linux Device Driver Development (in C)


حقیقتش اینکه این هفته جلسه نداریم؛ برای این هست که از شروع لایوها اولین جمعه ای هست که تسک ندارم و چون ۲ هفته گذشته بسیار بسیار درگیر بودم؛ ترجیح دادم این جمعه رو استراحت کنم و برای این استراحت این ۲ ویدئو رو انتخاب کردم برای دیدن.

امیدوارم شما هم لذت ببرید؛ کانسپت مهم هست.

A language for next-generation compiler technology

When we realized that no existing language could solve the challenges in AI compute, we embarked on a first-principles rethinking of how a programming language should be designed and implemented to solve our problems. Because we require high-performance support for a wide variety of accelerators, traditional compiler technologies like LLVM and GCC were not suitable (and any languages and tools based on them would not suffice). Although they support a wide range of CPUs and some commonly used GPUs, these compiler technologies were designed decades ago and are unable to fully support modern chip architectures. Nowadays, the standard technology for specialized machine learning accelerators is MLIR.

MLIR is a relatively new open-source compiler infrastructure started at Google (whose leads moved to Modular) that has been widely adopted across the machine learning accelerator community. MLIR’s strength is its ability to build domain specific compilers, particularly for weird domains that aren’t traditional CPUs and GPUs, such as AI ASICS, quantum computing systems, FPGAs, and custom silicon.

Given our goals at Modular to build a next-generation AI platform, we were already using MLIR for some of our infrastructure, but we didn't have a programming language that could unlock MLIR's full potential across our stack. While many other projects now use MLIR, Mojo is the first major language designed expressly for MLIR, which makes Mojo uniquely powerful when writing systems-level code for AI workloads.

https://docs.modular.com/mojo/why-mojo

دقیقا مشکل هوش مصنوعی هم همینجاست.

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

دلیلی برای وجود این تکنولوژی هست ولی خب خیلیا از همون اول دلیل وجودش رو متوجه نشدن.

پشت Mojo یه compiler toolchain جدیده.

سرعت دیگه اهمیت ندارع وقتی که روی سیستمی نشه کامپایل کرد.

ولی خب نگفتم که برید همون اول یاد بگیرید. :)

صبر کنید که اکوسیستمش خوب رشد کنه و بالغ بشه بعدش سویچ کنید.

نکنید اینکارو.

آقا نکنید. ای بابا...

کتاب اینترنتی شبکه های عصبی و یادگیری عمیق. نویسنده Michael Nielson.

میاد و از صفر کل مباحث شبکه های عصبی که باهاش تشخیص عدد MNIST رو حل کردن رو توضیح میده همراه با کد.

حتی الگوریتم SGD و backprop رو هم توضیح میده و کدش رو با numpy نوشته.

درسته که الان tranaformer ها رو داریم و هوش مصنوعیمون پیشرفته تره ولی خب پایه رو یاد بگیرید بعد سراغ اونم میرید.

http://neuralnetworksanddeeplearning.com/

بهترین راه واسه یادگیری هوش مصنوعی

1. مقاله علمی رو گیر بیار
2. با کد پیاده سازی کن
3. اونقدر مراحل بالا رو تکرار کن تا مهارت پیدا کنی

- George Hotz