Forwarded from Python BackendHub
تو گروه واقعا بحث های جالبی میشه دم همه گرم که فعالن 🙌 بحث کد فانکشنال و OOP شد دیشب که بحثش به امروزم رسید. من همیشه فانکشنال رو ترجیح میدم به OOP مگه طبق ویدیویی که گذاشتم چند روز پیش بخوام یا
۱. استیت ذخیره کنم
۲. بخوام abstraction انجام بدم
و من کاملا با این موافقم! ویدیو مربوطه:
https://www.youtube.com/shorts/oIyq0q5Q7eo
فانشکنال کد زدن به این معنی نیست که شما صرفا فانکشن بنویسی. وقتی فانکشنال دارین کد میزنید حتما باید declarative باشه نه imperative. و این موضوع باعث میشه
۱. فانکشن خیلی راحت تر reusable باشه
۲. دیباگش راحت تر شه
۳. تستش راحت تر شه
۴. قابل پیشبینی تر باشه
۵. باگ کمتری داره
حالا میخوام بحث declarative و imperative رو یکم باز کنم براتون که متوجه شین. یک کد basic رو میبینم با OOP
تو declarative شما کد میزنی باید هدفت رو این باشه که به چی میرسی نه اینکه چطور میرسی.
مثلا
همینو میتونی با ۳ تا فانکشن هم بنویسی درسته؟ اسمش فانکشنال هست؟ قطعا نه. چون این Imperative هست. تستش هم سخته. یعنی اینطوری نباید بشه:
به جاش باید اینطوری شه:
بازم شاید مثال خیلی خوبی نباشه چون نمیشه تو یک پیام تلگرامی کامل باز کرد موضوعو. بخوام خیلی خلاصه بگم بزرگ ترین pros و cons کد imperative اینه که ساید افتکت داره. ایا تستی که مینویسید همه اینا رو تست میکنه؟ ایا ۱۰۰درصد خیالتون راحته این وسط ساید افکتی به وجود نمیاد که باعث شه یک باگی تو برنامتون درست شه؟
do_this()
do_that()
then_this()
then_that()
در آخر اشتباه برداشت نکنید من دشمن OOP نیستم. 😁 منتهی ترجیح میدم هرچیزیو به جای خودش استفاده کنم با دونستن drawback هاش.
یک ویدیو کوتاه مربوطه از Arjan که نظرشو راجب فانکشنال و OOP گفته:
https://www.youtube.com/shorts/lEVu7_v2pbk
و یک مقاله خیلی خیلی خوب راجب functional که توصیه میکنم حتما بخونید:
https://medium.com/@olxc/switching-from-oop-to-functional-programming-4187698d4d3
@ManiFoldsPython
۱. استیت ذخیره کنم
۲. بخوام abstraction انجام بدم
و من کاملا با این موافقم! ویدیو مربوطه:
https://www.youtube.com/shorts/oIyq0q5Q7eo
فانشکنال کد زدن به این معنی نیست که شما صرفا فانکشن بنویسی. وقتی فانکشنال دارین کد میزنید حتما باید declarative باشه نه imperative. و این موضوع باعث میشه
۱. فانکشن خیلی راحت تر reusable باشه
۲. دیباگش راحت تر شه
۳. تستش راحت تر شه
۴. قابل پیشبینی تر باشه
۵. باگ کمتری داره
حالا میخوام بحث declarative و imperative رو یکم باز کنم براتون که متوجه شین. یک کد basic رو میبینم با OOP
تو declarative شما کد میزنی باید هدفت رو این باشه که به چی میرسی نه اینکه چطور میرسی.
مثلا
class NumberProcessor:
def __init__(self, numbers):
self.numbers = numbers
def filter_even(self):
self.numbers = [n for n in self.numbers if n % 2 == 0]
def square(self):
self.numbers = [n ** 2 for n in self.numbers]
def process(self):
self.filter_even()
self.square()
return self.numbers
همینو میتونی با ۳ تا فانکشن هم بنویسی درسته؟ اسمش فانکشنال هست؟ قطعا نه. چون این Imperative هست. تستش هم سخته. یعنی اینطوری نباید بشه:
def process_numbers(numbers):
even_numbers = []
for number in numbers:
if number % 2 == 0:
even_numbers.append(number)
squared_numbers = []
for number in even_numbers:
squared_numbers.append(number ** 2)
return squared_numbers
به جاش باید اینطوری شه:
def filter_even(numbers):
return filter(lambda x: x % 2 == 0, numbers)
def square(numbers):
return map(lambda x: x ** 2, numbers)
بازم شاید مثال خیلی خوبی نباشه چون نمیشه تو یک پیام تلگرامی کامل باز کرد موضوعو. بخوام خیلی خلاصه بگم بزرگ ترین pros و cons کد imperative اینه که ساید افتکت داره. ایا تستی که مینویسید همه اینا رو تست میکنه؟ ایا ۱۰۰درصد خیالتون راحته این وسط ساید افکتی به وجود نمیاد که باعث شه یک باگی تو برنامتون درست شه؟
do_this()
do_that()
then_this()
then_that()
در آخر اشتباه برداشت نکنید من دشمن OOP نیستم. 😁 منتهی ترجیح میدم هرچیزیو به جای خودش استفاده کنم با دونستن drawback هاش.
یک ویدیو کوتاه مربوطه از Arjan که نظرشو راجب فانکشنال و OOP گفته:
https://www.youtube.com/shorts/lEVu7_v2pbk
و یک مقاله خیلی خیلی خوب راجب functional که توصیه میکنم حتما بخونید:
https://medium.com/@olxc/switching-from-oop-to-functional-programming-4187698d4d3
@ManiFoldsPython
YouTube
💡 When to Use Functions and Classes
People always ask me when to use functions and when to use classes. In this short, I’ll give you a short explanation and examples that are easy to understand...
❤4👍1
کد reusable واقعا عالیه.
مدت خیلی زیاده دارم به هر فانکشن که مینویسم فکر میکنم این reusbale هست یانه. و سعی میکنم اگه reusable نیست بهترش کنم.
از وقتی اینکارو کردم به طرز عجیبی کد OOP ام بسیار کمتر شد. و حجم کدمم خیلی کمتر شد و خواناییش هم خیلی بهتر شد. 👌 از وقتی کمی سمت ری اکت و rust و typenoscript رفتم دیدم به برنامه نویسی خیلی تغییر کرده. تازه اول مسیرشونم ولی همون ایده پشتشون برام خیلی جالبه و ذهنمو خیلی بیشتر باز کرده.
@PyBackendHub
مدت خیلی زیاده دارم به هر فانکشن که مینویسم فکر میکنم این reusbale هست یانه. و سعی میکنم اگه reusable نیست بهترش کنم.
از وقتی اینکارو کردم به طرز عجیبی کد OOP ام بسیار کمتر شد. و حجم کدمم خیلی کمتر شد و خواناییش هم خیلی بهتر شد. 👌 از وقتی کمی سمت ری اکت و rust و typenoscript رفتم دیدم به برنامه نویسی خیلی تغییر کرده. تازه اول مسیرشونم ولی همون ایده پشتشون برام خیلی جالبه و ذهنمو خیلی بیشتر باز کرده.
@PyBackendHub
👍14
وقتی داکیومنت maintain کنید تازه میفهمین سباستین چه کاره خفنی کرده 😁
مشکلی که من خیلی بهش میخورم اینه که تو هر پروژه ای که داکیومنتا زیاد میشه یک دفعه شبیه داک sqlalchemy میشه یعنی سرو تهش مشخص نیست. یک طوری recursive میشه.
یعنی مثلا هر داکیومنت فیچر کلی context داره و کسی که میخونه اونا رو لازمه که اون context رو بدونه. و به نحوی یکی از بیرون بیاد که هیچ context ای نداره وقتی داکو بخونه نمیفهمه. البته context ای هم که میگم داکیومنت شده ولی خب برای درک یک فیچر یک صفحه ای باید ۱۰ صفحه context خوند.
نمیدونم راه حل این مشکل چیه. ولی شما وقتی داک فست رو میخونید مثلا فیچر دو رو میخونید دو پاراگراف بالاش کانتکس رو خیلی قشنگ توضیح داده و جمع کرده. 😁 یعنی این موقعیت اصلا تو فست رخ نمیده و تنها داکی بوده که دیدم اینطوریه.
داک pydantic هم خوبه ولی باز تا حدی این مشکلو داره.
@PyBackendHub
مشکلی که من خیلی بهش میخورم اینه که تو هر پروژه ای که داکیومنتا زیاد میشه یک دفعه شبیه داک sqlalchemy میشه یعنی سرو تهش مشخص نیست. یک طوری recursive میشه.
یعنی مثلا هر داکیومنت فیچر کلی context داره و کسی که میخونه اونا رو لازمه که اون context رو بدونه. و به نحوی یکی از بیرون بیاد که هیچ context ای نداره وقتی داکو بخونه نمیفهمه. البته context ای هم که میگم داکیومنت شده ولی خب برای درک یک فیچر یک صفحه ای باید ۱۰ صفحه context خوند.
نمیدونم راه حل این مشکل چیه. ولی شما وقتی داک فست رو میخونید مثلا فیچر دو رو میخونید دو پاراگراف بالاش کانتکس رو خیلی قشنگ توضیح داده و جمع کرده. 😁 یعنی این موقعیت اصلا تو فست رخ نمیده و تنها داکی بوده که دیدم اینطوریه.
داک pydantic هم خوبه ولی باز تا حدی این مشکلو داره.
@PyBackendHub
👍13
Python BackendHub
ادامه سری پست های SQL تو SQL ما windows function داریم.ویندو فاکشن ها به ما اجازه میدن محاسباتی رو یک ستی از row ها انجام بدیم به صورت نسبی به row فعلی. یعنی چی؟ یعنی مثلا SUM مجموع row هارو حساب میکنه. توابع window چهار دسته تقسیم میشن. که برای هر دسته پست…
ادامه سری پست های SQL
تایپ بعدی توابع window function توابع Aggregation هستن که احتمالا باهاشون آشنایی دارین. مثل SUM, AVG, MAX. نکته خیلی خوبه این توابع اینه که شما دیگه نیازی نیست GROUP BY aggregations داشته باشین یعنی میتونید دیتا کامل هر row رو داشته باشین
سوال چهارم:
مطابق دیتاست و example هایی که داشتیم با استفاده از توابع Aggregation برای هر deal نشون بدید که چه درصدی از حجم کل deal_amount رو توی اون ریجن نشون میدن.
جواب query شما باید چیزی مشابه عکس باشه.
@PyBackendHub
تایپ بعدی توابع window function توابع Aggregation هستن که احتمالا باهاشون آشنایی دارین. مثل SUM, AVG, MAX. نکته خیلی خوبه این توابع اینه که شما دیگه نیازی نیست GROUP BY aggregations داشته باشین یعنی میتونید دیتا کامل هر row رو داشته باشین
سوال چهارم:
مطابق دیتاست و example هایی که داشتیم با استفاده از توابع Aggregation برای هر deal نشون بدید که چه درصدی از حجم کل deal_amount رو توی اون ریجن نشون میدن.
جواب query شما باید چیزی مشابه عکس باشه.
@PyBackendHub
👍3
یک چیزی که بنظرم شما رو خیلی برنامه نویس بهتری میکنه و منم خیلی تغییر داده Active thinker بودنه. یعنی چی؟ ما دو دسته آدم داریم, دسته اول کسایی که lazy thinker هستن. دسته دوم کسایی که Active thinker هستن. lazy thinker ها که بهش مغز تنبل هم میگن واژه بدی نیست, یعنی شما چیزی که جلوتون هست رو میبیند و میخونید و قبول میکنید و خیلی راحت ازش رد میشین. به عبارت دیگری نگاه خیلی سطحی دارین. یعنی خیلی زحمت نمیکشید برای درک کردن و به چالش کشیدن چیزی. درواقع شما تصور میکنید که درک کردین بدون اینکه واقعا درک کرده باشین. تفکر فعال از طرفی یعنی شما به صورت آگاهانه و عمدی و هدفنمند بر خلاف تفکر منفعل که یک چیزی رو خیلی راحت میپذیره به سختی میپذیرین و زمانی میپذیرین که شما درک کافی از اون استدلال و اطلاعات رو داشته باشین. برای اینکه به اون درک برسین شما تحقیق میکنید سوال میپرسین و ارتباط میگیرین و با به کارگیری خلاقیت و ذهنتون در نهایت واقعا اون چیز رو درک میکنید.
حالا این موضوع تو حیطه برنامه نویسی چطوری رو ما تاثیر میذاره؟
@PyBackendHub
حالا این موضوع تو حیطه برنامه نویسی چطوری رو ما تاثیر میذاره؟
@PyBackendHub
👍19
Python BackendHub
یک چیزی که بنظرم شما رو خیلی برنامه نویس بهتری میکنه و منم خیلی تغییر داده Active thinker بودنه. یعنی چی؟ ما دو دسته آدم داریم, دسته اول کسایی که lazy thinker هستن. دسته دوم کسایی که Active thinker هستن. lazy thinker ها که بهش مغز تنبل هم میگن واژه بدی نیست…
دو مثال میزنم که درک کنید تفاوت یک ادم Lazy Thinker و Active Thinker
۱. شما در حال خوندن داکیومنت httpx هستین تا بهتر درکش کنید. داخل داکیومنت اشاره کرده شما باید یک کلاینت httpx به صورت گلوبال داشته باشین که بهترین پرفومنس رو داشته باشین چون یک کانکشن پولینگ گلوبال خواهید داشت.به کانکشن پولینگ هم رفرنس داده تو ویکی پدیا و رد شده ازش. اگه شما این حرفو قبول کردین و رد شدین lazy thinker هستین. active thinker یعنی شما اگه نمیدونید دقیقا connection pooling یعنی چی برین مطالعه کنید. برین تحقیق کنید چرا اینکار باعث پرفومنس بهتر میشه. چرا ۲ کانکشن پولینگ داشتن بده؟ چه مشکلاتی درست میکنه؟ چرا داکیومنت همچین پیشنهادی داده؟ دقیقا چطور کار میکنه connection pooling. صرفا بسنده کردن به حرف داکیومنت شما رو اکیتو تینکر بار نمیاره.
۲. شما دارین یک سوالی رو حل میکنید. از صبح ۱۰ تا لینک استک اورفلو باز کردین و ۹ تاش کار نکرده.اخریش کار میکنه. یک نفر توضیح و گفته دلیلش اینه راهکارشم اینه. اگه شما صرفا راهکارو اجرا کنید و ببینید مشکلتون حل شده و رد شین ازش شما lazy thinker هستین. حقیقت اینکه شما نیاز داشتین به استک اورفلو برای حل اون سوال نشون میده شما دانش عمیقی ندارین تو اون زمینه و احتمالا بازم به مشکل میخورین. اگه active thinker باشین همینجا دست نگه میدارین و میرین راجب اون root مشکلتون بیشتر تحقیق میکنید داکشو میخونید و درکش میکنید و درک میکنید چرا اونی که تو استک اورفلو اون جوابو داده به جای اینکه فقط جوابشو درک کنید.
اکتیو تینکر بودن از کنجاوی شروع میشه. کنجکاوی که حد و مرز نداره. خیلی active thinker هم باشین میبینید یک دفعه خیلی از تسک و کارتون فاصله گرفتین. هرچیزی شاید اندازه ای داره. خیلی داشتنش همونقدر بده که نداشتنش بده.
@PyBackendHub
۱. شما در حال خوندن داکیومنت httpx هستین تا بهتر درکش کنید. داخل داکیومنت اشاره کرده شما باید یک کلاینت httpx به صورت گلوبال داشته باشین که بهترین پرفومنس رو داشته باشین چون یک کانکشن پولینگ گلوبال خواهید داشت.به کانکشن پولینگ هم رفرنس داده تو ویکی پدیا و رد شده ازش. اگه شما این حرفو قبول کردین و رد شدین lazy thinker هستین. active thinker یعنی شما اگه نمیدونید دقیقا connection pooling یعنی چی برین مطالعه کنید. برین تحقیق کنید چرا اینکار باعث پرفومنس بهتر میشه. چرا ۲ کانکشن پولینگ داشتن بده؟ چه مشکلاتی درست میکنه؟ چرا داکیومنت همچین پیشنهادی داده؟ دقیقا چطور کار میکنه connection pooling. صرفا بسنده کردن به حرف داکیومنت شما رو اکیتو تینکر بار نمیاره.
۲. شما دارین یک سوالی رو حل میکنید. از صبح ۱۰ تا لینک استک اورفلو باز کردین و ۹ تاش کار نکرده.اخریش کار میکنه. یک نفر توضیح و گفته دلیلش اینه راهکارشم اینه. اگه شما صرفا راهکارو اجرا کنید و ببینید مشکلتون حل شده و رد شین ازش شما lazy thinker هستین. حقیقت اینکه شما نیاز داشتین به استک اورفلو برای حل اون سوال نشون میده شما دانش عمیقی ندارین تو اون زمینه و احتمالا بازم به مشکل میخورین. اگه active thinker باشین همینجا دست نگه میدارین و میرین راجب اون root مشکلتون بیشتر تحقیق میکنید داکشو میخونید و درکش میکنید و درک میکنید چرا اونی که تو استک اورفلو اون جوابو داده به جای اینکه فقط جوابشو درک کنید.
اکتیو تینکر بودن از کنجاوی شروع میشه. کنجکاوی که حد و مرز نداره. خیلی active thinker هم باشین میبینید یک دفعه خیلی از تسک و کارتون فاصله گرفتین. هرچیزی شاید اندازه ای داره. خیلی داشتنش همونقدر بده که نداشتنش بده.
@PyBackendHub
👍20🌚2
Python BackendHub
راجب سوال یک, بنظرتون کانکشن پول چیه و چرا پرفومنس رو بهتر میکنه؟ @PyBackendHub
سروش تو کامنتا جواب داد: کانکشن پول بیشترین افزایش performance ش زمانی هست که به "یک سایت" یعنی پورت و آیپی یکسان چندین request بدیم. میاد از keep-alive استفاده میکنه و کانکشن رو باز نگهمیداره. دیگه هربار هی tcp handshake و tls handshake نمیکنه با سرور. درخواست بعدی از همون سوکت و کانکشن استفاده میکنه.
به زبون ساده مرحله ۲ و ۳ طبق عکس تکرار نمیشه. البته درستش اینه بگیم برای هر اوریجین نه سایت. و این موضوع فقط برای http 1.1 هست. http 1.0 اصلا keep alive نداشت و deprecate شده از سال ۱۹۹۷. این هدر به صورت دیفالت هروقت شما از هر کلاینت http استفاده میکنی هندل میشه. یعنی درواقع کلاینت http پایتون (فرقی نمیکنه httpx یا هر لایبری دیگه ای) یک کانکشن پولینگ داره که درخواست هارو با اون میزنه و از کانکشن reuse میکنه.
حالا میخوام شما پرفومنسی که میگیرین رو لمس کنید تو سه سناریویی که
۱. کلاینت global دارین. یعنی یک جایی یک کلاینت ساختین به صورت سینگلتون و همه جا از اون استفاده میکنید.
۲. ابستکرشن روی کلاینت دارین. یعنی مثلا کراولر دارین و هر کرالورتون یک کلاینت داره
۳. اصلا کانکشن پولینگ ندارین. یعنی کلاینت درخواست میزنه
تو سناریو اول شما به محض اینکه هر اوریجینی درخواست بزنید, درخواست اول کمی کند تره. اما از درخواست دوم مدت زمان اجرا شما خیلی کمتر میشه.
تو سناریو دوم, اگه دو کلاینتتون به یک اوریجین درخواست بزنه اونوقت هرکدوم دارن مرحله ۲ و ۳ رو تکرار میکنن برای همین برای اوریجین های تکراری تو کراولر های مختلف مشکل خواهید داشت.
تا سناریو سوم که افتضاحه. شما هر درخواستی که میزنید درواقع tcp handshake میده و پشتش هم میبنده. این اتفاق میفته وقتی شما مستقیم متود get رو از لایبری request استفاده میکنید.
پس میشه گفت کلاینت شما وقتی درخواست میده اون جایی که داره هندشیک میزنه hot loop برنامه شماست. و اگه دانش خوبی نداشته باشین پرفومنس بدی میدین و هیچوقت متوجه نمیشین دلیلش رو و میندازین گردن نتورک یا اینترنت بد سرور.
The concept of a "hot loop" refers to the part of your application that is repeatedly executed and can become a performance bottleneck, especially if it involves network operations like establishing new connections. Understanding and optimizing this aspect of your code can lead to significant performance improvements.
@PyBackendHub
به زبون ساده مرحله ۲ و ۳ طبق عکس تکرار نمیشه. البته درستش اینه بگیم برای هر اوریجین نه سایت. و این موضوع فقط برای http 1.1 هست. http 1.0 اصلا keep alive نداشت و deprecate شده از سال ۱۹۹۷. این هدر به صورت دیفالت هروقت شما از هر کلاینت http استفاده میکنی هندل میشه. یعنی درواقع کلاینت http پایتون (فرقی نمیکنه httpx یا هر لایبری دیگه ای) یک کانکشن پولینگ داره که درخواست هارو با اون میزنه و از کانکشن reuse میکنه.
حالا میخوام شما پرفومنسی که میگیرین رو لمس کنید تو سه سناریویی که
۱. کلاینت global دارین. یعنی یک جایی یک کلاینت ساختین به صورت سینگلتون و همه جا از اون استفاده میکنید.
۲. ابستکرشن روی کلاینت دارین. یعنی مثلا کراولر دارین و هر کرالورتون یک کلاینت داره
۳. اصلا کانکشن پولینگ ندارین. یعنی کلاینت درخواست میزنه
تو سناریو اول شما به محض اینکه هر اوریجینی درخواست بزنید, درخواست اول کمی کند تره. اما از درخواست دوم مدت زمان اجرا شما خیلی کمتر میشه.
تو سناریو دوم, اگه دو کلاینتتون به یک اوریجین درخواست بزنه اونوقت هرکدوم دارن مرحله ۲ و ۳ رو تکرار میکنن برای همین برای اوریجین های تکراری تو کراولر های مختلف مشکل خواهید داشت.
تا سناریو سوم که افتضاحه. شما هر درخواستی که میزنید درواقع tcp handshake میده و پشتش هم میبنده. این اتفاق میفته وقتی شما مستقیم متود get رو از لایبری request استفاده میکنید.
پس میشه گفت کلاینت شما وقتی درخواست میده اون جایی که داره هندشیک میزنه hot loop برنامه شماست. و اگه دانش خوبی نداشته باشین پرفومنس بدی میدین و هیچوقت متوجه نمیشین دلیلش رو و میندازین گردن نتورک یا اینترنت بد سرور.
The concept of a "hot loop" refers to the part of your application that is repeatedly executed and can become a performance bottleneck, especially if it involves network operations like establishing new connections. Understanding and optimizing this aspect of your code can lead to significant performance improvements.
@PyBackendHub
👍10
با درک کردن عکسه و متنی که گفتم حالا متوجه میشین که چرا داکیومنت توصیه کرده شما کلاینت گلوبال داشته باشین. متوجه میشین که چرا باید درخواست رو توی context منیجر بذارین چون باید close شه (لایه پنجم). تو حالت sync کلوز توی مجیک متود del زده میشه که موقع garbage collect اتفاق میفته یعنی رفرنس آبجکت ۰ میشه اونوقت کلوز میکنه خودش.
ولی تو async این اتفاق نمیفته. چون مجیک متودا اکثرا async پشتیبانی نمیکنن. ما adel نداریم.
@PyBackendHub
ولی تو async این اتفاق نمیفته. چون مجیک متودا اکثرا async پشتیبانی نمیکنن. ما adel نداریم.
@PyBackendHub
Python BackendHub
ادامه سری پست های SQL تایپ بعدی توابع window function توابع Aggregation هستن که احتمالا باهاشون آشنایی دارین. مثل SUM, AVG, MAX. نکته خیلی خوبه این توابع اینه که شما دیگه نیازی نیست GROUP BY aggregations داشته باشین یعنی میتونید دیتا کامل هر row رو داشته…
ادامه سری پست های SQL
علی پاسخ درستو داد تو کامنت. ولی یک نکته ای بود که هم بولد شده بود تو متن و هم میخواستم بهش برسم. ببینید کاربرد توابع windows function aggregation اینه که شما نیازی نباشه sub query بزنید که به دیتا row دسترسی داشته باشین. هروقت که اینکارو کردین یعنی بد نوشتین queryتون رو.
مثال میگم, اول علی همچین query ای زد:
که بعدش همین خیلی راحت تر شد و بهتر شد وقتی دیگه sub query نزد:
پس هرجایی که subquery دیدین با aggegation صرفا برای دسترسی به دیتا اون row بدونید اون query حتما اشتباه نوشته شده. 😁
بنظرتون تایپ سوم و چهارم توابع winodws function چیه که هنوز بررسیشون نکردم؟
@PyBackendHub
علی پاسخ درستو داد تو کامنت. ولی یک نکته ای بود که هم بولد شده بود تو متن و هم میخواستم بهش برسم. ببینید کاربرد توابع windows function aggregation اینه که شما نیازی نباشه sub query بزنید که به دیتا row دسترسی داشته باشین. هروقت که اینکارو کردین یعنی بد نوشتین queryتون رو.
مثال میگم, اول علی همچین query ای زد:
with sum_val as (
select sum(deal_amount) as region_deals_sum, region
from deals
group by region
)
select d.*, 100 * d.deal_amount/s.region_deals_sum
from deals d
join sum_val s on d.region = s.region;
که بعدش همین خیلی راحت تر شد و بهتر شد وقتی دیگه sub query نزد:
select *, 100*deal_amount/sum(deal_amount) over (partition by region) from deals;
پس هرجایی که subquery دیدین با aggegation صرفا برای دسترسی به دیتا اون row بدونید اون query حتما اشتباه نوشته شده. 😁
بنظرتون تایپ سوم و چهارم توابع winodws function چیه که هنوز بررسیشون نکردم؟
@PyBackendHub
🔥8❤3
یکم امروز با FastUI کار کردم و واقعا شگفت انگیز بود😁 ایده پشتش خیلی جالبه.
یک لایبری ری اکت تایپ اسکریپت دارن که سمت کلاینت لود میشه.
بعد سمت FastUI شما با استفاده از pydantic و لایبری fastui میای جیسونی میسازی که اون لایبری react میفهمه چطور رندرش کنه! یک چیزی شبیه htmx. اما نکته خیلی خفن ترش اینه که شما میتونی component خودتم تو ری اکت بنویسی و ساب تایپ بهش بدی و بعد لایبری ری اکتشون component شما هم رندر میکنه یعنی کاملا extendable هست😁
داک نداره هنوز، ولی داک خوب داشته باشه میتونه ابزار خیلی خوبی باشه برای توسعه یک internal tool به سریعترین شکل ممکن!
@PyBackEndHub
یک لایبری ری اکت تایپ اسکریپت دارن که سمت کلاینت لود میشه.
بعد سمت FastUI شما با استفاده از pydantic و لایبری fastui میای جیسونی میسازی که اون لایبری react میفهمه چطور رندرش کنه! یک چیزی شبیه htmx. اما نکته خیلی خفن ترش اینه که شما میتونی component خودتم تو ری اکت بنویسی و ساب تایپ بهش بدی و بعد لایبری ری اکتشون component شما هم رندر میکنه یعنی کاملا extendable هست😁
داک نداره هنوز، ولی داک خوب داشته باشه میتونه ابزار خیلی خوبی باشه برای توسعه یک internal tool به سریعترین شکل ممکن!
@PyBackEndHub
👍19
Python BackendHub
یکم امروز با FastUI کار کردم و واقعا شگفت انگیز بود😁 ایده پشتش خیلی جالبه. یک لایبری ری اکت تایپ اسکریپت دارن که سمت کلاینت لود میشه. بعد سمت FastUI شما با استفاده از pydantic و لایبری fastui میای جیسونی میسازی که اون لایبری react میفهمه چطور رندرش کنه!…
روز دوم, و واقعا تحت تاثیر قرار گرفتم. توصیه میکنم حتما یک سری بهش بزنید. لایبری FastUI صرفا یک مشت pydantic model عه فقط. نکته جالب تر اینه که FastUI در واقع پروتکلی پیاده سازی کرده که لایبری ری اکت طبق اون رندرینگ رو انجام میده. یعنی مثلا شما فکر کن میخوای بگی برو صفحه /foo. یعنی درواقع شما با جیسونی که از بک اندت میاد (لزوما میتونه پایتون نباشه) به صورت declarative میتونی فرانت بسازی. مثال زیر رو ببینید:
و خوده react کلاینتو میبره اینجا. حالا مشابه همین میتونی بگی فرمی بساز که فیلداش اینن. تو یک div باشه با کلس x. و خلاصه به صورت جیسون میتونید تعریف کنید که چطور فرم ساخته شه. و بعد SubmitUrl هم بهش میدین که url رو میفرسته اونجا. به همین راحتی 😅و وقتی کلاینت درخواست میده به یک صفحه درواقع بک اند بهش جیسونی میده که توضیح میده اون صفحه چطور باید رندر شه و کلاینت طبق اون توضیح (که جیسونه) صفحه رو رندر میکنه. و دیتا هم داخلش باید بذاری که رندر کنه. مثلا کلاینت درخواست میده صفحه ۵ فلان تیبل رو بگیره, شما دیتا رو بهش میدی و میگی چند صفحه وجود داره آبجکت. یعنی یک جورایی هم کلاینت ساید رندرنیگه هم سرور ساید رندرینگ.
مشکلی که داره اینه که state نداره. که این هم خوبه هم بد. خوب از این نظر که باگ خیلی کمتره. بد از این نظر که دیتایی که به فرانت میدی تو هر صفحه ممکنه زیاد شه و سرعت لود صفحه رو کند کنه. مثلا استیتی نداری که فرانت یک بار استفاده کنه و بفهمه چقدر تیبل user چقدر user داره. و دیگه تو هر ریسپانس user list نیاز نباشه تعداد یوزر رو بدی. سرعت توسعه فوق العاده زیادی داره. واقعا عالیه از این نظر. component های خیلی خوبی داره و خیلی سریع میتونید یک داشبورد بسازید که خیلی کارای خفنی بکنه. اگه جایی نیاز داشتین با react همونطور که توضیح دادم میتونه extendable شه یعنی هم پایتون میتونید کد بزنید هم ری اکت.
ایده پشتش:
Think of your frontend as a puppet, and the backend as the hand within it — the puppet doesn't need to know what to say, that's kind of the point.
@PyBackEndHub
[{"event":{"url":"/foo","type":"go-to"},"type":"FireEvent"}]
و خوده react کلاینتو میبره اینجا. حالا مشابه همین میتونی بگی فرمی بساز که فیلداش اینن. تو یک div باشه با کلس x. و خلاصه به صورت جیسون میتونید تعریف کنید که چطور فرم ساخته شه. و بعد SubmitUrl هم بهش میدین که url رو میفرسته اونجا. به همین راحتی 😅و وقتی کلاینت درخواست میده به یک صفحه درواقع بک اند بهش جیسونی میده که توضیح میده اون صفحه چطور باید رندر شه و کلاینت طبق اون توضیح (که جیسونه) صفحه رو رندر میکنه. و دیتا هم داخلش باید بذاری که رندر کنه. مثلا کلاینت درخواست میده صفحه ۵ فلان تیبل رو بگیره, شما دیتا رو بهش میدی و میگی چند صفحه وجود داره آبجکت. یعنی یک جورایی هم کلاینت ساید رندرنیگه هم سرور ساید رندرینگ.
مشکلی که داره اینه که state نداره. که این هم خوبه هم بد. خوب از این نظر که باگ خیلی کمتره. بد از این نظر که دیتایی که به فرانت میدی تو هر صفحه ممکنه زیاد شه و سرعت لود صفحه رو کند کنه. مثلا استیتی نداری که فرانت یک بار استفاده کنه و بفهمه چقدر تیبل user چقدر user داره. و دیگه تو هر ریسپانس user list نیاز نباشه تعداد یوزر رو بدی. سرعت توسعه فوق العاده زیادی داره. واقعا عالیه از این نظر. component های خیلی خوبی داره و خیلی سریع میتونید یک داشبورد بسازید که خیلی کارای خفنی بکنه. اگه جایی نیاز داشتین با react همونطور که توضیح دادم میتونه extendable شه یعنی هم پایتون میتونید کد بزنید هم ری اکت.
ایده پشتش:
Think of your frontend as a puppet, and the backend as the hand within it — the puppet doesn't need to know what to say, that's kind of the point.
@PyBackEndHub
👍12👎1
یکم با Rust کار کردم این چند وقت و ایده ای که نسبت بهش دارم اینه که Rust شما رو مجبور میکنه به همه edge case ها فکر کنید و شما رو خیلی به فکر وا میداره. خیلی باید explicit باشین راجب همه چیز که بنظره خودم تجربه توسعه رو هم خوب میکنه هم بد. بد از این نظر که طول میکشه یک برنامه رو بنویسید و خوب از این نظر که dx خوبی داره و وقتی برنامتون کامپایل شد خیلی smoothعه.
به درد توسعه وب اپلیکیشن بنظرم نمیخوره چون خیلی effort زیادی میخواد کد نوشتن باهاش و اپلیکیشن ها بیشتر data intensive هستن (مگه اپلیکیشنی cpu intensive). هیچ ادج کیسی نمیتونید داشته باشین. تایپ Any نمیتونید داشته باشید (تکنیکالی میتونید ولی برای اینکه بهش دسترسی داشته باشید و باهاش کار کنید تهش باید یک جایی cast اش کنید و همه کیس هارو هندل کنید)
اما چیزی که بنظرم توصیه میکنم حتما برین سمتش طرز و خط فکریه که شما رو به اون سمت میبره. و میتونید از همون ایده هایی که تو راست بود هم تو پایتون استفاده کنید.
@PyBackEndHub
به درد توسعه وب اپلیکیشن بنظرم نمیخوره چون خیلی effort زیادی میخواد کد نوشتن باهاش و اپلیکیشن ها بیشتر data intensive هستن (مگه اپلیکیشنی cpu intensive). هیچ ادج کیسی نمیتونید داشته باشین. تایپ Any نمیتونید داشته باشید (تکنیکالی میتونید ولی برای اینکه بهش دسترسی داشته باشید و باهاش کار کنید تهش باید یک جایی cast اش کنید و همه کیس هارو هندل کنید)
اما چیزی که بنظرم توصیه میکنم حتما برین سمتش طرز و خط فکریه که شما رو به اون سمت میبره. و میتونید از همون ایده هایی که تو راست بود هم تو پایتون استفاده کنید.
@PyBackEndHub
👏15👍9👎1
Forwarded from سید فرندز / برنامه نویسی / هک و امنیت / تکنولوژی (SeYeD.Dev)
آموزش برنامهنویسی از صفر تا بینهایت به صورت کاملا رایگان، در این دوره قصد داریم هر آنچه که در بازار کار نیاز است را به شما آموزش دهیم. هدف این دوره، تبدیل شدن به یک برنامهنویس فول استک است.
مرحله ۱: مبانی و زبانهای برنامهنویسی
1. مقدمه به برنامهنویسی
2. زبان برنامهنویسی پایتون
3. زبان برنامهنویسی جاوا اسکریپت
4. مفاهیم برنامهنویسی شیگرا
مرحله ۲: توسعه وب و فریمورکها
5. فریمورک Django
6. فریمورک FastAPI
7. فریمورک VueJS
8. فریمورک gRPC
9. استفاده از بوتاسترپ، HTML، CSS و فریمورکهای CSS معتبر
مرحله ۳: دیتابیس
10. دیتابیس SQL
11. دیتابیس MongoDB
12. آشنایی با دیتابیس Neo4J
13. استفاده از ردیس، ربیت ام کیو، سلری
مرحله ۴: تکنولوژیهای متنوع
14. مفاهیم داکر
15. آشنایی با لینوکس
16. اجرای دیپلویمنت خودکار و CI/CD
مرحله ۵: امنیت و تستها
17. تکنیکهای تست نویسی
18. استفاده از گیت
19. مفاهیم امنیت در وب
مرحله ۶: مفاهیم پیشرفته
20. مفاهیم مالتیتردینگ و مالتیپروسسینگ و Async
21. آشنایی با معماری میکروسرویس
مرحله ۷: مهارتهای مساعدتی
22. آموزش ساخت رزومه
23. راهنمایی در مسیر کاریابی
24. فرایندهای توسعه نرمافزار Agile/Scrum
روش ارائه:
- کلاسها به صورت لایو در دیسکورد برگزار خواهند شد.
- کلاسها به صورت شبانه ارائه خواهند شد.
زمان شروع و مدت دوره:
- شروع دوره از پس از تعطیلات نوروز و تا حدود ۶ ماه به طول خواهد انجامید.
مدرس دوره:
- سید و همکاران ایشان افتخار دارند این دوره را برگزار نمایند.
کانال تلگرام سید و رفقا:
زمان دقیق شروع دوره و لینک دیسکورد در کانال سید و رفقا اطلاع رسانی داده خواهد شد
https://news.1rj.ru/str/seyed_bax
مرحله ۱: مبانی و زبانهای برنامهنویسی
1. مقدمه به برنامهنویسی
2. زبان برنامهنویسی پایتون
3. زبان برنامهنویسی جاوا اسکریپت
4. مفاهیم برنامهنویسی شیگرا
مرحله ۲: توسعه وب و فریمورکها
5. فریمورک Django
6. فریمورک FastAPI
7. فریمورک VueJS
8. فریمورک gRPC
9. استفاده از بوتاسترپ، HTML، CSS و فریمورکهای CSS معتبر
مرحله ۳: دیتابیس
10. دیتابیس SQL
11. دیتابیس MongoDB
12. آشنایی با دیتابیس Neo4J
13. استفاده از ردیس، ربیت ام کیو، سلری
مرحله ۴: تکنولوژیهای متنوع
14. مفاهیم داکر
15. آشنایی با لینوکس
16. اجرای دیپلویمنت خودکار و CI/CD
مرحله ۵: امنیت و تستها
17. تکنیکهای تست نویسی
18. استفاده از گیت
19. مفاهیم امنیت در وب
مرحله ۶: مفاهیم پیشرفته
20. مفاهیم مالتیتردینگ و مالتیپروسسینگ و Async
21. آشنایی با معماری میکروسرویس
مرحله ۷: مهارتهای مساعدتی
22. آموزش ساخت رزومه
23. راهنمایی در مسیر کاریابی
24. فرایندهای توسعه نرمافزار Agile/Scrum
روش ارائه:
- کلاسها به صورت لایو در دیسکورد برگزار خواهند شد.
- کلاسها به صورت شبانه ارائه خواهند شد.
زمان شروع و مدت دوره:
- شروع دوره از پس از تعطیلات نوروز و تا حدود ۶ ماه به طول خواهد انجامید.
مدرس دوره:
- سید و همکاران ایشان افتخار دارند این دوره را برگزار نمایند.
کانال تلگرام سید و رفقا:
زمان دقیق شروع دوره و لینک دیسکورد در کانال سید و رفقا اطلاع رسانی داده خواهد شد
https://news.1rj.ru/str/seyed_bax
❤🔥30👎8👍6🤔2🔥1🙏1
لاگرتونو خوب کانفیگ کنید✅
https://www.youtube.com/watch?v=9L77QExPmI0
بحث کانفیگ درسته لاگر چیزیه که خیلی کم تو پایتون دیدم درست پیادش کنند
این چنل و کلا این یوتیوبر عالیه، مباحث عمیق پایتونی رو بهش میپردازه
@PyBackEndHub
https://www.youtube.com/watch?v=9L77QExPmI0
بحث کانفیگ درسته لاگر چیزیه که خیلی کم تو پایتون دیدم درست پیادش کنند
این چنل و کلا این یوتیوبر عالیه، مباحث عمیق پایتونی رو بهش میپردازه
@PyBackEndHub
YouTube
Modern Python logging
A logging tutorial.
At some point, print statements aren't enough. When that time comes in Python, you should reach for the builtin logging package. It may be old (committed in 2002!), but it is the standard in Python. Unfortunately though, it being so old…
At some point, print statements aren't enough. When that time comes in Python, you should reach for the builtin logging package. It may be old (committed in 2002!), but it is the standard in Python. Unfortunately though, it being so old…
👍11🔥3
یک چیزه خیلی مهم تو دنیای برنامه نویسی:
https://www.youtube.com/watch?v=U7A12dQgFqI
به شدت Idempotency تو کد مهمه. صرفا به API ختم نمیشه و تو سطح کد هم میتونه رعایت شه. توابعی بنویسید که در برابر arguement ای که بهش میدین همیشه Idempotent هستن! یکی از مزایا بزرگ type state بودن هم Idempotency عه.
ویدیو تایپ استیت که قبلا تو کانال فرستاده بودم:
https://youtu.be/DwAQ6dm-Vn8
@PyBackEndHub
https://www.youtube.com/watch?v=U7A12dQgFqI
به شدت Idempotency تو کد مهمه. صرفا به API ختم نمیشه و تو سطح کد هم میتونه رعایت شه. توابعی بنویسید که در برابر arguement ای که بهش میدین همیشه Idempotent هستن! یکی از مزایا بزرگ type state بودن هم Idempotency عه.
ویدیو تایپ استیت که قبلا تو کانال فرستاده بودم:
https://youtu.be/DwAQ6dm-Vn8
@PyBackEndHub
YouTube
از Spotify یاد بگیریم 🔥 Idempotency در سیستم پرداخت
یه وقتهایی بخاطر مشکل شبکه یا درخواست ها به مقصد نمیرسن یا جوابش رو ما نمیگیریم. حالا وقتی درخواست خرید ارسال شده ولی مشکل شبکه خوردیم باید retry کنیم و دوباره درخواست بفرستیم یا تصور کنیم انجام شده؟ این مسئله توی Spotify باعث شده بود یا دوبار از حساب کاربر…
👍12🔥1
Forwarded from سید فرندز / برنامه نویسی / هک و امنیت / تکنولوژی (SeYeD.Dev)
Please open Telegram to view this post
VIEW IN TELEGRAM
🤣21😁1
سید فرندز / برنامه نویسی / هک و امنیت / تکنولوژی
یک نکته امروز یاد گرفتم که کاش زودتر یاد میگرفتم
تو پایتون هیچوقت از Any استفاده نکنید. اگه تایپ یک آبجکتی رو نمیدونید اونوقت از object استفاده کنید.
چرا؟
چون مجبور میشین حالا تایپ رو چک کنید و شرط بنویسید.
یعنی اگه بنویسی:
سیستم استتیک تایپ بهتون ایراد نمیگیره. ولی اگه بنویسید
استتیک تایپ چکر بهتون ایراد میگیره. پس مجبور میشین به صورت explicit تایپشو چک کنید. جاهایی که نمیدونید چه تایپی به این تابع پاس داده میشه عالیه.
@PyBackEndHub
تو پایتون هیچوقت از Any استفاده نکنید. اگه تایپ یک آبجکتی رو نمیدونید اونوقت از object استفاده کنید.
چرا؟
چون مجبور میشین حالا تایپ رو چک کنید و شرط بنویسید.
یعنی اگه بنویسی:
def foo(bar: Any):
bar.not_valid
سیستم استتیک تایپ بهتون ایراد نمیگیره. ولی اگه بنویسید
def foo(bar: object):
bar.not_valid
استتیک تایپ چکر بهتون ایراد میگیره. پس مجبور میشین به صورت explicit تایپشو چک کنید. جاهایی که نمیدونید چه تایپی به این تابع پاس داده میشه عالیه.
@PyBackEndHub
👍13👌3
Forwarded from Python BackendHub
کاربرد گروهو میخوام تغییر بدم
به گروهی برای رفع مشکل و بحث در خصوص Backend Engineering و پایتون
مرجعی هم بشه که بتونید کلا سوالات flask یا kafka یا rabbitmq یا FastAPI یا ORM هرچیز دیگه ای که ممکنه براش community پیدا نکنید. لینک:
https://news.1rj.ru/str/PythonFellow
خوشحال میشم جوین شید. قانون خاصی نداره به جز حفظ احترام اعضای گروه.
@PyBackEndHub
به گروهی برای رفع مشکل و بحث در خصوص Backend Engineering و پایتون
مرجعی هم بشه که بتونید کلا سوالات flask یا kafka یا rabbitmq یا FastAPI یا ORM هرچیز دیگه ای که ممکنه براش community پیدا نکنید. لینک:
https://news.1rj.ru/str/PythonFellow
خوشحال میشم جوین شید. قانون خاصی نداره به جز حفظ احترام اعضای گروه.
@PyBackEndHub
Telegram
Python Backend Fellow
گروه رفع اشکال و بحث در مورد Backend Engineering و پایتون
Channel: @PyBackEndHub
Channel: @PyBackEndHub
👍18
کار کردن با کسی که هیچ سواد برنامه نویسی نداره راحت تره نسبت با کار کردن کسی که خیلی با سواده ولی چیزی که نمیدونه رو ادعا میکنه بلده! چون اولی پیشرفت میکنه و از یکجایی عصا دست میشه ولی دومی جز سردرد باری نداره.
@PyBackEndHub
@PyBackEndHub
👍50🫡3👎1