سومین قسمت از پلی لیست SQLAlchemy منتشر شد!

در این بخش به تعامل بین Engine و Query می‌پردازیم. بررسی می‌کنیم که چگونه می‌توانیم یک کوئری را اجرا کنیم، نتایج حاصل از دیتابیس را پردازش کنیم، و چگونه با تغییر در نحوه‌ی کامپایل کوئری، می‌توانیم بر خروجی تاثیر بگذاریم. با پرداختن به این موضوع هابه درک بهتری از تایپ های SQLAlchemy میرسیم و داکیومنت شلوغ و به هم ریخته اش رو بهتر میتونیم بخونیم.

لینک ویدیو:

https://youtu.be/qDtB--xlbX0

این دوره شامل ۶ قسمت هست. این دوره ۶ قسمته شما رو برای استفاده از SQLAlchemy داخل پروژه هاتون و پروداکشن آماده میکنه و به شما درک بنیادی و کافی از SQLAlchemy میده که دیگه درک این ORM براتون خیلی سخت نباشه.

@PyBackendHub

قسمت چهارم امشب نمیاد, فردا شب میاد.
تا الان نیمی از دوره گذشته و حدود ۱ ساعت و ربع بوده 😁 اگه بتونم۶ قسمت رو در نهایت تو ۲ ساعت و نیم جمع کنم خیلی خوب میشه. 👌 امیدوارم اینطوری کمکی کرده باشم که کسایی که بخاطر پیچیدگی و داکیومنت بد نمیرفتن سمتش, یک تجدید نظر کنند.
@PyBackendHub

#فان_فکت

〰️〰️〰️〰️〰️〰️
© @DjangoEx

چهارمین قسمت از پلی لیست SQLAlchemy منتشر شد!

در این بخش ابتدا به انواع داده‌ها (Types) در SQL و نحوه تعریف و شخصی‌سازی آن‌ها در SQLAlchemy می‌پردازیم. سپس به بررسی روش‌های مختلف ساخت جداول (Tables) و استفاده از type registry خواهیم پرداخت. در نهایت، نحوه ایجاد Foreign Key، انجام عملیات query و ّInsert در جداول را تمرین خواهیم کرد.

لینک ویدیو:

https://youtu.be/wHV98-DZoZg

این دوره شامل ۶ قسمت هست. این دوره ۶ قسمته شما رو برای استفاده از SQLAlchemy داخل پروژه هاتون و پروداکشن آماده میکنه و به شما درک بنیادی و کافی از SQLAlchemy میده که دیگه درک این ORM براتون خیلی سخت نباشه.

@PyBackendHub

یک وقتا به دلایل خیلی منطقی مجبوریم cast کنیم. مثلاً تایپی که از لایبری برمی‌گرده اشتباهه. مثلاً فرض کنید لایبری تایپش داره میگه int برمی‌گرده ولی در واقع float هست. هیچوقت همچین کاری نکنید:

foo = library_func()
bar = typing.cast(float, foo)

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

foo: int = library_func()
bar = typing.cast(float, foo)

فرقش چیه؟ شما داری خودتو تایید می‌کنی که من می‌دونستم این int برمی‌گردونه. ولی به float اومدم cast اش کردم. اینطوری اگر یک روزی signature اون تابع عوض شد و تبدیل شد به استرینگ مثلاً، کد شما یک چیزی که قصد نداشتی (استرینگ) رو به یک چیز دیگه cast نمی‌کنه.

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

@PyBackendHub

پنجمین قسمت از پلی لیست SQLAlchemy منتشر شد!

در این بخش میپردازیم به مفهوم ORM. یاد میگیریم چطور میتونیم آبجکت ‍ORM بسازیم, چطوری راحت تر با دیتابیس کار کنیم. متوجه میشیم Session چیه. چه فرقی با انجین داره. به مفاهیم Expire, expunge, refresh و attach داخل سشن میپردازیم. رفتار سشن رو تو حالت های مختلف تست میکنیم. بالاخره با این ویدیو SQLAlchemy رو تموم کردیم و ویدیو بعدی فقط راجب ماگریشن نویسیه 😍

لینک ویدیو:

https://youtu.be/qH1B9xkfDNA

این دوره شامل ۶ قسمت هست. این دوره ۶ قسمته شما رو برای استفاده از SQLAlchemy داخل پروژه هاتون و پروداکشن آماده میکنه و به شما درک بنیادی و کافی از SQLAlchemy میده که دیگه درک این ORM براتون خیلی سخت نباشه.

@PyBackendHub

یک ویدیو اخر داریم 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