کامنت حق حامد تو کامنتا به نقل قول از Greg Young:

میگن یکی از بزرگترین چیزایی که یه فرد C لول تو یه شرکت یاد میگیره اینه که در جواب هر سوالی بگه It depends

@ManiFoldsPython

دوستانی که میپرسن چطور من sql یاد گرفتم:

۱. اولا هیچ query رو اخیرا دیگه رو اول تو orm به صورت کد نمینویسم مگه اینکه یک چیز خیلی ابتدایی باشه. اول همیشه با دیتابیس مینویسم بعد میام رو orm معادلشو مینویسم. این عادتو حتما ترک بدین و به محیط دیتابیس عادت کنید.

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

۳. همین query هایی که طی روز مینویسید تلاش کنید بهینه و با ۱ هیت بنویسید. با ۱ هیت نوشتن دلیل بر این نمیشه که query بهینه شد. explain و analyze رو بزنید ببینید چه اتفاقی داره میفته. با مفاهیم داخل دیتابیس آشنا باشین. بدونید cost estimate و execution plan وactual time و rows and width و buffers چیه. صرفا سریع ران شدن هم دلیل بر آپتیمایز بودن یک query نیست. ممکنه مموری خیلی زیادی مصرف کنه. پس متریک های دیتابیس رو یاد بگیرین. و کار کردن باهاش رو. مثل یک زمین بازی میمونه هرچی بیشتر توش بازی کنید بیشتر یاد میگیرین.

آیا مهمه؟
صد در صد 🙂 اخیرا دیدم تو community پایتون خیلی مانور میرن رو اینکه پایتون رو بشدت دیپ شن. بد نیستا ولی اولویت بندی کنید از بقیه چیزا غافل نشید. خیلیا که با orm کار میکنن اگه ۵ تا سوال sql ازشون بپرسن بلد نیستن چون تو عمرشون زیاد تو دیتابیس نچرخیدن و سرو کله نزدن.

@ManiFoldsPython

پی پست open telemetry که پریروز گذاشتم و معرفیش کردم, یک نفر ممکنه بگه چرا من بیام این همه داک بخونم و ازش استفاده کنم؟ خودم میرم یک چیزی مینویسم با یک میدلور کارو در میام. Keep it simple و don't overengineer.

خب تو جواب این کار باید بگم که keep it simple با shitty way خیلی فرق میکنه. این open standard که من معرفی کردم specificationاش توسط system designer هایی تهیه شده که سال ها با این چالشا درگیر بودن و پشت هر تصمیم دیزاینی که وجود داره کوله باری از تجربه هست. از شرکت های بزرگی هستن و رو پروداکت های بزرگی کار کردن مثل datadog یا aws cloudwatch.

نیازه سیستم مانیتورینگ و یا observability اینه که اگه خوده بک اند یا بقیه سرویسا پایین بیان نباید این سرویس پایین بیاد. مثلا بیاین فرض کنیم از همون دیتابیسی که برای monitoring استفاده کردیم برای بک اند و جنگومون هم بکنیم. خب اگه داون شه جفتش باهم داون میشن. و وقتی جفتش باهم داون شن سیستم سایلنت میشه یعنی دیگه نمیفهمیم اکسپشن رخ داده. خب این دلیل وجود خوده سیستمی که دیزاینش کردیم رو زیرسوال میبره نه؟

پس همیشه مرز بین shitty way رو بدونید با کار استاندارد. keep it simple یعنی شما تو نسخه اول استفادتون بیاین از همون sdk و لایبری هایی که خودش داره استفاده کنید که سریع خروجی رو ببینید و ایا ببینید به دردتون میخوره و بیزنستون در حدی بزرگ شده که بخواد این مفید باشه براتون؟ ‌بعد برین دورش کد بنویسید و لایبری های instrumentationاش رو کاستومایز کنید.

@ManiFoldsPython

یه جمله خیلی بامسما در کتاب Clean Code in Python هست که میگه:

Having maintainable software is not about anticipating future requirements (do not do futurology!)

ترجمه: داشتن یه نرم‌افزار قابل‌نگهداری به معنی پیش‌بینی نیازمندی‌های آینده نیست. (آینده‌پژوهی نکنید!)

اینجا "پیش‌بینی" به معنی تخصیص انرژی و زمان واسه ساخت یه بستر برای توسعه ساده‌تر در آینده با توجه به نیازمندی‌هایی هست که بعدها ممکنه بوجود بیان.

منظور اینه که بجای اینکه بیایم ذهنیت، معماری و دیزاین رو محدود به آینده کنیم، سعی کنیم نیازمندی‌های فعلی رو برطرف کنیم.

یه مثال کاربردی می‌زنم تا درک این قضیه ساده‌تر شه. فرض کنید شما یه Shop طراحی کردید و فقط یه متد پرداخت دارید و اونم PayPal هست. درحالی که دارید کلاس PayPal رو طراحی می‌کنید، این فکر به ذهنتون خطور می‌کنه که شاید بعدها متد پرداخت Stripe هم به سیستم اضافه شد. اونوقت من باید یه کلاس عین PayPal واسه Stripe درست کنم.. چرا از همین الان یه Base Class درست نکنم و PayPal و Stripe از اون بیس‌کلس ارثبری نکنن؟

موضوع اینه که هنوز نه به باره.. نه به داره.. استرایپ کو؟! داری عملا از دیزاین‌پترنی استفاده می‌کنی که اصلا نیازی بهش نداری. بله. درسته. این یه دیزاین OOP پرفکت هست و بهتره که همچین حرکتی رو بزنی ولی آیا الان؟!

اینجاست که Over-engineering کار دست آدم می‌ده. بنظرم این دو موضوع Overengineering و Overthinking در کنار هم میان. تمرکزتون رو بذارید روی نیازمندی‌های فعلی و سعی کنید سلوشن خوب برای الان بدید.. بعدا با تغییر نیازمندی‌ها، می‌تونید سراغ دیزاین‌پترن‌ها و متدلوژی‌ها و معماری‌های پیچیده‌تر هم برید!

میم امشب 😂
@ManiFoldsPython

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

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

@ManiFoldsPython

تو گروه واقعا بحث های جالبی میشه دم همه گرم که فعالن 🙌 بحث کد فانکشنال و 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

من واقعا اینو دیدم.. خیلی هم دیدم که نیروی های ایرانی به مراتب از نظر هارد اسکیل قوی ترن و راحت میتونن استخدام شن تو خارج کشور. ۳ مورد رو اگه تقویت کنید واقعا شانس استخدام شدنتون بالا میره:

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


۲. دومیش رزومست. رزومه غیر استاندارد مینویسن. قبول نمیشه توسط ATS ها. من خیلی افراد سطح بالایی دیدم که رزومشون واقعا ضعیف بود و این باعث کمتر شدن فرصت هاشون میشه. تو هر مقطع و سطحی که هستین باید رزومه رو خوب بنویسید. چه میخواد جونیور باشه چه principal engineer.

ریپو من راجب رزومه نویسی:
https://github.com/ManiMozaffar/awesome-resumes

۳. آخریش نشون دادن مهارته. من دیدم بعضی بچه ها واقعا مهارت خوبی دارن ولی چون تو رزومه و گیت هابشون خوب نتونستن نشون بدن به چشم نمیان. موقع بولت پوینت نویسی برین PR هایی که زدین به ریپو شرکت رو ببینید و یک دور دوره کنید. همین موضوع خودش باعث میشه ۳ سطح بولت پوینت هاتون بهتر شه چون یادتون میره چه کدایی زدین.

پلی لیست من راجب پیدا کردن شغل اول و رشد مسیر شغلی:
https://www.youtube.com/playlist?list=PLEQ3RnweNGA6ccgQkiov9Q6jnQAw8H-ob


من دیدم یک سری دوستان الان پول میگیرن رزومه بررسی میکنند یا از این قبیل کارا میکنن. خب اون دوستان نوش جونشون کار میکنن ولی شما که این همه ریسورس (حداقل تو ایران) ریخته چرا استفاده نمیکنی؟ و بعد میری پول میدی بابت همین چیزایی که رایگان با کیفیت عالی در دسترست هست.. مثل tech immigrant که واقعا کمکتون میکنه تو مسیر مهاجرت کاری, از صد تا موسسه مهاجرت بیشتر.

@ManIFoldsPython

برای اینکه این پستو بهتر درک کنید میخوام ۲ مثال بزنم که overengieering یعنی چی

۱. فرض کنید دارین برنامه چت تحت وب مینویسید که notification نداره. میخواین schedule message بسازین. مثل تلگرام.

۲. فرض کنید میخواین مورد یک رو پیاده کنید ولی این بار رو گوشی باشه و notification هم داشته باشه.

چیکار میکنید؟

@ManiFoldsPython

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

۱. خب من چیکار میکردم؟ تو سناریو اول کلا schedule نمیکردم! به جاش همون لحظه ای که schedule کرده پیام رو داخل دیتابیس میساختم ولی یک فیلد میذاشتم با display_at به زمان آینده که توسط یوزر تعیین شده. و وقتی بقیه کلاینت ها (تو همون گروه تلگرامی) درخواست میفرستن که محتوا رو ببینن فقط محتوایی که display_atشون کمتر مساوی زمان حال بود رو نشون میدادم.
that's it!
نه بروکر نیازه. نه استریم. نه event driven architecture
من تونستم به همون هدفی که requirement ام بوده برسم. که بقیه یوزر ها ببینن پیامو. همیشه وقتی requirement مینوسید رو how تمرکز نکنید. رو what تمرکز کنید. اگه requirement این بود که طرف schedule کنه اونوقت اون requirement احتمالا احمقانه هست چون داره رو نحوه پیاده سازی دخالت میکنه.


@ManiFoldsPython

و در نهایت همین سناریو ساده میتونه پیچیده تر شه...
مثلا تو این مثال میتونیم یک ورکر بذاریم پیام هایی که زمان displayAtشون رسیده و فرانت قراره نشون بده به کلاینت, رو با یک ورکر به صورت periodically بگیریم.

ممکنه بهترین راه کار نباشه. ولی ساده ترینه...

میتونیم هم همین سناریو رو با EventBridge پیاده کنیم. منتهی اشاره نکردم چون ممکنه بعضیا اشنا نباشن و خیلی تمیز تر هندل میشه.

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

این over engineering رو خیلی زیاد دیدم .. بنظرم فقط تو مصاحبه خوبه که یکم نشون بدین بلدین(پز بدین) 😁

@ManiFoldsPython

تو گروه بحث خوبی شد راجب ساید افکت. مهدی سورس خوبی رو گفت که میتونید ساید افکت رو مطالعه کنید و متوجه شین چیه دقیقا. لاگ انداختن ساید افکت نیست.
https://en.m.wikipedia.org/wiki/Side_effect_(computer_science)

من همونطور که اشاره کردم فقط functional نمیزنم. فانکشنال خالی و pure نوشتن اصلا اونقدر ساپورت خوبی نداره تو پایتون. پس بازم OOP هم نیازتون میشه. من خودم ترکیبی مینویسم ولی بیشتر اخیرا سعی میکنم فانکشنال کد بزنم چون ساید افکت نداره و تستش راحت تره. مثال قبلی بد بود. شاید با این مثال بهتر درک کنید:

یک مثال تمیز از داشتن و نداشتن ساید افکت:

class Order
   def deliver(self): ...

def deliver(order: StartedOrder) -> DeliveredOrder:
    .

..


استیت اوردر بعد از اجرای فانکشن دلیور تغییر میکنه. ولی فانکشن دلیور تو مثال دوم یک آبجکت جدید میسازه که میدونیم چیه و side effect نداره و راحت تست میشه.
برای تست کردنش:

result = deliver(order)
assert isinstance(

result

, DeliveredOrder)

# OOP
order.deliver()
assert ... # assert all the side effects now if you dare

@ManiFoldsPython

✔️ در طی چند سال گذشته از فعالیت کانال، محتواهای رایگان زیادی تولید شده و هدف کانال هم از ابتدا اشتراک دانش رایگان و عام المنفعه بوده، برای همین تصمیم گرفتیم یک بار دیگه تمام این محتواهارو در یک پیام قرار بدیم تا به راحتی قابل دسترسی برای افراد علاقمند به یادگیری باشه:

✅🎥 کانال یوتوب سیلیسیم مهران تعریف (آموزش پایتون و جاوااسکریپت و...)
https://www.youtube.com/@Silicium7

✅🎥 کانال یوتوب میکروفرانت اند (آموزش پایتون و جاواسکریپت و ...)
https://www.youtube.com/@MicroFrontend

✅🎥 کانال یوتوب بابی کلاد (آموزش پایتون، کلاد، دوآپس و ...)
https://www.youtube.com/@bobycloud

✅🎥 کانال یوتوب امیر مطهری (آموزش پایتون، میکروپایتون و ...)
https://www.youtube.com/@AmirMotahari

✅🎥 کانال یوتوب گیت اور هیر مانی (آموزش پایتون، دیزاین پترن و ...)
https://www.youtube.com/@GitOverHere

✅🎥 کانال یوتوب تورهام (آموزش پایتون، فست ای پی آی و ...)
https://www.youtube.com/@techwithtori

✅🎥 کانال یوتوب شهریار شریعتی (آموزش سلری، جنگو چنلز، وب فریمورک ها و ...)
https://www.youtube.com/@ShahriarShariati

✅🎥 کانال یوتوب دوآپس هابیز (آموزش امیربهادر - دوره پروژه محور جنگو به همراه داکر، سی آی سی دی و ...)
https://www.youtube.com/watch?v=KtYDIJN3wmM&list=PLYrn63eEqAzY5uG5ks_OquWcojzHvhp9Z

✅🔥 سه فایل مصاحبه با آقای حسن رمضانی که از Core Developer های Django, Gunicorn, Pydantic, Urllib3 و ... هستند در کانال موجود هست که با سرچ کردن اسم آقای "حسن رمضانی" در کانال میتونید مصاحبه هارو پیدا کنید و گوش بدید.

✅📚 ریپازیتوری گیتهاب Awesome Python Resources: مجموعه ای از بهترین و کامل ترین ریسورس‌های مورد نیاز برای رشد در مسیر شغلی مهندسی نرم افزار (پایتون) به همراه تفکیک بر اساس Career Path و Advanced Topics
https://github.com/DjangoEx/awesome-python-resources

✅📚 ریپازیتوری گیتهاب Awesome Python Roadmaps: مجموعه از رودمپ‌های مورد نیاز یک مهندس نرم افزار (پایتون) در Career Path هایی نظیر Backend، Data Scientist، Software Architect و ...
https://github.com/DjangoEx/awesome-python-roadmaps

✅📚 تمام ریپازیتوری‌ها به صورت یکجا نیز در صفحه گیتهاب DjangoEx قابل دسترسی هست
https://github.com/DjangoEx

✅ تمام این موارد آموزشی رایگان هستند و میتونید ازشون استفاده کنید.
✅ موقت: اگر مطلبی رو یادم رفته بزارم و قبلا توی کانال تولید محتوا داشتند لطفا به من (@BobyCloud) پیام بدید.

#رودمپ #پایتون #جنگو #منابع #از_کجا_شروع_کنیم

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

اف تاپیک؛ این بار ولاگ استایل :))

۴ روزه اومدم برلین. واقعا شهر باحالیه. نکته جالبش اینه که هرجور کالچری شما اینجا میبینی… از رستوران ایرانی تو مال بگیر تا کره ای ژاپنی چینی. من حتی از رستوران اِتیوپی هم رد شدم 🤣 و هرکی تو اون رستوران کار میکنه برای اون ملت و فرهنگه. همه انگلیسی حرف میزنن و حداقل تا الان تو برخورد های اول ادمای خیلی مهربون و خوبی بودن 🫠 خیلی قشنگه واقعا مردم اینطوری باهم کنار میان و نمیبینی مثلا بگن “go back to your country” و این چیزا…

تنها چیز مزخرف برلین تا اینجا با اختلاف زیاد هواش بوده… همش سرده همش بارونی ساعت ۳-۴ هم تاریک میشه😂 و کمبود خونه برای اجاره

@ManiFoldsPython

تو این پست میخوام ثبات داده رو بهتون توضیح بدم که به ۲ نوع وجود داره:

بذارین مثال بخوام بزنم که تفاوتشو متوجه شین. مثال خیلی راحت میزنم distributed system هم نباشه. فکر کنید دو تا سیستم دارین که یکی به اون یکی وابسته هست. مثلا یک api ساختین برای جمع آوری دیتا وضعیت آب و هوای همه کشور و شهر های دنیا. و هر پایگاه آب و هوایی هم سیستم خودشو داره و با api ای که شما ساختین حرف میزنه و براتون اطلاعات میفرسته.

دو تا راه حل دارین:
۱. تو هر دقیقه براتون دما اون شهرو بفرستن که میشه strong consistency
۲. هر یک ساعت یک بار تک تک دمای یک ساعت گذشته رو براتون ارسال کنند که میشه eventually consistent. و بعد شما همرو با هم insert کنی تو دیتابیس.

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

اگه یکم بهش فکر کنید و جدول هم ببینید متوجه میشین pros و cons هر روش چیه و به جاش با آگاهی راجب ثبات داده تو اپلیکیشنتون با قاطعیت باید تصمیم بگیرین.

@ManiFoldsPython

خیلیا این مفهوم رو با pull based و push based اشتباه میگیرن... شما میتونید اپی داشته باشین که eventual consistency داشته باشه چه بخواد pull based باشه چه push based.

سیستم های مانیتورینگ معمولا eventual consistency هستن چون هزینه نگه داریشون اینطوری کمتره و latencyشون خیلی مهم نیست و availabilityشون خیلی مهم تره.

سیستم های تراکنشی و بانکی حتما باید actual consistency باشن چرا که خیلی مهمه دیتا درست نمایش داده شه حتی اگه منجر به این شه که بیشتر داون شه سیستم.

@ManiFoldsPython

این مطالب سیستم دیزاین در صورتی که خیلی مهمن ولی جالبه برام اصلا طرفدار نداره (engage نمیگیره). حالا کافیه یک کتاب معرفی کنم ۳۰۰ تا share و لایک میخوره کسیم نمیخونش 😂 به زودی هم فعالیت یوتیوب از سر گرفته میشه‌😁 بگذریم... بریم سره اصل مطلب.

اینا رو برای چی گفتم؟‌بحث وب هوک بود. که چرا بانکا وب هوک نمیدن تو ایران و چرا خوبه که به جای اینکه با api بیایم integrate کنیم با وب هوک کنیم. حالا اصلا وب هوک چیه؟

A webhook in web development is a method of augmenting or altering the behavior of a web page or web application with custom callbacks. These callbacks may be maintained, modified, and managed by third-party users and developers who may not necessarily be affiliated with the originating website or application

خب یعنی چی؟
یعنی همون مثال قبلی, اگه میخواین داده های شهر های مختلف رو بگیرین از پایگاه هاشون, وب هوکشون رو integrate میکنید. url میدین و بهتون درخواست میزنن میگن الان دما تغییر کرد. بعد شما یک درخواست دوباره میزنی و دیتا مورد نظر رو میگیری. اصصطلاحا callback هستند که دیگه لازم نباشه تند تند درخواست بزنیم و ببینیم ایا تغییر کرده یا نه.

خب حالا میریم سراغ سوال بعدی :)‌ تو پست بعدی...

@ManiFoldsPython

خب برگردیم جواب quiz
اگه بخوایم Theory به قضیه نگاه کنیم همونی میشه که من گذاشتم
ولی اگه بخوایم عملی به قضیه نگاه کنیم inconsistent میشه جوابش!

سیستم های وب هوک در واقعیت eventually inconsistent هستند. یعنی شما اگه آپ تایم و خطا پذیری رو درنظر بگیرین امکان داره که مسیجی باشه که دریافت نشه (حالا به دلیل داون بودن شما یا اون سرویس). پس چرا استفاده ازش خوبه و چه محدودیت هایی داره؟

ببینید وقتی دیتا سورس از کنترلتون خارجه وب هوک میتونه بهترین گزینه integrate باشه. یعنی مثال مثالی که زدم برای آپدیت وضعیت هوا اگه به جای اینکه شما تند تند درخواست بدی به API و وضعیت رو بگیرین با وب هوک مطلع بشین کی درخواست بزنید بهتره. ولی بازم Strong consistence نیست معمولا. چرا؟ چون معمولا اینطوری کار میکنه که تلگرام مثلا یک پیام میفرستید شما به دوستتون, همون لحظه پیام رو تو دیتابیس ایجاد میکنه. بعد تو لایه پایین تر با بروکرش جاب های دیگه رو هم انجام میده مثل ارسال نوتیفیکشن به گوشی دوستتون یا هندل وب هوک اگه پیامی دریافت شده. پس ذخیره شدن پیام تو دیتابیس و مطلع شدن شما از اون پیام همیشه تاخیری وجود داره. ولی این تاخیر معمولا کمه (اگه مشکل backlog نباشه و ترافیک خیلی بالا نباشه تو سرور تلگرام) در صورتی که شما اگه درخواست بزنید تند تند بازم eventual consistent هست ولی خیلی eventual تره و با تاخیر بیشتریه نسبت به وب هوک.

ولی وب هوک چون eventually inconsistent هست پس همیشه باید یک periodic job بذارین که پیام هایی که دریافت نشدن تو وب هوک رو به صورت periodic چک کنید و ببینید ایا چیزی miss شده یا نه؟ مثلا این periodic job میتونه روزانه باشه یا ساعتی یا هفتگی بسته به نیاز شما. اینکه چقدر یک وب هوک eventually inconsistent هست هم خیلی مهمه. شما باید یک تست کنید قبل اینکه یک webhook رو کاملا integrate کنید. چطوری تست کنید؟‌مثلا ۱۰۰۰ تا پیام بدید به دوستتون و ببینید ایا ۱۰۰۰ تا درخواست گرفتین رو وب هوک یا نه؟‌
همیشه گفتم تو دپندسی خیلی دقت کنید. یک اشتباه رایج اینه که میرن کلی با وب هوک یک اپ integrate میکنن بعد میفهمنن خیلی inconsistent هست و لگ زیادی داره و درواقع اگه تند تند درخواست زده شه بهتره.

@ManiFoldsPython

سیستم دیزاین به عنوان بک اند دولوپر برای شما مهمه.
بحث های چند پست اخر کاربردش میشه مثلا وقتی دارین ربات تلگرام مینویسین یا درگاه بانکی دارین اتصال میکنید یا با third party application دارین integration انجام میدین. حتما یکی از این کارا رو انجام دادین اگه حداقل ۱ ساله که کار میکنید .... 🙂

@ManiFoldsPython

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

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems - Kleppmann, Martin

System Design Interview – An insider's guide

بالایی خوندم. پایینی رو هم به زودی سفارش میدم و میخونم 😁 تعریفشو خیلی شنیدم.
@ManiFoldsPython