یکی از تصمیم‌های کلیدی در کار با زمان در ‎.NET، انتخاب بین DateTimeOffset.Now و DateTimeOffset.UtcNow هست. یک انتخاب اشتباه اینجا می‌تونه باعث باگ‌های پیچیده‌ای بشه که فقط در Time Zone های خاصی خودشون رو نشون میدن.

خلاصه تفاوت این دو:
DateTimeOffset.Now
زمان محلی سیستمی که کد روش اجرا میشه رو برمی‌گردونه. این مقدار کاملاً به Time Zone سرور یا کامپیوتر کاربر وابسته است.

DateTimeOffset.UtcNow
زمان جهانی (UTC) رو با Offset صفر (+00:00) برمی‌گردونه. این مقدار هیچ وابستگی به تنظیمات محلی نداره و برای همه در یک لحظه، یکسان و ثابته.

اصل کلی اینه: "با UTC ذخیره کن، با زمان محلی نمایش بده."
همیشه برای ثبت زمان در دیتابیس، لاگ‌ها یا هر نوع Storage دیگه‌ای، از DateTimeOffset.UtcNow استفاده کنید. این کار یک (Source of Truth) بدون ابهام و قابل مقایسه ایجاد می‌کنه.
نمایش زمان به کاربر نهایی باید در لایه UI و بر اساس Time Zone خود کاربر انجام بشه.
این رویکرد ساده، جلوی بسیاری از مشکلات در سیستم‌های توزیع‌شده (Distributed Systems) رو می‌گیره.

کارآموزی بریم یا نه؟

#ویدئو_کدنویس
🔗 YouTube

فصل چهارم - الگوهای کارآموزی

ارزیابی دقیق خود

خطرناک‌ترین جایگاه برای یک برنامه‌نویس، جایی است که احساس کند بهترین است. ماهی بزرگ در برکه‌ی کوچک بودن، شاید حس غرور بدهد، اما در حقیقت پایانِ رشد توست.

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

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

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

یادگیری واقعی هم پشت میز و در انزوا اتفاق نمی‌افتد؛ بلکه در ساییدن آرنج‌ها (Rubbing Elbows) رخ می‌دهد. باید کنار یک حرفه‌ای بنشینی، کد زدنش را ببینی، و ریزه‌کاری‌هایی را یاد بگیری که در هیچ کتابی نوشته نشده است. دانشی که فقط در عمل و هم‌نشینی منتقل می‌شود.

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

این فصل یک هشدار جدی است:
اگر در کارت احساس راحتی می‌کنی، اگر کسی نیست که تو را به چالش بکشد، و اگر فکر می‌کنی همه چیز را بلدی، احتمالاً متوقف شده‌ای.

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

همیشه تیمی را پیدا کن که در آن بتوانی دوباره شاگرد باشی.

معیار واقعی کیفیت نرم‌افزار: WTF در ساعت

روش های زیادی برای سنجیدن کیفیت نرمافزار وجود داره — از code coverage تا پیچیدگی و ابزارهای مختلف تحلیل.
اما یک معیار ساده همیشه دقیقتر از بقیه بوده:

WTF/H — «چند بار در ساعت میگی این دیگه چی بود؟»

یعنی چند بار وسط خوندن کد مکث میکنی و با خودت میگی «چی شد؟!»

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

WTF/H پایین:
ساختار مشخص، نام‌گذاری درست، رفتار قابل پیش‌بینی و تست‌های قابل اعتماد.
اینجا میتونی راحت فکر کنی و مشکل حل کنی.

WTF/H متوسط:
کد کار میکنه، اما فهمیدنش زمان میبره.
ترکیبی از تصمیم‌های قدیمی و میان‌برهای که هنوز موندن.

WTF/H بالا:
فانکشن‌های طولانی، منطق نامشخص، تغییرات پرریسک.
هر تغییری میتونه مشکل درست کنه.


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

هرچه WTF/H کمتر باشه، توسعه سریع‌تر و تیم خوشحال تر.

🔗 LinkedIn

#استخدام
استخدام برنامه نویس Dotnet (دورکار)

با سلام، وقت بخیر

برای توسعه نیرو های پروژه نیاز به دو همکار Backend داریم که Mid-Level یا Senior باشند.

تسط به موارد زیر اجباری می باشد :

1. Dotnet 9-10
2. T-SQL
3. EFCore 9-10
4. ASP .NET Core Web API
5. AzureDevops (Git)
6. DDD (Domain Driven Design)
7. Onion or Clean Architecture
8. SSMS
9. RabbitMQ یا Kafka

تسط به موارد زیر دارای امتیاز مثبت خواهد بود :
1. تجربه کار پروژه ای با معماری Microservices
2. تجربه کار با APIGateway Ocelot
3. تجربه کار با Docker file
4. تجربه کار با Pipeline های Azuredevops

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

لطفا دوستان عزیز حقوق درخواستی مورد نظر برای سال 1404 رو ذکر کنند در ایمیل، که من به همکاران HR اعلام کنم.

ارسال رزومه :
ali.poustdouzan@gmail.com
LinkedIn

فصل پنجم - الگوهای کارآموزی

یادگیری همیشگی

توسعه‌ی نرم‌افزار تولید محصول نیست؛ بلکه فعالیتِ کسبِ دانش است.

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

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

برای اینکه در مسیر استادی بمانید، باید این الگوها را زندگی کنید:

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

۲. اسباب‌بازی‌های شکستنی (Breakable Toys):
لینوس توروالدز لینوکس را نساخت چون می‌خواست دنیا را تغییر دهد؛ آن را ساخت چون فقط یک سرگرمی بود.
شما هم باید پروژه‌هایی داشته باشید که فقط مال خودتان باشد. یک ویکی شخصی بسازید، یک بازی بنویسید، یا یک سیستم‌عامل ساده و ناقص طراحی کنید. این‌ها اسباب‌بازی‌هایی هستند که اجازه دارید آن‌ها را بشکنید، خراب کنید و از دلِ خرابی‌هایشان معماری واقعی را یاد بگیرید.

۳. استفاده از کد منبع (Use the Source):
فقط کتاب نخوانید؛ کد بخوانید. بیل گیتس می‌گفت سطل زباله‌های مرکز کامپیوتر را می‌گشت تا کدهای سیستم‌عامل دیگران را پیدا کند و بخواند. کد، داور نهایی است. خواندنِ کدهای متن‌بازِ خوب، به شما یاد می‌دهد که بزرگان این صنعت چگونه فکر می‌کنند.

۴. یادگیری را ثبت کن و به اشتراک بگذار:
وبلاگ بنویس، نه برای اینکه مشهور شوی، بلکه برای اینکه وقتی می‌نویسی، مجبور می‌شوی عمیق‌تر فکر کنی. وقتی یکی درس می‌دهد، دو نفر یاد می‌گیرند.

این فصل یک هشدار بزرگ دارد:
تجربه با تکرار فرق دارد.
بسیاری از برنامه‌نویسان ۱۰ سال تجربه ندارند؛ آن‌ها ۱ سال تجربه دارند که ۱۰ بار تکرار شده است.
یادگیری همیشگی یعنی هر روز به دنبال راهی باشی تا نادانی‌ات را به مهارت تبدیل کنی، حتی اگر این فرآیند دردناک باشد. چون دردِ یادگیری، تنها نشانه‌ی رشد است.

برنامه‌نویسی دات‌نت بدون این اصطلاحات، مثل رانندگی بدون ترمز و کلاچه! 🚗
این ۲۰ مفهوم حیاتی دات‌نت به زبان ساده و خودمونی:

🏗 زیرساخت (Engine Room)

۱. CLR:
قلب تپنده دات‌نت! مدیریت اجرا، حافظه و امنیت با ایشونه. بدون CLR کدت اجرا نمیشه.

۲. IL:
کد سی‌شارپ اول به زبان میانی (IL) تبدیل میشه، نه مستقیم به زبان ماشین.

۳. JIT:
مترجم لحظه آخر! موقع اجرا، کد IL رو به زبان ماشین تبدیل می‌کنه تا سرعت بره بالا.

۴. GC:
رفتگر حافظه! اتوماتیک آبجکت‌های بلااستفاده رو از رم پاک می‌کنه.

۵. Roslyn:
کامپایلر مدرن دات‌نت. همزمان با تایپ، کد رو تحلیل می‌کنه (مثل خط قرمزهای ویژوال استودیو).

🌐 وب و ASP .NET Core

۶. Kestrel:
وب‌سرور سبک، سریع و کراس‌پلتفرم که پیش‌فرض ASP .NET Core هست.

۷. Middleware:
ایستگاه بازرسی درخواست‌ها. هر Request از این لایه‌ها (مثل لاگین) رد میشه تا به Response برسه.

۸. DI:
تزریق وابستگی؛ بجای new کردن، آبجکت رو از سیستم می‌گیری. قلب معماری ASP .NET Core.

۹. Razor:
موتور ترکیب سی‌شارپ با HTML برای ساخت صفحات وب پویا (مثل cshtml.).

۱۰. Blazor:
جادوی مایکروسافت! نوشتن فرانت‌اند با سی شارپ (جای React) که توی مرورگر اجرا میشه.

🛠 ابزارها

۱۱. NuGet:
پکیج منیجر دات‌نت. معدن هزاران کتابخونه آماده تا چرخ رو دوباره اختراع نکنی.

۱۲. LINQ:
سینتکس جادویی برای فیلتر و جستجو در لیست‌ها و دیتابیس با کدی تمیز.

۱۳. EF Core:
رابط دیتابیس (ORM). بجای SQL، با کلاس‌های سی شارپ کار می‌کنی؛ تبدیل به کوئری با خودشه.

۱۴. Async/Await:
کلید سرعت! وقتی برنامه منتظر I/O هست، قفل نمیشه و کارهای دیگه رو انجام میده.

۱۵. SDK vs Runtime:
اولی جعبه‌ابزار برای ساخته، دومی موتور اجرا برای سرور مشتری.

🎯 پیشرفته

۱۶. TFM:
شناسه نسخه دات‌نت پروژه. مثلاً net8.0.

۱۷. LTS:
نسخه‌های با پشتیبانی طولانی ۳ سال آپدیت؛ مثل .NET 8.

۱۸. Poco:
کلاس‌های ساده (فقط پراپرتی) بدون وابستگی خاص.

۱۹. Scaffolding:
ساخت اتوماتیک کنترلر و ویو بر اساس مدل‌ها برای افزایش سرعت.

۲۰. Minimal API:
نوشتن API بدون کنترلر و پیچیدگی. فقط کد اصلی و تمام!

۲۰ اصطلاح دات‌نت که شما را از سطح جونیور به مید-لول میرساند!
(قسمت دوم)
اگر لیست قبلی الفبا بود، این لیست گرامر دات‌نت حساب میشه. بریم سراغش:

🧠 مفاهیم عمیق‌تر (Deep Dive)
۱. Stack vs Heap:
دو ناحیه حافظه. Stack برای متغیرهای کوچیک و سریعه (مثل int)، Heap برای آبجکت‌های بزرگ و موندگار. تفاوتش رو ندونی، مموری لیک (Memory Leak) در کمینته!

۲. Generics:
جادوی <T>! بهت اجازه میده کدی بنویسی که با هر نوع دادهای کار کنه، بدون اینکه برای هر کدوم جداگانه کد بزنی.

۳. Delegate & Event:
سیستم خبررسانی دات‌نت. Delegate اشاره‌گر به یک متده، و Event یعنی وقتی اتفاقی افتاد (مثل کلیک)، به بقیه خبر بده.

۴. Lambda Expression:
اون فلش معروف =>. روشی مختصر برای نوشتن توابع بینام و جمعوجور توی یک خط.

۵. Reflection:
قابلیت "خودآگاهی" کد! برنامه‌ای که میتونه در زمان اجرا، کلاس‌ها و متدهای خودش رو ببینه و دستکاری کنه (البته با احتیاط مصرف شود!).

🏗️ معماری و الگوها (Architecture)

۶. DTO (Data Transfer Object):
پیک موتوریِ داده‌ها! اشیایی که فقط برای جابجایی داده بین لایه ها ساخته شدن و هیچ منطق یا لاجیکی ندارن.

۷. Repository Pattern:
انباردارِ پروژه. لایه ای که بین کد شما و دیتابیس قرار میگیره تا مستقیم با دیتابیس درگیر نشید.

۸. CQRS:
قانون "تفکیک قوا". یعنی مسیر خوندن اطلاعات (Query) رو از مسیر نوشتن و تغییر اطلاعات (Command) جدا کنی تا سیستم تمیزتر بشه.

۹. Microservices:
شکستن غولِ نرم‌افزار به سرویس‌های کوچیک و مستقل که هر کدوم کار خودشون رو میکنن و با هم حرف میزنن.

۱۰. Solid Principles:
۵ قانون مقدس در طراحی شی گرا که اگر رعایت نکنی، کدت بعد از ۶ ماه غیرقابل نگهداری میشه!

🌐 وب مدرن و ارتباطات
۱۱. SignalR:
کتابخونه ای برای ارتباط Real-time (در لحظه). جون میده برای ساخت چتروم، داشبوردهای زنده و نوتیفیکیشن.

۱۲. gRPC:
جایگزین مدرن و فوق سریع برای REST API. گوگل ساختش و توی دات‌نت برای ارتباط بین میکروسرویس ها عالیه.

۱۳. JWT (JSON Web Token):
کارت ورود دیجیتال. روشی امن و استاندارد برای احراز هویت (Authentication) در APIها.

۱۴. Swagger / OpenAPI:
مستندات زنده! ابزاری که APIهای شما رو اسکن میکنه و یک صفحه شیک میسازه تا بقیه بتونن راحت تستش کنن.

۱۵. CORS:
نگهبان مرورگر. قانونی که تعیین میکنه آیا سایت A اجازه داره به منابع سایت B دسترسی داشته باشه یا نه.

⚡ تکنیک‌های حرفه‌ای (Pro Features)

۱۶. Records:
نوع داده جدید (C# 9.0+) که مخصوص نگهداری دادههای ثابته (Immutable). امنتر و خلاصه‌تر از Class معمولی.

۱۷. Span:
مدیریت حافظه بدون کپی کردن! برای کار با متنها و آرایه های بزرگ، سرعت رو فضایی بالا میبره.

۱۸. Extension Methods:
روشی برای چسبوندن متدهای جدید به کلاس های قدیمی (حتی کلاس های خود دات‌نت مثل String) بدون دستکاری اونها.

۱۹. Hot Reload:
قابلیت جذاب ویژوال استودیو که میذاره وقتی برنامه در حال اجراست، کد رو عوض کنی و نتیجه رو همون لحظه ببینی.

۲۰. AOT (Ahead-of-Time):
کامپایل پیش از موعد. برنامه رو مستقیم به کد ماشین تبدیل میکنه تا بدون نیاز به JIT، توی کسری از ثانیه اجرا بشه.

کدوم یکی از اینا اخیراً بیشتر به کارتون اومده؟ 😎

فصل ششم - الگوهای کارآموزی

ساخت برنامه درسی خود

ما دیگر برای نمره درس نمی‌خوانیم. ما یاد می‌گیریم چون این تنها راه بقا در این اقیانوس بی‌انتهای تکنولوژی است.

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

برای اینکه در این سیلاب غرق نشوید، باید برنامه‌ی درسیِ شخصی خود را بسازید:

۱. فهرست کتاب‌ها (The Reading List):
کتاب‌هایی که باید بخوانید همیشه بیشتر از زمان شماست. یک صف اولویت‌دار درست کنید. نکته کلیدی اینجاست: کتاب درست را باید در زمان درست خواند. خواندن Design Patterns وقتی هنوز اصول اولیه را نمی‌دانید، فقط گیج‌تان می‌کند. از مربیان بپرسید: الان چه چیزی برای من حیاتی است؟

۲. دائماً مطالعه کنید (Read Constantly):
تسلط بر زبان اول کافی نیست. دیو هوور (نویسنده کتاب) هر روز ۹۰ دقیقه در قطار مطالعه می‌کرد. شما باید همیشه یک کتاب در دست داشته باشید تا زمان‌های مرده را زنده کنید.

۳. مطالعه کلاسیک‌ها (Study the Classics):
تکنولوژی‌ها می‌آیند و می‌روند، اما اصول می‌مانند. به جای اینکه فقط دنبال جدیدترین فریم‌ورک جاوااسکریپت باشید، کتاب‌های قدیمی و کلاسیک مثل The Pragmatic Programmer یا The Mythical Man-Month را بخوانید. اگر دیدید کتابی متعلق به ۳۰ سال پیش است اما هنوز حرف‌هایش تازه است، بدانید گنج پیدا کرده‌اید.

۴. عمیق‌تر کاوش کنید (Dig Deeper):
سطحی‌نگری آفت برنامه‌نویسان مدرن است. ما یاد می‌گیریم چطور با یک ابزار کار کنیم، اما نمی‌دانیم چرا کار می‌کند.
فرق بین یک کدنویس معمولی و یک مهندس نرم‌افزار در همین عمق است. کسی که RFC پروتکل HTTP را می‌خواند، درکی از وب دارد که کسی که فقط داکیومنت React را خوانده، هرگز نخواهد داشت. به زیرِ پوستِ ابزارها بروید.

۵. ابزارهای آشنا (Familiar Tools):
در میانه‌ی یادگیری چیزهای جدید، باید جعبه‌ابزاری داشته باشید که چشم‌بسته با آن کار کنید. این‌ها ابزارهایی هستند که بهره‌وری شما را تضمین می‌کنند و به شما اعتمادبه‌نفس می‌دهند تا در پروژه‌های پرریسک، روی چیزی محکم بایستید.

جمع‌بندی:
شما دیگر دانش‌آموز نیستید؛ شما معمارِ ذهنِ خودتان هستید.
برنامه درسی خود را بسازید، منابع اصلی را بخوانید، و هرگز اجازه ندهید جریان تند تکنولوژی، شما را به یک مصرف‌کننده‌ی سطحی تبدیل کند.

آیا هوش مصنوعی می‌تواند برنامه‌ریزی بلندمدت بکند؟

#ویدئو_کدنویس
🔗 YouTube

یک جعبه‌ ابزار کاربردی برای توسعه‌ دهندگان دات‌ نت

استفاده از کتابخانه‌های استاندارد و تست‌ شده، کارهای تکراری و پیچیده را ساده می‌کند تا تمرکز اصلی روی منطق (Business Logic) برنامه باشد.
این ۱۰ کتابخانه (Nuget Package) از پرکاربردترین و محبوب‌ترین ابزارها در اکوسیستم دات‌نت هستند:

۱. Newtonsoft.Json (Json.NET)
هنوز هم یکی از قدرتمندترین و منعطف‌ترین کتابخانه‌ها برای کار با JSON محسوب می‌شود، حتی با وجود کتابخانه داخلی مایکروسافت.

۲. Serilog
جایگزینی مدرن برای لاگ‌برداری سنتی. این کتابخانه امکان ثبت لاگ‌های "ساختاریافته" (Structured) را فراهم می‌کند که جستجو و تحلیل داده‌ها را بسیار ساده‌تر می‌سازد.

۳. AutoMapper
ابزاری برای حذف کدهای تکراری هنگام تبدیل مدل‌ها به یکدیگر (مانند تبدیل Entity به DTO). با یک بار تنظیم، عملیات مپینگ به صورت خودکار انجام می‌شود.

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

۵. Polly
یک کتابخانه حیاتی برای مدیریت خطاها و پایداری سیستم. پیاده‌سازی الگوهایی مثل Retry (تلاش مجدد)، Circuit Breaker و Timeout با این ابزار بسیار ساده است.

۶. Hangfire
راهکاری جامع برای مدیریت کارهای پس‌زمینه (Background Jobs). برای زمان‌بندی کارها و اطمینان از اجرای آن‌ها (حتی در صورت ریست شدن سرور) استفاده می‌شود.

۷. Dapper
یک Micro-ORM فوق‌العاده سریع و سبک. گزینه‌ای عالی برای زمانی که نیاز به پرفورمنس بالا و کنترل مستقیم روی کوئری‌های SQL وجود دارد.

۸. FluentAssertions
مخصوص تست‌نویسی. این کتابخانه کمک می‌کند تا کدهای Unit Test با زبانی بسیار نزدیک به زبان انسان نوشته شوند و خوانایی بالایی داشته باشند.

۹. Swashbuckle (Swagger)
تولید خودکار مستندات API. با اسکن کدها، یک رابط کاربری تعاملی می‌سازد که فرانت‌اندکارها و تسترها می‌توانند از آن استفاده کنند.

۱۰. BenchmarkDotNet
ابزاری دقیق برای اندازه‌گیری عملکرد کد. برای بهینه‌سازی و مقایسه سرعت اجرای الگوریتم‌های مختلف ضروری است.


جای کدام کتابخانه مهم دیگر در این لیست خالی؟

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

این ۱۰ پکیج (Nuget Package) عصای دست توسعه‌دهندگان حرفه‌ای هستند:

۱. MediatR
قلب تپنده بسیاری از پروژه‌های مدرن (به خصوص Clean Architecture). این کتابخانه پیاده‌سازی الگوی Mediator و CQRS را بسیار ساده می‌کند و باعث کاهش وابستگی بین اجزای سیستم می‌شود.

۲. xUnit
استانداردترین فریم‌ورک برای نوشتن Unit Test در دات‌نت. سبک، مدرن و توسعه‌پذیر است و مایکروسافت هم برای پروژه‌های خودش از آن استفاده می‌کند.

۳. Moq
وقتی تست می‌نویسید، نیاز دارید وابستگی‌ها (مثل دیتابیس) را شبیه‌سازی کنید. Moq محبوب‌ترین ابزار برای ساختن این اشیای مصنوعی (Mock Objects) در تست‌هاست.

۴. Refit
تبدیل اینترفیس‌های C# به HTTP Client! با این کتابخانه دیگر نیازی به نوشتن کدهای تکراری HttpClient ندارید؛ فقط اینترفیس تعریف کنید، Refit بقیه کار را انجام می‌دهد.

۵. MassTransit
اگر سمت میکروسرویس یا رویدادها (Events) می‌روید، این ابزار ضروری است. مدیریت ارتباط با Message Brokerها (مثل RabbitMQ و Kafka) را به شکلی انتزاعی و قدرتمند انجام می‌دهد.

۶. Bogus
داده‌های تستی واقعی نیاز دارید؟ Bogus می‌تواند هزاران رکورد داده جعلی اما منطقی (نام، آدرس، ایمیل و...) برای تست کردن دیتابیس یا UI تولید کند.

۷. StackExchange.Redis
پروژه‌ای نیست که بزرگ شود و به Caching نیاز نداشته باشد. این کتابخانه، کلاینت استاندارد و با پرفورمنس بالا برای کار با Redis در دات‌نت است.

۸. Quartz .NET
یک سیستم زمان‌بندی (Scheduling) بسیار دقیق و قدیمی. اگر نیازهای زمان‌بندی پیچیده‌ای دارید (مثل Cron Jobهای خاص) که فراتر از توانایی Hangfire است، Quartz انتخاب اول است.

۹. OpenTelemetry
استاندارد جدید برای مانیتورینگ و Trace کردن درخواست‌ها در سیستم‌های توزیع شده. به شما نشان می‌دهد یک درخواست دقیقا کجا کند شده یا به خطا خورده است.

۱۰. Humanizer
جزئیات کوچک اما مهم! این کتابخانه داده‌های کامپیوتری را به زبان انسان تبدیل می‌کند. (مثلاً تاریخ 2023-10-01 را به "2 days ago" یا PascalCase را به "Pascal Case" تبدیل می‌کند).

ترجمه فارسی The Pragmatic Programmer

این کتاب فقط درباره نوشتن کد نیست؛ درباره ساختن ذهنیت یک توسعه‌دهنده حرفه‌ایه

مسئولیت‌پذیری، تصمیم‌گیری بهتر، و نوشتن کدی که هم قابل اعتماد باشه هم قابل نگهداری، حتی وقتی پروژه بزرگ و تیم شلوغ می‌شه.
با گذشت سال‌ها هنوز هم یکی از بهترین منابع رشد شغلیه؛ از جونیور تا سنیور.


https://github.com/hheydarian/the-pragmatic-programmer-parsion

فصل هفتم - الگوهای کارآموزی

نتیجه‌گیری (پایان یا آغاز؟)

آیا استادان نرم‌افزار وجود دارند؟ شاید هنوز نه.
اما اگر می‌خواهیم روزی وجود داشته باشند، باید رازی را که استرادیواری با خود به گور برد، کشف کنیم.

ویولن‌های استرادیواری ۳۰۰ سال است که بی‌رقیب مانده‌اند. چرا؟ چون او نتوانست نبوغ خود را فرموله کند و به شاگردانش یاد دهد. با مرگ او، کارگاهش هم مُرد.

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

۱. استادی یعنی انتقال مهارت:
نبوغ شخصی کافی نیست. سِمل‌وایس (پزشکی که فهمید شستن دست‌ها جان مادران را نجات می‌دهد) یک نابغه بود، اما یک نابغه‌ی شکست‌خورده. چون نتوانست دیگران را قانع کند. او دیوانه شد و مُرد، و ۲۰ سال طول کشید تا دنیا حرفش را بفهمد.
استاد نرم‌افزار کسی نیست که کد خارق‌العاده می‌زند؛ کسی است که می‌تواند آن مهارت خارق‌العاده را به دیگران هم یاد بدهد.

۲. خطر توهم مهارت:
بیشتر برنامه‌نویسان فکر می‌کنند بالاتر از میانگین هستند. این اثر "دنینگ-کروگر" است: ما آنقدر نمی‌دانیم که حتی بفهمیم چقدر نمی‌دانیم.
استادی یعنی درک اینکه مقیاس مهارت از ۱ تا ۱۰ نیست؛ از ۱ تا ۱۰۰ است و ما شاید تازه به ۹ رسیده باشیم.

۳. هیچ‌کس خودش را استاد نمی‌نامد:
اگر کسی گفت "من استاد هستم"، به او شک کنید. استادی یک برچسب است که دیگران (آن هم دیگر استادان) باید به تو بدهند.
مدرک واقعی استادی، کیفیت کار شاگردان توست. اگر شاگردانت از تو بهتر شدند، یعنی تو استادی.

۴. هنوز استادان واقعی نداریم:
نویسندگان کتاب صادقانه می‌گویند: ما خودمان هنوز استاد نیستیم. ما مسافریم.
شاید هنوز در تاریخ نرم‌افزار، استادی در تراز میکل‌آنژ یا استرادیواری ظهور نکرده باشد. اما این یک خبر بد نیست؛ این یک دعوت‌نامه است.
شاید نسل بعدی کارآموزان (شما) همان کسانی باشید که می‌گویید:
استادان نرم‌افزار وجود نداشتند... تا اینکه ما آمدیم.

این کتاب تمام شد، اما مسیر The Long Road تازه شروع شده است.

کدنویسی شغل نیست؛ یک مسیر طولانی است

دانشگاه و بوت‌کمپ‌ها به ما سینتکس یاد می‌دهند، اما کسی به ما یاد نمی‌دهد چطور در این اقیانوس بی‌انتها غرق نشویم، چطور رشد کنیم و چطور از یک کدنویس معمولی به یک استاد نرم‌افزار تبدیل شویم.
کتاب Apprenticeship Patterns (الگوهای شاگردی) دقیقاً همان حلقه گمشده است.
این کتاب درباره جاوا یا پایتون نیست؛ درباره تو است. درباره مسیر شغلی‌ات، طرز تفکرت و عادات روزانه‌ای که تفاوت میان یک کارمند خسته و یک مهندس خلاق را رقم می‌زند.
من در هفته‌های گذشته، عصاره‌ی این کتاب ارزشمند را فصل‌ به‌ فصل خلاصه کردم تا راهنمایی باشد برای تمام کسانی که نمی‌خواهند درجا بزنند.
اگر احساس می‌کنید رشدتان متوقف شده، یا اگر تازه اول راه هستید و نقشه راه می‌خواهید، این مجموعه پست‌ها برای شماست.
- دسترسی به خلاصه تمام فصل‌ها

- فصل اول: الگوهای کارآموزی (چرا باید ذهنیت شاگردی داشته باشیم؟)

- فصل دوم: خالی کردن فنجان (چگونه غرور دانایی مانع یادگیری می‌شود؟)

- فصل سوم: پیمودن راه طولانی (چرا نباید عجله کرد و چگونه در مسیر بمانیم؟)

- فصل چهارم: ارزیابی دقیق خود (چرا باید همیشه بدترین عضو تیم باشیم؟)

- فصل پنجم: یادگیری همیشگی (تفاوت کار کردن و تمرین کردن؛ اسباب‌بازی‌های شکستنی)

- فصل ششم: ساخت برنامه درسی خود (چگونه منتظر دیگران نمانیم و مسیر یادگیری خودمان را بسازیم؟)

- فصل هفتم: نتیجه‌گیری (آیا استادان نرم‌افزار وجود دارند؟)

۵ اشتباه رایج در نوشتن رزومه که باعث رد شدن در نقش‌های بین‌المللی می‌شود

اگر دنبال شغل با ویزا اسپانسر شیپ هستید، رزومه تان باید یک سطح بالاتر از معمول باشد.

این ۵ خطا، بیشتر از هر چیز، باعث رد شدن رزومه ها میشود:

❌ ۱) نوشتن وظایف شغلی به جای نتایج
✔️ کارفرما دنبال اثر است، نه فعالیت.
❗ بهجای:
“Worked on Python APIs”
✔️ بنویس:
“Reduced API latency by 34% through refactoring Python microservices.”

❌ ۲) نداشتن مهارت‌های کلیدی همان نقش
سیستم‌های ATS دقیقاً دنبال همان ۵–۸ Skill اصلی هستند.
✔️ مهارت ها باید با Job Denoscription همراستا باشند نه پراکنده.

❌ ۳) جمله‌های طولانی، بدون اعداد
اعداد = واقعیت + تاثیر
✔️ “Improved ETL throughput by 45%”
✔️ “Cut cloud cost by 27%”

❌ ۴) نبود بخش Tech Stack کاربردی
کارفرما باید در ۵ ثانیه متوجه شود با چه ابزارهایی کار کردهاید.
✔️ “Python, FastAPI, Airflow, AWS, Docker, PostgreSQL, BigQuery”

❌ ۵) رزومه ی طولانی بدون ساختار
یک رزومه موفق برای نقشهای بین‌المللی:
دو صفحه
بخش بندی حرفه‌ای
Bullet Points
مثال های عدددار

🔗 LinkedIn

اگر کدهاتون هنوز پر از if و else هست، دارید به سیشارپ مدرن خیانت میکنید! 🔪🩸

بیایید رو راست باشیم؛ نیمی از کدهایی که ما روزانه مینویسیم، فقط چک کردن شرایط هستن.
( عددش مثبته؟ نوعش درسته؟ وضعیتش فعاله؟ Null هست؟)
نتیجه؟ ده‌ها خط کد اسپاگتی با ifهای تو در تو که خوندنش عذاب آوره. 🍝
اما Pattern Matching در نسخههای جدید سی شارپ فقط یک سینتکس قشنگ نیست؛ یک تغییر پارادایم (Paradigm Shift) برای نوشتن کدهای Declarative (توصیفی) به جای Imperative (دستوری) هست.

چرا باید همین امروز استایل کدنویسی تون رو عوض کنید؟
۱. خداحافظی با Cast کردنهای دستی (Type Pattern)
دیگه لازم نیست بنویسید:
if (obj != null && obj is Employee) { var emp = (Employee)obj; ... }

خیلی شیک بنویسید:
if (obj is Employee emp) { ... }

۲. شرط های خوانا مثل زبان انسان (Logical Patterns)
به جای عملگرهای ریاضی گیج کننده، با کامپیوتر حرف بزنید:
❌ if (number > 0 && number < 10)
✅ if (number is > 0 and < 10)

۳. قدرت نمایی در Switch (Switch Expressions)
این قابلیت، قاتلِ case و break های قدیمیه! شما میتونید ۱۰ خط switch قدیمی رو تبدیل کنید به یک خط کد که مستقیماً مقدار برمیگردونه. تمیز، کوتاه و بدون باگ.

۴. جراحی دقیق آبجکت ها (Property Pattern)
میخواید چک کنید که آیا کاربر فعاله و اهل تهرانه؟
if (user is { IsActive: true, City: "Tehran" })
بدون نیاز به نوشتن user.IsActive && user .City == ...

💡 نکته حرفه‌ای:
کد نویسی با Pattern Matching فقط خلاصه‌نویسی نیست؛ بلکه باعث میشه نیت کد شما واضح‌تر بشه. وقتی کد رو میخونید، درگیر چطوری انجام دادن نمیشید، بلکه چی بودن رو میبینید.
❓ صادقانه بگید: چند درصد از کدهای پروژه تون هنوز به سبک C# 5.0 و پر از If/Else نوشته میشه؟

اعتراف کنید! هنوز دارید با as کد مینویسید و منتظر NullReferenceException هستید؟ 💣

بیایید درباره یکی از شایع‌ترین بوهای بد کد (Code Smell) در سی شارپ حرف بزنیم: Type Checking و Casting.
خیلی از ما هنوز به سبک C# 2.0 کد مینویسیم. اما واقعیت اینه که استفاده نادرست از is و as و Castهای مستقیم، مثل مین گذاری توی کدبیس شماست!
👇 بیایید این ۴ روش رو کالبد شکافی کنیم:

۱. روش خطرناک (Direct Cast):
(Employee)obj
این یعنی: من مطمئنم این آبجکت از نوع Employee هست، اگه نبود برنامه رو بترکون! 💥
نتیجه: اگر اشتباه کرده باشید، یک InvalidCastException زیبا در زمان اجرا میگیرید.
✅ کاربرد: فقط و فقط وقتی ۱۰۰٪ مطمئنید.

۲. روش ترسو (The as operator):
var emp = obj as Employee;
این یعنی: سعی کن تبدیلش کنی، اگه نشد، null برگردون.
مشکل اینجاست که خیلی‌ها بعدش یادشون میره چک کنن که نتیجه null شده یا نه! و چند خط پایین‌تر... بوم! NullReferenceException. ❌

۳. روش قدیمی (The old is):
if (obj is Employee) { ... }
امن هست، ولی کُد رو زشت و تکراری میکنه. اول چک میکنی، بعد دوباره داخل if مجبور Cast کنی. چرا کار تکراری؟

🔥 ۴. روش مدرن و حرفه‌ای (Pattern Matching is):
اینجاست که باید سبک کدنویسی تون رو عوض کنید!
از C# 7.0 به بعد، اپراتور is قدرت Pattern Matching پیدا کرده. همزمان هم چک میکنه و هم Cast، بدون خطر:

if (obj is Employee emp)
{
Console.WriteLine($"Hello {emp.Name}");
}

✅ مزایا:
اتمیک: چک و کست در یک حرکت.
امن: متغیر emp فقط داخل بلاک معتبره و نال نیست.
خوانا: خداحافظی با کدهای تکراری.
💡 خلاصه کلام برای مهندسین مدرن:
دور Cast مستقیم (T)x رو خط بکشید (مگر اینکه عاشق Exception هستید).
از as فقط زمانی استفاده کنید که null بودن براتون یک نتیجه معتبره، نه خطا.
برای ۹۹٪ موارد، Pattern Matching بهترین دوست شماست.

❓ شما هنوز کجا از as استفاده میکنید؟ تو کامنت ها بنویسید!

ساخت استارتاپ، خروج موفق و شروع سرمایه گذاری - پارسا غفاری

#ویدئو_کدنویس
🔗 YouTube