وقتی Span کم میاره! (خداحافظی با ارورهای عجیب Async)

توی پست قبلی دیدیم که Span<T> چقدر سریعه، چون داده‌ها رو کپی نمی‌کنه. اما به محض اینکه خواستم توی یه متد Async (مثلاً موقع دانلود فایل یا دیتابیس) ازش استفاده کنم، کامپایلر کوبید تو صورتم!
ارور معروف: Span cannot be used in async methods.

چرا؟
چون Span روی Stack زندگی می‌کنه (حافظه موقت و سریع). وقتی شما await می‌کنید، کانتکست عوض میشه و Span گم میشه. نمی‌تونی اون رو توی کلاس ذخیره کنی یا منتظر بمونی.

💡 قهرمان داستان: Memory<T>
اینجاست که دات‌نت Memory<T> رو معرفی کرده.
اگه Span مثل یه یادداشت روی دستت باشه (سریع ولی موقت)، Memory مثل یه دفترچه یادداشت واقعیه.
✅ تفاوت کلیدی:
۱.ء Span: فقط برای پردازش همگام (Sync) و لحظه‌ای.عمر کوتاه
۲.ء Memory: برای ذخیره‌سازی در کلاس‌ها و عملیات ناهمگام (Async).عمر طولانی

فرمول طلایی مایکروسافت:
هر وقت داده رو لازم دارید ولی نمی‌دونید کِی کارش تموم میشه (مثل Task)، از Memory استفاده کنید. هر وقت خواستید پردازشش کنید، ازش یه .Span بگیرید و با سرعت نور کار کنید!

شما تو پروژه‌های سنگین، چطور داده‌های حجیم رو بین متدهای Async پاس میدید؟

#استخدام

استخدام برنامه‌نویس Back-End (.NET Core / Microservices)
شرح موقعیت شغلی:
ما در شرکت ایز ایران (کنسرسیون متمایز) به منظور توسعه و نگهداری سامانه‌های مبتنی بر معماری مایکروسرویس و تکنولوژی‌های روز، از برنامه‌نویسان Back-End توانمند و علاقه‌مند به کار در پروژه‌های مقیاس‌پذیر دعوت به همکاری می‌شود.
شرایط و مهارت‌های مورد نیاز:
حداقل ۳ سال تجربه کاری مرتبط
تسلط به .NET Core
تسلط به SQL و طراحی پایگاه داده
تجربه کار با Dapper و EF Core
آشنایی با RabbitMQ
تجربه کار با Redis
تجربه کار با Docker و مفاهیم Containerization
تسلط به Git
آشنایی با مفاهیم CI/CD
درک مناسب از معماری Microservices
نوع همکاری:
تمام‌وقت
مزایا و امکانات:
بیمه تأمین اجتماعی
بیمه تکمیلی (SOS)
ناهار و میان‌وعده
محیط کاری حرفه‌ای و تیم فنی پویا
فرصت رشد و یادگیری در پروژه‌های بزرگ
لینک های زیر جهت ارسال رزومه می باشد.
https://lnkd.in/eziqVU9z
https://lnkd.in/ehXHUQqz

لیست‌هایت را فقط خواندنی کن! خداحافظی با تغییرات ناخواسته

یکی از اصول مهم در طراحی کلاس‌ها، حفظ یکپارچگی داده‌هاست. اگر یک پراپرتی از نوع List<T> رو به صورت عمومی (Public) در دسترس قرار بدید، یعنی به همه اجازه دادید که محتوای اون لیست رو (بدون اجازه شما) اضافه، حذف یا پاک کنن!

✅ راه حل حرفه‌ای: استفاده از Read-Only Collections
در سی‌شارپ، با استفاده از ReadOnlyCollection<T> یا اینترفیس IReadOnlyList<T> می‌تونید به بقیه اجازه بدید داده‌ها رو فقط ببینند، اما نتونند تغییرش بدن.
به جای:

public List<string> Names { get; set; }

از این الگو استفاده کنید:

public IReadOnlyList<string> Names => _names.AsReadOnly();

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

جزئیات بیشتر و مثال‌های عملی رو در این مقاله بخونید:
https://lnkd.in/eET__xeR

شما برای محافظت از لیست‌ها معمولاً از IEnumerable استفاده می‌کنید یا IReadOnlyList؟ توی کامنت‌ ها بنویسید.

#استخدام

Back-End Developer (.NET Core)
تماموقت | حضوری
امید بانک سپه جهت تکمیل تیم فنی خود از متخصصین Back-End .NET Core مسلط به معماری Microservices دعوت به همکاری مینماید.
شرایط احراز:
تسلط به C# و ASP.NET Core
تجربه عملی در Microservices Architecture
تسلط به دیتابیس SQL Server
آشنایی با MongoDB و Redis
آشنایی با RabbitMQ و Message Brokerها
آشنایی با Elasticsearch
آشنایی با Git و مفاهیم CI/CD

📩 ارسال رزومه در لینکدین یا ایمیل زیر:
[email protected]

سکانسی از فیلم راکی

🎨 برنامه نویسی با حال و هوای جدید!

بالاخره نسخه ۴ اکستنشن ویژوال استودیوی من آماده شد! 😍
توی این نسخه حسابی گردگیری کردیم و تعداد تم‌ها رو به ۴۴ تا رسوندیم.
اگه دنبال یه تغییر توی محیط کدنویسیتون هستید یا می‌خواید چشمتون کمتر خسته بشه، DotNET Theme v4 رو نصب کنید. تم‌هایی مثل Dracula، Nord، Monokai، و حتی تم‌های شبیه VS Code الان توی ویژوال استودیو در دسترسن.

دانلود

سورس

چرا ReadOnly برای امنیت داده‌های شما کافی نیست؟

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

راه حل واقعی:
Immutable Collections
اگه می‌خواید داده‌هاتون مثل سنگ نوشته ثابت بمونن و با هیچ طوفانی (حتی توی Multi-threading) تکون نخورن، باید برید سراغ System.Collections.Immutable.

✅ فرقش چیه؟
۱.ء ReadOnly: اگه مرجع اصلی عوض بشه، اینم عوض میشه. (وابسته)
۲.ء Immutable: یه کپی کاملاً مستقل و ثابت. (مستقل)

جادوی Immutable:
وقتی می‌خواید به لیست Immutable آیتم اضافه کنید (Add)، اون لیست قبلی رو دستکاری نمی‌کنه! بلکه یه لیست جدید با اون آیتم اضافه شده بهتون میده.
این یعنی History یا تاریخچه داده‌هاتون همیشه حفظ میشه و هیچ باگ همزمانی (Concurrency) نمی‌تونه سیستم رو کرش کنه.

شما برای داده‌های حساس و ثابت (مثل کانفیگ‌ها) از کدوم استفاده می‌کنید؟

🔗 اطلاعات بیشتر

خداحافظی با کندی جستجو در داده‌های ثابت! سلام بر FrozenDictionary

تا دیروز وقتی یک لیست ثابت (مثل کانفیگ‌ها یا داده‌های مرجع) داشتیم، فکر می‌کردیم ImmutableDictionary بهترین گزینه است. امن بود، ترد-سیف بود، ولی... سریع‌ترین نبود!
دات‌نت ۸ با معرفی Frozen Collections بازی رو عوض کرد.

تفاوت کجاست؟

وقتی شما از ToFrozenDictionary() استفاده می‌کنید، دات‌نت وقت بیشتری می‌ذاره تا داده‌ها رو آنالیز کنه و بهترین ساختار هَش (Hash) رو برای اون داده‌های خاص بسازه.
این سرمایه‌گذاری اولیه باعث میشه که بعداً سرعت خواندن (Read) به طرز وحشتناکی بالا بره.

قانون انتخاب:

۱. اگه داده‌هاتون مدام تغییر می‌کنه - Dictionary (معمولی)
۲. اگه امنیت و ترد-سیف بودن مهمه ولی آپدیت هم دارید - ImmutableDictionary
۳. اگه داده‌ها یک بار لود میشن و دیگه تکون نمی‌خورن و سرعت جستجو حیاتیه - FrozenDictionary

پ.ن: بهینه‌سازی همیشه به معنی بازنویسی کد نیست؛ گاهی فقط انتخابِ ظرفِ درست برای داده‌هاست.
شما تو پروژه‌هاتون برای داده‌های ثابت (Static Data) از چی استفاده می‌کنید؟

🔗 اطلاعات بیشتر

اگه هنوز دو تا foreach تو در تو می‌نویسی، این پست مال توئه!

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

❌ روش سخت - The Hard Way:
ساختن یه لیست خالی، نوشتن حلقه روی فاکتورها، نوشتن حلقه روی محصولات، و Add کردن دونه دونه...

✅ روش هوشمندانه - The Smart Way:
استفاده از متد قدرتمند SelectMany.
این متد کارش صاف کردن (Flattening) ساختارهای درختیه.
var allProducts = orders.SelectMany(o => o.Products);

این دستور میگه: برو تو دلِ هر سفارش، محصولاتش رو بردار و همه رو بریز رو هم، یه لیست صاف بهم بده.

نکته کنکوری:
فرق Select و SelectMany دقیقا همینجاست:
ءSelect: لیستی از لیست‌ها میده (List<List<Product>>)
ءSelectMany: یک لیست واحد میده (List<Product>)
کد تمیزتر = باگ کمتر + نگهداری راحت‌تر.

شما کجاها از SelectMany استفاده کردید که نجاتتون داده؟

می‌خواهی یک برنامه‌نویس حرفه‌ای باشی یا فقط کد می‌زنی؟

شاید فکر کنیم حرفه‌ای بودن یعنی داشتنِ عنوان Senior یا Lead در لینکدین، یا تسلط بر ۱۰ زبان برنامه‌نویسی!
اما رابرت سی. مارتین - Uncle Bob در کتاب شاهکارش The Clean Coder نظر متفاوتی دارد.

او می‌گوید: حرفه‌ای‌گری یعنی پذیرفتن مسئولیت.

من قبلاً این کتاب ارزشمند را به فارسی ترجمه کردم و حالا تصمیم گرفتم فصل‌به‌فصل نکات کلیدی‌اش را با شما به اشتراک بگذارم. پست امروز، عصاره‌ی فصل اول: حرفه‌ای‌گری (Professionalism) است. فصلی که مثل یک سیلی محکم به صورت ما توسعه‌دهندگان است!
خلاصه این فصل در ۴ اصل کلیدی:

1️⃣ اول، آسیب نزن:
درست مثل پزشکان، اولین وظیفه ما این است که به نرم‌افزار آسیب نزنیم. فرستادن کدی که می‌دانی (یا شک داری) ناقص است به واحد QA، نهایت غیرحرفه‌ای بودن است. QA نباید باگ پیدا کند؛ آن‌ها برای اطمینان نهایی هستند، نه برای پیدا کردن اشتباهاتِ بدیهی ما.

2️⃣ تست‌نویسی یک وظیفه است، نه پیشنهاد:
چطور مطمئن می‌شوی کدت کار می‌کند؟ تستش کن! تست‌های خودکار باید ۱۰۰٪ کد تو را پوشش دهند. این تنها راهیه که شب‌ها راحت بخوابی و از تغییر دادن کد نترسی.

3️⃣ قانون ۶۰ ساعت کار:
عمو باب معتقد است برنامه‌نویس حرفه‌ای هفته‌ای ۶۰ ساعت کار می‌کند: ۴۰ ساعت برای کارفرما و ۲۰ ساعت برای خودش! این ۲۰ ساعت باید صرف مطالعه، تمرین (Kata) و یادگیری شود. کارفرما مسئول آموزش تو نیست؛ حرفه‌ی تو، مسئولیت توست.

4️⃣ تمرین به سبک نوازندگان:
کار روزمره اجرا است، نه تمرین. نوازنده‌ها ساعت‌ها تمرین می‌کنند تا در کنسرت عالی باشند. ما هم باید خارج از ساعات کاری تمرین کنیم تا مهارت‌هایمان تیز بماند.

این کتاب فقط درباره کدنویسی نیست؛ درباره‌ی شخصیت ما به عنوان یک مهندس نرم‌افزار است.

فصل اول، کلین کدر

تا حالا چند بار برای راضی نگه‌داشتن مدیرت، به یک ددلاین غیرممکن گفتی چشم، سعی‌ام رو می‌کنم؟


در ادامه ترجمه کتاب بی‌نظیر The Clean Coder (اثر رابرت سی. مارتین)، به فصل دوم یعنی نه گفتن (Saying No) رسیدیم. فصلی که احتمالاً خیلی از ما با خوندنش یاد خاطرات تلخ اضافه‌کاری‌های بی‌نتیجه و کدهای کثیف می‌افتیم!

عمو باب در این فصل یک خط قرمز پررنگ می‌کشه: حرفه‌ای‌ها جرئت دارند حقیقت را به قدرت بگویند.

خلاصه این فصل جنجالی در ۴ نکته طلایی:

1️⃣ چیزی به نام سعی کردن وجود ندارد! (قانون یودا): وقتی مدیرت یک کار غیرممکن می‌خواد و تو می‌گویی سعی می‌کنم، در واقع داری دروغ می‌گویی. قول دادن به تلاش، یعنی اعتراف به اینکه تا الان کم‌کاری می‌کردی و حالا می‌خواهی انرژی ذخیره‌ات را آزاد کنی. اگر برنامه جدیدی برای حل مشکل نداری، گفتن سعی می‌کنم فقط آماده شدن برای یک شکست قطعی است.
2️⃣ تضاد منافع، سالم و ضروری است: مدیران وظیفه دارند اهداف کسب‌وکار را با شدت دنبال کنند (مثل تحویل سریع‌تر). برنامه‌نویس‌ها هم وظیفه دارند از کیفیت و واقعیت دفاع کنند. اگر مدیرت می‌گوید فیچر X باید تا فردا آماده شود و تو می‌دانی غیرممکن است، تنها جواب حرفه‌ای یک کلمه است: نه.
3️⃣ آدمِ تیمی بودن به معنی بله‌قربان‌گو بودن نیست: آدم تیمی کسی نیست که برای خوشایند بقیه، قول‌های غیرمنطقی بدهد. تیمی بودن یعنی صادقانه و با شجاعت نشان دهی چه چیزی شدنی است و چه چیزی نیست، حتی اگر به قیمت یک جلسه پرتنش تمام شود.
4️⃣ هزینه وحشتناکِ بله گفتن: وقتی از روی ترس یا برای قهرمان‌بازی ددلاین‌های غیرمنطقی را می‌پذیریم، چه اتفاقی می‌افتد؟ تست‌نویسی فراموش می‌شود، معماری نابود می‌شود، کدهای کثیف (Spaghetti Code) متولد می‌شوند و در نهایت هم خودمان فرسوده می‌شویم و هم پروژه شکست می‌خورد.

کسی که نمی‌تواند نه بگوید، نمی‌تواند کد تمیز بنویسد.

فصل دوم، کلین کدر

گوگل Gemini 3.1 Pro را معرفی کرد
مدل هم‌اکنون در حالت پیش‌نمایش از طریق API، Google AI Studio و Vertex AI در دسترس است. در سرویس NotebookLM دسترسی به‌طور انحصاری برای مشترکین طرح‌های Pro و Ultra باز است.

https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-1-pro/

#استخدام

شرکت مبتکر وصال (واقع در محدوده خیابان حافظ تهران) جهت تکمیل تیم فنی خود از برنامهنویسان توانمند .NET دعوت به همکاری مینماید.
🎯 مهارتهای مورد انتظار:
تسلط کامل به C# و .NET
تجربه کار با ASP .NET Core (Web API یا MVC)
آشنایی با SQL Server و طراحی دیتابیس
تسلط نسبی به Git
توانایی کار تیمی و حل مسئله
🌟 مزایا:
محیط کاری حرفهای و دوستانه
فرصت رشد فنی و شغلی
مشارکت در پروژههای واقعی و مقیاسپذیر
📩 ارسال رزومه:
رزومه خود را به ایمیل زیر ارسال کنید:
[email protected]

فصل پیش یاد گرفتیم به ددلاین‌های فضایی و غیرممکن نه بگوییم؛ اما آیا بله گفتن هم مهارت می‌خواهد؟


در ادامه ترجمه کتاب بی‌نظیر The Clean Coder (عمو باب)، رسیدیم به فصل سوم: بله گفتن (Saying Yes). فصلی که نشان می‌دهد

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

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

1️⃣ زبان تعهد (The Language of Commitment): تعهد واقعی ۳ مرحله دارد: بگویی که انجامش می‌دهی، واقعاً منظورت همان باشد، و در نهایت انجامش دهی. یک برنامه‌نویس حرفه‌ای می‌گوید: «من این کار را تا روز سه‌شنبه تمام می‌کنم.» (بدون اما و اگر!)
2️⃣ کلماتِ ممنوعه و غیرحرفه‌ای: واژه‌هایی مثل باید، سعی می‌کنم، امیدوارم یا کاش، نشان‌دهنده نبودِ تعهد هستند. شما را شبیه قربانی شرایط نشان می‌دهند، نه کسی که کنترل اوضاع را در دست دارد.
3️⃣ خط قرمزهای غیرقابل‌مذاکره: وقتی مدیرت می‌پرسد نمی‌شود این فیچر را تا فردا برسانی؟، وسوسه می‌شوی که نوشتن Unit Testها یا ریفکتور کردن (Refactoring) را فدای سرعت کنی. عمو باب می‌گوید این کار خط قرمز یک حرفه‌ای است! پایین آوردن کیفیت کد، شما را سریع‌تر نمی‌کند، بلکه پروژه را به باتلاق می‌کشاند.
4️⃣ بله‌ی خلاقانه (هنر مذاکره): اگر قرار است برای رساندن پروژه اضافه‌کاری کنید، باید حد و مرزتان را بشناسید. یک بله‌ی حرفه‌ای یعنی: من آخر هفته اضافه‌کاری می‌کنم تا فیچر تا دوشنبه آماده شود، اما در عوض سه‌شنبه و چهارشنبه را مرخصی می‌گیرم تا ریکاوری شوم.

پایبندی به حرفی که می‌زنیم، مهم‌ترین برند شخصی ما در دنیای توسعه نرم‌افزار است.

فصل سوم، کلین کدر

تا حالا به کدهایی که ساعت ۳ صبح زدی افتخار کردی؟
اگر جوابت مثبته، عمو باب توی فصل چهارم کتاب The Clean Coder قراره حسابی غافلگیرت کنه!

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

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

خلاصه ۵ قانون طلایی عمو باب برای زمان کدنویسی:

1️⃣ افسانه کد ساعت ۳ صبح: بیدار موندن و کد زدن در حالت خستگی نشانه تعهد نیست، نشانه بی‌انضباطی است! کدی که با ذهن خسته نوشته بشه، پر از باگ و طراحی‌های فاجعه‌بار خواهد بود که ماه‌ها وقت تیم رو برای دور زدنش می‌گیره. وقتی خسته‌ای، کُد نزن!

2️⃣ فرار از ناحیه جریان (The Flow Zone):
خیلی از ما عاشق اون حالت خلسه و تمرکز تونلی موقع کد زدن هستیم (زون). اما عمو باب می‌گه در این حالت، تصویر بزرگ پروژه رو از دست می‌دی و کدهایی می‌زنی که بعداً باید پاک بشن. برنامه‌نویسی دونفره (Pair Programming) بهترین پادزهر برای نیفتادن تو این تله است.

3️⃣ امید، قاتل پروژه‌هاست:
وقتی می‌فهمی به ددلاین نمی‌رسی، به معجزه و اضافه‌کاری امیدوار نباش. یک حرفه‌ای فوراً پرچم قرمز رو بالا می‌بره، واقعیت رو به ذی‌نفعان می‌گه و با کاهش دامنه (Scope) کار رو مدیریت می‌کنه.

4️⃣ توهم تمام شد (False Delivery):
بدترین رفتار غیرحرفه‌ای اینه که بگیم کار تموم شده در حالی که فقط کدش رو نوشتیم و تست نشده. تعریف تمام‌شده (Done) یعنی پاس شدن تمام تست‌های پذیرش خودکار.

5️⃣ دیباگ کردن جزو زمان توسعه نیست، یک خطاست:
زمان دیباگ همون‌قدر برای شرکت هزینه داره که زمان توسعه! یک حرفه‌ای با استفاده از توسعه مبتنی بر تست (TDD) زمان دیباگ رو به سمت صفر میل می‌ده.

فصل چهارم، کلین کدر