البته اضافه کنم

۱. از gpt برای کمک به خودتون استفاده نکنید خیلی. چون جلوی خلاقیتتون رو میگیره. برای code review یا کدی که قراره میدونید دقیقا چطوری بشه و ۱۰۰درصد بلدین و صرفا واسه صرفه جویی وقته استفاده کنید.
۲. برای سلف استادی خیلی خوبه. که مثلا ریسورس های خوبو سریع پیداش کنید. یعنی ریسورس هایی که تو حالت عادی شاید رسیدن بهشون یکم سخت باشه. مثلا میخواین راجب <فلان چیز خاص> تحقیق کنید. ازش بخواین کتاب بهتون معرفی کنه راجب همون تایتل و همون سرفصلا و خیلی عالی انجام میده. یا مقدمه بهتون بگه.
۳. مطالبی که میگه چشم بسته قبول نکنید. مثلا اینجا code review ای که کرد خیلی جنرال بود. شاید خیلی از پوینتاش valid نبود برای یک کدی که قرار نیست maintain شه خیلی. یعنی نظرش خیلی تک بعدیه.

@ManiFoldsPython

تو ریپو student fastapi app هم تست نویسیم تموم شد. کلا تموم شد همه بخشاش به جز delete که تصمیم گرفتم ننویسم 😂 جاخالی باشه برای کسی که fork خواست کنه.

دو نکته مهم راجب تست نویسی:

اولا که وقتی unit test مینویسید در لحظه باید یک unit رو تست کنید نه بیشتر. که اگه fail شد بدونید کدوم unit فیل شده. به جای اینکه خیلی رو خوانایی تستتون کار کنید رو text ای که برای assertion گذاشتید کار کنید. که اگه fail شد بدونید چرا این اتفاق افتاده

دوما که اصلا و اصلا و ابدا ‍تست کاوریج مهم نیست!! تاکید میکنم تست کاوریج فقط برای لایبری اوپن سورس مهمه! احمقانه ترین measure برای تست نویسی اینه که شما تست کاوریج رو بسنجید.

ریپو تست ACL منو ببینید
ACL Tests

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

در نهایت به جای اینکه بیام هر روتر رو تست کنم که پرمیشنش مطابق تسک عمل میکنه اومدم اول permission هارو تست کردم, بعد رفتار روتر رو. وقتی رفتار روتر رو تست کردم خود پرمیشن رو ماک کردم که کلا به من برای همه اندپوینت ها همیشه دسترسی بده!! چرا؟‌چون وقتی دارم روتر رو تست میکنم فقط و فقط و فقط باید روتر رو تست کنم نه چیز دیگه ای رو.

@ManiFoldsPython

نهایتا خوشحال میشم یک سر به سورس کد بزنید و ببینید که چطور شد؟

اگه خواستین code review کنید. اگه کسی هم تسکشو بفرسته حتما من سره وقت review میکنم براش.

https://github.com/ManiMozaffar/fast-student

@ManiFoldsPython

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

https://www.youtube.com/watch?v=-EQ5-5wpaec

@ManiFoldsPython

دو falsehoold تست نویسی

۱. چون unit test من پاس شده پس software requirement من satisfy شده و محصول من کار میکنه
۲. تست کاوریج بالا و داشتن assertion زیاد یعنی من تست هام خیلی خوبه و باگ برنامم بسیار کمه

وقتی میگم تست باید رفتار محصول و software requirement رو تست کنه یعنی چی؟ برای یک لاگین بیایم یک software requirement بنویسیم برای لاگین:

User shall be required to change his/her password every 3 months
Login response time on backend shall be time contrainst of 1 second to avoid timing attacks
Login response shall be with respect to Auth0, handled by JWT in cookie with CSRF in header, to be considered as safe
User shall not attempt to unsuccessfull login more than 20 times with an IP Address
User shall be redirected to dashboard after a successfull login
User shall be asked for username and password, to match credential in database, to perform a a successfull login
User shall not be aware of the spefiec reason behind unsuccessfull login, such as "Wrong Password" or "Wrong Email"
Optionally, the user may enable two-factor authentication for added security. This could include SMS, authenticator apps, or hardware tokens.
After a specified number of unsuccessful login attempts, the user's account shall be temporarily locked to prevent brute force attacks. An unlock process must be provided, often through email verification
For avoiding automated login attempts, a CAPTCHA could be implemented, especially after a few failed login attempts.
Optionally, users can choose to be remembered on a specific device/browser, so they don’t have to log in every time


دیدین؟‌حالا باید برای تک تک این موارد بشینید تست بنویسید. که اکثرا e2e test هستند. چرا؟‌چون api throttling که معمولا از gateway میاد و یا ایمیل ارسال میشه و یا فرانت و بک اند همزمان باهم درگیرن. پس میشه گفت ۶-۷ تا unit دارن باهم کار میکنن تا این software requiremenet رعایت شه. وقتی میگم دیتا سمپل باید خوب باشه همینجا خودشو نشون میده. همونطور که فهمیدین باید اکانتی تو دیتابیس تست باشه که ۳ ماه از اخرین باری که رمز رو تغییر داده باشه گذشته باشه که بتونه اون popup مربوط به تغییر پسوورد رو ببینه تو فرانت و بک اند. میتونه بعد از این تستا code coverage ما ۷۰ درصد باشه میتونه هم ۱۰۰ درصد باشه اصلا برامون مهم نیست!‌مهم اینه که کارایی که یوزر میخواسته بکنه موقع لاگین رو پلتفورم رو همگی تست کردیم حتی اگه یک روتر اصلا تست نداشته باشه. همونطور که میتونه تست کاوریج ۱۰۰ باشه و هیچکدوم از اینا تست نشده باشه.

در آخر اشتباه برداشت نکنید, یونیت تست برای ‍smoke testing خیلی عالیه. e2e تست پیچیدگی زیادی داره و دلیل نمیشه قید unit test رو بزنید چون e2e دارین.


وقتی این موارد رو رعایت نمیکنید انتظار یک پروداکت خیلی stable نباید داشته باشین. البته که پایبند بودن به همه اینا سخته و زمانبر ولی تو case و پروداکت خودتون باید بسنجید آیا برای من سودی داره که پروداکتم بسیار stable و کم باگ و خطا باشه؟


@ManiFoldsPython

#RECAP
پستی که قبلا گذاشتم دوباره میذارم:

تست ها دو وضعیت دارن:

یا stateful هستند. یعنی state چیزهایی که دارید تست میکنید قبل و بعد از تست فرق میکنه. مثلا فکر کنید دیتابیس رو ماک نگرفتین و تست بک اند رو یک دور ران کردید رو خود پروژه به صورت مستقیم. اینطوری شما دارین دیتایی به اپلیکیشنتون اضافه میکنید که قبلا نبوده. یعنی state اپلیکیشن شما با هر بار ران شدن تست ها فرق میکنه

و یا stateless هستند. یعنی مثلا شما ۱۰۰ بارم که تست رو ران کنی state اپلیکیشن شما فرقی نمیکنه و همونیه که قبلا بوده.


و تو چند تا کتگوری مختلف هستند که ۴ تاشو اینجا معرفی میکنم:

۱. یونیت تست: به تستی گفته میشه که داره یک یونیت رو تست میکنه. اگه یونیت دیگه ای باشه اون یونیت می بایست ماک شه. مثل ردیس و یک API. اگه قراره API یونیت تست شه پس ردیس باید ماک شه. یونیت تست ها معمولا stateless هستند. معمولا تو مرحله توسعه هر یونیت نوشته میشوند. هر یونیت باید ایزوله شود.

۲. اینتگریشن تست:‌درواقع integration بین ۲ یا چند unit تست میشه. اکثر مواقع stateful هستند ولی میتونند stateless هم باشند. معمولا تو مرحله اتصال دو یونیت به هم نوشته می شوند. مثلا تست میکنید که ایا وقتی یک مسیج produce میکنید تو کافکا ایا کانسومر ران میشه و تسکشو اجرا میکنه؟‌به این میگن integration test.

۳. تست اند تو اند (e2e):‌ کل سیستم تست میشه. اکثر اوقات (خیلی کم پیش میاد اینطور نباشه) stateful هستند. معمولا از دید کاربر سیستم ‍e2e میشود و در آخرین چرخه توسعه قبل از رفتن رو پروداکشن انجام میشود. همچنین قبل از اولین ریلیز اولین بار شروع به توسعه خود تست میشود. برعکس دو مثال بالا که حین توسعه بودند.

۴. اسموک تست:‌تستی که برای بیلد گرفتن اجرا میشود بهش میگن اسموک تست. معمولا از unit test برای اسموک استفاده میشه. از هر تست stateless دیگه ای هم میشه استفاده کرد برای اسموک تست. حواستون باشه نباید از stateful برای اسموک استفاده کرد چون ممکنه به اشتباه تست fail شود (بخاطر تغییر state) و بیلد الکی ریجکت شود. ولی بازم ممکنه یک جاهایی استفاده از تست stateful برای اسموک هم منطقی باشه. ولی تو حالت عادی باید از این کار جلوگیری کرد.

@ManiFoldsPython

سلام 👋👋

مطالب مهمی که تو کانال گفتم, مواردی که کمتر بهش پرداخته میشه تو کامینیتی پایتون ایران, رو نوشن کردم تو این کانال

لینک نوشن

میتونید ببینید و از این نوت ها استفاده کنید.

در آینده پست هایی که تو کانال هم میره بعضا وارد این نوشن میشه.

اگه براتون notion درست نمایش داده نمیشه(راست چین نیست) میتونید از یکی از دو extension زیر استفاده کنید:

Notion-Enhancer

NotionRTL

@ManiFoldsPython

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

خب خب
بریم سراغ راهنمایی اول
من پروژه رو خودم تکمیل کردم و در لینک زیر قرار دادم
https://github.com/amirbahador-hub/python_tutorial
کاری که شما باید بکنید اینه که fork بگیرین و بهبودش بدین
الان دیگ خیلی راحت تره دیگ , یه کدی دارین که داره کار می‌کنه
فرض کنید سنیور شرکت هستین و اینو یه جونیور بهتون pull request داده

همانطور که گفتم باید سعیتون این باشه که با کمترین راهنمایی به جواب برسین

@BenDevelop

تو پروژه student app رضا جان PR زد یک نکته خیلی تمیز پیدا کرد!

در صورتی که من شروطمو اسم گذاری کرده بودم که باعث خوانا تر شدن کد میشد رضا از Walrus Operator استفاده کرد که همینکارو تو یک خط انجام بده و حجم کد بیشتر نشه 👌

یک نکته

اگه برید تو ریپو کل پوشه ACL و پیاده سازیش یک کلس هم نداره! یک نفر از دوستام همین کارو کرده بود ولی برای هر user role اومده بود یک کلس ساخته بود که نتیجش این شده بود که همیشه نیاز به کلس داشت برای اضافه کردن یک role جدید و نمیتونست از فانکشن هایی که نوشته re-use کنه.


همیشه استفاده از دیزاین پترن های OOP همه چیزو پیچیده میکنه. منتهی باید بدونید کجا استفاده کنید که کدتون رو خوانا تر کنه (مثلا اگه ۱۰۰ تا فانکشن داشتم اون موقع قطعا باید function هامو decouple میکردم یا تو چند تا کلس اونا رو میشکوندم که رفتاری رو پیاده سازی میکردن.

@ManiFoldsPython

SOA vs Microservices

@ManiFoldsPython

یک اشتباهی که تو این تیبل وجود داره اینه که نوشته containerization تو SOA محبوب نیست در صورتی که عکس این موضوعه
تو microservice هم اشاره به grpc نشده

@ManiFoldsPython

دو ریسورس خوب که تو گروه بچه ها به اشتراک گذاشتن

یکی برای درک بیشتر SOA که آمازون توضیح داده. خوبه نسبتا. فقط کاش توضیح ESB رو بیشتر میداد چون یک پارگراف براش تو همچین article ای کم بود.
https://aws.amazon.com/what-is/service-oriented-architecture/

یکی هم شرح DI تو مدرن پایتون و رفع ابهام
https://www.youtube.com/watch?v=qkGxy4c64Jg


گروه دقیقا داره سمت خوبی میره و سوالات خیلی خوبی پرسیده میشه👌
@ManiFoldsPython

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

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

خیلی به اشتباه دیدم دولوپرا همینطوری قطاری میان ایندکس میزنن بدون اینکه بفهمن داره چه اتفاقی میفته. خیلی وقتا index ای که شما میزنی بدتر باعث میشه پرفومنس اپلیکیشتون ضعیف تر شه.

مزایا نداشتن ایندکس:

write خیلی سریع تر
CPU-usage خیلی کمتر
دیسک اسپیس کمتری اشغال میکنه دیتابیستون بدون ایندکس
میدونستید وقتی دارین یک row رو آپدیت میکنید دیتابیس داره indexاش رو لاک میکنه؟ چون باید در برابر race condition مقاوم باشه. البته این تاثیرش مثلا تو postgresql خیلی بهینه تر و کمتره تا mysql
اورایندکس که sql planner تون میتونه به اشتباه index بدی رو انتخاب کنه
ایندکس زدن رو دیتایی که موقع query زدن بیشتر از ۳۰ درصده (ایندکس رو دیتایی جواب میده که مثلا کمتر درصد حضور داشته باشه. مثلا دیتایی که ۳ تا حالت بیشتر نداره بهتره از enum استفاده شه به جای ایندکس)

من یک پروژه همینکارو کردم. قطاری ایندکس زدم. سرعت read عالی شد. ولی وای به حال موقعی که بخواد کلی write همزمان بخوره...
چند بار شده دیتابیس داون شده بخاطر همین...
مجبور شدم کل index هارو دراپ کنم از اول بزنم.
زدن ایندکس اصولی واقعا سواد بالایی میخواد و همینطوری کشکی زدن درست نیست اصلا. باید دقیقا متوجه شین چی رو دارید ایندکس میکنید و چرا ایندکس میکنید؟


یک برنامه نویس سنیور میفهمه داره چیکار میکنه! نمیخوام label کنم ولی این کامل ترین تعریفی بود که شنیدم. این تجربه مصاحبه من با ولکس واگن بود حتما توصیه میکنم بخونید.. خیلی دیدم به مفهوم سنیوریتی تغییر کرد بعد این مصاحبه!

پ.ن: سنیور کلمه ایه که کلا ۵ بار تو کل پستای کانالم تکرار شده... چون واقعا علاقه ندارم به این الفاظ اینطوری..
@ManiFoldsPython

اپدیت اخر فست شما حالا میتونید تو سطح APIتون چندین مثال داشته باشین برای schema 🙌🙌
@ManiFoldsPython

مثال ACL که نوشتم یادتون بود؟ تو اپ دانش آموز

که تو هر روتر مجبور میشدم بیام یک enum بهش بدم که این روتر چیه که بتونه کانفیگو بخونه از ACL

حالا داشتم یک کاری میکردم که کدی که داره چک میکنه پرمیشن روتر رو کاملا بره تو depends که تو همه روتر ها duplicate نشه. تقریبا تا ۹۰درصد مسیرو رفتم ولی خیلی بد شد چون باید APIRouter خود فست کاستومایز میشد.

حالا اگه built in تو خود لایبری میشد برای هر روتر یک enum گذاشت که دیگه نیاز نباشه با path اون روتر شناساییش کنیم خیلی عالی میشد (یک چیز static و با خوانایی بالا). نظرتون چیه؟

اینجا پیشنهادشو گذاشتم اگه موافق بودین حتما upvote کنید. اینطوری کل کد میرفت تو Depends و DI میشد کلا و خیلی تمیز و خوشگل تر میشد کد👌

https://github.com/tiangolo/fastapi/discussions/10156

@ManiFoldsPython

دوستان falsehood یعنی خرافه
یعنی این متنی که مینویسم اینجا از مورد اول تا آخر غلطه.
اینو برعکس کنید درست میشه تازه.

دلیل اینطور پستا هم اینه که باور غلطمون رو سریع بتونیم پیدا کنیم و اصلاحش کنیم.

مثلا تو این پست من کلی چیز یاد گرفتم:
https://news.1rj.ru/str/manifoldspython/318

مثلا میدونستید ما ساعت ۲۳:۵۹:۶۰ داریم؟

میدونستید که داشتن دو تا UTC Timestampts دلیل نمیشه شما بتونید فاصله ثانیه ایشون رو حساب کنید؟‌اگه یکیشون تو اینده باشه؟‌:)))).

میدونستید کم ترین فاصله بین دو نقطه یک خط مستقیم بینشون نیست؟

آدم اینا رو میخونه کم کم به اطرافیانش شک میکنه 🤣

@ManiFoldsPython

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

https://www.youtube.com/live/UjPYhD2PUVc?feature=share
@ManiFoldsPython

یکی از خفن ترین typing هایی که تو پایتون هست و تو داک pydantic هم حتی بهش اشاره شده لایبری annotated_types هست

خیلی خوبه حتما استفاده کنید!
https://github.com/annotated-types/annotated-types

@ManiFoldsPython

توضیح annotated type از سروش که خیلی کامل بود
و داستانش کلا...

@ManiFoldsPython