DEV Community: Peter Saktor

GitHub Spec-Kit: From Vibe Coding to Spec-Driven Development

Peter Saktor — Mon, 06 Apr 2026 17:12:24 +0000

AI coding agents are improving rapidly. Tools like Copilot, Codex, and Claude can generate large chunks of code, but without proper structure, this can quickly lead to messy and inconsistent implementations.

That’s where spec-driven development comes in.

By using the GitHub Spec-kit, you can move from "hoping for the best" to a controlled, logical development cycle where the AI works for you, not the other way around.

What is Spec-Kit?

Spec-kit is an AI prompting framework designed to integrate various coding agents (like Copilot, Claude Code, or Codex) into a structured workflow.

The core philosophy is simple: Start with a spec.

The Spec: A high-level description of what you want to build, focusing on the "what" and "why" without technical implementation details.
The Plan: A technical blueprint derived from the spec.
The Tasks: A logical list of coding steps.
The Code: The final implementation carried out by the agent.

Why use it?

If you’ve tried “vibe coding” with AI, you’ve probably seen this:

The agent goes off track
Code becomes inconsistent
Bugs appear in unexpected places
Everything feels loosely stitched together

Spec-Kit solves this by introducing structure.

Benefits

More control over AI output
You clearly define what the agent should do before it writes code.
Consistency across teams
Specs act as shared rules, especially valuable in team environments.
Traceability
Specs are stored in your repository, so the AI has historical context.
Better alignment
You can review plans and tasks before any code is generated.

Getting Started with Spec-Kit

The easiest way to get started is from the official repository:

👉 https://github.com/github/spec-kit

Spec-Kit uses uv, a fast Python package manager. You can initialize it within an existing project or scaffold a new one.

Create a new project

uvx --from git+https://github.com/github/spec-kit.git@vX.Y.Z specify init <PROJECT_NAME>

Use it in an existing project

uvx --from git+https://github.com/github/spec-kit.git@vX.Y.Z specify init --here

The uvx command runs a package without installing it, similar to npx for Node packages.

During setup, you’ll choose:

Coding agent (e.g., Copilot)
Script type (e.g., PowerShell)

The command creates two folders:

├── 📁 .github/     # Prepared prompts for your coding agent
└── 📁 .specify/    # Memory (constitution), scripts, and templates

.github/ contains prompts for different development stages, available in your Copilot chat
.specify/memory/ holds your constitution.md file with ground rules
.specify/scripts/ contains PowerShell scripts that the agent runs
.specify/templates/ provides templates for specs, plans, and tasks

The Development Cycle

Here's the typical Spec-Kit workflow:

Command	Purpose
`/constitution`	Set core binding principles for the entire application
`/specify`	Create a high-level spec for a feature (creates new branch)
`/clarify` (optional)	Agent asks questions about underspecified areas
`/plan`	Add technical preferences (frameworks, libraries, etc.)
`/tasks`	Turn the plan into a logical list of coding tasks
`/analyze` (optional)	Check alignment across all artifacts
`/implement`	Execute the tasks and build the feature

At the end of the cycle, you have a working feature based entirely on your initial spec. For each new feature, you walk through this process again, minus the constitution command, which you typically run once.

Real-World Demo: Refactoring an Azure Container App

I scaffolded a demo app called ACSdemo using GitHub Copilot CLI - an Azure Container App with this structure:

ACSdemo/
 ├── 📄 ACSdemo.slnx
 ├── 📄 README.md
 ├── 📄 docker-compose.yml
 ├── 📄 .dockerignore
 │
 ├── 📁 src/
 │   └── 📁 ACSdemo.Api/
 │       ├── 📄 Program.cs
 │       ├── 📄 WeatherForecast.cs
 │       ├── 📄 appsettings.json
 │       ├── 📄 appsettings.Development.json
 │       ├── 📄 Dockerfile
 │       ├── 📁 Controllers/
 │       │   ├── EventsController.cs
 │       │   ├── MessagesController.cs
 │       │   └── WeatherForecastController.cs
 │       ├── 📁 Models/
 │       │   ├── SendEmailRequest.cs
 │       │   └── SendSmsRequest.cs
 │       ├── 📁 Services/
 │       │   ├── ICommunicationService.cs
 │       │   └── CommunicationService.cs
 │       └── 📁 Properties/
 │           └── launchSettings.json
 │
 ├── 📁 dapr/
 │   └── 📁 components/
 │       ├── pubsub.yaml
 │       └── statestore.yaml
 │
 └── 📁 deploy/
     ├── main.bicep
     └── containerapp.bicep

The goal:

Remove old REST controllers
Process Azure Service Bus events
Store data in Cosmos DB
Expose data via GraphQL

👉 Important constraint:
No manual coding, everything done by the AI agent.

Step 1: The Constitution Command

The constitution (constitution.md) outlines governing principles for your project, required frameworks, UX guidelines, testing expectations, etc.

Here's the prompt I used:

/speckit.constitution Create a project constitution for a microservice called "ACSdemo" with:

## Architecture & Design Patterns
- CQRS pattern with MediatR for all business operations
- Single-project structure with Domain/, Application/, Infrastructure/, Web/ folders
- GraphQL primary API using HotChocolate v15 with Apollo Federation

## Testing Requirements (NON-NEGOTIABLE)
- No unit tests, integration tests, or acceptance tests (demo app simplification)

## Communication & Integration
- Dapr pub/sub with Azure Service Bus, [Dapr.Topic()] attributes

## Technology Stack (exact versions)
- Runtime: .NET 10.0
- CQRS: MediatR 12.x
- GraphQL: HotChocolate 15.x
- Persistence: Azure Cosmos DB
- Messaging: Azure Service Bus via Dapr pub/sub
- Persistence: Azure Cosmos DB (Microsoft.Azure.Cosmos)
- Configuration: Azure App Configuration + Azure Key Vault
- Containerization: Docker (Linux), Azure Container Apps

## Infrastructure
- All Azure resources in Bicep templates under .infrastructure/. No manual portal changes.
- Configuration via Azure App Configuration with Key Vault for secrets.
- Environment values parameterized, never hardcoded.

Output: A constitution with 6 core principles.

Pro tip: I deliberately pulled back on testing because this is a demo. In a real project, you'd add testing requirements to the constitutional prompt.

Step 2: The Specify Command

Instead of describing implementation, we define intent. We should focus on the what and the why, not the how:

/speckit.specify acsdemo-refactoring - This application needs refactoring. 
Delete EventsController, MessagesController, and WeatherForecastController.
Create a new EmailNotification controller that receives the 
Microsoft.Communication.EmailDeliveryReportReceived event from Azure Service Bus 
and saves it to Azure Cosmos DB. Users can then retrieve data via GraphQL queries.

Output: A spec with 3 user stories (P1: data capture, P2: GraphQL queries, P3: cleanup) and 8 functional requirements.

Step 3: The Clarify Command (Optional but Valuable)

The clarify command instructs the agent to read the spec and find ambiguities, edge cases, or areas needing clarification. It asks you questions, and your answers get baked into the spec.

I ran it without any additional input:

/speckit.clarify

The agent asked 5 questions, each with recommendations:

How to store delivery status history? → Append a statusHistory array (Cosmos DB idiomatic approach)
What partition key for Cosmos DB? → email address (optimizes the main query path)
Should GraphQL support pagination? → Offset/limit with default page size of 20
Closed enum or open string for status values? → Open string (EmailDeliveryReportReceived is an external contract owned by Microsoft and can change)
Maximum retry limit or defer to infrastructure? → Defer to Dapr/Service Bus config (YAGNI)

All questions answered, the spec was updated, and coverage was confirmed across all categories.

Key insight: This is where Spec-Kit shines. The agent thinks through edge cases you might have missed and documents the decisions.

Step 4: The Plan Command

Now we define the how.

Before planning, read your spec and make sure it's correct. All planning, research, task generation, and implementation will be based on this spec. Fix it now, not later.

/speckit.plan 

## 1. Cleanup & Deletion
- Delete Controllers/EventsController.cs, MessagesController.cs, WeatherForecastController.cs
- Remove associated DTOs

## 2. Domain Layer
- Create Domain/Entities/EmailDeliveryReport.cs with GuardClauses

## 3. Application Layer (CQRS & MediatR)
- Create SaveEmailDeliveryReport command (co-locate with handler + validator)
- Create GetEmailDeliveryReports query (co-locate with handler + validator)

## 4. Infrastructure Layer
- Update Cosmos DB configuration
- Update Bicep templates
- Configure Dapr pub/sub

## 5. Web Layer
- Create Dapr pub/sub endpoint in EmailNotificationController
- Create GraphQL queries with HotChocolate

## 6. Configuration & Wire-up
- DI registration via Configuration/ folder extension methods

Output: A complete plan with research decisions, data models, GraphQL contracts, Dapr subscription specs, and a quickstart guide. All constitution checks passed.

Step 5: The Tasks Command

This command takes the plan and turns it into a series of tasks for the AI to follow. No additional input needed, just run it:

/speckit.tasks

Output: 33 tasks across 6 phases, with clear parallelization opportunities:

Phase	Tasks	Focus
Phase 1: Setup	T001–T003	.csproj upgrade, folder scaffold
Phase 2: Foundational	T004–T006	Repository port, validation stub
Phase 3: US1 (MVP)	T007–T015	Entity, command, controller
Phase 4: US2	T016–T020	GraphQL queries
Phase 5: US3	T021–T025	Legacy code cleanup
Polish	T026–T033	Bicep, configuration

Step 6: The Analyze Command (Optional but Recommended)

The analyze command reviews all artifacts for inconsistencies, ambiguities, or coverage gaps. It's read-only, the agent won't make changes.

/speckit.analyze

The analysis found 9 issues, including:

CRITICAL: Missing FluentValidation validators in query files (violates Constitution Principle I)
HIGH: TotalCount field in GraphQL schema couldn't be populated
HIGH: DI registration removal happening before dependent controllers were deleted

I asked for concrete remediation:

Suggest concrete remediation edits for the top issues

The agent provided specific edits for each issue, which I applied directly to tasks.md.

Always run analyze before implementation. It catches constitutional violations and logical gaps that would cause runtime failures.

Step 7: The Implement Command

Finally, the agent runs through the task list and writes the code. You end up with a fully implemented feature that actually matches your initial vision.

/speckit.implement

Result: Implementation complete — 33/33 tasks ✅

Build succeeded with 0 errors, 0 warnings
All legacy files deleted
Full infrastructure defined in Bicep
GraphQL endpoint working
Dapr pub/sub configured

Add a new feature

We can reuse our spec with a different plan, task list, and implementation. For example, if I want to implement a similar kind of feature using a different stack or database, I can use that spec file again because it does not contain any implementation details, only the required features from a user’s perspective. I could walk through the whole process again if I wanted to add another feature to the application.

I am going to start with a new spec. I do not need to change the constitution file because there have been no changes to the grounding principles of the app. We can jump straight to the specify command. We have a new branch and a new spec file inside the folder.

When Should You Use Spec-Kit?

Use it when:

You want structured AI development
You work in a team environment
You need traceability and consistency

Avoid it when:

You’re building quick throwaway prototypes
The feature is too small (overhead isn’t worth it)

The Future of Spec-Kit

Spec-Kit is new and constantly evolving. New features are being added regularly, so keep up by checking the GitHub repo.

You can find the source code for the demo app here: ACSdemo

Automatic Prompt Optimization: When AI Learns to Improve Its Own Prompts

Peter Saktor — Wed, 18 Feb 2026 15:18:37 +0000

The Challenge We All Face

We've all been there. You spend hours crafting what seems like the perfect prompt, but end up with mediocre results. You tweak a word here and restructure a sentence there, slowly-painfully slowly-inches toward better results.

But what if your AI could optimize its own prompts?

What if you could build a system that automatically tests variations, learns what works, and improves continuously without manual intervention?

What is Automatic Prompt Optimization?

Automatic Prompt Optimization is exactly what it sounds like: a system that uses AI to experiment with and evaluate its own prompts systematically.

Think of it as a prompt engineer that never sleeps-constantly testing variations, measuring performance, and evolving toward better results.

The Core Concept

This creates a self-improving loop that can dramatically improve prompt quality with minimal human effort.

System Architecture

Let's look at how our automatic prompt optimizer is structured:

[Note: The image above shows the complete architecture with PromptOptimizer, DeepSeekClient, RateLimiter, and the evaluation flow]

Key Components:

PromptOptimizer - The brain of the operation, managing the optimization cycle
DeepSeekClient - Handles API communication with retry logic and rate limiting
RateLimiter - Ensures we stay within API quotas using the token bucket algorithm
Evaluation Engine - Scores prompt variations against test cases

Implementation Deep Dive

Let's walk through the actual code from the GitHub repository. This is production-ready code you can use today.

The PromptOptimizer Class

async def optimize_prompt(
    self,
    base_prompt: str,
    task_description: str,
    evaluation_examples: List[Dict],
    optimization_rounds: int = 3
) -> Dict:
    """Optimize a prompt through multiple rounds"""

    current_prompt = base_prompt
    best_score = 0
    best_prompt = base_prompt

    for round_num in range(optimization_rounds):
        print(f"Optimization Round {round_num + 1}/{optimization_rounds}")

        # Generate prompt variations
        variations = await self._generate_variations(
            current_prompt,
            task_description,
            round_num
        )

        # Evaluate variations
        evaluation_results = []
        for variation in variations:
            score = await self._evaluate_prompt(
                variation,
                evaluation_examples
            )
            evaluation_results.append({
                "prompt": variation,
                "score": score,
                "round": round_num
            })

        # Select best variation
        best_variation = max(evaluation_results, key=lambda x: x["score"])

        # Store results
        self.performance_history.extend(evaluation_results)

        if best_variation["score"] > best_score:
            best_score = best_variation["score"]
            best_prompt = best_variation["prompt"]
            current_prompt = best_variation["prompt"]

            print(f"Improved score: {best_score:.3f}")
        else:
            print(f"No improvement. Best score: {best_score:.3f}")
            # Try different optimization strategy
            current_prompt = await self._try_different_strategy(
                current_prompt,
                task_description
            )

        return {
            "optimized_prompt": best_prompt,
            "final_score": best_score,
            "improvement_from_original": best_score - await self._evaluate_prompt(base_prompt, evaluation_examples),
            "optimization_rounds": optimization_rounds,
            "performance_history": self.performance_history
        }

This is the heart of the system. In each round:

Generate variations using different strategies
Test each variation against evaluation examples
Score the results
Keep the best performer
Try different strategies if no improvement

Generating Smart Variations

The system doesn't just make random changes. It uses different optimization strategies:

async def _generate_variations(
    self,
    prompt: str,
    task_description: str,
    round_num: int
) -> List[str]:
    """Generate variations of a prompt"""

    variation_strategies = [
        "improve_clarity",
        "add_examples",
    ]

    # Select strategy based on round
    strategy = variation_strategies[round_num % len(variation_strategies)]

    optimization_prompt = f"""
    Optimize this prompt for better performance:

    Original Prompt:
    {prompt}

    Task Description:
    {task_description}

    Optimization Strategy: {strategy}

    Generate 2 improved variations of this prompt.
    Return each variation on a new line starting with "VARIATION X:".
    """

    response = await self.client.chat_completion(
        messages=[{"role": "user", "content": optimization_prompt}],
        temperature=0.7,
        max_tokens=1000
    )

    variations = self._extract_variations(response['choices'][0]['message']['content'])
    return variations[:2]  # Return top 2 variations

Evaluating Prompt Quality

Each variation gets scored against test examples:

async def _evaluate_prompt(
    self,
    prompt: str,
    evaluation_examples: List[Dict]
) -> float:
    """Evaluate prompt quality"""

    scores = []

    for example in evaluation_examples:
        test_input = example["input"]
        expected_output = example.get("expected_output")

        # Test prompt with example
        test_prompt = f"{prompt}\n\nInput: {test_input}"

        messages = [{"role": "user", "content": test_prompt}]
        response = await self.client.chat_completion(
            messages=messages,
            temperature=0.3,
            max_tokens=500
        )

        actual_output = response['choices'][0]['message']['content']

        # Calculate score based on metrics
        example_score = self._calculate_example_score(
            actual_output,
            expected_output,
            example.get("evaluation_criteria", {})
        )

        scores.append(example_score)

    # Return average score
    return sum(scores) / len(scores) if scores else 0

Smart Recovery When Stuck

If improvements stall, the system tries a completely different approach:

async def _try_different_strategy(self, current_prompt: str, task_description: str) -> str:
    """Try a different optimization strategy"""

    strategy_prompt = f"""
    The previous optimization attempt didn't improve results.
    Try a completely different approach:

    Current Prompt:
    {current_prompt}

    Task: {task_description}

    Generate a significantly different prompt that takes a fresh approach.
    Think about:
    1. Different framing of the task
    2. Different output format
    3. Different level of detail
    4. Different tone or style

    Return only the new prompt without explanation.
    """

    response = await self.client.chat_completion(
        messages=[{"role": "user", "content": strategy_prompt}],
        temperature=0.8,
        max_tokens=1000
    )

    return response['choices'][0]['message']['content']

Running the System

Here's how to use the optimizer in practice:

async def main():
    """Execute prompt optimization system"""

    config = DeepSeekConfig(api_key=shared.get_api_key('DEEP_SEEK_API_KEY'))

    async with DeepSeekClient(config) as client:
        # Initialize optimizer
        optimizer = PromptOptimizer(
            client=client,
            evaluation_metrics=["clarity", "completeness", "relevance"]
        )

        # Base prompt to optimize
        base_prompt = """
        Explain a technical concept in simple terms.
        Make it easy to understand for beginners.
        """

        # Task description
        task_description = "Explain machine learning to someone with no technical background"

        # Evaluation examples
        evaluation_examples = [
            {
                "input": "What is machine learning?",
                "expected_output": "Machine learning is when computers learn from examples instead of being explicitly programmed",
                "evaluation_criteria": {
                    "clarity": 0.8,
                    "completeness": 0.7
                }
            }
        ]

        # Run optimization
        result = await optimizer.optimize_prompt(
            base_prompt=base_prompt,
            task_description=task_description,
            evaluation_examples=evaluation_examples,
            optimization_rounds=3
        )

        print(f"Optimized Prompt: {result['optimized_prompt']}")
        print(f"Improvement: {result['improvement_from_original']:.3f}")

Sample Output

When you run this system, you'll see output like:

Optimization Round 1/3
Improved score: 0.723

Optimization Round 2/3
Improved score: 0.856

Optimization Round 3/3
Improved score: 0.892

Optimization Complete!
Final Score: 0.892
Improvement from original: 0.245
Optimized_prompt: Imagine you're explaining machine learning to your grandmother. Use everyday analogies, like...

The optimized prompt might evolve from a generic request to something like:

"Imagine you're explaining machine learning to your grandmother. Use everyday analogies, like how we learn to recognize apples by seeing many examples, not by following rules. Start with a simple one-sentence definition, then build understanding through relatable examples. Avoid all technical jargon. End with a practical example they encounter daily."

Real-World Applications

This system isn't just theoretical. Here's where you can apply it:

1. Content Generation Pipelines

Automatically optimize prompts for blog posts, social media, or marketing copy based on engagement metrics.

2. Code Generation

Fine-tune prompts for different programming languages and frameworks based on test pass rates.

3. Customer Support

Optimize prompts for different query types based on customer satisfaction scores.

4. Educational Content

Improve explanation prompts based on student comprehension tests.

5. Data Analysis

Optimize analytical prompts based on insight quality and actionability.

Production Considerations

When deploying this in production, consider:

Rate Limiting

The system includes a token bucket rate limiter to stay within API quotas:

class RateLimiter:
    """Token bucket rate limiter"""
    def __init__(self, max_requests: int, per_seconds: int):
        self.max_requests = max_requests
        self.per_seconds = per_seconds
        self.tokens = max_requests
        # ...

Retry Logic

API calls use exponential backoff for resilience:

@retry(
    stop=stop_after_attempt(3),
    wait=wait_exponential(multiplier=1, min=4, max=10)
)
async def chat_completion(self, messages, ...):
    # ...

Cost Management

Track token usage across optimization rounds
Set max_tokens limits appropriately
Cache frequent queries to avoid redundant API calls

Beyond Basic Optimization

The system in Chapter 6 of DeepSeek Prompt Engineering goes even further with:

Self-Consistency Checks: Testing multiple reasoning paths
Tree of Thoughts: Exploring parallel solution branches
Meta-Prompting: Prompts that optimize their own structure
Cross-Domain Transfer: Applying learned strategies to new domains

Want to Go Deeper?

This implementation is just one piece of a comprehensive prompt engineering framework. The DeepSeek Prompt Engineering e-book covers:

Foundation techniques (Chapter 3): The 6-element prompt formula, zero-shot and few-shot learning
Advanced strategies (Chapter 4): Chain-of-Thought, Self-Consistency, Tree of Thoughts, ReAct
Domain specialization (Chapter 5): Software development, scientific research, business, creative writing
Integration & automation (Chapter 6): API frameworks, batch processing, agent-based systems
Future frontiers (Chapter 7): Neuro-symbolic prompting, quantum-inspired optimization

All code is available on GitHub with practical examples you can run immediately.

Get Started Today

Clone the repository: git clone https://github.com/petersaktor/deepseek-prompt-engineering
Install dependencies
Add your API key
Run the example: python chapter_6_6_1.py

Final Thoughts

Automatic Prompt Optimization represents a fundamental shift from static, manually-crafted prompts to dynamic, self-improving systems. By building these feedback loops, we move from telling AI what to do to creating systems that learn how to communicate most effectively.

The code shared here is production-ready and battle-tested. Use it to:

Reduce manual prompt engineering time
Continuously improve prompt performance
Scale prompt optimization across teams and use cases
Build self-improving AI applications

Get the complete e-book here for 170+ pages of techniques, 50+ code examples, and comprehensive domain-specific frameworks.

Visual Studio 2026 is the new IDE and agent cloud management with the built-in Azure MCP server

Peter Saktor — Mon, 17 Nov 2025 17:38:08 +0000

The release of Visual Studio 2026 is a game-changer for developers, setting the stage for a smarter, more connected IDE experience. At the core of this new setup are AI-first workflows powered by GitHub Copilot, plus a cool new cloud feature called the built-in Azure MCP Server that takes things to the next level.
This new feature is designed to eliminate context switching, allowing developers to manage, provision, and troubleshoot cloud resources using natural language and secure, agentic automation directly within the IDE.

Understanding the Built-in Azure MCP Server

The Azure MCP Server (Model Context Protocol Server) is a highly secure, standards-based component integrated into Visual Studio 2026. It serves as the dedicated communication bridge between the IDE’s AI agents (primarily through GitHub Copilot Chat) and the underlying Azure services.

Its core function is to facilitate agentic cloud automation:

It securely translates natural language requests (e.g., "List my resource groups") into executable Azure API calls.
It leverages existing local developer credentials, ensuring all operations are governed by your established Identity and Access Management (IAM) policies.
The result is a unified workflow where code generation, resource monitoring, and infrastructure-as-code (IaC) management occur seamlessly without requiring a separate terminal or web browser.

Configuring the Azure MCP Server Integration

Establishing connectivity for the Azure MCP Server is a streamlined process that relies on existing, established Azure tooling. The critical step is ensuring your local environment is correctly authenticated.

Step 1: Visual Studio Workload Installation

The MCP Server is bundled with the Azure development components of the IDE.

Launch the Visual Studio Installer.
Select Modify for your Visual Studio 2026 installation instance.
Ensure the Azure and AI development workload is selected for installation. This bundle includes the necessary MCP Server components.
Verify that GitHub Copilot is enabled, as it provides the primary interface for utilizing the MCP Server’s agentic capabilities.

Step 2: Authentication via Azure CLI and Azure Developer CLI

The MCP Server automatically inherits its credentials from the token cache managed by the Azure Command Line Interface (CLI). This ensures maximum security and consistency with all other Azure tooling.

➡️ Utilizing the Azure CLI (`az`) for Authentication

The recommended method for initial setup is the standard Azure login process:

Open your preferred command-line interface (e.g., Command Prompt, PowerShell, or Bash).
Execute the following command to establish credentials:
```
az login
```
This command initiates the device code or browser flow, allowing you to sign in with your Microsoft Entra ID (formerly Azure Active Directory) account.
Once successfully signed in, the authentication token is securely cached, and the Azure MCP Server automatically discovers and utilizes these credentials for all subsequent requests.

➡️ Integration with Azure Developer CLI (`azd`)

For developers focused on deploying end-to-end cloud applications, the Azure Developer CLI (azd) is essential. While azd primarily focuses on provisioning and deployment (often via Infrastructure-as-Code like Bicep), it also relies on the same credential store as the az CLI.

By ensuring you have successfully run az login, the MCP Server is ready to integrate with azd-initialized projects, utilizing the same identity to manage and inspect resources defined within your application's azure.yaml structure.

Step 3: Operational Usage via GitHub Copilot

With the MCP Server configured and authenticated, developers can interact with Azure using natural language within the Copilot Chat's Agent Mode within Visual Studio 2026.

Developer Query (Natural Language)	Azure MCP Server Operation
“Display the recent throughput metrics for the Cosmos DB instance associated with this solution.”	Executes secure queries against Azure Monitor and Cosmos DB APIs, presenting the data in the IDE.
“Generate the Bicep template necessary to provision a new virtual network with two subnets for my dev environment.”	Utilizes Azure knowledge to construct a validated IaC file based on security best practices.
“I need to confirm the firewall rules for my Azure SQL Database.”	Performs the resource inspection, retrieving and summarizing the active network security rules.

Visual Studio 2026, through the embedded Azure MCP Server, moves cloud development from a manual, multi-tool workflow to an integrated, AI-driven process, significantly improving developer velocity and operational security.

Modern PHP on Windows 11: VS Code, Podman, and MariaDB

Peter Saktor — Tue, 30 Sep 2025 17:06:59 +0000

Developing PHP applications on Windows used to be painful, often relying on legacy tools like XAMPP. Today, we have a clean, modern, and high-performance solution using Podman (a daemonless container engine compatible with Docker), WSL2 (Windows Subsystem for Linux), and VS Code.

This article will guide you through setting up a powerful development environment that runs PHP 8.4 in a container while connecting seamlessly to your host Windows MariaDB instance for persistence.

1. Prerequisites: Tools You Need

Before we start coding, ensure you have the necessary components installed:

Windows Subsystem for Linux (WSL2): Required to run a Linux distribution (e.g., Ubuntu) efficiently.
Podman: Installed inside your WSL distribution. This is your container engine.
Podman Compose: The equivalent of docker-compose, installed inside WSL (e.g., via sudo apt install podman-compose).
VS Code: Your main editor on the Windows host.
MariaDB/MySQL: Installed and running directly on your Windows 11 host.
VS Code Extensions:
- PHP Intelephense (For code completion)
- Docker (Useful for managing containers, even Podman, once configured)

Replacing Docker with Podman on Windows

2. Project Structure and Configuration

We'll start by defining the project structure and the two core container files: Dockerfile and docker-compose.yml.

my-php-app/
├── src/
│   └── index.php           # Our main application file
├── Dockerfile              # Defines the PHP container image (PHP 8.4)
├── docker-compose.yml      # Defines how to run the container (Podman Compose)
└── xdebug.ini              # Configuration for PHP debugging

2.1. Defining the PHP 8.4 Container (`Dockerfile`)

This file installs PHP 8.4 with the PDO MySQL extension (required to connect to MariaDB) and sets up Xdebug for debugging in VS Code.

# Use the official PHP image with Apache (httpd)
FROM php:8.4-apache

# Set the working directory in the container
WORKDIR /var/www/html

# Install Xdebug
RUN pecl install xdebug \
    && docker-php-ext-enable xdebug

# Copy Xdebug configuration
COPY xdebug.ini /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini

# Copy application files to the working directory in the container
COPY src/ /var/www/html/

# If you need PDO (for databases)
# RUN docker-php-ext-install pdo pdo_mysql

2.3. Discover the Windows Host IP from WSL (CRITICAL STEP)

The Windows Host IP, as seen from the WSL/Podman network, can change after a reboot. You must determine this address and use it for the database connection and Xdebug.

Open your WSL terminal (e.g., Ubuntu).
Run the following command to find the Windows host's IP address (it's typically the default gateway of the WSL network):
```
ip route | grep default | awk '{print $3}'
```
Note the returned IP address (e.g., 172.20.96.1 or 192.168.x.x). You will use this exact IP in the next step. If you reboot Windows, you may need to run this command again.

2.2. Setting up Xdebug (`xdebug.ini`)

To enable debugging, Xdebug needs to know how to connect back to your VS Code (on the Windows host).

; Enable Xdebug extension
zend_extension=xdebug

; xdebug.ini
xdebug.mode = debug
xdebug.start_with_request = yes
xdebug.client_host = 172.20.96.1
xdebug.client_port = 9003
xdebug.idekey = VSCODE
xdebug.log = /tmp/xdebug.log
xdebug.log_level = 7

3. Connecting to Windows MariaDB and VS Code (The Networking Challenge)

Since Podman runs in WSL2, your container needs a special IP address to reach the Windows host machine for both the database connection and the Xdebug connection.

A. Configure MariaDB for Remote Access (Windows)

Locate your MariaDB configuration file (my.ini or my.cnf) on Windows.
Change the binding address to allow external connections:
```
bind-address = 0.0.0.0
```
Restart the MariaDB service on Windows and ensure your Windows Firewall allows incoming TCP connections on port 3306.

B. Defining Services and Networking (`docker-compose.yml`)

Use the IP address found in Step B for your database connection (DB_HOST).

version: '3.8'

services:
  app:
    build: .
    ports:
      - "8080:80"  # Maps port 8080 on your computer to port 80 in the container
    volumes:
      # Mount the 'src' directory from your PC to the Apache directory
      - ./src:/var/www/html/
    environment:
      # Set the Xdebug client host dynamically
      - XDEBUG_CONFIG=client_host=172.20.96.1 client_port=9003
    extra_hosts:
      - "host.docker.internal:host-gateway"

4. Launching the Environment

Navigate to your project root in the WSL terminal and execute the Podman Compose commands. Since you modified the Dockerfile, you must use the --build flag.

Build and Run:

podman-compose down  # Stop and remove old containers
podman-compose up --build -d # Build new image and start services

Verify PHP Version: Open your browser and go to http://localhost:8080. Your index.php should now confirm PHP 8.4 is running and successfully connecting to MariaDB on your Windows host.

5. Seamless VS Code Development

Thanks to the volume mounting (./src:/var/www/html/), the code editing is simple: you edit files in VS Code on Windows, and the changes appear instantly in the running container.

Debugging with VS Code

The key for debugging is that the xdebug.ini file uses the same IP address (172.20.96.1 in our example) to send the debug signal back to your Windows machine.

In VS Code, go to the Run and Debug tab.
Set a breakpoint in your PHP code.
Click the green play button for the "Listen for Xdebug" configuration (port 9003).
Load your application in the browser. VS Code should automatically halt execution at the breakpoint.

There is a potential issue. The Windows Firewall might be blocking inbound connections to VS Code, preventing XDebug from connecting.

<?php
// Your PHP code
echo "<h1>Hello, world! Running in Podman container with PHP " . phpversion() . "</h1>";

// Debugging test
$message = "Debug test: Xdebug should stop here";
echo "<p>" . $message . "</p>";

// Show some variables for debugging
$numbers = [1, 2, 3, 4, 5];
foreach ($numbers as $number) {
    echo "<p>Number: " . $number . "</p>";
}

// Show Xdebug info
if (extension_loaded('xdebug')) {
    echo "<p style='color: green;'>✅ Xdebug is loaded!</p>";
    echo "<p>Xdebug version: " . phpversion('xdebug') . "</p>";
} else {
    echo "<p style='color: red;'>❌ Xdebug is NOT loaded!</p>";
}
?>

By mastering the networking between the Windows host and the WSL/Podman container, you have created a robust, high-performance, and entirely containerized PHP development environment on Windows 11.

A Concise Guide to Asynchronous Data Flow with C# Channels

Peter Saktor — Tue, 02 Sep 2025 15:11:34 +0000

In modern C# development, synchronization of data exchange between concurrent tasks is a prevalent challenge. While higher-level constructs like Concurrent Queue<T> are thread-safe, they still require manual and error-prone signaling semantics to work optimally in asynchronous contexts.

This is where C# Channels come in. Part of the System.Threading.Channels namespace, Channels offer a powerful and elegantly designed solution for building asynchronous producer-consumer workflows. They provide a high-performance, thread-safe data structure specifically designed for passing data between asynchronous operations.

This concise article will provide a practical introduction to C# Channels, exploring what they are, how to use them, and where they fit best in your applications.

Let's dive into some code to see how Channels work in practice.

What Exactly Are C# Channels?

In essence, a Channel is a data structure that acts as a pipeline between one or more 'consumers' and one or more 'producers.' Producers write to the Channel, and consumers read from the Channel in the order the data was received. This decouples producers from consumers, allowing them to execute independently and concurrently.

The key components of a Channel are:

Channel<T>: The main class, which you create using Channel.CreateBounded<T>(...) or Channel.CreateUnbounded<T>().
ChannelWriter<T>: An interface for writing data into the channel.
ChannelReader<T>: An interface for reading data from the channel.

This write/read separation of concerns is a powerful concept, allowing you to share the 'ChannelWriter' with your producers and the 'ChannelReader' with your consumers, thereby practicing the principle of least privilege.

Channels come in two main varieties:

Unbounded Channels: These have no limit on the number of items they can store. The producer can always write to the channel, but this comes with the risk of high memory consumption if the consumer can't keep up.
Bounded Channels: These have a fixed capacity. If a producer tries to write to a full channel, it will asynchronously wait until space becomes available. This feature, known as backpressure, is crucial for preventing memory overload and creating stable, self-regulating systems.

Getting Started with Channels: Code Examples

Let's dive into some code to see how Channels work in practice.

Example 1: A Basic Producer-Consumer Scenario

Here is a fundamental example where a single producer generates data and a single consumer processes it using an unbounded channel.

using System;
using System.Threading.Channels;
using System.Threading.Tasks;

public class BasicChannelExample
{
    public static async Task Run()
    {
        var channel = Channel.CreateUnbounded<string>();

        // The Producer
        var producer = Task.Run(async () =>
        {
            for (int i = 0; i < 5; i++)
            {
                var message = $"Message {i}";
                await channel.Writer.WriteAsync(message);
                Console.WriteLine($"Produced: {message}");
                await Task.Delay(100); // Simulate work
            }
            // Signal that no more items will be written.
            channel.Writer.Complete();
        });

        // The Consumer
        var consumer = Task.Run(async () =>
        {
            // ReadAllAsync creates an IAsyncEnumerable that completes when the channel is marked complete.
            await foreach (var message in channel.Reader.ReadAllAsync())
            {
                Console.WriteLine($"Consumed: {message}");
                await Task.Delay(150); // Simulate processing
            }
        });

        await Task.WhenAll(producer, consumer);
        Console.WriteLine("Processing has completed.");
    }
}

Key takeaways from this example:

The producer writes items using channel.Writer.WriteAsync().
The consumer reads items efficiently using await foreach on channel.Reader.ReadAllAsync(). This loop waits for new items to arrive and gracefully exits when the channel is completed.
channel.Writer.Complete() is essential. It signals to the reader that production is finished, allowing the consumer's loop to terminate.

Example 2: Bounded Channels and Backpressure

Now, let's see how a bounded channel can regulate a fast producer working with a slower consumer.

using System;
using System.Threading.Channels;
using System.Threading.Tasks;

public class BoundedChannelExample
{
    public static async Task Run()
    {
        // Create a channel with a capacity of only 3 items.
        var channel = Channel.CreateBounded<int>(3);

        var producer = Task.Run(async () =>
        {
            for (int i = 0; i < 10; i++)
            {
                // This call will asynchronously wait if the channel is full.
                await channel.Writer.WriteAsync(i);
                Console.WriteLine($"Produced: {i}");
            }
            channel.Writer.Complete();
        });

        var consumer = Task.Run(async () =>
        {
            await foreach (var item in channel.Reader.ReadAllAsync())
            {
                Console.WriteLine($"-- Consumed: {item}");
                // Simulate slower processing
                await Task.Delay(500);
            }
        });

        await Task.WhenAll(producer, consumer);
        Console.WriteLine("Processing has completed.");
    }
}

When you run this code, you'll observe that the producer writes the first three items and then pauses. It only resumes writing a new item after the consumer has processed one, freeing up a slot in the channel. This automatic backpressure is a core strength of bounded channels.

Common Use Cases for C# Channels

Channels are not merely a theoretical concept; they solve real issues elegantly.

Background Task Processing in ASP.NET Core: A web API endpoint can take a request, write a task to a Channel, and return a 202 Accepted response directly. A singleton IHostedService can act as a long-running consumer, asynchronously taking tasks from the channel in the background without occupying web threads.
Data Processing Pipelines: It is possible to connect multiple channels to create multi-step data pipelines. One segment can read from a network stream and write to a "raw data" channel. Another segment can read from the previous channel, transform the data, and write to a "processed data" channel for ultimate consumption.
High-Throughput In-Memory Buffering: In use cases like logging or event gathering, a channel may be used as an in-memory buffer. Your main application threads can asynchronously and swiftly write log messages to the channel, while a consumer task dedicated solely to this purpose batches and writes them to a file or external service.

Why Choose Channels Over `ConcurrentQueue<T>`?

While ConcurrentQueue<T> is a thread-safe collection, it was not implemented in terms of native asynchronous operations. If you used it in a producer-consumer pattern and avoided blocking the threads, you would need to implement a polling mechanism or some complex signaling system around SemaphoreSlim or AutoResetEvent.

Channels abstract all this complexity away. They are designed specifically for async/await, providing a much cleaner, more efficient, and less error-prone API for asynchronous data exchange.

Conclusion

C# Channels are a fundamental part of modern .NET concurrency programming. They provide a solid, high-performance, and developer-friendly way to manipulate asynchronous data streams. By using the producer-consumer pattern with inherent backpressure support and async/await usage, Channels enable you to write cleaner, more scalable, and more fault-tolerant concurrent code. Whenever you need to move data between asynchronous operations, consider reaching for a Channel.

Time to Live (TTL) in Azure Cosmos DB

Peter Saktor — Mon, 21 Jul 2025 06:58:55 +0000

TTL is a powerful feature that automatically deletes items from a container after a specified time period. This feature helps manage storage, reduce costs, and keep data fresh. Works at both the container and individual item level.

How to set it up

Azure Portal

Open the Azure Portal and navigate to your Cosmos DB account.
In the left-hand menu, go to the Data Explorer.
Expand your database and select the container where you want to apply TTL
Click on Scale & Settings under the selected container.
Go to the Settings tab (as shown in the screenshot).
Under the Time to Live section:
- Select On to enable TTL for the container.
- Optionally, you can:
  - Select "On (no default)" to require TTL per item.
  - Select "On" and enter a value in seconds in the box below to set a default TTL duration for all items.
Click Save at the top to apply your changes.

Azure CLI

az cosmosdb sql container update \
    --account-name <your-account-name> \
    --database-name <your-database-name> \
    --name <your-container-name> \
    --resource-group <your-resource-group> \
    --default-ttl <new-ttl-value>

Replace <your-account-name>, <your-database-name>, <your-container-name>, <your-resource-group>, and <new-ttl-value> with your specific values. Setting default-ttl to -1 enables TTL without a default expiration, 0 disables TTL, and any positive integer sets the default TTL in seconds.

Bicep file

resource cosmosDbAccount 'Microsoft.DocumentDB/databaseAccounts@2021-04-15' = {
  name: 'myCosmosDbAccount'
  location: 'West US'
  kind: 'GlobalDocumentDB'
  properties: {
    consistencyPolicy: {
      defaultConsistencyLevel: 'Session'
    }
    locations: [
      {
        locationName: 'West US'
        failoverPriority: 0
      }
    ]
  }
}

resource cosmosDbDatabase 'Microsoft.DocumentDB/databaseAccounts/sqlDatabases@2021-04-15' = {
  name: '${cosmosDbAccount.name}/myDatabase'
  properties: {
    resource: {
      id: 'myDatabase'
    }
  }
}

resource cosmosDbContainer 'Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers@2021-04-15' = {
  name: '${cosmosDbDatabase.name}/myContainer'
  properties: {
    resource: {
      id: 'myContainer'
      partitionKey: {
        paths: ['/myPartitionKey']
        kind: 'Hash'
      }
      defaultTtl: -1  // TTL set to "On (no default)"
    }
  }
}

The defaultTtl attribute for Azure Cosmos DB containers can have the following values:

-1: This value enables TTL without a default expiration time. You can then set the TTL for individual documents within the container.
0: This value disables TTL for the container.
Positive Integer: Any positive integer value sets the default TTL in seconds for all documents in the container. For example, a value of 3600 sets the default TTL to 1 hour.

How ttl and _ts attribute interact

_ts attribute is a system-generated timestamp that records the last modification time of a document in seconds since the Unix epoch (January 1, 1970). It helps track when a document was last updated.

When a document is created or modified, the _ts value is updated to the current time.
The ttl value is set to define how long the document should be retained.
Cosmos DB periodically checks the _ts value against the ttl value. If the difference between the current time and the _ts value exceeds the ttl value, the document is marked for deletion.

This mechanism ensures that documents are automatically cleaned up based on their age and the specified ttl value, helping manage storage and maintain data freshness.

There is no guarantee that items will be deleted exactly at the TTL expiration time. Cosmos DB performs background deletion of expired items. This process is asynchronous, meaning the items are not deleted immediately after the TTL expires. The actual deletion time can vary based on factors like container throughput and the volume of expired items.

Summary

Time to Live (TTL) in Azure Cosmos DB is a valuable feature for automating data lifecycle management. By enabling TTL, you can ensure that outdated or unnecessary documents are automatically deleted after a specified period, helping to optimize storage costs and maintain performance.

Additional Resources

For more in-depth guidance and the latest updates on TTL in Azure Cosmos DB, refer to the official Microsoft documentation:

https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/time-to-live

https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/how-to-time-to-live?tabs=dotnet-sdk-v3

Build a Simple MCP Server and Client in C#

Peter Saktor — Fri, 20 Jun 2025 16:00:46 +0000

What is MCP?

The Model Context Protocol (MCP) is a standardized way for AI systems to access and interact with various external resources file systems, databases, APIs, and other services. Instead of writing unique connectors for each integration, MCP provides a unified interface that any compliant system can use.

By using MCP, developers can empower AI agents to discover, retrieve, and act upon information regardless of the underlying technology. This abstraction allows developers to focus more on what the system does rather than how it connects to the data.

Core MCP Primitives

MCP is built around three key concepts:

1. Resources

These represent any external data the AI agent might need to access: documents, images, files, databases, and so on.

Consistent Access: Agents use a unified interface to request any resource.
Always Up to Date: The system ensures access to the latest information.
Abstracted Complexity: Developers don’t need to write custom code for every data source.

2. Tools

Tools represent the functions or operations that the AI agent can invoke to perform specific tasks like fetching data, editing files, processing content, and more.

Action Oriented: Agents don’t just read data, they can also modify or trigger workflows.
Dynamic Selection: Agents can dynamically discover and choose the right tool based on context.

3. Prompts

Prompts are structured templates or instructions that define how AI agents interact with tools and resources.

Guided Interactions: Prompts ensure all requests are formatted correctly.
Context Management: Agents maintain coherent interaction across multiple operations.
Clarity: Standardized prompts reduce ambiguity and misinterpretation.

Together, these primitives allow agents to operate intelligently and autonomously in a modular system.

MCP Architecture: Client-Server Model

MCP is designed using a client-server model:

The Client (typically the AI agent) sends structured requests, which include prompts and resource identifiers.
The MCP Server processes these requests, maintains context, and returns results.

This separation ensures scalability, security, and flexibility across various applications.

C# SDK for MCP

To support .NET developers, there is a C# SDK available on GitHub:

👉 MCP SDK for C#

This SDK simplifies the process of integrating your AI agents with an MCP server, handling serialization, request/response formats, and context management.

Sample Solution: Simple MCP Server and Client

To demonstrate how MCP works in practice, I’ve created a minimalistic MCP solution in C#:

📁 GitHub Repository: petersaktor/mcp

The solution includes both a server and a client, showing how to:

Define and expose tools on the server side
Send prompts and interact with resources
Log and handle results returned from the MCP server

MCP Server

Program.cs

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

Console.WriteLine("Hello, MCP Simple server!");

var builder = Host.CreateApplicationBuilder(args);
builder.Logging.AddConsole(consoleLogOptions =>
{
    // Configure all logs to go to stderr
    consoleLogOptions.LogToStandardErrorThreshold = LogLevel.Trace;
});

builder.Services
    .AddMcpServer()
    .WithStdioServerTransport()
    .WithPromptsFromAssembly()
    .WithToolsFromAssembly()
    .WithResourcesFromAssembly();

await builder.Build()
    .RunAsync();

SimplePrompt.cs

using Microsoft.Extensions.AI;
using ModelContextProtocol.Server;
using System.ComponentModel;

namespace SimpleServer.Prompts;

[McpServerPromptType]
public static class SimplePrompt
{
    [McpServerPrompt, Description("Creates a prompt to summarize the provided message.")]
    public static ChatMessage Summarize(string content) =>
        new(ChatRole.User, $"Please summarize this content into a single sentence: {content}");
}

SimpleTool.cs

using ModelContextProtocol.Server;
using System.ComponentModel;

namespace SimpleServer.Prompts;

[McpServerToolType]
public static class SimpleTool
{
    [McpServerTool, Description("Returns the current time for the specified time zone.")]
    public static string GetCurrentTime(string timeZone)
    {
        try
        {
            var tz = TimeZoneInfo.FindSystemTimeZoneById(timeZone);
            var now = TimeZoneInfo.ConvertTimeFromUtc(DateTime.UtcNow, tz);
            return now.ToString("o"); // ISO 8601 format
        }
        catch (TimeZoneNotFoundException)
        {
            return $"Time zone '{timeZone}' not found.";
        }
        catch (InvalidTimeZoneException)
        {
            return $"Time zone '{timeZone}' is invalid.";
        }
    }
}

SimpleResource.cs

using ModelContextProtocol.Server;
using System.ComponentModel;

namespace SimpleServer.Prompts;

[McpServerResourceType]
public static class SimpleResource
{
    [McpServerResource, Description("Returns the Bing endpoint URL.")]
    public static string GetBingEndpoint() => "https://bing.com";
}

MCP Client

Program.cs

using ModelContextProtocol.Client;
using ModelContextProtocol.Protocol;

Console.WriteLine($"Hello, MCP Simple client!");

// Create the stdio transport (using current process's stdin/stdout)
var transport = new StdioClientTransport(new StdioClientTransportOptions
{
    Name = "MCP Simple Client",
    Command = "..\\..\\..\\..\\SimpleServer\\bin\\Debug\\net8.0\\SimpleServer.exe",
    // The command to start the MCP server process
    // If the server is already running, you can use the same command as the server
    // If you want to use a different command, specify it here
});

try
{
    // Create the MCP client
    var client = await McpClientFactory.CreateAsync(cancellationToken: default, clientTransport: transport);

    // List available prompts from the server
    foreach (var pr in await client.ListPromptsAsync())
    {
        Console.WriteLine($"Available prompt: {pr.Name} - {pr.Description}");
    }

    // Specify the prompt you want to use
    var promptName = "Summarize";

    // Create a dictionary of arguments for the prompt
    IReadOnlyDictionary<string, object> promptArguments = new Dictionary<string, object>()
    {
       { "content", "ModelContextProtocol enables structured communication." }
    };

    // Get the prompt from the server using the specified name and arguments
    var prompt = await client.GetPromptAsync(promptName, promptArguments!);
    if (prompt == null)
    {
        Console.WriteLine($"Prompt '{promptName}' not found.");
        return;
    }

    // Print the prompt details
    foreach (var message in prompt.Messages)
    {
        Console.WriteLine($"Message Role: {message.Role}, Content: {message.Content?.Text}");
    }

    // List available tools from the server
    foreach (var to in await client.ListToolsAsync())
    {
        Console.WriteLine($"Available tool: {to.Name} - {to.Description}");
    }

    // Specify the tool you want to use
    var toolName = "GetCurrentTime";

    // Create a dictionary of arguments for the tool
    IReadOnlyDictionary<string, object> toolArguments = new Dictionary<string, object>()
    {
        { "timeZone", "Pacific Standard Time" } // Example time zone
    };

    // Call tool from the server using the specified name and arguments
    var result = await client.CallToolAsync(toolName, toolArguments!);
    if (result == null)
    {
        Console.WriteLine($"Tool '{toolName}' not found.");
        return;
    }

    // Print the tool result
    foreach (var res in result.Content)
    {
        Console.WriteLine($"Tool Result: {res.Text}");
    }

    // List available resources from the server
    foreach (var res in await client.ListResourcesAsync())
    {
        Console.WriteLine($"Available resource: {res.Name} - {res.Description}");
    }

    // Specify the resource you want to use
    var resourceName = "resource://GetBingEndpoint";

    // Get the resource from the server using the specified name
    var resource = await client.ReadResourceAsync(resourceName);
    if (resource == null)
    {
        Console.WriteLine($"Resource '{resourceName}' not found.");
        return;
    }

    // Print the resource details
    foreach (var res in resource.Contents)
    {
        Console.WriteLine($"Resource Content: {((TextResourceContents)res)?.Text}");
    }
}
catch (Exception ex)
{
    Console.WriteLine("Error creating MCP client: " + ex.Message);
    return;
}

Summary

MCP brings a new level of consistency and modularity to AI integrations. With a simple but powerful abstraction using Resources, Prompts, and Tools, and a clean client-server model, you can build intelligent agents that interact seamlessly with the outside world.

Explore more:

Avoid Memory Leaks in Angular When Using takeUntil with Higher-Order RxJS Operators

Peter Saktor — Sun, 18 May 2025 10:30:44 +0000

When working with Angular and RxJS, takeUntil is a common operator for unsubscribing from observables, especially in component lifecycle management. However, if you're using takeUntil incorrectly with higher-order mapping operators like mergeMap, switchMap, concatMap, exhaustMap, you may still end up with memory leaks.

The Problem

A common mistake is placing takeUntil before a higher-order operator in your observable pipeline. This seems logical, but it doesn't always behave as expected. When takeUntil is upstream of a higher-order operator, it won't effectively unsubscribe the inner subscription created by that operator.

❌ Problematic Pattern

this.counterB$.pipe(
  takeUntil(this.destroySubject),
  mergeMap((value) => this.counterA$)
).subscribe(...);

In the example above, the outer observable (counterB$) is unsubscribed, but the inner observable (counterA$ from mergeMap) continues to emit values even after the component is destroyed. That’s your memory leak!

Why It Happens

Higher-order operators return new inner observables. If takeUntil is applied before them, it only stops the outer observable. But the inner one lives on.

The Correct Pattern

To ensure both outer and inner subscriptions are cleaned up properly, place takeUntil after the higher-order operator.

✅ Recommended Pattern

this.counterA$.pipe(
  mergeMap((value) => this.counterB$),
  takeUntil(this.destroySubject),
).subscribe(...);

In this corrected example, the whole observable chain, including inner subscriptions, is properly unsubscribed when the destroySubject emits.

Real-World Example

Service Providing Observables

@Injectable({ providedIn: 'root' })
export class TakeUntilLeakChildService {
  counterA$ = interval(2000);
  counterB$ = interval(1000);
}

Component Subscription

@Component({
  selector: 'app-take-until-leak-child',
  imports: [],
  templateUrl: './take-until-leak-child.component.html',
  styleUrl: './take-until-leak-child.component.scss'
})
export class TakeUntilLeakChildComponent implements OnInit, OnDestroy {

  counterService = inject(TakeUntilLeakChildService);

  counterA$ = this.counterService.counterA$;
  counterB$ = this.counterService.counterB$;

  destroySubject = new Subject();

  ngOnInit(): void {
    this.counterA$.pipe(
      mergeMap((value) => {
        return this.counterB$;
      }),
      takeUntil(this.destroySubject),
    ).subscribe((value) => {
      console.log('Counter A:', value);
    });

    this.counterB$.pipe(
      takeUntil(this.destroySubject),
      mergeMap((value) => {
        return this.counterA$;
      }),
    ).subscribe((value) => {
      console.log('Counter B:', value);
    });
  }

  ngOnDestroy(): void {
    console.log('Child component destroyed!');
    this.destroySubject.next(true);
    this.destroySubject.complete();
  }
}

Console Observation

When inspecting the console, you may find that:

counterA$ is unsubscribed correctly.
counterB$ continues to emit values even after component destruction - memory leak.

Related Note on `takeUntilDestroyed`

The same principle applies when using Angular's takeUntilDestroyed operator. If you're using takeUntilDestroyed with higher-order mapping operators, make sure it is placed after those operators to properly unsubscribe inner observables and avoid memory leaks.

Summary

To prevent memory leaks:

Always place takeUntil (or takeUntilDestroyed) after higher-order operators.
Understand that mergeMap, switchMap, concatMap, and exhaustMap create inner observables that need cleanup.

Happy coding!

Avoiding Performance Mistakes with Angular's Async Pipe

Peter Saktor — Sat, 29 Mar 2025 07:33:57 +0000

The async pipe is a powerful feature in Angular that helps manage subscriptions automatically. However, improper usage can lead to performance bottlenecks. In this article, we'll explore a common mistake developers make when using the async pipe and how to avoid it.

The Problem: Unnecessary Subscriptions Inside Loops

Consider the following problematic code:

@for (item of items; track item.id) {
  <user-item [user]="user$ | async" [item]="item"></user-item>
}

At first glance, this might seem fine. However, let's examine how the async pipe works internally.

How the Async Pipe Works

When you pass an observable to the async pipe, Angular creates a subscription:

this._subscribe(obj);

Here's how the transform method is implemented:

transform<T>(obj: Observable<T> | Subscribable<T> | Promise<T> | null | undefined): T | null {
  if (!this._obj) {
    if (obj) {
      try {
        this.markForCheckOnValueUpdate = false;
        this._subscribe(obj); // Creates a subscription
      } finally {
        this.markForCheckOnValueUpdate = true;
      }
    }
    return this._latestValue;
  }

  if (obj !== this._obj) {
    this._dispose();
    return this.transform(obj);
  }

  return this._latestValue;
}

The subscription is assigned to _subscription:

private _subscribe(obj: Subscribable<any> | Promise<any> | EventEmitter<any>): void {
  this._obj = obj;
  this._strategy = this._selectStrategy(obj);
  this._subscription = this._strategy.createSubscription(
    obj,
    (value: Object) => this._updateLatestValue(obj, value),
    (e) => this.applicationErrorHandler(e)
  );
}

Each time the async pipe is used, it creates a new subscription and updates the view:

private _updateLatestValue(async: any, value: Object): void {
  if (async === this._obj) {
    this._latestValue = value;
    if (this.markForCheckOnValueUpdate) {
      this._ref?.markForCheck(); // Triggers change detection
    }
  }
}

Why is This a Problem?

Using the async pipe inside a loop means that a new subscription is created for each iteration, leading to multiple unnecessary change detection triggers. This can severely impact performance.

The Solution: Using Async Pipe Outside the Loop

Instead of using the async pipe inside the loop, extract its value beforehand using *ngIf, the @if directive, or the let syntax in Angular's newer syntax:

Correct Approach 1: Using Let Syntax

@let user = users$ | async;
@for (item of items; track item.id) {
  <user-item [user]="user" [item]="item"></user-item>
}

Correct Approach 2: Using *ngIf

<ng-container *ngIf="users$ | async as user">
  <ng-container *ngFor="let item of items; trackBy: trackById">
    <user-item [user]="user" [item]="item"></user-item>
  </ng-container>
</ng-container>

trackById(index: number, item: any): any {
  return item.id;
}

Conclusion

Using the async pipe correctly can significantly improve performance in Angular applications. Avoid placing it inside loops and instead extract the observable value beforehand to prevent unnecessary subscriptions and change detection cycles. By following these best practices, you can ensure your application remains efficient and responsive.

For more information, check out the Angular async pipe implementation on GitHub.

Happy coding!

Replacing Docker with Podman on Windows

Peter Saktor — Tue, 11 Mar 2025 08:59:10 +0000

If you're looking for a lightweight and daemonless alternative to Docker on Windows, Podman is a great choice. This guide walks you through installing Podman on Windows, setting up Podman Compose, and configuring it to work seamlessly with the Docker CLI.

1. Installing Podman Desktop and Podman on Windows

Podman provides a user-friendly desktop application along with the command-line tool. To install it:

Navigate to the official Podman Desktop installation guide.
Follow the instructions to download and install Podman Desktop and Podman CLI.

After installation, ensure that Podman is added to your system PATH and verify the installation:

podman --version

2. Setting Up Podman Compose

Podman Compose allows you to run multi-container applications using docker-compose.yml files. To set it up:

Follow the official Podman Compose setup guide.
Verify the installation:

   podman-compose --version

3. Installing Docker CLI

While Podman provides a Docker-compatible command-line interface, some tools may still require the Docker CLI. You can install it using Windows Package Manager winget:

winget install Docker.DockerCLI

4. Creating a Symlink for Docker Compatibility

To make the Docker CLI use Podman under the hood, create a symbolic link:

Open a PowerShell console and navigate to the WinGet links directory:

   cd C:\Users\<currentuser>\AppData\Local\Microsoft\WinGet\Links

Rename the original Docker executable:

   rename docker.exe docker-ori.exe

Create a symbolic link to the Podman executable:

   New-Item -ItemType SymbolicLink -Path "docker.exe" -Target "C:\Program Files\RedHat\Podman\podman.exe"

Replace <currentuser> with your actual Windows username.

5. Configuring User Permissions

To ensure Podman works properly with the Docker CLI, verify and configure the docker-users group:

Check Available Local Groups: Run the following command to list all local groups:

   net localgroup

Look for docker-users in the list.

Create the 'docker-users' Group (if it doesn't exist): If the docker-users group is not listed, create it using:

   net localgroup docker-users /add

Add Your User to 'docker-users' Group: Run the following command, replacing YourUsername with your actual Windows username:

   net localgroup docker-users YourUsername /add

Log Out and Log Back In This ensures that the group changes take effect.

6. Restart Windows

To ensure all changes take effect, restart your system.

7. Verify Docker Compatibility

After restarting, open PowerShell and check if the docker command now points to Podman:

docker --version

If everything is set up correctly, you should see a version message from Podman.

Conclusion

Congratulations! You've successfully replaced Docker with Podman on Windows. This setup allows you to run containerized applications while maintaining compatibility with existing Docker-based workflows.

For more details, refer to the official Podman documentation.

Handling Concurrency in CosmosDB with ETags

Peter Saktor — Wed, 08 Jan 2025 06:50:59 +0000

Handling Concurrency in CosmosDB with ETags

When working with distributed systems and databases like Azure CosmosDB, concurrency can be a tricky problem to handle effectively. Without proper safeguards, simultaneous updates to the same data can lead to conflicts and data corruption. Fortunately, CosmosDB provides a built-in mechanism to manage concurrency through ETags (Entity Tags).

In this post, we'll explore what ETags are, how they work in CosmosDB, and how you can leverage them to solve concurrency issues in your applications.

What is an ETag?

An ETag is a string value automatically maintained by CosmosDB for every document. It represents the version of the document at a given point in time. Every time a document is modified, its ETag value changes.

Think of it as a fingerprint of the document's current state:

Before an update: The ETag represents the state of the document before the modification.
After an update: A new ETag is generated, reflecting the updated state.

The Concurrency Challenge

In a typical scenario, two or more clients may attempt to read and update the same document at the same time. Without a mechanism to manage these simultaneous updates, one client's changes may overwrite the other's, leading to lost updates.

Here’s an example:

Client A reads a document with ETag abc123.
Client B reads the same document with ETag abc123.
Both clients modify the document and send their updates back to CosmosDB.

Without checking the ETag, the last update (whichever arrives later) overwrites the first, discarding any intermediate changes.

How ETags Solve Concurrency

To address this, CosmosDB allows you to implement optimistic concurrency control using ETags. When updating a document, you can specify the ETag value you expect the document to have. If the document’s current ETag doesn't match the one provided in your request, CosmosDB will reject the update with a precondition failure.

Workflow:

Read the document: Fetch the document along with its current ETag.
Modify the document: Make your changes locally.
Update with ETag: Include the ETag in the update request as a precondition.
CosmosDB validates:
- If the ETag matches: The update succeeds.
- If the ETag doesn’t match: The update fails, signaling a conflict.

Implementation in Code

Let’s look at a practical example using the Azure CosmosDB SDK for .NET:

Fetching the Document

var container = cosmosClient.GetContainer("databaseId", "containerId");

// Read the document
var response = await container.ReadItemAsync<dynamic>("documentId", new PartitionKey("partitionKeyValue"));
var document = response.Resource;

// Store the ETag
string etag = response.ETag;

Updating with ETag

// Modify the document
document["propertyToUpdate"] = "newValue";

// Prepare the request options with ETag
var requestOptions = new ItemRequestOptions
{
    IfMatchEtag = etag // Specify the expected ETag
};

try
{
    // Attempt the update
    var updateResponse = await container.ReplaceItemAsync(document, "documentId", new PartitionKey("partitionKeyValue"), requestOptions);
    Console.WriteLine("Update succeeded!");
}
catch (CosmosException ex) when (ex.StatusCode == System.Net.HttpStatusCode.PreconditionFailed)
{
    Console.WriteLine("Concurrency conflict detected. Update failed.");
}

Key Scenarios Where ETags Shine

Preventing Lost Updates: By validating the ETag before applying updates, you ensure no intermediate changes are overwritten.
Conflict Resolution: If a conflict occurs, you can re-fetch the document, merge changes, and retry the update.
Auditing Changes: Use ETags to identify when documents have been modified and by whom (alongside other metadata).

Best Practices

Use Partition Keys: Always include the correct partition key when working with CosmosDB to optimize performance.
Handle Precondition Failures Gracefully: Design your application to retry updates or prompt users to resolve conflicts.
Log ETag Values: Maintain a history of ETags for debugging and auditing purposes.

Conclusion

Concurrency is a common challenge in distributed databases, but CosmosDB’s ETag mechanism provides a simple and effective way to manage it. By adopting optimistic concurrency control with ETags, you can safeguard your data integrity and create more resilient applications.

Practical example

using System;
using System.Net;
using System.Threading.Tasks;
using Microsoft.Azure.Cosmos;

namespace Infrastructure.CosmosDB
{
    public static class CosmosDBConcurrencyWrapper
    {
        public static async Task<string?> GetItemEtagAsync(string? id, PartitionKey partitionKey, Container container)
        {
            ArgumentNullException.ThrowIfNull(container, nameof(container));

            if (string.IsNullOrEmpty(id))
            {
                return null;
            }

            try
            {
                ItemResponse<dynamic> response = await container.ReadItemAsync<dynamic>(id, partitionKey);
                return response.ETag;
            }
            catch (CosmosException ex) when (ex.StatusCode == HttpStatusCode.NotFound)
            {
                return null;
            }
        }

        public static async Task<Tuple<ItemResponse<T>, bool>> TryUpsertItemAsync<T>(PartitionKey partitionKey, T item, Container container, string? etag)
        {
            ArgumentNullException.ThrowIfNull(container, nameof(container));
            ArgumentNullException.ThrowIfNull(item, nameof(item));

            try
            {
                ItemResponse<T> response = await container.UpsertItemAsync(item, partitionKey, new ItemRequestOptions { IfMatchEtag = etag });
                return new(response, response.StatusCode == HttpStatusCode.OK);
            }
            catch (CosmosException ex) when (ex.StatusCode == HttpStatusCode.PreconditionFailed)
            {
                throw new ConcurrencyException(ex);
            }
        }       
    }

    public class ConcurrencyException : Exception
    {
        public ConcurrencyException()
        {
        }

        public ConcurrencyException(string message)
            : base(message)
        {
        }

        public ConcurrencyException(string message, Exception inner)
            : base(message, inner)
        {
        }

        public ConcurrencyException(Exception inner)
            : base("Concurrency problem detected", inner)
        {
        }
    }
}

DEV Community: Peter Saktor

GitHub Spec-Kit: From Vibe Coding to Spec-Driven Development

What is Spec-Kit?

Why use it?

Benefits

Getting Started with Spec-Kit

Create a new project

Use it in an existing project

The Development Cycle

Real-World Demo: Refactoring an Azure Container App

Step 1: The Constitution Command

Step 2: The Specify Command

Step 3: The Clarify Command (Optional but Valuable)

Step 4: The Plan Command

Step 5: The Tasks Command

Step 6: The Analyze Command (Optional but Recommended)

Step 7: The Implement Command

Add a new feature

When Should You Use Spec-Kit?

The Future of Spec-Kit

Automatic Prompt Optimization: When AI Learns to Improve Its Own Prompts

The Challenge We All Face

What is Automatic Prompt Optimization?

The Core Concept

System Architecture

Key Components:

Implementation Deep Dive

The PromptOptimizer Class

Generating Smart Variations

Evaluating Prompt Quality

Smart Recovery When Stuck

Running the System

Sample Output

Real-World Applications

1. Content Generation Pipelines

2. Code Generation

3. Customer Support

4. Educational Content

5. Data Analysis

Production Considerations

Rate Limiting

Retry Logic

Cost Management

Beyond Basic Optimization

Want to Go Deeper?

Get Started Today

Final Thoughts

Visual Studio 2026 is the new IDE and agent cloud management with the built-in Azure MCP server

Understanding the Built-in Azure MCP Server

Configuring the Azure MCP Server Integration

Step 1: Visual Studio Workload Installation

Step 2: Authentication via Azure CLI and Azure Developer CLI

➡️ Utilizing the Azure CLI (az) for Authentication

➡️ Integration with Azure Developer CLI (azd)

Step 3: Operational Usage via GitHub Copilot

Modern PHP on Windows 11: VS Code, Podman, and MariaDB

1. Prerequisites: Tools You Need

2. Project Structure and Configuration

2.1. Defining the PHP 8.4 Container (Dockerfile)

2.3. Discover the Windows Host IP from WSL (CRITICAL STEP)

2.2. Setting up Xdebug (xdebug.ini)

3. Connecting to Windows MariaDB and VS Code (The Networking Challenge)

A. Configure MariaDB for Remote Access (Windows)

B. Defining Services and Networking (docker-compose.yml)

4. Launching the Environment

5. Seamless VS Code Development

Debugging with VS Code

A Concise Guide to Asynchronous Data Flow with C# Channels

What Exactly Are C# Channels?

Getting Started with Channels: Code Examples

Example 1: A Basic Producer-Consumer Scenario

Example 2: Bounded Channels and Backpressure

Common Use Cases for C# Channels

Why Choose Channels Over ConcurrentQueue<T>?

Conclusion

Time to Live (TTL) in Azure Cosmos DB

How to set it up

Azure Portal

Azure CLI

Bicep file

➡️ Utilizing the Azure CLI (`az`) for Authentication

➡️ Integration with Azure Developer CLI (`azd`)

2.1. Defining the PHP 8.4 Container (`Dockerfile`)

2.2. Setting up Xdebug (`xdebug.ini`)

B. Defining Services and Networking (`docker-compose.yml`)

Why Choose Channels Over `ConcurrentQueue<T>`?

Related Note on `takeUntilDestroyed`