این پست Falsehood رو یادتونه؟‌این سبک یاد گیری بنظرم خیلی خوبه. حالا بریم راند دو :))

1. If the code works, it is clean.
2. Comments are unnecessary if the code is written clearly.
3. Clean code is always easy to understand, regardless of the complexity of the problem.
4. Writing clean code will always take more time than writing quick-and-dirty code.
5. Clean code means having no duplication whatsoever.
6. Adhering strictly to a particular coding standard or style guide guarantees clean code
7. Clean code is only about readability and has nothing to do with maintainability
8. Refactoring a working codebase to make it cleaner is usually a waste of time.
9. Using many design patterns guarantees that the code is clean
10. Clean code can only be achieved by senior developers; beginners cannot write clean code
11. Testing is a separate concern from writing clean code and doesn't contribute to it
12. A piece of code is clean if it passes all linters and automated style checkers.
13. Following SOLID principles blindly, without understanding the context, will always result in clean code
14. Clean code doesn't need documentation outside of the code itself
15. Clean code is a fixed goal, not an ongoing process; once the code is clean, it will stay that way without continuous effort.

اونایی که مهم تر بودن رو بولد کردم. کلش بولد شد :))
@ManiFoldsPython

یک توصیه:‌برین تک تک چیزایی که تو typing پایتون ۳.۱۱ هست بشینید و بخونید.

مثلا من خیلی دیدم وقتی دارن یک base class میسازن و یک متود رو مینویسن دکوریتور final رو نمیذارن. وقتی دیکوریتور final رو میذارید رو یک متود از کلس یعنی این متود اجازه نداره اورراید شه.

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

@ManiFoldsPython

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

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

create_user -> User
create_classroom -> ClassRoom
create_teacher -> Teacher
create_student -> Student
create_advisor -> Advisor
create_admin -> Admin

create_relation(
classroom_id: ClassRoomId,
student_id: StudentId | None = None,
teacher_id: TeacherId | None = None,
) -> ClassRoomRelation:
return ClassRoomRelation(
teacher_id=teacher_id,
student_id=student_id,
classroom_id=classroom_id,
expires_at=datetime.now()
+ timedelta(days=random.randint(0, 30))
- timedelta(days=random.randint(0, 30)),
)


# Then use all those functions -> create DB!
add_sample_data(
count_admin: int = 1,
count_classroom: int = 3,
count_advisor: int = 3,
count_student: int = 100,
count_teacher: int = 8,
) -> Type[Database]


این expires_at چیه؟ همونطور که تو live گفتم نشون میده دانش آموز کی ریلیشنش با اون کلاس قطع میشه. مثلا دانش اموز یک سال درس میخونه دیگه درسته؟


@ManiFoldsPython

۲ سوال دارم ازتون یکم فکر کنید میتونید جواب بدید

۱. چرا تو سمپل دیتا موقع ساختن من اومدم expıres-at رو تایم الان گرفتم بعد منهای ۱ تا ۳۰ روز (رندوم) کردم و بعدش دوباره رندوم (۱ تا ۳۰ روز) اضافه کردم؟

۲. چرا اصلا سمپل دیتا باید بنویسیم؟ به چه دردی میخوره؟ مزایاش چیه اگه مثلا سمپل دیتامون دامپ پروداکشن باشه؟ یا نسبت به حالتی که کلا سمپل دیتا نداریم؟

@ManiFoldsPython

مبین جواب جفت سوالو داد تو کامنت, دو مالفه داریم برای یک دیتا سمپل

‍۱. تنوع یا diversity
۲. حجم یا scale

خیلی وقتا تستای ما پاس میشن, چون دیتایی که قبل از تستا ساختیم(تازه اگه ساخته باشیم) خوب ساخته نشدن. وقتی دارین سمپل دیتا میسازید برای هر آبجکت تمام حالت های ممکن رو باید داشته باشید تو سمپل دیتاتون. پروداکشن نمیتونه به ما تضمین بده که همه حالت هارو کاورد کرده.

نکته دوم اینه که حجم دیتا production دست ما نیست. پس نمیتونیم stress test بنویسیم. خود حجم دیتا هم ممکنه تاثیر گذار باشه رو pass شدن تستمون.

و نکته آخر اینه که برای استفاده از دیتا پروداکشن, اولا دارین به تمام developer ها این دسترسی رو میدین که جالب نیست. دوما دارید کل دیتابیس رو میذارین تو ریپازیتوری git اتون!‌ ‌که اینم جالب نیست.


کد من که داره سمپل دیتا میسازه اشکال داره,اشکالش کجاست؟

https://github.com/ManiMozaffar/fast-student/blob/main/fast_acl/sample_data.py

@ManiFoldsPython

نظرتون چیه مطالب کانال notion شه؟ یا پلتفورمی سراغ دارین که به همون راحتی باشه؟ 🤔 واسه خودمم note و مرتب میشه

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

نظری ندارین؟

مشکل کد من اینجا بود.

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

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

پس رفتار هایی که ناشی از این دو تا پارامتر به وجود میاد همیشه پاس میشه تو تست من. مثلا ممکنه endpoint لیست دانش آموز من نباید دانش آموز اخراجی برگردونه. ولی چون تو سمپل دیتا من نیست پس تستام پاس میشه.

@ManiFoldsPython

اگه تو برلین هستین این event رو از دست ندید 👀 سباستین و مارسلو (استارلت)‌و samuel calvin (سازنده pydantic و پایتون fellow جدید) و armin ronacher (سازنده فلسک)‌همه اونجان

کاش میتونستم برم :))

https://sentry.io/resources/fastapi-event/

@ManiFoldsPython

سوال:‌ میخواهید schema برای APIتون بنویسید که تمام timestampt هارو UTC کنه با Pydantic و FastAPI که دیگه خیالتون راحت باشه هرچی فرانت فرستاد تاثیری نخواهد داشت.

اگه حتی نمیتونید کدشو بزنید در حد prototype هم کامنت کنید جوابشو. جوابش نهایتا چند خطه.

@ManiFoldsPython

تو کامنت ها جواب رو اشاره کردن

UTCDatetime = Annotated[datetime, AfterValidator(lambda v: v.to_utc())]

class Model(BaseModel):
    remind_at: UTCDatetime

دقیقا نکته همینجاست.
PARSE DON'T VALIDATE

به جای اینکه بیایم از validator پایندانتیک همه جا کپی پیست بگیریم بذاریم, یک تایپی میسازیم که خود پایندانتیک برامون کلین کنه. حالا سوال اینجاست, که اگه خواستیم بیشتر کاستومایز کنیم چی؟ دقیقا تو عکس گذاشتم که چطور میشه.

یعنی شما میتونید کاملا ولیدتور کاستوم برای هر تایپی بنویسیم و بعد اون تایپ رو استفاده کنید. نکته مهم سعی کنید حتما تو داکیومنت pydantic core رو یکم بخونید و یکم ازش سر دربیارید. مثلا هندلر های مختلف داره که خودش تایپو براتون هندل میکنه. مثلا اگه string بدید تاریخو خودش datetime میکنه اگه بشه. خودتون هم میتونید هندلر بنویسید کاری نداره. هر اروری raise کنید خود پایندانتیک هندلش میکنه ولی بهتره از ارور خود ValueError پایندانتیک یا built in python استفاده کنید.

اگه مجیک متود پایندانتیک core schema رو تعریف نکنید اونوقت تایپتون میشه Arbitrary و فقط با ‍isintance چکش میکنه.

@ManiFoldsPython

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

۱. از 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