Artur Rios Lab

How to Use PlantUML With Markdown

Wed, 21 Oct 2026 21:00:00 +0000

PlantUML draws diagrams from text. Instead of dragging boxes around an editor, you write Customer -> Shop: Place order and PlantUML lays out the sequence diagram for you. Markdown is where most documentation lives. Put the two together and the diagram’s source sits in the same file as the text that explains it: it is reviewed in the same pull request, searched with the same tools, and never drifts away from the document because someone lost the original drawing.

String Similarity: Levenshtein, Jaro and Jaro–Winkler

Wed, 21 Oct 2026 20:00:00 +0000

Two strings are equal or they are not, and for a computer that is the end of it: "Smith" and "Smyth" differ, and so do "recieve" and "receive". For the person who typed them, though, they are almost the same, and a lot of software has to act on that “almost”. A spell checker has to find the word that was meant. A search box has to forgive a typo. A company merging two customer lists has to notice that “Jon Smyth, 12 Main St” and “John Smith, 12 Main Street” are probably the same person. A string similarity measure puts a number on how close two strings are, so a program can make those calls.

How I Develop APIs

Wed, 21 Oct 2026 19:30:00 +0000

Every backend I build is an ASP.NET Core API, and they all look alike on purpose. When the structure is the same everywhere, I never have to remember where a thing lives, a new feature is a list of files to add rather than a design decision, and a test that fails points at one small piece of code.

This page describes that shape, using Heimdall as the example throughout. Heimdall is my identity management API: people, applications, logins, two-factor authentication and permissions, for several client systems at once, each in its own scope. It is the largest API I have, so every pattern here has been tested against a real use case rather than a toy one. All code on this page is taken from it, trimmed only where noted.

Common Windows Issues and How I Fix Them

Wed, 21 Oct 2026 19:00:00 +0000

This page is a reference rather than an article: problems I have hit on Windows more than once, with the fix written down so I do not have to search for it again. Each entry says what the problem looks like, what is going on underneath, and the steps that solve it. The file locations below were checked on Windows 11 Pro on 21 October 2026.

Blank or outdated icons: rebuilding the icon cache

What it looks like. Explorer, the desktop or the taskbar shows a blank white icon, a generic one, or the old icon of an application that has since been updated.

The Conventions I Follow

Wed, 21 Oct 2026 18:00:00 +0000

A convention is a decision made once. Without them, every new repository, class and commit reopens the same small questions: what to call it, where to put it, how to phrase it. None of those questions is hard, but answering them again every time is slow, and answering them differently every time leaves a codebase that reads like it was written by several people who never met.

This page collects the conventions I follow in my own projects. Where a style guide already covers something, I follow it; the Google Style Guides are my default reference for the languages they cover. What is written here is either what those guides leave open, or a choice I have made on top of them.

Deploying With Yggdrasil

Wed, 21 Oct 2026 17:55:00 +0000

Yggdrasil is the deploy manager I built for my server. It does one job: take an application from a GitHub repository to a healthy container in the right environment, and back to the previous version if the new one does not come up. This part follows a change from a pull request to production.

One catalog

Everything yggdrasil knows comes from one file, catalog.yaml, in three layers:

Documentation Sites

Wed, 21 Oct 2026 17:55:00 +0000

Every project with users gets a documentation site: what it is, how to install and use it, and its reference. Heimdall’s documentation is one, and so is the documentation of my .NET libraries. They are all built the same way.

Concern	Choice
Generator	Hugo, extended edition
Theme	Docsy, as a Hugo module
Hosting	GitHub Pages
Deploys	GitHub Actions
DNS	Cloudflare, optional

Why Hugo

Hugo is a single binary that builds thousands of pages in about a second, and documentation is Markdown in a folder, next to the code it describes, reviewed in the same pull requests. Docsy is a documentation theme from Google with navigation, search and versioned sections built in.

How I Host My Projects

Wed, 21 Oct 2026 17:55:00 +0000

Every project eventually has to run somewhere, and deciding where for each one separately is how a hobby turns into a pile of accounts, bills and half- remembered setups. So I decided once, by kind of project, and every new project inherits the answer. This series describes that setup, as it runs today.

The decision table

I’m building	Stack	Hosting
A marketing or product page	Next.js with shadcn/ui	Vercel, behind Cloudflare
A static portfolio or brochure site	Astro, or a Next.js static export	Cloudflare Pages or GitHub Pages
Technical documentation	Hugo with the Docsy theme	GitHub Pages
An interactive web app	Flutter, built for the web	My server: Docker, Traefik, yggdrasil
A backend API	ASP.NET Core	My server: Docker, Traefik, yggdrasil
A reusable package	NuGet, or the language’s own format	nuget.org and GitHub Packages

The rule behind it

Anything with a running backend is self-hosted; everything else is not.

Landing Pages

Wed, 21 Oct 2026 17:55:00 +0000

A landing page sells something: a hero section, a grid of features, pricing, a contact or waiting-list form. It has to look polished, load fast everywhere, and occasionally do something dynamic, such as accept a form. That last part is why landing pages are not plain static sites.

Concern	Choice
Framework	Next.js, with the App Router
UI	shadcn/ui and Tailwind CSS
Hosting	Vercel, on the free tier
DNS	Cloudflare
Deploys	Vercel’s Git integration

Building one

bash

npx create-next-app@latest my-landing --ts --tailwind --app --eslint
cd my-landing
npx shadcn@latest init
npx shadcn@latest add button card input navigation-menu

shadcn/ui is not a component library installed as a dependency: it copies each component’s source into the project, built on Radix and Tailwind, so every component can be changed like my own code.

Libraries

Wed, 21 Oct 2026 17:55:00 +0000

Code that more than one project needs becomes a package. Mine are .NET libraries, published as NuGet packages to two places: nuget.org, where anyone finds them, and GitHub Packages, next to their source.

Concern	Choice
Package format	NuGet, or the language’s own format elsewhere
Primary feed	nuget.org
Secondary feed	GitHub Packages
Publishing	GitHub Actions, on a version tag
Versioning	Semantic versioning

Package metadata

The project file describes the package, so dotnet pack produces a complete .nupkg with its symbols alongside:

Sizing the Server

Wed, 21 Oct 2026 17:55:00 +0000

Before an application goes on the server, it should be clear that it fits. This is the model I size the server with: one figure per service for what it needs, a formula that adds headroom, and the signals that say the model has stopped being true.

The figures are starting estimates for a small production load, a few requests a second on each API, not measurements. After a week of real traffic, Grafana’s numbers replace them.

Static Sites

Wed, 21 Oct 2026 17:55:00 +0000

A static site is rendered to HTML, CSS and JavaScript when it is built, and served as files from then on: portfolios, brochure sites, event pages and small blogs. With no code running on a server, it can be hosted for free on a CDN and will never go down for want of a patch.

Concern	Choice
Generator	Astro for content-first sites, or Next.js with a static export
Styling	Tailwind CSS
Hosting	Cloudflare Pages, or GitHub Pages
Deploys	The host’s Git integration, or GitHub Actions

Its neighbours in this series draw the line: a page that needs a form or a server function is a landing page, on Vercel, and reference documentation is a documentation site, in Hugo.

The Platform: Traefik, Monitoring and the Console

Wed, 21 Oct 2026 17:55:00 +0000

On top of the server runs one Compose project, yggdrasil, that every application shares: the reverse proxy, the monitoring, and a status API with its console. It is started once per host, and serves every environment on that host.

bash

scripts/platform.sh up

Component	Version	Job
Traefik	v3.6	Routes every request, terminates TLS
Docker socket proxies	1.13.1	Give Traefik, Alloy and the status API read-only access to Docker
Status API	.NET 10	Health, version and deploy time of every application
Console	Flutter	Shows the status API, on the web, Windows and Android
Prometheus	v3.5	Metrics, kept 30 days
Loki	3.5	Logs, kept 31 days
Alloy	v1.10	Ships every container’s logs to Loki
Grafana	12.1	Dashboards over Prometheus and Loki
Jenkins	LTS	Deploys, covered in Deploying With Yggdrasil

Traefik and one wildcard certificate

Traefik is the only container that publishes ports, 80 and 443, and port 80 does nothing but redirect to 443. It watches Docker for containers that opt in with labels, so a new application is routed the moment it starts, without touching Traefik’s configuration.

The Server

Wed, 21 Oct 2026 17:55:00 +0000

Everything self-hosted runs on one machine: the platform, the deploy server, and every application in three environments. This part covers the machine itself and what is installed on it directly, outside any container.

The machine

Resource	Spec
Provider	Hostinger VPS
vCPU	4 cores
RAM	16 GB
Disk	200 GB NVMe
Bandwidth	16 TB a month
OS	Ubuntu LTS

One machine is a single point of failure, and I accept that knowingly: these are my own projects, an outage costs me an evening, and one well-understood server is easier to keep healthy than three. Whether everything fits on it is the subject of Sizing the Server.

Web APIs

Wed, 21 Oct 2026 17:55:00 +0000

My backends are ASP.NET Core APIs, and every one of them meets the platform the same way. Heimdall’s API is the example throughout; Fortuna’s follows the same shape.

Concern	Choice
Framework	ASP.NET Core on .NET 10
Image	Multi-stage: the SDK to build, the ASP.NET runtime to run
Database	The host’s PostgreSQL, one database per environment
Configuration	Environment variables, from yggdrasil
Health	`/healthcheck`, probed by Docker, yggdrasil and the status API
Metrics	OpenTelemetry’s Prometheus exporter, on port 9464
Logs	Standard output, shipped to Loki
Checks	Tests and a Docker build in GitHub Actions

The image

The Dockerfile has two stages. The first restores and publishes with the .NET 10 SDK, copying the project files before the sources so a source-only change reuses the cached restore. The second copies the output onto the much smaller ASP.NET runtime image, and runs it as the image’s own non-root user:

Web Apps

Wed, 21 Oct 2026 17:55:00 +0000

My interactive front ends are Flutter apps, and on the web they are a set of static files: HTML, JavaScript and WebAssembly. So the container that runs one is just a web server, small and stateless. Heimdall’s web app is the example.

Concern	Choice
Framework	Flutter, built for the web
Build stage	Debian with a Flutter SDK pinned by version and checksum
Runtime	nginx, unprivileged, with a read-only file system
Settings	Compiled in at build time, once per environment
API	Its own origin’s `/api/`, routed to the API by Traefik
Health	`/healthz`
Checks	Analysis and tests, and generated code checked in GitHub Actions

The image

The build stage installs Flutter itself, rather than starting from a community Flutter image, so the exact SDK version is pinned and its download is checked against a SHA-256 checksum. It builds as a non-root user, and fetches packages with --enforce-lockfile, so the build uses exactly the versions the repository was tested with:

How I Start a Project From Scratch

Wed, 21 Oct 2026 17:30:00 +0000

Every project on this site starts the same way. Not with code, but with a document, because the cheapest place to find a mistake is in a sentence, before anything has been built on top of it. This is the roadmap I follow, from the first idea to a system that is ready to use:

Create a brainstorm document for the project, with ideas about its nature, its implementation and the technologies to use.
Refine the brainstorm into four initial documents: Project Overview, Technology Stack, Workflow and Business Rules.
Formalise them into a Vision Document, a System Requirements Document and a Use Case Specification Document.
Review the documents, improve them, and review them again until they match what the project is meant to be.
Create GitHub issues for the initial scaffold and infrastructure.
Create a GitHub issue for each use case, linked to a GitHub Project and to an MVP milestone.
Implement the initial scaffold and infrastructure.
Implement one use case after another, including unit and functional tests.
For each use case, run the tests and fix until all of them pass, and only then move on to the next one.
Run a final test of the full functionality and fix any issue found, repeating until the system is ready.

The ten steps fall into four phases:

Craft: A Programming Language

Wed, 21 Oct 2026 17:00:00 +0000

A modern programming language that supports the most used paradigms, and has all the features you need to write elegant solutions.

Features

Multiplatform
Syntax inspired by C#
Proof, parallelism and speed inspired by Bend

Roadmap

Develop a minimal version
Develop and test more features on top of the minimal version
Once we have a first stable version, start to develop simple programs in it
Develop more features, as we test and identify requirements
Build more complex programs and develop the language as we go
After having a stable programming language, with complex projects written on it, create a compiler written in Craft itself
Build an Operating System using the language

Technology stack

A language is two things: the design people write in, and the compiler and runtime that make it run. The stack is mostly the second, but three design choices shape it so much that they come first: how parallelism works, how memory is managed, and what “proof” means. The background on how a compiler is structured is in Compilers, and the way C# itself runs is in How C# Runs.

Anvil OS: An Operating System From Scratch

Wed, 21 Oct 2026 15:00:00 +0000

An open source operating system built from scratch.

Overview

The idea is to build a fully functional operating system, to learn about how an operating system works, and from the simpler version of a kernel, improve it until something really usable.

Roadmap

Start with the simpler version of a kernel
Build functionalities on top of the kernel
Improve as we test

Technology stack

An operating system has almost no stack in the usual sense: there is no runtime, no standard library and no framework beneath it, because it is the thing those normally run on. The choices that matter are the language, the processor architecture, how the kernel gets loaded, and the tools for running and debugging a kernel that cannot print an error when it crashes. The background for all of it is in Operating Systems and Processors.

The .NET Libraries I Reach For

Wed, 21 Oct 2026 13:20:00 +0000

Every new .NET project starts with the same handful of decisions. How will I test it? Where does fake data come from? How do I validate input, survive a flaky dependency, export a spreadsheet, run something every night? The base class library answers some of these. For the rest, I have settled on a short list of NuGet packages that I add almost without thinking.

This page is that list, with the reasoning written down. For each library I explain what it is for, why I use it, show a small example and say when I would pick something else. A recommendation is only as good as what it leaves out, so I also flag what I would want to know before adding a dependency: licence, maintenance, breaking changes, and in two cases events that every user of the library should know about.

Test Coverage in .NET: What It Measures and How to Collect It

Wed, 21 Oct 2026 13:10:00 +0000

A pull request comes back with a comment: “coverage dropped from 84% to 81%”. What does the number mean? Which 3% went missing, and does it matter? Coverage is one of the few test metrics that every .NET tool can produce for free, and one of the easiest to misread. It is very good at answering which code did no test run? and close to useless at answering are the tests any good?

EF Core or Dapper? Two Ways to Talk to a Database from .NET

Wed, 21 Oct 2026 13:00:00 +0000

Almost every .NET application that stores data ends up choosing how its C# code will talk to a relational database. Two names come up more than any other. Entity Framework Core is Microsoft’s object-relational mapper: you describe your classes, and it writes the SQL, tracks what you change and evolves the schema. Dapper is a small library from Stack Overflow: you write the SQL, and it turns the rows that come back into objects.

C# Delegates: Methods as Values

Wed, 21 Oct 2026 12:50:00 +0000

List<T>.Sort doesn’t know how you want your items ordered, so it asks you: pass it a method that compares two items, and it calls that method whenever it needs to. A button doesn’t know what should happen when it is clicked, so it keeps a list of methods to call. LINQ’s Where doesn’t know which items you want, so it takes a method that answers yes or no for each one. All three need the same thing from the language: a way to treat a method as a value that can be stored in a field, passed as an argument and called later. In C# that value is a delegate.

IEnumerable, ICollection, IList and IQueryable: What Each Collection Interface Promises

Wed, 21 Oct 2026 12:40:00 +0000

Open almost any C# codebase and you will find method signatures that take an IEnumerable<T>, entities with ICollection<T> navigation properties, repositories returning IQueryable<T>, and the occasional IList<T> or IReadOnlyList<T>. They are easy to treat as interchangeable names for “a bunch of items”, and the code usually compiles whichever one you pick. Yet each interface makes a different promise, and choosing the wrong one causes real bugs: a query that runs three times, a database table loaded into memory to be filtered in C#, an exception thrown far from the line that caused it, or a “read-only” list that changes under your feet.

How C# Runs: From Source to IL to Machine Code

Wed, 21 Oct 2026 12:30:00 +0000

A C# program is not compiled straight to machine code, and it is not interpreted either. It is compiled twice. When you build, the C# compiler turns source code into an intermediate language and a description of every type, packed into an assembly, a .dll file. When you run, the .NET runtime turns that intermediate language into machine code for the CPU it is running on, usually one method at a time and often more than once as it learns which code is hot.

Git Tags: Naming the Commits That Matter

Wed, 21 Oct 2026 12:00:00 +0000

Branches move: every commit on main moves main forward. Sometimes you need a name that stays where it is put, such as “the commit that went out as version 1.6.0”. That is a tag. Tags mark releases, the build a bug report refers to, or the last commit before a large refactor, and almost every release tool, from GitHub Releases to package registries, reads them.

Tags look simple, and mostly are. The parts that cause trouble are the two kinds of tag, which behave differently in some commands, and the fact that tags are not pushed, fetched or overwritten the way branches are. This article covers both. The commands shown were run with Git 2.56 on 21 October 2026, in a scratch repository and in this site’s own repository. Long temporary paths in the output are left out.

Thoth: An IDE That Grows With You

Wed, 21 Oct 2026 12:00:00 +0000

An IDE that adapts to your exact needs, nothing more, nothing less.

Features

Starts like a simple and lightweight code editor and the user can activate modules to add functionalities to fill their needs. For example a .NET module, an Angular module etc
Experience must be similar to Visual Studio Code on Linux and Windows and similar to LunarVim on terminal
Do not support extensions, the idea is to use the modules to extend the application on-demand

Platforms

Linux
Windows

First release modules

.NET
Angular
React
Flutter
Python
Rust
HTML/CSS
JavaScript/TypeScript
Java

Technology stack

The feature that shapes the stack most is the second one: the same IDE in a window and in a terminal. If the window and the terminal are two programs, every feature is built twice. So the design starts from one core that owns everything an editor does, such as buffers, cursors, syntax trees, language servers, commands, keymaps and modules, and two thin front ends that only draw what the core describes and send it the user’s input. The core and the front ends talk only through typed messages: input events go in, view updates come out. Neither side calls into the other, so a front end can be replaced, and the core could later run in a separate process, for example on a remote machine over SSH.

Git Submodules: One Repository Pinned Inside Another

Wed, 21 Oct 2026 11:00:00 +0000

This site is built with a Hugo theme I also maintain, nuno, and the theme lives in its own repository. The site needs an exact version of it, and I want to change the theme without copying files back and forth. Git’s answer is a submodule: a repository placed inside another repository, the superproject, which records exactly which commit of it to use. The site’s themes/nuno folder is one, and it is the example throughout this article.

My Git Config and the Commands I Keep Reaching For

Wed, 21 Oct 2026 10:00:00 +0000

This page is a reference rather than an article: the global configuration I set on every new machine, and the commands I look up often enough to keep written down. Each one comes with what it actually does and, where it rewrites history or throws work away, what to watch out for. Every command here was run against Git 2.56 on 21 October 2026, and the explanations follow the official Git reference pages linked at the end.

Mosaic: A Second Brain App

Wed, 21 Oct 2026 09:00:00 +0000

An app that wants to be your second brain.

Features

Create and organize notes in Markdown
Calendar
To do list
Kanban board
Pomodoro sessions
Mermaid diagrams
Draw diagrams

Inspiration

This app wants to combine features from these apps:

Platforms

Android
Linux
Web
Windows

Technology stack

Two of the features decide most of the stack before anything else is weighed. Excalidraw is published as a React component, and Mermaid is a JavaScript library. Any stack that does not run JavaScript in a web view has to embed one to get them, so the cheapest path is to make the whole app a web app and wrap it for each platform. The suggestion below follows that path.

What Is the Dependency Inversion Principle? Policy, Detail and Who Owns the Interface

Wed, 21 Oct 2026 00:05:00 +0000

A checkout that takes a payment has to call the payment provider: there is no way around that at run time. It does not follow that the checkout’s source code has to name the provider, import its SDK, or change when the provider changes its API. The dependency inversion principle is the rule that separates those two things. It asks which way the arrows between modules should point, and its answer is that the code holding the important decisions should not depend on the code holding the details; the details should depend on it. This is part five of a series on SOLID, after the single responsibility, open-closed, Liskov substitution and interface segregation principles, and it leads into inversion of control, the mechanism most programs use to put the principle into practice. This article explains what the principle says, where it came from, why the flow of control and the direction of a dependency can point opposite ways, why the abstraction has to belong to the code that uses it, and what is not worth inverting. Every output shown here was produced by running the code on Windows 11, with Python 3.14.6, not written by hand.

What Is the Interface Segregation Principle? Fat Interfaces, Role Interfaces and the Clients That Shape Them

Wed, 21 Oct 2026 00:04:00 +0000

An invoice printer needs to read one order. In many codebases it is handed an object that can also save orders, cancel them, total the month’s revenue and export everything to a spreadsheet, because that is the interface the order store happens to have. The printer never calls those methods, but it depends on them all the same: when one of them changes, the printer is rebuilt, retested and redeployed, and anyone writing a stand-in for it in a test has to implement all five. The interface segregation principle is the rule against that arrangement, and the fourth of the five SOLID principles this series covers. This article explains what it says, where it came from, what a fat interface costs, how to split one into interfaces shaped by their clients, and where splitting stops paying. Every output shown here was produced by running the code on Windows 11, with Python 3.14.6 and with the .NET 10 SDK, not written by hand.

What Is the Liskov Substitution Principle? Subtypes, Contracts and the Promises a Base Class Makes

Wed, 21 Oct 2026 00:03:00 +0000

A function that sorts a list of shapes by area has never heard of the square. It was written against a base type, and it will be handed whatever subclasses exist now and whatever subclasses someone writes next year. Whether it keeps working depends on a promise nobody wrote down: that every one of those classes behaves the way the base type said it would. The Liskov substitution principle is that promise, made explicit. It is the third of the five SOLID principles, and this is part 3 of a series on SOLID. This article explains what the principle says, where it came from, the rules a subtype has to keep, the violations that ship inside widely used platforms, and how to repair one. Every output shown here was produced by running the code on Windows 11, with Python 3.14.6, mypy 2.4.0 and the .NET 10 SDK, not written by hand.

What Is the Open-Closed Principle? Extension, Abstraction, Plug-ins and the Expression Problem

Wed, 21 Oct 2026 00:02:00 +0000

A shop adds a new way to ship parcels. In one codebase that means opening the function that prices shipping, adding a branch to the middle of it, and re-testing everything that calls it. In another it means writing one new class in one new file, and nothing that already works is touched. The difference between the two is what the open-closed principle is about: arranging code so that new behaviour arrives as new code, rather than as edits to code that is released, tested and depended on. It is the second of the five SOLID principles, and this is part 2 of a series on them, after the single responsibility principle. This article explains what the principle means, where it came from, what it looks like in running code, why no module can be closed against every change, how the expression problem sets its limits, and when the abstraction it calls for is worth paying for. Every output shown here was produced by running the code on Windows 11, with Python 3.14.6, not written by hand.

What Is the Single Responsibility Principle? Reasons to Change, Actors and Cohesion

Wed, 21 Oct 2026 00:01:00 +0000

An online shop has an Order class. Finance uses it to book revenue, the storefront uses it to print receipts, and the platform team uses it to store orders in the database. One day the storefront asks for receipts to show prices with VAT, a developer makes the change in the obvious place, every test the storefront cares about passes, and at the end of the month finance’s revenue is twenty per cent too high. Nobody touched finance’s code. They touched code that finance shared. The single responsibility principle is the rule that would have kept those two apart, and it is the most quoted and least understood of the five SOLID principles. This is the first part of a series on SOLID: it explains what the principle says, where it came from, how the acronym itself was born, what it looks like in running code, and how far to take it. Every output shown here was produced by running the code on Windows 11, with Python 3.14.6, not written by hand.

What Are CVE and CWE? Naming Vulnerabilities and the Weaknesses Behind Them

Tue, 20 Oct 2026 23:30:00 +0000

A dependency scanner fails your build with “CVE-2021-44228, critical”. A static analysis tool flags a line of code as “CWE-89”. A vendor’s release notes list a dozen CVE numbers fixed in the latest patch, and a security questionnaire asks how you prevent “the CWE Top 25”. The two acronyms look alike, both are run by the same organisation and both turn up in the same tools, but they answer different questions. CVE answers which vulnerability is this?: it gives one specific, publicly known flaw in one product a name everyone can use. CWE answers what kind of mistake is this?: it names a type of weakness that can occur in any product, and that may cause many vulnerabilities over the years.

What Is Inversion of Control? Frameworks, Callbacks, Dependency Injection and Containers

Tue, 20 Oct 2026 23:00:00 +0000

A web framework calls a function when a request arrives. A test runner finds the tests in a file and runs each one. A browser calls a handler when a button is clicked, and an application server hands a class the database connection it asked for in its constructor. In each case the code a programmer wrote does not decide when it runs or where its collaborators come from: something else does. That reversal has a name, inversion of control, and it is one of the ideas most of modern software is quietly built on. This article explains what it means, where the term came from, the forms it takes, how dependency injection and IoC containers work inside, and when the indirection is worth paying for. It closes a series on SOLID: where the dependency inversion principle says which way dependencies should point, this is the mechanism that makes them point that way at run time. Every output shown here was produced by running the code on Windows 11, with Python 3.14.6 and with the .NET 10 SDK and Microsoft.Extensions.DependencyInjection 10.0.13, not written by hand.

What Is a Unit Test? Where Unit Testing Came From and How to Write Good Ones

Tue, 20 Oct 2026 22:30:00 +0000

You change one line in a pricing function and want to know whether anything broke. You could start the whole application, log in, fill a cart and look at the total, for every kind of cart you can think of. Or you could run a few hundred small programs that each call the pricing function with one input and check the answer, and know in under a second. Those small programs are unit tests, and the second way of working is one of the biggest changes in how software has been written in the last thirty years: from testing as a phase at the end of a project, done by someone else, to testing as something every programmer does every few minutes.

How Do Programs Talk to Each Other? JSON, XML, Protobuf, RPC, REST, gRPC, GraphQL and Messaging

Tue, 20 Oct 2026 20:00:00 +0000

A mobile app asks a server for a user’s orders. The server asks a payment service whether an order was paid, tells a warehouse system to ship it, and announces to anyone interested that it has shipped. A code editor asks a language server where a function is defined; an AI agent asks a tool to read a file. All of these are programs talking to other programs, and every one of those conversations rests on two decisions: how the data is encoded into bytes, and how the conversation is shaped, as a function call, a request for a resource, a query, a stream or a message dropped in a queue.

Angular, React or Flutter? How They Compare and How to Choose

Tue, 20 Oct 2026 18:00:00 +0000

“Angular or React?” is one of the most common questions in front-end development, and “or Flutter?” is now often added to it. The question sounds like a choice between three brands of the same product. It is not. Angular is a complete framework for web applications; React is a library for turning state into UI, which needs a framework around it to make an application; Flutter is a toolkit for mobile, desktop, web and embedded apps that does not use the browser’s HTML at all, but draws every pixel itself. Each has been described in detail in this section: What Is Angular?, What Is React? and What Is Flutter?. This article puts them side by side and ends with a guide to choosing.

How Do Computer Networks Work? TCP/IP, the OSI Model and the Protocols Every Programmer Uses

Tue, 20 Oct 2026 18:00:00 +0000

Very few programs work alone. A web page fetches data from an API, the API queries a database on another machine, the database replicates to a third, and all of them ask a time server what time it is and a name server where everyone else lives. Every one of those conversations crosses a network, and every one of them can be slow, fail halfway or arrive in pieces. A programmer who understands what happens between connect() and the reply can tell a DNS problem from a TLS problem from a congested link, and can write code that copes with all three.

What Is Angular? Google's Web Framework, From AngularJS to Signals

Tue, 20 Oct 2026 18:00:00 +0000

Most web pages are documents. Some are applications: a mail client, an analytics dashboard, a banking back office, a cloud console. Those have hundreds of screens, thousands of components and teams of dozens of people working on them for years, and building them directly on the browser’s DOM and event loop quickly becomes unmanageable. Angular is Google’s answer to that problem: a complete, opinionated framework that decides how such an application is structured, compiled, tested and shipped.

What Is Flutter? History, Architecture and How to Build With It

Tue, 20 Oct 2026 18:00:00 +0000

Most toolkits for building an app on more than one platform make a choice early on: either they wrap each platform’s own buttons, lists and text fields, or they run the app inside a web view. Flutter does neither. It ships its own rendering engine inside every app and draws every pixel of the interface itself, from the text to the scroll bars, on a canvas the operating system hands it. The same Dart code then runs on Android, iOS, the web, Windows, macOS and Linux, and on embedded devices through a custom host.

What Is React? Components, Rendering and the Library Behind Modern Interfaces

Tue, 20 Oct 2026 18:00:00 +0000

React is a JavaScript library for building user interfaces out of components: small functions that describe what a piece of the screen should look like for a given state. You never tell React how to change the page; you describe what it should be now, and React works out the smallest set of changes that gets the screen there. The idea met a cool reception when Facebook released React in 2013; today React is the most used library of its kind. In Stack Overflow’s 2026 Developer Survey, 42 percent of respondents said they had used it, second among web frameworks and technologies only to Node.js.¹

How Does a Web Browser Work? From a URL to Pixels on the Screen

Tue, 20 Oct 2026 17:30:00 +0000

A web browser is probably the most complex program most people use every day. In a few hundred milliseconds it turns a line of text in an address bar into a network connection, a stream of bytes, a tree of objects, a set of styled and measured boxes, and finally pixels, then keeps all of that live while scripts change it and the user scrolls, types and clicks. It is also a small operating system in its own right (What Is an Operating System?), running untrusted code from every site you visit and keeping those sites apart.

What Is Text Encoding? From Telegraph Codes to Unicode and UTF-8

Tue, 20 Oct 2026 17:00:00 +0000

A computer stores nothing but numbers. Every letter you read on a screen, every name in a database and every line of source code is held as a sequence of numbers, and something has to agree on which number means which character. That agreement is a text encoding. When it works, nobody notices. When two programs disagree, “café” turns into “cafÃ©”, a customer’s name is rejected as invalid, or an emoji crashes a database insert. This article explains what a text encoding is, how the world got from telegraph codes to Unicode, how the modern encodings work bit by bit, and where text still goes wrong. The examples were run with Python 3.10 and Node.js 12, and their output is shown as printed.

What Are Data Structures? From Arrays to Hash Tables, and How to Choose One

Tue, 20 Oct 2026 16:30:00 +0000

Niklaus Wirth titled a 1976 book Algorithms + Data Structures = Programs,¹ and What Is Programming? quoted it: choosing how to represent information is as much a part of programming as choosing the steps that work on it. This article is about the second half of that equation. It explains what a data structure is, where the classic ones came from, how each works and what it costs, and how to choose between them. The examples were run with Python 3.10 on an Intel Core i9-13900K, and their output is shown exactly as printed.

What Is a Compiler? How Source Code Becomes a Running Program

Tue, 20 Oct 2026 16:00:00 +0000

What Is Programming? ended with high-level languages taking over from machine code, and What Is a Processor? described the machine instructions a CPU actually runs. Between the two sits the compiler: the program that turns one into the other. This article explains what a compiler is, where compilers came from, how each of their phases works, how a C file becomes an executable on a real system, and how to build a small compiler of your own. Every compiler output shown here was produced by running the tools on Ubuntu 22.04 with GCC 11.4 and Python 3.10, not written by hand.

Processes and Threads: What They Are, Where They Came From and How They Work

Tue, 20 Oct 2026 15:30:00 +0000

What Is an Operating System? introduced processes and threads in a few paragraphs, and What Is a Processor? showed the hardware they run on. This article gives them the space they deserve. Almost every question about how a program behaves when it does more than one thing at a time, from “why did my server run out of memory?” to “why does this counter come out wrong?”, comes down to the difference between a process and a thread.

What Is a Processor? History, Architectures and How a CPU Works

Tue, 20 Oct 2026 15:00:00 +0000

What Is Programming? described programs as precise descriptions of a process, and What Is an Operating System? described the software that shares a machine between them. This article goes one level further down, to the part that does the work: the processor. It covers what a processor is, how it got from vacuum tubes to tens of billions of transistors, the main ways processors are designed, and, in some detail, how a modern CPU turns instructions into results.

What Is an Operating System? History, Architectures and How It Works

Tue, 20 Oct 2026 09:00:00 +0000

Every program you have ever written leaned on an operating system without asking. Printing a line, opening a file, allocating memory, waiting for a key press: none of these is something a processor knows how to do. The operating system does them on the program’s behalf, and does them for hundreds of other programs at the same time without letting any of them trample the others.

What Is Programming? followed the history of telling machines what to do. This article follows the program that stands between every other program and the machine: what it is, how it came to exist, the main ways it can be built, and, in some detail, how it actually works.

What Is Programming? A Short History of Telling Machines What to Do

Mon, 19 Oct 2026 09:00:00 +0000

Ask ten developers what programming is and you will get ten answers: “writing code”, “solving problems”, “telling a computer what to do”. All of them are true, and none of them is quite enough. This article tries to pin the idea down, and then follows it through roughly two centuries of history — because most of what feels arbitrary about programming today makes sense once you know where it came from.