Developer Advocate

🧘‍♀️ کتاب Stop Overthinking 🧠 «ذهن آروم = زندگی آروم» اگه ذهنت همیشه درگیر فکراییه که نه تموم می‌شن، نه به دردت می‌خورن، این کتاب دقیقاً برای تو نوشته شده! 📖 Stop Overthinking یه راهنمای عملی و ساده‌فهمه برای روزایی که از فکر زیاد خسته‌ای. نویسنده‌اش با ۲۳ تکنیک کاربردی بهت یاد می‌ده چطور جلوی فکرای منفی، استرس بی‌دلیل، و نشخوار ذهنی رو بگیری و دوباره با خودت آشتی کنی. ✅ چی یاد می‌گیری؟ چطور چرخه فکرای منفی رو متوقف کنی چطور تمرکزتو بیاری روی «الآن» و از گذشته و آینده رها بشی راهکارهای ساده برای کاهش استرس و شلوغی ذهن @DeveloperAdvocate 🥑

📚 کتاب No Rules Rules 🎥 نتفلیکس و فرهنگ بازآفرینی تا حالا فکر کردی چطور یه شرکت مثل نتفلیکس تونسته از یه فروشنده DVD پستی، تبدیل بشه به یکی از غول‌های بی‌رقیب دنیای سرگرمی؟ 📦➡️📺 کتاب «No Rules Rules» به قلم رید هیستینگز (مؤسس نتفلیکس) و ارین میر دقیقاً درباره همین ماجراست. یه سفر واقعی به پشت صحنه نتفلیکس؛ جایی که قانون‌ها کمتر، اعتماد بیشتر و مسئولیت‌پذیری بی‌نهایت بالاست. 🔥 تو این کتاب یاد می‌گیری: چرا نتفلیکس مرخصی نامحدود می‌ده ولی هیچ‌کس سوءاستفاده نمی‌کنه! چطور با حذف کنترل‌ها، نوآوری بیشتر می‌شه نه کمتر چرا صداقت بی‌رحمانه بین کارمندان تبدیل به یک مزیت رقابتی شده اگه دنبال کتابی هستی که هم الهام‌بخشه، هم تجربه واقعی ساخت یه سازمان خلاق رو نشون می‌ده، این کتاب رو از دست نده. مخصوصاً برای مدیرها، فریلنسرها، و کسایی که تیم دارن یا می‌خوان فرهنگ کاری‌شون رو متحول کنن. 🚀

New Article: Introducing Goal-Oriented Software Architecture! Ever feel like your software gets lost in technical details instead of focusing on what your business needs? In my new article, I introduce Goal-Oriented Architecture, a new architectural style developed to address challenges often seen in common approaches like Clean, Onion, Ports and Adapters, and Vertical Slicing architectures. It's a fresh way to build software that puts your real business objectives, your "goals", right at the core. Discover how it makes systems clearer, more effective, and perfectly aligned with your business vision 👇: https://masoudbahrami.com/article/introducing-goal-oriented-software-architecture/

# مهندسی آشوب (Chaos Engineering): طراحی سیستم‌هایی مقاوم از طریق تزریق خطا در دنیای توزیع‌شده‌ی امروز، پیش‌فرض پایدار بودن سرویس‌ها خطرناک است. مهندسی آشوب به شما کمک می‌کند تا نقاط ضعف سیستم‌تان را کشف کنید، پیش از آن‌که حادثه‌ای در تولید رخ دهد. ابزارهایی مانند Chaos Mesh و Gremlin این امکان را می‌دهند که خطاهایی نظیر قطع شبکه، کاهش عملکرد دیسک، یا از کار افتادن سرویس‌ها را شبیه‌سازی کنید. اما چگونه می‌توان یک آزمایش آشوب ساده را مستقیماً در یک اپلیکیشن ASP.NET Core پیاده‌سازی کرد؟ در مثال زیر، یک میدل‌وِر سفارشی را مشاهده می‌کنید که با استفاده از یک Feature Flag ساده، به صورت تصادفی خطای Exception را به زنجیره درخواست اضافه می‌کند. این کار، رفتار سیستم در مواجهه با Exception ناگهانی را ارزیابی می‌کند:

public class ChaosMiddleware
{
    private readonly RequestDelegate _next;
    private readonly Random _random = new();

    public ChaosMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        if (Environment.GetEnvironmentVariable("CHAOS_MODE") == "on" && _random.NextDouble() < 0.2)
        {
            throw new Exception("Chaos Engineering: injected fault.");
        }
        await _next(context);
    }
}

// In Startup.cs or Program.cs:
app.UseMiddleware<ChaosMiddleware>();

این رویکرد را می‌توان به سادگی گسترش داد، مانند شبیه‌سازی تأخیر شبکه یا قطع وابستگی‌های خارجی. اصل کلیدی مهندسی آشوب این است که هر آزمایش باید قابل کنترل، قابل ردیابی و تکرارپذیر (deterministic) باشد تا بتوانید تاثیر هر خطا را به دقت اندازه‌گیری کنید. در اجرای واقعی‌تر، توصیه می‌شود از ابزارهایی مانند Chaos Mesh یا Gremlin برای سناریوهای سطح زیرساخت استفاده کنید. به‌علاوه، همیشه پایش (Observability) قوی (مانند OpenTelemetry) را کنار آزمایش‌های آشوب داشته باشید تا ریشه‌یابی مشکلات به سادگی انجام شود. مطالعه پیشرفته: Chaos Engineering at Netflix - Principles of Chaos Advanced CI/CD & Automation @DeveloperAdvocate 🥑

📊 پایگاه داده ستونی (Columnar Databases): معماری بهینه برای بارهای تحلیلی در معماری سنتی پایگاه‌های داده رابطه‌ای، داده‌ها به صورت سطری ذخیره می‌شوند (row-based). این مدل برای بارهای عملیاتی (OLTP) عالی است اما در سناریوهای تحلیلی (OLAP) هزینه‌ی گزافی دارد؛ به‌خصوص هنگام اجرای جستارهای پیچیده روی ستون‌های خاص با حجم دیتای بزرگ. اما چرا مدل ستونی تحول‌آفرین است؟ در ذخیره‌سازی ستونی، دیتای هر ستون به صورت مجزا و متوالی در دیسک نوشته می‌شود. این رویکرد چند مزیت کلیدی دارد: - افزایش سرعت کوئری‌های تحلیلی: اسکن فقط ستون‌های مورد نیاز بدون نیاز به خواندن کل سطرها. - فشرده‌سازی فوق‌العاده مؤثر: داده‌های هم‌شکل کنار هم قرار می‌گیرند (مثلاً اعداد یا تاریخ‌ها)، که الگوریتم‌های فشرده‌سازی را بسیار کارآمد می‌کند. - پردازش برداری (Vectorized Execution): CPU می‌تواند دسته‌ای از داده‌های مشابه را به صورت موازی پردازش کند. - IO کمتر: مخصوصاً زمانی که فقط تعداد کمی ستون از چندین میلیون ردیف پرس‌وجو می‌شوند، میزان خواندن از دیسک به‌شدت کاهش می‌یابد. 🔬 یک مثال ساده: فرض کنید یک جدول فروش حجیم دارید و فقط نیاز است مجموع فروش سالیانه را برای یک شهر خاص محاسبه کنید. در مدل ستونی، فقط ستون‌های مورد نیاز (City, Amount) اسکن و پردازش می‌شوند:

// فرضی: تحلیل روی ستون‌های جدولی با ذخیره‌سازی ستونی
var result = sales
    .Where(x => x.City == "Tehran")
    .Select(x => x.Amount)
    .Sum();

اگر این جدول روی دیتابیس ستونی مثل Apache Parquet یا MS SQL Server Columnstore Index باشد، فقط دو ستون فوق خوانده و پردازش می‌شوند، نه کل جدول. در دات‌نت می‌توانید از DataFrame در Microsoft.Data.Analysis یا ابزارهایی مانند ClickHouse و Apache Arrow برای بارهای سنگین استفاده کنید. 🚀 در پروژه‌های تحلیلی سنجش‌پذیر (مثلاً گزارش‌گیری‌های BI با حجم بزرگ)، انتخاب معماری ذخیره‌سازی ستونی می‌تواند تا دو مرتبه بهره‌وری را افزایش دهد. مطالعهٔ بیشتر: Columnstore Indexes Guide - Microsoft Docs Advanced Database Concepts @DeveloperAdvocate 🥑

🚀 عمیق‌تر به مفاهیم ایندکسینگ دیتابیس: B-Tree، Hash و Columnstore هر نوع ایندکس، مشخصاً برای ورودی‌های خاصی بهینه شده و معماری دیتابیس‌ را متحول می‌کند: 🟦 B-Tree Indexes: پیش‌فرض اکثر دیتابیس‌ها (SQL Server, PostgreSQL...)، ساختار متعادلی برای جستجو، درج و حذف با پیچیدگی O(logN) مهیا می‌کند. کلیدها به‌صورت مرتب ذخیره می‌شوند؛ اجرای efficient رنج کوئری‌ها (BETWEEN, <, >) و order by را تضمین می‌‌کنند. اگر پراکندگی داده‌ها زیاد باشد (high-cardinality)، تاثیرشان فوق‌العاده است. 🟦 Hash Indexes: ایتدکس‌های هش برای جستجوی equality (=) عالی هستند، اما برای رنج کوئری یا order اصلاً خوب نیستند. عملکرد ثابت O(1) برای پیدا کردن مقدار خاص! داکیومنتیشن SQL Server توضیح می‌دهد که hash indexها در memory-optimized tables و سناریوهای OLTP توصیه می‌شود. 🟦 Columnstore Indexes: برای دیتابیس‌های تحلیلی (OLAP)، Columnstore Indexها داده‌ها را ستون به ستون فشرده و ذخیره می‌کنند. I/O و queries تحلیلی را برای تجمیع‌های سنگین (sum, avg, min/max) به شدت بهبود می‌دهند. مناسب جداول با میلیون‌ها ردیف و حجم پردازش تحلیلی. در .NET، استفاده از BulkInsert با جدول‌های دارای Columnstore Index سرعت ETL را افزایش می‌دهد. 🔎 یک الگوی خوب:‌ - برای OLTP و کوئری‌های معمولی => B-Tree - برای lookup بر اساس مقدار یکتا/مساوی => Hash - برای گزارش‌گیری و آمار با جداول بزرگ => Columnstore مثال تعریف ایندکس‌ها در SQL Server:

-- ایجاد ایندکس B-Tree (ایندکس معمولی)
CREATE INDEX IX_Users_LastName ON Users(LastName);

-- ایجاد ایندکس Hash (فقط روی memory-optimized table)
CREATE HASH INDEX IX_Users_Email ON Users(Email) WITH (BUCKET_COUNT = 100000);

-- ایجاد Clustered Columnstore Index
CREATE CLUSTERED COLUMNSTORE INDEX IX_MeasurementData ON MeasurementData;

در نهایت، انتخاب درست ایندکس و آگاهی از الگوریتم ذخیره‌سازی زیرساخت دیتابیس، مستقیماً بر performance اعمال CRUD و analytical تاثیر می‌گذارد. مطالعه تکمیلی (توصیه‌شده از Microsoft Docs): https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-index-design-guide Advanced Database Concepts @DeveloperAdvocate 🥑

📦 الگوهای طراحی بانک اطلاعاتی: دنرمال‌سازی، ویوهای مادی‌شده و طراحی اسکیمالِس در معماری‌های مقیاس‌پذیر، انتخاب صحیح الگوی طراحی دیتابیس، نرخ پاسخ‌دهی (latency)، پیچیدگی توسعه و حتی هزینه‌های نگهداری را تحت تاثیر قرار می‌دهد. بیایید سه الگوی رایج را دقیق‌تر بررسی کنیم: ۱️⃣ دنرمال‌سازی (Denormalization): گاهی نیاز به عملکرد بالا هنگام کوئری‌های سنگین داریم. دنرمال‌سازی یعنی نقض عمدی قواعد نرمال‌سازی برای کپی داده‌ها در چند جدول تا خواندن دیتا سریع‌تر انجام شود. مثال رایج: ذخیره‌ی UserName مستقیماً کنار دیتای ثبت سفارش، به‌جای جوین زدن زمان اجرا؛ اما یادتان باشد هزینه‌ی همگام‌سازی داده در هنگام تغییر ایجاد می‌شود.

public class Order
{
    public int Id { get; set; }
    public string UserId { get; set; }
    public string UserName { get; set; } // Denormalized field
    public DateTime CreatedAt { get; set; }
    // ...
}

۲️⃣ ویوهای مادی‌شده (Materialized Views): ویوهای مادی‌شده، کوئری‌های پرهزینه را به‌صورت فیزیکی روی دیسک ذخیره می‌کنند، نه اینکه هر بار محاسبه شوند. مناسب برای سناریوهای read-heavy که تازه‌سازی دوره‌ای کافی است. مثلاً خلاصه‌ی روزانه فروش که هر ساعت یک‌بار بروز می‌شود. بعلاوه در SQL Server می‌توانید از Indexed Views استفاده کنید. ۳️⃣ طراحی اسکیمالِس (Schemaless): در مدل‌هایی مانند NoSQL یا EF Core Value Conversion و JSON columns در SQL Server 2016+ می‌توان ساختاری انعطاف‌پذیر و قابل توسعه ایجاد کرد. این الگو مناسب داده‌های پویا یا ویژگی‌هایی است که دائم اضافه/حذف می‌شود، مثلاً متادیتای سفارشی روی هر رکورد:

public class Document
{
    public int Id { get; set; }
    public string Title { get; set; }
    public string JsonMetadata { get; set; } // Schemaless storage (→ JSON)
}

استفاده‌ی درست از این الگوها، نیازمند تحلیل دقیق نیازمندی‌ها و درک عمیق از trade-offهاست. جزئیات بیشتر: https://martinfowler.com/articles/operational-read-model.html Advanced Database Concepts @DeveloperAdvocate 🥑

🎯 ترسیم و پیاده‌سازی ویژن فنی: از ایده تا اکوسیستم تیمی یک ویژن فنی قدرتمند، تنها یک شعار نیست؛ نقشه راهی استراتژیک برای تصمیم‌گیری‌های معماری، تکنولوژی و رشد تیم. اگر می‌خواهید تیم‌تان همراستا توسعه دهد، مراحل زیر را جدی بگیرید: 1️⃣ تدوین تصویر کلان (Big Picture) ویژن باید کوتاه، قابل فهم و الهام‌بخش باشد. به جای «ما می‌خواهیم سریع‌ترین باشیم»، بگویید: «زیرساخت مقاوم و مقیاس‌پذیر بر پایه .NET ۸ برای سرویس real-time با latency زیر ده میلی‌ثانیه می‌سازیم.» 2️⃣ تقطیع تا راهکارهای فنی ویژن را به پرسش‌های Concrete‌ برای معماری، DevOps و توسعه محصول تبدیل کنید: - آیا به CQRS نیاز داریم؟ - دامنه‌های Core/Boundary ما چیست؟ - در زمینه مشاهده‌پذیری (Observability) چه فوریت‌هایی داریم؟ 3️⃣ تدوین Roadmap قابل تأیید هر هدف فنی بایستی با معیارهای success قابل سنجش، مالکیت واضح و وابستگی‌های شفاف وارد بک‌لاگ شود. به جای «بهبود performance»، یک Epic واضح بنویسید: «مهاجرت سیستم auth به dotnet 8 و افزایش throughput به ۲۰۰۰req/s با استفاده از Minimal APIs». 4️⃣ شفاف‌سازی انتظارات و مسیر Drift تداوم alignment کل تیم مسئله است. اگر تیم تصمیمی بر خلاف ریل ویژن گرفت، باید چرایی و هزینه drift را بررسی و مستندسازی کنیم. 5️⃣ ابزارسازی برای هم‌سویی از تکنیک‌هایی مثل Architecture Decision Record استفاده کنید. مستند AD زیر، نمونه‌ای برای تصمیم مهم سرور Gateway آمده است:

// ADR-2024-07: Migrate Gateway to YARP (Yet Another Reverse Proxy)
Context:
We require advanced routing, built-in observability, and future HTTP/3 support.

Decision:
Migrate Gateway from custom middleware to YARP on .NET 8.

Consequences:
+ Improved maintainability and performance metrics availability.
- Some team re-learning required.

6️⃣ بازبینی منظم و Refine ویژن باید زنده باشد؛ با کسب تجربه و نیازهای بیزینسی توسعه یابد. نشست‌های ۶-۸ هفته‌ای برای بازبینی و تنقیح Roadmap فنی برگزار کنید. 🔗 مقاله پیشنهادی برای مطالعه عمیق‌تر: Establishing and Communicating a Technical Vision — Martin Fowler Technical Leadership & Mentoring @DeveloperAdvocate 🥑

پیاده‌سازی Health Check سفارشی برای وابستگی‌های پیچیده گاهی کافی نیست فقط موجود بودن دیتابیس یا یک Service را چک کنیم؛ باید سناریوهایی مثل latency زیاد، وضعیت transactionها یا صحت داده را هم ارزیابی کنیم. Health Checkهای سفارشی در ASP.NET Core دقیقا همین ضعف چک‌های ساده را پوشش می‌دهند. فرض کنید Health یک Redis را نه صرفا با ping بلکه با سنجش توانایی خواندن/نوشتن دیتا و زمان پاسخ اندازه بگیرید:

using Microsoft.Extensions.Diagnostics.HealthChecks;
using StackExchange.Redis;

public class RedisComplexHealthCheck : IHealthCheck
{
    private readonly IConnectionMultiplexer _redis;
    public RedisComplexHealthCheck(IConnectionMultiplexer redis) => _redis = redis;

    public async Task<HealthCheckResult> CheckHealthAsync(
        HealthCheckContext context, CancellationToken cancellationToken = default)
    {
        var db = _redis.GetDatabase();
        var testKey = "healthcheck:test";
        var testValue = Guid.NewGuid().ToString();

        try
        {
            var write = await db.StringSetAsync(testKey, testValue, TimeSpan.FromSeconds(2));
            if (!write) return HealthCheckResult.Unhealthy("Cannot write to Redis.");

            var read = await db.StringGetAsync(testKey);
            if (read != testValue) return HealthCheckResult.Degraded("Read-Write mismatch.");

            var timer = System.Diagnostics.Stopwatch.StartNew();
            await db.PingAsync();
            timer.Stop();

            if (timer.ElapsedMilliseconds > 200)
                return HealthCheckResult.Degraded($"Redis slow response: {timer.ElapsedMilliseconds}ms");

            await db.KeyDeleteAsync(testKey);
            return HealthCheckResult.Healthy("Redis read/write/ping OK.");
        }
        catch (Exception ex)
        {
            return HealthCheckResult.Unhealthy("Redis health check failed.", ex);
        }
    }
}

برای ثبت این Health Check در برنامه:

services.AddHealthChecks()
    .AddCheck<RedisComplexHealthCheck>("redis_complex");

با چنین ابزاری حتی می‌توانید مشکلات ظریف‌تر مثل latency یا در دسترس نبودن feature خاصی را به خوبی مانیتور کنید. این الگو برای سایر سرویس‌های خارجی (مانند Elastic، Kafka، یا APIهای حیاتی) نیز قابل توسعه است. مطلب عمیق‌تر از مستندات مایکروسافت درباره ایجاد health checkهای پیشرفته را اینجا بخوانید: https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/health-checks?view=aspnetcore-8.0#custom-health-checks ASP.NET Core (Advanced) @DeveloperAdvocate 🥑

🔹 مایکروسافت در این مقاله به نقش هوش مصنوعی و GitHub Copilot در تسریع و بهبود فرآیند مهاجرت از Exchange Web Services (EWS) پرداخته است. با توجه به اینکه بسیاری از سازمان‌ها با چالش‌هایی همچون پیچیدگی کدها و نیاز به بازنویسی سرویس‌ها برای مهاجرت به APIهای مدرن مایکروسافت 365 مواجه‌اند، ابزارهای هوشمندی مثل Copilot می‌توانند کمک بزرگی باشند. 🔹 GitHub Copilot با استفاده از فناوری هوش مصنوعی به توسعه‌دهندگان امکان می‌دهد تا با سرعت بیشتری کدهای مهاجرت بنویسند، خطاها را کاهش دهند و راه‌حل‌های بهینه‌تری تولید کنند. این ابزار می‌تواند خطوط بعدی کد را پیش‌بینی کرده و پیشنهاداتی متناسب با پروژه ارائه کند که این کار موجب صرفه‌جویی در زمان و انرژی تیم‌ها می‌شود. 🔹 در این مقاله مراحل مختلف مهاجرت به طور گام‌به‌گام توضیح داده شده و مثال‌هایی واقعی از نحوه استفاده از Copilot و دیگر ابزارهای AI برای ساده‌سازی فرایند آورده شده است. مایکروسافت تأکید می‌کند که با اتکا به این فناوری‌ها می‌توان به راحتی با تغییرات سریع دنیای فناوری همگام شد و زیرساخت‌های نرم‌افزاری سازمان را با کمترین ریسک و هزینه به‌روزرسانی کرد. 🔹 اگر قصد مهاجرت از EWS به سرویس‌های ابری جدیدتر را دارید، پیشنهاد می‌شود حتماً از مزایای هوش مصنوعی و ابزارهایی چون GitHub Copilot بهره بگیرید تا تجربه‌ای سریع‌تر، آسان‌تر و مطمئن‌تر داشته باشید. https://devblogs.microsoft.com/microsoft365dev/supercharge-your-ews-migration-with-ai-and-github-copilot @DeveloperAdvocate 🥑

در این مقاله از وبلاگ «Old New Thing»، نویسنده به موضوع اختلاف اسامی مسیرهای پرینتر در ویندوز قدیم و جدید می‌پردازد. در نسخه‌های قدیمی ویندوز (مثل Windows 9x)، مسیرهای پرینتر به صورت \\server\printer نمایش داده می‌شدند. اما در نسخه‌های جدیدتر (مثل Windows NT)، برای مقصد پرینتر از مسیرهایی مانند \\server\print$\printer یا \\server\printer استفاده می‌شود. دلیل این تفاوت‌ها به ساختار داخلی سیستم‌عامل و سازگاری با نسخه‌های مختلف برمی‌گردد. ویندوز باید امکان تشخیص و پشتیبانی هر دو نوع مسیر را داشته باشد تا برنامه‌های قدیمی و جدید به‌درستی کار کنند. همچنین، سیستم مدیریت پرینتر در هر نسخه از ویندوز کمی متفاوت است و به همین خاطر برخی اسم مسیرها شبیه به‌نظر می‌رسند ولی در واقع به مکان یا نشانه خاصی روی سیستم اشاره دارند. نکته دیگر اینکه برخی اسامی مثل LPT1 یا COM1 هم برای نگهداری سازگاری تاریخی، هنوز در سیستم وجود دارند، هرچند استفاده اصلی آنها مربوط به پرینترهای خیلی قدیمی است. به طور کلی، ویندوز همیشه تلاش می‌کند ضمن اضافه کردن امکانات جدید، همچنان پشتیبانی از روش‌ها و مسیرهای قدیمی‌تر را نیز حفظ کند تا کاربران با مشکلات ناسازگاری مواجه نشوند. https://devblogs.microsoft.com/oldnewthing/20250715-00/?p=111381 @DeveloperAdvocate 🥑

مایکروسافت در نسخه پیش‌نمایش ۶ از دات‌نت ۶ (که به اشتباه در آدرس، دات‌نت ۱۰ قید شده) ویژگی‌ها و بهبودهای جدیدی را معرفی کرده است. در این نسخه، تمرکز اصلی روی بهبود کارایی، تجربه توسعه‌دهنده و رفع مشکلات نسخه‌های قبلی بوده است. برخی از مهم‌ترین تغییرات این نسخه عبارت‌اند از: ۱. بهبود اجرای دات‌نت در پلتفرم‌های مختلف: این نسخه سازگاری و پشتیبانی بهتری با سیستم‌عامل‌های لینوکس، مک و ویندوز ارائه می‌کند و مشکلات اجرا در برخی سناریوهای خاص رفع شده است. ۲. بهبود در hot reload: قابلیت Hot Reload در این نسخه پایدارتر و کاربردی‌تر شده است تا توسعه‌دهندگان بتوانند بدون نیاز به متوقف کردن برنامه، تغییرات کد را به سرعت مشاهده کنند. ۳. به‌روزرسانی ASP.NET Core: در این نسخه برای توسعه وب، بهبودهایی از نظر عملکرد، امنیت و بهینه‌سازی کتابخانه‌ها معرفی شده و توسعه سریع‌تر برنامه‌های وب را امکان‌پذیر می‌سازد. ۴. بهینه‌سازی‌های Blazor: ابزارها و ویژگی‌های جدیدی برای فریم‌ورک Blazor اضافه شده که توسعه اپلیکیشن‌های وب تعاملی را ساده‌تر و سریع‌تر می‌کند. ۵. بهبود Entity Framework Core: نسخه جدید EF Core بهینه‌تر و با امکانات تازه‌ای عرضه شده است که مدیریت پایگاه داده‌ها را آسان‌تر می‌کند. ۶. پشتیبانی بهتر از زبان #C نسخه ۱۰: امکانات جدید زبان برنامه‌نویسی سی‌شارپ ۱۰، شامل دستورات ساده‌تر و قابلیت‌های مدرن‌تر، به این نسخه افزوده شده تا توسعه کدهای تمیزتر و خواناتر باشد. در کنار این ویژگی‌ها، مشکلات گزارش شده توسط کاربران نسخه‌های پیشین رفع شده تا قدرت و پایداری دات‌نت نسخه ۶ بیشتر شود. انتشار این پیش‌نمایش نشان‌دهنده نزدیک شدن به نسخه نهایی است و توصیه می‌شود توسعه‌دهندگان پروژه‌های خود را با امکانات جدید تست و تجربه کنند. https://devblogs.microsoft.com/dotnet/dotnet-10-preview-6 @DeveloperAdvocate 🥑

در هنگام تعویض دیسک سیستم‌عامل (OS Disk) ماشین مجازی در Azure، یکی از چالش‌های مهم، مدیریت صحیح اکستنشن‌های نصب‌شده روی ماشین مجازی است. اکستنشن‌ها افزونه‌هایی هستند که امکاناتی مثل آنتی‌ویروس، بکاپ، مانیتورینگ و غیره را به ماشین مجازی اضافه می‌کنند. وقتی دیسک سیستم‌عامل را تعویض می‌کنید (مثلاً برای بازیابی یا ارتقا)، باید به این نکات توجه کنید: ۱. اکستنشن‌ها اطلاعات وضعیت خود را روی دیسک سیستم‌عامل ذخیره می‌کنند. بنابراین بعد از تعویض دیسک OS، ممکن است اکستنشن‌ها نتوانند کار خود را ادامه دهند یا وضعیت ناسازگاری پیدا ‌کنند. ۲. تمیز کردن اکستنشن‌ها قبل از تعویض دیسک پیشنهاد می‌شود. می‌توانید اکستنشن‌ها را حذف کرده و پس از جایگزینی دیسک، دوباره آن‌ها را نصب کنید تا اطلاعات به‌روز و صحیحی روی دیسک جدید بنویسند. ۳. اگر دیسک سیستم‌عامل جدید کاملاً شبیه قبلی است (مثلاً از یک اسنپ‌شات برگشت خورده) ممکن است برخی اکستنشن‌ها بتوانند به‌درستی کار کنند، اما تضمینی برای همه اکستنشن‌ها وجود ندارد. ۴. در سناریوهایی که باید دیسک OS را جایگزین کنید، مخصوصاً برای ماشین‌های حساس، استفاده از اسکریپت‌های اتوماسیون برای حذف و سپس نصب مجدد اکستنشن‌ها توصیه شده است. ۵. هنگام مدیریت اکستنشن‌ها، به مجوزها، شناسه‌ها و پیکربندی‌های مربوط به هر اکستنشن توجه لازم را داشته باشید تا پس از تعویض دیسک دچار مشکل نشوید. در نتیجه: اگر در محیط Azure کار می‌کنید و با عملیات جایگزینی دیسک سیستم‌عامل سروکار دارید، حتماً برنامه‌ریزی دقیقی برای حذف و افزودن مجدد اکستنشن‌ها داشته باشید تا ماشین مجازی شما به خوبی و بدون مشکل به کار ادامه دهد. https://devblogs.microsoft.com/azure-vm-runtime/extension-concerns-when-replacing-the-os-disk @DeveloperAdvocate 🥑

در این مقاله وبلاگ رسمی دات‌نت، مایکروسافت اعلام کرده که سرور MCP (Managed Code Package) را به عنوان یک راهکار ساده و سریع برای راه‌اندازی یک سرور شخصی NuGet معرفی کرده است. NuGet ابزار رسمی مدیریت بسته‌ها در اکوسیستم .NET است و گاهی کاربران یا تیم‌ها نیاز دارند بسته‌های خود را به صورت خصوصی و مستقل از فضای عمومی نگهداری کنند. قبلاً راه‌اندازی سرور اختصاصی NuGet نیاز به استفاده از ابزارهایی مثل NuGet.Server یا BaGet و پیکربندی‌های پیچیده داشت. اما MCP.Server با هدف ساده‌سازی این فرآیند عرضه شده و تنها با چند فرمان ساده در خط فرمان می‌توان یک سرور خصوصی، سبک‌وزن و کاملاً متن‌باز برای میزبانی پکیج‌ها ایجاد کرد. این ابزار مبتنی بر .NET و ارائه شده توسط تیم رسمی NuGet است. برای استفاده کافی است mcp-server را به صورت گلوبال از طریق dotnet tool نصب کنید و در پوشه مدنظر اجرا نمایید تا به راحتی بسته‌های خود را مدیریت، آپلود و فراخوانی کنید. MCP.Server دارای داکیومنت کامل، تنظیمات قابل سفارشی‌سازی، سرعت بالا و نصب بسیار آسان است. همچنین امکان احراز هویت و محدود کردن دسترسی نیز فراهم شده تا تیم‌ها و سازمان‌ها بتوانند با اطمینان بسته‌های داخلی خود را نگهداری کنند. طبق راهنمای مقاله، فقط کافی است چند دستور ساده اجرا شود تا سرور توزیع بسته‌های .NET در اختیار شما قرار گیرد. این خبر برای توسعه‌دهندگان و تیم‌هایی که به فضای خصوصی برای پکیج‌های NuGet نیاز دارند بسیار کاربردی است و یک انتخاب امن و ساده برای میزبانی داخلی بسته‌ها فراهم می‌کند. https://devblogs.microsoft.com/dotnet/mcp-server-dotnet-nuget-quickstart @DeveloperAdvocate 🥑

🔹 توضیحات کامل مقاله "Power Platform API and SDKs: From UX-first to API-first" در این مقاله، تیم توسعه Power Platform مایکروسافت توضیح می‌دهد که چگونه رویکرد این پلتفرم از طراحی مبتنی بر رابط کاربری (UX-first) به طراحی مبتنی بر API (API-first) تغییر یافته است. پیش‌تر، بیشتر قابلیت‌های Power Platform ابتدا در رابط کاربری پیاده‌سازی می‌شدند و سپس APIهای لازم برای توسعه‌دهندگان فراهم می‌گردید. این موضوع باعث می‌شد گاهی توسعه‌دهندگان با محدودیت‌هایی مواجه شوند چون همه قابلیت‌ها از طریق API در دسترس نبودند. اکنون Power Platform به سمت مدل API-first حرکت کرده است؛ به این معنا که ابتدا سرویس‌ها و امکانات اصلی به شکل API طراحی و عرضه می‌شوند. بنابراین توسعه‌دهندگان زودتر به جدیدترین ویژگی‌ها دسترسی دارند و می‌توانند فرآیندهای اتوماسیون، هوش مصنوعی، ساخت برنامه‌ها و ارتباط با داده‌ها را به شکلی یکپارچه‌تر انجام دهند. همچنین این تغییر باعث می‌شود SDKها و ابزارهای توسعه سریع‌تر و ساده‌تر به‌روزرسانی شوند و جامعه توسعه‌دهندگان بتوانند راحت‌تر و منعطف‌تر راه‌حل‌های حرفه‌ای بسازند. در این مقاله برخی از جدیدترین تغییرات و امکانات معرفی شده‌اند؛ از جمله دسترسی گسترده‌تر به داده‌ها، مدیریت بهبود یافته محیط‌ها و راه‌های جدید تعامل با Power Platform از طریق API رسمی. از این پس، توسعه‌دهندگان می‌توانند با استفاده از APIهای جدید به عملکردهایی دسترسی پیدا کنند که پیشتر تنها از طریق محیط‌های گرافیکی ممکن بود. در انتها، مایکروسافت برنامه آینده خود را برای توسعه بیشتر APIها و ارائه مستندات جامع و ابزارهای متن‌باز اعلام کرده است تا اکوسیستم Power Platform برای همه توسعه‌دهندگان جذاب‌تر و کارآمدتر شود. 🔗 اطلاعات بیشتر در وبلاگ رسمی مایکروسافت Power Platform https://devblogs.microsoft.com/powerplatform/power-platform-api-and-sdks-from-ux-first-to-api-first @DeveloperAdvocate 🥑

در این مقاله از وبلاگ توسعه‌دهندگان مایکروسافت، تغییرات جدید در زمینه نحوه مدیریت و سرکوب هشدارها در ابزار Code Analysis برای زبان ++C مایکروسافت توضیح داده شده است. در گذشته، سرکوب‌های هشدار عمدتاً با استفاده از دستورالعمل‌های pragma مانند #pragma warning(suppress: xxx) انجام می‌شد که فقط برای هشدارهای کامپایلر کاربرد داشت. اما اکنون این قابلیت بهبود یافته و سرکوب هشدارهای تحلیل کد (Code Analysis) نیز به همین روش پشتیبانی می‌شود. نکته مهم دیگر این است که شناسه‌های هشدارهای تحلیل کد قبلاً با فرمت پیشوند Cxxxx (مانند C26451) بودند، اما اکنون برای هماهنگی بیشتر با کامپایلر و ساده‌سازی مدیریت هشدارها، از فرمت جدید CAxxxx (مانند CA26451) استفاده می‌کنند. این تغییر موجب می‌شود فرایند سرکوب هشدار با این شناسه‌ها راحت‌تر و یکنواخت‌تر باشد. همچنین اکنون می‌توان هشدارهای تحلیل کد را از طریق شناسه CAxxxx مستقیماً در همان خط کد با استفاده از پراگماهای استاندارد سرکوب کرد. برای نمونه:

#pragma warning(suppress: 26451)

این پشتیبانی جدید برای توسعه‌دهندگان امکان کنترل دقیق‌تر و محلی‌تر بر هشدارها را فراهم می‌کند و نیاز به ویرایش فایل تنظیمات یا پراگماهای پیچیده را کاهش می‌دهد. در انتهای مقاله تأکید شده که این ابزارها همواره در حال پیشرفت‌اند و تیم مایکروسافت به بازخورد برنامه‌نویسان اهمیت زیادی می‌دهد تا تجربه کدنویسی باکیفیت‌تری میسر شود. https://devblogs.microsoft.com/cppblog/updates-to-warning-suppressions-in-microsoft-c-code-analysis @DeveloperAdvocate 🥑

در این مقاله از وبلاگ رسمی مایکروسافت، نویسنده به چرایی وجود خط و نشان/ ممیز مورب (slash) به جای خطوط دیگر مانند بک‌اسلش (\) در مسیرهای URL پرداخته است. توضیح داده می‌شود که دلیل این انتخاب به استانداردهای اولیه اینترنت برمی‌گردد؛ در آن زمان برای جدا کردن مسیرها از کاراکتر اسلش (/) استفاده شد چرا که UNIX نیز از همین علامت برای ساختار پوشه‌ها استفاده می‌کرد. اگرچه در ویندوز از بک‌اسلش (\) برای مسیرها استفاده می‌شود، اما URLها همچنان از اسلش (/) پیروی می‌کنند تا با استانداردهای جهانی و سیستم‌های دیگر مانند UNIX سازگار باشند. همچنین، نویسنده یادآوری می‌کند که در ابتدای توسعه اینترنت، بسیاری از مشکلات ناسازگاری بابت همین تفاوت نمادها ایجاد شد اما در نهایت اسلش (/) به‌عنوان یک انتخاب رایج تثبیت شد و امروزه هم در تمام مرورگرها و وب‌سایت‌ها همین استاندارد رعایت می‌شود. بنابراین اگرچه علامت‌های مختلفی وجود داشت، اما دلیل انتخاب اسلش در URLها ریشه در تاریخچه سیستم‌های عامل اولیه و استانداردهای بین‌المللی دارد. https://devblogs.microsoft.com/oldnewthing/20250716-00/?p=111383 @DeveloperAdvocate 🥑

مایکروسافت و لانگ‌چین4J همکاری جدیدی را برای توسعه برنامه‌های هوش مصنوعی مبتنی بر جاوا با امنیت و مقیاس‌پذیری سازمانی اعلام کردند. لانگ‌چین4J یک چارچوب قدرتمند برای ساخت اپلیکیشن‌های هوش مصنوعی مولد و Agentهای هوشمند با زبان جاوا است. در این همکاری، امکاناتی مانند نمونه‌های کد برای یکپارچه‌سازی با سرویس‌های ابری مایکروسافت از جمله Azure AI و Azure OpenAI، مدیریت هویت، امنیت داده‌ها و پشتیبانی جامعه توسعه یافته در اختیار برنامه‌نویسان جاوا قرار می‌گیرد. همکاران پروژه، ابزارها و کتابخانه‌های جدیدی را طراحی کرده‌اند که امکان اتصال ساده اپلیکیشن‌های جاوا به مدل‌های پیشرفته هوش مصنوعی و استفاده ایمن در محیط‌های سازمانی را فراهم می‌کند. از جمله امکانات مهم، ادغام با سرویس Azure OpenAI برای دسترسی به مدل‌هایی مانند GPT-4 و مدیریت ایمن داده‌ها، محدودسازی دسترسی بر اساس نقش و کنترل هویت کاربران است. علاوه بر این، منابع و راهنماهایی برای شروع کار سریع، مثلاً نمونه‌های کدنویسی و پروژه‌های آغازین (starter projects) منتشر شده تا توسعه‌دهندگان بتوانند سریع‌تر اپلیکیشن‌های هوش مصنوعی خود را با استانداردهای امنیتی مایکروسافت تولید و اجرا کنند. این همکاری قدمی مهم در توسعه نرم‌افزارهای مبتنی بر هوش مصنوعی با استفاده از قابلیت‌ها و اکوسیستم جاوا به حساب می‌آید و گزینه‌های بیشتری برای سازمان‌ها و برنامه‌نویسان فراهم می‌کند تا بتوانند محصولات هوشمندتر و ایمن‌تری بسازند. https://devblogs.microsoft.com/java/microsoft-and-langchain4j-a-partnership-for-secure-enterprise-grade-java-ai-applications @DeveloperAdvocate 🥑