ممنون از همه دوستانی که امروز تو لایو حضور داشتن. خیلی خوشحال شدم از حجم استقبال تو لایو!

۲ ساعت و ۲۰ دقیقه شد لایو. ۵۰ دقیقه بیشتر از چیزی که پلن ریخته بودیم متاسفانه. کدشو تکمیل کردم گیت هابشم اینجا میفرستم که بتونید کلون کنید و ببینید. طول هفته مشغولم و آخر هفته فقط سرم خلوته احتمالا میفته شنبه یا یک شنبه هفته آینده. تو کانال همرو با 4k اپلود کردم که حجمش شد ۹ گیگ. یک نسخه دیگه هم آپلود میکنم که ۱ گیگ خواهد شد با کیفیت پایینتر

@ManiFoldsPython

من اکثر newsletter هایی که میاد برام رو unsub میکنم

ولی واقعا مال آریان خیلی قشنگه
توصیه میکنم حتما سابش کنید

https://www.arjancodes.com/

@ManiFoldsPython

کیفیت 720P با حجم ۱.۳ گیگابایت

00:00 - 19:18
نحوه خواندن کدینگ چلنج

19:18 - 27:12
- تست نویسی و اصول تست در SDLC

27:12 - 38-45
Database design

38:45 - 51:55
API Design

51:55 - 1:22:48
Restful best practice + JWT function impl

1:22:48 - 1:46:27
MVC + Repository pattern

1:46:27 - 2:19:58
ACL Impl

2:19:58 - END
Why should we use ACL rather than permission

@ManiFoldsPython

سلام دوستان!
دیروز یک کد لایو چلنجی رو در حد prototype باهم کد زدیم
به نظر شاید خیلی ساده میومد ولی کلی نکاتی داشت که ممکنه از قلم بندازید! ۲ ساعت و ۲۰ دقیقه شد که نهایتا تو چندین پارت داخل کانالم قرار دادم که لینکش رو براتون میذارم. همچنین اگه تمایل داشتین که با حجم کمتر دانلود کنید (720P).

قبلش اشاره کنم که اگه با مفاهیمی که تو لایو کد اشاره میکنم آشنا نبودید (یا اگر بودین هم بازم توصیه میکنم)‌ که این ۲ ویدیو رو حتما ببینید
- Software engineer mindset (300-700$)
- Software design (Youtube)

لینک توضیحات خود تمرین و چیزایی که تو تسک خواسته شده بود ازتون
- توضیح لایو کد چنلج

برای دانلود کل دوره میتونید از این لینک هم استفاده کنید
- دانلود کل لایو کد از با کیفیت 720P

بخش های کوچیک تر از هر دوره
- نحوه خواندن کدینگ چلنج
- تست نویسی و اصول تست در SDLC
- دیزاین دیتابیس و نکات مربوطه
- دیزاین کلی API اپ دانش آموز
- دیزاین JWT
- نکاتی راجب RestAPI
- نکاتی در مورد MVC + Repository Pattern
- دیزاین و پیاده سازی ACL
- کدمون چه شکلی میشد بدون ACL?

™️ @DjangoIR
〰〰〰〰〰〰
© @DjangoEx |
© @ManiFoldsPython

خیلی مهمه که V-Model رو درک کنید تو SDLC

این مقاله به زبون فارسی خیلی خوب توضیح داده

همینطور میتونید از ریسورس انگلیسی هم استفاده کنید.
از chatgpt پرسیدم که چی گفته و تا حد خوبی توضیح داده!

1. Requirements Analysis: At this stage, you gather and analyze the requirements for the software project. This is the basis for the entire development process.

2. System Design: This involves designing the overall architecture of the software system.

3. Architecture Design: The system is broken down into smaller components, and the relationships between them are defined.

4. Module Design: Individual components are detailed further, defining how they will function.

5. Coding: This phase involves writing the actual code for the project, using best practices and standards, such as those you outlined in your preferences.

6. Unit Testing: Each small part (or unit) of the software is tested to ensure that it functions correctly. This corresponds to the Module Design phase.

7. Integration Testing: As components are combined, integration testing ensures that they work together as intended. This corresponds to the Architecture Design phase.

8. System Testing: The entire system is tested to ensure that it meets the requirements defined in the System Design phase.

9. Acceptance Testing: This phase ensures that the complete system complies with the requirements originally outlined. It's usually conducted by the end-user and corresponds to the Requirements Analysis phase.

The V-Model is called such because the process can be visualized as a "V," where the left side represents the development phases, and the right side represents the corresponding testing phases. The bottom of the "V" is where the coding takes place.


Advantages:
• Clear Relationship Between Development and Testing: Each development phase has a corresponding testing phase, so it's clear what type of testing is required at each stage.
• Emphasis on Verification and Validation: This approach ensures that both the functionality (verification) and the compliance with requirements (validation) are emphasized throughout the lifecycle.
• Early Identification of Defects: By having corresponding test phases for each development stage, errors can be identified early in the process.

Disadvantages:
• Rigidity: The V-Model is quite rigid and doesn't easily allow for changes once a phase is completed


یک Disadvantages دیگه و یک Advantage دیگه هم گفت که خیلی اشتباه بود! حتما وقتی از gpt یک چیزی میپرسید و یک جوابی بهتون میده برین گوگل کنید و راجبش تحقیق کنید و مقاله بخونید. هرچی میگه رو سریع و چشم بسته قبول نکنید 🙂


@ManiFoldsPython

V-Model
@ManiFoldsPython

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

ریپو کدینگ چلنج تقریبا تموم شده
دیباگش مونده‌ +‌تست هاش
که فردا مینویسم

و آخر هفته هم یک ویدیو دیگه ریکورد میکنم و توضیح میدم جاهایی که اضافه کردم.


سوالی داشتین حتما بپرسید .. :)
@ManiFoldsPython

سه نکته خیلی مهم 🙂

۱. شروطتون رو اسم گذاری کنید. مثلا دیدم ۳ خط شرط نوشتن, که خب مشخص نیست چیو داره دقیقا چک میکنه!

از توی ریپو اگه ببینید مثال زدم

is_classroom_teacher = relation.teacher_id == asked_id
if is_classroom_teacher:
   ...

is_self_student = relation.student_id == asked_id and asked_id == ask_for_id
if is_self_student:
   ...

خیلی مشخصه چیو چک داره میکنه دقیقا 🙂

۲. استفاده از NewType
درسته که مثلا user_id من UUID هست ولی دلیل نمیشه من همه جای کد بنویسم این UUID عه! چون user id من با student id من فرق میکنه. پس بهتره براش تایپ جدیدی بنویسم و توی خود مدل هم به جای اینکه بگم این UUID هست بگم این UserId هست. اینطوری اگه به تابعی چیزی پاس بدم که مثلا student_id میخواست ولی منuser_id دادم اون موقع کد ادیتور من بهم ارور میده.

تایپ هام تو ریپو


۳. استفاده از TypeVar
فرق بین typevar و newtype اینه که TypeVar دقیقا تایپ جدید نیست. بلکه تایپیه که داره یک چیزی رو represent میکنه

خیلیی به درد میخوره. شما با تایپینگ میتونید کدتون رو داکیومنت کنید!‌یعنی چی؟‌الان توضیح میدم‌👀
فکر کنید من تابعی دارم که میخوام یک نویسنده رو اضافه کنم به عنوان اصلاح کننده (یا ادیتور)

assign_editor_to_author(editor: Author, blog_author: Author) -> Author

الان اینجا مشخص نیست که من خود نویسنده رو برگردوندم یا ادیتور رو؟ باید کل تابع رو بشینم بخونم. تایپ جدیدی هم ندارم که NewType بسازم. جفتشون واقعا Author هستند حالا یکیشون اومده اینجا ادیتور شده. پس چیکار میکنم؟‌از TypeVar استفاده میکنم و bound میکنم

Editor = TypeVar("Editor", bound=Author)
BlogAuthor = TypeVar("BlogAuthor", bound=Author)
assign_editor_to_author(editor: Editor, blog_author: BlogAuthor) -> BlogAuthor

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

@ManiFoldsPython

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

صرفا اینو میگم چون مثلا کنترلری که نوشتم که SRP رو نقض میکرد ۵-۶ تا ری اکشن منفی خورد ولی تو کامنتا کسی توضیح نداده چرا!

@ManiFoldsPython

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

ببینید من تجربه خودمو میگم.
مورد اول:‌شما وقتی اصول SOLID رو رعایت کنی خیلی کم لازمه دیباگ کنی. هیچوقت با باگای خیلی عجیب و غریب نیازی نیست سرو کله بزنی. مثال میگم من چند روز پیش داشتم با کلاینت AioHTTP کار میکردم. یک باگی خوردم که حالشو نداشتم واقعا بشینم دیباگ کنم که از کجای کدم میاد. چون SOLID رو رعایت کرده بودم به جای اینکه ۳۰ دقیقه دیباگش کنم تو ۵ دقیقه یک کلاینت httpx نوشتم و از اون استفاده کردم :))) من یک ماه درگیر یک باگی تو سلنویم بودم در صورتی که اگه SOLID رو رعایت کرده بودم تو چند دقیقه میتونستم سلنیوم رو به playwright تغییر بدم! اون flexibility که به شما میده بهتون اجازه میده که صورت سوال رو کلا پاک کنید. حالا اگه SOLID ننوشته بودم هم تستامو باید ریفکتور میکردم هم کل کدامو!

و البته type hint هم رعایت کنی تایمی که صرف دیباگینگ میکنی ناچیز میشه چون خیلی از باگا رو حین develop میگیرین. مثل مثال encode claim که بالاتر اشاره کردم. من ترجیح میدم ۲ ساعت تایپ هینت بنویسم تا اینکه ۲ ساعت بیشتر دیباگ کنم.

پس رعایت SOLID رو درازمدت و رعایت type hint تو کوتاه مدت بهتون سود میده! و کم کم دستتون سریع تر میشه و عادت میکنید به کد خوب نوشتن :)

پی نوشت:‌من کلا منظورم SOLID فقط ‍SOLID نیستا. تاکید رو خود SOLID ندارم. تاکید رو این دارم که کدتون یک دست و decouple شده باشه حتی اگه OOP نباشه.

@ManiFoldsPython

این پست 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