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

https://www.youtube.com/playlist?list=PLC0nd42SBTaPYSgBqtlltw328zuafaCzA


@ManiFoldsPython

لینک گروهو میذارم با محوریت فقط پایتون و کلین کد و clean architecture و کلا پرکتیس هایی که تو کامینیتی پایتون واقعا جاشون خالیه تو ایران

https://news.1rj.ru/str/PythonFellow

@ManifoldsPython

مرسی از مهدی بابت شیر این ویدیو
تو گروه واقعا مطالب خوبی share میشه خوشحالم که بحث های اینطوری میشه.

https://youtu.be/o_TH-Y78tt4?list=PLgFpVsHvyMn6COlTXABz0pU5A4I81aDIG&t=1820

این ویدیو رو ببینید که عمو توضیح داده راجب MVC as Architecture pattern
خیلی برای من روشن کننده بود
حتما ببینید

مخصوصا جایی که تو ویدیو مارکش کردم ببینید اون ۵ دقیقه رو چون نکات مهمی داره اونجا
@ManiFoldsPython

نظرتون راجع به این جمله چیه؟ (می‌دونم خیلیا واسه فان و خنده اینو پست می‌کنن ولی خب می‌خوام نظرتونو بدونم)

If the code works, don't touch it.
اگه کدتون کار می‌کنه، بهش دست نزنید.

پلی لیست تست جایی قشنگ میشه, که از توی تست نویسی میرسیم به مفاهیم

debugging
refactoring
و
documentation!

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

تو قسمت بعدی از پلی لیست, میپردازم به BDD Testing
@ManiFoldsPython

سلام مانی هستم, یک پلی لیست داریم که توش میپردازم به نحوه تست نویسی, تست های مختلف, و اصول تست نویسی در SDLC


در قسمت پنجم پلی لیست, بررسی کردم که چیو باید تو unit test تست کنیم, و پرداختم به اشتباهاتی که اکثر دولوپر ها تو unit test انجام میدن موقع نوشتن Assertion
همچنین بررسی کردم چرا استفاده از code coverage برای بررسی کیفیت تست ایده بدی هست
و در نهایت تست کد پروداکشن خودمو رو نشون دادم و توضیح دادم چرا تست نویسی خودش میتونه یک داکیومنت خوب باشه

https://www.youtube.com/watch?v=LyT8AiUJTnY&list=PLEQ3RnweNGA6v7qTMrDCcpgr9u91zvpq_&index=5


سوال داشتین حتما زیر ویدیو کامنت کنید پاسخ میدم
@ManiFoldsPython

خیلیا میگن اینستاگرام از جنگو استفاده میکنه, این ویدیو رو ببینید که متوجه شین دقیقا این اتفاق چطور میفتاده

https://www.youtube.com/watch?v=lx5WQjXLlq8

پ.ن:‌تاریخ ویدیو ۲۰۱۶ عه 👌

@ManiFoldsPython

چون خیلیا اینو پرسیدن تصمیم گرفتم تو کانال توضیح بدم, بعدا که پلی لیست هم تموم شد یک ویدیو ظبط میکنم و توضیح میدم پیش نیاز دوره چیه.
برای دیدن دوره تست نویسی, شما کلا باید
۱. یک سال تجربه کار با پایتون داشته باشی یا سینتکس پایتون رو بتونی بخونی
۲. با syntax async اشنا باشید. در حد خیلی خیلی کم
۳. سینتکس fastapi رو بتونی بخونی

مورد سوم هم خیلی نباید سخت باشه حتی بدون خوندن داک فست هم شاید بتونید متوجه شید. ولی باز اگه خواستین خوندن داک فست مقدماتیش ۴ روز بیشتر زمان نمیبره بنظرم.


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

@ManiFoldsPython

بنظرم به جای Makefile از justfile استفاده کنید بهتره, به دو دلیل:

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

تو هر پروژه ای, بنظرم باید کامندی وجود داشته باشه که:
۱. دیتا سپل جنریت کنه برای تست دستی
۲. دیتابیس رو ریست کنه با دیتای جدید
۳. تیبلا رو مجدد بسازه
۴. ماگریتی که نوشتین رو بتونه تست کنه
۵. اینستال پروژه هندل شه
۶. برای ران تست هم کامند جدا باید باشه

همیشه ترجیح میدم از poetry استفاده کنم چون خودش پکیج میسازه برام و lockfile داره و میتونم توش خودم پکیج بسازم که به صورت live از روش بخونه و آپدیتش کنه (مثل shared library بین سرویسا)

Justfile: https://github.com/casey/just


برای تست ماگریشنتون:
۱. باید تیبل هاتون رو پاک کنید
۲. باید برید برنچی که ازش برنچ میگیرین مثلا dev
۳. دیتابیس رو بسازید با اون برنچ و migration هایی که بوده اونجا رو اسکیپ کنید
۴. برگردین برنچی که کار میکردین روش
۵. ماگریشن رو حالا ران کنید تا اخرین نسخه
۶. دیتابیسو چک کنید ببینید چه بلایی اوردین سره دیتابیس :))

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


@ManiFoldsPython

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

خب اینا به هم وابستگی دارن. اگه یکی از پکیج‌ها، یه بخش critical پکیج بالایی خودشو نتونه ساپورت کنه، کل سیستم می‌خوابه و پکیج منیجیر کارش اینه که حواسش به این قضیه باشه.

وقتی pip install میزنید، یه فاز، dependency resolving هست که به همین قضیه می‌پردازه.

راجع به این داستان و جهنم وابستگی‌ها، در این مقاله توضیح دادم:
https://imsadra.me/dependency-hell

سلام مانی هستم, یک پلی لیست داریم که توش میپردازم به نحوه تست نویسی, تست های مختلف, و اصول تست نویسی در SDLC

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

https://www.youtube.com/watch?v=T2mL2fO45hk&list=PLEQ3RnweNGA6v7qTMrDCcpgr9u91zvpq_&index=6


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

@ManiFoldsPython

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

از پلی لیست این ویدیو ها باقی مونده

7. Writing testable codes (DI Container)
8. Deep dive to unit test (Example Testing)
9. Deep dive to unit test (Boundary Testing)
10. Deep dive to unit test (Parameterized Testing)
11. Deep dive to unit test(Property testing)
12. Deep dive to unit test(Hypothesis Testing)
13. Deep dive to unit test (Data driven Testing)
14. Deep dive to unit test (State based Testing)
15. Deep dive to unit test(Contract Testing)
16. Refactoring with unit testing
17. Smoke test
18. Stress test
19. Component Testing
20. Simple UI Testing as Horizontal E2E Test
22. Simple Integration testing
22. Simple A/B testing
23. Testing phases in SDLC


مسیر زیادیه 😁امیدوارم مخاطب نپره :))

@ManiFoldsPython

این meme رو دیدم خیلی جالب بود… عمق دانشنتون از PostgreSQL تا چه حدیه؟ یکم حس بی سوادی دست داد بهم :)) تو یکی از پستا چند روز پیش راجب یکیش پرداخته بودم 😁

Every sql operator is actually a join? WTF?😂

@ManiFoldsPython

سوال: میخواین یک دیتا کلس یا پاینداتیک تعریف‌ کنید، که پیجینشن هم داره.
۱۰ تا schema دارید تو اپلیکیشنتون، چیکار میکنید؟

خب طبیعتا تو همه schema ها این کلید ها تکراری میشن:

result: list[…]
count: int

مثلا برای حیوون میشه
result: list[Animal]

چطوری این قضیه رو قشنگ پیاده سازی میکنید؟

@ManiFoldsPython

جواب سوال, دو نکته داره:

۱. هیچوقت count عددی کمتر از ۰ نیست. اینجا خروجیه ولی دیدم خیلی جاها ورودی مثلا count میگیرن ولی دقیقا positive بودنشو اشاره نمیکنن.

۲. استفاده از جنریک تایپ ها که هم باعث میشن swagger ساخته شه (اگه از فست یا تولز هایی که دیتاکلس/پایندانتیکو ساپورت میکنن استفاده کنید) و هم باعث میشه کمتر کد بزنید و کدتون خوانا تر شه و هم باعث میشه برنامه نویس اشتباه نکنه موقع کار با اون data class.

@ManiFoldsPython

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

https://youtu.be/RSPdZP8YSBE

@BenDevelop

ویدیو خیلی خوبی بود، توصیه میکنم حتما ببینید. من داخل یک جایی دیدم دوستان متاسفانه برداشت کردن که امیربهادر گفته <کلا جنگو بدرد نمیخوره> 😂 خودم کارایی که میکنم و واقعا به قدرت حل مسئله ام جواب داده:

۰. اولین و مهم ترین نکته: همیشه query رو روی دیتابیس مینویسم، تا بهینه ترین کوئری ممکن رو بتونم بنویسم. بعد ترجمش میکنم به کد ORM. خیلی دیدم این مسیرو برعکس میرن که باعث وابستگی به ORM میشه.

۱. اولا کدای لایبری رو میخونم همونطور که اشاره کرد. خیلی وقتا داکیومت نمیخونم. واقعا لایبریا خیلی کوچیکن اکثرا، مثلا فلسک کلا ۱۵-۲۰ فایله پایتونیه تو ۲ فولدر 😁 تستاشم میخونم حتی. خیلی کمکم کرده این موضوع

۲. سخترین تسکایی که تو شرکت ممکنه به من assign نشه اخر هفته یواشکی انجام میدم :)) واقعا کمکتون میکنه این موضوع 😁

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

۴. سعی میکنم تولز ها و لایبری های جدید یاد بگیرم. مثل propan یا rocketry.و خیلی چیزای دیگه که تو شرکت استفاده میشه و نمیتونم اشاره کنم، چون سولوشن هایی که میدن اکثرا راه حل خیلی خلاقانه ای پشتشونه. حتی کدشونم میخونم.

۵. وقتی با یک چیزی کار میکنم، سعی میکنم بهش فکر کنم. مثلا واقعا برام سوال شده بود Kafka چطور fault tolerance ای داره و چه مزیت و ضرری داره نسبت به rabbitmq، که چند تا مقاله راجب دیزاین اینترنالش خوندم و واقعا جالب بود.

۶. تا یک چیزیو حل نکنم ولش نمیکنم 😂 قبلا اینطور بودم که اگه میدیدم یک shortcut میانبر هست که مثلا صورت سوال رو پاک میکنم از اون میرم، ولی الان خیلی به ندرت پیش میاد همچین کاری کنم

@ManiFolsPython

مورد صفر سوال پرسیدن:‌
من هم جاهایی که میبینم کوئری ممکنه یکم پیچیده بشه معمولا اولا میرم sqlش رو مینویسم بعد همونو میذارم توی کد و اکزکیوتش میکنم چون orm ی وقتایی ناخوانا میشه چنتا اگرگیشن و اینا میاد توش گیج میشم. منظورت همینه؟

پاسخ: نه. منظورم این نیست. منظورم اینه که شما هر query که میخوای بنویسی باید مایندست SQL Query رو داشته باشید. یعنی اینقدر تمرین کرده باشین که بدونید چیو رو چی جوین بزنید و چطور query بنویسید که ران تایم queryتون به شکل عجیبی بالا نباشه. (کاری به ایندکس و اینا ندارما خود query رو دارم میگم) و با کمترین هیت به دیتایی که میخواین برسید. خیلی از دوستان دقیقا مسیر رو برعکس میرن یعنی اول میرن سراغ اینکه orm چطور اون اکشن رو عمل میکنه نگاه میکنن query که orm زده چطور شده. خیلیام اصلا اون چک رو نمیکنن که دیگه فاجعه رخ میده..😁

برای query نویسی من همیشه اول دیتابیس رو با سمپل دیتا جلوم باز میکنم. شروع میکنم به query زدن. دیباگش میکنم و ران تایمشو کم میکنم. بهینش میکنم و در نهایت میرسم مثلا به یک query که شده ۱۵ خط مثلا. بعد میام تو orm میگردم ببینم چیزایی که استفاده کردم چطور تو orm استفاده میشه. در نهایت تبدیلش میکنم به کد پایتونی. اینطوری orm هیچوقت برای من query بد نمیسازه. orm جای من تصمیم نمیگیره. من وابستگی ندارم به orm صرفا یک تولزه که دارم ازش استفاده میکنم برای راحت تر شدن maintain کدم و نداشتن sql injection

اتفاقی که تو جنگو ممکنه براتون یک وقتا رخ بده اینه که query که نوشتید مثلا چیزی داره که جنگو ساپورت نمیکنه. مثل outer join (قبلا نمیکرد الان شاید کنه). اون موقع مجبورین query raw بنویسید. اگه دیدین query raw هاتون داره زیاد میشه باید حواستون باشه یا orm رو تغییر بدید یا raw query هاتون رو maintainable بنویسید. یعنی مثلا به جای اینکه تو پایتون بنویسید
query = "SELECT User.username FROM Users"
بنویسید
query = f"SELECT {User.__table_name__}.{User.id.field_name} From {User.__table_name__}"

که اگه اسم فلان فیلد یا تیبل روتو دیتابیستون تغییر دادین یا اگه اصلا حذفش کردین queryتون آپدیت شه.
میتونید از repository pattern هم استفاده کنید که raw query هاتون همه یک جا باشه که بتونید راحت maintain اش کنید.
البته این مثاله ها.. اگه یوزر اینپوت دارین حتما باید از پارامتر استفاده کنید که sql injection نخورید.

پی نوشت:‌برای query خیلی ساده در حد یک where دیگه نمیام همچین کاری کنما... منظورم query هایی هست که یکم پیچیده ترن از اون query های خیلی ساده.

@ManiFoldsPython

یکی از دوره هایی که هر بک اند کاری باید ببینه :)

https://git.ir/p/xnEZB
این تیکه ای که تو عکس گذاشتم رو اصلا فراموش نکنید. مخصوصا قسمت 229. واقعا جذابه 👌
@ManifoldsPython

دوستان یک چیز بگم امروز چند نفر پرسیدن.. میشه کلا raw query زد و از orm استفاده نکرد و sql injection نداشت؟

بله چرا نشه. ولی منطقی نیست. چرا؟
۱. هر orm ای که استفاده کنیم به ما تایپینگ میده. سرعتمون رو سریعتر میکنه

۲. کدمون رو maintainable تر میکنه. تو دنیایی که orm استفاده نمیکنیم در اخر باید اون models.py رو بسازیم و مثلا اسم یک فیلدو همه جا تکرار نکنیم و ... . در نهایت یک چیزی شبیه ORM میشه بازم.

۳. خطای انسانی رو به شدت کاهش میده

پس orm استفاده نمیکنیم که sql ننویسیم یا فقط SQL Injection نداشته باشیم. اگه ملاک اینا بود که از stored procedure به جای ORM استفاده میکردیم. ولی بازم دلیل نمیشه چون از orm استفاده میکنیم پس ندونیم sql injection چیه و چطور هندل میشه و یا sql نتونیم بنویسیم.

@ManiFoldsPython