این کانال رو زدم صرفا جهت اشتراک دانشی که از مطالعاتم بدست میارم
سپاس گزارم از همراهی شما🌱

من یه مقاله به تازگی نوشتم در خصوص چرایی وجود یک سری primitives keyword ها در سی شارپ و چجوری اینا میتونن به توسعه و کاهش latency سیستم به ما کمک کنند با مثال واقعی:
https://mhmdnzr.drl.ink/post/concurrent-file-uploader

پارسال رفته بودم مصاحبه Asan Pardakht برای نیروی دات نت
یک سوالی اونجا ازم کرد که خیلی برام جالب بود، پرسید فرق بین for vs foreach تووی سی شارپ چیه؟
خب این یه سوال به ظاهر خیلی سادست اما وقتی ترکیب میشه با دیتابیس و فچ دیتا میبینی انگار چوب جادوی هری پاترو انگار پیدا کردی
تووی این بلاگ سعی کردم در مورد این موضوع بییشتر صحبت کنم که چیشد اینجوری شد!
پ.ن: البته اینم بگم که من قبول نشدم تووی مصاحبه اما هربار که من fail میشم خلاهای بیشتری رو در خودم کشف میکنم و به ظرف دانش یک قسمت دیگه اضافه میکنم تا بهتر از دیروز بشم
#csharp #dotnet #software #architecture #pattern #learning

https://mhmdnzr.drl.ink/post/for-vs-foreach

یک هفته هم نگذشته از خبر واترمارک claude که ایشون دست به کار شدن و رنده کردنش
https://github.com/guillaumemeyer/watermarks-remover

دارم روی یه سری پست کار می‌کنم که موضوعش دور و بر همون چیزیه که این روزها خیلی درگیرشم: latency، consistency، و اون لحظه‌هایی که سیستم یه چیزی رو "فکر می‌کنه" داره درست انجام می‌ده ولی در واقع نداره. این پست از دل یه بحث واقعی دراومد — یه سناریوی ساده که همه‌مون یه جایی باهاش برخورد کردیم ولی خیلی‌ها (منم قبلاً) دقیق بهش فکر نکردیم که چرا واقعاً خطرناکه.

بذارید مستقیم بریم سراغ صحنه‌ی جرم.
https://mhmdnzr.drl.ink/post/distributed-lock

فراتر از Npgsql: راهنمای کامل PgBouncer، Pgpool-II، Odyssey و پروکسی‌های ابری Postgres برای اپلیکیشن‌های C#
https://mhmdnzr.drl.ink/post/npgsql-pgbouncer-pgpool-ii-odyssey-postgres-c

یه جایی توی پروژه‌مون به خودمون گفتیم:

«بابا Notification که دیگه این همه داستان نداره! یه API می‌زنیم، پیامو می‌فرستیم، تموم.»

و واقعاً هم همین کارو می‌شه کرد.

ساده‌ست، سریع پیاده می‌شه، Infrastructure خاصی نمی‌خواد و تا وقتی همه‌چی خوب پیش میره، خیلی هم قشنگه :)

ولی مشکل از جایی شروع می‌شه که همه‌چی خوب پیش نمی‌ره!

مثلاً:

پیام توی DB ذخیره شده، ولی سرویس قبل از Publish کردن به RabbitMQ می‌میره.

تبریک می‌گم!

پیام داری ولی Event نداری :)

یا OTP و Campaign رو ریختی توی یه Queue و یهو چند هزار تا پیام Campaign اومده.

حالا کاربر منتظر OTPـه و Queue داره با خودش حال می‌کنه!

اینجاست که داستان کم‌کم تبدیل می‌شه به یه فاجعه کوچیکِ قابل مدیریت و باید بری سراغ چیزهایی مثل:

Outbox

Retry

Idempotency

Queue Isolation

Hangfire

Critical Workers

و کلی چیز دیگه.

البته اینجا هم فکر نکنی همه‌چی حل شد!

هر راه‌حل جدید خودش یه عالمه پیچیدگی، Monitoring، Failure Mode و در نهایت یه مقدار بگ....یی!! جدید با خودش میاره :))

توی NotificationHub دقیقاً سعی کردم همین مسیر رو بررسی کنم:

هر تصمیم معماری چه مشکلی رو حل می‌کنه؟

چه مزیتی داره؟

چه هزینه‌ای ایجاد می‌کنه؟

و مهم‌تر از همه، کِی اصلاً نباید ازش استفاده کنیم؟

اگه با Backend و Distributed Systems سروکله می‌زنی، احتمالاً این داستان برات آشناست.

اینجا فقط یه بخش کوچیکشو گفتم.

اگه کنجکاو شدی ببینی آخرش این فاجعه رو چطوری جمع کردیم، بنظرم ارزش وقت گذاشتن و خوندن رو داره:

🔗 https://mhmdnzr.drl.ink/post/5086561b

#SoftwareArchitecture #Backend #DotNet #DistributedSystems #SystemDesign

این جمله درسته که همیشه دیتای حجیم باعث مرگ سیستم میشه؟ یا یک hot path در لایه infra SQL باعث میشه به ددلاک بخوریم؟
چجوری میشه حلش کرد؟ صرفا چندتا راه همیشگی AsNoTracking, AsSplitQuery, projection, N+1 problem و... یا استفاده از compiled query مارو از این منجلاب بیرون میکشه؟
یا شاید در زبان سی شارپ و ویژگی هاش باید دیپ تر بشیم؟
خب بنظرم گزاره دوم درسته، ما فهم ناقصی از سیستم کارکرد سی شارپ داشتیم
تووی این مقاله سعی کردم راه حلمو با for vs foreach ترکیب کنم و بهتون ارائه بدم.
میتونین از طریق لینک زیر مطالعه کنید:

https://mhmdnzr.drl.ink/post/d0040081

ما اکثرا از FirstOrDefault استفاده کردیم تا بخوایم بر اساس کلید یا یک ستون بریم داخل دیتا بیس پیدا کنیم، اما بقیش چی؟ کلا پنج تابع اصلی داریم برای پیدا کردن. اونا چیکار میکنن؟ تبدیل به چه کوئری میشه در نهایت؟
همه و همه در این مقاله جا شدن:
تفاوت در پیدا کردن است!

https://mhmdnzr.drl.ink/post/4ff4fb50

چرا وقتی میخوایم بدونیم یه آیتم توی دیتابیس یا یک persistent store هست یا نه، باید از Any استفاده کنیم نه Count() > 0؟

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

روی یک IQueryable (مثلاً EF Core):

users.Any(u => u.Id == id)
users.Count(u => u.Id == id) > 0

اولی به EXISTS یا SELECT TOP(1) ترجمه میشه؛ دیتابیس همین که یه ردیف مچ پیدا کنه متوقف میشه.
دومی به COUNT(*) ترجمه میشه؛ دیتابیس مجبوره (بسته به index) همهٔ ردیف‌های مچ رو بشمره، حتی اگه فقط بخوای بدونی حداقل یکی هست.

روی دیتاست بزرگ این فرق فقط تئوری نیست؛ رو query plan، I/O، و latency واقعاً اثر میذاره.

توی حافظهٔ خود برنامه (نه دیتابیس) هم یه داستان مشابه با جزئیات متفاوت هست: enumerator، closure allocation، و اینکه چرا struct بودن Enumerator باعث میشه فرق اصلی سر heap نباشه، سر تعداد iteration باشه.

کل تحلیلش رو با کد، جدول پیچیدگی زمانی، و رسم Stack/Heap توی این پست نوشتم:
[لینک مقاله]

فایل README این پروژه خودش گویای همه‌چیز است. با الهام از الگوریتم topological sort و ساختار DAG که در جلد اول کتاب The Art of Computer Programming (فصل ۲، بخش 2.2.3، Linked Allocation) مطالعه کردم، این router را توسعه دادم. کاربردهای آن می‌تواند بسیار متنوع باشد. توجه شما را به بخش benchmark آن جلب می‌کنم.
https://github.com/0x-mhmdnzri/TheRouter

برای بچه های فرانت
بنظرم تمیز و خوبه

https://farsiui.ir/

یک سری سرویس های رایگان

https://github.com/public-apis/public-apis

یه مدت خیلی شدید با AI Agent ها مخالف بودم و استفاده‌شون نمی‌کردم.
ولی از وقتی تو کارآفرین کار می‌کنم، شرایط کارم عوض شد و رفته رفته ما رو بردن سمت این دستیار جدید.
تو این مدت یه چیز یاد گرفتم که تو یه جمله جمع میشه: هوش مصنوعی دقیقاً اندازه‌ی خودِ تو می‌فهمه! اگه آدرس درست بهش ندی، دیتای غلط می‌گیری، توکن بیشتری می‌سوزونی و آخرش کد کثیف تحویل می‌گیری. اینجاست که تفاوت vibe coder و برنامه‌نویس معلوم میشه.

تو وبلاگ نوشتم: چرا به نظرم مهارت اصلی ما از «کد زدن» رفته سمت تحلیل و project management چطور قبل از دادن کار به AI، ERD و User Story و ADR آماده کنیم اهمیت TODO comment رابطه‌ی توکن‌سوزی با کیفیت پروژه اگه با AI کد می‌زنی، نظرتو بنویس.

https://mhmdnzr.drl.ink/post/aef41873

این ترد از @RezoCv رو ریپست می‌کنم چون یه سؤاله که خیلی‌ها تو جست‌وجوی کار باهاش روبه‌رو می‌شن ولی کمتر درباره‌ش حرف می‌زنن: وقتی ریکروتر درباره‌ی گپ تو رزومه پرسید، چی بگیم؟
اول بذارید بگم چی نگیم. جمله‌هایی مثل «داستانش طولانیه»، «فقط داشتم استراحت می‌کردم» یا «چیزی پیدا نکردم» تقریباً همیشه حس بدی منتقل می‌کنن. جواب خوب سه تا ویژگی داره: کوتاه، صادقانه، و رو به جلو. مثلاً:
«سال ۲۰۲۵ یه وقفه‌ی برنامه‌ریزی‌شده داشتم تا از یکی از اعضای خانواده مراقبت کنم. تو این مدت با [مهارت] از طریق [دوره/پروژه] به‌روز موندم. اون فصل تموم شده و آماده‌م کامل روی یه نقش مثل این تمرکز کنم.»
چرا این جواب کار می‌کنه؟ چون دلیل رو تو یه جمله می‌گی و توضیح اضافه نمی‌دی، نشون می‌دی که فعال مونده‌ی، و حرف رو از گپ به شغل می‌رسونی. نکته‌ی اصلی هم همینه: ریکروتر معمولاً خودِ گپ رو قضاوت نمی‌کنه، طرز حرف زدنت درباره‌ش رو قضاوت می‌کنه.
یه چیز دیگه هم هست: گپ رو تو خودِ رزومه هم یه خط بنویس که غافلگیرکننده نباشه. گپی که توضیح داده شده فقط یه خطه، ولی گپ ساکت یه علامت سؤاله.
چند تا کار هم هست که بهتره نکنی: تاریخ شغل‌های قبلی رو نکشی که گپ پنهان بشه، چند بار عذرخواهی نکنی، از جزئیاتی که راحت نیستی نگی، و کارفرمای قبلی رو مقصر ندونی. تو مدیون هیچ‌کس نیستی که کل داستان زندگیت رو تعریف کنی؛ یه خلاصه‌ی واضح و صادقانه کافیه.
آخرش هم، جواب دوجمله‌ایت رو قبل از مصاحبه با صدای بلند تمرین کن. هدف اینه که طبیعی به نظر برسه، نه حفظ‌شده.
اگه می‌خوای یه خط وقفه‌ی شغلی تمیز به رزومه‌ت اضافه کنی، می‌تونی از RezoCV استفاده کنی: https://rezocv.com/?src=x
#Career #Hiring #Resume #JobSearch