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

اغلب سازمان‌ها برنامه استراتژیک سالانه خود را در سه ماه سوم سال برگذار می‌کنند و یکی از این نتایج فهرست محصولاتی است که می‌خواهند روی آن کار کنند. این محصولات باهم در بک‌لاگ سبد محصول وارد شده و موجب اختلال در برنامه ریزی سبد محصول می‌شوند

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


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


۴-برنامه ریزی برای انتشارهای کوچک و زود به زود
انتشارات کوچکتر توجیه اقتصادی بهتری دارند و همواره موجب افزایش سود چرخه عمر محصول می‌شود. علاوه بر این از ایجاد «اثر کاروانی» نیز جلوگیری می‌کند، تصور کنید یک اسکانیا در مسیر وجود دارد و موجب شده که ماشین‌های کوچکتر وشت سر او صف طولانی تشکیل دهند این همان اثر کاروانی است که با ورود محصول بزرگ ایجاد می‌شود و دلیل آن استفاده از تمام ظرفیت جاده و مسیر است. محصولات بزرگ منابع زیاد و طولانی نیاز دارند و موجب صف تاخیر می‌شود که خود هزینه بردار است. راه جلوگیری از آن اعمال سیاست سازمانی است بزای مثال هیچ محصولی با حجم کاری بیش از نه ماه پذیرفته نمیشود مگر راه حلی برای شکستن آن در انتشارات کوچک‌تر پیدا شود. همچنین تصور عدم وجود انتشار دوم موجب می‌شود که جانب احتیاط را گرفته و ویژگی‌هایی اضافه کنیم که موجب بزرگ شدن محصول می‌شود


استراتژی جریان خروجی
این استراتژی به سازمان‌ها کمک می‌کند تا تصمیم بگیرند چه زمانی یک محصول را از سبد محصول خارج کنند، سه استراتژی در این بخش

۱-توجه به کارهای ناتمام به جای افراد بیکار
۲-تعیین سقف برای کار در جریان
۳-منتظر ماندن برای تشکیل یک تیم کاما

استراتژی اول
بجای افراد بیکار به کارهای ناتمام توجه کنید.
این اصل بیان می‌کند اتلاف منابع و خسارت ناشی از کارهای ناتمام بیشتر از بیکاری افراد به مراتب بیشتر است. شیوه مدیریت سبد محصول در اغلب سازمان‌ها با این اصل در تناقض است.
شیوه رایج اما اشتباه شروع توسعه محصول:

۱-محصول ردیف اول بک‌لاگ را بردارید و افرادی را برای انجام آن تعیین کنید
۲-آیا همه وقتشان پر شده است، اگر خیر گام اول را تکرار کنید

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

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

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

#scrum

@code_crafters

استراتژی محصولات جاری
این استراتژی در تصمیم‌گیری به ما کمک می‌کند کدام اقدام را انجام دهیم: حفظ، تغییر مسیر، تحویل یا توقف. که در پایان هر اسپرینت گرفته می‌شود و گاها در بازه‌های و هنگام وقوع رویدادهای غیرعادی، بازبینی، بازبینی محصولات جاری ضروری می‌شود. واحدهای حاکمیتی شازمان استراتژی‌های متفاوتی دارند که یکی از این موارد «مطلوبیت اقتصاد نهایی» است که با اصول اسکرام و چابکی سازگار است و باید در تصمیم گیری‌ها مورد استفاده قرار گیرد

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

حفظ: ادامه توسعه محصول
تحویل: توقف کار و تحویل محصول
تغییر مسیر: ثبت آموخته‌ها و تغییر سمت و سوی آینده محصول
توقف: اتمام کار و کنار گذاشتن محصول

تصویر اول در کامنت‌ها

اگر سرمایه گذاری توجیه دارد در حالت حفظ قرار می‌گیریم، این سناریو زمانی رخ می‌دهد که یکی از محصولات جاری را بازنگری کنیم
در غیر این صورت باید رو سه حالت دیگر تصمیم گرفت


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

هیچگاه اجازه ندهید که تصمیمات حسابداری شما را به رفتار نابخردانه بکشاند 

#scrum


@code_crafters

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

تو این مجموعه قراره تو ۵ بخش، ۱۰ دیزاین پترن مهم برای ساختن میکروسرویس قوی و مقیاس‌پذیر رو توضیح بدم. تو بخش اول، می‌ریم سراغ اینکه میکروسرویس‌ها چی هستن؟ چرا دیزاین پترن ها مهم هستن؟، و دو تا الگوی خاص به اسم Service Service Registry Pattern(رجیستری سرویس) و Service Mesh Pattern(مش سرویس) رو بررسی می‌کنیم.

میکروسرویس‌ها چی هستن؟

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

تصویر اول
این سرویس‌ها با هم از طریق API باهم ارتباط برقرار میکنند و معمولاً از روش‌های ساده‌ای مثل HTTP یا از مسیچ بروکر هایی (مثل RabbitMQ) استفاده می‌کنن. این روش باعث می‌شه:
- سیستم انعطاف‌پذیرتر باشه، چون هر سرویس جداگونه قابل‌تغییره.
- سریع‌تر بتونی تغییرات رو اعمال کنی.
- اگه یه سرویس خراب بشه، کل سیستم از کار نمی‌افته (مثل وقتی یه قطعه پازل خراب بشه، کل تصویر خراب نمی‌شه).

چرا ادیزاین پترن ها مهم‌ان؟

دیزاین پترن ها مثل یه جعبه‌ابزار برای توسعه‌دهنده‌ها هستن. دلایل اهمیت‌شون:

- استفاده دوباره و مقیاس‌پذیری: این الگوها مشکلات تکراری رو حل کردن، پس می‌تونی از راه‌حل‌های آماده استفاده کنی و کدهات رو طوری بنویسی که بعداً راحت بتونی سیستمت رو بزرگ‌تر کنی. مثلاً میکروسرویس‌ها بهت کمک می‌کنن با اضافه کردن سرویس‌های جدید، سیستم رو مقیاس‌پذیر کنی.
- نگهداری و انعطاف: الگوها یه ساختار استاندارد به کدها می‌دن که باعث می‌شه کدت تمیزتر و قابل‌فهم‌تر باشه. اینجوری اگه بخوای چیزی رو تغییر بدی، کل سیستم به هم نمی‌ریزه. مثلاً الگوهایی مثل Observer یا Strategy بهت کمک می‌کنن کدت رو مدولار و قابل‌تغییر نگه داری.
- بهینه‌سازی و زبان مشترک: بعضی الگوها کمک می‌کنن سیستمت سریع‌تر کار کنه، حافظه کمتری مصرف کنه یا امن‌تر باشه. ضمناً این الگوها یه زبان مشترک بین توسعه‌دهنده‌ها ایجاد می‌کنن که بتونن راحت‌تر با هم درباره سیستم‌های پیچیده حرف بزنن.

دیزاین پترن میکروسرویس‌ها

1- رجیستری سرویس
برای درک بهتر الگوی رجیستری سرویس، فرض کنید یه شهر بزرگ دارید که پر از مغازه‌ها و خدمات مختلفه. هر مغازه (که اینجا نماینده یه میکروسرویسه) باید به مشتری‌ها (یا سرویس‌های دیگه) بگه کجاست و چی ارائه می‌ده. حالا اگه هیچ سیستم مرکزی وجود نداشته باشه، هر مغازه باید خودش بره دنبال مغازه‌های دیگه، که این کار خیلی زمان‌بر و پیچیده می‌شه.

اینجاست که رجیستری سرویس مثل یه دفتر اطلاعات شهری عمل می‌کنه. هر مغازه وقتی شروع به کار می‌کنه، می‌ره و خودش رو تو این دفتر ثبت می‌کنه. مثلاً می‌گه: «من مغازه قهوه‌فروشی‌ام، تو این آدرس کار می‌کنم و این خدمات رو ارائه می‌دم.» بعد، اگه یه مغازه دیگه (مثلاً یه شیرینی‌فروشی) بخواد قهوه سفارش بده، به جای گشتن تو کل شهر، مستقیم می‌ره به این دفتر اطلاعات و آدرس قهوه‌فروشی رو پیدا می‌کنه.

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

مثال: Netflix Eureka
Eureka یه ابزار کشف سرویس ساخته نتفلیکسه. سرورش طوری طراحی شده که همیشه در دسترس باشه و چند تا سرور بتونن اطلاعات سرویس‌های ثبت‌شده رو با هم به اشتراک بذارن.

2-الگوی مش سرویس
تصور کنید تو یه شهر شلوغ هستید که پر از ماشین‌ها (میکروسرویس‌ها) است که می‌خوان با هم ارتباط برقرار کنن. اگه هر ماشین بخواد خودش مسیرش رو پیدا کنه، ترافیک قفل می‌شه، تصادف پیش میاد و هیچ‌کس به موقع به مقصد نمی‌رسه. حالا مش سرویس مثل یه سیستم هوشمند مدیریت ترافیک عمل می‌کنه. این سیستم یه شبکه‌ی اختصاصی از «پروکسی‌ها» (مثل چراغ‌های راهنمایی یا پلیس‌های ترافیک) داره که تمام ارتباطات بین ماشین‌ها رو هدایت، کنترل و بهینه می‌کنه.


تصویر سوم
این لایه‌ی واسطه (که معمولاً با ابزارهایی مثل Istio یا Linkerd پیاده‌سازی می‌شه) مسئولیت کارهای زیر رو به عهده می‌گیره:

هدایت ترافیک: تصمیم می‌گیره درخواست‌ها از کدوم مسیر برن. مثلاً اگه یه سرویس شلوغ باشه، درخواست‌ها رو به یه نمونه‌ی دیگه از همون سرویس می‌فرسته.
تعادل بار (Load Balancing): بار کاری رو بین نسخه‌های مختلف یه سرویس تقسیم می‌کنه تا هیچ سرویسی بیش از حد تحت فشار نباشه.
امنیت: ارتباط‌ها رو رمزنگاری می‌کنه (مثلاً با TLS) و مطمئن می‌شه فقط سرویس‌های مجاز بتونن با هم حرف بزنن.
نظارت و رصد: اطلاعاتی مثل زمان پاسخ‌گویی، تعداد درخواست‌ها یا خطاها رو جمع‌آوری می‌کنه تا تیم توسعه بتونه عملکرد سیستم رو تحلیل کنه.
مدیریت خطا: اگه یه سرویس از کار بیفته، مش سرویس می‌تونه درخواست‌ها رو به‌طور خودکار به یه سرویس سالم هدایت کنه یا یه پیام خطای مناسب برگردونه.

مثال واقعی: فرض کنید تو یه اپلیکیشن خرید آنلاین، سرویس «پرداخت» و سرویس «سبد خرید» باید با هم کار کنن. بدون مش سرویس، هر کدوم از این سرویس‌ها باید خودشون منطق ارتباطی، مثل مدیریت خطاها یا رمزنگاری، رو پیاده‌سازی کنن. اما با مش سرویس، یه لایه‌ی پروکسی (مثلاً Envoy تو Istio) بین این دو سرویس قرار می‌گیره و تمام این کارها رو به‌صورت خودکار انجام می‌ده. اینجوری تیم توسعه می‌تونه روی منطق اصلی سرویس‌ها تمرکز کنه و نگران پیچیدگی‌های ارتباطی نباشه.

مزیت بزرگ: مش سرویس کد سرویس‌ها رو ساده‌تر می‌کنه، چون منطق شبکه‌ای (مثل retry، timeout یا رمزنگاری) از سرویس‌ها جدا می‌شه و به لایه‌ی مش منتقل می‌شه. اما یه نکته هم داره: راه‌اندازی و مدیریت مش سرویس ممکنه خودش پیچیدگی‌هایی به سیستم اضافه کنه، مخصوصاً تو محیط‌های کوچک‌تر.
#microservice #design_patterns

@code_crafters

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

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

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

اCircuit Breaker چطور کار می‌کنه؟

صور کنید یه سرویس مثل یه لامپه. مدار شکن سه تا حالت داره:

بسته (CLOSED): لامپ سالمه، همه‌چیز رواله، درخواست‌ها راحت می‌رن و میان.
باز (OPEN): لامپ سوخته یا اتصالی کرده! مدار شکن درخواست‌ها رو بلاک می‌کنه تا سرویس فرصت داشته باشه درست بشه.
نیمه‌باز (HALF OPEN): لامپ انگار داره کم‌کم روشن می‌شه. مدار شکن یه چند تا تست می‌کنه ببینه سرویس دوباره اوکیه یا نه. اگه اوکی بود، همه‌چیز به حالت عادی برمی‌گرده.

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

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

همچنین تو پایتون، می‌تونیم از کتابخانه CircuitBreaker استفاده کنیم.

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

رمان گرگ بیابان از هرمان هسه

قبل از هرچیزی عمیقا باور کردم که این کتاب رو خدا و شیطان باهم نوشتند

موضوع کتاب ارجاع به درون انسان هستش، خویشتن‌های درونی هر انسانی

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

درک سطر به سطر کتاب برام سخت بود


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

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

#book

@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

نوشتن یا بررسی یک نرم افزار رو از کجا شروع کنیم؟؟؟

سوالی که همیشه وجود داره حتی تو مصاحبه‌های استخدامی

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

یک نرم افزار از بیرون سه تا بخش داره

view
service
model

چرا میگیم این سه بخش و بالاتر گفتم محدود؟

دو شیوه توسعه نرم افزار مهم رو به یاد بیارید DDD و TDD علاوه بر اینکه این دو رویکرد تمام جنبه‌های خاص رو مورد پوشش قرار میدن موارد انتزاعی هم بهمون تدریس میکنن

که یکی از اونها سوال اولمون بود؟؟؟
از کجا شروع به نوشتن یا بررسی کنیم

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

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


این دو رویکرد منجر به برطرف کردن بدفهمی و کج فهمی‌های مدل سه لایه میشه و خب بسیار عالی

ولی از کجا بدونیم کدومش رو کجا بکار ببریم؟؟؟
اگه با یک سیستم دارای پیچیدگی روبرو هستید DDD
اگه با یک سیستم با اطمینان بالا روبرو هستید TDD



آیا رویکرد بهتری سراغ داریم؟؟؟
بله ترکیب این دو با هم

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

#DDD
#TDD

@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

یو یو, 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

قسمت دوم: نودها سودشون چیه و پروژه‌های کریپتو چرا عاشقش شدن؟
خب، تا اینجا فهمیدیم 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

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

پیاده‌سازی الگوی مخزن (Repository) از طریق CQRS با استفاده از Python-Django-ElasticSearch


#Django
#CQRS
#ElasticSearch

@code_crafters

داشتم کتاب «طراحی برنامه‌های داده محور» رو میخوندم

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

یجای کتاب بحث راجب داده‌های کلید/مقدار هستش و یک موضوع جالبی مطرح کرد با این عنوان که شما اگه در کلیدی که درست می‌کنید (مثلا ۳۲ کاراکتر) اگه یکمقدار یکتا داشته باشید براتون کافیه تا بعدا هرجا خواستید با اون کلید کار کنید فقط مقدار یکتای اون رو صدا بزنید و داشته باشید


وقتی بهش فکر کردم دیدم همین رو تو پلتفرم‌های روزمرگی مورد استفاده خودمون هم دیدم (لاگ مربوط به گیت که فقط کافیه چند کاراکتر اولش رو بدونی، id مربوط به موجودیت‌های داخل داکر که بازم کافیه چند مقدار اولش رو بدونی، هم لاگ گیت و هم id موجودیت‌های داکر یک رشته حداقل ۶۴ کاراکتری هستند) این مقدار یکتا منجر میشه که هم سرعت کارمون بیشتر بشه هم کار کردن باهاش راحتتر باشه (واسه خودمون و سیستم)

یادمه یبار یکی از بچه‌ها یکی از مشکلاتی که داشتند تو سیستمشون و راجبش باهم صحبت کردیم این بود که کلید ۶۴ کاراکتری رو داخل ردیس ذخیره کرده بودن که از طریق اون به یکسری اطلاعات برسند که مورد استفاده در کل سیستم بود، و خب جستجوی یک مقدار ۶۴ کاراکتری در بین هزارتا کلید با یک مقدار یکتای ۷ کاراکتری خیلی متفاوت هستش

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

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

@code_crafters

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

بچه‌ها دستم خورد با اکانت ادمین گروه رو پاک کردم

راهی واسه برگردوندنش هست؟؟؟

خب میتونید برگردید

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