قسمت سوم سری «مایکروسرویس و DDD برای تیم‌های کوچیک؟»
✅ خواستگاه‌ و قصه‌ی شکل‌گیری مایکروسرویس (بخش ۲)

🤦🏻‍♂️ سوءبرداشت‌های پرتکرار
🔤برای سرعت، حتماً مایکروسرویس!: اگر مشکل دارید؛ شاید پاسخ مشکلتون چیز دیگه‌ای یا از جای دیگه‌ای باشه. سربارِ ارتباطات مضاعف شبکه‌ای و بین سرویسی رو در نظر بگیرید که از چاله به چاه نیوفتید. شاید Modular Monolith/Modulith با مرزبندی درست، سریع‌تر و کم‌ریسک‌تر باشه.

🔤هر جدول = یک سرویس: واحد تقسیم و شکستن سرویس‌ها «قابلیت یا کانتکست» است، نه جدول.

🔤مایکروسرویس = کوبرنتیز: کوبرنتیز ابزاره، نه توجیه. کاش وقت شه روزی خواستگاه کوبرنتیز رو هم بنویسم تا با ۳ تا سرور فیزیکی فاز «مقیاس‌پیذیری» بر نداریم! swarm و k3s و... هم هستن!

🔤سرویس کوچیک‌تر ⇒ بهتر: ریزدانه‌گیِ افراطی، انفجار هماهنگی به بار میاره!

🔤می‌خواهیم تراکنش توزیع‌شده‌ی سراسری داشته باشیم: نشونه‌ی تقسیم و شکست غلطه؛ به event-driven و... فکر کنید.

🗑بوی بدی (Smells) که نشون می‌ده راه رو کج رفتیم
- انتشار هم‌زمان چند سرویس برای یک تغییر کوچیک (Coupling پنهان).
- استفاده از Shared Database/Schema بین سرویس‌ها.
- آشفتگی ارتباطات (چند ده Call برای یک درخواست کاربر).
- استفاده سراسری از Two-Phase Commit (2PC)، بدون پذیرش event-driven/Outbox/....
- کتابخونه‌های Shared سنگین که نسخه‌بندی رو قفل می‌کنن (به‌جای قرارداد سبک).

💀 چه زمانی سراغش نرویم؟
- یک یا دو تیم کوچیک دارید و بیشترین درد شما کیفیت تست/اتوماسیون/استقراره؛ نه مرزهای دامنه.
- تغییرات کم‌بسامده و پیچیدگی دامنه متوسط.
- هنوز Observability، CI/CD، IaC در سطح پایه‌ای هم آماده نیست.
- «مالکیتِ end-to-end» برای هیچ سرویس/تیمی تعریف نشده.

در این حالت‌ها، Modulith با مرزبندی DDD (Bounded Context) «پله‌ی اول» بهتریه. هم بدهی معماری تولید نمی‌کنید، هم راهِ جداسازی آینده رو باز می‌گذارید.

🌱 نشونه‌های آمادگی :
- می‌تونید برای یک قابلیت، تیمِ مالک، بک‌لاگ، KPI و انتشار مستقل تعریف کنید.
- مولفه‌های Trace/Log/Metric شما پاسخ‌گوست: «اگر چیزی خراب شد، می‌دونید دقیقاً کجا و چرا؟»
- قراردادهایتان نسخه‌پذیره و Breaking Change رو تدریجی عرضه می‌کنید.
- داده‌ها مالک مشخص دارن و اشتراکِ مستقیمِ Schema ندارید.
- در لایه‌ی ارتباطات Fail-Fast/Retry/Timeout/Idempotency، «پروتکل تیم» است نه لطفِ داوطلبانه‌ی دولوپرها.

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

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

🧠 🚀هوش مصنوعی در تیم توسعه‌: ابزار روزمره به جای تقلب!

با رایج شدن مدل‌های هوش مصنوعی توی محیط‌های توسعه؛ مسیر تعامل برنامه‌نویس با مدل، از حالت پرسش ‌و پاسخ یا Ask، به توانمندی ویرایش یا Edit رسید و بعدتر به حالت Agent. در طول این مسیر، نیاز به سر و سامون دادن به رفتار مدل و اعمال تنظیمات دلخواه، ضرورتش بیشتر و بیشتر شد. حالا این تنظیمات می‌تونه پرامپت‌های از پیش ذخیره شده باشه برای صرفه‌جویی در زمان، یا مثلا دستورالعمل‌هایی مثل ساختار نامگذاری متغیرها یا اینکه همیشه لاگ‌ها رو به شیوه خاص بنویسه یا... برای همین فایل‌هایی مثل AGENTS.md یا .github/copilot-instructions.md یا .instructions.md به وجود اومدن.
توی این پست، اول این فایل‌ها رو با مثال مرور می‌کنم، بعدتر به اهمیت توجه به یکسان‌سازی/استانداردسازی اون‌ها در تیم‌های توسعه توسط platform engineering خواهم نوشت. این ابزارها خیلی سریع دارن توی ریپازیتوری‌های حرفه‌ای و شرکت‌ها، جا می‌افتن و مهمه که بدونیم دقیقاً چی‌ان؟ چرا مهم‌ان؟ و اصلاً چطور می‌تونن به تیم ما کمک کنن؟

✅ این فایل‌ها چی هستن؟

اگه بخوام ساده بگم، این فایل‌ها نقش «دستورالعمل استفاده از هوش مصنوعی» رو دارن برای توسعه‌دهنده‌ها و ابزارهای هوشمند مثل GitHub Copilot، Cody، یا حتی agentهای داخلی تیم‌ها.
به کمک این فایل‌ها، می‌تونیم به ابزار AI یاد بدیم که:

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

🔧 مثال‌های کاربردی:

👨‍💻فایل copilot-instructions.md:
فایل ساده‌ایه که توش توضیح می‌دیم Copilot تو این ریپو چطوری باید رفتار کنه. مثلاً:

- از Flurl.Http استفاده کن، نه HttpClient
- وقتی اسم متد با Get شروع شد، حتماً یه تست یونیت بساز
- همیشه Exceptionهای گلوبال با ProblemDetails هندل می‌شن

 .github/copilot-instructions.md
# Shared Platform Coding Standards

- Use `async/await`, not callbacks.
- Follow project’s naming conventions.
- Include dependency vulnerability tagging in comments.
- Provide default error handling structure.
- Always include logging statements.

🤖 فایل AGENTS.md:
اگه تو تیم‌مون agent داریم (مثلاً برای اینکه PR می‌زنه یا کد جنریت می‌کنه؛ یا از منابع کانفلوئنس شرکت اطلاعات می‌خونه یا به جیرا دسترسی داره یا...)، این فایل نقش پروفایل اون agent رو داره.
توش توضیح می‌دیم که این agent قراره چی کار کنه، چه داده‌ای داره، چه دامنۀ تصمیم‌گیری‌ای داره و کی باید بررسی کنه خروجیاشو.

AGENTS.md
# AGENTS.md — Developer Platform Guide for AI Agents

## Environment Setup
- `make setup` to install dependencies.
- `make test` for running full test suite.
- `docker compose up` to launch local services.

## Code Style
- Pre-commit: `black`, `isort`, `eslint`.
- Linting: `./tools/lint`.
- Tests: coverage must exceed 85%.

## Development Workflow
- Branch naming: `feat/*`, `fix/*`.
- PR guidelines: include ticket link, test coverage, and denoscription.

## Platform Behavior
- Always run `make build` before tests.
- Platform maintains shared Docker images, secrets, and env configurations.

📘 فایل .instructions.md:
یه فایل کلی‌تر برای راهنمایی خود ابزارها یا هم‌تیمی‌ها. توش ممکنه توضیح بدیم تو این پروژه چه Naming Convention داریم، چطوری باید migration ساخت، یا اینکه اصلاً ساختار پوشه‌ها چطوریه.

backend.instructions.md
---
applyTo: "backend/**/*.py"
---
# Backend Python Guidelines

- Format using Black (line length 88).
- Use Pydantic for input validation.
- Comment public functions with docstrings.
- Follow platform’s API client patterns.

ادامه در پست بعدی...

ادامه و جمع‌بندی:

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

اگه تبدیل بشن به بخشی از یه زیرساخت مشترک تیمی، دقیقاً مثل تمپلیت‌های .editorconfig یا CI/CDهای سراسری، اون‌وقت واقعاً اثر می‌ذارن و سرعت توسعه و کیفیت محصول رو افزایش می‌دن. و به نظرم این‌کار باید توسط تیم پلتفرم یا DevEx انجام بشه. اونا می‌تونن یه repo مرکزی بسازن برای این دستورالعمل‌ها، یا حتی یه پک آماده بدن که با هر پروژه جدید بشه cloneش کرد. مثلا می‌تونید از این ریپو برای دیدن انواع پرامپت‌ها یا دستورالعمل‌ها الهام بگیرید و نسخه بومی تیمتون رو بسازید...

💡 اگه می‌خوایم هوش مصنوعی رو به عنوان یه همکار قابل‌اعتماد و سازنده وارد تیم کنیم، نه یه ابزار دیمی و فانتزی، لازمه این زیرساخت‌های ساده ولی مهم رو جدی بگیریم.

فایل‌هایی مثل AGENTS.md یا copilot-instructions.md شاید کوچیک باشن، ولی یه قدم بزرگ‌ان برای کار تیمی، استانداردسازی، و استفاده درست از AI تو توسعه‌ی نرم‌افزار.

♟ اهمیت «ریز تصمیم‌ها» و «تصمیمات روزانه» در تیم‌های فنی!

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

🐘 تصمیمات روزمره (everyday decisions)
هر انتخابی که در طول یک روز معمولی انجام می‌شود، از تصمیمات بزرگ زندگی گرفته تا تصمیمات کوچک.
دامنه‌اش می‌تونه شامل انتخاب‌های مهم زندگی مثل محل زندگی، جابجایی‌های شغلی بزرگ یا تصمیمات فنی بزرگ باشه. تأثیر این انتخاب‌ها بر جهت کلی و کیفیت زندگی و کار فرد تأثیر می‌گذاره.

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

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

ما آدم‌ها ما در طول روز فقط مقدار محدودی از انرژی ذهنی یا بودجه تصمیم‌گیری (Decision-making bandwidth) داریم. هر تصمیم، هرچند کوچیک، بخشی از این ظرفیت رو مصرف می‌کنه. این ایده به مفهومی به نام Decision Fatigue (خستگی تصمیم‌گیری) مرتبطه.
برای همینه که مثلا زاکربرگ، جابز، یا اوباما در مورد محدود کردن انتخاب‌های غیرضروری روزانه صحبت کردن (مثل پوشیدن لباس تکراری روزانه)، چون می‌خواستن ظرفیت تصمیم‌گیری‌شون رو برای مسائل مهم نگه دارن. یا مثلاً قضات دادگاه صبح‌ها تصمیم‌های عادلانه‌تری می‌گیرن نسبت به عصرها. یا McKeown موضوع تمرکز بر «تمرکز انرژی روی تصمیمات مهم» رو طرح می‌کنه برای از بین بردن "نشت انرژی شناختی" در ریزتصمیم‌های بی‌ارزش.

با این مثال‌ها فکر می‌کنم نیازی به طولانی کردن مطلب نباشه که به عنوان عضو یا لیدر تیم فنی، تصمیمات کوچیک روزانه رو چقدر باید جدی گرفت و چقدر مهمه که انرژی رو سر ریزتصمیمات کم‌اهمیت هدر ندیم! نمونه‌های زیادی از ریزتصمیمات اشتباه توی تیم‌های فنی هست مثل:

- نوشتن کد بدون تست اولیه (و گفتن اینکه “الان مهم نیست، بعداً مینویسم تستشو”)
- چک نکردن لاگ‌ها بعد از دیپلوی یا رها کردن هشدارهای CI/CD به حال خودشون
- اینکه بگیم “فعلاً یه راه‌حل موقت می‌ذارم تا بعداً بهترش کنم” (که هیچ‌وقت بهتر نمی‌شه)
- باز کردن پیام اسلک/تیمز وسط تمرکز و بعدش گم‌کردن تسک اصلی
- انتخاب سریع و بدون بررسی لایبرری یا پکیج، بدون اینکه نگاه کنیم آخرین آپدیتش کی بوده یا چقدر در جامعه فنی پذیرفته شده
- گفتن “فعلاً این naming بد رو تحمل می‌کنم، وقت ندارم عوضش کنم” و بعدش به دام تکنیکال دِبت افتادن
- یا حتی نگفتن یک جمله تشکر یا فیدبک کوچیک که می‌تونه انرژی مثبت زیادی تو تیم پخش کنه

این‌ها همه ریزتصمیم‌ هستن؛ سریع، جزئی، اما به طرز عجیبی مؤثر.

🔧 پس چیکار کنیم؟

برای اینکه ریزتصمیم‌ها در خدمت ما و تیم‌مون باشن، نه علیه‌مون، چند تا اصل مهم رو می‌تونیم دنبال کنیم:

🚀 انتشار TeleScribe نسخه پیش‌نمایش

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

امکانات:
- تهیه خروجی مارک‌دان از محتوای کانال تلگرامی
- به‌روزرسانی محتوای خروجی گرفته شده
- تهیه گزارش از محتوای سایت (مثال تک‌افترنون)
- ساخت سایت ایستا بر اساس محتوا (مثال تک‌افترنون)
- آپلود مطالب در وردپرس (هنوز کامل نشده و باگ داره)
- تهیه عنوان و هشتگ مطالب با LLM (هنوز کامل نشده و باگ داره)

📱 مخزن کد

⚙️ اگر باگ و مشکل دیدید، لطفا کامنت یا توی گیت‌هاب ثبت کنید. پیشنهاد و بهبود و... هم که بدیهیه که مزید امتنان است 🌱😊.

🎯 معرفی گیت‌وی اختصاصی هوش مصنوعی: AgentGateway چیه و چرا به وجود اومده؟

این روزها که گاهی عاقلانه و گاهی جوگیرانه، استفاده از agentها و MCPها رایج شده، و ارتباط و یکپارچگی نرم‌افزارها با مدل‌های هوش مصنوعی داغه، باید یه مشکل اساسی رو بررسی کنیم:

💡 چطوری این agentها بتونن ابزارهای مختلف رو کشف کنن، بهشون متصل بشن، احراز هویت کنن، نتیجه بگیرن و اگه لازم شد fallback بزنن؟ برای پاسخ به این نیاز، گیت‌وی‌هایی اختصاصی برای ارتباط با agents وارد می‌شن!

🛠 حالا AgentGateway چیه؟
پروژه AgentGateway یه پروژه متن‌بازه که agents هوش مصنوعی، سرورهای MCP و ارائه‌دهنده‌های LLM رو در هر محیطی به هم وصل می‌کنه. این اتصالات دوطرفه، امن، مقیاس‌پذیر و stateful هستن و امکانات لازم مثل امنیت سازمانی، observability، انعطاف‌پذیری و multi-tenancy رو ارائه می‌ده.

✅ وظایف کلیدی AgentGateway:

🔗 ارتباط یکپارچه:
- اتصال امن و مقیاس‌پذیر بین agentها و ابزارها
- پشتیبانی از پروتکل‌های agent مثل MCP و A2A
- تبدیل REST APIهای موجود به ابزارهای agent-native

🛡 امنیت و مدیریت:
- احراز هویت JWT و سیستم RBAC قدرتمند
- محافظت در مقابل حملات tool poisoning
- کنترل دسترسی در سطح agent، tool و tenant

⚡️ عملکرد سریع:
- با Rust نوشته شده تا کارایی بالا، تأخیر کم، قابلیت اطمینان و پایداری رو حفظ کنه
- مدیریت اتصالات طولانی‌مدت و الگوهای fan-out داره

📊 نظارت و مدیریت:
- از metrics و tracing داخلی برای رصد تعاملات پشتیبانی می‌کنه
- پورتال سلف‌سرویس برای توسعه‌دهنده ارائه می‌کنه

❓فرق اساسیش با API Gateway چیه؟

نوع درخواست‌ها:
- گیت‌وی API: عمدتاً REST/HTTP
- گیت‌وی Agent: تعاملات پیچیده مثل Agent ↔️ Tool، Agent ↔️ Agent، Agent ↔️ LLM

پروتکل ارتباطی:
- گیت‌وی API: HTTP
- گیت‌وی Agent: MCP و A2A که پروتکل‌های JSON-RPC برای ارتباط agents و tools هستن

مدیریت session:
- گیت‌وی API: درخواست‌های کوتاه‌مدت HTTP
- گیت‌وی Agent: می‌تونه sessionهای stateful که باید context جلسه رو حفظ کنن و پیام‌ها رو مداوماً ارسال و دریافت کنن رو ارائه کنه

پیچیدگی پردازش:
- گیت‌وی API: قادر به forward کردن ساده درخواست‌ها است
- گیت‌وی Agent: دسترسی به چندین سرور MCP، تجمیع پاسخ‌ها و بازگردوندن نتیجه منسجم رو داره

🚫 چرا گیت‌وی‌های سنتی کافی نیستند؟

گیت‌وی‌های سنتی برای معماری microservices RESTful طراحی شدن که درخواست‌های HTTP کوتاه‌مدت دریافت می‌کنن، backend رو انتخاب می‌کنن و درخواست رو forward می‌کنن. ولی:

🔴 مشکلات اساسی:
- عدم پشتیبانی از session awareness
- ضعف در مدیریت ارتباطات دوطرفه
- این الگوهای ارتباطی resource intensive هستند و می‌تونن گیت‌وی‌های سنتی رو مختل کنن
- نیاز به بازطراحی اساسی برای پشتیبانی از use caseهای agentic AI دارن

🚀 ویژگی‌های منحصربه‌فرد AgentGateway

ارائه data plane یکپارچه:
مدیریت اتصال agent با پشتیبانی از پروتکل‌های agent و قابلیت یکپارچه‌سازی REST APIهای موجود

امکان multiplexing و federation:
ارائه endpoint واحد برای federation چندین سرور MCP و مجازی‌سازی tool server بر اساس هر client

پشتیبانی از هر framework:
سازگاری با هر framework agentic که از پروتکل‌های MCP و A2A پشتیبانی می‌کنه، مثل LangGraph، AutoGen، kagent، Claude Desktop و OpenAI SDK

خصوصیت platform-agnostic:
قابلیت اجرا در هر محیطی از bare metal تا virtual machine، containers و Kubernetes

به‌روزرسانی پویا:
امکان به‌روزرسانی از طریق رابط xDS بدون downtime

🛡 سیاست‌های امنیتی و ترافیک:

مدیریت ترافیک:
- دستکاری headerها، redirect، rewrite
- پاسخ مستقیم بدون ارسال به backend

امنیت پیشرفته:
- تنظیمات CORS، احراز هویت MCP
- پشتیبانی از TLS برای backend، محدودیت نرخ محلی و توزیع شده
- پشتیبانی از JWT Auth و external authorization

انعطاف‌پذیری:
- قابلیت‌های request mirroring، timeout، retry logic

🎯 کی از AgentGateway استفاده کنه خوبه؟

- سازمان‌های بزرگ: مدیریت ارتباطات پیچیده بین agents
- توسعه‌دهنده‌های AI: یکپارچه‌سازی tools و agents
- تیم‌های DevOps: استقرار در محیط‌های مختلف
- محققین: آزمایش فریم‌ورک‌های جدید agent

مخزن گیت‌هاب
مستندات رسمی

🔥 🐘 انتشار PostgreSQL 18، و اهمیت تغییراتش!

طبق روال سال‌های گذشته حوالی سپتامبر ریلیز نسخه جدید PostgreSQL انجام شد. حالا چرا این نسخه برای برخی سیستم‌ها می‌تونه قابل توجه و مهم باشه؟

- تغییرات انقلابی در I/O (Asyn I/O):
بالاخره! این قابلیت اومد و سرعت عملیات Read رو «تا» ۳ برابر افزایش می‌ده! معطلی‌های CPU برای I/O خیلی کمتر می‌شه و برای کارهای مثل VACUUM و اسکن‌های بزرگ، تاثیرش چشمگیره (من روی نسخه‌های پیش‌نمایش تست کردم و عالی بود).

- پشتیبانی از UUIDv7:
برای توسعه‌دهنده‌ها این شاید خیلی مهم باشه! (اگر دوست دارید در مورد انواع UUIDها بیشتر توضیح بدم: 🤪)
پشتیبانی Native از UUIDv7 یعنی Primary Key‌ها به صورت گلوبال یونیک میشن و هم چون بر اساس زمان مرتب هستن، عملکرد ایندکس B-tree به شکل چشمگیری بهتر میشه. (یعنی Page Split بی مورد نداریم!)

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

افزودن NOT NULL بدون Downtime: کابوس اضافه کردن NOT NULL به جدول‌های بزرگ تموم شد! حالا می‌شه قید NOT NULL رو به‌صورت NOT VALID اضافه کنیم و بلافاصله برای ردیف‌های جدید اعمال بشه. اعتبارسنجی ردیف‌های موجود رو هم می‌تونیم بعداً بدون قفل کامل جدول انجام بدیم.

- امکان Skip Scan برای B-tree:
یه بهبود عالی برای بهینه‌سازی کوئری؛ اگه توی ایندکس‌های چند ستونی، ستون اول رو در WHERE فیلتر نکرده باشیم، باز هم ایندکس کار می‌کنه و کوئری‌های تحلیلی/گزارش‌گیری خیلی سریع‌تر میشن.

- امکان RETURNING هوشمند:
حالا میشه توی یک دستور UPDATE یا DELETE به هر دو مقدار قدیمی (OLD) و جدید (NEW) یک ستون در بخش RETURNING دسترسی داشته باشیم.

- آپگرید آسون‌تر:
قابلیت حفظ Planner Statistics حین آپگرید با pg_upgrade باعث میشه دیتابیس جدید خیلی سریع‌تر به پرفورمنس دلخواه برگرده.

اگر جزو افرادی هستین که به مهاجرت به PostgreSQL فکر می‌کنید، یه تعداد کارت‌های شسته‌رُفته برای مهاجرت از SQL Server به PostgreSQL با هشتگ #MSSQL_to_PGSQL توی کانال داریم (کارت‌های قرمز رنگ از بخش تصاویر هم قابل پیدا کردنه)

⚙️ کمی در باب UUID

توی اکثر سیستم‌های اطلاعاتی، چه در مورد پیام‌های مورد تبادل بین سرویس‌های یک نرم‌افزار مبتنی بر مایکروسرویس صحبت کنیم، چه در مورد داده‌های دیتابیس، نیاز به یک روش مطمئن برای شناسایی منحصربه‌فرد داده‌ها وجود داره. استفاده از شناسه‌های ترتیبی (Sequential Integers) مثل Auto-Increment توی دیتابیس‌ها ساده و سریعه ولی توی محیط‌های توزیع‌شده که چندین سرور به طور همزمان ID تولید می‌کنن، برای جلوگیری از تکرار، نیاز به هماهنگی مرکزی دارن که خودش گلوگاه مقیاس‌پذیریه (Scalability).

برای پاسخ به این نیاز، UUID (Universally Unique Identifier) به وجود اومده. UUID‌ها شناسه‌های 128 بیتی (۳۶ کاراکتر) هستن که بدون نیاز به هماهنگی مرکزی، منحصر به فرد بودن رو در سطح جهانی تضمین می‌کنن. سال ۲۰۲۴، استاندارد رسمی RFC 9562 نسخه‌ی ۷ رو معرفی کرده: ۴۸ بیتِ اول «تایم‌استمپ یونیکس بر حسب میلی‌ثانیه»، بقیه بیت‌ها تصادفیِ امن. نتیجه؟ شناسه‌ها زمان‌مرتب و در عین حال یونیک هستن. چرا زمان‌مرتب بودن این شناسه‌ها مهمه؟ چون مثلا توی نسخه ۴، شناسه کاملا تصادفیه و اگر به ترتیب بخواهیم مرتب کنیم احتمال اینکه شناسه‌ای که الان تولید می‌کنید بعد از شناسه‌ای که دو ساعت پیش یا دو سال پیش تولید کردید قرار بگیره زیاده. این یعنی شروع مشکل. چه مشکلی؟ ایندکس جداول یا سری‌های زمانی.

فرض کنین یه کتاب دارید که شماره صفحاتش کاملا رندوم ولی یکتا باشه. در حالت عادی که شماره صفحات مرتب و دنبال هم هستن وقتی دنبال صفحه ۱۳۷ کتاب می‌گردید، اول یه جای کتاب رو باز می‌کنید و می‌بینید مثلا ۱۸۹ است، چون مطمئنید شماره ۱۳۷ قبلش است دیگه صفحات بعدی رو نگاه نمی‌کنید، یه جا قبل‌تر رو باز می‌کنید می‌بینید ۱۲۵ است، دیگه قبل‌تر و نمی‌گردید و چند صفحه جلوتر، ۱۳۷ رو پیدا می‌کنید. این یعنی پیدا کردن سریع‌تر مطالب. حالا اگر شماره صفحات رندوم باشه، هر بار که مرتبش کنیم با اولین مقدار جدید، نظم به هم می‌ریزه و پیدا کردن صفحات دشوار می‌شه.

مرور نسخه‌ها تا به امروز:

نسخه v1: مبتنی بر زمان و MAC Address » ترتیبی بر اساس زمان، یونیک جهانی » ولی افشای آدرس MAC (مشکل حریم خصوصی)

نسخه v2: مبتنی بر Domain محلی و Security » رزرو شده برای DCE Security » کاربری و استفاده بسیار محدود.

نسخه v3: مبتنی بر نام (MD5 Hashing) » همیشه برای یک "نام" و "دامین" مقدار یکسان تولید می‌شه. » از هش قدیمی MD5 استفاده می‌کنه که منسوخ شده.

نسخه v4: کاملاً تصادفی، یونیک جهانی با بالاترین میزان تصادفی بودن. » نامرتب؛ عملکرد ایندکس دیتابیس (B-tree) رو به شدت کاهش می‌دهه. » متاسفانه همچنان رایج، اما برای Primary Key نامناسب.

نسخه v5: مبتنی بر نام (SHA-1 Hashing) مشابه v3، اما از هش بهتر SHA-1 استفاده می‌کنه » فقط برای مواردی که نیاز به تکرارپذیری UUID است، مناسبه. » بهتر از v3، برای تولید شناسه‌های ثابت از URL یا نام.

نسخه v6: مشابه v1 ولی با ترتیب زمانی بهتر » مرتب زمانی، ولی بدون افشای MAC
» هنوز نسخه draft است، » کاربردش جایگزینی v1 در آینده

نسخه v7: مبتنی بر زمان یونیکس + مقدار تصادفی » مرتب بر اساس زمان و در عین حال یونیک جهانی + عملکرد بهینه دیتابیس » بهینه برای Primary Key خصوصا توی سیستم‌های توزیع‌شده و سری‌های زمانی » امکان افزودن کسریِ زیرِ میلی‌ثانیه و/یا کانتر هم برای تضمین مرتب‌بودن در همان میلی‌ثانیه پیش‌بینی شده.

نسخه v8: فضای سفارشی/تجربی برای نیازهای خاص.

📌 نسخه UUIDv7 به صورت بومی توی PostgreSQL 18 و SQL Server 2025 و پایتون ۳.۱۴ و دات‌نت ۹ و گو هم gofrs/uuid v5 پشتیبانی می‌شه ولی MySQL و MariaDB و جاوا هنوز نسخه بومی رو پیاده نکردن.

♻️ چرخه عمر نیروی انسانی (Employee Life Cycle) چیه؟

در بررسی ریشه‌های وضعیت فعلی توسعه نرم‌افزار در ایران، یکی از مهم‌ترین دلایل، ضعف فاحش در مدیریت چرخه عمر کارمند (Employee Life Cycle - ELC) است. این چرخه تمام مسیر یک فرد رو از پیش از جذب تا بعد از خروج پوشش می‌ده، توی شرکت‌ها و سازمان‌های ایرانی عموما جدی گرفته نمی‌شه یا به شوخی شبیهه. ELC یه مدل راهبردی توی مدیریت منابع انسانیه (HRM) که معمولا شامل ۶ مرحله کلیدی می‌شه.

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

مراحل ELC عموما:

➖ برنامه‌ریزی نیروی کار یا Workforce Planning
➖ جذب و گزینش یاRecruitment & Selection
➖ فرایند پذیرش و آشنایی یا Onboarding
➖ توسعه و آموزش یاDevelopment
➖ مدیریت عملکرد یا Performance Management
➖ نگهداشت یاRetention
➖ فرایند خروج یا Offboarding

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

🔗 در باب وضعیت امروز نرم‌افزار ایران، چند خطی رو در از منظر ELC نوشتم که اگر دوست داشتید مطالعه کنید و خوشحال می‌شم نظرتون رو به اشتراک بگذارین 😊

✨ آیا APIهای فعلی‌مون می‌تونن MCPهامون رو بسازن؟! (بخش ۱)

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

مقدمه:

اگر با مفهوم و ساختار MCP آشنایی دارید می‌تونید از روی بخش مقدمه بپرید و برید سراغ «✅ اصل مطلب»!

پروتکل MCP یا Model Context Protocol یک پروتکل باز و استاندارد برای شناسایی و به کارگیری منابع و ابزارها (منابع مثل دیتابیس‌ها، ابزارها هم مثل API و کامندها) توسط مدل‌های زبانیه که شرکت Anthropic (توسعه‌دهنده Claude) سال ۲۰۲۴ معرفی کرد.

💡 هدف و عملکرد
هدف اصلی MCP، ایجاد یه زبان مشترک برای تعامل مدل‌های زبان بزرگ (LLM) با برنامه‌ها و خدمات دنیای واقعیه. به بیان ساده‌تر، این پروتکل به هوش مصنوعی (LLM) اجازه می‌ده تا به‌جای اینکه فقط بر اساس داده‌های خودش متن تولید کنه، اقداماتی (Actions) رو در یک برنامه خارجی انجام بده (مثل فراخونی API یا کوئری گرفتن از دیتابیس یا...).

استانداردسازی: این پروتکل نحوه ارائه "ابزارها" و "قابلیت‌های" یک برنامه به LLM رو به شکل استاندارد تبیین می‌کنه.

سرور MCP: هر برنامه‌ای که بخواد توسط هوش مصنوعی قابل استفاده باشه، باید یه سرور MCP پیاده‌سازی کنه که رابط‌های تعاملی خودش رو اعلام کنه.

🧱 اجزای کلیدی (MCP Server)
سرور MCP سه مفهوم اصلی رو به LLM (که نقش کلاینت رو داره) ارائه می‌ده:

۱: ابزارها یا Tools:
مهم‌ترین جزء هستن. در واقع همون عملیات (Actions) یا APIهای سطح بالایی هستن که LLM می‌تونه فراخونی کنه. مثال: "ایجاد پایگاه داده" یا "رزرو پرواز" یا "درج یه سفارش جدید".
یک LLM برای انجام وظایف بهینه، به تعداد محدودی از ابزارهایی که به خوبی تعریف‌شده باشن نیاز داره.

۲: منابع یا Resources:
داده‌ها یا اطلاعات جانبی مورد نیاز برای اجرای ابزارها (دیتابیس، فایل حاوی داده یا ...).

۳: دستورالعمل‌ها یا Prompts:
متن‌هایی که به LLM کمک می‌کنن تا درک کنه چه زمانی و چجوری از ابزارها استفاده کنه.

🐤 یه نمونه MCP ساده برای تبدیل واحد توی کامنت می‌گذارم

✅ اصل مطلب: آیا API شما برای ساخت MCP کافیه؟
اگر نرم‌افزار شما RESTful باشه، ابزارهای متعددی هستن که از روی OpenAPI Spec شما برای MCP سرور می‌سازن. این رو داشته باشید فعلا تا ۳ تا حالت ساخت MCP رو ببینیم:
۱: خودکار
با استفاده از ابزارهایی مثل Fast MCP از APIهای فعلی رو به عنوان ابزار توی MCP سرور معرفی می‌کنیم. خیلی سریع! (بررسی مشکلات در بخش دوم همین مطلب)

۲: دستی
متناظر با قابلیت‌هایی که می‌خواهیم با استفاده از هوش مصنوعی ارائه کنیم، APIهای اختصاصی برای هوش‌مصنوعی تولید می‌کنیم، طبیعتا تعداد محدوتر، و کلی‌تر (مثلا یک API برای کل یک فرایند)


«ادامه در بخش دوم، فردا»
(مشکلات روش خودکار + معرفی روش سوم یا همون هایبرید)

✨ آیا APIهای فعلی‌مون می‌تونن MCPهامون رو بسازن؟! (بخش دوم)

در بخش ۱ دو روش خودکار و دستی ساخت MCP رو فقط نام بردیم و تحلیل این دو روش و معرفی روش سوم باقی موند!

چهار مشکل اساسی تولید خودکار
۱. معضل انتخاب بیش از حد
یکی از موضوعات مهم در کار با LLMها اینه که این مدل‌ها زمانی که با تعداد زیادی گزینه روبرو می‌شن، خِنگ می‌شن! و پاسخ‌های دقیقی ارائه نمی‌کنن. تصور کنید یک API با ۷۵ تا ۱۰۰ endpoint رو به‌طور خودکار به MCP تبدیل کنید. LLM با کلی ابزارها روبرو می‌شه و تصمیم‌گیری برای انتخاب ابزار مناسب برای هر کار، به یه چالش جدی براش تبدیل می‌شه. نتیجه؟ سردرگمی، انتخاب‌های نادرست، و در نهایت تجربه کاربری ضعیف. (حالا تصور کنین توی یک سیستم بزرگ که چند هزار و یا توی انترپرایزها چند ده هزار API خیلی خیلی عادیه)

۲. توضیحات نامناسب برای LLM
عملا APIهای سنتی با توضیحات نوشته شده برای توسعه‌دهنده‌های انسانی طراحی شده‌ان (بگذریم که ۹۹درصد APIهای خیلی شرکت‌ها همون رو هم نداره!). انسان‌ها می‌تونن استنباط کنن و سوال بپرسن.اما LLMها به توضیحات مستقیم، دقیق و اغلب مثال‌محور نیاز دارن تا بفهمن چه زمانی و چجوری باید از یه ابزار استفاده کنن. توضیحات API موجود شما، صرف‌نظر از اینکه برای انسان‌ها چقدر واضحه، احتمالاً برای LLM بهینه نشده.

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

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

🙂 ۳: هایبرید
ترکیبی از هر دو، که نیازی نیست از صفر شروع کنیم. نوشتن یک سرور MCP از ابتدا می‌تونه کار سنگینی باشه (حتی نمونه‌های ساده). راه‌حل بهینه، یک رویکرد ترکیبیه که از نقاط قوت تولید خودکار بهره بگیره، اما با بهینه‌سازی دستی تکمیل بشه.
مراحل پیاده‌سازی راه‌حل هایبرید:
۳-۱. شروع با تولید خودکار
از ابزارهای موجود برای تولید اولیه سرور MCP از API خودمون استفاده می‌کنیم. این به ما یه پایه‌ی سریع می‌ده.

۲-۳: هَرَس کردن ابزارها
تعداد endpointهای اعلان شده رو بنا به نیاز کاهش می‌دیم. فقط مهم‌ترین و پرکاربردترین ابزارها رو نگه می‌داریم. کیفیت بر کمیت ارجحیت داره.

۳-۳. بازنویسی توضیحات
توضیحات ابزارها رو به‌گونه‌ای بازنویسی می‌کنیم که برای LLMها مستقیم و صریح و قابل فهم باشن و بین APIها به اشتباه نیوفتن. از مثال‌های واضح استفاده بشه و سناریوهای استفاده رو به‌طور دقیق توضیح بدید.

۴-۳. افزودن ابزارهای سفارشی
ابزارهای جدید و اختصاصی که برای گردش‌های کاری مبتنی بر LLM طراحی شدن رو بسازیم، حتی اگر این ابزارها در API اصلی ما وجود نداشته باشن. این ابزارها می‌تونن چندین عملیات رو ترکیب کنن یا منطق سطح بالاتری رو پیاده‌سازی کنن.

۵-۳. تست و بهینه‌سازی
تست‌های جامعی بنویسید تا اطمینان پیدا کنین LLMها به‌درستی از ابزارها استفاده می‌کنن. این مرحله حیاتیه! خیلی هم حیاتی. چون خیلی چیزها که تئوری کار می‌کنن، ممکنه در عمل نیاز به تنظیم داشته باشن تا مدل اشتباه نکنه و مزخرف تحویل نده.

«ادامه در بخش سوم، فردا»

✨ آیا APIهای فعلی‌مون می‌تونن MCPهامون رو بسازن؟! (بخش سوم و آخری)

در بخش ۱ و ۲ علاوه بر مرور MCP و روش‌های ساختن MCP سرور، مشکلات تولید خودکار و نحوه ایجاد هایبرید رو مرور کردیم، بریم سراغ بخش سوم و آخر این مطلب:

نتیجه‌گیری:

در واقع MCP فرصت خیلی خوبی برای ایجاد یکپارچگی عمیق بین LLMها و سرویس‌های موجود ماست. اما مثل خیلی از تکنولوژی‌های جدید، موفقیت در جزئیات نهفته است. API موجود شما یک شروع عالیه، اما به‌تنهایی کافی نیست. تولید فَله‌ای و چشم‌بسته می‌تونه علاوه بر یک محصول افتضاح، باعث مشکلات خیلی خیلی جدی بشه، می‌پرسید چه مشکلی؟ یا فکر می‌کنید فوق فوقش درست کار نمی‌کنه؟ نه جانم! خیلی راحت می‌تونه باعث بشه دیتای غیرمجاز رو به کاربر غیر مجاز افشا کنه!! خیلی راحت همین فَله‌ای تولید کردن‌ها می‌تونه باعث بشه از حساب یکی دیگه اعتبار کسر یا اضافه بشه! کافیه بدون کنترل دسترسی، بدون فرایندهای کنترلی مضاعف، فَله‌ای MCP تولید کنین و برید توی لینکدین و توییتر بنویسید «خسته از کد زدن بسیار ولی خرسند از کاویدن اعماق هوش مصنوعی» (عکس با قهوه یا ماچا فراموش نشود!). چند روز بعدش هم که افتضاحش علنی شد، برگردیم به همون بحث عمیقا علمی PHP بهتر است یا Go یا دوران شی‌گرایی به سر اومده!!

ولی با پذیرش یک رویکرد ترکیبی، شروع با تولید خودکار و بعدش با بهینه‌سازی هوشمندانه (هوشمندانه یعنی مرور تمام ابزارهای افشا شده در MCP و بررسی توضیحات، سناریوها و نکات امنیتی) می‌تونید سرورهای MCP بسازین که نه‌تنها کار می‌کنن، بلکه واقعاً قدرت LLM رو توی نرم‌افزار سنتی آزاد می‌کنن تا کارهای «معناداری» برای کاربرها انجام بدن.

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

و یادآوری: اگر اون روزی که باید، OpenAPI رو جدی گرفته باشین، و best practiceها و اصول طراحی رو رعایت کرده باشین، امروز خیلی راحت‌تر می‌تونین همون نرم‌افزار موجود رو با LLM توانمند کنید.
مطالبی مثل این یا این پیشتر در همین باب توی کانال نوشته‌ام که اگر دوست داشتید مطالعه کنید.

💬 تجربه و نظرتون درباره تولید MCP و استفاده توی نرم‌افزارهای LOB چیه؟

✈️ معرفی Microsoft Agent Framework برای پایتون و دات‌نت؛ توسعه ساده‌تر سیستم‌های ایجنتیک

مایکروسافت اخیرا فریم‌ورک کدباز Agent Framework رو معرفی کرد که عملا با ترکیب ایده‌ها و قابلیت‌هایی که پیشتر به صورت مجزا در Semantic Kernel و AutoGen ارائه کرده بود، کمک می‌کنه تا توسعه‌دهنده بتونه ربات‌ها یا ایجنت‌های مورد نظرش رو با انعطاف، مقیاس‌پذیری و پایداری مورد انتظارش بسازه و مدیریت کنه.

چرا MAF مهمه؟ چون پایان یک دوراهیه!
تا الان یه دو راهی مهم جلو پای توسعه‌دهنده‌ها بود:

۱: استفاده از Semantic Kernel: که پایداری و آمادگی لازم برای محیط‌های سازمانی و پروداکشن رو داره.

۲: استفاده از AutoGen: که برای نوآوری، آزمایش و ساخت ایجنت‌هایی که با هم گفتگو و تعامل دارن مناسبه (یعنی Multi-Agent Orchestration؛ همچنین توسعه و نگهداریش هم با Microsoft Research’s AI Frontiers Lab است که از اسمش مشخصه تکنولوژی‌های نوآورانه و در دست توسعه رو دنبال می‌کنه).

ولی حالا هر دو رو در توی یک پکیج واحد داریم.

✅ استانداردهای باز و تعامل‌پذیری
از پروتکل‌هایی مثل MCP، Agent2Agent، و طراحی OpenAPI-first پشتیبانی می‌کنه؛ و امکان اتصال آسون به ابزارها و سرویس‌های مختلف بدون وابستگی به یک اکوسیستم خاص رو فراهم می‌کنه.

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

✅ قابلیت گسترش (Extensibility)
ماژول‌های حافظه قابل انتخاب هستن (مثل Redis، Pinecone، Qdrant)، کانکتورهای سازمانی می‌شه براشون نوشت یا از نمونه‌های آماده استفاده کرد، تعریف ایجنت به‌صورت YAML یا JSON. می‌شه خیلی سرراست اجزا رو بر اساس نیاز پروژه تا حد زیادی سفارشی کرد.

✅ آمادگی برای تولید (Production-Ready)
امکانات مورد نیاز محیط پروداکشن مثل observability، کنترل خطا، checkpointing، امنیت و فلوهای CI/CD رو داره و می‌تونه توی پروژه‌های واقعی با الزامات سازمانی به کار بره. و Human-in-the-Loop رو داره؛ یعنی قابلیت "تایید توسط انسان" برای عملیات‌های حساس؛ ایجنت قبل از اقدام منتظر تأیید می‌مونه.

شروع کار:
این فریم‌ورک کاملاً متن‌بازه و برای Python و NET. در دسترسه و مثال‌های خیلی خوبی هم برای شروع داره.

مخزن گیت‌هاب
داکیومنتیشن و راهنمای نصب

💡 پیشنهاد می‌کنم بدون به دام حباب‌ و هیجان افتادن؛ هم این کاربردها رو یاد بگیرید، هم به استفاده ازشون فکر کنید، چون شاید خیلی زود دیر بشه! کاربری AI فقط سوال پرسیدن، توهمات ناشی از وایب‌کُدینگ و... نیست...

🐤 مطلب بعدی در مورد ۳ تا از بارزترین خصوصیات «بدترین برنامه‌نویس یا مهندس نرم‌افزار» خواهد بود!

به نظر شما به چه خصوصیاتی می‌شه گفت بدترین و افتضاح‌ترین؟ 🤔
کامنت کنید لطفا

حتی اگه نظرتونه که
- پنگوئن یا سیب یا پنجره دوست داشته|نداشته باشه 😅
- یا همه چیز رو آبجکت ببینه یا فانکشن ببینه!
- یا اینکه موقع کار، ماچا بخوره یا چایی‌شیرین!

🐊 بدترین مهندس نرم‌افزار دنیا چه شکلیه؟ شاید هم خودمونیم؟؟

این مطلب صرفا نظر و تجربه شخصیه؛ نسخه جهان‌شمول یا خط‌کش نیست. تجربه‌ی بیش از دو دهه تعامل و دقت در رفتارها و مسیر رشد آدم‌ها از نگاه یک نفر از ۸ میلیارد جمعیت زمین است! قطعا میشه متون دقیق‌تر، کامل‌تر و موشکافانه‌تری هم نوشت؛ ولی شاید مرورش خالی از لطف نباشه...

لیست معضلات رفتاری، فنی، اخلاقی و تیمی خیلی بلند و مفصله. اما بعضی ویژگی‌ها، نه‌فقط مشکل هستن، بلکه مانع یادگیری و ریشه‌ی معضلات دیگه هم می‌شن. من قبل از نوشتن این مطلب، سعی کردم رفتارها و خصوصیت‌هایی که در خودم «تصور» می‌کنم بهبود دادم رو مرور کنم، ببینم اگر چه خصوصتی داشتم، مانع جدی برای بهبود می‌شد؟! بعد این لیست رو اینقدر مرور کردم که چکیده‌ای از رذائل دربیارم که ریشه مشکلات باشن! به نظرم اون‌هایی واقعاً «افتضاح‌ترین» هستن که ترکیب خطرناکی از این ۳ ویژگی رو دارن:

۱. نداشتن صداقت و اخلاق حرفه‌ای
یادمون نره: بدترین برنامه‌نویس، کسی نیست که اشتباه می‌کنه؛ کسیه که اشتباهش رو پنهان می‌کنه.

✏️ مصداق‌ها:
- وانمود می‌کنه چیزی رو بلده ولی بلد نیست
- دروغ می‌گه که پیشرفت پروژه خوبه، در‌حالی‌که نیست (green shifting)
- عامدانه code review تقلبی می‌ده؛ فقط یه ابزار آنالیز خودکار باز کرده
- باگ‌ها رو قایم می‌کنه

😡 چرا بده؟ چون اعتماد تیم رو نابود می‌کنه. بدون اعتماد، حتی بهترین فرآیندها هم به لجن کشیده می‌شن. این افراد به خودشون هم دروغ می‌گن. تقلب می‌کنن و کار کردن با کسی که عامدانه دروغ می‌گه و بهش عادت کرده، دیگ داغیست از دیگ‌های داغ جهنم!

۲. بی‌سؤالی، تعصب، توقف رشد
بزرگ‌ترین ریسک صنعت ما توقف یادگیریه؛ نه نابلدی!

🧠 کسی که سوال نداره، انگار دیگه دنبال بهتر شدن نیست.
🔒 کسی که تعصب داره (فقط فلان زبان، فقط فلان ابزار)، راه اصلاح رو به خودش بسته؛ شاید فکر کنه داره یاد می‌گیره؛ ولی داره مهارتش در یاد نگرفتن و توجیه نادانی‌اش رو تقویت می‌کنه.
🙈 کسی که اشتباه می‌کنه، ولی فکر می‌کنه تقصیر دنیاست، یعنی از دورِ یادگیری خارج شده.

فرق کسی که رو به جلو می‌ره و کسی که رو به زواله توی همین چیزاست.

۳. بی‌مالکیتی و انفعال

"به من بگو چی‌کار کنم" ممکنه از دهن یه تازه‌کار قابل قبول باشه. ولی یه مهندس واقعی باید خودش دنبال معنی، مشکل، راه‌حل، و تبعات کارش باشه.

📡 نشونه‌ها:
- فقط همون کاری رو می‌کنه که دقیقاً بهش گفتن
- هیچ پیش‌فرضی رو به چالش نمی‌کشه (تفکر نقادانه نداره اساسا)
- تغییرات رو با مقاومت پاسخ می‌ده (فناوری، فرآیند، ابزار)
- کارش رو فقط "تا اینجا وظیفه‌م بود" می‌بینه

❓ چرا بده؟ چون تیم رو از یه گروه خلاق به یه کارخانه "دستور بگیر - خروجی بده" تبدیل می‌کنه. هیچ self-organization واقعی‌ای شکل نمی‌گیره. (توی پست نرم‌افزار و این روزهای ایران مفصل نوشتم)

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

یه آدم فاقد principle، بر اساس منفعت لحظه‌ای رفتار می‌کنه. یه بار پنهان می‌کنه، یه بار تقلب می‌کنه، یه بار مقاومت در برابر حرف صحیح، یه بار انفعاله... چون "راهنمای درونی" نداره.

🤝 و آخرش اینه:
- می‌شه چیزی رو بلد نبود، ولی یاد گرفت، «سوال خوب داشت»
- می‌شه هم‌تیمی خوبی نبود، ولی مهارت کار تیمی رو تقویت کرد
- می‌شه اشتباه کرد، ولی پنهانش نکرد، دنبال راه‌حل گشت، مقاومت و فرافکنی نکرد و دیگه تکرار نکرد
- می‌شه بهترین نبود، بهترین جا نبود؛ ولی با ساکن و منفعل نبودن، جای بهتری قرار گرفت، محیط بهتری ساخت...

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

💬 حالا نوبت شماست:
کامنت کنید؛ شاید کمک کنه فردا کمی بهتر از امروز باشیم 🌱