标签：#csharp

Ask Crysta — the AI agent on CrystaCode.ai — to switch the site to dark mode, and the site actually turns dark. Ask it to show the login popup, and the modal actually opens. The model doesn't just answer anymore; it operates the UI. But here's the thing: the LLM lives on the server , and the UI lives in the browser . A model can't click buttons. So how do you give a remote brain hands? The answer is a pattern we ended up calling the Client Driver Skill : function calling, with SignalR as the hand. The Problem The first version of our chat was a one-way street. The model could say "sure, I'll take you to the plans page" — and then nothing happened. The answer was text; the UI was deaf. You have two classic options: The client polls the server for commands (ugly, wasteful, feels like 2010) The server pushes commands to the client (real-time, instant, exactly what SignalR is for) We went with the push. The flow became: the model calls a function → the function runs on the server → the server pushes a typed command over SignalR → the client executes it. How It Works (The Full Loop) [Browser] [Server] | | | 1. "switch to dark mode" | | ---- InvokeAsync ---------> | | | 2. Brain runs, model sees | | the UpdateSiteTheme tool | | 3. Model calls the function | | (function calling) | | 4. Push to the exact tab: | <--- ChangeSiteTheme ------ | Clients.Client(connId) | 5. ThemeService flips it | | 6. "Site theme changed..." | 5b. return value re-enters | | the model's context | <--- chat answer ---------- | User types "switch to dark mode" → the Blazor client calls the hub The server session runs the brain; the model sees a tool called UpdateSiteTheme The model decides the user wants dark mode and calls the function The server pushes ChangeSiteTheme(DarkMode) to the exact browser connection The client applies the theme and re-renders The function's return value goes back into the model's context, so the AI knows the theme changed and confirms it in the chat 1) The Client Regist

Every couple of weeks I need a twenty-line program. Find what's bloating a build agent's disk, dedupe a CSV, hash-check a folder. For fifteen years the honest answer to "which language?" was not C# — by the time I'd done mkdir , dotnet new console , and named yet another throwaway csproj, the moment had passed. So those little jobs went to bash or Python, and I grumbled quietly every time. .NET 10 removed the ritual. You write one .cs file and run it. I'd been meaning to check how well this actually holds up for real scripts, so this week I did — nothing fancy, one Linux container and a stopwatch. One file, no project Here's biggest.cs , a small utility that lists the largest files under a directory. The whole program is this one file — no csproj anywhere: # !/ usr / bin / env dotnet # : package Humanizer @ 3.0 . 10 using Humanizer ; var root = args . Length > 0 ? args [ 0 ] : "." ; var top = args . Length > 1 && int . TryParse ( args [ 1 ], out var n ) ? n : 10 ; var files = new DirectoryInfo ( root ) . EnumerateFiles ( "*" , new EnumerationOptions { RecurseSubdirectories = true , IgnoreInaccessible = true , AttributesToSkip = FileAttributes . ReparsePoint }) . OrderByDescending ( f => f . Length ) . Take ( top ) . ToList (); foreach ( var f in files ) { var size = f . Length . Bytes (). Humanize ( "#.#" ); var age = ( DateTime . UtcNow - f . LastWriteTimeUtc ). Humanize (); Console . WriteLine ( $" { size , 10 } { f . FullName } (modified { age } ago)" ); } Two lines are new. #:package Humanizer@3.0.10 is a NuGet reference written as a directive, right in the source. The shebang we'll get to in a minute. Everything else is the C# you already write, top-level statements and all. $ dotnet run biggest.cs -- ~/.dotnet 5 Top 5 files under /root/.dotnet: 37.6 MB .../FSharp.Compiler.Service.dll (modified 46 seconds ago) 18.7 MB .../Microsoft.CodeAnalysis.CSharp.dll (modified 46 seconds ago) 18.7 MB .../Roslyn/bincore/Microsoft.CodeAnalysis.CSharp.dll (modified 45 seconds

Hey everyone, I'm excited to share my brand-new C# Crash Course for Beginners on YouTube! 🎉 For those of you who are new here, I'm Amir, a software developer who enjoys learning new technologies and creating programming tutorials that are practical, beginner-friendly, and straight to the point. If you've been thinking about learning C#, this course is the perfect place to start. C# is one of the most popular programming languages in the world and is widely used for desktop applications, web development with ASP.NET, cloud services, game development with Unity, and enterprise software. Combined with the power of the .NET ecosystem, it provides an excellent foundation for building modern applications. In this one-hour crash course, we'll start from the very beginning by setting up the .NET development environment and learning the essential command-line tools. From there, we'll gradually build our understanding of the language through practical demonstrations and live coding examples. Throughout the course, you'll learn: How to install and configure the .NET SDK Using the .NET CLI and .NET Script Variables and data types String interpolation Arithmetic, comparison, and logical operators Conditional statements Loops Methods and functions Arrays and collections Lists, Dictionaries, and HashSets LINQ fundamentals Classes, objects, and Object-Oriented Programming (OOP) Records and modern C# features Pattern Matching You'll also get a preview of a real-world application that we'll build together in a future tutorial series, showing how these concepts come together in an actual project. This course focuses on building a strong understanding of C# fundamentals. Topics such as asynchronous programming with async and await are intentionally left for a dedicated tutorial, where we can explore them properly with practical examples. Whether you're completely new to programming or coming from another language like Java, Python, JavaScript, Go, or Rust, I hope this course helps make

In post 10 I closed the composition-versus-coherence question with one paragraph: I kept strict object-scoping, reserved an Inline operator for later, and rejected automatic reach-down. That was true, and it was too fast. A reader told me the reserved operator was not clear from a sentence, which is fair. A design record that asserts a decision without showing it is not really a record. So here is the seam, worked out. First, the good news that made this only one seam and not ten: composition and coherence mostly do not collide. Composition substitutes complex types ; coherence binds scalar facets ; those are disjoint kinds of member. A collection gives one persona per element. Draw order falls out of the eager construction rule from post 7. And the resolver pipeline I pre-paid for back in post 4 turned out to be coherence's host. The two threads layer cleanly almost everywhere. Almost. The discontinuity Coherence is object-scoped (post 5). That one rule has a consequence that only shows up once you have composition encouraging you to split a type across nested objects: moving a facet into a child changes whether it coheres. // Flat: Email is a Person facet, so it coheres with the name. Customer { FirstName , LastName , Email } // -> "Maria", "Gonzalez", "maria.gonzalez@..." // Decomposed: Contact is its own scope. A lone Email there does not activate a // persona (one corroborating member, no name anchor), so it is a plain, unrelated email. Customer { FirstName , LastName , Contact : ContactInfo { Email } } // -> "Maria", "Gonzalez", "rwilson@..." Same three fields, same intent, different result, decided entirely by which object they live on. That is the discontinuity. The options A, strict: object-scoping stays. The decomposed email does not cohere. Maximally predictable. The gap is the already-deferred cross-entity work. B, reach-down: a child with no entity of its own is absorbed into the parent scope. The email coheres. But "absorbed or not" now depends on hidd

Parking and matching puzzles look almost insultingly simple from the outside. A few cars, a cramped lot, tap or drag to move them out. But if you've actually tried to build one that feels tight — no janky collision resolution, no ambiguous "why didn't that move register" moments, no lag once the board gets crowded — you know there's a real systems design problem hiding underneath what looks like a weekend project. I recently went through the architecture of a parking/matching hybrid template built in Unity and wanted to break down the core systems the way I'd want them explained if I were reskinning or extending one myself. This isn't a marketing post — it's a walkthrough of the actual mechanics: how vehicle movement and collision resolution work, how the match/clear pipeline is structured, how level data is separated from movement logic so hundreds of levels don't require touching code, and how monetization hooks slot into natural break points without polluting gameplay scripts. If you want to see the finished product this breakdown is loosely based on, there's a working template here: Park Match Unity Game Template . Everything below applies whether you're building something similar from scratch or extending an existing base. Why Parking Puzzles Are Harder Than They Look The core loop — tap or drag a vehicle, it exits along a valid path, the lot clears one piece at a time — is trivial to describe and genuinely fiddly to implement well. Four problems show up almost immediately once you move past a static mockup: Valid-move detection : how do you know, at any given moment, which vehicles can actually move given their orientation and the current board state? Path resolution : once a vehicle starts moving, how does it navigate around other vehicles and obstacles without clipping through them or getting stuck mid-animation? Match/clear logic : when does a vehicle actually "clear" the board — on reaching an exit, on matching color/type with another vehicle, or both — an

Hello everyone! After publishing my Machine Learning with ML.NET series, I decided to turn the recommendation model into a complete application. In this new series, we build RockPlayer, a rock music player that combines modern software architecture, ASP.NET Core, Angular 22, Redis, and YouTube integration. Each article focuses on a different part of the project: 🎵 1. Introducing RockPlayer An overview of the project, its goals, and the overall architecture. https://devfullstack.net/blog/introducing-rockplayer 🔌 2. Adapters: Isolating the YouTube Provider Using the Adapter pattern to decouple the application from the YouTube integration. https://devfullstack.net/blog/adapters-isolating-the-youtube-provider ⚡ 3. No Database: Caching Lookups with Redis Using Redis to cache search results instead of storing external data in a database. https://devfullstack.net/blog/no-database-caching-lookups-with-redis 🅰️ 4. Angular 22 in Practice Applying modern Angular 22 features to build the user interface. https://devfullstack.net/blog/angular-22-in-practice 🚀 5. Building the RockPlayer API Building the API that orchestrates the application. https://devfullstack.net/blog/building-the-rockplayer-api ▶️ 6. The YouTube Adapter: Finding and Playing the Song Implementing the YouTube integration to search for and play songs. https://devfullstack.net/blog/the-youtube-adapter-finding-and-playing-the-song 🎧 7. RockPlayer in Angular 22: Onboarding Setting up the Angular application and organizing the project structure. https://devfullstack.net/blog/rockplayer-in-angular-22-onboarding 🎸 8. RockPlayer: Putting It All Together Bringing all the components together into a complete application. https://devfullstack.net/blog/rockplayer-putting-it-all-together I hope this series is useful for developers interested in software architecture, .NET, and Angular. See you there!

Let's get the joke out of the way, because you're going to hear it within four minutes of telling anyone you're learning C#: "Oh, C#? Isn't that just Microsoft Java?" Yes. Kind of. A little. Here's the actual story. Back around 2000, Microsoft wanted a modern, garbage-collected, object-oriented language for their shiny new .NET platform. Java existed and was extremely popular. Microsoft had previously shipped their own version of Java, Sun sued them into the sea, and the whole thing ended in tears and lawyers. So Microsoft did the very sensible, very corporate thing: they hired Anders Hejlsberg , the man who built Turbo Pascal and Delphi, and said: "make us a Java, but ours, and don't get us sued." He did. And then he kept improving it for twenty-five years while Java spent a decade arguing about whether it should add lambdas. So calling C# "Microsoft Java" today is like calling a smartphone "a Microsoft telegraph." Technically, you can trace the lineage. It is also extremely funny to the person being insulted, which is the only thing that matters. So, what can you actually do with this thing? More than you'd think. Let's take the tour. First, the obligatory Hello World Every language tour is legally required to start here. C#'s has changed a lot, which tells you something about the language's whole vibe. The old way, circa 2005, was a ceremony: using System ; namespace MyFirstApp { class Program { static void Main ( string [] args ) { Console . WriteLine ( "Hello, world!" ); } } } Eleven lines to say hello. You needed a namespace , a class , a Main method with a specific signature, and the kind of static void incantation that makes beginners quietly close the tab and go learn Python instead. The modern way (C# 9 and later) is this: Console . WriteLine ( "Hello, world!" ); That's the whole program. The compiler quietly puts all the ceremony back for you behind the scenes. This is C# in a nutshell: it grew up in a buttoned-up enterprise suit, and over twenty years it

A product search, a filter list that kept growing, and a status code I hadn't seen in years. Filters went in the query string, the way they always do. That held up fine until someone saved a "filter set" with a few hundred SKUs in it and the endpoint started answering with 414. I rebuilt a small version of it to find the exact wall. Same search, filters as repeated ?sku= values, count going up in steps of a hundred: 1) GET with filters in the URL 100 filters | request line 1534 bytes | 200 OK 200 filters | request line 3034 bytes | 200 OK 300 filters | request line 4534 bytes | 200 OK 400 filters | request line 6034 bytes | 200 OK 500 filters | request line 7534 bytes | 200 OK 600 filters | request line 9034 bytes | 414 RequestUriTooLong Kestrel's default max request line is 8 KB, and the request line is the method plus the URL plus the HTTP version. Somewhere between 500 and 600 filters, my URL stopped being a URL. Every fix I knew was a compromise. A body on GET is undefined by spec and some proxies quietly drop it. POST works, but POST announces "this might change something", so caches skip it, gateways won't auto-retry it, and anyone reading your API docs has to guess whether POST /search is actually a search. Cramming the filters into a header is the kind of idea that sounds clever for about a day. The method that was missing RFC 10008 defines QUERY , and it's exactly the thing that spot in the matrix was waiting for. The body carries the query. The method is safe and idempotent, so it can be retried after a dropped connection without anyone panicking. Responses are cacheable, and the spec is explicit that the cache key has to be built from "the request content and related metadata". There's also a nice touch on the response side: Content-Location can point at a URL where those exact results can be fetched with a plain GET. The one-line version I keep giving people: it's a GET with a body, and that's the entire point. Wiring it up in ASP.NET Core 10 .NET 10 shi

Introdução Integrar Apache Airflow com .NET 10 não significa portar o orquestrador, reescrever DAGs em C# ou executar o runtime Python dentro da aplicação. A solução correta é manter o Airflow responsável por criar, agendar e monitorar workflows e fazer o serviço .NET consumir sua API REST pública. O serviço autentica, dispara um DAG Run com parâmetros, guarda o identificador retornado e consulta o estado até receber success , failed ou canceled . Essa separação preserva o papel de cada tecnologia e cria um contrato claro entre a aplicação transacional e a plataforma de dados. Neste guia, eu vou implementar esse fluxo de ponta a ponta usando .NET 10 , HttpClient , autenticação JWT e a API /api/v2 do Apache Airflow 3.3 . O exemplo não se limita a um POST : ele gera um dag_run_id rastreável, serializa conf corretamente, reutiliza o token até perto da expiração, renova a credencial após uma resposta 401 , aplica timeout ao monitoramento e propaga cancelamento. Também vou expor a integração por uma Minimal API, para que outro sistema possa iniciar o processo sem conhecer os detalhes do Airflow. O nome atual da plataforma da Microsoft é .NET 10 , e não “.NET Core 10”. A marca “.NET Core” foi usada até a versão 3.1; desde o .NET 5, o produto unificado passou a se chamar apenas .NET. Essa diferença não altera o código, mas evita confusão ao procurar documentação, imagens de container e pacotes compatíveis. O cenário prático será um serviço de pedidos que solicita a execução do DAG etl_vendas . A configuração enviada contém a data de referência e um identificador de correlação. O Airflow continua executando tarefas Python, SQL, containers ou jobs distribuídos; o C# apenas controla o ciclo de vida da execução pela fronteira HTTP. ℹ️ Informação: no Airflow 3, os endpoints públicos estáveis ficam sob /api/v2 . Rotas internas de UI não são um contrato de integração e podem mudar conforme o frontend. Pré-requisitos Para acompanhar o exemplo, você precisa do .NET 10 SDK , do Dock

The first session ended at post 10. The design did not. I came back to it and, before writing a single new decision, asked the least glamorous question a solo project can ask itself: how far along is this, really, and what would it take to call it ready for someone else to review in depth? The answer was more useful than I expected, because it forced a distinction I had been blurring: a settled mechanism is not a hardened design . The fork: promote now, or hold and harden Composition was already reconciled into the binding docs. Coherence had seventeen recorded decisions covering the whole load-bearing core: binding, determinism, precedence, persona content, gender, explainability, detection, activation, the explicit accessor, and a second entity proving the abstraction generalizes. It was tempting to call that reviewable and promote it too. A: promote coherence into the binding docs now. 17 decisions, self-consistent, composition already went. Looks done. B: hold. The mechanism is settled, but the seams between features are not. Harden first, promote second. I took B. The tell was that I could not yet answer a reviewer's most obvious question, "what happens when a composed child is itself a person," without pointing at an open fork. A design you cannot stress at the seams is decided, not done. What "hardened" actually means The value of taking stock was turning a vague "almost there" into a concrete, finite list. Three passes stand between the current state and an in-depth review: 1. Cross-feature interaction pass. Where correctness bugs hide once two features exist. Composition x coherence is done (next post). Uniqueness, null-probability, and locale remain. 2. Surface-enumeration pass. Collect every public member the design has accumulated into one list to accept or cut. Public surface is locked, so this is the gate that matters most. 3. Consistency re-read. Read all the decisions straight through for contradictions and stale cross-references, the kind that creep

This is Part 18 of my series on the Microsoft Agent Framework. You can read the original post over on lukaswalter.dev . In the previous article , we looked at observability for agents. The main idea was to make a run visible as a chain of model calls, tool calls, approvals, and workflow events. Testing starts from the same idea. An agent run is not one answer string. It is a small application flow with several boundaries: user input -> prompt and context -> model request -> model response -> tool selection -> tool arguments -> tool execution -> structured result or final answer -> routing or workflow state If the only test is an end-to-end prompt against a live model, all of those boundaries are mixed together. When the test fails, you do not know whether the problem is the prompt, the model, the tool schema, the router, the workflow, or the real dependency behind the tool. The solution is not to pretend that an LLM is deterministic. The solution is to test each boundary at the level where it is deterministic, then add a smaller number of evaluation-style tests for behavior that genuinely depends on the model. This post covers: fake model clients tool contract tests structured output tests routing tests workflow tests eval-style regression checks The examples use xUnit-style assertions, but the testing approach does not depend on xUnit. The snippets focus on the relevant testing boundary and omit some application-specific factory and workflow setup. Do not start with the live model A live model test is useful. It is also expensive, slow, sometimes flaky, and difficult to diagnose. That makes it a poor replacement for normal unit and integration tests. I use a testing pyramid for agent applications: evals realistic model and user examples application integration tests agent + tools + storage + workflow boundaries deterministic component tests fake model client, tools, schemas, routing The bottom layer should be the largest. It should catch ordinary programming mistak

Let's say you need to implement a feature that returns a different package based on the user-provided coupon code. So you start with a model: public record Package { public int Id { get ; set ; } public string Name { get ; set ; } public double Price { get ; set ; } } And you write a function that returns a different package based on the coupon code: private static Package GetPackageFromCoupon ( string coupon ) { if ( coupon == "ABC" ) { return new Package { Id = 1 , Name = "PS5 Controller" , Price = 50.00 }; } if ( coupon == "EBC" ) { return new Package { Id = 2 , Name = "Iphone X" , Price = 200.00 }; } if ( coupon == "DDD" ) { return new Package { Id = 3 , Name = "X7 Mouse" , Price = 20.00 }; } return new Package { Id = 1000 , Name = "Soda" , Price = 1.00 }; } And invoke it from your main method: internal class Program { static void Main ( string [] args ) { var package = GetPackageFromCoupon ( "ABC" ); Console . WriteLine ( package ); Console . ReadLine (); } } Quick test Provide expected parameters and inspect the results. "ABC" => Package { Id = 1 , Name = PS5 Controller , Price = 50 } "EBC" => Package { Id = 2 , Name = Iphone X , Price = 200 } "DDD" => Package { Id = 3 , Name = X7 Mouse , Price = 20 } Works as expected. Also, if you enter something that doesn't exist: "a" => Package { Id = 1000 , Name = Soda , Price = 1 } The Problem What if you need to add more coupon codes and return different variations of the Package object? Well, it's gonna get pretty messy very soon. Quick solution - Dictionary Rather than writing every possible variation in the if block, create a dictionary where the key is the coupon code and the value is the Package: private static readonly Dictionary < string , Package > _packages = new () { [ "ABC" ] = new Package { Id = 1 , Name = "PS5 Controller" , Price = 50.00 }, [ "EBC" ] = new Package { Id = 2 , Name = "Iphone X" , Price = 200.00 }, [ "DDD" ] = new Package { Id = 3 , Name = "X7 Mouse" , Price = 20.00 }, }; The next step is to

Table of Contents: Introduction Constants Singletons & Services Singleton Service Locator Introduction Every Unity developer eventually hits the exact same wall: how do I get my UI script to talk to my Game Manager without turning my codebase into a tangled web of dependencies? Managing global state is a fundamental challenge in game architecture, and the internet is full of conflicting, often dogmatic advice on how to handle it. In this article, we are going to look at some popular approaches to managing global state: Static Constants, Singletons and Service Locator. Before we start though, I encourage you to read some of my previous blog posts in this series on project scaffolding or, even more crucial to some sections in this article, the bootstrapping process . Constants Not every piece of global data needs a instance to live in, interfaces, or an initialization phase. Some data is constant and never changes at runtime (constants). These constants are usually defined with static readonly or const (at least they should be if they never change). Example: public static class MathConstants { public const float MilesToKm = 1.60934f ; } public class CharacterAnimationController : MonoBehaviour { // we must use static readonly instead of const here because we need to generate the SpeedHash from the string literal. public static readonly int SpeedHash = Animator . StringToHash ( "Speed" ); } Constants are also tied to the type they are defined in. So to keep things neat, you should only define constants where appropriate. Meaning if you have a constant for the max networked inventory slot capacity, this shouldn't be defined in a class called NetworkedConstants and instead should reside inside the class that represents the NetworkedInventory which needs this data. In fact, if this is the only class that needs this data, you can even make it private although it's perfectly fine to make it public as well if there's a need for it in other scripts as long as you are not just

Open a lot of .NET projects and you'll find the repository pattern sitting on top of Entity Framework Core. IProductRepository, GetById, Add, Save, the whole set. Underneath, every method just calls the EF Core DbContext and passes the result straight back. The wrapper adds a name and nothing else. So do you need the repository pattern with EF Core? For most apps, no. EF Core already gives you one. DbSet is a repository. It already does the thing the pattern is for. The reason this keeps happening is that the repository pattern got taught alongside EF, so people assume you need one to use the other. You don't. What the Pattern Was For The repository pattern came before EF Core. It started in a time when data access meant hand-written SQL, SqlCommand, and mapping DataReader rows to objects by hand. Wrapping all of that behind an interface was worth it. It hid a real mess, and it let you swap what was underneath without the rest of the app noticing. EF Core already does that. DbContext is the unit of work. DbSet is the repository. SaveChanges() is the commit. The pattern you're adding is one the tool already gives you. What the Wrapper Actually Does Here's the shape you see in most codebases: public class ProductRepository : IProductRepository { private readonly AppDbContext _db ; public ProductRepository ( AppDbContext db ) => _db = db ; public async Task < Product ?> GetById ( int id ) => await _db . Products . FindAsync ( id ); public async Task < List < Product >> GetAll () => await _db . Products . ToListAsync (); public void Add ( Product product ) => _db . Products . Add ( product ); } Read what each method does. GetById calls FindAsync. GetAll calls ToListAsync. Add calls Add. It's a passthrough. Every line hands the call straight to EF Core and returns whatever comes back. You wrote an interface, a class, and a registration to rename methods that already existed. This is what people mean by a generic repository over EF Core, and it's the most common version y

When you develop a game at the beginning of your journey, you quickly notice that the environment is very static. To change that, let’s create some oscillations and move our platforms. We will use methods like Vector3.Lerp and Mathf.PingPong . using UnityEngine ; public class Oscillate : MonoBehaviour { [ SerializeField ] private Vector3 movementVector ; [ SerializeField ] private float speed ; private Vector3 _startPosition ; private Vector3 _endPosition ; private float _movementFactor ; private void Start () { _startPosition = transform . position ; _endPosition = transform . position + movementVector ; } private void Update () { _movementFactor = Mathf . PingPong ( Time . time * speed , 1f ); transform . position = Vector3 . Lerp ( _startPosition , _endPosition , _movementFactor ); } } First, we add movementVector and speed to inspector. movementVector receives the direction, and we tell it how far object must move. speed defines how fast objects move _ startPosition simply gets the starting coordinates in Start() with transform.position , and _ endPosition is the sum of the _ startPosition and movementVector . Now _ movementFactor is different. It defines the progress of the movement. Imagine it as a loading bar from 1% to 100%. In Update() method, we constantly calculate it every frame using Mathf.PingPong _movementFactor = Mathf.PingPong(Time.time * speed, 1f); So what is going on here, Mathf.PingPong does what you would imagine. Value goes back and forth. 1f is our length, so in Update() every frame _ movementFactor is getting updated from 0.0, 0.1, 0.2… up to 1.0, when the value is 1.0, it goes back to 0.0 in the same way. And since it’s in Update() this is an endless cycle. transform.position = Vector3.Lerp(_startPosition, _endPosition, _movementFactor); Now this is where magic happens. Lerp (Linear Interpolation) takes start position, end position and a “loading” bar. Why we did exactly 1f in PingPong is perfectly described in the official documentation: a

Most C# developers know how to use yield return. Few understand what actually happens after compilation. If you've ever written something like this: public IEnumerable < int > GetNumbers () { yield return 1 ; yield return 2 ; yield return 3 ; } it looks almost magical. No collection. No list allocation. No iterator implementation. Yet somehow the method returns an IEnumerable. So what is really happening? The answer is one of the most elegant compiler transformations in the entire .NET ecosystem. Let's open the hood. The Illusion Most developers imagine the previous code executes like this: Call method ↓ Return 1 ↓ Pause ↓ Return 2 ↓ Pause ↓ Return 3 That isn't what happens. C# methods cannot actually pause execution. Instead, the compiler completely rewrites your method into something entirely different. The Compiler Creates a State Machine Your tiny method becomes a hidden class similar to this: private sealed class GetNumbersIterator : IEnumerable < int >, IEnumerator < int > { private int _state ; private int _current ; public bool MoveNext () { switch ( _state ) { case 0 : _current = 1 ; _state = 1 ; return true ; case 1 : _current = 2 ; _state = 2 ; return true ; case 2 : _current = 3 ; _state = - 1 ; return true ; default : return false ; } } public int Current => _current ; } Your original method no longer exists. Instead, it simply returns: return new GetNumbersIterator (); Every yield return becomes another state inside MoveNext(). Why Local Variables Don't Disappear Consider this code: IEnumerable < int > Squares () { int x = 1 ; while ( x <= 3 ) { yield return x * x ; x ++; } } After the first yield, the method "pauses." But where is x stored? Not on the stack. The original stack frame has already disappeared. Instead, the compiler promotes local variables into fields: private int _x ; The iterator object now owns every variable that must survive between iterations. This is why iterator methods can remember where they left off. Heap Allocation Happens Ma

Introdução A visão original de Kay para OOP não era "objetos com dados públicos que outros manipulam", era objetos que trocam mensagens e decidem sozinhos o que fazer com elas. é Tell dont ask é basicasmente um resgate dessa ideia original, porquer com o tempo muita gente passou a usar OOP como “structs com getters e setters”, pedendo o encapsulamento de verdade. Ideia Central Exemplo do Cliente e Carteira Ask Eu PERGUNTO o saldo, e EU decido o que fazer com ele if ( cliente . carteira . saldo >= 50 ) { cliente . carteira . saldo -= 50 ; } else { console . log ( "saldo insuficiente" ); } Tell Eu DIGO pro cliente pagar, e ELE decide o que faze // "Tell" — eu DIGO pro cliente pagar, e ELE decide o que fazer cliente . pagar ( 50 ); class Cliente { carteira : Carteira ; pagar ( valor : number ) { if ( this . carteira . saldo < valor ) { throw new Error ( "saldo insuficiente" ); } this . carteira . saldo -= valor ; } } Repare a diferença de responsabilidade: No "Ask", quem chama o código precisa saber a regra ("se o saldo for menor, não pode pagar") e tomar a decisão sozinho. No "Tell", o próprio objeto conhece sua regra e decide por dentro. Quem chama só diz o que quer que aconteça. Por que "perguntar" é perigoso Pensa no "Ask" espalhado pelo sistema: toda tela, todo botão, todo endpoint que cobra do cliente vai ter que copiar essa mesma verificação de saldo: if ( cliente . carteira . saldo >= valorDoCarrinho ) { ... } if ( cliente . carteira . saldo >= valorDaAssinatura ) { ... } if ( cliente . carteira . saldo >= valorDoBoleto ) { ... } Se um dia a regra mudar (por exemplo, "clientes VIP podem ficar com saldo negativo até -R$100"), você precisa caçar todos esses lugares e mudar um por um. É praticamente garantido que algum lugar vai ser esquecido — e aí seu sistema tem um bug de regra de negócio inconsistente. Com "Tell", a regra mora em um lugar só ( Cliente.pagar ). Mudar uma vez, resolve todo o sistema. Como isso conecta com Law of Demeter Os dois princípios andam

If your team has ever spent 20 minutes on a pull request arguing about brace placement instead of the actual bug, welcome to the club. StyleCop was the tool to keep C# codebases from turning into everyone's personal-style soup. It did its job. But it's also old, slow, and wasn't built for a world where half your codebase might be vibe coded. The good news: .NET now ships with everything you need to enforce style natively, faster, and without an extra NuGet package. This post walks through why the old approach creaks under modern workloads, and gives you a copy-pasteable migration plan to fix it. Table of Contents The Real Cost of Style Debates Quick Refresher: What Is StyleCop? Do We Even Need Linters Now That AI Writes Code? The Problem With StyleCop: It's Slow The Modern Toolbox The 3 Layer Guardrail Strategy Step by Step Migration Guide Before and After Seeing It In Action Key Takeaways Wrapping Up The Real Cost of Style Debates Nobody has ever gotten a promotion for winning a tabs-vs-spaces argument. Yet these debates eat real time: PR bikeshedding ,reviewers nitpick spacing instead of catching actual logic bugs. Noisy git diffs ,one developer's auto-formatter touches 300 lines to fix a 3-line bug. Cognitive overhead ,jumping between services that each "feel" different slows everyone down. A linter's whole job is to make these arguments boring and automatic, so humans can focus on things that actually matter,like whether the code works . Quick Refresher: What Is StyleCop? StyleCop (and its Roslyn-based version, StyleCop.Analyzers ) is a static analysis tool that checks the visual grammar of your C# code,not bugs, not security holes, just style: Are public members documented? Are namespaces organized consistently? Do braces follow the "approved" pattern? It's not checking if your code is correct . It's checking if your code looks correct. Do We Even Need Linters Now That AI Writes Code? Short answer: yes, more than ever. AI coding assistants (Copilot, Cursor, and

Why some records should be created by your system, not your users, and how to do it safely in .NET. A support ticket lands on your desk: "The Teams page is empty. I added a member, but no team shows up." You check the API. It's behaving exactly as written: { "items" : [], "totalCount" : 0 } Nothing is broken. And that's the problem. The system is faithfully returning nothing, because the row that the page reads from was never created. Somewhere in your design, you assumed a human would create it first. This article is about a small, recurring design decision that quietly causes empty dashboards, confused users, and "is this a bug?" tickets: who is responsible for creating derived records the user, or the system? and how to let the system do it without introducing duplicate rows or race conditions. The problem Let's use a fictional product: a collaboration tool called Loop . In Loop, the important entities are: An Organization (a paying customer). A Member (a person invited into an organization under a plan). A Team a grouping that members belong to, keyed by (OrganizationId, PlanCode) . The admin dashboard lists Teams . Each team card shows a member count. Here's the catch in the original design: creating a Member wrote a member row. Creating a Team was a separate, manual step an admin was expected to do first. If an admin invited members without first creating the matching team, the dashboard showed nothing even though the members clearly existed. From the user's point of view, they did everything right. From the system's point of view, a required row simply didn't exist. Why it matters The Team record isn't independent information. It is fully derivable from the first member invited under a plan. When one entity's existence is implied by another, forcing a human to create it manually is a design smell. It leads to: Empty states that look like outages. Users can't tell "no data" from "misconfigured." Support load. Every skipped step becomes a ticket. Silent data dr

Working late nights on server migrations and code architectures often means typing in low-light environments. While USB lamps or backlit keyboards are the standard solutions, they consume extra power and add physical clutter. I realized the ultimate light source was already directly in front of me: the monitor. With a clear vision in mind, I partnered with Google's Gemini AI to rapidly prototype and refine what became LightBar For Keyboard , a lightweight Windows application that creates a reflective light bar at the bottom of the screen to illuminate the keys. Here is how we built it using C# and WPF, tackled the Windows API to manage screen space, and optimized it for modern OLED energy consumption. The Core Challenge: Desktop Toolbars (AppBar) The simplest approach to creating a light bar is a borderless, top-most window. However, the immediate UX flaw is that maximized applications (like Chrome or Visual Studio) will either cover the bar or be partially obscured by it. To solve this, the application needed to behave like the Windows Taskbar. I implemented the native Windows Application Desktop Toolbar (AppBar) API using SHAppBarMessage from shell32.dll . Docked Mode: By registering the application as an AppBar and setting the edge to ABE_BOTTOM , Windows automatically recalculates the working area of the desktop. Result: Maximized windows are pushed upward, ensuring the light bar remains entirely visible and never covers any underlying application UI. Floating Mode: For users who need temporary access to the bottom of their screen, I added a state toggle that unregisters the AppBar and enables standard drag-and-drop window movement via MouseLeftButtonDown . Enforcing a Single Instance Because the app directly manipulates the desktop working area, launching multiple overlapping instances would cause UI glitches. To prevent this, I implemented a Mutex in App.xaml.cs to guarantee a single instance constraint. protected override void OnStartup ( StartupEventArgs e )