CodeCrafters

تو کشور خیلی عجیبی زندگی میکنیم خانواده الهه برای صدور اشد مجازات باید نصف دیه رو به دادگاه پرداخت کنن (قاتل مرد هستش و دیه زن نصف مرد هستش) این در حالیه که کل جامعه ایران تو شک و عدم امنیت قرار گرفتن و عالی ترین دادستان کشور و رییس قوه قضاییه تا کنون هیچگونه گفتگوی رسمی و مستقیمی با مردم رو نداشتن بدترین کابوس جاییه که بابک زنجانی (بزرگترین سارق ایران که از جیب تک تک ماها دزدی کرده) اومده توییت زده و در خصوص قتل الهه گفته که باید تاکسی دات‌وان راه بندازیم که امنیت مالی و جانی برای شهروندان داره و منتظر خبرهای خوب در این زمینه از ایشون باشیم (خبر خوب از دزد یا بهتره بگیم دار و دسته چهل دزد بغداد) میدونی مشکل چیه؟؟؟ هیچ‌تفاوتی بین قاتل الهه با زنجانی وجود نداره، همونجور که قوه قضاییه مجرمان سابقه دار خودش رو بدون رصد در جامعه ول کرده و باز هم میکنه (نمونه اون بابک زنجانی و قاتل الهه) فقط برام سوال سد قوه قضاییه با دریافت این همه امکانات و اختیارات و بودجه‌های کلان، چطور نمیتونه وظیفه خودش رو به نحو احسنت انجام بده، از شدت این همه بی مسئولیتی در مهمترین قوه کشور داریم به این نتیجه میرسیم که افراد عادی جامعه رو جهت محافظت ازشون زندانی کنیم تا افراد مجرم راحتتر زندگی کنند #موقت

دوستان سی شارپ و .net سطح ارشد کار حضوری در تهران (قرارداد اولیه سه ماهه) برام رزومه بفرستید (بازه حقوقیتون رو هم اعلام کنید) #موقت

وقتی جهان رو نگاه میکنی و طبیعتش متوجه میشی این زیستگاه حیوانات و مناسب حیوانات هستش و انسان دارای تفکر و هوشی هستش که نظیر اون در مابقی حیوانات ذره‌ای وجود نداره به دوگانگی ضدیت ذهن و طبیعت که نگاه میکنی پی میبری که اساسا انسان متعلق و مناسب با این طبیعت نیست و رنج برای انسان یک واقعیت است شاید به قول ژیژک بجای نگاه به درون بهتره که تمایل به یکی شدن با ماسک‌هایی پیدا کنیم که برای خود گذاشتیم

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

وقتی یک پل از کتاب‌ها به شخصیت خودت پیدا میکنی معمولا خوندن کتاب‌های فلسفی زمخت و سخت هستش (برای مایی که آدم‌های معمولی هستیم) به هرحال چه بخواهیم یا نه نیازه که راجبشون بخونیم چون هستی زندگی انسان رو تشریح می‌کنند در این وسط خوندن رمان‌های فلسفی خالی از لطف نیست داشتم به داستان کتاب دمیان فکر میکردم شخصیت داستان یک نوجوان هستش که در حال عبور به دنیای بزرگ سالی و بلوغ هستش که درگیر کشمکش درونی و اخلاقی قرار گرفته، بین شخصیتی که خونواده براش ساختن و شخصیتی که خودش در جامعه داره شکل میده برای خودش در نگاه اول کتاب مثه همه رمان‌های معمولی هستش تا اینکه سعی میکنه خواننده رو ترغیب کنه تا یک پل به زندگی خودش با کتاب ایجاد کنه متوجه شدم که از خود گذشتگی و تلاش بی اندازه برای کمک به اطرافیانم ریشه در شخصیتی داره که از خونواده برام شکل گرفته، سخت ترین بخشش جایی بود که پی بردم نه تنها خودم بلکه کل اعضای خونواده با این مکانیسم رفتاری روبرو هستیم و داستان‌هایی رو مرور کردم که چطور نه تنها به خودم بلکه کل اعضای خونواده ازش یجاهایی آسیب دیدیم و چنان در طول زندگی دسته جمعی باهاش درگیریم بودیم که هیچوقت متوجهش نشدیم و حالا همون کشمکش شخصیت داستان اومده سراغ خودم و سوالات زیادی برام مطرح کرده اینکه ادامه این از خودگذشتگی و فداکاری در بعضی جاها تبدیل شده به نادیده گرفتن خودم، اینکه آنچه سالها فکر میکردم یک موضوع اخلاقی درست هستش بیشتر یک ریشه روانی (قطع به یقین ناسالم) داره بیشتر ازون چیزی که فکر کنیم در جبری به سر میبریم که منشا اون نامشخص هستش بگردید و ریشه برخی از رفتارهاتون رو که تصور میکنید درست و اخلاقی هستش میفهمید از یک الگو در خونواده شکل گرفته که با وجه اخلاقی داره بهتون صدمه میزنه #موقت

Redirection - بخش اول پروتکل HTTP به تنهایی برای تمام نیازهای ارتباطی وب کافی نیست. گاهی اوقات پیام‌های کاربر تا رسیدن به سرور اصلی از مسیرهای مختلفی عبور می‌کنند و بین چندین سرور جابه‌جا می‌شوند. این مسیرهای پیچیده می‌توانند باعث تاخیر یا حتی نرسیدن پیام به مقصد شوند. Redirection یکی از راهکارهایی‌ست که برای بهینه‌سازی این فرایند استفاده می‌شود. چرا از Redirection استفاده می‌کنیم؟ هدف اصلی Redirection سریع‌تر شدن ترنزکشن‌ها و کاهش زمان انتظار کاربر است. مثلا ممکن است درخواست کاربر به سروری نزدیک‌تر فرستاده شود تا با سرعت بیشتری پاسخ دریافت شود. ریدایرکشن چگونه انجام می‌شود؟ ریدایرکشن می‌تواند در لایه‌های مختلفی انجام شود. گاهی مرورگر طوری تنظیم می‌شود که درخواست را به یک پروکسی سرور بفرستد. گاهی هم DNS resolver آدرس یک سرور دیگر را ارائه می‌دهد. حتی در برخی موارد این روترها یا سوییچ‌ها هستند که مسیر پیام را مشخص می‌کنند. گاهی هم خود وب‌سرور تصمیم می‌گیرد پیام را به سرور مناسب‌تری منتقل کند. HTTP Redirection یکی از روش‌های رایج برای این موضوع، ارسال HTTP Redirection با کد ۳۰۲ است. فرض کنید یک Load Balancer دارید که وظیفه‌اش تقسیم درخواست‌ها بین چند سرور است. کاربر A درخواست خود را به لود بالانسر می‌فرستد و پاسخ ۳۰۲ دریافت می‌کند که در آن آدرس سرور مناسب قرار دارد. حالا مرورگر باید درخواست را به این آدرس جدید ارسال کند. این‌که لود بالانسر بر چه اساسی تصمیم‌گیری می‌کند، موضوعی‌ست که در آینده به آن خواهیم پرداخت. البته یکی از مشکلات این روش، نیاز به ارسال چند درخواست برای رسیدن به سرور نهایی است که باعث افزایش تاخیر می‌شود. DNS Redirection زمانی که کاربر می‌خواهد به سایت codecrafters.ir دسترسی پیدا کند، DNS resolver باید این نام دامنه را به یک IP تبدیل کند. این IP می‌تواند از منابع مختلفی مثل مرورگر، DNS سرور شبکه یا منابع دیگر بیاید. ما می‌توانیم DNS سرور را طوری تنظیم کنیم که هر بار IP متفاوتی ارائه دهد. این کار می‌تواند به روش ساده‌ای مثل round robin انجام شود یا با تحلیل متریک‌های پیچیده‌تر، تصمیم بهتری بگیرد. در بخش بعدی به روش‌هایی مثل Anycast Addressing و IP-MAC Forwarding می‌پردازیم. #http_guideline @code_crafters

قسمت دوم: نودها سودشون چیه و پروژه‌های کریپتو چرا عاشقش شدن؟ خب، تا اینجا فهمیدیم IPFS چطوری داده‌ها رو بین نودهای شبکه پخش می‌کنه و چطور آدرس‌دهی‌ش مبتنی بر محتوا (Content Addressing) هست، اما سوال اصلی اینه: نودها چجوری سود می‌کنن؟ نودها (همون کامپیوترهایی که داده‌ها رو نگه می‌دارن و بین همدیگه رد و بدل می‌کنن) تو IPFS یه چیزی بیشتر از یک نقش ساده دارن: ذخیره‌سازی و اشتراک‌گذاری داده‌ها: نودها فایل‌ها رو نگه می‌دارن و وقتی کسی درخواست داد، سریع اون فایل رو ارسال می‌کنن. پاداش برای سرویس‌دهی: پروژه‌های مبتنی بر IPFS، مخصوصاً تو دنیای کریپتو و Web3، معمولاً برای نودهایی که بیشتر و بهتر خدمات میدن پاداش میدن. یعنی هر چقدر یک نود داده‌ها رو سریع‌تر و مطمئن‌تر تحویل بده، سود بیشتری می‌بره. استفاده از توکن‌ها: شبکه‌های ذخیره‌سازی غیرمتمرکز مثل Filecoin که بر پایه IPFS ساخته شده، به نودها توکن Filecoin میدن به عنوان پاداش. این توکن‌ها میشه در بازارهای کریپتو معامله کرد و سود واقعی ازشون گرفت. چرا پروژه‌های بزرگ کریپتو مثل Chainlink و غیره IPFS رو انتخاب کردن؟ Chainlink و ذخیره‌سازی داده‌های اوراکل: Chainlink که نقش اوراکل‌های امن رو بازی می‌کنه، نیاز داره داده‌ها رو جایی امن، سریع و غیرمتمرکز ذخیره کنه. IPFS این امکان رو بهش میده تا داده‌ها رو بدون وابستگی به یک سرور خاص، بین هزاران نود توزیع کنه و تضمین کنه که داده‌ها دستکاری نشدن. غیرمتمرکز بودن و امنیت: پروژه‌هایی که امنیت و اعتماد بالا براشون مهمه، به IPFS تکیه می‌کنن چون امکان سانسور و از بین رفتن داده تقریبا صفر میشه. مقیاس‌پذیری: IPFS به دلیل ساختار توزیع‌شده، مقیاس‌پذیری خیلی بهتری نسبت به سیستم‌های سنتی ذخیره‌سازی داره. برای پروژه‌های کریپتو که روز به روز بزرگ‌تر میشن، این موضوع حیاتی محسوب میشه. پروژه‌های معروف دیگه که IPFS دارن استفاده می‌کنن: ایک-Filecoin: شبکه ذخیره‌سازی غیرمتمرکز که با IPFS کاملا یکپارچه شده و توکن مخصوص به خودش رو داره. دو-اArweave: پروتکلی برای ذخیره دائمی داده‌ها، که IPFS هم بهش کمک می‌کنه. سه=Unstoppable Domains: استفاده از IPFS برای ساخت دامنه‌های وب غیرقابل سانسور. چهار-Audius: پلتفرم موزیک غیرمتمرکز که IPFS رو برای نگهداری موزیک‌ها و داده‌ها استفاده می‌کنه. #ipfs #web3 @code_crafters

یو یو, ipfs چیست؟(InterPlanetary File System)

یک پروتکل غیرمتمرکز برای ذخیره‌سازی و شتراک‌گذاری داده‌هاست که با استفاده از آدرس‌دهی مبتنی بر محتوا (Content Addressing) و به روش p2p ، اطالاعت رو بین نودهای مختلف توزیع میکنه. برخلاف سیستم‌های متمرکز که به سرورهای خاص وابستن IPFS امکان دسترسی سریع‌تر، امن‌تر و مقاوم‌تر به داده‌ها را فراهم می‌کنه دقیقا مثل چیزی که در ساختار بیت کوین وجود داره.همه چیزو خود مردم مدیریت میکنند بدون وابستگی به دولت ها یا یک قدرت متمرکز.

تفاوت آدرس ها امروزه وقتی یک دیتا رو ذخیره میکنیم یک URL منحصر به فرد داره که آدرس اون هست.

"C:\Program Files\Epic Games

اما در ipfs آدرس دهی مبتنی بر content addtessing هست. به‌جای اشاره به مکان ذخیره‌سازی، داده‌ها با یک هش (Hash) منحصربه‌فرد که همیشه با Qm شروع میششن شناسایی میشن.

QmQ3hUpzcze4ASWwmo42M4ZG6ALYsqjY6wyw694vRbPtcV

این روش باعث میشه که اگر محتوای فایل تغییر کنه، هش اونم تغییر کنه. در نتیجه، داده‌ها قابل تأیید هستن و نمی‌شه اونا رو دستکاری کرد بدون اینکه کسی متوجه بشه. چطور کار می‌کنه؟ وقتی فایلی رو در IPFS آپلود می‌کنید، اون به بخش‌های کوچک تقسیم و بین نودها پخش می‌شه. هر بخش یه هش داره و کل فایل با یک هش اصلی شناسایی می‌شه. برای دسترسی، فقط کافیه هش رو وارد کنید، چرا IPFS مهمه؟ غیرمتمرکز و ضدسانسور: هیچ نهاد مرکزی نمی‌تونه داده‌ها رو حذف یا محدود کنه. سرعت و صرفه‌جویی: داده‌ها از نزدیک‌ترین نودها بارگذاری می‌شن(این موضوع و چگونگی کار کردنش یکم پیچیده به نظر میاد) غیر متمرکز بودنش باعث میشه اگه یک نود آفلاین بشه، داده‌ها از نودهای دیگه بارگذاری بشن و درواقع هیچوقت این چرخه از بین نمیره فارغ این از که ipfs تو شبکه‌های ویدئویی و استریم P2P یا میزبانی وبسایت ها یا بدیهی ترینش ذخیره داده کاربرد داره ,در DApps ههم خیلی کاربرد داره و با بلاکچین ادغام میشه(نقطه عطف🔥) بلاکچین به تنهایی برای ذخیره‌سازی داده‌های بزرگ مثل تصاویر، ویدئوها یا اسناد مناسب نیست، چون هر نود در شبکه باید یک کپی از کل بلاکچین را نگه داره که این کار هزینه‌بر هستش و اون رو ناکارآمد میکنه. IPFS این مشکل راو به خوبی درک کرده و به راحتی میتونه این ضعف بلاکچین رو پوشش بده .،این ویژگی‌ها با اصول بلاکچین، یعنی امنیت، شفافیت و غیرمتمرکز بودن، هم جهت و هم راستا هست. #ipfs #web3 @code_crafters

ینفر سئو‌کار لازم دارم بابت یه پروژه بررسی کنه با ابزارهای خاصی و بهمون یه نتیجه بگردونه و ادامه کار هم خودش پیش ببره #موقت

حضور CTEs در دیتابیس و محدودیت ormها بیایید با یک مثال براتون توضیح بدم، یک پیچیدگی نسبتا معمولی در دیتابیس و کوئری‌ها یک مدل رو تصور کنید که دوتا فیلد داره class Model: id: int(PK) name: str parent: FK(self, null) در نگاه اول این یک مدل کاملا ساده هستش و کاملا هم درست فکر میکنید این یه مدل ساده و ابتدایی هستش، اما منطق تجاری؟؟؟ منطق تجاری از ما میخواد که در ازای یک کوئری تمام والد‌های اون object رو بدست بیاریم، تصور کنید که ریشه‌های تو در تو داخل مدل برای یک object حدود 100 والد وجود داره و برای یک object دیگه ممکنه 1000 والد وجود داشته باشه، منطق تجاری از ما خواسته والد هر آبجکتی که درخواست میشه از مدل رو هم بهش برگردونیم، در دید اول این یک مسئله ساده هستش اما یک منطق تجاری نسبتا پیچیده هستش خود CTEs ها در دیتابیس چیه؟ بطور خلاصه یک‌نمای جدولی موقتی هستش که فقط و فقط در طول اجرای همون کوئری وجود دارند. داخل زبان کوئری با استفاده از With همراه با join و on ما یک ساختار درختی رو متصور میشیم و داده مدنظر خودمون رو ازش میکشیم بیرون. جدول موقت اولین گام برای ورود به ادمین پایگاه داده شدن هستش شاید تعجب کنید از این حرف ولی حقیقت داره، در مثال ما یک منطق نسبتا پیچیده مطرح شد (از نوع CTE بازگشتی) کاربرد اصلی CTE در تحلیل داده و مهندسی داده خودش رو نشون میده چرا محدودیت در orm گفتیم؟؟ در orm ها موارد cte مطرح و پیاده سازی نشده چرا که دلیل اون این هستش که orm ها طراحی شدن بابت queryset های معمولی و نه بابت انجام کوئری‌های پیچیده، اینجاست که تو مثال بالا که مطرح کردیم اگه بخوایم از orm استفاده کنیم دچار محدودیت میشیم برای مثال اگه از prefetch استفاده کنیم محدود به انتخاب سطح میشیم بصورت دستی، اگه از زبان‌های برنامه نویسی بهره ببریم کارایی و کندی میاد سراغمون، به هر حال تصور درختی دیتابیسی که چندین میلیون رکورد داخلش هست کار راحتی نیستش، به اجبار باید سراغ CTEها بریم واسه بچه‌هایی که با جنگو کار میکنند یکم تایم بزارید و django-cte و django-treebeard رو بخونید کتابخونه‌های زیادی احتمالا پیدا بشه منتها این دوتا رو معرفی میکنم که بابت دو سناریوی مختلف مناسب هستند که خودتون بخونید راجبشون #sql #django @code_crafters

نوشتن یا بررسی یک نرم افزار رو از کجا شروع کنیم؟؟؟ سوالی که همیشه وجود داره حتی تو مصاحبه‌های استخدامی گاها وقت‌ها حس میکنم اون چیزی که یاد میگیریم و راجبش میخونیم رو یجوری محدود میکنیم که واقعا از گزینه‌های بیشتری که بهمون میده رو فراموش میکنیم یک نرم افزار از بیرون سه تا بخش داره view service model چرا میگیم این سه بخش و بالاتر گفتم محدود؟ دو شیوه توسعه نرم افزار مهم رو به یاد بیارید DDD و TDD علاوه بر اینکه این دو رویکرد تمام جنبه‌های خاص رو مورد پوشش قرار میدن موارد انتزاعی هم بهمون تدریس میکنن که یکی از اونها سوال اولمون بود؟؟؟ از کجا شروع به نوشتن یا بررسی کنیم در رویکرد DDD میگه اول سرویس‌هات رو بنویس و بعد لایه داده و ویوت رو مطابق با اون پیش ببر (در ابتدای نوشتن از فیک دیتا بهره ببر) چرا این رویکرد جالبه برامون، چون ما هیچ درکی از پیچیدگی نداریم و هیچ درکی هم از تمام نیازمندی داده هم نداریم، وقتی DDD میاد وسط هم پیچیدگیت مشخص میشه و هم درکت از نیازمندی داده، تو شروع پروژه کمتر مدلت رو لمس میکنی یا بهتره بگیم مدام و مدام مدل‌هات رو لمس نمیکنی و درکت از داده بیشتر میشه، این از اتلاف وقت و هزینه برای سازمان جلوگیری میکنه و بهمون میگه با چه چیزی قراره روبرو بشیم تو روش TDD میگه بیا اول تست بنویس بعد حالا اون رو پاس کن، که از ویوهامون شروع میکنی، چه اتفاقی میافته؟؟؟ انتظارمون کاملا مشخص میشه و این منجر میشه ویوهای کامل و جامعتری داشته باشیم و بدونیم چی لازم داریم بابتش و باز همین منجر میشه کمتر مدل رو لمس کنی و تغییر بدی، انتظارت از خروجی کاملا مشخص هستش و بدهی فنی رو به حد مناسبی میرسونه که لازمه یک پروژه هستش، صرف زمان اولیه داره اما بازخورد دورنگر بهتری بهمون میده این دو رویکرد منجر به برطرف کردن بدفهمی و کج فهمی‌های مدل سه لایه میشه و خب بسیار عالی ولی از کجا بدونیم کدومش رو کجا بکار ببریم؟؟؟ اگه با یک سیستم دارای پیچیدگی روبرو هستید DDD اگه با یک سیستم با اطمینان بالا روبرو هستید TDD آیا رویکرد بهتری سراغ داریم؟؟؟ بله ترکیب این دو با هم

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

#DDD #TDD @code_crafters

سری الگوهای طراحی میکروسرویس‌ها — بخش سوم تو بخش اول، با مفاهیم پایه‌ی میکروسرویس‌ها آشنا شدیم و الگوهای رجیستری سرویس و مش سرویس رو بررسی کردیم و تو تو بخش دوم هم الگوهای مدار شکن و منبع‌یابی رویداد رو دیدیم که چطور به پایداری و تاریخچه‌نگاری سیستم کمک می‌کنن. حالا تو بخش سوم، قراره با دو تا الگوی مهم دیگه آشنا بشیم: الگوی SAGA و الگوی API Gateway. این دو الگو بهمون کمک می‌کنن تا هماهنگی داده‌ها و دسترسی به سرویس‌ها رو تو سیستم‌های پخش‌شده بهتر مدیریت کنیم. 5. الگوی SAGA (SAGA Pattern) الگوی SAGA یه روش کارآمد برای مدیریت هماهنگی داده‌ها تو تراکنش‌های پخش‌شده بین میکروسرویس‌هاست. تو سیستم‌های سنتی، تراکنش‌ها با مدل ACID مدیریت می‌شن که تضمین می‌کنه همه‌چیز یا کامل انجام بشه یا اصلاً انجام نشه. اما تو معماری میکروسرویس، که هر سرویس دیتابیس خودش رو داره، پیاده‌سازی این مدل خیلی سخته. اینجاست که الگوی SAGA یه راه‌حل هوشمندانه ارائه می‌ده. چطور کار می‌کنه SAGA؟

تو این الگو، یه تراکنش بزرگ به چند قدم کوچیک‌تر تقسیم می‌شه که هر کدومش رو یه سرویس انجام می‌ده. هر قدم یه پیام یا رویداد منتشر می‌کنه که باعث فعال شدن قدم بعدی می‌شه. اگه یه قدم به مشکل بخوره، یه سری عملیات جبرانی (Compensating Transactions) اجرا می‌شن تا وضعیت به حالت اولیه برگرده. دو نوع هماهنگی در SAGA: 🔹 کروئوگرافی (Choreography): هیچ هماهنگ‌کننده‌ی مرکزی نداریم. هر سرویس یه رویداد منتشر می‌کنه و بقیه سرویس‌ها خودشون به اون گوش می‌دن. مثلاً سرویس سفارش یه رویداد «سفارش ثبت شد» می‌فرسته، سرویس انبار اینو می‌شنوه و موجودی رو کم می‌کنه. این روش تو سیستم‌های ساده خوبه، ولی تو سیستم‌های بزرگ مدیریت سخت می‌شه. 🔹 ارکستراسیون (Orchestration): اینجا یه سرویس مرکزی (Orchestrator) همه‌چیز رو مدیریت می‌کنه. مثلاً اول به سرویس سفارش می‌گه سفارش رو ثبت کن، بعد به سرویس پرداخت دستور می‌ده پول رو بگیره. مدیریتش متمرکزه و برای سیستم‌های پیچیده بهتره، ولی نقطه‌ی شکست هم می‌تونه باشه.

یه مثال ساده: تو یه فروشگاه آنلاین، وقتی سفارشی ثبت می‌کنید، چند مرحله باید طی بشه: سرویس سفارش، سفارش رو ثبت می‌کنه. سرویس انبار، موجودی رو کم می‌کنه. سرویس پرداخت، مبلغ رو برداشت می‌کنه. اگه پرداخت موفق نباشه، عملیات جبرانی فعال می‌شن: موجودی انبار برمی‌گرده و سفارش لغو می‌شه. اینطوری مطمئن می‌شیم که هیچ چیزی نصفه نمی‌مونه. چرا SAGA مهمه؟ تضمین هماهنگی داده‌ها تو سیستم‌های پخش‌شده مدیریت درست خطاها با عملیات جبرانی مناسب برای معماری‌های مدرن که نمی‌تونن از تراکنش‌های سنتی استفاده کنن

6. الگوی API Gateway (API Gateway Pattern) الگوی API Gateway یه راه‌حل برای ساده‌سازی و مدیریت دسترسی به میکروسرویس‌هاست. تو سیستم‌های پخش‌شده، معمولاً سرویس‌های زیادی وجود دارن که هر کدوم وظیفه خاصی دارن. اگه کلاینت‌ها (مثلاً اپ موبایل یا وب) بخوان مستقیماً با هر سرویس ارتباط برقرار کنن، کار خیلی پیچیده می‌شه. اینجاست که API Gateway وارد می‌شه و همه‌چیز رو ساده‌تر می‌کنه. چطور کار می‌کنهAPI Gateway ؟ مثل یه دربان هوشمند جلوی سیستم می‌ایسته. هر درخواستی که از سمت کاربر میاد، اول وارد API Gateway می‌شه، بعد اون تصمیم می‌گیره این درخواست باید به کدوم سرویس بره.

وظایف کلیدی API Gateway: هدایت و تعادل بار (Routing and Load Balancing): درخواست‌ها رو بر اساس قوانین به سرویس درست می‌فرسته و با پخش بار بین نسخه‌های مختلف، سیستم رو پایدار نگه می‌داره. ترجمه پروتکل (Protocol Translation): می‌تونه درخواست‌های HTTP رو به فرمت‌های دیگه (مثل gRPC) تبدیل کنه تا با سرویس‌های بک‌اند سازگار بشه. تغییر درخواست (Request Transformation): درخواست‌ها و پاسخ‌ها رو بر اساس نیاز سرویس‌ها تغییر می‌ده، مثلاً پارامترها یا هدرها رو تنظیم می‌کنه. کش کردن (Caching): با ذخیره داده‌ها، سرعت رو بالا می‌بره و بار رو از روی سرویس‌ها کم می‌کنه. هدایت و تعادل بار (Load Balancing) بین چند سرور یه مثال ساده: فرض کنید یه اپلیکیشن خرید دارید. به‌جای اینکه اپ مستقیماً با سرویس سفارش، پرداخت و ارسال ارتباط بگیره، همه درخواست‌ها می‌رن سمت API Gateway. اونجا اول اعتبارسنجی انجام می‌شه، بعد درخواست به سرویس مربوطه فرستاده می‌شه، و اگه لازم باشه، جواب کش می‌شه تا سریع‌تر به دست کاربر برسه. چرا API Gateway مهمه؟ دسترسی به سرویس‌ها رو متمرکز و ساده می‌کنه امنیت و نظارت رو از یه نقطه انجام می‌ده به مقیاس‌پذیری، پایداری و مانیتورینگ سیستم کمک می‌کنه

#microservice #design_patterns @code_crafters

از بچه‌هایی که سیستم عاملشون ویندوز هست یه سوال داشتم حالتون خوبه؟؟؟ #موقت

رمان گرگ بیابان از هرمان هسه قبل از هرچیزی عمیقا باور کردم که این کتاب رو خدا و شیطان باهم نوشتند موضوع کتاب ارجاع به درون انسان هستش، خویشتن‌های درونی هر انسانی اما بر خلاف خیلی از کتاب‌های دیگه به بخش تاریک و ترسناک درون انسان پرداخته و در تقابل روح پاک و پلید انسان و چگونه پیروز شدن پلیدی بر پاکی در درون می‌پردازد درک سطر به سطر کتاب برام سخت بود در یک کلام چنین شاهکار وحشتناکی رو تا کنون نخونده بودم، خوندنش رو به هرکسی توصیه نمیکنم، منتها اگر حس میکنید روحتون در بالاترین حالت پذیرش درونتون قرار داره بخونیدش یک بخش از کتاب برای خودم خیلی ترسناک بود #book @code_crafters

4-الگوی Event Sourcing حالا تصور کنید یدیه دفترچه خاطرات دارید که هر چیزی تو زندگیت توناتفاق می‌افته رو توش می‌نویسیید: امروز چی خریدید، کجا رفتید، چی گفتی. اگه بخوادی یه روز خاص رو یادتون بیاد، فقط کافیه دفترچه رو باز کنید و اون صفحه رو بخونید. الگوی Event Sourcing به همون منبع یابی رویداد تو میکروسرویس‌ها هم یه همچین چیزیه تقریبا. جای اینکه فقط حالت فعلی سیستم (مثل موجودی حساب بانکی) رو ذخیره کنید، هر اتفاقی که تو سیستم می‌افته رو به‌عنوان یه ایونت ثبت می‌کنید. بعد هر وقت بخوایذ، می‌تونیذ این رویدادها رو بخونیذ و حالت سیستم رو بازسازی کنی. اجزای اصلی این الگو:

ا(Event): مثل یه خط تو دفترچه‌ست. مثلاً «کاربر X صد تومن واریز کرد». هر ایونت یه تغییر تو سیستم رو نشون می‌ده. ا(Event Store): همون دفترچه خاطراته! همه رویدادها رو به ترتیب و بدون امکان تغییر ذخیره می‌کنه. ا(Event Handler): مثل یه کتابدار که می‌ره تو دفترچه، ایونت رو می‌خونه و سیستم رو به‌روزرسانی می‌کنه. ا(Aggregate): یه گروه از ایونت هایی مرتبط که با هم یه داستان کامل (مثل لاگ یه حساب بانکی) رو تعریف می‌کنن. ا(Event Stream): تاریخچه ایونت هایی یه چیز خاص (مثلاً همه تراکنش‌های یه حساب). ا(Event Publisher): مثل یه پستچی که خبر رو به بقیه می‌رسونه، ایونت رو به سرویس‌های دیگه می‌فرسته. ا(Event Subscriber): سرویس‌هایی که منتظرن خبر جدید برسه و باهاش کار کنن. ا(Command): درخواست‌هایی که کاربر می‌فرسته (مثل «پول واریز کن») و باعث می‌شن یه ایونت جدید ساخته بشه.

مثال:

این دفعه تصیور کنید یه اپلیکیشن بانکی دارید. به جای اینکه فقط موجودی حساب کاربر رو تو دیتابیس ذخیره کنید، هر تراکنش (مثل واریز، برداشت، یا انتقال) رو به‌عنوان یه رویداد ثبت می‌کنیذ. مثلاً: رویداد 1: «100 تومن واریز شد» رویداد 2: «50 تومن برداشت شد» اگه بخواید موجودی حساب رو ببینی،د سیستم همه رویدادهای اون حساب رو می‌خونه و محاسبه می‌کنه: 100 - 50 = 50 تومن. این روش نه‌تنها تاریخچه کامل رو نگه می‌داره، بلکه اگه بخواهید حسابرسی کنید یا خطایی رو پیدا کنید، خیلی راحت می‌تونید همه‌چیز رو بررسی کنید. همچنین مقیاس پذیری ,حسابرسی و انعظاف پذیری از ویژگی های Event Sourcing به حساب میان.

کلام آخر این که تو این بخش، دو تا الگوی خفن دیگه رو بررسی کردیم:Circuit Breaker که مثل یه نگهبان جلوی خرابی‌های بزرگ رو می‌گیره(مثل بتمن🥸)، و Event Sourcing که مثل یه دفترچه خاطرات همه‌چیز رو ثبت می‌کنه. #microservice #design_patterns @code_crafters

سری دیزاین پترن میکروسرویس‌ها — بخش دوم تو بخش اول، سرکی کشیدیم تو میکروسرویس‌ها فهمیدیم چرا دیزاین پترن مثل یه جعبه‌ابزار برای توسعه‌دهنده‌ها مهم‌ان، و دو تا الگوی بکاربردی به اسم رجیستری سرویس و مش سرویس رو بررسی کردیم. حالا تو بخش دوم، قراره دو تا الگوی دیگه رو مورد بررسی قرار بدیم: Circuit Breaker Pattern (الگوی مدار شکن😂) وEvent Sourcing Pattern(یافتن منبع رویداد)یکیشون جلوی خرابی‌های بزرگ رو می‌گیره، اون یکی تاریخچه سیستم رو نگه می‌داره تا هیچ‌وقت چیزی از دست نره! 3- مدار شکن (Circuit Breaker Pattern) تصور کنید تو یه خونه پر از وسایل برقی هستید. اگه یه دستگاه شروع کنه به خرابکاری و فیوز بپره، کل برق خونه قطع می‌شه. حالا Circuit Breaker و میکروسرویس‌ها یه جور فیوز هوشمند عمل می‌کنه. وقتی یه سرویس شروع می‌کنه به قاطی کردن (مثلاً چون شلوغه یا خاموشه)، این الگو می‌فهمه و نمی‌ذاره بقیه سرویس‌ها هم به مشکل بخورن. چطور؟ با قطع موقت ارتباط با سرویس خراب و دادن یه فرصت بهش که خودشو درست کنه! اCircuit Breaker چطور کار می‌کنه؟

صور کنید یه سرویس مثل یه لامپه. مدار شکن سه تا حالت داره: بسته (CLOSED): لامپ سالمه، همه‌چیز رواله، درخواست‌ها راحت می‌رن و میان. باز (OPEN): لامپ سوخته یا اتصالی کرده! مدار شکن درخواست‌ها رو بلاک می‌کنه تا سرویس فرصت داشته باشه درست بشه. نیمه‌باز (HALF OPEN): لامپ انگار داره کم‌کم روشن می‌شه. مدار شکن یه چند تا تست می‌کنه ببینه سرویس دوباره اوکیه یا نه. اگه اوکی بود، همه‌چیز به حالت عادی برمی‌گرده. مراحل کارش چیه؟ چک کردن سلامت: مدار شکن مثل یه دکتر، مدام سرویس‌ها رو چک می‌کنه که حالشون خوبه یا نه. تنظیم حد و مرز: یه سری خط قرمز برای چیزایی مثل تعداد خطاها یا سرعت پاسخ سرویس تعریف می‌کنه. قطع کردن: اگه سرویس از خط قرمز رد شد، مدار شکن می‌گه «دیگه کافیه!» و ارتباط رو قطع می‌کنه. پاسخ جایگزین: به جای اینکه کاربر رو تو تاریکی ول کنه، ممکنه یه پاسخ آماده (مثل داده کش‌شده) بده. امتحان دوباره: بعد یه مدت، مثل یه معلم صبور، یه امتحان از سرویس می‌گیره ببینه درستش شده یا نه.

مثال: سرویس پرداخت یهو قاطی می‌کنه چون کلی آدم همزمان دارن خرید می‌کنن. اگه اCircuit Breakerنباشه، کل سایت ممکنه هنگ کنه, اما با این پترن، سیستم می‌فهمه سرویس پرداخت مشکل داره، درخواست‌ها رو بهش نمی‌فرسته، وپیفام هایی مثل «لطفاً چند دقیقه دیگه امتحان کنیئ». حتی ممکنه یه صفحه کش‌شده نشون بده تا بتونییم بقیه خریدیمون رو ادامه بدیم. خرزمان سرویس پرداخت برگشت، همه‌چیز آروم‌آروم به حالت عادی برمی‌گرده. همچنین تو پایتون، می‌تونیم از کتابخانه CircuitBreaker استفاده کنیم.

Web hosting در روزهای نخستین WWW هنگامی که مردم می‌خواستند محتوایی را در این شبکه به اشتراک بگذارند, می‌بایستی یک ماشین تهیه می‌کردند و با کانفیگ کردن آن در شبکه, اطلاعات ذخیره شده در آن را برای عموم قابل دستیابی می‌کردند. با گذر زمان و رشد این شبکه, شرکت‌ها متوجه شدند که همه مردم نمی‌توانند یک سرور فیزیکی بخرند و آن را کانفیگ کنند. پس شرکت های web hosting تاسیس شدند. در این پیام می‌خواهیم به این بپردازیم که این شرکت‌ها دقیقا چه کاری انجام می‌دادند. Dedicated Hosting: تصور کنید Joe و Mary هرکدامشان یک سایت فروشگاهی دارند. آنها از یک شرکت به نام Irene’s Isp درخواست می‌کنند تا سایت آن‌ها را host کنند. شرکت پروایدر که در رک خود چند سرور دارد, یکی را به Joe و یکی را به Mary می‌دهد که هرکس دامنه سایت آن‌ها را وارد کرد, شرکت پروایدر تصمیم بگیرد که درخواست را به سمت کدام سرور هدایت کند. Virtual Hosting: تا اینجای ماجرا همه چیز خوب بنظر میرسه اما وقتی بحث قیمت سرورا میشه, هیچکس حاضر نیست هزاران دلار برای یک سرور بده که یک سایت ساده رو بیاره بالا! پرووایدر ها تصمیم گرفتند که بجای اینکه به هر مشتری یک سرور گران بدهند, آن سرور را بخش بخش کنند و چندین سایت را روی آن serve کنند. در این موقعیت کلی پول و منابع ذخیره می‌شود. اما این به این معنی نیست که یک سرور چندین سایت را serve می‌کند. بلکه ممکن است replication انجام بشود و ترافیک این سایت ها بین چندین سرور پخش شود! برسی یکی از مشکلات Virtual hosting: تصور کنید دو سایت را روی یک سرور serve می‌کنیم. a.com/index.html b.com/index.html برای دسترسی به این ریسورس‌‌ها یک ریکوئست مانند ریکوئست زیر ساخته و ارسال می‌شود: GET /index.html HTTP/1.0 ما فقط می‌گوییم که از این host فایل index.html را می‌خواهیم اما سرور نمیداند که فایل را از کدام یکی از سایت های موجود بردارد. برای حل این مشکل, در HTTP 1.1 تصمیم گرفتند که URL کامل را ارسال کنند تا وب سرور تصمیم بگیرد به کدام اپلیکیشن درخواست را ارسال کند. اما مشکل این‌ است که این تصمیم بعد از توسعه هزاران اپلیکیشن گرفته شد. تکلیف برنامه های قدیمی چیست؟ 1- ارسال url کامل 2- ارسال port اپلیکیشن 3- ارسال یک ip که isp آن را به یک اپلیکیشن منتسب کرده. 4- ارسال یک header که مشخص می‌کند به کدام برنامه ارسال شود موارد ۱ و ۲ و ۴ تا حدودی مشخص است اما مورد سوم نیاز به توضیح بیشتری دارد. در این روش که بسیار مرسوم است, پرووایدر یک آیپی را به joe می‌دهد که آن را برای سایت خودش استفاده کند. هنگامی که به این ایپی درخواست بزنیم, پرووایدر دقیقا می‌داند که این درخواست برای کدام یک از سرور ها و برای کدام سایت دیپلوی شده روی آن است. #http_guideline @code_crafters

> Mohamad: Web hosting در روزهای نخستین WWW هنگامی که مردم می‌خواستند محتوایی را در این شبکه به اشتراک بگذارند, می‌بایستی یک ماشین تهیه می‌کردند و با کانفیگ کردن آن در شبکه, اطلاعات ذخیره شده در آن را برای عموم قابل دستیابی می‌کردند. با گذر زمان و رشد این شبکه, شرکت‌ها متوجه شدند که همه مردم نمی‌توانند یک سرور فیزیکی بخرند و آن را کانفیگ کنند. پس شرکت های web hosting تاسیس شدند. در این پیام می‌خواهیم به این بپردازیم که این شرکت‌ها دقیقا چه کاری انجام می‌دادند. Dedicated Hosting: تصور کنید Joe و Mary هرکدامشان یک سایت فروشگاهی دارند. آنها از یک شرکت به نام Irene’s Isp درخواست می‌کنند تا سایت آن‌ها را host کنند. شرکت پروایدر که در رک خود چند سرور دارد, یکی را به Joe و یکی را به Mary می‌دهد که هرکس دامنه سایت آن‌ها را وارد کرد, شرکت پروایدر تصمیم بگیرد که درخواست را به سمت کدام سرور هدایت کند. Virtual Hosting: تا اینجای ماجرا همه چیز خوب بنظر میرسه اما وقتی بحث قیمت سرورا میشه, هیچکس حاضر نیست هزاران دلار برای یک سرور بده که یک سایت ساده رو بیاره بالا! پرووایدر ها تصمیم گرفتند که بجای اینکه به هر مشتری یک سرور گران بدهند, آن سرور را بخش بخش کنند و چندین سایت را روی آن serve کنند. در این موقعیت کلی پول و منابع ذخیره می‌شود. اما این به این معنی نیست که یک سرور چندین سایت را serve می‌کند. بلکه ممکن است replication انجام بشود و ترافیک این سایت ها بین چندین سرور پخش شود! برسی یکی از مشکلات Virtual hosting: تصور کنید دو سایت را روی یک سرور serve می‌کنیم. a.com/index.html b.com/index.html برای دسترسی به این ریسورس‌‌ها یک ریکوئست مانند ریکوئست زیر ساخته و ارسال می‌شود: GET /index.html HTTP/1.0 ما فقط می‌گوییم که از این host فایل index.html را می‌خواهیم اما سرور نمیداند که فایل را از کدام یکی از سایت های موجود بردارد. برای حل این مشکل, در HTTP 1.1 تصمیم گرفتند که URL کامل را ارسال کنند تا وب سرور تصمیم بگیرد به کدام اپلیکیشن درخواست را ارسال کند. اما مشکل این‌ است که این تصمیم بعد از توسعه هزاران اپلیکیشن گرفته شد. تکلیف برنامه های قدیمی چیست؟ 1- ارسال url کامل 2- ارسال port اپلیکیشن 3- ارسال یک ip که isp آن را به یک اپلیکیشن منتسب کرده. 4- ارسال یک header که مشخص می‌کند به کدام برنامه ارسال شود موارد ۱ و ۲ و ۴ تا حدودی مشخص است اما مورد سوم نیاز به توضیح بیشتری دارد. در این روش که بسیار مرسوم است, پرووایدر یک آیپی را به joe می‌دهد که آن را برای سایت خودش استفاده کند. هنگامی که به این ایپی درخواست بزنیم, پرووایدر دقیقا می‌داند که این درخواست برای کدام یک از سرور ها و برای کدام سایت دیپلوی شده روی آن است. #http_guideline @code_crafters

یه پروژه بزرگی اومده سمتم پروژه هم بین المللی هستش ارزش انجام خود کارش ، از پولش بیشتره، ولی منتها نیاز به یک تیم داره که حداقل پنج نفر مثه خودم باشن تا اطمینان بدم تحویل داده میشه ازون چهارتا فقط یکنفر دیگه رو سراغ دارم که مطمئنم میتونم باهاش کار رو پیش ببرم فقط برام سوال شد چرا متخصص اوتقدری تو مملکت نیست (python, socket, geo) سیستم دیزاین و طراحی ساختار داده بابت داده‌های ریل تایم #موقت