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

@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

کاربرد گروهو میخوام تغییر بدم
به گروهی برای رفع مشکل و بحث در خصوص Backend Engineering و پایتون

مرجعی هم بشه که بتونید کلا سوالات flask یا kafka یا rabbitmq یا FastAPI یا ORM هرچیز دیگه ای که ممکنه براش community پیدا نکنید. لینک:

https://news.1rj.ru/str/PythonFellow

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

@PyBackEndHub

حق 👌
دو سه پست بعدی کانالو اختصاص میدم به SQL

@PyBackendHub

یک تیبل میسازیم... به اسم deals که deal هایی که ثبت میشه رو وارد دیتابیس کنیم.

CREATE TABLE deals (
deal_id INT PRIMARY KEY,
deal_amount DECIMAL (10, 2),
customer_name VARCHAR (255),
region VARCHAR(255),
deal_date DATE

و یک سری دیتا هم اضافه میکنیم که تو عکس میتونید ببینید query رو که چه چیزی insert شده.
سوال اول:‌ یک query بنویسید که برای هر region بزرگ ترین deal هارو نشون بده.
@PyBackendHub

کسایی که نیاز دارن به اجرای کامند
insert
@PyBackendHub

یک سری query کامنت کردن که بررسیشون میکنیم تک تک:

SELECT  max(deal_amount), d.*
From deals d
GROUP BY region

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

ایرادش چیه؟ ایرادش اینجاست که ریجن آسیا ۲ تا deal داره که amount شون ۱۵۰۰۰ هست! (یکی آیدی ۸ یکی آیدی ۱۰). ولی این فقط ۸ رو برگردوند. 😅 چون max همیشه فقط یکی رو برمیگردونه به ازای ریجن. سوال خواسته شده بزرگ ترین deal های هر ریجن رو در بیارین.

@PyBackendHub

یک query دیگه کامنت کردن که دوباره همین اتفاق بالا براش میفتاد. یک query هم با رنک نوشتن که جواب درست میده. اینکه رنک چیه رو تو پست های بعدی توضیح میدم. اما قبلش میپردازیم به راه حل های آسون تر بدون استفاده از PARTITION و RANK.

اولین راه حل مبتدیانه:

SELECT *
FROM deals d1
WHERE d1.deal_amount = (
    SELECT MAX(d2.deal_amount)
    FROM deals d2
    WHERE d2.region = d1.region
);

هیچوقت اینطوری subquery نزنید. تو این حالت تو inner query درواقع اومده رفرنس زده به outer query
اتفاقی که میفته تو سطح دیتابیس به ازای هر row این query inner ران میشه و باعث میشه خیلی کند ران شه. میتونیم subquery بهتری کنیم که دیگه این رفرنس اتفاق نیفته ولی بهتره به جاش از CTE استفاده کنیم (common table expression) چون هم خوانایی خوبی داره و هم هرچی query بزرگ تر شه بازم خواناییش سخت تر نمیشه و شکسته شکسته هست.

WITH max_deals_by_region AS (SELECT region, MAX(deal_amount) as max_deal_amount
                             FROM deals
                             GROUP BY region)
SELECT d.*
FROM deals d
         JOIN max_deals_by_region rmd
              ON d.region = rmd.region
                  AND d.deal_amount = rmd.max_deal_amount
ORDER BY d.deal_id;

@PyBackendHub

ریزالتی که در نهایت باید به دست میومد:

@PyBackendHub

ادامه سری پست های SQL

تو SQL ما windows function داریم.ویندو فاکشن ها به ما اجازه میدن محاسباتی رو یک ستی از row ها انجام بدیم به صورت نسبی به row فعلی. یعنی چی؟ یعنی مثلا SUM مجموع row هارو حساب میکنه. توابع window چهار دسته تقسیم میشن. که برای هر دسته پست و مثال میذارم;

اولین درسته توابع رنک هستند, توابعی که رتبه دیتا رو تو یک دیتاست بر معیار یکی از ترتیبی که تعیین میکنید با ORDER BY مقایسه میکنه. مثلا یک تیبل دارین که جدول مسابقه لیگ فوتبال رو نشون میده. میخواین تیم ۱ تا ۲۰ رو رتبه بندی کنید اون موقع از توابع ranking استفاده کنید. بیایم سوال اول رو کمی تغییر بدیم,
سوال دوم:‌یک query بنویسید که برای هر ریجن ۳ تا از بزرگ ترین deal هارو نشون بده.
جوابش:

WITH RankedDeals AS (
    SELECT *,
           RANK() OVER (PARTITION BY region ORDER BY deal_amount DESC) AS rank
    FROM deals
)
SELECT *
FROM RankedDeals
WHERE rank < 4;

دقت کنید چه اتفاقی افتاد...
داخل CTE نوشتم که deal هارو انتخاب کن و rank شون کن با پاریشن region و ترتیب deal_amount به صورت desc
یعنی چی؟پارتیشن: دیتا رو به تیکه کوچیک تر تبدیل میکنه. که بعد سینتکس OVER() میاد. یعنی اول دیتا رو بیا طبق region هاشون بشکون. بعد به ترتیب deal_amount مرتبشون کن. و در آخر رتبشون رو حساب کن.

توابع رنک تو SQL:
ROW_NUMBER
RANK
DENSE_RANK

فرق اینا چیه؟ تو سوال سوم مشخص میشه.


تو سه سناریو زیر از کدوم فانکشن ranking استفاده میکنید؟
سناریو اول) صد دونده را در marathon شرکت کردن. رتبه دونده ها رو بر اساس تایم پایانشون حساب کنید. چنانچه دو دونده همزمان اتمام کردن هر دو دونده رو هم رتبه در نظر بگیرین. دونده ها لزوما از رتبه ۱ تا ۱۰۰ قرار نمیگیرن, مثلا اگه نفر ۹۹ و ۹۸ همزمان به خط پایانی رسیدن رتبه ۹۸ میشن. و نفر ۱۰۰ ام رتبه ۹۹ میشه.

سناریو دوم) در جدول لیگ فوتبال بیست تیم رو به ترتیب از رتبه ۱ تا ۲۰ رتبه بندی کنید بر اساس امتیازشون. چنانچه امتیاز برابری داشتن تفاضل گل رو در نظر بگیرین.

سناریو سوم) شرکتی میخواد به ۱۰۰ کاربر برترش مطابق سیستم امتیاز دهی اش جایزه بده. اما نمیخواد در حق کارمندا ناحقی شه برای همین اگه مثلا امتیاز نفره ۱۰۰ ام با ۱۰۱ام برابر بود, نفره ۱۰۱ ام هم رتبه ۱۰۰ در نظر میگیره و بهش جایزه میده. اما شرکت تو حالت ایده آل نمیخواد به بیشتر از ۱۰۰ کارمند جایزه بده.

@PyBackendHub

سناریو اول dense_rank
سناریو دوم row_number
سناریو سوم rank
اما چرا؟؟ به عکس دقت کنید. رو همون دیتاستی که داشتیم سه تا رنک رو همزمان query زدیم

SELECT deal_id, deal_amount, customer_name, 
  ROW_NUMBER() OVER
      (PARTITION BY region ORDER BY deal_amount DESC)
      AS row_number,
   RANK() OVER
      (PARTITION BY region ORDER BY deal_amount DESC)
      AS rank,
   DENSE_RANK() OVER
      (PARTITION BY region ORDER BY deal_amount DESC)
      AS dense_rank

FROM deals
ORDER BY region, deal_amount DESC;

ریزالتش رو تو عکس بعدی میتونید ببینید. اتفاقی که میفته:

۱. همیشه ROW_NUMBER یکی یکی بالا میره. حتی اگه دو تا column تو رنکینگ مساوی شن بازم رتبه هاشون فرق میکنه. وقتی از این رنکینگ استفاده میکنید حواستون باشه fallback زیاد بذارین. مثل جدول فوتبال. مثلا اگه امتیاز مساوی بود اونوقت تفاضل. اگه تفاضل مساوی بود اونوقت ....

۲. رنک RANK بهتون رتبه نسبی میده. یعنی مثلا اگه دو تیم امتیازشون یکی شه رتبه شون یکی میشه. مثلا رتبه تیم اول تا پنجم میشه ۱-۲-۳-۳-۵ . اگه دقت کنید وقتی یک رتبه اسکیپ میشه فاصلش حفظ میشه. برای همین برای شرکت (سناریو سوم) گزینه مناسبی بود. چون فقط به شرطی بیشتر از ۱۰۰ کارمند جایزه میگرفتن که ۱۰۱ امین کارمند امتیازش برابر میشد با ۱۰۰مین کاربر. و یا ۱۰۲امین برابر میشد. برای سناریو هایی استفاده میشه که میخواین رتبه بندی کنید ولی نمیخواین کنترلتون رو تعداد آبجکت ها تا اون رتبه از دست بدید. مثلا رتبه ۱۰۰ گارانتی بهتون میده 100+n آبجکت وجود داره که n در واقع میشه تعداد مساوی ها با ۱۰۰امین آبجکت.

۳. رنک DENSE_RANK کاربرد کمتری داره. این رنک مثل RANK دیتاست های برابر رو هم رتبه میکنه. ولی فرقش اینجاست که دیگه compromise(جبران) نمیکنه موقع رتبه دادن به دیتا بعدی تو جدول. یعنی چی؟ یعنی فکر کنید مثل سناریو قبلی رتبه تیم اول تا پنجم اینطوری میتونه بشه: ۱-۱-۲-۲-۲. در صورتی که اگه rank بود میشد ۱-۱-۳-۳-۳. کاربرد تو دنیای واقعی من تاحالا ازش نداشتم.😅 برای همین مثالش یکم بد قلق بود.


@PyBackendHub

اینم ریزایت query رو دیتابیس
@PyBackendHub

#toxic 😂
هروقت یک کد خفنی تو یک لایبری دیدین لایبری رو نصب نکنید
کدو کپی کنید که بقیه فکر کنن چقدر خفنید 😎 امضا خودتونم بزنید پای کد

@PyBackendHub

تو گروه واقعا بحث های جالبی میشه دم همه گرم که فعالن 🙌 بحث کد فانکشنال و OOP شد دیشب که بحثش به امروزم رسید. من همیشه فانکشنال رو ترجیح میدم به OOP مگه طبق ویدیویی که گذاشتم چند روز پیش بخوام یا
۱. استیت ذخیره کنم
۲. بخوام 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

کد reusable واقعا عالیه.
مدت خیلی زیاده دارم به هر فانکشن که مینویسم فکر میکنم این reusbale هست یانه. و سعی میکنم اگه ‍reusable نیست بهترش کنم.

از وقتی اینکارو کردم به طرز عجیبی کد OOP ام بسیار کمتر شد. و حجم کدمم خیلی کمتر شد و خواناییش هم خیلی بهتر شد. 👌 از وقتی کمی سمت ری اکت و rust و typenoscript رفتم دیدم به برنامه نویسی خیلی تغییر کرده. تازه اول مسیرشونم ولی همون ایده پشتشون برام خیلی جالبه و ذهنمو خیلی بیشتر باز کرده.

@PyBackendHub

وقتی داکیومنت maintain کنید تازه میفهمین سباستین چه کاره خفنی کرده 😁
مشکلی که من خیلی بهش میخورم اینه که تو هر پروژه ای که داکیومنتا زیاد میشه یک دفعه شبیه داک sqlalchemy میشه یعنی سرو تهش مشخص نیست. یک طوری recursive میشه.

یعنی مثلا هر داکیومنت فیچر کلی context داره و کسی که میخونه اونا رو لازمه که اون context رو بدونه. و به نحوی یکی از بیرون بیاد که هیچ context ای نداره وقتی داکو بخونه نمیفهمه. البته context ای هم که میگم داکیومنت شده ولی خب برای درک یک فیچر یک صفحه ای باید ۱۰ صفحه context خوند.
نمیدونم راه حل این مشکل چیه. ولی شما وقتی داک فست رو میخونید مثلا فیچر دو رو میخونید دو پاراگراف بالاش کانتکس رو خیلی قشنگ توضیح داده و جمع کرده. 😁 یعنی این موقعیت اصلا تو فست رخ نمیده و تنها داکی بوده که دیدم اینطوریه.

داک pydantic هم خوبه ولی باز تا حدی این مشکلو داره.
@PyBackendHub

ادامه سری پست های SQL

تایپ بعدی توابع window function توابع Aggregation هستن که احتمالا باهاشون آشنایی دارین. مثل SUM, AVG, MAX. نکته خیلی خوبه این توابع اینه که شما دیگه نیازی نیست GROUP BY aggregations داشته باشین یعنی میتونید دیتا کامل هر row رو داشته باشین

سوال چهارم:
مطابق دیتاست و example هایی که داشتیم با استفاده از توابع Aggregation برای هر deal نشون بدید که چه درصدی از حجم کل deal_amount رو توی اون ریجن نشون میدن.
جواب query شما باید چیزی مشابه عکس باشه.

@PyBackendHub

یک چیزی که بنظرم شما رو خیلی برنامه نویس بهتری میکنه و منم خیلی تغییر داده Active thinker بودنه. یعنی چی؟ ما دو دسته آدم داریم, دسته اول کسایی که lazy thinker هستن. دسته دوم کسایی که Active thinker هستن. lazy thinker ها که بهش مغز تنبل هم میگن واژه بدی نیست, یعنی شما چیزی که جلوتون هست رو میبیند و میخونید و قبول میکنید و خیلی راحت ازش رد میشین. به عبارت دیگری نگاه خیلی سطحی دارین. یعنی خیلی زحمت نمیکشید برای درک کردن و به چالش کشیدن چیزی. درواقع شما تصور میکنید که درک کردین بدون اینکه واقعا درک کرده باشین. تفکر فعال از طرفی یعنی شما به صورت آگاهانه و عمدی و هدفنمند بر خلاف تفکر منفعل که یک چیزی رو خیلی راحت میپذیره به سختی میپذیرین و زمانی میپذیرین که شما درک کافی از اون استدلال و اطلاعات رو داشته باشین. برای اینکه به اون درک برسین شما تحقیق میکنید سوال میپرسین و ارتباط میگیرین و با به کارگیری خلاقیت و ذهنتون در نهایت واقعا اون چیز رو درک میکنید.

حالا این موضوع تو حیطه برنامه نویسی چطوری رو ما تاثیر میذاره؟
@PyBackendHub

دو مثال میزنم که درک کنید تفاوت یک ادم Lazy Thinker و Active Thinker

۱. شما در حال خوندن داکیومنت httpx هستین تا بهتر درکش کنید. داخل داکیومنت اشاره کرده شما باید یک کلاینت httpx به صورت گلوبال داشته باشین که بهترین پرفومنس رو داشته باشین چون یک کانکشن پولینگ گلوبال خواهید داشت.به کانکشن پولینگ هم رفرنس داده تو ویکی پدیا و رد شده ازش. اگه شما این حرفو قبول کردین و رد شدین lazy thinker هستین. active thinker یعنی شما اگه نمیدونید دقیقا connection pooling یعنی چی برین مطالعه کنید. برین تحقیق کنید چرا اینکار باعث پرفومنس بهتر میشه. چرا ۲ کانکشن پولینگ داشتن بده؟ چه مشکلاتی درست میکنه؟ چرا داکیومنت همچین پیشنهادی داده؟ دقیقا چطور کار میکنه connection pooling. صرفا بسنده کردن به حرف داکیومنت شما رو اکیتو تینکر بار نمیاره.

۲. شما دارین یک سوالی رو حل میکنید. از صبح ۱۰ تا لینک استک اورفلو باز کردین و ۹ تاش کار نکرده.اخریش کار میکنه. یک نفر توضیح و گفته دلیلش اینه راهکارشم اینه. اگه شما صرفا راهکارو اجرا کنید و ببینید مشکلتون حل شده و رد شین ازش شما lazy thinker هستین. حقیقت اینکه شما نیاز داشتین به استک اورفلو برای حل اون سوال نشون میده شما دانش عمیقی ندارین تو اون زمینه و احتمالا بازم به مشکل میخورین. اگه active thinker باشین همینجا دست نگه میدارین و میرین راجب اون root مشکلتون بیشتر تحقیق میکنید داکشو میخونید و درکش میکنید و درک میکنید چرا اونی که تو استک اورفلو اون جوابو داده به جای اینکه فقط جوابشو درک کنید.

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

@PyBackendHub

راجب سوال یک, بنظرتون کانکشن پول چیه و چرا پرفومنس رو بهتر میکنه؟

@PyBackendHub