بنظرم به جای 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

ازتون یک سوال دارم،
https://roadmap.sh/backend
این سایت پره رودمپ خفنه، که مال بک اند رو گذاشتم، منتهی ته رودمپ میخوره به بحث های دوآپسی
بنظر شما یک بک اند کار چقدر باید مفاهیم زیرم بلد باشه؟

۱. لینوکس
۲. instrumentation
۳. monitoring
۴. کوبر
۵. Web server
۶. داکر و سوارم
۷. تلمتری

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

اما مرز یادگیریش تا چه حد باید باشه؟ من سعی کردم در حدی یاد بگیرم که سرویس خودمو جمع و جور کنم، و کمک دست devops کاره باشم جایی که اورلپ داره با کدای خودم، مثلا یک دوره prometheus داشتم میدیدم که تهش میرسید به auto scaling با k8s و دیگه سعی نکردم اونو یاد بگیرم چون حس کردم از تایتل شغلی‌من خارجه
نظرتون چیه؟

@ManiFoldsPython

یه عده کانتنت کریتور هستن، سمی‌ان. از اینا دوری کنید. 😂

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

اصلا چه اصراریه اینقدر بولد کنی یه ابزار یا زبان رو؟

(خدا نکنه بیزینسی بیوفته دست این نوع طرز تفکر)

یک نکته بگم تو آداپتور نویسی (Adaptor pattern)

شما هرجایی تو آداپتور که I/O داشتین حتی اگه sync بود بازم با async بنویسید. یعنی مثل async باهاش برخورد کنید حتی با وجود اینکه sync عه! دلیل دارم اینو میگم;
ممکنه امروز لایبری نباشه ساپورت کنه async اون I/O رو. ولی فردا ممکنه بیاد. پس وقتی میاد ریفکتور خیلی بزرگی نخواهید داشت و کافیه چند خط رو ریفکتور کنید تا کدتون async شه.
به این کار میگن future-proof code

یعنی کدی که میتونید رانش کنید به محض بیرون اومدن تکنولوژی جدید بدون اینکه مجبور باشید ریفکتور بزرگی کنید.
منتهی نباید over-do کنید اینکارو. فقط جایی که لازم دارین واقعا اینکارو انجام بدید. پروژه ای که میدونید این تیکش اگه async بشه خیلی عالی میشه. زیاد انجام دادنش باعث پیچیدگی بیخود کد میشه زمانی که اون کد اصلا کارایی نداشته. خلاصه YAGNI رو نقض نکنید :))


@ManiFoldsPython

WTF 😂😂
خیلی جالب بود :))))))

@ManiFoldsPython

:))))

اینم جدول ارزش گذاری دوستان :))
@ManiFoldsPython

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

@ManiFoldsPython

ویدیو بعدی راجب DI Container و نحوه پیاده سازیش

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

پی نوشت:‌سورس کد تمام دوره رو گیتهابه
https://github.com/ManiMozaffar/testing-101

@ManiFoldsPython

داشتم ویدیو رو آپلود میکردم که یوتیوب تو ساجسشن برام یک ویدیو خیلی جالب اورد
توصیه میکنم حتما ببینید
https://www.youtube.com/watch?v=1KiItzAHDpM
نمیشه گفت <همه نکات> ولی نکات خیلی خوبی رو اشاره کردن

یک ریسورس هم معرفی کردن که خیلی خوب بنظر میان:
https://www.manning.com/books/the-art-of-unit-testing-second-edition

و البته مرد همیشه در صحنه Martin Fowler و بلاگ خوبش راجب تست نویسی
https://martinfowler.com/bliki/UnitTest.html

@ManiFoldsPython