AZ-200 قراره آخر این ماه بازنشسته بشه.
چی بود؟ مدرک آژور برای برنامه نویسها.
بازنشسته میشه چون مطالبی که تو این آزمون سنجیده میشدند کامل نبودند و قراره مدرک AZ-204 جایگزینش بشه. تقریبا میشه گفت همون مباحث قبلیا توش هست + تمرکز بر AI.

دیروز اسپک جدید برای MCP ها منتشر شد. مهمترین و کلیدی ترین اتفاق توش اینه که درخواستها Stateless خواهند بود. باقی توضیحات آورده شده تو سندشون در اصل پیدا کردن راه حلی برای رسیدن به این هدف بوده به نحوی. مثلا اینکه از متادیتا برای یه سری چیزها که تو سشن بود استفاده کنند.

خیلی وقتها که به عقب برمیگردم و نگاه میکنم میبینم بزرگترین اشتباهاتم از عدم نوشتن بوده.منظورم کد نیست.اتفاقا چیزیه فرسنگها جلوتر از کده.
چیزیه که امروز یاد گرفتم هرجا وارد شدم «اولین» چیزی باشه که تو اون سازمان جا بندازم.
نوشتن اسناد و آرتیفکتها.
اگر زودتر بلد بودم،یاد میگرفتم چطور میتونستم بگم «چطور این سیستم رو بسازیم؟» (Design Document)
یا چطور بگم «آیا این تغییر رو انجام بدیم؟»(RFC)
یا چطور بگم «چطور این تصمیم رو گرفتیم؟»(ADR)
یا چطور بگم «آیا این موضوع رو شروع کنیم؟»(Proposal)
یا «چطور از سیستم قدیمی دل بکنیم و بریم سراغ جدیدش؟»( Migration Plan)
یا چطور بگم«فلان چیز چرا خراب شد و چطور دوباره تکرار نشه؟»(Incident Review)
یا چطور بگم «قراره به کجا برسیم تو آینده؟»(Technical Strategy )

یاد میگرفتم که نوشتنه که ارزش تو و تیمت رو نشون میده.

یاد میگرفتم enterprise بودن سازمانها نه به ادعای خودشونه،نه به رنج حقوقیشون و نه میزان تراکنش مالیشون و تعداد پرسنلشون. برای من فرهنگ «نوشتن»شون مهمه

تو این هفته دوتا اتفاق خوب برام افتاد که ازطرفی هم خیلی باارزش بود و از طرفی هم خیلی مغفول.
یکیش این بود که اسمم تو لیست تکنیکال ریویورهای آینده انتشارات Apress رفت. داستان از اینجا شروع میشد که موقعی که داشتم ریپوی مربوط به یکی از کتابهاشون رو میخوندم متوجه شدم یه بخشی از کتاب در دست انتشارشون آپدیت نیست. پس هم ایشو raise کردم و هم ازطریق ایمیل بهشون اطلاع دادم. ولی به علت نزدیکی به انتشار کتاب(آخرسپتامبر) احتمالا تو این ورژن نرسیم. و گفتن تو لیست قرار میگیرم برای کار بعدی.
دومیش هم ایشویی بود که برای sdk رسمی سی شارپ نوشته بودم که valid شمرده شد و تو دستور کار قرارگرفت.

اینها نه اونقدر هنوز بزرگند که بتونم مثلا تو فضای عمومی بیانشون کنم و نه اونقدر کوچیک که بتونم ایگنورشون کنم.

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


من برای خودم شادی میکنم. چه برای بقیه بزرگ باشه و چه کوچیک. همین جشن گرفتنها سوخت ادامه مسیره.
لینک ایشوهایی که گفتم:
https://github.com/modelcontextprotocol/csharp-sdk/issues/1770#issuecomment-5147114239

https://github.com/Apress/Building-MCP-Servers-with-C-Sharp/issues/1

یکی از غلط ترین اطلاعاتی که در سطح سنیور میبینید بحث سر ردیس و سینگل thread بودنشه.
وقتی ازش صحبت میشد طوری گفته میشد که انگار برنامه نویسای ردیس یه اشتباهی رو کردند که multi thread طراحیش نکردن. یا مثلا وقتی ردیس رو مینوشتن ترد نبوده و اینها هم دیگه حوصله شون نشده بازنویسیش کنن.

و اغلب داستان اینجا اوج میگیره که یکی که مثلا آپدیت تره میگه: بابا ردیس که دیگه خیلی وقته single thread نیست. از ورژن ۶ به بعد مالتی ترد شده.


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

تو خیلی از سیستمهایی که میشناسیم از جمله همین ردیس اتفاقا سینگل ترد بودنش باعث سرعتش شده.
اگر خواستید بیشتر درموردش بخونید:
https://dev.to/akbar_dizaji/why-one-writer-can-beat-hundreds-of-threads-1gd4

مرج یه PR کوچیک دیگه تو ریپوی csharp-sdk:
https://github.com/modelcontextprotocol/csharp-sdk/pull/1769#event-28970855005

قبول دارید؟

هر چیزی که نیاز به «یادآوری» داشته باشه وقتی میریم تو اسکیل بزرگ،شکننده میشه.
چون دولوپر ممکنه خسته باشه،ریویور ممکنه نبینه،فرد تازه وارد اصلا ندونه،ai ممکنه ایگنورش کنه و … .

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

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

https://www.youtube.com/watch?v=a8kAtDitM2E

#موقت
یه خواهش:
شرگتمون یه جایزه و کمپین گذاشته که همه همکارا یه پستی رو ریپست کنیم و برای کسی که پستش بیشتر لایک بخوره برنده میشه و یه جایزه میدن. اگر حمایت کنید که کم نیارم پیششون ممنون میشم😁✌
https://www.linkedin.com/posts/akbardizaji_one-less-thing-to-worry-about-ugcPost-7490846934522593280-1LhX/?utm_source=share&utm_medium=member_desktop&rcm=ACoAABq4oHwBkfJsQPDhV_PfVQ2Z7q19f1BHqU4

احتمالا نوشتن اینا براتون سخت باشه. و حتی اینکه یادتون باشه که الان نوشتن یه سند خوبه.
AgentRecall یه مدته این قابلیت رو داره.
بعد از هر چتتون میبینه آیا کاندیدی برای تولید یه سند تو این چت وجود داره یا نه.
فقط باید آپدیتش کنید.
اگر براتون این هم سخته یه agentrecall doctor داره که اگر باز براتون سخت بود به ai بگید خودش این دستور رو براتون اجرا کنه.

درکنار ci و cd داره یه مفهوم دیگه ای هم داره متولد میشه: cm(continuous modernization)
اینکه دیگه technical debt ها جمع نشند و بعد از چندماه بریم سراغشون. به صورت مداوم بدهی های فنی رو پرداخت کنیم. این موضوع بخاطر این جدیتر شده چون سرعت تولید کد و درنتیجه سرعت ایجاد بدهی افزایش پیدا کرده.
حتی سرویسهای ابری مثل آمازون و آژور هم دارن سرویسهایی رو براش ارائه میدن ولی بدون اونها هم قطعا قابل اجراست.سادهترین و دم دست ترین راه اینه که یه ai دیگه بذاریم ریویو کنه ولی قطعا برای بالغ شدن این موضوع نیاز دارید از کاپایلر هم کمک بگیرید.مثلا تو دات نت از رزلین. این باعث میشه ساختار کد رو دستتون داشته باشید

داشتم تو وبلاگ مارتین فاولر میچرخیدم یه مقاله جالب دیدم. ایده اش این بود که برای کنترل تنوع جوابهای ai که باعث خرابکاری ممکنه بشه بیایم dsl بسازیم. dsl دراصل زبان کوچیکیه که برای همون دامین و نیاز خودمون تعریف میکنیم.
خب ساخت dsl بنظرم خودش خیلی سخته.اما پشت این مقاله شون یه حرف بزرگ خوابیده.اینکه همه دارن میبینن ai چطور میتونه سرکش باشه و دارن راه های deterministic رو برای مهارش کم کم وارد میکنن

اگه اکانت گیت هاب قدیمی دارین، باهاش اینجا ساین آپ کنین تا 150 دلار اکانت claude بگیرین. تستش کردم و به زیبایی کار میکنه.
https://agentrouter.org/register?aff=BGsd
https://tabitoken.com/sign-up?aff=aF26
https://gorouter.app/sign-up?aff=gLQa

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

تو سفر کوتاهم به ایران دوتا مقاله تو فراغتم خوندم که یکیش خوب بود و اون یکی خیلی بهش نقد دارم:
اولیش میگفت زبان Go بهترین زبان برای توسعه تو دنیای ai هست. این مقاله تو کامیونیتی همون زبون به صورت کاملا بلایند ترند شد.بنظرم کل مقاله حرفای چالشی بود. اولیش اینکه خب این موضوع رو خود گوگل داره پرموت میکنه. طبیعتا من بهش بعنوان تبلیغ نگاه میکنم ولی یه عده خیلی جدیش گرفتند گویا. مثلا یکی از ادعاهاش اینه go اجازه خطا کردن رو به ایجنتها نمیده و safty ایجاد میکنه. بخوایم صادق باشیم زیانهای دیگه هم همینو دارن و باقی موارد ادعایی رو دارن.

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

با درخواست انتشارات Packet به عنوان Early reader کتاب Claude Visual Bible بودم و قراره ۱۵ سپتامبر ریویو خودمو تو جاهایی که عرضه میشه بگم ولی قبلش به صورت غیررسمی دوس داشتم اینجا کوتاه بیانش کنم:
بیشتر از چیزی که از عنوانش انتظار داشتم، از خود کتاب خوشم اومد. تصورم اول و قبل از شروع کردن به خوندن این بود که با یک راهنمای تصویری برای کار با Claude و یه مجموعه‌ از screenshot و prompt آماده روبرو میشم ، اما کتاب آروم آروم از آموزش ساده‌ Chat عبور میکنه و به این میرسه که چطور میشه یک فرایند قابل کنترل و تکرارپذیر دور AI ساخت. یعنی بهتون فقط یاد نمیده چه فیچری کجاست بلکه میگه چطور از claude خوب استفاده کنیم. یکی از نقاط قوت اصلی کتاب اینه که تقریبا از همون اول روی نقش آدمیزاد تو بررسی نتیجه تاکید میکنه و اینکه Claude قرار نیست فقط جواب تولید کنه و ما اونو بپذیریم. کتاب بارها پیشنهاد میکنه قبل از اجرا هدف، محدودیت، منبع و معیار موفقیت را مشخص کنیم و بعد نتیجه رو با source اصلی بررسی کنیم. این طرز فکرو فصل‌های بعدی جدیتر هم میشه: از مشخص کردن اطلاعاتی که نیاز به بررسی داره بگیر تا جدا کردن evidence از interpretation و تعریف acceptance criteria برای کارهای تکرارشونده. چیزی که به نظرم کتابو از خیلی از آموزشای AI جدا میکنه اینه که فقط روی "prompt بهتر" تمرکز نمیکنه. کم کم وارد موضوعاتی مثل context، permissions، source boundaries، verification، reusable workflows، Skills و automation میشه.
مسیر کتاب از "چطوری سوال بهتری بپرسیم" به "چطوری AI را وارد یک workflow واقعی کنیم" حرکت میکنه.
با همه این اوصاف، کتاب ضعفهایی هم بنظرم داره. برای کسی که قبلا زیاد با ابزارهای AI کار کرده، بخشی از فصلای ابتدایی بیش از حد مقدماتی و گاهی تکراری هستن که البته بخشی از این موضوع اجتناب ناپذیره. چندین بار همون الگوی Brief → Outline → Generate → Review در contextهای مختلف تکرار میشه. از طرف دیگه قسمت‌های وابسته به UI، planها، نام featureها و مدلها احتمالا سریعتر از مفاهیم اصلی کتاب قدیمی شاید بشن اما خب نمیشد نگفتنشون هم.و شاید نقد بعدی این باشه که بعضی چیزها میشه کنار هم ذکر بشند ولی بدون اشاره به اینکه قراره بعدا بهش برسه میگذره و حتی بعدا هم که بهش میرسه خیلی سریع ازش عبور میکنه.

پ.ن: من Technical Reviewer نبودم و Early Reader بودم

⚰ TDD is Dead. ⚰
به همین سادگی. تی دی دی رو میشه تو عصر کد نوشتن ai یه فرایند عبث فرض کرد که هیچ آورده ای نداره.
اینکه اول به مدلتون بگید براتون تست بنویسه عملا حتی کمکی به خود مدل برای کشف کانتکس نمیکنه.چون مدل برای نوشتن همون تستها باید بره سراغ کانتکسهایی که برای نوشتن کد هم نیازه پس فقط ترتیب نمایش و پیاده سازی کد و تست تغییر میکنه نه کیفیت و کارایی.

یکی از چیزایی که خیلی داره صحبت میشه کیفیت تستهای نوشته شده است. چه ai بنویسه و چه خودت.
حرف درموردش واقعا زیاده.
بیشترین فرکانس صحبت تو تاک ها و مقالات شاید میوتیشن تست باشه.
یعنی تعمدا کدت رو بهم میریزی و میبینی آیا تستها تونستن کشفش کنن یا نه.
تجربه شخصیم رو بذارید درموردش بگم.
من هم شروع کردم به استفاده از stryker برای میوتیت کردن کدها و سنجششون. زمان صرف شده فاجعه بود. استفاده از سوییچهای خود کتابخونه مثل —since و ران کردنش صرفا روی pr ها زمان رو کم کرد ولی هنوز رضایت بخش نبود.
چون اساسا این نوع کتابخونه ها به صورت استاتیک شروع به بهم ریختن کد میکنن که گاها اصلا به هم ریختن اون بخش کد مفهوم و دغدغه بیزینسی نداره.
اما با دادن این وظیفه به ai میشد سناریوهای واقعی میوتیشن رو کشف کرد. توصیه میکنم این مقاله متا رو بخونید:
https://engineering.fb.com/2025/09/30/security/llms-are-the-key-to-mutation-testing-and-better-compliance/?utm_source=chatgpt.com

این مقاله اساس کار من شد برای نوشتن واسکیلی که میوتیشن توش سمنتیک باشه. این ایده خیلی خوب جواب داد و تو همون هفته اول تستش تونست تعداد خوبی باگ که توسط تستها و حتی تیم QA هنوز کشف نشده بود رو پیدا کنه. یعنی یه تستر بی نظیر.
تعداد میوتیشنها هم به صورت چشمگیری کم شد و فقط چیزهایی که معنی دار بودند مونده بودند. قبلا مثلا ۹۰ تا جا رو تغییر میداد ولی با روش جدید رسید به ۸-۹ تا.
موضوع بعدی فروش این دستاورد بود به تیم که بعدا میگم.

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

اما همیشه هم شدنی نیست. تو فصل آخر کتاب Staff Engineer یه جا جرف جالبی میزنه. میگه این حرفا رو که زدیم خیلی به ساختار سیستم وابسته است. قرار نیست شما تو همه سیستمها بتونید اظهارنظر کنید.بتونید تغییر ایجاد کنید. گاهی هم باید فهمید اون سیستم کشش اون رو نداره.