یک ویدیو اخر داریم alembic. که میشه فقط سیستم ماگریشن یعنی خوده لایبری کلا جمع شد. که اونم امشب یا فردا شب منتشر میشه.

اما یک چیزی کمه، که یک نمونه کد باهم بزنیم. یعنی یک پروژه کوچیک بزنیم. که ببینید تو دنیای واقعی چطوری استفاده میشه.

اینو میخوام بصورت لایو بذارم.میدونم نت ها بده. برای همین من یکی دو هفته باید وقت بدم که هرکی عقبه ببینه ویدیو هارو. بنابراین این لایو رو ۲ هفته دیگه اینطورا خواهیم داشت.


@PyBackendHub

فرهنگ فیدبک دادن واقعا افتضاحه! یک نفر میاد همینطوری کامنت میذاره، بدون اینکه هیچ دلیل و استدلالی باشه. هروقت دارین یک نظری راجب یک content میدین، چه مثبت چه منفی باید اینطوری باشه:
من فکر میکنم <افکارتون>…، چون <دلیل ۱> و <دلیل ۲>.
من حدس میزنم دوستمون چرا همچین حرفی زده، برای همین تو کانال توضیح میدم:

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

دوما همه چیزو تو detail ریز توضیح نمیدم. مثلا تو ویدیو اخر میگم اره Session داره ابجکت های orm اتون رو track میکنه. نمیام بگم چطوری میکنه. چون باید یک ویدیو بدم فقط راجب این حرف بزنم، و به درده ۹۹ درصد نمیخوره و هدف یک crash course نیست و اکثریت رو گیج میکنه. به جاش با ازمون خطا این فکتو ثابت میکنم.

@PyBackendHub

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

@PyBackendHub

یک چالشی تو ذهنم طراحی کردم بنظرم برای لایو و این ویدیو جالب میشه:

اپلیکیشن Rest APIبنویسید که این requirement هارو پوشش بده

۱. ردیابی زمان کارمندان:
• کارمندان باید بتوانند از اپلیکیشن به عنوان تایمر برای ردیابی ساعت‌های کاری خود استفاده کنند.
• اپلیکیشن باید اکشن‌های شروع کار، استراحت و پایان کار را پشتیبانی کند.

۲. نقش مدیر یا منابع انسانی برای تایید:
• باید یک نقش برای مدیر یا منابع انسانی (HR) وجود داشته باشد تا بتوانند زمان‌های رکورد شده توسط هر کارمند را تایید کنند.

۳. خروجی زمان کاری و حقوق:
• مدیر باید بتواند خروجی زمان‌های کاری هر کارمند را در یک بازه تاریخی مشخص و بر اساس حقوق ساعتی ذخیره شده در پروفایل کارمند دریافت کند.
• این خروجی باید با یک query قابل دسترسی باشد.

۴. ثبت پرداخت حقوق:
• پس از دریافت خروجی و پرداخت حقوق کارمند، مدیر باید بتواند این پرداخت‌ها را در سیستم ثبت کند.

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

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

نظرتون چیه؟
@PyBackendHub

مانی حرف قشنگی زد. گفت الان کلی بیزینس اومده بالا که صرفا ChatGPT Wrapperه و نه چیز دیگه! 👌

لایو یک شنبه هفته بعد، ۲۵ ام August به وقت ۸ شب تهران خواهد بود

یک نکته راجب این لایوی که میخوام بذارم بگم:
من قبلش اموزش fastapi و pydantic نمیدم. تو لایو هم دیگه توضیحات ابتدایی که تو دوره SQLAlchemy هست رو نمیدم. صرفا دارم با یک سری پرکتیس نوشتن api خوب، یک محصولیو کد میزنم.

راجب FastAPI و pydantic که جفتشون به شدت راحتن. تایپینگ و async بلد باشین ۱ روزه یاد میگیرین با خوندن داکیومنتش.
راجب SQLAlchemy سعی کنید تا اون موقع دوره من رو ببینید یا داکشو بخونید.

@PyBackendHub

همیشه قرار نیست چون یک چیزی یک فیچری داره پس حتما ازش استفاده کنید. باید دلیل منطقی باشه پشت استفاده از یک فیچر. و البته آگاه باشین از روش کارکردش.

این اشتباهو من اخیرا انجام دادم. تو دیتابیس postgresql چون یک لاجیک transactional داشتم بین دو تا دیتابیس , از two phase commit استفاده کردم. اینطوریه که شما یک بار کامیت میکنی و دیتابیس بهت میگه که کامیتت انجام میشه یا نه. و بعد باره دوم واقعا کامیت میکنید. (اینکه چرا لاجیک transactional داشتم بین دو تا دیتابیس خارج از کنترله من بوده)

حالا این مکانیزم تو لایه زیر چطوری کار میکنه؟
داره از prepare transaction استفاده میکنه برای اینکار. درواقع یک کامیت الکی هم مثل کامیت واقعی باید تو WAL نوشته شه. تو postgresql تو قسمت لاگ فایلاش یک فایلی هست به اسم pg_twophase که این رکورد هارو نگه میداره. اگه این وسط کرش شه دیتابیس, این لاگ ها باقی میمونه و وقتی که دوباره استارت شه prepare transaction ها restore میشن.
فایل ها دیلیت میشن اگه اون transaction که prepared بود رول بک شه یا کامیت شه.

حالا مشکل کجاست؟
اگه دیتابیس crash شه prepared transaction ها باقی میمونن. مثلا یک prepared transaction میتونه یک row ای رو lock کرده باشه. و این میتونه باعث deadlock میشه. یا میتونه تداخل ایجاد کنه برای VACUUM پی جی.

چرا؟ مگه transaction ها rollback نمیشن اگه دیتابیس کرش شه؟
چرا میشن, ولی از قصد اینطوری دیزاین شده که prepared transaction ها نشن. چون اگه کامیت فاز اول خورده, رول بک کردنشون ممکنه باعث inconsistent شدن اون یکی دیتابیسی شه که داره two phase commit میزنه. برای همین از قصد footprint میذارن از خودشون که db admin ها بیان چک کنند و اگه inconsistency وجود داره درستش کنند.

وقتی که دیتابیس رو ریستارت میکنید و ریکاور میشه دیگه پروسسی وجود نداره برای اون prepared transaction ها. چون کانکشن قطع شده و پروسس بسته شده. ولی لاگش هنوز اونجاست. خلاصه من داشتم از این فیچر استفاده میکردم بدون اینکه بدونم همچین اتفاقی ممکنه بیفته. و یک جایی دیدم یک سری لاک دارم تو postgresql که اصلا process id ندارن ولی transactional id دارن 😅 که با خوندن داکیومنت postgresql متوجه این چیزا شدم. و در آخر تصمیم گرفتم از این فیچر استفاده نکنم.

@PyBackendHub

Two general problems
یکی از سخت ترین مشکلات کامپیوتر ساینسه که حل نشده هست. و معمولا تو معماری ماکروسرویس خیلی زیاد دیده میشه. اگه نمیدونید چیه حتما توصیه میکنم ویدیو زیرو ببینید. یکی از بزرگ ترین cons های distributed system همینه.

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

@PyBackendHub

به دلیل سرما خوردگی لایو به یک شنبه یک هفته بعد موکول خواهد شد (۲۵ ام August).
متاسفانه نتونستم ویدیو آخر که راجب ماگریشن نویسی با alembic هست رو ظبط کنم. ایشالا اونم طی این آخر هفته انجام میدم وقتی بهتر شدم :)

سورس کدی که خوب تست نداره هر PR ای که زده میشه بهش، مثل رولت روسی (Russian roulette) میمونه 😁

@PyBackendHub

یه مدت سعی کردم هر ریپازیتوری که می‌سازم، تاجایی که ممکنه علاوه بر تست خوب، کاورج رو بالای ۹۵ نگه دارم. (اون ۵ درصدم چیزایی که بخاطر دیزاین بد نتونستم تست کنم و باید سریع ریفکتور شه)

اوایل ایگنور می‌کردم اون فایل‌ها یا خط‌ها رو تا Badge کاورج ۱۰۰ درصد خودنمایی کنه توی ریدمی ریپازیتوری، ولی خب چراا مرد؟ 😂

نمی‌دونید تست‌هایی که صد در صد کدبیس رو تست می‌کنن چقدر خوبن! فرض کن ۱۰۰۰ تا فیچر توی پروژه‌ات داری. یهو یه PR میاد. راحت با یه کامند می‌تونی مطمئن شی که این PR هیچ چیزی رو Break نمیکنه و (حداقل) از این بابت ایمنه. این دقیقا یه لول بعد از لاجیک برنامه هست. یعنی شما به توافق رسیدی که فلان PR باید زده شه، فلان بخش باید تغییر کنه. حالا این اتفاق افتاده و تست‌ها کارشون رو انجام می‌دن.

من اولش که TDD رو مطالعه می‌کردم اینجوری بودم که: هنن؟ چرا باید واسه هیچی (پروژه‌ای که خالیه) تست بنویسی؟ اصلا چی بنویسی؟ چیو می‌خوای تست کنی وقتی چیزی وجود نداره اصلا؟ ولی بعد که رفتم جلوتر، دیدم فرهنگ جالبی داره و خیلی UX رو می‌بره بالا. منظورم UXی هست که یه توسعه‌دهنده دیگه از ابزار شما به دست میاره. (فرضا ابزارتون یه کتابخونه هست)

راجع به TDD در Integration Testing و مشکلاتش، اینکه چرا زیاد جالب نیست هم بعدا یه پست می‌ذارم. :)) 🙌

یک نکته به حرفای صدرا اضافه کنم
قانون goodhart میگه که اگه یک measure (معیار) تبدیل به تارگت بشه، دیگه معیار خوبی نیست.

برای همین من اصلا چیزایی مثل تست کاوریج و استوری پوینتو اینا رو قبول ندارم. چون اینا measure نیستن هیچوقت همیشه تارگت میشن.

همین اتفاقی که واسه صدرا افتاد، شما به جای اینکه دنبال این باشین که تست بنویسید که یوزکیس و ادجکیس هارو کاور کنید، تست مینویسید که صد در صد شه 😅. برای همین قبلا گفتم تست کاوریج یک دروغه. خوبه که داشته باشیم، بدونیم عه فلان فایلمون اصلا کاور نشده، ولی target نیست! همین موضوع راجب استوری پوینت، استوری پوینت تارگت نیست!

تارگت باید این باشه: تست هایی که business requirement رو تست میکنن، که گارانتی میدن نرم افزار اون requirement رو satisfy میکنه طبق اون شرایط

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

@PyBackendHub

آیوکلاک (AioClock) یک فریم ورک برای scheduling و یا تسک منیجمنت هست و هر چیزی که هر فریم ورکی نیاز داره رو داخلش داره, مثل دپندسی اینجکشن و startup/stop ایونت, ساپورت از ماژولار کد نوشتن و ...

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

داکیومنت
گیتهاب


@PyBackendHub

اگه این لایبری براتون مفید بود، خوشحال می‌شم اگه بهش استار بدید. این کار به من انگیزه بیشتری برای توسعه و بهبود فریم‌ورک میده. از حمایت‌تون خیلی ممنونم 🙂 🙏

@PyBackendHub

نکنید اینکارو با همکاراتون 😂😂😂
@PyBackendHub

🚩 پایتون ۳.۱۳؛ فیچرهای جدید و دپریکیشن‌ها!


🔥 گیل (GIL) آپشنال: امکان بیلد گرفتن از CPython و غیرفعال کردن GIL. (در حالت عادی شما از GIL استفاده می‌کنید)

🔥 کامپایلر JIT: قراره در این پچ جدید، از یک کامپایلر just in time رونمایی شه که در یک سری از سناریوهای خاص، سرعت اجرای کدتون رو افزایش میده. این رو موقع بیلد گرفتن دستی از CPython میشه تنظیم‌ کرد و بصورت پیشفرض غيرفعال هست.

🔥 تایپ هینت IsType و ReadOnly: دوتا تایپ جدید به typing اضافه شده. در مقاله مثال زدم.

🔥 ساپورت از سیستم‌عامل iOS: یک رلیز قابل نصب روی iOS قراره در این پچ قرار داده بشه. هنوز خبری از رلیز اندروید نیست ولی گویا دارن روش کار می‌کنن. (چیزی که بعنوان پایتون روی دیوایس‌های اندرویدتون نصب دارید، رلیز لینوکس پایتون هست.)

🔥 بهبود Interaction: ارورها و تریس‌بک‌ها دقیق‌تر و هوشمندتر شدن. همچنین ارورها بصورت رنگی نمایش داده میشن.

🔥 بهبود REPL: کامندهای exit، help و quit تغییر کردن.

و کلی فیچر و امکانات جدید که توی ۵ دقیقه در مقاله زیر توضیح دادم به همراه مثال‌های ساده و قابل فهم:

🔗 https://blog.imsadra.me/python-313-new-features-deprecations


For more 👉 @lnxpylnxpy

بحث خوبی شد تو گروه, یکی پرسید که JIT چیه و چی کار میکنه دقیقا. ‌سعی میکنم خیلی ساده توضیح بدم که قابل درک باشه برای همه.

وقتی یه اسکریپت پایتونی رو ران می‌کنی، یه سری فایل با پسوند .pyc تو پوشه‌ی pycache ساخته میشه. اینا بایت کد هستن. بایت کد چیه؟ یه low level representation از کدی که نوشتی. بایت کد platform independent هست یعنی مهم نیست رو چی داری رانش میکنی. اما این بایت کد برای CPU قابل فهم نیست. CPU فقط ماشین کد رو می‌فهمه، یعنی همون باینری صفر و یک. پس وقتی بایت کد تولید میشه، PVM (Python Virtual Machine) میاد و بایت کد رو به ماشین کد تفسیر می‌کنه تا CPU بتونه اجراش کنه.

حالا JIT چیه؟ تبدیل بایت کد به ماشین کد زمان و منابع مصرف می‌کنه. JIT توی ران‌تایم این تبدیل رو انجام میده و ماشین کد رو توی حافظه نگه می‌داره تا دفعات بعدی که همون کد اجرا میشه، دوباره نیاز به تبدیل نباشه. اینکار رو فقط برای بخش‌هایی از کد که زیاد اجرا میشن (بهشون میگن hot loop) انجام میده. چرا؟ چون خوده ذخیره کردن این دیتا پرهزینست و مموری اشغال میکنه پس کل کد رو نمیاد اینکارو کنه. یعنی JIT Engine نگاه می‌کنه ببینه این بخش از کد اونقدری داره اجرا میشه که ارزش داشته باشه ماشین کدش رو نگه داره یا نه.

چرا کد پایتون مستقیم کد ماشین نمیشه؟ دلیلش اینه که PVM و Python runtime environment داره تو پایتون کارای دیگه‌ای هم میکنه تو ران تایم مثل مدیریت حافظه، لود کردن ماژول‌ها و پکیج‌ها و... این باعث میشه که پایتون انعطاف‌پذیر و راحت باشه، ولی خب به قیمت افت عملکرد در مقایسه با زبان های کامپایلری مثل C.


@PyBackendHub

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

یک مثال خیلی ساده بزنم شما تو پایتون میتونید یک سورس پایتونی از اینترنت دانلود کنید, و بعد از تابع eval() استفاده کنید که درجا رانش کنه! چطور این کد میتونه تبدیل به کد ماشینی بشه با یک کامپایل مستقیما؟ موقع کامپایل هنوز مشخص نیست چی قراره دانلود شه و ران شه! این اولین خاصیت پایتونه تو انعطاف پذیریش.

دومین خاصیش داینامیک تایپ بودنشه. شما یک فانکشن دارین foo(a,b,c). اگه شما تایپ ورودی این فانکشن رو نمیدونید, نمیتونید کامپایلش کنید. ولی اگه بدونید ممکنه چه تایپ هایی باشن, میتونید برای هر combination یک نسخه متفاوت کمپایل کنید. برای همینه که زبونای statically typed راحت کمپایل میشن به کد ماشین.

این دو خصوصیت باعث میشه پایتون نتونه به راحتی مستقیم تبدیل به ماشین کد بشه. پروژه هایی هستش که اینکارو میکنن ولی با static analysis و تکنیک های دیگه با لیمیتشن های خیلی زیاد. کلا زبون های داینامیک تایپ خیلی سخت از قبل میتونن تبدیل به ماشین کد بشن‌(اگه نگم غیر ممکن) ولی زبونای استتیک تایپ خیلی راحت تر اینکارو انجام میدن.

@PyBackendHub