کد به همچین شکلی تغییر کرد در نهایت که تو ویدیو توضیح دادم چه قدر فواید خوبی داره این سبک کد زدن:

def send_email(client: MailClient, rec_addr: EmailString, noscript: str, content: str):
    email = client.build_email_body(noscript, content, rec_addr)
    client.send_emails([email])

این کد به شدت امنه و فقط به شرطی fail میشه که یا خط دوم (ساخت ایمیل) اتفاق نیفته و یا تو خط سوم یک دفعه مشکل کانکشن پیش بیاد (کلاینت لاگین شده تو constructorاش و کاملا type safe هست)

@PyBackEndHub

اینم اضافه کنم Typestate به شدت بین rust developer ها محبوبه و توصیه میکنم بعد ویدیو مقاله زیر رو هم بخونید

https://cliffle.com/blog/rust-typestate/#what-are-typestates

@PyBackEndHub

از شکوه sqlalchemy اینه که شما میتونید compiler ORM رو extend کنید و خودتون compiler کاملا کاستوم بنویسید که اصلا تو لایبری وجود نداشته. نکته خفن ترش اینه که میتونید تعیین کنید این کامپایلر کاستوم شما تو هر دیتابیس (مثلا pg یا ‍sqllite) چطوری ران شه پس تستون رو همچنان بدون دوپلیکت کردن query ها رو sqllite ران کنید و به شدت سریعتر شه در عینه حال رو pg با استفاده از فانکشن های pg ران شه که پرفومنس بهتری داره.

واقعا این قابلیت عجیب ترین و خفن ترین چیزی بود که دیدم!

https://docs.sqlalchemy.org/en/20/core/compiler.html#synopsis

@PyBackEndHub

قول هفته ای دو ویدیو رو دادم. یک ویدیو اش میپردازم به دیزاین پترن. ویدیو دومو پیشنهاد بدین چه چیزی کار کنم تو کامنتا 👇👇 بعدش رای گیری میذارم بین گزینه ها.

تو ذهن خودم این پیشنهادا هست:
۱. انجام coding assigment های مصاحبه ها
۲. دوره faststream لایبری event streams با بروکر های مختلف
۳. دوره cloud instrumentation با opentelemetr
‍۴. دوره تایپ هینت و تایپینگ در پایتون

@PyBackEndHub

یک نظر سنجی میذارم. فقط یک جمع بندی میکنم قبلش:

۱. دوره اول احتمالا چند اپلیکیشن پایتونی (fastapi یا اپ های مختلف پایتونی لزوما میتونه استریم نباشه)‌مینویسم. که هر کدوم خودشون coding assigment یک شرکت برای backend engineer هست. سطح دوره نسبتا بالا خواهد بود. (حدودا ۵-۱۰ قسمت)
۲. یک لایبری هست که کارش اینه که کارتونو با بروکر راحت تر کنه. تو دوره سعی میکنم این لایبری رو استفاده کنم و باهاش اپ استریم پایتونی بنویسیم. (شبیه سلری ولی یوزکیسش فرق میکنه کمی. سلری تسک منیجره ولی این streamer هست). سطح دوره متوسط خواهد بود. (حدودا ۱۰-۱۵ قسمت)
۳. دوره ای که opentelemtry رو باهم دوره میکنیم. بست پرکتیس های instrumentation یک اپ wsgi یا asgi یا استریمینگ پایتونی رو بررسی میکنیم. و یک نمونه پیاده میکنیم مثلا یک فروشگاه اینترنتی که فعالیت کاربر داخلش کاملا instrument شده باشه.سطح دوره نسبتا بالا خواهد بود. (حدودا ۱۰-۱۵ قسمت)
۴. اگه پایتون کد میزنید و از تایپینگش خوب استفاده نمیکنید این دوره برای شماست. دوره ای که سری میزنیم به ماژول typing پایتون. با کل ماژول آشنا میشیم. با چند لایبری stdlib مثل دیتا کلس و چند لایبری external مثل pydantic آشنا میشیم و تخصصی بهشون میپردازیم. سطح دوره متوسط خواهد بود. (حدودا ۱۰-۱۵ قسمت)

@PyBackEndHub

با توجه به نتیجه نظرسنجی coding assignment رو انتخاب میکنم و باهم چالش چند شرکت رو انجام میدیم. Record این دوره از ۳ هفته آینده شروع میشه تا تو این مدت دوره تست هم به انتها برسه.

اگه چالش مصاحبه ای داشتین که براتون جالب بوده ممنون میشم با من اشتراک بذارین تا ایده بگیرم.
@Mani_nikou


@PyBackEndHub

نمیدونم چرا مغزم قفل شده
۱. موقع ریکورد ویدیو یادم میره صدا میکروفونو بیشتر کنم. برای همین باید دوباره ظبط کنم. و این باره ۳امه این دوهفته این اتفاق واسم میفته
۲. هنوزم وقتی پست میذارم تو کانال به جای @PyBackEndHub از @ManifoldsPython استفاده میکنم‌:)) . همه پستا ادیت خورده سره همین موضوع :))

@PyBackEndHub

این ‍ffpmeg چقدر خوبه :))

صداتون کمه؟ زیادش کنید
https://ffmpeg.org/ffmpeg-filters.html#Commands-53

ffmpeg -i input.mp4 -c:v copy -af "volume=10dB" output.mp4


نویز داره صداتون؟ نویز رو بگیرین
https://ffmpeg.org/ffmpeg-filters.html#afftdn

ffmpeg -i input.mp4 -c:v copy -af "afftdn=nr=20" output.mp4

چقدر فیچر داره!
@PyBackEndHub

در قسمت دهم پلی لیست دیزاین پترن
تو این قسمتChain of Responsibility رو بررسی کردیم. یک مثال پروداکشنی با کد بویلرپلیت هم نمایش دادم که نسبتا مثال پیچیده ای بود تا واقعا یوزکیس این دیزاین پترن رو درک کنید. در نهایت به نقاط ضعف و قوت این دیزاین پترن پرداختیم. اگه سوالی داشتین حتما زیره ویدیو کامنت کنید. برای حمایت ممنون میشم سابسکرایب کنید و داخل گیتهاب استار بدین به ریپو.


لینک ویدیو:
https://youtu.be/F0YyisF7Hq4

لینک گیتهاب دوره دیزاین پترن; جزوه و مثال های دوره همه اینجا ذخیره خواهند شد:
https://github.com/ManiMozaffar/design-101



@PyBackEndHub

“… Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. “ —Joe Armstrong, creator of Erlang progamming language

وقتی به یک موز نیاز دارین تو یک تابعی , یک گوریلا با موز ندین به اون تابع! 😁 مقاله مدیوم:
https://medium.com/codemonday/banana-gorilla-jungle-oop-5052b2e4d588

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

# BAD
def activate_user(user: User, session) -> None 
     session.execute(sa.update(User).where(User.id==user.id).values(is_active=True) 

# GOOD
def activate_user(user_id: UserId, session) -> None
     session.execute(sa.update(User).where(User.id==user_id).values(is_active=True)

به این قانون law of demeter هم میگن. هدفشم چیزی جز بهتر شدن reusability کدتون و راحت تر تست نوشتن نیست.


@PyBackEndHub

اختلال OTD خیلی رواج پیدا کرده این روزا! اگه نمیدونید چیه ویدیو رو ببینید 🤣
@PyBackEndHub

میخوام یک چیزه باحال نشونتون بدم

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

from enum import StrEnum, auto
from typing import Literal

from pydantic import BaseModel


class MammalsEnums(StrEnum):
    DOG = auto()
    CAT = auto()


class ReptiliaEnum(StrEnum):
    SNAKE = auto()


class Dog(BaseModel):
    name: Literal[MammalsEnums.DOG] = MammalsEnums.DOG
    legs: int = 4


class Cat(BaseModel):
    name: Literal[MammalsEnums.CAT] = MammalsEnums.CAT
    legs: int = 4


class Snake(BaseModel):
    name: Literal[ReptiliaEnum.SNAKE] = ReptiliaEnum.SNAKE
    length: int = 112

پستاندار همیشه legs داره. خزنده همیشه length داره. حالا میخواین یک switch case بذارین که اگه پستاندار بود راه برو و اگه خزنده بود بخز.
چیکار میکنید؟ یک راه OOPای اینه که شما یک schema بیس بسازین برای پستاندار ها. بعد همه پستاندار ها از اون ارث بری کنند. و بعد با isintance چک کنید. اما یک راه حل به سبک Rust میخوام بهتون یاد بدم 😁 که شبیه Traits هست.

from typing import runtime_checkable

@runtime_checkable
class MammalsTrait(Protocol):
    legs: int


@runtime_checkable
class ReptiliaTrait(Protocol):
    length: int


animal = Snake() # or any other animals

match animal:
    case MammalsTrait(): 
         print("This is Mammals")
    case ReptiliaTrait(): 
         print("This is Reptilia")
     case _:
         print("This is unknown animal")

متوجه شدین چی شد؟‌ در واقع switch case میاد Pattern Matching رو اجرا میکنه. و طبق اون میاد attr هارو مقایسه میکنه. در نهایت متوجه میشه که الان کدوم حالته! 😎 افت پرفومنس داره چون runtime checkable داره انجام میشه که تو لینک زیر میتونید بخونید جواب کامل تر گذاشتن. ولی درکل خیلی باحال بود.

https://discuss.python.org/t/is-there-a-downside-to-typing-runtime-checkable/20731/4

@PyBackEndHub

یک سوال میپرسم ببینم چند نفر بلدن اینو 😁تو بحث distributed system و fault tolerancy و دیتابیس.

شما دو سرویس داری, یک سرویس IAM که وظیفش نگه داری اطلاعات شخصی کاربر و پرمیشن هاست, و یک سرویس دیگه یک محصولیه که دارین. مثلا فکر کنید فروشگاه اینترنتی تو zone ایران هست. حالا کاربر میخواد ثبت نام کنه تو این فروشگاه. یک فرم هست. یک بخشیش میشه مربوط به سرویس فروشگاه. یک بخشیش مربوط به سرویس IAM میشه. پس دو تا سرویس نیازه با هم صحبت کنند به طریقی. و قراره کل این کار به صورت unit of work با transaction انجام شه.
درخواست از سرویس فروشگاه ارسال میشه به سرویس IAM و کاربر رجیستر میشه و کلی entity اضافه یا modify میشه برای اون کاربر به اون سرویس. حواستون باشه صرفا INSERT نیست و میتونه UPDATE هم باشه. کل query هایی که زدیم هم اوکیه و ران میشن. درخواست برگشت به سرویس فروشگاه و اینجام همه query های داخل transaction ران شد. ولی وقتی میخوایم کامیت کنیم به مشکل integrity میخوریم و کامیتمون fail میشه. حالا سوال اینجاست که چطور درخواستی که رفته به سرویس IAM و کاربری که ساخته شده رو rollback کنیم جوری که انگار اون اتفاق نیافتاده؟‌ چطور این مسئله رو حل میکنید؟

@PyBackEndHub

تو جواب ها اشاره کردن به بخش اول سوال. یک راه حل نسبتا کارگشا.
یک چیزی هست به اسم two phase commit. یعنی شما قبل اینکه بخوای یک transaction رو کامیت کنی میتونی یک اوکی بگیری از دیتابیس. دیتابیس بهت میگه این transaction تو اون لحظه ای که داری ازش میپرسی قابلیت کامیت شدن رو داره بدون مشکل یا نه. پس اون سرویس دوم باید two phase commit بزنه وقتی با سرویس اول داره حرف میزنه. و اگه اوکی بود ببره رو سرویس اول.

حالا مشکلی که وجود داره اینه که ممکنه اختلاف زمانی که تو two phase commit رخ میده ممکنه خودش باعث fail شدن transaction شه. یعنی state دیتابیس تو این چند ثانیه تغییر کرده باشه. ممکنه براتون سوال پیش بیاد باید چیکار کرد؟‌
هیچی باید تسلیم شد!

این بحث تو ریاضی بهش میگن Two Generals' Problem که هیچوقت حل نشده و ثابت شده حل نشدنیه.
یعنی چی؟‌ یعنی فکر کنید دو ژنرال میخوان به یک شهر حمله کنن با ۲ ارتش مختلف از ۲ نقطه مختلف. ژنرال اول به دوم میگه دو شنبه صبح حمله میکنیم. ژنرال اول نمیدونه ژنرال دوم پیامش رو دریافت کرد یا نه. برای همین باید صبر کنه که ژنرال دوم جواب بده. ژنرال دوم میگه باشه شنیدم. حالا ژنرال دوم نمیدونه که ژنرال اول پیامشو دریافت کرد یا نه. حالا باید صبر کنه دوباره ژنرال اول بگه شنیدم. و این loop تا انتها میتونه بره.

بنابر این قضیه, شما حتی میتونی درخواست HTTP بزنی که duplicate شه یعنی دو بار ارسال شه! چون acknowledge نشده.
واسه همین fault tolerancy همیشه تا یک حدی معقوله. از یک جا به بعد دیگه میشه مرز جنون :)) خوبه بهش فکر کنیم ولی یادمون نره وارد جنون نشیم 😁
@PyBackEndHub

Two general problem
@PyBackendHub

Automagic is a drug
امروز یکجا اینو خوندم… و خیلی باهاش موافقم.
مثلا ری اکت وقتی بیلد میگیرین همه کدارو میریزه تو main.js که خیلی آپتیمایز نیست و اینو باید هندل کنید برای پرفومنس بهتر که بهش میگن code split
و از یک طرف دیگه next js خودکار اینو انجام میده و هندل میکنه.

کسی که از nextjs استفاده میکنه و نمیدونه این چطوری کار میکنه، مثل یک دراگ براش میمونه و همیشه مانعی براش میشه که سمت جواب و این سوال هیچوقت نره.

همین موضوع تو بک اندم خیلی زیاده…
@PyBackendHub

یکی از مشکلاتی که اکثر برنامه نویسا دارن تو مدیریت دپندسیه! حالا لایبری جدید یا external service که قراره ازش استفاده کنن.

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

خب چیکار کنیم؟
اولین کاری که میکنید اینه که توتوریالشو میریزین دور. میرین داکیومنتشو خوب میخونید. متوجه میشین limitation هاش چیه. متوجه میشین سیستمش چطور کار میکنه. یک داکیومنت مختصر شده ازش میسازین و cons pro هاشو در میارین. مثلا یعنی چی؟

فکر کنید مثلا دارین یک external system اضافه میکنید. مثلا یک CRM. خب اول باید چک کنید چه limitation هایی داره؟‌ایا api داره؟‌ایا web hook داره؟ ایا share state به وجود میاد؟ هزینش چقدره؟ alternative هاش چیه؟ چطور اصلا کار میکنه؟ اصلا خوب کار میکنه؟!
بعد تو درجه دوم میرین گوگل میکنید و مقاله هایی پیدا میکنید که نقاط ضعفشو بیشتر گفته. ممکنه همه نقاط ضعفش تو داکیومنتش نباشه و یکم پنهان باشه. میبینید بقیه چه چالش هایی داشتن موقع کار کردن باهاش.
در نهایت بین آپشن ها یک لیست pro cons میسازین و تصمیم گیری نهایی رو میکنید.


اگه این کارو نکنیم چه اتفاقی میفته؟
بذارین مثال بگم. مثلا شما ندیدین این api limit احمقانه ای داره. بعد کلی روش کد میزنید. یک روزی سایز بیزنستون بزرگ تر میشه و حالا هرچی کد رو زدین باید undo کنید.


همیشه تو انتخاب دپندسی هاتون خیلی فکر کنید! من بعضا دیدم بچه ها میگن <کارفرما اینطوری گفته> یا <مدیر تیم با این بیشتر حال کرده>‌. اینا دلایل منطقی اصلا نیستن برای انتخاب یک دپندسی.

@ManiFoldsPython

وقتی فریلنسری😂 دوآپس هم اضافه کنید :))

@PyBackendHub

تو کامپیوتر ساینس یک مدل باگی داریم که از همه باگا سخت تره دیباگش و خدا نصیبتون نکنه :)) اسمش هایزنباگ هست.

In computer programming jargon, a heisenbug is a software bug that seems to disappear or alter its behavior when one attempts to study it

از این باگا دیدین تاحالا؟ باگی که reproduce نمیشه وقتی میخواین دستی reproduce اش کنید و اگه خیلی خوب تست بنویسید شاید بتونید با تست reproduce کنید تو حالت خیلی خوش بینانه. اگه براتون تاحالا اتفاق افتاده کامنت کنید و بگین چطوری دیباگش کردین 🤓

@PyBackendHub

یک بحث خیلی خوبی شد تو گروه, گفتم تو کانالم بهش اشاره کنم.
تو معماری Event driven هر وقت شما یک ‍periodic taskای دارین باید یک نکته رو بهش خیلی دقت کنید. این تسک پریودیک شما خیلی خیلی باید تا جایی که میتونه کم بار باشه. یعنی چی؟
فکر کنید یک تسک پریودیک دارین که میخواد هر ۱ ساعت یک بار چک کنه به یوزر هایی که خیلی وقته تو پلفتورم شما فعالیت نداشتن notification بزنه. اگه یک تسک بذارین که اینکارو انجام بده خیلی لاجیک اشتباهیه. به جاش باید دو تسک باشه. یک تسک دیتابیس رو query میزنه و یک سری یوزر آیدی میگیره. و میده به تسک دوم به صورت یک به یک. یعنی به تعداد یوزر آیدی ها میاد مسیج produce میکنه. تسک دوم با استفاده از اون user id هر دیتایی که بخواد میگیره و query میزنه به دیتابیس یا سرویس دیگه و نوتیفیکشن رو ارسال میکنه.

حالا چرا؟
چون تسک periodic خودش ذاتا state داره. مثل یک سرویس web socket. سرویس هایی که state دارن خیلی سخت ‍scale میشن. پس تا جایی که میتونید سعی کنید بخش state دار برنامتون رو کم کنید که scale برنامتون راحت شه.چرا؟ فکر کنید یک تسک دارین. اونوقت اگه scale کنید مجبور میشین دیتابیستون رو لاک کنید چون اگه نکنید ممکنه race condition بخورین و سرویستون همزمان به ۱ یوزر ۲ بار نوتیفیکشن بده.
اینطوری شما میتونی یک instance داشته باشی از سرویس periodic_producerاتون. و صد تا instance داشته باشین از سرویس notification_dispatcher تون. بنابراین اگه شما تو یک ساعت لازم باشه به ده هزار نفر نوتیف بدین میتونید بدید. یا اگه سرویس نوتیفتون یک لحظه قطع شه همه با هم fail نمیشن. و میره تو dead letter queue و یا میتونه حتی دوباره retry هم بشه.


@PyBackendHub