TECH STASH – Telegram
TECH STASH
212 subscribers
115 photos
5 videos
15 files
254 links
اینجا هر چی رو که یاد میگیرم، به اشتراک میزارم...
هوش مصنوعی، لینوکس، اوپن سورس، برنامه نویسی و...

Admin: @D3F4U1T_ARS
Download Telegram
سلام دوستان.
چند وقت پیش میخواستم راجب 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
منابع تورنت مشکلات کپی رایت دارن.

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

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

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


1- Cuda Programming Course (in C)

2- Linux Device Driver Development (in C)


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

امیدوارم شما هم لذت ببرید؛ کانسپت مهم هست.
👍1
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
TECH STASH
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…
دقیقا مشکل هوش مصنوعی هم همینجاست.

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

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

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

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

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

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

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

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

http://neuralnetworksanddeeplearning.com/
Haha GPUs go brrrrr

#Meme
کانال letsgetrusty آموزش های خوبی راجب rust میزاره.
اگر rust کار باشید قطعا میشناسید.

https://www.youtube.com/@letsgetrusty

حالا یه آموزشی هم داره که تو downloadly گذاشته شده. که به نظر میاد عالیه.

https://downloadly.ir/elearning/video-tutorials/rust-developer-bootcamp/#/134348-letsgetr-112401103107.html
چه ابزارایه اوپن سورس جایگزین PowerPoint داریم؟

https://revealjs.com/

https://www.manim.community/

https://marp.app/

https://sli.dev/

https://impress.js.org

تازه ترکیب manim و revealjs هم میتونیم داشته باشیم با embed کردنش داخل خود revealjs.

اینم احتمالا بدردتون میخوره.

https://manim-slides.eertmans.be/latest/