tech-afternoon – Telegram
tech-afternoon
1.23K subscribers
174 photos
6 videos
6 files
166 links
تِک‌افترنون، رویدادی گاه‌به‌گاه است با موضوعات حول معماری و توسعه نرم‌افزار، این کانال هم برای اشتراک اخبار، آموزش، نکاتی حول مهندسی نرم‌افزار، دیتابیس‌، تکنولوژی و مدیریت تولید محصولات نر‌م‌افزاری خواهد بود.
youtube.com/@AminTechTalks/videos
امین مصباحی
Download Telegram
#موقت
از دوستانی که منتظر ویدیو aspire و ویدیو توضیح بدهی فنی هستند، بابت تاخیر عذرخواهی می‌کنم. دسامبر خیلی شلوغی بوده تا امروز، امیدوارم طی روزهای آتی برسونم 😊🙏
13
tech-afternoon
📌 ربع‌بندی بدهی فنی (Technical Debt Quadrant) دیروز یه توییتی زدم که برای توضیح بهتر منظورم (که هیچ ربطی هم به نرم‌افزار نداشت)، از توصیف بدهی فنی ناآگاهانه‌ی بی‌پروا استفاده کردم، این شد که گفتم شاید بد نباشه کمی عمیق‌تر در مورد بدهی فنی گپ بزنیم... مارتین…
📽 توضیح تکمیلی بر تحلیل ساختارمند بدهی فنی (کوادرانت فاولر)
پیش از هر چیز از دوستانی که با ری‌اکشن 🤓 برای بررسی عمیق‌تر موضوع بدهی فنی، ابراز علاقه کرده بودند متشکرم.

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

مقدمه: (0:00)
تعریف بدهی فنی: (0:37)
خصوصیات رایج بدهی‌های فنی: (3:15)
انواع بدهی فنی: (5:40)
لزوم بررسی ساختارمند بدهی فنی: (7:28)
کوادرانت (ربع‌بندی) مارتین فاولر: (12:30)
نوع اول-آگاهانه و منطقی: (13:30)
نوع دوم-ناخواسته و محتاطانه: (15:10)
نوع سوم-آگاهانه و غیرمسئولانه: (16:41)
نوع چهارم-ناآگاهانه و بی‌پروا: (17:37)
سایر طبقه‌بندی‌ها: (18:51)
جمع‌بندی: (22:35)

خیلی خوشحال می‌شم تا بهانه‌ای باشه برای هم‌فکری و گپ و گفت بیشتر 🌱💬😊
🔥63👍1
تایپ هینت‌ها توی پایتون در سال ۲۰۲۴: محبوب ولی هنوز چالش‌دار


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

PEP 484 چیه؟
تایپ‌هینت توی زبان‌های داینامیک تایپ (Dynamic Typing) مثل پایتون یا جاوا اسکریپت، این امکان رو به توسعه‌دهنده‌ها می‌ده تا «نوع» داده‌ای ورودی‌ها و خروجی توابع و متغیرها رو مشخص کنن.
مثلا به جای:
def greet(name):
return f"Hello, {name}!"


بنویسن:
def greet(name: str) -> str:
return f"Hello, {name}!"



سال ۲۰۱۴، Guido van Rossum (خالق پایتون) و Jukka Lehtosalo (خالق mypy) امکان تایپ هینت (Type Hint) رو در قالب PEP 484 معرفی و به پایتون اضافه کردن. تایپ هینت اجباری نیست، یعنی کد پایتون بدون اون هم اجرا میشه، اما وقتی ازش استفاده کنیم، می‌تونیم توی پیدا کردن باگ‌های احتمالی، بهتر شدن تکمیل خودکار کد (autocomplete) توی IDEها و مستند‌سازی، از مزایاش استفاده کنیم.

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


یکی از دلایل اصلی محبوب شدن تایپ‌ها تو پایتون PEP 484 بوده و باعث شده ابزارها و کتابخونه‌های زیادی ازش پشتیبانی کنن. حالا ده سال بعد از معرفی PEP 484، یه نظرسنجی بزرگ توسط JetBrains، Meta و مایکروسافت انجام شده تا ببینن وضعیت استفاده از تایپ‌ها تو پایتون چجوریه. بیش از ۱۰۰۰ نفر تو این نظرسنجی شرکت کردن و نتایج جالبی به دست اومده. خلاصه‌اش اینه:

نکات مهم:
- تقریبا ۸۸٪ برنامه‌نویسا یا همیشه یا اغلب از تایپ‌ها استفاده می‌کنن.
- مزایای اصلی، بهبود IDEها، داکیومنت‌ها و پیدا کردن باگ‌ها.
- مشکلات اصلی هم دشواری توی استفاده برای الگوهای پیچیده، کندی ابزارها و نبود تایپ تو کتابخونه‌های محبوب.
- تفاوت توی نحوه پیاده‌سازی تایپ چکرها و سختی پیدا کردن مستندات، کارو برای جونیورها سخت می‌کنه.

📌 کجاها از تایپ‌ها استفاده میشه؟
کوتاه: خیلی جاها 😁
کمی دقیقتر: از اسکریپت‌نویسی و توسعه وب گرفته تا دیتا ساینس، دیتا انجینیرینگ، هوش مصنوعی و... حتی برای پروژه‌های شخصی هم ۶۶٪ از تایپ‌ها استفاده می‌کنن.

⚙️ ابزارها و تایپ چکرها
- محبوب‌ترین محیط توسعه VS Code بوده.
- تو تایپ چکرها، Mypy اول و Pyright دومه.
- جالبه که Pydantic هم کلی استفاده میشه (۶۲٪)، حتی برای چک‌های زمان اجرا.

😍 چیزایی که دولوپرا دوست دارن:
- تکمیل خودکار (autocomplete) قوی‌تر.
- شفاف‌تر شدن کد.
- پیدا کردن باگ‌های احتمالی قبل از اجرا.
- ریفکتور راحت‌تر.

😤 مشکلاتی که اذیت می‌کنه:
- پیچیدگی تایپ‌ها برای چیزای داینامیک.
- سرعت پایین ابزارهایی مثل Mypy.
- نبود تایپ تو بعضی از کتابخونه‌ها.
- مستندات ناکافی، مخصوصاً برای موارد پیشرفته.

🧐 چرا بعضیا تایپ استفاده نمی‌کنن؟
- ۲۹٪ گفتن نیازی به تایپ تو پروژه‌هاشون ندارن. جالب اینکه حتی بین این افراد، ۶۰٪ تایپ رو "همیشه" یا "اغلب" استفاده می‌کنن.

✍️ پیشنهادها برای بهبود:
- استانداردسازی بهتر ابزارها.
- پشتیبانی قوی‌تر برای الگوهای پیچیده و داینامیک.
- بهبود مستندات، مخصوصاً برای تایپ‌های پیشرفته با مثال‌های عملی.
- افزایش سرعت تایپ چکرها.

🔄 این نظرسنجی قراره سال ۲۰۲۵ دوباره انجام بشه تا ببینن وضعیت تغییر کرده یا نه.

🔗 لینک نتایج نظرسنجی از بلاگ مهندسی شرکت متا

نظر شما چیه؟ از تایپ‌ها استفاده می‌کنی یا ترجیحت پایتون‌نویسی به شیوه مردان شجاع و فارغ از تایپه؟ 😅
👍3
📊 محبوب‌ترین API Clientها در سال ۲۰۲۴ به آمار Cloudflare

روزهای آخر ساله و شرکت‌های مختلف، آمار و ارقامشون رو می‌گذارن روی میز (مثل مطلب قبلی). حالا Cloudflare به عنوان پرمخاطب‌ترین CDN دنیا که به گزارش سال ۲۰۲۲ W3Techs حدود ۸۰٪ همه وب‌سایت‌ها ازش استفاده می‌کنن (سال ۱۴۰۰ هم آروان سهم کلودفلر رو بین سایت‌های ایرانی حدود ۷۰٪ ذکر کرد)، آمار API Clientها رو برای سال ۲۰۲۴ ارائه کرده.
اینا رو عرض کردم که بدونیم آمار و ارقامش قابل اتکا است. ولی:

✏️ در نظر بگیریم که کلودفلر CDN محبوب وب‌سایت‌ها است و خیلی از اپلیکیشن‌های سازمانی پشت کلودفلر نیستن، بلکه پشت CDNهایی مثل Azure CDN یا آمازون CloudFront هستند یا اصلا از CDN استفاده نمی‌کنن.

با این‌ توضیحات:

بر اساس گزارش جدید کلودفلر، زبان برنامه‌نویسی Go به محبوب‌ترین زبان برای توسعه کلاینت‌های API تبدیل شده و از Node.js پیشی گرفته. همچنین، AWS به‌عنوان انتخاب اصلی برای میزبانی وب‌سایت‌های عمومی در بین ۵۰۰۰ دامنه برتر شناخته شده.

جزئیات گزارش:
محبوبیت Go برای کلاینت‌های API: بیش از نیمی از ترافیک اینترنتی که کلودفلر مشاهده کرده، مربوط به APIهاست.

تحلیل‌هاشون نشان داده که Go با ۱۱.۸٪ استفاده، در صدر زبان‌های مورد استفاده برای توسعه کلاینت‌های API قرار داشته، از طرفی Node.js با ۱۰٪ و پایتون با ۹.۶٪ در رتبه‌های بعدی بودن.

این تغییر نسبت به سال گذشته قابل توجه است، چرا؟ چون سال گذشته Node.js با ۱۴.۶٪ در صدر بود و Go با ۸.۴٪ در رتبه دوم قرار داشت.

میزبانی وب‌سایت‌های عمومی: در بین ۵۰۰۰ دامنه برتر، AWS با ۶۲.۳٪ سهم، پیشتازه: در مقابل، مایکروسافت Azure فقط ۴.۸٪ سهم داشته و بعدش هم WP Engine با ۸.۵٪ و Vercel با ۶.۱٪ قرار داشتن.

فریم‌ورک‌ها و کتابخونه‌های وب: توی این دامنه‌ها، PHP با ۴۸.۱٪ به‌عنوان محبوب‌ترین زبان برنامه‌نویسی بوده (یحتمل به خاطر وردپرس و...)، بعدش هم Node.js با ۲۷.۹٪ و جاوا با ۱۶.۸٪ قرار داشتن. در بین فریم‌ورک‌های جاوااسکریپت، React با ۳۶.۶٪ در صدر بوده و بعدش Vue.js با ۱۹.۷٪ و Next.js با ۱۲.۶٪ قرار داشتن.

🔗 لینک گزارش


👀 این اعداد به هیچ وجه به معنی برتری یا ترجیح یا حتی محبوبیت مطلق این ابزارها و تکنولوژی‌ها نیست! 😊

پیشنهاد می‌کنم گزارش رو نگاهی بندازین. یا به صورت کلی پیگیر گزارش‌های آخر سال شرکت‌های بزرگ و منابع معتبر باشین (خصوصا رادارها شون)
👍21
🚀 تبدیل فایل‌های پی‌دی‌اف و آفیس و... به Markdown!

یک کتابخونه خوب پایتونی از مایکروسافت! (+ یک اپلیکیشن که با استفاده ازش ساخته شده) برای تبدیل فایل‌های
- PDF (.pdf)
- PowerPoint (.pptx)
- Word (.docx)
- Excel (.xlsx)
- Images (EXIF metadata, and OCR)
- Audio (EXIF metadata, and speech trannoscription)
- HTML (special handling of Wikipedia, etc.)
- Various other text-based formats (csv, json, xml, etc.)

به Markdown!

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

from markitdown import MarkItDown

markitdown = MarkItDown()
result = markitdown.convert("test.xlsx")
print(result.text_content)

https://github.com/microsoft/markitdown
2👍2🔥1
♻️💡 نظرسنجی در مورد محتوای کانال

سلام به همگی 😊

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

لینک زیر یک نظرسنجی کوتاه و فقط ۵ سوال انتخابیه (و البته به صورت ناشناس) که با شرکت در اون کمک مهمی در مسیر آینده کانال و بهبود محتواش خواهید داشت...
دم شما گرم، منتظر پاسخ‌ها، نقدها، نظرها و پیشنهاداتتون هستم 😉
https://forms.gle/Qu8xC8PvxcUP8fAx5
8
tech-afternoon pinned «♻️💡 نظرسنجی در مورد محتوای کانال سلام به همگی 😊 امروز، ۳ ماه از شروع این کانال می‌گذره، هدف اولیه (و فعلی) من اشتراک آموخته‌ها و تجربه‌ها بوده. ولی باور دارم زمانی این هدف محقق می‌شه که محتوا و مخاطب «همسو» با هم باشن. لینک زیر یک نظرسنجی کوتاه و فقط ۵…»
📚📚 بریم برای گپ و گفت در مورد کتاب‌هایی که سال ۲۰۲۴ خوندیم (حالا کامل، یا فصل‌هایی که جالب بوده برامون)

این مطلب بسته به استقبال شما می‌تونه از ذکر اسم کتاب، تا خلاصه صوتی مطالب متغیر باشه!

از خودم شروع می‌کنم (بخش اول، کتاب‌های جدید؛ بخش بعدی: کتاب‌هایی که بیشترین تعداد رجوع مجدد بهشون داشتم):

Architecture Modernization: Socio-technical alignment of software, strategy, and structure
سال انتشار: ۲۰۲۴
نویسنده: Nick Tune, Jean-Georges Perrin

——————
Patterns of Distributed Systems
سال انتشار: ۲۰۲۳
نویسنده: Unmesh Joshi
——————
ALEX KARP: From Philosophy to Palantir - A Life of Vision, Innovation, and Leadership
سال انتشار: ۲۰۲۴
نویسنده: Herbert K. Howard
——————
Clean Architecture with .NET
سال انتشار: ۲۰۲۴
نویسنده: Dino Esposito
——————
Programming Large Language Models with Azure Open AI: Conversational programming and prompt engineering with LLMs
سال انتشار: ۲۰۲۴
نویسنده: Francesco Esposito
——————
💸💸 انتشارات Packt مثل سال‌های پیش، از امروز به مدت چند روز تمام کتاب‌هاش رو فقط با ۹ یورو می‌فروشه!
12🔥22
🌟 ساده نگه داشتن سیستم‌ها، ۶ درس از Werner Vogels

حرف‌های زیادی میشه درباره AWS زد، اما واقعیت اینه که این غول کلود، سیستم‌ها و سرویس‌هاش رو طی دو دهه با موفقیت scale کرده و همچنان کاربری راحتش رو حفظ کرده.

ورنر فوگلس، CTO آمازون، تو کنفرانس AWS re:Invent درس‌های جذابی از تجربه‌اش تو نگهداری سیستم‌های پیچیده مطرح کرد.

💫 نکته کلیدی؟ پیچیدگی همیشه توی طراحی سیستم‌ها کمین میکنه، پس مهندس باید هوشیار باشه.

💫 هدف این نیست که پیچیدگی رو کلا حذف کنیم، بلکه باید اون رو مدیریت کنیم. لری تسلر میگه: "پیچیدگی رو نمیشه حذف کرد، فقط میشه جابجاش کرد".

یه مثال جالب: طراحی دوچرخه!

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

۶ توصیه Vogels برای مدیریت پیچیدگی:

۱. سیستم‌های قابل تکامل بسازید
نرم‌افزارهایی که پیش نمیرن، میمیرن
هر بار که مقیاس سیستم عوض میشه، باید معماری رو بازنگری کنید

۲. پیچیدگی رو خرد کنید
تغییرات کوچک رو نادیده نگیرید
هر سرویس باید اونقدر کوچک باشه که تو ذهن یه مهندس جا بشه

۳. معماری رو با نیازهای کسب‌وکار هماهنگ کنید
اجزای هوشمند با رابط‌های ریزدانه بسازید
با واحدهای کسب‌وکار همکاری کنید

۴. کار رو به سلول‌ها تقسیم کنید
معماری سلولی پیچیدگی رو مدیریت میکنه
مشکلات رو محدود میکنه بدون تاثیر روی کل سیستم

۵. سیستم‌های پیش‌بینی‌پذیر طراحی کنید
عدم قطعیت رو کاهش بدید
از معماری‌های با پالس ثابت استفاده کنید

۶. همه چی رو اتوماتیک کنید
اتوماسیون استاندارد باشه
فقط جاهایی که نیاز به قضاوت انسانی هست، دخالت انسان لازمه

💫 خلاصه کلام: "سادگی نیاز به انضباط داره" - Werner Vogels

در موردش صحبت کنیم؟ نظر شما چیه؟
👍10🔥54
tech-afternoon pinned «🤔 موضوع دورهمی بعدی چی باشه؟»
tech-afternoon
🤔 موضوع دورهمی بعدی چی باشه؟
خب، ممنون از همه دوستانی که طی ۲۴ ساعت گذشته مشارکت کردن 🙏🌱

📌 نتیجه می‌گیرم در دورهمی بعدی، در مورد سیستم‌های توزیع‌شده گپ خواهیم زد.

ولی چون Semantic Kernal و AI هم فقط ۲ تا رأی فاصله داشت، دورهمی بعدش به احترام رفقایی که نظرشون روی کاربرد هوش‌مصنوعی بود، به اون خواهیم پرداخت.

من سعی می‌کنم زودتر برنامه‌ریزی کنم. ولی فعلا خوشحال می‌شم توی کامنت یا ایمیل، دغدغه و نکاتی که بیشتر دوست دارید در موردش بدونید در رابطه با Distributed Systems برای بنویسید 😊
8👍2👏1
🚀 💸 یک خبر خوب! امروز گیت‌هاب از سرویس رایگان کوپایلوت رونمایی کرد و بلافاصله هم تیم ویژوال‌استدیو نسخه رایگان رو برای ویژوال‌استدیو ارائه کرد.

من دو ساله مشترک کاپایلوت هستم و حقیقتا سرویس خوبیه. حتی از IntelliCode و JetBrains AI و Tabnine و Cody و Tabby هم که من تست کردم بهتر بوده (در تست‌ها و نیازهای شخصی من، که قطعا جهان‌شمول نیست)

و AI چند ساله که کم‌کم بخشی از هزینه‌های سبد خانواده شده که باید بهش جدی‌تر فکر کرد. از بس که متعدد شدن!

خبر گیت‌هاب
خبر ویژوال‌استدیو
خبر VS Code
👍8😍2🥰1😎11
قابلیت‌های جدید افزونه‌ی SQL Server برای VS Code!

اگر سیر تغییر رویکرد مایکروسافت رو دنبال کرده باشید، سرعت توسعه و نوآوری توی VS Code به طرز محسوسی سریع و خوشحال‌کننده است.
حالا اومده خیلی قابلیت‌هایی که قبلا فقط توی SSMS برای SQL Server بود رو توی افزونه VS Code اضافه کرده.

احتمالا تصاویر گویا است و می‌بینید که کوئری‌پلن، و تولید اسکریپت و کلا محیط بصری خیلی بهتر و کامل‌تری نسبت به نسخه‌های قبلی توی ورژن جدید داریم.

از طرفی می‌دونید که Azure Data Studio که بر پایه VS Code توسعه داده شده و کدباز و رایگانه، از MySQL, PostgreSQL, MongoDB, CosmosDB و SQL Server پشتیبانی می‌کنه (نه به کاملی DataGrip ولی در حال بهبود و تکمیله).

اینا همه در حالیه که SSMS 21 که الان نسخه پیش‌نمایش است هم تغییرات بزرگی داشته.

مثل اینکه مایکروسافت برای سهم‌گیری از بازار ابزارهای مرتبط با دیتابیس و بهبود ابزارهای قبلی خودش خیز برداشته!

💬 شما از چی استفاده می‌کنید؟ ابزار مورد علاقه‌تون چیه؟!
👌7👍221
انواع استراتژی‌های تاب‌آوری نرم‌افزار (Resiliency Strategy)

مفهوم Resiliency یا تاب‌آوری، به توانایی یک سیستم برای بازیابی شرایط پایدار در صورت بروز خطا گفته می‌شه. حالا این بازیابی می‌تونی تلاش برای بازیابی باشه، یا انتخاب راه جایگزین. مثل اینکه شما ۲ بار تلاش می‌کنی از API آب‌وهوا مقدار دمای فعلی یک منطقه رو بگیری، هر بار با فاصله زمانی ۵ ثانیه API رو صدا می‌زنی ولی بعد از اینکه پاسخ موفق نمی‌گیری (تا اینجا به این می‌گن استراتژی retry) بعد تصمیم می‌گیری از cache آخرین مقداری که کم‌تر از ۵ ساعت گذشته وجود داشته رو استفاده کنی که فعلا کار راه بیوفته (استراتژی fallback) یا ... به هر کدوم از این رفتارها برای تداوم کار و مقابله با موانع، می‌گن resiliency strategy.

کتابخونه Polly محبوب‌ترین در بین دات‌نتی‌هاست. و تو دل Aspire هم ازش استفاده شده، برای درک بهتر ویدیوی Aspire که به زودی پابلیش می‌شه، خوبه یه مرور روی انواع استراتژی‌ها کنیم...
—————————
دو گروه اصلی داریم:

⚙️گروه استراتژی‌های Reactive (واکنشی)
وقتی به کار می‌رن که یک خطا یا مشکلی رخ داده و سیستم باید به شکلی واکنش نشون بده.

🛡 ۱: استراتژی Retry
فرضیه: خطاها موقتی هستن و ممکنه با کمی تأخیر و تلاش مجدد برطرف بشن.

در این استراتژی، سیستم تلاش می‌کنه که یک عملیات ناموفق رو بعد از یک بازه‌ی زمانی مشخص دوباره امتحان کنه. این بازه زمانی می‌تونه ثابت یا متغیر باشه (مثل Exponential Backoff). مثلاً اگر سرور موقتی قطع شده باشه، با چند بار Retry ممکنه مشکل حل بشه. در Polly، این با “Retry Policy” قابل پیاده‌سازی است. و تعداد دفعات و بازه زمانی بین هر تلاش به تصمیم ما وابسته است.

🛡 ۲: استراتژی Circuit-Breaker
فرضیه: وقتی سیستم به شدت دچار مشکل می‌شه، بهتره سریعاً فرآیندها متوقف بشن به جای اینکه کاربران منتظر بمونن.

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

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

🛡 ۳: استراتژی Fallback
فرضیه: خطا تداوم خواهد داشت؛ پس برای پلن B برنامه‌ریزی می‌کنیم.

چطوری کمک می‌کنه؟ یک مقدار یا راه حل جایگزین در صورت بروز یا تداوم خطا ارائه می‌ده.

وقتی یک عملیات شکست می‌خوره، به جای نمایش خطا به کاربر، یک نتیجه جایگزین برمی‌گرده. مثلاً به جای اینکه پیام “سرور API در دسترس نیست” نمایش داده بشه، می‌تونید یک مقدار ذخیره شده از کش رو ارائه بدید.

🛡 ۴: استراتژی Hedging
فرضیه: گاهی اوقات برخی مسیرها شاید کند یا حتی ناموفق باشن؛ پس بهتره چندین راه برای رسیدن به هدف در نظر بگیریم، هر کدوم زودتر جواب داد، همون.

چطوری کمک می‌کنه؟ برای یک کار، چند راه رو تلاش می‌کنه به طور موازی پی بگیره و منتظر اولین پاسخ موفق می‌مونه.

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

⚙️گروه استراتژی‌های Proactive (کنشگر)
این استراتژی‌ها برای پیشگیری از بروز مشکلات در سیستم طراحی شده‌اند.

🛡 ۱: استراتژی Timeout
فرضیه: بعد از مدت زمانی مشخص، موفقیت بعیده.

چطوری کمک می‌کنه؟ تضمین می‌کنه که درخواست‌ها بیشتر از زمان مشخص منتظر نمی‌مونن.

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

🛡 ۲: استراتژی Rate Limiter
فرضیه: محدود کردن تعداد درخواست‌هایی که سیستم در یک بازه زمانی مشخص می‌پذیره (راهی برای کنترل بار ورودی).

چطوری کمک می‌کنه؟ اجرای درخواست‌ها رو محدود می‌کنه تا از حد مشخصی فراتر نره.

برای جلوگیری از بار زیاد روی سیستم، این استراتژی تعداد درخواست‌ها در یک بازه زمانی مشخص رو محدود می‌کنه. مثلاً اگر کاربران زیادی همزمان به سیستم درخواست بفرستن، Rate Limiter می‌تونه از خرابی جلوگیری کنه.

—————————

ما می‌تونیم از یک یا ترکیبی از چند استراتژی برای افزایش تاب‌آوری سیستم‌هامون استفاده کنیم.

🔗 رفرنس جهت مطالعه عمیق‌تر

💬 نظر؟ تجربه؟ سوال؟
Please open Telegram to view this post
VIEW IN TELEGRAM
👏83🔥2🙏2🤔1
🍉 مطلب ویژه برای شبی که 1️⃣ دقیقه بیشتر برای فکر کردن وقت داریم...

مفهومی داریم به نام Cargo Cult Practices که به رفتارها یا فرآیندهایی اشاره داره که به‌طور «سطحی» شبیه به رفتارهای موفق و موثر هستن، اما «بدون درک عمیقی» از دلیل یا اصول اساسی‌ای که پشت اون رفتارها و انتخاب‌ها وجود داره...

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

اصطلاح "کارگو کالت" در زمینه‌های مختلف برای توصیف تقلید ظاهری از یک عمل، بدون درک عمیق از مکانیزم‌های واقعی او‌ها به کار می‌ره، به‌ویژه در حوزه‌هایی مثل مدیریت و توسعه نرم‌افزار.

استفاده از فلان معماری یا فلان زبون یا فلان ساختار تیمی چون فلان شرکت استفاده کرده، از همین مصادیقه... توی فرهنگ ما ضرب‌المثل «مرغی که انجیر می‌خوره نوکش کجه» مترادف با همینه...

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

⚡️ ساختن فرهنگ و فرایند «متناسب» با نیازها و بضاعتمون، و به کارگیری ابزار مناسب براش... ⚡️

و بعدش:

✔️ کورکورانه از روش‌های شرکت‌های دیگه کپی نکن! اول ببین اصلاً به درد تیمت می‌خوره یا نه. یه چیزی که برای یه شرکت دیگه خوب بوده، الزاماً برای تو هم خوب نیست. حتی اگر اون شرکت خیلی خفن و مشهور باشه!

✔️ یه فضایی درست کن که برنامه‌نویس‌هات احساس مسئولیت کنن، بتونن مستقل کار کنن و راحت با هم‌تیمی‌هاشون حرف بزنن. نذار حس کنن دارن زیر میکروسکوپ کار می‌کنن.

✔️ به جای اینکه هر روز صبح همه رو بکشونی تو جلسه استندآپ، از ابزارها و روش‌هایی استفاده کن که خود به خود همه بدونن چی به چیه و مشکلات کجاست.

✔️ این افسانه برنامه‌نویس ده برابری (10x programmer) رو باور نکن! معمولاً اونایی که خیلی خوبن، تو یه زمینه خاص تخصص دارن، نه اینکه تو همه چیز استاد باشن.

✔️ موقع استخدام نیروی جدید، از همون اول درست بهشون یاد بده که چطور باید با بقیه ارتباط بگیرن و مسئولیت‌پذیر باشن. نذار عادت‌های بد از همون اول شکل بگیره.

یلدای همگی مبارک و امیدوارم در کنار خانواده و عزیزانتون سلامت و شاد و موفق باشین 😉
Please open Telegram to view this post
VIEW IN TELEGRAM
12👏22👍1
👀 ورک‌لود توی دات‌نت چیه؟
ورک‌لود‌های دات‌نت مجموعه‌ای از اجزای اختیاری SDK هستن که برای توسعه انواع خاصی از برنامه‌ها مورد استفاده قرار می‌گیرن. به زبون ساده‌تر، به جای نصب یک SDK بزرگ که همه چیز رو شامل بشه، می‌تونیم فقط اجزای مورد نیاز برای پروژه خودمون را نصب کنیم.

مثال: 🔤aspire 🔤یا macos یا tvos یا maui-tizen


✍️ تاریخچه و دلیل ایجاد ورک‌لود‌ها
توی نسخه‌های قبل از دات‌نت ۵، تمام قابلیت‌ها در قالب یک SDK یکپارچه (مونولیتیک) ارائه می‌شد. این رویکرد مشکلات متعددی داشت:

- حجم زیاد SDK و مشکلات توزیع
- زمان طولانی ساخت محصول
- پیچیدگی توی مدیریت و به‌روزرسانی
- مصرف منابع غیرضروری توی محیط‌ CI/CD

📌 اهداف اصلی معرفی ورک‌لود‌ها
مایکروسافت با معرفی ورک‌لود‌ها، چند هدف کلیدی رو دنبال کرد:

- امکان دانلود انتخابی قابلیت‌های مورد نیاز (مثلاً فقط ASP.NET Core یا فقط Xamarin)
- ساده‌سازی پیکربندی برای محیط‌های CI/CD
- ارائه پیام‌های خطای مفید هنگام نبود ورک‌لود مورد نیاز
- قابلیت نصب خودکار ورک‌لود‌ها بر اساس فایل پروژه
- امکان به‌روزرسانی ورک‌لود‌ها بدون نیاز به نصب نسخه جدید SDK (مثلا aspire رو به‌روز کنیم مستقل از سایر SDKها)

ساختار و ترکیب‌بندی
ورک‌لود‌ها از دو بخش اصلی تشکیل شده‌اند:

*️⃣مانیفست: فایلی که ورک‌لود و اجزاش رو توصیف می‌کنه
*️⃣پک‌ها: مجموعه فایل‌های فشرده‌شده شامل ابزارها، کتابخونه‌ها و منابع مورد نیاز

شروع به کار:
برای دیدن لیست ورک‌لودها و انتخاب از بینشون:

dotnet workload search


یا برای آپدیت کردن ورک‌لودها:

dotnet workload update


یا مثلا وقتی می‌خواین ورک‌لود لازم برای ساختن نرم‌افزار روی تلویزیون سامسونگ مجهز به تایزن رو نصب کنین:

dotnet workload install maui-tizen


🛫 آینده ورک‌لود‌ها
طبق برنامه مایکروسافت، در آینده:

*️⃣تمام قابلیت‌های دات‌نت (از جمله WPF و Windows Forms) به صورت ورک‌لود ارائه خواهند شد
*️⃣امکان نصب و مدیریت از طریق مدیریت‌کننده‌های بسته لینوکس فراهم می‌شه
*️⃣ابزارهای CLI برای مدیریت ورک‌لود‌ها گسترش پیدا می‌کنن

🚀 مدیریت نسخه‌های ورک‌لود با Workload Sets
یکی از ویژگی‌های مهم که از دات‌نت ۸.۰.۴۰۰ معرفی شد، قابلیت Workload Sets بود. این قابلیت به ما امکان می‌ده مجموعه‌ای از ورک‌لود‌ها رو با یک شماره نسخه مشخص مدیریت کنیم.

مزایای استفاده از Workload Sets

- کنترل بهتر روی نسخه‌های نصب شده
- اطمینان از سازگاری ورک‌لود‌ها با همدیگه
- همگام‌سازی آسون‌تر نسخه‌ها توی تیم توسعه
- مدیریت ساده‌تر به‌روزرسانی‌ها

مثال کاربردی:

dotnet workload install aspire --version 9.0.100-preview.7.24414.1


dotnet workload config --update-mode workload-set



حتی می‌تونیم توی global.json هم درجشون کنیم:

{
"sdk": {
"workloadVersion": "9.0.200-preview.0"
}
}



🧮جمع‌بندی
ورک‌لود‌های دات‌نت نشونه‌ی تکامل طبیعی پلتفرم و حرکت به سمت ماژولار شدن هرچه بیشترش هستن. و این رویکرد به ما این امکان رو میده تا محیط توسعه‌مون رو بهینه‌تر و سبک‌تر نگه داریم و فقط ابزارهای مورد نیازمون رو نصب کنیم.

و NET Aspire. اساسا بر پایه‌ی workloadها بنا شد و چابکی خودش رو وامدار workloadها است، و با رهانش (release)های مستقل از دات‌نت خودش رو مرتب بهبود داده تا امروز...


امیدوارم این مطلب به درک بهتر ورک‌لود کمک کرده باشه و بتونه به عنوان خونه‌های پازل کمک کنه تا Aspire رو بهتر درک کنید.

🔗مدخل مستندات رسمی
🔗داستان پیدایش توی گیت‌هاب و توسعه دات‌نت

💬 اگر سوالی دارید، حتماً طرح کنید!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥113👍1