نسخه ۲.۷ پایندانتیک اومد که خیلی فیچر های جالبی داره:

https://blog.pydantic.dev/blog/2024/04/11/2-7-release/#new-features


@PyBackendHub

نسخه بعدی لایبری aioclock منتشر شد. 🚀

تو این نسخه شما میتونید مشخص کنید تسکتون چند بار ران شه. مثلا من میخوام تسکم هر ۵ ثانیه یک بار ران شه ولی کلا میخوام ۱۰۰۰ بار ران شه.

from aioclock import AioClock, Every

app = AioClock()

@app.task(trigger=Every(seconds=5, max_loop_count=1000)
async def some_task(): 
    print("This would only run for 1,000 times!")

با تشکر از مهدی و امیر عارف بابت contributeشون. برای حمایت میتونید استار بدید یا contribute کنید. اگه فیچری مد نظرتون هست خوشحال میشم تو ریپو یا تو تلگرام بهم بگید.

https://github.com/ManiMozaffar/aioclock


@PyBackendHub

سلام خدمت دوستان. حدودا ۱ سال از تاسیس کانال میگذره. برای همین این پستو میذارم که پین بمونه تا سال دیگه😁

اولا که من هیچ تبلیغی انجام نمیدم. لطفا برای این موضوع مراجعه نکنید.
دوما چند تا از دوستان این هفته لطف داشتن از من بخوان که منتورشون بشم و هزینه بدن. من منتورشیپ انجام نمیدم چون متاسفانه وقتشو ندارم, ولی هم سایت رایگان هست برای اینکار و هم اینکه من تو گروه و داخل پی وی جواب میدم و کمکی از دستم بیاد حتما انجام میدم.
سوما بهتره سوالتون رو تو گروه بپرسید چون اونجا افراد بیشتری هستن و نظرات من ممکنه bias باشه و یا اشتباه باشه. ولی باز اگه به هر دلیلی نمیخواستین داخل گروه بپرسید داخل پیوی هم پاسخ میدم.

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

من مانی هستم. از سال ۲۰۲۰ برنامه نویسی رو به طور حرفه ای شروع کردم. قبلا پروداکت داشتم و به صورت تیمی روش کار میکردیم.البته الانم هستم ولی دیگه کاره تمام وقتم نیست. الان ۲ سالیه داخل یک استارت آپ آلمانی به عنوان مهندس نرم افزار کار میکنم و برلین زندگی میکنم. تجاربم بیشتر سمت بک اند, فرانت, تست نرم افزار (QA) و وب اسکرپ, و کمی آپریشن (ci/cd, observation, orchestration) هست. زبونی که باهاش کار میکنم پایتون و تایپ اسکریپت هست و در حال یادگیری rust هستم.

یوتیوب من:
https://www.youtube.com/@GitOverHere

لینکدین من:
https://www.linkedin.com/in/manimozaffar/

گیت هاب من:
https://github.com/manimozaffar


@PyBackendHub

گلچین مطالب کانال.

۱. رزومه نویسی و کار یافتن

دوره رزومه نویسی و رشد در مسیر شغلی

چند درصد آگهی رو خوب بلدیم رزومه بفرستیم؟‌راهنما عملکرد بهتر در مصاحبه ها

قدم های مورد نیاز برای مهاجرت

ریپازیتوری آموزش رزومه نویسی با بیش از ۲۰۰ استار

معرفی ریسورس برای مصاحبه و بهتر کردن رزومه


۲. دوره های آموزشی در یوتیوب

دوره SQLAlchemy

دوره دیزاین پترن

دوره تست نویسی



این پست در آینده ادیت خواهد شد.

@PyBackendHub

این پست رو تو لینکدین دیدم. دوست دارم جوابتون رو بدونم. <چالش طراحی>
فرض کنید قراره سرویسی بنویسید که پلتفرم آنلاین رزرو و مدیریت کلاس درس باشه. حالا به این فکر کنید که یه کلاس درس از زمانی که خریداری میشه و در وضعیت «در انتظار برگزاری» قرار میگیره، باید بصورت خودکار وضعیت هاش توسط سیستم مدیریت بشه، مثلا وقتی کلاس خواست برگزار بشه بره در وضعیت «در حال برگزاری»، بعدش بشه «خاتمه یافته»، بعدش که کمیسیون استاد حساب شد بشه «تسویه شده» تصور کنید که ممکنه روی مقیاس بالا مثلا در ساعت اوج حدود ۵۰ هزار یا بیشتر کلاس برگزار بشه. تصور کنید کلاس ها به صورت آنلاین برگذار میشه. از چه ابزارها و معماری ای استفاده میکنید که پاسخگو نیاز بیزنس باشه؟

@PyBackendHub

نسخه 0.5 پای‌اکشن هم رلیز شد! 💫

پای‌اکشن یه ابزاره متن‌بازه که اجازه می‌ده با استفاده از پایتون، گیت‌هاب اکشن بسازید!

توی این رلیز کلی اتفاق افتاده. پروژه دیگه یه تمپلیت ساده نیس و تبدیل شده به یه پکیج پایتون. علاوه‌بر بهترشدن داکیومنت و ساختار، یه فیچر خیلی خفن هم اضافه شده که واقعا استفاده از GitHub Issues رو یه لول می‌بره بالاتر!

این فیچر این قابلیت رو به شما میده تا از Issue Form گیت‌هاب بعنوان ساید فرانت اپ های پایتونتون استفاده کنید! این فیچر الان قابل استفاده هست و توتوریالش هم توی داک‌ها قرارداده شده.

یک مثال که می‌تونید با پای‌اکشن پیاده کنید: فرض کنید که یک ریپو NLP دارید که برای Text Summaraization استفاده می‌شه و می‌خواید مردم این قابلیت رو داشته باشن که تستش کنن. به راحتی می‌تونید ساختاری رو طراحی کنید که هرشخص بتونه یک ایشو باز کنه و در ایشو، از ابزار شما استفاده کنه. (همه‌چیز اتوماتیک اتفاق میوفته)

💅 Issue Form feature: pyaction.imsadra.me/tutorial/#issueform

🟣 PyAction repo: github.com/lnxpy/pyaction

یک چالش رو به رو شدم یکی از دیتابیس های پروداکشن ۳ ترابایت دیتا داخلش بود. گرچه کل row هاش رو هم ۱۰۰ گیگ هم نمیشد. و باعث میشد فضای سرور پر شه و دیتابیس بیاد پایین.

میدونستین وقتی یک row رو دیلیت میکنید فضا داخل دیتابیس PostgreSQL خالی نمیشه؟ بخوام درست تر بگم, فضا همچنان توسط تیبل reserve شده. برای همینه که میگن بهتره تو postgresql نیاین فایل byte بزرگی رو ذخیره کنید. البته تو کیس من دیتا بایت بزرگ نبود, صرفا دیتا زیاد بود. و دلیلش هم به خاطر مدل MVCC دیتابیس هست.

دو راهکار وجود داره برای اینکار. اولیش استفاده از VACUUM خوده دیتابیسه.😎 فکر کنید دوستتون زنگ بزنه بپرسه داری چیکار میکنی, بگی دارم جارو میکنم :))

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

@PyBackendHub

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

یک فیلم جذاب از آرمین که داره rye رو معرفی میکنه. توصیه میکنم حتما ببینید.
داخل یک ویدیو تو کانال یوتیوبش هم یک walk through رو سورس کد و نحوه کارکرد rye رو نشون میده.
پ.ن: فقط صدای کیبورد آرمین >>>. البته واسه ویدیو. وگرنه همکارم بود استعفا میدادم 🤣(شوخیه دوستان جدی نگیرین😅)

@PyBackendHub

#otel

بر پایه opentelemetry ابزار بعدی pydantic هم توسعه داده شد 🔥🔥

همونطور که تو رودمپشون بود قرار بود سولوشنی بدن که دیگه نیازی نباشه شما خیلی درگیر observability بشی داخل کدتون و اینترفیس developer friendly تر و تجربه بهتری بهتون بدن.

دقایقی پیش logfire سولوشن جدید pydantic اوپن سورس شد. توصیه میکنم حتما یک سر بزنید بهش
https://docs.pydantic.dev/logfire/

@PyBackendHub

#otel

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

اول بذارین توضیح بدم observation یعنی چی. ما توی devops دو آپریشن داریم که شبیه همن و گاها باهم اشتباه گرفته میشن. اولیش مانتورینگه. مانیتورینگ به پروسه ای میگن که دیتا کالکت میشه از سرویسی, و یک ریپورت از سلامت سرویس بر اساس metric های مشخصی که برای سلامت سیستم رو نشون میدن و کالکت شدن ساخته میشه. یعنی چی؟ مثلا تعداد ریسپانس های 5xx در ۲۴ ساعت گذشته. یکی از شناخته شده ترین ابزار برای اینکار prometheus هست. observability به پروسه ای میگن که رویکرد تحقیقاتی داره. یعنی دنبال این نیست که بگه چقدر ریسپانس 5xx وجود داره. دنبال دلیل وجود این ریسپانس هاست. چرا الان این درخواست تو پروداکشن ارور ۵۰۰ میده؟ خوندن کل لاگ سرویس قدیمی ترین و ابتدایی ترین راهکار بود.

وقتی بک اند پیچیده تر شد, دیگه خوندن لاگ واقعا کارساز نبود. شما فکر کنید در لحظه ۱۰۰ درخواست داره میاد براتون. چطور میخواین لاگ هارو بخونید؟ تو قدم بعدی لاگ های هر درخواست رو جدا کردن. ولی بازم کار ساز نبود تو دنیای distributed system. چون مثلا یک سرویس ۱ با سرویس ۲ داشت حرف میزد. ورودی که میداد بهش درست نبود. سرویس ۱ صرفا یک exception میگرفت که سرویس ۲ استتوس ۵۰۰ داده. و این کافی نبود برای اینکه متوجه شیم چه اتفاقی میفته.

سولوشن های زیادی اومدن تو مارکت. از قبیل sentry که شاید اسمشو شنیده باشین. یا datadog و لوکی و ... . اینقدر این سولوشن ها زیاد شدن و هر کدوم ساز خودشون رو میزدن. نمیشد راحت از این سولوشن سوییچ کرد به اون یکی. نمیشد مزایا دو سولوشن رو همزمان داشت. و learning curve سختی داشت اگه میخواستین سوییچ کنید از یکی به یکی دیگه.

اینجا بود که CNCF (Cloud native compute foundation) یک پروژه جدید رو استارت زد. همون فاندیشنی که کوبر و prometheus و خیلی ابزار های تحت کلاد رو ساخته. اومد یک پروتکلی ساخت به اسم opentelemetry.
یعنی چی پروتکل؟ یعنی گفت sentry جان من برام مهم نیست شما لاگ رو چطور ذخیره میکنی یا پردازش میکنی اینترنالی. شما باید span داشته باشی. metric داشته باشی. و trace. و دقیقا تعریف کرد که اینا چین. یعنی اومد گفت اینترفیس خارجی یک سیستم observability چطور باید باشه؟ چون در نهایت همه این سیستما شبیه هم بودن. و حالا چون همشون داشتن از یک پروتکل خاصی پیروی میکردن شما میتونستی راحت از سولوشن یک سوییچ کنی به سولوشن دو. مثلا شاید مثالشو دیده باشین که تو سیستم فایل استوریج بعضی استوریجا s3 compatible هستن. اینم دقیقا شبیه همونه.

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

خوده opentelemetry داشبورد خاصی نداره. صرفا یک سری exporter تو زبون های مختلف داره که میتونید تو گیتهابش ببینید. مثلا برای fastapi و جنگو لایبری داره. ولی پیاده سازی و داشبوردی نداره برای نشون دادن این اطلاعات. چون همونطور که گفتم در نهایت فقط یک پروتکل و specification هست. از طرفی سولوشن های داشبورد زیاده.یک سرچ کنید میرسید بهش. مثلا من خودم signoz استفاده میکنم.

خب همه اینارو گفتم. حالا نقش logfire این وسط چیه؟ logfire همون لایبری های اکسپورتر opentelemetry رو اینترفیسشو بهتر کرده. و با pydantic هم اینتگریتشون کرده. و یکم utilty اضافه کرده. این قسمت exporter اش هست که اوپن سورسه.
یک قسمت داشبورد هم داره که هنوز اوپن سورس نشده. و مشخص نیست که بشه یا نه. ولی فعلا رایگانه.


اینجا قشنگ صفر تا صد توضیح داده. بعد توضیح های من حالا خیلی بهتر متوجه میشین.

@PyBackendHub

یک سوال خوبی هم که پرسیدن این بود که چی سره sentry و datadog و اینا اومد.

ببینید اینا خودشون یک sdk داشتن. هنوزم دارن. منتهی اومدن sdk هارو ریفکتور کردن که با opentelemetry protocol هم سازگاری داشته باشه. ولی اگه sdk ها ۱۰۰ تا فیچر داشتن, اگه سوییچ کنید رو پروتکل اوپن تلمتری, اون موقع ممکنه ۲۰ تا فیچر sdk هاشو از دست بدید. چرا؟‌ چون opentelemetry هنوز نتونسته چهارچوبی بسازه که صد در صد فیت باشه واسه همه این سولوشن ها. ولی اگه بخواین اون ۲۰ تا فیچر رو فاکتور بگیرین, مثلا شما میتونید sdk سنتری رو استفاده کنید با داشبورد سیگنوز. یا sdk لاگ فایر با داشبورد سنتری. یا sdk خوده اوپن تلمتری با datadog. و خوبی opentelemetry هم دقیقا همینه. که شما هر sdk که دوست دارین با هر داشبوردی میتونید استفاده کنید.
منتهی همونطور که اشاره کردم ممکنه یک وقتا sdk ها در برابر داشبورد خودشون یک سری فیچر های اضافه و خارج از پروتکل opentelemetry داشته باشن.

@PyBackendHub

بنظرم دانش تو زمینه بک اند به ۳ قسمت تقسیم میشه، که خیلی مهمه سه تاشو داشته باشیم.

مثلا فکر کنید میخواین یک rest api بنویسید به همراه تست.

قسمت اول بلد بودن فریم ورکی برای اینکاره. مثل پای تست و فست. ولی بلد بودن اینا کافی نیست فقط

قسمت دوم، فلسفه پشت اون موضوعه. که دونستنش خیلی ضروریه. مثلا تو بحث api نویسی کی باید یک اندپوینت post باشه کی put کی patch و .. . یک api چطور باید باشه. Rest api چی داره که بهش میگن restful. و …. یا مثلا برای تست نویسی چی باید تست شه. چقد باید تست نوشته شه. چی باید ماک شه. چی نباید ماک شه.

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


@PyBackendHub

برداشت اشتباه نکنید از حرفم، من نگفتم فقط باید نوشتن api و تست بلد باشین. گفتم سه سطح یادگیری برای هرچیزی هست.
تو یک سطح شما یوزر‌ خوبی هستی با اتکا به یک ابزار خاصی.
تو یک سطح شما میتونی یوزر‌خوبی باشی حتی بدون اتکا به اون ابزار خاص. و میتونی درک کنی که چطوری کار میکنه.
و تو یک سطح شما نه تنها یوزر‌خوبی هستی، بلکه تصمیم گیرنده خوبی هستی چون چرا ها رو درک میکنی.

@PyBackendHub

👌👌
بحثش بود دیروز تو گروه که یکی از دوستان دنبال مدلی از business analytic دیتا بود و میخواست خودش اینو حساب کنه و یک فیچر جدید بذاره
ولی حقیقت واقعا نیازی نیست. اگه observationتون خوب باشه, خیلی وقتا همون دیتا میتونه برای بیزنس خیلی مهم و کریتیکال بشه.

@PyBackendHub

یک سایتی هست, که ۱۲ فاکتور مهم برای اپلیکیشن های software-as-a-service رو نوشته. و توصیه میکنم بخونیدش حتما.

https://12factor.net
تو قسمت کانفیگ یکیش اینه:
Config varies substantially across deploys, code does not.

دقت کنید ببینید چطوری تغییر کرد. یعنی چی دقیقا این؟

یعنی این پترن اشتباهه:
deploy_env = "local" / "dev" / "staging" / "prod"

اپلیکیشن شما با تغییر deploy_env نباید تغییر کنه. اپلیکیشن شما یک کانفیگ داره که آگاه نیست که قرار کجا ران شه. پس چیزایی مثل prod.env اشتباهه. دلیلش هم تو سایتش نوشته:
In a twelve-factor app, env vars are granular controls, each fully orthogonal to other env vars. They are never grouped together as “environments”, but instead are independently managed for each deploy. This is a model that scales up smoothly as the app naturally expands into more deploys over its lifetime.

پس شما هرچیزی که میخواین کانفیگ شه رو کانفیگ پذیر میکنید. دیگه اینکه debug=false باشه یا true تو deploy برمیگرده به آپریشن. بهتره مقدار دیفالت نذارین اگه چیزی که دارین کانفیگ میکنید خیلی مهمه.

و نکته بعدی که بسیار مهمه, پوش کردن .env به ریپو نباید اشکالی تو ci/cd شما بکنه. حواستون باشه چه فایل هایی رو دارین شیپ میکنید به پروداکشن. فایلی مثل .env فایلی نیست که شیپ کنید. اینکه چطور env variable ها ساخته میشن روش های مختلفی وجود داره, ولی ساختنش با یک فایل .env و اضافه کردنش به گیت ایگنور اصلا روش منطقی نیست. چون تو scale شما خیلی اذیت میشین. هر scale horizontally که بخواین انجام بدید باید ssh کنید به سرور و اون فایل ‍.env رو اضافه کنید 🤦‍♂️
تجربه توسعه هم بد میکنه. روش های زیادی برای انجام این کار هست. مثل استفاده از kustomize یا secret manager کلادی که ازش استفاده میکنید یا hashicorp vault یا .... . اینکه چه روشی انتخاب میکنید مهم نیست. مهم اینه که تو حالت اول stateless باشه یعنی بتونید خیلی راحت scale horizontal انجام بدید. در درجه دوم اینکه implicit نباشه(مثل deploy env) و کاملا مشخص باشه چی داره کانفیگ میشه. و در درجه آخر و حالت خیلی ایده آل یک حالت versioning و ورژن کنترل داشته باشه.

@PyBackendHub

یک ویدیو خیلی جالب از کنفرانس pgconf در سال پیش که یک message queue با راست رو postgresql نوشتن.

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

حتما توصیه میکنم ببینید. چون خیلی نکات قشنگی و query های قشنگی داره این ویدیو.

@PyBackendHub

یک پروژه خیلی ساده و کم حجم نوشتم که چطوری pub/sub رو با ردیس پیاده کنیم طوری که تایپ سیف باشه. تایپ سیف بودن این پروژه, هدفش بود. همین پترن رو میتونید هرجای دیگه ای هم اپلای کنید.

واسه sub هم از لایبری خودم aioclock استفاده کردم که ببینید چقدر سادست استفاده ازش 😁
https://github.com/ManiMozaffar/typed-redis

@PyBackendHub

ایده برای aioclock دارین؟ ممنون میشم کامنت کنید.

اگه مشتاقین aioclock چیه, یک لایبری هست که وظیفه اش scheduling عه با استفاده از asyncio پایتون و سینتکس جذاب و declartive که هم دپندسی اینجشکن مثل فست داره و هم event های مختلف مثل استارت آپ و شات داون.

https://github.com/ManiMozaffar/aioclock

@PyBackendHub

سوال پرسیدن که هدف این کد چیه چیو داره حل میکنه؟
ببینید یک اصلی تو کد نویسی هست که کد شما هرچی invariant کمتر داشته باشه بهتره چون احتمال خطا کمتره. و شما تست کمتری مینویسی. اینو بارها تو کانال اشاره کردم. که دو تا از بهترین روش ها برای رسیدن به این یکی fully typed بودنه کده (مثل کد ریپازیتوری که به اشتراک گذاشتم) و یکی type state هست یعنی استیت component شما تو یک تایپ encode شه. این دو تا کمی متفاوتن. لایبری fastexchange که اوپن سورس کردم تایپ استیت هست چرا چون state currency تو تایپینگ انکود شده. ولی این پروژه فولی تایپه نه تایپ استیت.

من الان تو چنل "foo" انتظار دارم یک data خاصی ارسال شه چه گارانتی هست که من تو چنل فو چیز اشتباهی نفرستم؟ این صورت مسئله هست. راهکارش چیه؟ من لایبری رو wrap میکنم. دیگه موقع پابلیش فورس میکنه که تایپ درستی بدم برای چنل با استفاده از discriminated union میزنم رو چنلج های مختلفی که ساپورت میکنه برنامم. و همینطور موقع گرفتن مسیج هم فورس میکنه که همون تایپ رو بگیرم. دیگه بایت و دیتا خام نمیگیرم.

این باعث میشه:
۱. دیتا رو تو چنل اشتباهی نفرستم
۲. تو چنلی دیتا اشتباه نفرستم

و تجربه توسعه رو بهتر میکنه.

راجب تایپ استیت هم که قبلا زیاد صحبت کردم ولی اگه اولین باره میشنوید توصیه میکنم این پست رو بخونید

@PyBackEndHub