Los Techies

Big Design Up Front Is Responsible Again

Fri, 31 Jul 2026 09:00:00 +0000

Agile taught us to avoid big design up front. That was the right call — for the constraints we had. Those constraints are gone, and I think the advice inverted.

Here’s why we avoided it. Two things were slow and expensive: writing the spec, and building the software. Both were done by hand. So a detailed upfront design was a large bet you couldn’t easily change, written before you knew if it was right. The sane response was to write less of it, ship a thin slice, and learn by building the wrong thing first. For twenty years that was the responsible move. I’ve shipped plenty of thin slices that discovered the wrong product — expensively — and called it agility.

AI deleted both of those costs.

Last week I designed a whole application before writing a line of it. Not a napkin sketch — a complete, traceable spec: stakeholder needs, system requirements, architecture with sequence diagrams, down to component-level tickets. Then it was rendered into a narrated video walkthrough with real UI screens, and I handed that to the customer to review. Pause, draw on a frame, leave a voice note.

Writing that spec used to take weeks of typing. It took hours. Building a throwaway version just to get real feedback used to be the only option. Now I get feedback on the design itself, at full fidelity, before building anything.

The part that matters: this is not waterfall. Waterfall failed because the big upfront design was unvalidated and expensive to change — by the time reality showed up, you were committed. Flip both of those. The design is now cheap to produce, cheap to change, and cheap to validate: render a new video, get feedback, re-render. That is big design up front with a tight feedback loop — the thing waterfall couldn’t afford and agile gave up on.

Put it in a grid. Waterfall: expensive to produce, expensive to change. Agile: so skip the design. What we have now: cheap to produce, cheap to change, cheap to validate. Different quadrant. Different rules.

So where did the bottleneck go? It was never typing. It was typing speed — for specs and for code — that forced us to go slow and iterate. The model writes specs at the speed of light and builds at the speed of light. The only scarce thing left is judgment: deciding what’s right, and getting the humans aligned before you commit.

Spend your time there. Do the design work you’ve been skipping since 2005 — you can finally afford it. Refine it. Review it properly, with people who aren’t going to read a forty-page doc but will watch a five-minute video and tell you it’s wrong. Then let the model build it.

Concretely, the loop I’m running now:

A living spec that deepens by level — stakeholder need, system, architecture, components — each traceable to the next.
Every level rendered into a narrated review video, approved before the design goes deeper.
The final design compiles to tickets.
The model implements; you verify against the spec you already agreed on.

The responsible move in 2026 isn’t “move fast and iterate.” It’s get it right, then let the machine move fast.

Vertical Slice Architecture Webinar

Thu, 23 Jul 2026 18:57:00 +0000

Next month I'm hosting a free webinar on Vertical Slice Architecture, DDD, and how they fit in with AI-assisted development. I, like a lot of developers, have embraced AI assistance for designing and building systems. While these tools can accelerate the creation of code, they don't necessarily create malleable or maintainable code. This has real-world impacts on the systems we build - burning tokens on long review cycles, introducing bugs, or simply complexity, rather than value-add features. In this webinar, I'll show how VSA can shorten those cycles by reducing side-effects and coupling in your systems.

The webinar is next month (August 20th) and you can register for free here:

Vertical Slice Architecture: Effective Guardrails for AI Development

Hope to see you there!

AutoMapper 16.2.0 and MediatR 14.2.0 Released

Thu, 02 Jul 2026 14:09:17 +0000

Today we released the 16.2.0 version of AutoMapper and 14.2.0 version of MediatR:

This release is a bit more enterprise-focused, with extensions for setting the license keys via environment variables, fixing some threading issues around license key validation, and including more security-related items on releases (SBOMs, etc.)

These last few releases have been targeting items more or less required for enterprises consuming commercial packages. In the next release, we'll be more focused on adding features and fixing historical bugs.

Enjoy!

23 Models, One Weekend, Final Picks

Sat, 06 Jun 2026 12:00:00 +0000

Part 5 of 5 in the Local LLM Bench series.

The project started with ten models and two prompts. It ended with 23 models, a 13-point scoring harness, 3 Python agentic tasks, and more surprises per hour than I expected. This is the final leaderboard and the honest verdict.

Expanding to 23 Models

After the initial ten-model run, I pulled thirteen more based on a mix of research agent recommendations and community signals. The research was right about some things and wrong about others.

It correctly killed two obvious traps. qwen2.5vl is a vision model, not a coder — the “vl” should have been the clue but I wanted confirmation. qwen3.5:27b is a thinking model that burns its token budget on internal reasoning before producing output; on 16GB VRAM with a standard context budget it hits the wall and times out on every agentic task. Both of those were correct calls.

Then there was cogito:14b. The research said: skip it, superseded, runs 2-3 points behind qwen2.5. I almost listened. What actually happened when I ran cogito: 11-second code generation on the fizzbuzz task, 100/100 agentic score, both edit formats working cleanly. The research was wrong. Cogito turned out to be the fastest sweet-spot model I tested, and it passed tasks that models with higher single-shot scores failed entirely.

Two tag hallucinations also surfaced during pulls. qwen3.5:9b doesn’t exist — only the 27B is available. qwen3-vl:8b doesn’t exist — only the 235B is available. The research had the right model families but invented specific version tags. The fix is always the same: check ollama.com/library before pulling. Don’t trust a model recommendation that includes a specific tag without verifying.

The Pi Harness Experiment

Alongside the expanded model pool, I tested a different agentic harness entirely. Pi is fundamentally different from aider: instead of receiving structured edit instructions, the model gets direct Bash tool access and can run dotnet new, dotnet test, and anything else itself. It operates as an autonomous loop rather than a guided editor.

I ran devstral and qwen3-coder through pi on two tasks: fizzbuzz-plus and csv-parser. Both timed out at 1020 seconds. Not close calls — full exhaustion, zero useful output across both models and both tasks.

The root cause is that pi is designed for models fine-tuned for tool-calling loops: NousResearch Hermes-class, OpenClaw, models explicitly trained to keep calling tools autonomously and self-terminate when done. Devstral and qwen3-coder via Ollama’s OpenAI-compat API don’t have that fine-tuning. They can use tools when prompted, but they don’t have the trained instinct to keep invoking tools in sequence until a test passes.

The thing pi taught me even while failing: harness design is not neutral. An aider task prompt and a pi task prompt are different programs. The model receives different inputs, operates under different constraints, and requires different trained behaviors to succeed. A 100/100 aider score does not predict pi performance, and vice versa. If a Hermes-class model shows up in Ollama’s library with solid benchmark numbers, pi is worth revisiting. Until then, aider is the right tool for local 14-30B models.

The Scoring Expansion

The harness also grew. I extended the single-shot tests from 10 to 13 points by adding three new probes: a math word problem (3 apples at $0.50 plus 4 oranges at $0.75, reply with only the dollar amount), a JSON output test (return a JSON array of 3 programming languages, nothing else), and a sequence test (output 1 through 5, one per line, nothing else).

These three tests turned out to be more discriminating than I expected. Ten of twenty-three models fail the $4.50 math test — not because they get the arithmetic wrong, but because they reason aloud about the problem instead of answering it. The sequence test catches models that follow instructions in general but can’t suppress the urge to add a brief explanation. The JSON test catches models that can’t stop themselves from wrapping output in markdown fences when explicitly told not to.

None of these tests are hard. All of them reveal something real about how a model behaves when you need it to produce structured output on command.

Three New Python Agentic Tasks

The agentic suite expanded to include three Python tasks alongside the existing C# work. The tasks: a markdown-to-html converter (implement md_to_html(), 10 pytest tests covering headers, bold, italic, inline code, and links), a JSON validator (implement validate(data, schema) returning error strings, 9 pytest cases covering required fields, type checking, and enum validation), and a word-frequency counter (implement top_words(text, n) returning top-N tuples sorted by count descending then alphabetically, 8 pytest cases).

I ran these on seven models: devstral, qwen3-coder, phi4, hermes3, qwen2.5-coder, mistral-small3.2, and codestral. The results reshuffled the leaderboard in ways the single-shot scores did not predict.

The Full Leaderboard

Model	Size	SS /13	Chat ms	Code ms	Agentic Best	Agentic Pass%
gemma4:latest	~12B	12/13	6,918	603	20/100	0% (0/2)
devstral:latest	~24B	11/13	16,875	3,246	100/100	83% (5/6)
gemma4:26b	26B	11/13	11,029	3,255	20/100	0% (0/2)
qwen3.5:27b	27B	11/13	24,810	7,222	20/100	0% (timeout)
deepseek-r1:14b	14B	10/13	6,286	561	—	—
glm-4.7-flash	30B MoE	10/13	8,843	2,531	20/100	0% (timeout)
granite4:32b-a9b-h	32B MoE	10/13	20,885	3,125	20/100	0%
qwen2.5:14b	14B	10/13	6,221	475	10/100	0%
qwen2.5vl:7b	7B	10/13	5,783	863	—	—
qwen3-coder:30b	30B	10/13	9,948	2,143	100/100	67% (4/6)
qwen3:14b	14B	10/13	3,876	523	20/100	0%
cogito:14b	14B	9/13	6,447	438	—	—
hermes3:latest	~8B	9/13	3,756	280	100/100	40% (2/5)
mistral-small3.2:24b	24B	9/13	12,169	3,228	100/100	100% (3/3)
mistral:latest	7B	8/13	3,335	323	20/100	0%
codestral:22b	22B	7/13	17,182	2,427	100/100	67% (2/3)
deepseek-coder-v2:16b	16B	7/13	6,516	298	—	—
llava:7b	7B	7/13	4,045	292	—	—
magistral:24b	24B	7/13	22,802	11,568	—	—
gpt-oss:20b	20B	6/13	8,751	8,915	20/100	0%
phi4:14b	14B	6/13	6,415	466	100/100	50% (2/4)
qwen2.5-coder:14b	14B	6/13	5,989	529	100/100	100% (4/4)
qwen3:30b	30B	3/13	14,866	10,749	—	—

qwen3.5:27b, gpt-oss:20b, and deepseek-r1:14b are thinking models — they burn context on internal reasoning before producing visible output. The scores reflect that.

The Surprising Results

gemma4:latest. 12/13 single-shot, 603ms code generation, fastest chat in its size class. Zero percent agentic pass rate across every task it attempted. This is the sharpest split in the entire dataset. gemma4 is an excellent model for answering questions. It has no working mental model of “I am in a multi-turn loop writing files until tests pass.” Those are different capabilities. The single-shot tests reward the former. The agentic tasks require the latter. gemma4 nails one and is completely useless at the other.

mistral-small3.2:24b. I almost missed this one entirely. It had no agentic run history going into the final Python task batch — it just hadn’t come up in earlier experiments. When I finally ran it, it swept all three new Python tasks with 100/100 scores on first attempt, finishing each in 26 to 52 seconds. Nine out of 13 on single-shot. It had minimal community attention during the bench period. It turned out to be one of the two most reliable agentic performers I tested. The lesson here: community signal is a useful prior, not a substitute for running the test.

qwen2.5-coder:14b. 6/13 on single-shot. That score is a lie in the specific direction that matters most. The instruction-following tests fail consistently. The code generation test produces output that compiles but gets the wrong answer. On every agentic task I ran it on, it passed. Four for four, 100% pass rate. The single-shot harness penalizes its tendency to reason aloud before writing code. In an agentic loop, that verbosity doesn’t hurt — aider just waits for the edit block, and the edit block is correct. Single-shot actively mispredicts this model’s real-world utility.

hermes3:latest. 280ms code generation. The fastest model in the field by a significant margin, and at 4.7GB it’s the lightest serious option. 3,756ms average chat latency, also fastest. It scored 100/100 on csv-scaffolded with a 25-second wall time — another field record. Then it scored 10/100 on fizzbuzz and instant-failed on json-validator in zero turns. The inconsistency pattern makes sense for a model fine-tuned specifically for tool use and short completions: it handles the tasks that match its training profile well and falls apart outside them. For anyone doing rapid-fire chat or simple completions at scale, hermes3 is the answer. For general agentic coding, the brittleness is a real problem.

phi4:14b. 6/13 on single-shot; 100/100 on fizzbuzz and word-freq. It failed markdown-to-html and json-validator, and both failures have the same signature: 16 to 17% context utilization, then the output starts spiraling. phi4 has a 16K context ceiling, and tasks that grow their working context over multiple iterations hit that wall. The context limit is the only thing preventing phi4 from joining the reliable agentic tier. With 32K context or better, I’d expect it to pass everything it currently fails.

codestral:22b. The markdown-to-html task produced a unicode crash — aider’s display layer choked on an arrow character in a CP1252 terminal. json-validator and word-freq both passed 100/100. That markdown failure is an environment bug, not a model failure. I’m counting it in the pass rate because I can’t retroactively change the environment it ran in, but anyone testing codestral in a UTF-8 terminal should expect a different result.

The Actual Picks

For coding work on a 16GB machine, the answer depends on what you’re doing.

If you’re working in a new codebase — multi-file, complex scaffolding, scratch-to-working-tests — use devstral:latest. It’s the only model in this pool that reliably handles multi-file C# from scratch. 83% agentic pass rate across six diverse tasks spanning C# and Python. Not the fastest at 3 to 20 seconds per response, but it has the highest ceiling and it doesn’t fall apart on complexity.

If you’re working in an existing codebase — the actual everyday case, where you’re editing files that already exist — use qwen3-coder:30b. 100/100 on Python tasks, strong on scaffolded C#, 2-second code generation. The whole edit format is mandatory; diff mode fails silently and produces nothing. Get the format right and this model is very fast for its size.

If VRAM is the constraint, use qwen2.5-coder:14b. It runs on about 9GB, which means it fits alongside other processes. It passed every agentic task I ran it on. The 6/13 single-shot score is misleading — ignore it for agentic work.

mistral-small3.2:24b is on a watch list. Three tasks run, three passed. That’s not enough data to promote it above devstral for serious work, but it’s enough to keep it in the rotation. If it holds 100% across ten more tasks I’ll move it up.

For chat and Q&A, the picks are different. gemma4:latest for quality — 12/13, fast for its size, clean outputs. Don’t use it for anything agentic. For speed, hermes3:latest at 4.7GB and 280ms code generation is the answer, especially if you’re running it alongside something else or doing high-volume completions.

What Single-Shot Scores Actually Measure

This question came up enough during the project that it deserves a direct answer.

Single-shot scores measure whether a model understands what it’s being asked, can produce a well-formed response on one shot, and follows tight output constraints. That’s genuinely useful for chatting, summarizing, classifying, and answering questions. The score is predictive for those tasks.

What it does not measure: will this model keep working across turns, will it understand its own previous outputs, can it handle a tool returning an unexpected result, will it know when to stop and verify rather than spiraling, can it write files instead of prose. Those are the capabilities that determine agentic performance. They don’t show up in any single-prompt test because by design they can’t — they require multiple turns to observe.

The practical implication is that running a 13-point single-shot harness before picking a coding model will tell you roughly nothing about whether the model can actually do the coding work. You have to run the agentic task. There is no shortcut.

Closing

Six weeks. 23 models. 630 lines of harness code. 50+ agentic task runs. The answer to “which local model can actually code?” turns out to be a different question depending on what you mean by coding.

The model that tops the single-shot leaderboard is the one to use for chat. The model that wins at agentic coding tasks is a different model entirely. I spent a weekend thinking gemma4 was the obvious answer before it timed out on every real task I gave it.

The bench application and all results are at github.com/erichexter/ollama-model-bench. The harness accepts any model Ollama can serve — pull it, add an entry to the settings file, run it. The numbers here are reproducible on any machine with 16GB of VRAM. If you find something that beats devstral on multi-file from scratch, I want to know about it.

The Config That Changed Everything

Wed, 03 Jun 2026 12:00:00 +0000

Part 4 of 5 in the Local LLM Bench series.

After Part 3’s 1-in-6 pass rate, I had a theory about qwen3-coder. The model scored 0/100 not because it couldn’t write C#, but because aider couldn’t parse what it wrote. If the failure was format mismatch, then fixing the format should fix the score.

I was right. One line in a YAML file took qwen3-coder:30b from 0/100 to 100/100. Twenty-six seconds. Same model, same task, same hardware.

That result rewrites how I think about local model evaluation.

The edit_format Lever

aider supports two primary edit modes. In diff mode, the model sends back git-style patches — only the changed lines, with surrounding context. In whole mode, the model sends back the entire file contents. These are not stylistic preferences. They require completely different output from the model, and models are not equally capable of both.

The research I ran before Phase 9 turned up a finding I didn’t take seriously enough at the time: “harness mismatch is bigger than model choice.” One real-world study cited 6x performance variation purely from harness configuration changes, holding the model constant. I read that and thought it was probably overstated. Then I ran the A/B.

The .aider.model.settings.yml file lets you configure per-model settings. The critical field is edit_format. Here’s what qwen3-coder’s entry looks like after the fix:

- name: ollama_chat/qwen3-coder:30b
  edit_format: whole
  use_repo_map: false
  extra_params:
    num_ctx: 65536

Before this change: edit_format was unset, defaulting to diff. After: whole. The model behavior changes completely.

The A/B Results

I ran six models against both formats on the fizzbuzz-plus sweet-spot task:

Model	whole	diff
qwen3-coder:30b	100/100 (26s)	0/100 FAIL
devstral:latest	100/100 (53s)	100/100 (98s)
qwen2.5-coder:14b	100/100 (73s)	100/100 (65s)
gpt-oss:20b	20/100 FAIL	20/100 FAIL
qwen3:14b	20/100 FAIL	20/100 FAIL
mistral:latest	20/100 FAIL	20/100 FAIL

Three models work. Three models don’t. The format A/B cleanly separates the populations. gpt-oss, qwen3:14b, and mistral fail in both formats — those are genuine capability problems, not configuration problems. qwen3-coder was a false negative: the code was right, the format was wrong, the score said zero.

devstral and qwen2.5-coder work in both formats, which tells you something about their training. They’ve been explicitly tuned to produce structured edit blocks. qwen3-coder has not — or at least not in the diff format aider expects. Switching to whole file output removes the constraint entirely: just dump the file, let aider handle the diff computation. qwen3-coder is very good at writing complete, correct files.

The Thinking-Mode Problem

Three models that looked promising on paper — gpt-oss:20b, deepseek-r1:14b, and qwen3.5:27b — share a different failure mode. They all run in “thinking mode”: before producing any code output, they generate thousands of internal reasoning tokens. On single-shot tasks this is invisible; the <think> block appears in a separate field and the user only sees the final answer. On an agentic task with a 300-second timeout, the thinking block alone can exhaust the budget.

gpt-oss, deepseek-r1, and qwen3.5 all timeout at zero turns — the model thought itself to death before writing a single line of code.

The fix for qwen3 models (not qwen3.5, which has different training) is a /no_think prefix in the aider system prompt:

- name: ollama_chat/qwen3:14b
  edit_format: whole
  system_prompt_prefix: "/no_think"
  use_temperature: 0.7
  extra_params:
    num_ctx: 32768
    top_p: 0.8
    top_k: 20

This worked for qwen3:14b and qwen3:30b. It does nothing for qwen3.5 — different model family, different training, the prefix is ignored. qwen3.5:27b is a 17GB model on 16GB VRAM, so it’s partially spilling to RAM anyway. At mixed CPU/GPU generation speed with a thinking block running first, it cannot produce useful output inside 300 seconds. The hardware ceiling and the thinking penalty compound each other. Model eliminated.

The num_ctx Revelation

Ollama’s default context window is 2048 tokens. That’s not 2048 for the task — that’s 2048 for the entire conversation, including the system prompt, the file content, the task description, and every prior exchange. For an agentic coding session where aider is sending file contents back and forth, 2048 fills in two or three turns. After that, the model is working with a truncated view of its own conversation. It starts looping, contradicting itself, or deleting code it just wrote.

Ollama doesn’t warn you when it truncates. It silently discards the oldest tokens and keeps going. The model’s outputs start looking confused on turn three and you assume it’s a capability problem. It isn’t.

Setting num_ctx: 32768 (or 65536 for the larger models) unlocks stable multi-turn behavior. Several failures that looked like model confusion were actually context truncation. The fix is one line per model in the YAML.

The Architect Mode Dead End

I wanted to test whether combining two models — one to plan, one to implement — could improve results on stretch-tier tasks. aider calls this “architect mode.” In principle: the architect model breaks the task into pieces, the editor model writes the code, and the combination should outperform either alone. It’s a reasonable theory. The machine had other plans.

Loading two 14-17GB models on 16GB VRAM means constant unloading and reloading. Every time control switches from architect to editor, Ollama has to evict one model and load the other. That swap is not fast. I ran devstral + qwen3-coder and devstral + qwen2.5-coder. Both pairs hit the five-minute timeout at zero turns. The entire budget went to model swap overhead before a single tool call completed.

Architect mode requires both models to be co-resident in VRAM. On 16GB, that means two models totaling at most 16GB, which limits you to two 7B models — too small to be useful on complex tasks. The minimum viable VRAM for architect mode with 14B+ models is 32GB. Below that, single-model runs strictly better.

The Scaffolding Experiment

After the format A/B produced clear winners, I wanted to understand what was really limiting the failing models on the csv-parser task. The task asked models to build a C# console app and test project from scratch — which means creating .csproj files, a solution file, adding project references, restoring NuGet packages, and then writing correct C#. That’s two separate problems: .NET project plumbing and C# logic.

I split them apart. The scaffolded version of the task pre-creates everything: both .csproj files with correct net10.0 targets, a Program.cs entry point the model doesn’t touch, a stub CsvProcessor.cs with a TODO comment, a test project with a NuGet reference already wired, and stub test method shells. dotnet restore runs before the model starts. The model’s job is to implement one static method and fill in five test bodies.

Model	From-scratch	Scaffolded	Change
devstral:latest	70/100	90/100	+20
qwen3-coder:30b	0/100	90/100	+90
cogito:14b	0/100	10/100	+10
granite4:32b-a9b-h	0/100	10/100	+10

qwen3-coder was never broken. Its 0/100 on the from-scratch task was entirely a scaffolding failure. It doesn’t know how to create a .NET solution structure from the command line — that’s a DevOps problem, not a C# problem. Given the structure, it writes correct C# and correct tests in one shot, in 56 seconds. That’s four times faster than devstral on the same task.

cogito:14b and granite4:32b-a9b-h still fail on the scaffolded version. Their problem is C# reasoning, not project structure. The scaffolding experiment drew a clean line between the two failure modes.

The practical implication: if you’re deploying these models on an existing codebase — the actual real-world use case — the scaffolding problem doesn’t exist. The codebase is already there. qwen3-coder becomes a genuine competitor to devstral for existing-codebase work.

Where the Leaderboard Stands

After format configuration, context window fixes, and scaffolding experiments, the picture looks like this:

For sweet-spot tasks (one or two files, existing codebase, 80-120 lines of code): qwen3-coder:30b at 26 seconds, cogito:14b at 11 seconds on both formats, devstral at 53 seconds, mistral-small3.2:24b at 44 seconds, and qwen2.5-coder:14b at 73 seconds. Five models that work reliably.

For multi-file from scratch: devstral:latest, confirmed against eight challengers. No other local model in this weight class completes the csv-parser task reliably regardless of configuration.

Eliminated regardless of configuration: gemma4 (all variants), glm-4.7-flash, qwen2.5:14b, qwen3:14b, qwen3.5:27b, deepseek-r1, gpt-oss, magistral — all timeout or fail in both formats. These aren’t configuration problems. They’re either the wrong model type (thinking models on a 16GB budget), capability gaps, or both.

The 6x performance variation claim from the research turned out to be conservative in at least one case. qwen3-coder went from zero to perfect. You can’t express that as a multiplier.

Next up: Part 5 — expanding the model pool, three surprise entries that research told me to skip, and the final leaderboard after 23 models across six weeks of testing.

Single-Shot Lies

Sun, 31 May 2026 12:00:00 +0000

Part 3 of 5 in the Local LLM Bench series.

gemma4:latest scored 10/10 on every test I built. Perfect chat response. Perfect code generation. Perfect tool call. Perfect instruction following. I ran it twice to be sure. Same result. So naturally, when it came time to run the first real agentic coding task, that was the model I reached for.

It produced zero lines of useful code in ten minutes.

That’s the story of Phase 8, and it changed everything about how I think about model evaluation.

The Task

The agentic benchmark I built is a CSV parser in C#. A console app that reads a file with Name and Score columns, prints the top 3 scores descending, ties broken alphabetically. Verify with dotnet test. The task is sized to what I’d call “stretch tier” — two projects, roughly 150 lines of code, multi-file, requires the model to scaffold a .NET solution from scratch and then implement correct logic. A competent human developer does this in about ten minutes.

The harness is aider 0.86.2 installed via uv tools, running headless with --yes-always --exit --message-file. Scoring: 60 points if the verify command passes, 20 if the model finishes in two iterations or fewer, 10 for no compile errors, 10 for clean edit format. 100 points maximum.

I ran six models: the top performers from Phase 4’s single-shot benchmark plus two new additions.

The Results

Model	Score	Notes
devstral:latest	70/100	5 iterations, 147 seconds
gemma4:latest	20/100	600 second timeout, 0 turns
gemma4:26b	20/100	600 second timeout
glm-4.7-flash	20/100	600 second timeout
qwen2.5:14b	10/100	91 seconds, never recovered
qwen3-coder:30b	0/100	77 seconds, garbled output

One passes. Five fail. The model that aced every single-shot test I designed hits its ten-minute wall and produces nothing. The model that topped the leaderboard with a perfect score is the first casualty.

devstral is, notably, marketed specifically for agentic coding loops. That framing turned out to matter.

What Went Wrong With gemma4

gemma4:latest doesn’t fail because it can’t write C#. It fails because it doesn’t understand that it’s supposed to be writing files. When aider sends it a task, it responds with a description of what the code should look like, or it writes a fenced code block in prose, or it explains the approach in detail without producing any actual edits. I watched this happen in real time and it took longer than I’d like to admit before I understood what I was seeing. These responses look helpful if you’re reading them as a chat assistant. aider can’t do anything with them — it’s waiting for structured edit blocks that follow its protocol, not a tutorial.

The single-shot benchmark rewarded exactly the behavior that makes gemma4 useless in an agentic loop. “Write a Python function that checks if a number is prime” — gemma4 produces clean, correct Python instantly. But that task has one shot, one context, one output. There’s no concept of a multi-step session, no expectation that the model needs to write files into a directory, no loop where the model gets feedback and tries again.

Ask gemma4 to run a ten-minute coding session and it has no mental model for what “running a coding session” means. It’s a very good chat assistant. That’s not the same thing.

What Went Wrong With qwen3-coder

qwen3-coder:30b scores 0/100, which looks worse than the timeout failures. It’s actually more interesting. The model ran for 77 seconds before aider gave up, which means it produced output — just output that aider silently rejected as malformed edits. The code was probably fine. The format wasn’t.

This is a harness compatibility problem, not a capability problem. aider expects edit blocks in specific formats — either a diff-style patch or a whole-file replacement. qwen3-coder was emitting something that resembled neither cleanly enough for aider to parse. aider’s response to a malformed edit is to silently skip it, log nothing useful, and eventually exit. From the score sheet, it looks like the model produced nothing. That’s not what happened.

This distinction matters, because it’s a clue. If the failure is format mismatch rather than capability, changing the format instruction should fix it. I filed that away and moved on.

What It Means

The research literature on agentic coding benchmarks describes a roughly 17% pass rate for 14-30B parameter models on what they call “stretch tier” tasks: multi-file, 150+ lines of code, multiple tool-call iterations. My six-model run hit 1-in-6. Exactly 17%.

That number didn’t come from luck. It came from the same thing the research describes: most models that can answer questions well don’t have a working mental model of “I am operating a computer, I need to write files, I need to keep doing work until a test passes.” Those are different cognitive tasks. Single-shot chat benchmarks don’t distinguish between them.

The models that time out aren’t slower or dumber than devstral. They’re not designed for this. gemma4 is optimized to produce a high-quality response to a question. devstral is optimized to take a task and not stop until it’s done. The training objectives are different. The behavior is different. The single-shot score captures none of that.

Where This Leaves Us

devstral finished the task with 70/100. It needed five iterations instead of two (losing 20 points on the efficiency score), but it shipped working code. None of the other five models produced a single passing test.

The 70/100 score isn’t a ceiling — it’s a baseline. devstral used the default aider configuration with no tuning. It worked anyway. The question is whether anything else can be made to work, or whether devstral is the only local model that can do this at all.

qwen3-coder’s format failure points toward an answer. If the problem is configuration, not capability, then changing the configuration should change the result. That’s the experiment Part 4 runs.

Next up: Part 4 — one config change takes a model from 0/100 to 100/100, and the harness turns out to matter more than the model.

Building a .NET 10 Benchmark Harness

Thu, 28 May 2026 12:00:00 +0000

Part 2 of 5 in the Local LLM Bench series.

The PowerShell script from part one did its job. It surfaced the think-mode problem, sorted out which models could call tools, and gave me rough latency numbers. But it could not tell me whether the code models wrote was actually correct — I was reading output and deciding it looked fine, which is not the same thing as running it.

What I needed was a harness that ran models against defined tasks, verified the outputs mechanically, and produced a repeatable score. I’m a C# developer. .NET 10 was already on the machine. The choice was not a choice.

Architecture

The project is a .NET 10 console application. The core pieces are:

OllamaRunner is a thin HTTP wrapper around Ollama’s /api/generate and /api/chat endpoints. Every request goes out with temperature=0, seed=42, and think=false. Temperature zero makes results deterministic enough to compare across runs. The seed locks that in further. The think flag is false by default — models that need it explicitly will be detected and handled.

RoslynEvaluator handles the SumEvens code test in-process. It takes whatever the model returns, strips any markdown fences, wraps the bare method in a class, and hands it to the Roslyn CSharp scripting API to compile and execute. If it compiles and SumEvens(new[] {1,2,3,4,5}) returns 6, the model passes. This runs entirely in memory with no disk I/O and no subprocess.

TempProjectRunner is where it gets more serious. This component scaffolds actual temporary dotnet projects, writes model-generated code into them, builds them with dotnet build, and runs them with dotnet run. It checks stdout for the expected output. For the test suite portion, it scaffolds a second project alongside the first, adds a project reference, drops in model-generated xUnit test code, and runs dotnet test. Every project is cleaned up from the temp directory when the run completes.

Scorer orchestrates the sequence — chat test, code test, tool test, instruction test, reasoning test, JSON output test, sequence test, Hello World test — and assembles the results into a ModelResult record.

ModelResult is a straightforward C# record type. Every boolean metric is a property; TotalScore is a computed getter that sums them. The record also carries timing in milliseconds for each test category and a ThinkRequired flag that is informational only and does not affect the score.

ConsoleReporter prints the final table to the terminal with ANSI color coding. ResultStore writes the raw results to results/model-results.json and a human-readable markdown ledger to results/RESULTS.md after each run.

The Code Tests

The first code test is SumEvens: write a C# method that takes IEnumerable<int> and returns the sum of even numbers. Return only the method, no class, no namespace, no explanation. This is deliberately narrow. The narrow scope is the point — it is testing whether a model can follow output constraints and write code that compiles and produces correct results, not whether it can write impressive prose around the code.

RoslynEvaluator wraps the method in a class, invokes it with {1, 2, 3, 4, 5}, and checks that the result is 6. Compile error means the model scores zero on both compile and correct. Compiles but returns the wrong number means compile point awarded, correct point denied. Compiles and returns 6 means full credit.

Hello World: The Real Test

The Hello World test is where I learned something useful. The prompt asks the model to write a complete C# console application: a Greeter class with a public static GetGreeting() method that returns "Hello, World!", plus a Main method or top-level statements that calls it and prints the result. Separately, it asks the model to write xUnit tests for that Greeter class.

TempProjectRunner scaffolds a dotnet new console project, replaces Program.cs with whatever the model generated, runs dotnet build, then dotnet run, and checks stdout for "Hello, World!". For the test portion, it scaffolds a dotnet new xunit project in the same temp directory, adds a project reference to the app, drops in the model’s test code as GreeterTests.cs, runs dotnet build, and then dotnet test.

This turns out to be an excellent proxy for whether a model understands C# project structure. Writing a method is straightforward. Writing a complete application that builds from scratch against a specific framework target, with a class in a form that a separately compiled test project can reference — that is a different problem. Models that understand C# project conventions get it right on the first try. Models that pattern-match on superficial features tend to include the wrong using statements, declare the class in a namespace that the test code does not account for, or produce an entry point that conflicts with the Greeter class definition.

Each step is gated: if the app does not compile, neither the output check nor the test run happens. If the tests do not compile, the pass/fail result is not recorded. Partial credit is possible — a model can build the app but write tests that compile and then fail at runtime, earning two of the four Hello World points.

Scoring

The 10-point scoring breakdown for the initial complete run:

Category	Points
Chat response (non-empty, sensible)	1
SumEvens compiles	1
SumEvens correct	1
Tool call supported (not HTTP 400)	1
Tool call valid (structured, correct function)	1
Instruction followed (exactly three words)	1
Hello World app compiles	1
Hello World app correct output	1
Hello World tests compile	1
Hello World tests pass	1

After the initial runs I extended the suite with three more tests, bringing the maximum to 13: a reasoning test (a word problem with an exact numeric answer — $4.50, no other text), a JSON output test (produce a valid JSON array of at least three programming language names), and a sequence test (output the numbers 1 through 5, one per line, nothing else). All three are binary pass/fail with no partial credit. The reasoning and sequence tests catch models that ignore output constraints even when the constraint is explicit. Several did.

Unit Tests

The test project covers 13 cases across five test classes. ModelResultTests verifies that the scoring logic is correct — all true returns the expected sum, all false returns zero, ThinkRequired does not affect the score. RoslynEvaluatorTests covers the markdown fence stripping and three evaluation cases: correct implementation, wrong result, and garbage input. ScorerTests uses a MockRunner that replays canned responses and verifies that the Scorer assembles the ModelResult correctly for the pass case, the tool-rejected case, and the instruction-failure case. ConsoleReporterTests confirms that PrintTable does not throw with null prior results or when a model has regressed since the previous run.

None of these tests require a running Ollama instance. The mock runner pattern makes the Scorer fully testable without any external dependencies.

First Complete Run

Thirteen models, ten metrics each. This is what came back:

Model	Score	Notes
gemma4:latest	10/10	Clean sweep
glm-4.7-flash	9/10
gemma4:26b	8/10
qwen2.5:14b	8/10
devstral:latest	7/10
qwen3-coder:30b	7/10
qwen3:14b	7/10
mistral:latest	6/10
gpt-oss:20b	5/10	think_required detected
phi4:14b	5/10
llava:7b	5/10
qwen2.5-coder:14b	4/10
qwen3:30b	3/10

gemma4:latest — a ~12B parameter model — scores 10 out of 10. It answers the chat question, writes SumEvens correctly, emits a proper tool call, follows the three-word instruction, builds the Hello World app, writes tests that compile and pass, gets the math problem right, produces valid JSON, and outputs the sequence with no extra text. On every metric the harness defines, it is the best model in the pool by a clean margin over everything larger than it.

The result is worth sitting with. A model less than half the size of qwen3:30b outscores it by seven points. glm-4.7-flash is a 30B MoE and comes in second at 9/10. The coding-focused variants — qwen2.5-coder and qwen3-coder — score lower than their general-purpose counterparts at similar sizes.

The obvious interpretation is that gemma4:latest is simply the best model here. The problem is that the harness measures what I built the harness to measure. Before drawing that conclusion, I need to know whether these metrics are the right metrics.

The full source is at github.com/erichexter/ollama-model-bench.

Next up: Part 3 digs into what the scores actually mean — and why gemma4:latest’s clean sweep turned out to be almost entirely beside the point.

Search — The Evolution of the Karpathy LLM Wiki

Tue, 26 May 2026 12:00:00 +0000

My LLM notes wiki outgrew file reads. Agents were pulling entire files to find a single relevant section — burning tokens on context that didn’t matter, missing things that were buried three pages deep. The corpus had just grown past the point where IO-based access was practical.

The fix was search. And since agents need tools, the obvious move was to build it as an MCP server. But if you’re building search anyway, plain keyword matching felt like leaving half the value on the table — too easy to miss conceptual matches that don’t share exact terms. So: something old and something new. SQLite already has FTS5. sqlite-vec adds HNSW vector search as a loadable extension. Ollama runs the embedding model locally. Put them together and you get hybrid RAG on hardware you already own, exposed as an MCP tool any agent in the fleet can call.

This post covers how it’s built — starting from what the agent sees and working inward to the SQL and vector embeddings.

What the Agent Sees

From the agent’s perspective, this is just an MCP server with a set of tools. Point an .mcp.json at the host and the tools are available. No setup, no SDK, no awareness of what’s running underneath.

The primary tool is search_knowledge:

{
  "method": "tools/call",
  "params": {
    "name": "search_knowledge",
    "arguments": {
      "query": "attention mechanism scaled dot product",
      "top_k": 5,
      "hybrid_alpha": 0.6,
      "sources": ["karpathy-wiki"]
    }
  }
}

The response comes back as ranked chunks with source context:

{
  "content": [{
    "type": "text",
    "text": "[
      {
        \"text\": \"Scaled dot-product attention divides the dot products by √d_k to prevent vanishing gradients in high dimensions...\",
        \"source\": \"karpathy-wiki\",
        \"relPath\": \"transformers/attention.md\",
        \"score\": 0.91,
        \"frontmatter\": { \"tags\": [\"attention\", \"transformers\"] }
      },
      ...
    ]"
  }]
}

The agent gets ranked text chunks, source file paths, and scores. It doesn’t need to know whether the result came from a vector search or keyword search — that’s the server’s problem.

The Full Tool Set

Seven tools in total. search_knowledge covers 95% of use.

Tool	Purpose
`search_knowledge`	Hybrid vec+FTS search across one or more sources.
`get_page`	Retrieve a full page by source + relative path. Use when search returns a partial chunk and you want the full document.
`list_sources`	Lists indexed sources with page/chunk counts and last-indexed timestamps.
`get_stats`	Query counts and latencies over 1h / 24h / 7d / 30d windows.
`get_query_log`	Recent query history. Useful for understanding what agents are actually asking.
`refresh_ingest`	Trigger immediate re-indexing for a source after a write.
`ping`	Returns current UTC. Health check.

list_sources is underrated as a diagnostic. A 200 response from the API tells you nothing about whether the index is populated. If results are poor, check pageCount > 0 and that lastIndexed is recent before assuming the search logic is wrong.

The `hybrid_alpha` Parameter

This is the control knob for the blend between vector search and full-text search.

0.0 — pure FTS (BM25 keyword ranking)
1.0 — pure vector (semantic similarity)
0.5 — equal blend (default)

In practice, 0.6–0.7 (vector-weighted) works better for conceptual queries: “how does attention scale with sequence length.” Drop toward 0.3 when you need an exact term match that the embedding model might paraphrase: specific function names, error codes, version numbers.

How the Search Works

When search_knowledge is called, the server runs two queries in parallel and merges the results.

var vectorTask = SearchByVector(embeddingVector, topK * 2, sources);
var ftsTask    = SearchByFts(query, topK * 2, sources);

await Task.WhenAll(vectorTask, ftsTask);

var merged = Merge(vectorTask.Result, ftsTask.Result, hybridAlpha, topK);

The merge step normalizes each result list’s scores to [0, 1], applies the alpha weight, sums scores per chunk (a chunk can appear in both lists), and returns the top K. Normalization matters — BM25 and HNSW distance are on completely different scales. Skip it and one path dominates every query regardless of alpha.

Before either query runs, the search query itself gets embedded:

POST http://<ollama-host>:11434/api/embeddings
Content-Type: application/json

{
  "model": "nomic-embed-text:latest",
  "prompt": "attention mechanism scaled dot product"
}

That gives back a 768-dimensional float vector — what the vector search runs against.

The Vector Query

sqlite-vec exposes vector search through a virtual table with a MATCH clause. Under the hood it’s doing an approximate nearest-neighbor scan via HNSW:

SELECT c.id, c.body, c.source, c.rel_path, c.frontmatter,
       cv.distance
FROM chunk_vecs cv
JOIN chunks c ON c.id = cv.chunk_id
WHERE cv.embedding MATCH :embedding
  AND cv.k = :k
  AND (:sources IS NULL OR c.source IN :sources)
ORDER BY cv.distance;

distance here is L2 distance — lower is closer. sqlite-vec handles all the index internals; from the query side it looks like a regular SQL query.

The FTS Query

Standard SQLite FTS5 with BM25 ranking:

SELECT c.id, c.body, c.source, c.rel_path, c.frontmatter,
       bm25(chunk_fts) AS fts_score
FROM chunk_fts
JOIN chunks c ON c.id = chunk_fts.rowid
WHERE chunk_fts MATCH :query
ORDER BY bm25(chunk_fts)
LIMIT :k;

FTS5’s MATCH supports phrase queries, prefix matching, and boolean operators. For agent queries coming in as natural language, the server sanitizes the input to a simple term query before passing it to MATCH.

The Data Model

Three tables carry the retrieval workload:

-- Chunked text with metadata
CREATE TABLE chunks (
    id          INTEGER PRIMARY KEY,
    page_id     INTEGER NOT NULL REFERENCES pages(id),
    chunk_index INTEGER NOT NULL,
    body        TEXT    NOT NULL,
    token_count INTEGER,
    source      TEXT,
    rel_path    TEXT,
    frontmatter TEXT
);

-- Vector index (sqlite-vec extension)
CREATE VIRTUAL TABLE chunk_vecs USING vec0(
    chunk_id INTEGER PRIMARY KEY,
    embedding FLOAT[768]
);

-- Full-text search index (FTS5, built into SQLite)
CREATE VIRTUAL TABLE chunk_fts USING fts5(
    body,
    source    UNINDEXED,
    rel_path  UNINDEXED,
    content='chunks',
    content_rowid='id'
);

chunk_vecs is a sqlite-vec vec0 virtual table — INSERT a row with the chunk ID and its 768-dim embedding, sqlite-vec maintains the HNSW index internally. chunk_fts is a content-backed FTS5 table that stays in sync with chunks via triggers.

Supporting tables: pages (source files with hash-based change detection), indexer_runs (ingest audit log), query_log (query history for observability).

One SQLite file. No separate processes, no network hops between storage components, no backup complexity.

The Write Path

When a document is added or updated in the source directory, the indexer picks it up:

SHA-256 hash the file. Compare against pages.content_hash. Skip if unchanged.
Parse YAML frontmatter. Extract the body.
Split into chunks — 512-token target, 64-token overlap, break on paragraph boundaries where possible.
For each chunk: POST to Ollama /api/embeddings. Receive a 768-dim float array.
INSERT into chunks. INSERT into chunk_vecs. FTS5 trigger handles chunk_fts sync.
Update pages.content_hash and indexed_at.
Write a row to indexer_runs.

nomic-embed-text is 137M parameters — fast on a GPU host, single-digit milliseconds per chunk. The indexer pipelines requests; Ollama queues them.

Gotchas

The embed model context limit is a silent failure.

nomic-embed-text has an 8K token context window. Chunks that exceed it are silently not embedded — present in chunks, retrievable via get_page, invisible to vector search. No error from Ollama. Enforce the chunk size limit at ingest time. Symptom check:

SELECT p.rel_path, p.source, LENGTH(p.content) A



Which Local Models Can Actually Code?
Mon, 25 May 2026 12:00:00 +0000
Part 1 of 5 in the Local LLM Bench series.

I had ten local models installed and no good answer to a simple question: which of them could actually do useful work? Chat demos are easy to fake. I wanted to know whether these models could write working code, call tools correctly, and follow instructions without needing hand-holding. The only way to find out was to run them.

The Setup

Machine is an Alienware Windows 11 box with an RTX 5080 carrying 16GB of VRAM. Ollama is running locally, serving the following ten models:


  mistral:latest (7B)
  llava:7b (7B, vision)
  gemma4:latest (~12B)
  gemma4:26b (26B)
  qwen3:14b (14B)
  qwen3:30b (30B)
  phi4:14b (14B)
  qwen2.5:14b (14B)
  qwen2.5-coder:14b (14B, coding-focused)
  glm-4.7-flash (30B MoE)


The size range alone tells you the hardware story. Anything under about 20B fits in VRAM comfortably. The 26B and 30B models spill onto system RAM — which you feel in the latency numbers.

First Pass: Two Prompts, PowerShell

The first script was about as minimal as it gets. Two prompts per model: “What is the capital of France?” to confirm the model is responding at all, and “Write an is_prime() function in Python” as a basic code generation check. No scoring, no verification — just checking that something came back.

Most models answered both prompts without incident. Then I hit the bigger ones. gemma4:26b, glm-4.7-flash, and qwen3:30b all returned empty responses. Not errors — the HTTP calls succeeded, Ollama said everything was fine, the responses just contained no text.

That took longer than it should have, and the answer was different for each model.

The Think-Mode Wall

qwen3 models support a reasoning mode where the model works through a problem step by step before producing visible output. The reasoning tokens live inside <think>...</think> blocks and don’t count against the response. What does count against the response is the token budget, and when I was requesting with a tight num_predict limit, the model was spending the entire budget on internal reasoning and returning nothing to the caller. glm-4.7-flash has its own variant of the same mode — different model family, same symptom.

The fix for both: add "think": false to the request body. With that flag set, qwen3:14b went from returning a blank response to producing clean, working code in about 2 seconds. The qwen3 and glm models followed.

gemma4:26b’s blank responses were a separate problem entirely. At 26B it spills to RAM, and with a tight num_predict budget and slow generation speed, the script’s read timeout was firing before any tokens arrived. More headroom fixed it.

The lesson here is that “model returned empty string” and “model failed” are not the same thing, and you have to understand what each model family expects before you can interpret the output.

Tool-Calling: Where Things Got Interesting

Once the basic chat and code tests were passing, I added a tool-calling test. The prompt was “What’s the weather in Paris?” with a get_weather function schema attached to the request. A model that handles tool calling correctly should stop generating text and instead emit a structured tool_calls object pointing at get_weather with the right argument. A model that doesn’t understand the protocol either returns prose (“I don’t have access to weather data”), returns a JSON blob as plain text, or refuses the request entirely with an HTTP 400.

The results split into three clear buckets. mistral, gemma4 (both sizes), qwen3:14b, qwen2.5:14b, and glm-4.7-flash all produced proper structured tool_calls. That is the expected behavior — the model uses the tool schema as intended.

qwen2.5-coder:14b was the interesting failure. It returned what looked like a tool call, but as a raw JSON string embedded in the message content rather than as a structured tool_calls entry. The model clearly understood what was being asked; it just didn’t output it in the right format. A “coder” model is not necessarily a “tool-aware” model. They are different capabilities.

llava:7b and phi4:14b both returned HTTP 400 on any request that included the tools field. Those models simply do not accept the parameter — the API rejects it before the model even sees the prompt. llava makes sense here: it is a vision model, not a chat/agent model. phi4 is less obvious.

Mid-Phase Additions

While working through these tests I pulled in three more models that had come up in research as strong candidates for coding benchmarks: devstral:latest (22B, Devstral Small — Mistral’s coding-focused release), qwen3-coder:30b (~30B, Qwen’s coding-tuned variant), and gpt-oss:20b (~20B). All three were added before the formal scoring phase started.

The Baseline Table

Here is where every model stood after the initial phase — response times are wall-clock from the PowerShell script, rounded to the nearest second:


  
    
      Model
      Size
      Chat
      Code
      Tool call
      Notes
    
  
  
    
      mistral:latest
      7B
      3s
      1s
      proper
       
    
    
      llava:7b
      7B
      4s
      <1s
      rejected
      Vision model
    
    
      gemma4:latest
      ~12B
      6s
      1s
      proper
       
    
    
      qwen3:14b
      14B
      4s
      1s
      proper
      think=false required
    
    
      phi4:14b
      14B
      5s
      1s
      rejected
       
    
    
      qwen2.5:14b
      14B
      6s
      1s
      proper
       
    
    
      qwen2.5-coder:14b
      14B
      6s
      1s
      text (not structured)
      “coder” does not mean tool-aware
    
    
      gemma4:26b
      26B
      9s
      3s
      proper
      Partial CPU offload
    
    
      glm-4.7-flash
      30B MoE
      8s
      4s
      proper
       
    
    
      qwen3:30b
      30B
      14s
      8s
      proper
      Slowest in pool
    
  


The latency numbers tell one story — size matters, mostly predictably. The tool-call column tells another: ten models, three different behaviors from the same input, and two of them would silently fail in any agentic loop that expected structured output.

What “Works” Actually Means

The issue with this baseline is that “passes” hides a lot. A model that returns a tool call in the message content instead of the tool_calls field looks fine until your application tries to deserialize the response. A model that works at num_predict=300 might silently truncate at num_predict=100. A model that answers “capital of France” correctly might write Python is_prime() that has an off-by-one error nobody noticed because nobody ran it.

Everything in this phase was manual inspection. I was reading outputs and deciding they looked reasonable. That is not a test; that is a vibe check.

The only way to actually know whether a model can write working code is to compile and run the code. Which meant building something more serious.



Next up: Part 2 covers building the .NET 10 benchmark harness — including a scoring system that actually executes model-generated C# and runs the tests.


Back from the dead
Sat, 23 May 2026 12:00:00 +0000
Twelve years. My last post here was April 2014, and I closed it by
promising “painstaking detail in the coming months” on what my team
was building. Then I wrote exactly zero of those posts. Sorry about
that.

A lot has changed — starting with the site itself. When I last hit
publish, lostechies.com was running on WordPress. Today it’s a Jekyll
static site, hosted on GitHub Pages, and posting means committing a
markdown file to lostechies/blog.
Which is honestly delightful. No login, no editor, no plugin upgrades.
Write, commit, ship.

In that spirit of bringing old things back to life: I also just
revived Should, the assertion
library I built way back when. It’s been dragged forward into modern
.NET and is usable again. More on that in a follow-up post.

The bigger thing on my plate, though, is AI. I’ve been heads-down on
agent development and agent frameworks — building them, breaking them,
figuring out where the seams are. A few recent threads I’ve been
pulling on over on LinkedIn: the economics of AI software
delivery,
adversarial code reviews run by AI,
and why companies forget what they already know.
That’s most of what I want to write about going forward.

I’m not going to promise a posting cadence — I learned my lesson in

  But if you stumbled back here from an old MvcContrib link or a
2012 SignalR post: welcome. The blog isn’t dead. It just needed a
git push.



AutoMapper 16.1.1 Released
Fri, 13 Mar 2026 15:58:13 +0000
This release is a patch release to fix a thread deadlock and security issue. From the release notes:
Thread Deadlock
Thanks to @t0m-4 for reporting this issue, which due to Microsoft deprecating some of the "sync" APIs for decryption, led to potential thread starvation and locking issues. The update still has to use a "sync-over-async" pattern, but does so in a much safer manner.
Security
We fixed an issue where certain cyclic or self-referential object graphs could trigger uncontrolled recursion during mapping, potentially resulting in stack exhaustion and denial of service.
Applications that process untrusted or attacker-controlled object graphs through affected mapping paths may be impacted.
Users should upgrade to this release.
Security advisory: GHSA-rvv3-g6hj-g44x
Thanks to @bluefossa for responsibly disclosing this issue.


AutoMapper 16.1 and MediatR 14.1 Released
Tue, 03 Mar 2026 21:50:55 +0000
Today I released AutoMapper 16.1 and MediatR 14.1 (as part of now regular quarterly releases):
AutoMapper Release Notes
MediatR Release Notes
AutoMapper added some interesting features, allowing for factories and conditions to use dependencies (previously only allowing Func-based callbacks. On the MediatR side, we added support for more interesting generic use cases in complex generic hierarchies as well as a number of bugs squashed.
You can get the latest drops on NuGet. And a little celebration is in order - AutoMapper hit 1 billion downloads 🥳
Enjoy!


AutoMapper 16.0.0 and MediatR 14.0.0 Released with .NET 10 Support
Wed, 03 Dec 2025 21:23:28 +0000
With the release of .NET, we've released updated packages of AutoMapper and MediatR targeting .NET 10 (and all supported versions of .NET and 4.x of .NET Framework).
From this release forward, we're aligning to major release cadences of .NET since this also means upping our dependency versions as well. Minor versions will still happen throughout the year but upping dependencies often has just as many issues as breaking API changes so we want to align with that cadence to make it easier for folks to understand when things are changing.
This release doesn't have any API changes from the previous minor release, but we did add NuGet package signing:
NuGet package information with digital signatures
This shows that the AutoMapper (and MediatR) packages were published by Lucky Penny Software (my company) and not...Unlucky Penny Software? Getting this additional security verification is important for customers to know that this package comes from us and not some other entity. Getting verified for code signing certificates is a fairly involved process doing things like "taking selfies with my passport".
Downloads and release notes below:
AutoMapper NuGet
AutoMapper v16.0.0 Release Notes
MediatR NuGet
MediatR v14.00 Release Notes
Enjoy!


AutoMapper 15.1 and MediatR 13.1 Released
Mon, 03 Nov 2025 22:06:16 +0000
Starting a new policy of regular quarterly releases, today I pushed out new versions of AutoMapper and MediatR:
AutoMapper 15.1.0 Release Notes
MediatR 13.1.0 Release Notes
The previous versions restored netstandard2.0 support across the board. In these releases, I'm including first-class support for net462 where I'm building and testing on both *nix and Windows. We noticed that just including netstandard2.0 as a target framework wasn't enough to really guarantee that the libraries would work against full .NET, so we now build and test on both.
There's some new features, enhancements, and bug fixes that you can view in the release notes above.
Enjoy!


AutoMapper and MediatR Roadmaps
Tue, 08 Jul 2025 15:15:32 +0000
One of my main goals of commercialization of AutoMapper and MediatR was being able to finally invest time in these projects where basically all new work stopped when I lost corporate sponsorship. I wanted to take some time to share where I'd like to take these projects now that I have that sponsorship back.
Tracking official .NET support
Firstly, the latest releases bring back netstandard2.0 support for both AutoMapper and MediatR which had dropped both years ago. MediatR was actually still on net6.0 prior to this release which was already out of support for months.
It wasn't exactly easy, especially because of how much net8.0 and net9.0 have diverged from netstandard2.0 not just in terms of APIs but C# language features, but having been part of several ASP.NET 4.x to ASP.NET Core migrations, having netstandard2.0 support makes this transition quite a bit easier. In the past we'd have to conditionally reference packages because there was no longer a common package version between say .NET 8 and .NET 4.8. That's something that I wish I had before that now I do.
AutoMapper Roadmap
One of the biggest complaints I hear about AutoMapper is that it's hard to debug - you're trading compile-time errors for runtime exceptions. We spent a LOT of time baking in better exception handling into the expression trees generated (resulting in worse performance, but better diagnostics), but that isn't always enough.
The answer here is source generators, but I'm not interested in merely copying other library's approaches. What I want to target is source generators that:
Plug in to AutoMapper's rich extensibility model
Stay true to AutoMapper's design philosophy 
Support IQueryables (my favorite feature)
Track the features of AutoMapper's in-memory mapping
Support mapping validation (critical for any mapping tool)
Debuggability is my main focus here, although obviously performance would be a secondary win. Source generators have come a LONG way since I first looked at them when they were first released, so I'm excited to extend AutoMapper's functionality in this area.
This one is pretty big, so that's going to be my focus initially.
MediatR Roadmap
Some folks have asked or even pointed to other libraries that do source generation of basically a copy of MediatR's API. I am looking at that, but there's been quite a few things on MediatR's backlog that I want to look at first. Source generation in mediators I find a bit less interesting in real-world projects, outside of philosophical debates.
MediatR is commonly used in concert with Vertical Slice Architecture, and a number of its features came out of using it in these scenarios (like behaviors). Today, a lot of features are tied in to the feature set of the stock Microsoft DI container. Unfortunately, features are only really added to that container if the ASP.NET Core team needs them. Even my PR to support generic constraints took like 5 years to merge in.
Moving away from relying on those DI features would mean I could do much more interesting things in the "application use case pipeline" that aren't possible with C#/DI alone, like:
Applying behaviors based on customized policies
Baking in support for result patterns
Direct support for application use casesBlazor (sending a request from the client to a handler on the server)
Minimal APIs (scaffolding to separate API logic from application logic)
Domain events via notifications and EF/other ORMs
The idea of behaviors came from reviewing many production systems using MediatR and folding in that into first-class features. I am going to continue on this track.
What else are you interested in?


AutoMapper and MediatR Commercial Editions Launch Today
Wed, 02 Jul 2025 15:00:12 +0000
Today I'm excited to announce the official launch and release of the commercial editions of AutoMapper and MediatR. Both of these libraries have moved under their new corporate owner (me), Lucky Penny Software. I formed this company to house these projects separate from my consulting company, but it's just me there, I'm the sole corporate overlord.
The GitHub repositories have transferred to the new GitHub organization (along with their ownership) here:
LuckyPennySoftware/AutoMapper
LuckyPennySoftware/MediatR
With these, I've launched new home pages for each library:
https://automapper.io
https://mediatr.io
As well as a storefront site to purchase and manage licenses at:
https://luckypennysoftware.com
It's quite a bit to dig in to, so let's go over the details!
What's the new license?
As discussed before, I wanted to release these libraries under a dual-license model:
Reciprocal Public License 1.5 (RPL1.5)
Lucky Penny Software Commercial License
It's a common dual-license model that many other OSS companies have chosen (MongoDB etc.) and had success with.
Under the commercial license, I've created a tier-based licensing model based on team size. There are no individual per-seat licenses, only licensing based on the number of developers.
How much will it cost?
With a tier-based pricing approach, I wanted a pricing model that scales with team size and allows for company growth without a lot of hassle. There are 3 paid tiers:
Standard - 1-10 developers
Professional - 11-50 developers
Enterprise - Unlimited developers
Pricing is a subscription model, with both monthly and annual subscriptions (with a discount for annual subscriptions), as well as an option to bundle both libraries at a discount. You can find the details here (with all options), priced to your currency or in USD:
AutoMapper pricing
MediatR pricing
You can also find the details of what subscription benefits you'll get at the links above, including:
Private Discord channels
Priority support
Early access to new releases
Support for all currently supported versions of .NET Framework 4.x and .NET (netstandard2.0, net8.0, net9.0)
And more (as I build it)
All subscription payments are managed through Paddle, which supports...many different countries, currencies, and payment providers.
Do you have free licenses for <insert situation here>? 
Yes! Besides the RPL license, I'm also including a Community edition under the Commercial license that is free for:
Companies and individuals under $5,000,000 in gross annual revenue
Non-profits under $5,000,000 in annual total budget (expenditure)
Educational/classroom use
Non-production environments
You're still required to register for a license key, but this is only for auditing purposes.
How do I get the commercial versions?
To make everyone's lives easier, these new major versions of AutoMapper and MediatR on NuGet are released under the new dual license agreement:
AutoMapper v15.0
MediatR v13.0
When you install these versions, you'll now be prompted for license acceptance. Once you obtain a license key, you'll be able to set the license key as:
services.AddAutoMapper(cfg => /* or AddMediatR */
    cfg.LicenseKey = "<License key here>";
});
I don't restrict usage of these products with a missing/invalid/expired license key, but you'll see some messages in your logs prompting you to supply a valid key.
What about the existing versions?
I've created archived versions of the final releases of these two libraries:
AutoMapper/AutoMapper.Archive
jbogard/MediatR.Archive
Per those existing license agreements, you're free to fork, download, print out and read by the fireplace. Those archives will live on for anyone to use as they like.
If you're an existing user, you don't need to do anything. The existing NuGet packages (prior to the major versions listed above) are bound by the license agreements at the time of their release and will also live on.
Why Lucky Penny?
Because she was my first dog! Although she's no longer with us anymore, I loved her spunk and her spirit and wanted to honor her memory with my company name (and logo). Here she is judging, always judging:
Penny the dog
I named her Penny because 1) she was found by the side of a busy highway miles from anywhere (lucky for both of us) and 2) her copper color. So, Lucky Penny Software!
Lucky Penny Software logo
It's been a long journey to get here but I'm excited about what the future holds for these libraries that have amassed more than 1.1 billion downloads. Thanks everyone for your patience and support as I worked to launch!


AutoMapper and MediatR Licensing Update
Wed, 16 Apr 2025 05:15:28 +0000
In my last post, I shared the news that I've decided to take a commercialization route for AutoMapper and MediatR to ensure their long-term success. While that post was heavy on the motivation, it was intentionally light on the details. I did share that I wanted to be transparent on that process, and this post is part of that transparency.
There is a TON of information out there on possible models for sustainable open source, such as:
Consulting services
Open core
Hosted services
Dual license
a dozen others
Of course besides my previous situation, "be fortunate enough to work at a place that values and directly sponsors your work." This is the easiest place to be, but for projects that reach some threshold of users/downloads/complexity, maintainers must rely on sponsorship in some form or fashion. And when that sponsorship goes away for whatever reason, well, here we are.
Of the many options available, the most viable option is to move AutoMapper and MediatR to a dual license model. This looks to be the best choice after carefully examining the options and consulting with many other OSS maintainers who have already made this journey.
Dual Licensing Model
When I first started thinking about how I might go about this, I asked myself, "who bears the most responsibility in ensuring the sustainability of the OSS projects on which they depend?" which is a long winded way of saying "who should pay?" But another way of thinking of this is "who should NOT pay?" Looking at how others do this as well as how I want to approach it, I want to make these libraries free for:
Developers using it in an OSS setting
Individuals/students/hobbyists (using AutoMapper for fun not profit)
Non-profit/charities (maybe not for fun but also not for profit)
Startups or small companies (below some revenue/funding threshold)
Non-commercial setting (this I'm not sure is absolutely necessary with the other categories)
Non-production environments (instead of any trial period etc.)
I don't know if this exact verbiage is what will be the end result, but this is my overall goal.
Then for who I'm targeting for paid for-licenses, it's for-profit businesses using these libraries for commercial activities. Looking at my clients over the years who've used my libraries, it's a mix of these free/commercial categories.
In terms of a model for commercial licensing, I want to ensure that paid licenses add value beyond "I can download the license." This is the more fun part of this exercise for me, where I can try the things I never really could before without a more direct form of sponsorship/funding. I have a lot of ideas here, but nothing ready to share yet. If you have an idea of "if my company paid for a license, what else would I want to have included?" I would love to hear about it!
I am looking at a tiered license model but no per-seat licenses. I don't want to charge individual developers anything—that seems like a pain for everyone involved and I'm trying to keep things simple. "A new developer gets onboarded and now we need a new license" is too much for me to deal with and goes against the spirit of these libraries—the benefit is to the entire team, regardless of the number of developers.
I don't know what those tiers will be exactly, I'm figuring that out next. I do expect some blanket enterprise, site-wide licenses that hopefully makes everything simpler for everyone. I've been on the other side of the table, getting licenses approved internally with clients, and I understand predictability and simplicity go a long way.
Thoughts on Pricing
As for pricing, I don't have details yet, and probably won't until launch in the next couple months. Range-wise, it's hard to compare to other commercial or dual-licensed products out there, since I don't want to do any individual or per-seat license and that seems to be the norm. I am however keenly aware of how much tooling and library products cost as I have to pay for many of these myself.
But if I were to compare to the cost for a team of 10 or 50 or 100 for their IDEs, I would expect my commercial license price to be a fraction of that.
Thanks again to everyone that's reached out with kind words and support, and to the community for their patience while I figure things out.


AutoMapper and MediatR Going Commercial
Wed, 02 Apr 2025 13:00:12 +0000
Yes, another one of "those posts". But tl;dr:
In order to ensure the long-term sustainability of my OSS projects, I will be commercializing AutoMapper and MediatR.
I did not post this on April 1st for obvious reasons. But first a little background on how I got to this point.
How I Got Here
These two projects originated at my time at Headspring, a consulting company I worked at for over 12 years. About 5 years ago, in January 2020, I decided to strike off on my own and give solo consulting a try. Although it was a scary leap, it's been more rewarding than I could have possibly hoped for, in almost every area.
The area that it didn't work out well, and not at all intentionally, was OSS work:
You can see exactly where my contributions cratered and flat-lined. And that's just commits—issues, PRs, discussions, all my time dried up. This wasn't the intention but was a natural side effect of me focusing on my consulting business.
At Headspring, my time on OSS was directly encouraged and sponsored by them. I could use time between projects to invest back in existing OSS or new OSS, because it benefited the client, the company, and the employees (me and my coworkers).
With me leaving that company, and that company then selling to Accenture later that year, I had no direct major sponsor of my OSS work anymore. My free time was being spent growing and ensuring the success of my consulting company, which being solo, is...kinda important.
Taking time to see how things have been going on all fronts, I had a bit of a shock looking at my OSS work. I realized that model is not sustainable for the long-term success of these projects, which I still endorse and believe in. I need to be able to pay for my time to work on these projects, and get direct feedback from paying clients, like I had earlier at Headspring.
What Will This Look Like?
The short answer is "I don't know exactly". I'm working out those details now and will share them when I figure it out. I have lots of examples of what does and doesn't work well, at least from my perspective, as well as what I consider will work well for these projects.
Short term, nothing will change. I'll still be as (un)responsive on GitHub issues, and I just pushed out a couple releases of any existing work.
My goal is to be able to pay for the time to spend actually improving these projects, building out communities, helping more users, and in general, doing the things that people have asked me MANY times over the years that I should do, but I didn't, because it was not my job. OSS was/is/never will be a hobby for me. I want to change it to at least be part of my job and to fund real work.
I can’t rely on donations, I don't want to make developers pay anything or do anything to punish/annoy them, and I certainly don't think it's Microsoft's job to "pay me the money." Past that, I'm still figuring it out.
When Will This Happen?
I don't know, it's still just me that owns everything. It's still using my free time to sort it out, as my day job is still a consultant. But I plan to be open with this whole process. I'm sure I'll surprise someone but the goal here is to be transparent.
Personally, I'm both filled with excitement and dread—doing these projects for so long has been incredibly rewarding, especially as this is code that came directly out of many, many long-lived production-deployed projects at Headspring. But I don't want these projects to wither and die on the vine, I want them to grow and evolve and thrive. But not just these projects—I want ALL my OSS projects (Respawn etc.) to thrive. This is how it needs to happen.
Final Thanks
Thanks to all that have contributed over the years, and especially to Lucian Bargaoanu who really helped pick up the torch with AutoMapper after I more or less fell off the map. Also thanks to my GitHub sponsors, as many a pint has been purchased with your generous support. And finally thanks to the community, I never hoped anything I built would help anyone beyond my clients, coworkers, and company, but it's always nice to hear that it has.


MediatR 12.5.0 Released
Tue, 01 Apr 2025 18:50:06 +0000
I pushed out MediatR 12.5 today:
Release Notes
NuGet
This is mainly a regular minor release with a couple extra interesting features:
Adding convenience method to register open behaviors
Better cancellation token support (it's passed now everywhere including behaviors)
And some other cleanup items as well. Enjoy!


AutoMapper 14.0 Released
Wed, 19 Feb 2025 13:41:24 +0000
I pushed out version 14.0 (!) of AutoMapper over the weekend:
Release notes
NuGet
This release targets .NET 8 (up from .NET 6 from the previous release). It's mainly a bug fix release, with some quality-of-life improvements in configuration validation where we gather up all the possible validation errors before reporting them in an aggregate exception.
Enjoy!


Integrating the Particular Service Platform with Aspire
Tue, 24 Sep 2024 22:48:57 +0000
I've been playing around with Aspire for a bit mainly to understand "is this a thing I should care about?" and part of what I wanted to do is take a complex "hello world" distributed system and convert it to Aspire. Along the way, Particular Software also released container support for their Service Platform, so it also seemed like a good opportunity to try it out.
I'll follow up in another post about Aspire impressions, but the NServiceBus part was actually relatively simple. Many Aspire integrations have some kind of 1st-party support where you can do things like:
var rmqPassword = builder.AddParameter("messaging-password");
var dbPassword = builder.AddParameter("db-password");

var broker = builder.AddRabbitMQ(name: "broker", password: rmqPassword, port: 5672)
    .WithDataVolume()
    .WithManagementPlugin()
    .WithEndpoint("management", e => e.Port = 15672)
    .WithHealthCheck();
var mongo = builder.AddMongoDB("mongo");
var sql = builder.AddSqlServer("sql", password: dbPassword)
    .WithHealthCheck()
    .WithDataVolume()
    .AddDatabase("sqldata");
And now my system has RabbitMQ, MongoDB, and SQL Server up and running in containers. There's a lot of stock configuration going on behind AddSqlServer and similar methods but we don't have to use those convenience methods if we don't want to.
The overall Service Platform architecture looks something like:
The "instances" here are running containers that we need to configure in Aspire. On top of that, we might also want to have Service Pulse (another container) and Service Insight (a Windows-only WPF app) running, and these all require extra configuration. Also, the Error and Audit instances use RavenDB as their backing store but Particular also has an image there. The Docker Hub site has links to docs on both the instance and containers.
First up, we need to provide our license to the running containers as raw text in an environment variable, so we'll just read our license (this is just for local development):
var license = File.ReadAllText(                                              
    Path.Combine(                                                            
        Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData),
        "ParticularSoftware",                                                
        "license.xml"));                                                     
Next, we need our RavenDB instance. There's a special image from Particular, so we'll use the AddContainer method to add our custom image to our Aspire distributed application:
builder                                                                             
    .AddContainer("servicecontroldb", "particular/servicecontrol-ravendb", "latest")
    .WithBindMount("AppHost-servicecontroldb-data", "/opt/RavenDB/Server/RavenData")
    .WithEndpoint(8080, 8080);                                                      
The container docs say that we must mount a persistent volume to that path, so we use the WithBindMount method to mount the volume following the Aspire docs.
Next up are the Particular containers!
Setting up the Service Control Error instance
From the Particular docs, we see that we need to supply configuration for:
Transport type (RabbitMQ, Azure Service Bus, etc.)
Connection string to the transport
Connection string to the Raven DB instance
Audit instance URLs
License
Plus port mapping. Pretty quickly I ran into a few challenges:
The Service Control image can start before RabbitMQ is "ready", resulting in connection failures
Service Insight, the WPF app, is Windows only so I need to connect to Service Control from a VM
The base configuration is fairly straightforward, we specify the container and image, with environment variables:
builder                                                                                             
    .AddContainer("servicecontrol", "particular/servicecontrol")                                    
    .WithEnvironment("TransportType", "RabbitMQ.QuorumConventionalRouting")                         
    .WithEnvironment("ConnectionString", "host=host.docker.internal")                               
    .WithEnvironment("RavenDB_ConnectionString", "http://host.docker.internal:8080")                
    .WithEnvironment("RemoteInstances", "[{\"api_uri\":\"http://host.docker.internal:44444/api\"}]")
    .WithEnvironment("PARTICULARSOFTWARE_LICENSE", license)                                         
    .WithArgs("--setup-and-run")                                                                    
But the other two challenges are a bit harder to deal with. There is no built-in way in Aspire to "wait" for other resources to start. This isn't new to Aspire - in the past we had to write custom hooks in Docker Compose to wait for our dependencies' health checks to come back. The extensibility is there to do such a thing, so I found an extension to do just that.
The second problem was...a long slog to figure out. It's possible to have a Parallels VM be able to communicate with Docker containers running in the Mac host. However, I could not get this to work with Aspire. After doing side-by-side comparisons between container manifests running inside/outside of Aspire, I found the culprit:
"PortBindings": {
	"8080/tcp": [
		{
-			"HostIp": "",
+			"HostIp": "127.0.0.1",
			"HostPort": "8000"
		}
	]
},
With the Docker CLI, doing -p 8080:8000 does not set the host IP. Aspire does however, which means I can only access this container via localhost. Not ideal because my Windows VM is definitely not able to access that. Instead of using WithEndpoint or similar, I have to drop down to container runtime args:
.WithContainerRuntimeArgs("-p", "33333:33333")
.WaitFor(rabbitMqResource);                   
Now my Service Control instance is up and running!
Setting up Service Control Audit, Monitoring, and Service Pulse
Following our previous example, we can finish out our configuration for the other container instances:
builder                                                                              
    .AddContainer("servicecontrolaudit", "particular/servicecontrol-audit")          
    .WithEnvironment("TransportType", "RabbitMQ.QuorumConventionalRouting")          
    .WithEnvironment("ConnectionString", "host=host.docker.internal")                
    .WithEnvironment("RavenDB_ConnectionString", "http://host.docker.internal:8080") 
    .WithEnvironment("PARTICULARSOFTWARE_LICENSE", license)                          
    .WithArgs("--setup-and-run")                                                     
    .WithEndpoint(44444, 44444)                                                      
    .WaitFor(rabbitMqResource);                                                      
                                                                                     
builder                                                                              
    .AddContainer("servicecontrolmonitoring", "particular/servicecontrol-monitoring")
    .WithEnvironment("TransportType", "RabbitMQ.QuorumConventionalRouting")          
    .WithEnvironment("ConnectionString", "host=host.docker.internal")                
    .WithEnvironment("PARTICULARSOFTWARE_LICENSE", license)                          
    .WithArgs("--setup-and-run")                                                     
    .WithEndpoint(33633, 33633)                                                      
    .WaitFor(rabbitMqResource);                                                      
                                                                                     
builder                                                                              
    .AddContainer("servicepulse", "particular/servicepulse")                         
    .WithEnvironment("SERVICECONTROL_URL", "http://host.docker.internal:33333")      
    .WithEnvironment("MONITORING_URL", "http://host.docker.internal:33633")          
    .WithEnvironment("PARTICULARSOFTWARE_LICENSE", license)                          
    .WithEndpoint(9090, 9090)                                                        
    .WaitFor(rabbitMqResource);                                                      
With all this in place in my Service Pulse instance is up and running:
And on the Service Insight side, I had to do the Parallels trick of using my hosts file to create a special "localhost.mac" entry to point to the Mac host:
10.211.55.2 localhost.mac
With this in place, I can configure Service Insight in Windows to connect to the Docker Service Pulse instance running in Docker on the Mac:
All my NServiceBus messages and traces now show up just fine:
Most of the work I had to do was not really Aspire-related, but just configuring Aspire to pass in the appropriate configuration to the containers. You can find the full code to my configuration here:
Code Example
Enjoy!


Tales from the .NET Migration Trenches - Turning Off the Lights
Thu, 05 Sep 2024 15:25:16 +0000
Posts in this series:
Intro
Cataloging
Empty Proxy
Shared Library
Our First Controller
Migrating Initial Business Logic
Our First Views
Session State
Hangfire
Authentication
Middleware
Turning Off the Lights
In the last post, we looked at migrating our middleware, which we tackle in an as-needed basis. When a controller needs middleware to be migrated, we migrate that middleware over. If the entire app needs the middleware, it needs to come rather early.
Once we migrate much of our middleware over, it becomes much less work to incrementally migrate individual controllers and their subsequent actions/pages over. I won't go into deep detail into this part - mostly it's fixing namespaces, adjusting features (such as converting child actions into view components), but it can go quite fast. On recent teams I was working with, we migrated easily a dozen controllers a week amongst 3-4 developers. At this point, the bottleneck wasn't the conversion, but testing to make sure the pages still worked correctly
It's essentially testing the entire application, one page at a time, so hopefully you've got some regression tests in some form or fashion. I'm not skipping the incremental controller migration because it's not interesting - it's just because our teams really didn't encounter many challenges there. There will be something that comes up, there always is, but just the controller/action/view part is not too terrible.
But in this post I wanted to focus on getting to the end - what do we do once we've migrated everything but authentication? When there's just one controller left, we're now OK to proceed with migrating the last pieces over and "turning off the lights" on the .NET 4.x application.
Migrating Last Features
The last (or next-to-last) migration typically:
Migrates the last controller, usually authentication
Turns off proxying and all remote app features
You don't necessarily need to split this into two separate units of work/deployments, as once you've migrated the last set of requests you can migrate all final features from the .NET Framework application. If the last controller is authentication, we'll also need to remove remote authentication. Our current web adapter configuration before final migration is:
builder.Services.AddSystemWebAdapters()
    .AddJsonSessionSerializer(options =>
    {
        options.RegisterKey<string>("FavoriteInstructor");
    })
    .AddRemoteAppClient(options =>
    {
        // Provide the URL for the remote app that has enabled session querying
        options.RemoteAppUrl = new(builder.Configuration["ProxyTo"]);

        // Provide a strong API key that will be used to authenticate the request on the remote app for querying the session
        options.ApiKey = builder.Configuration["RemoteAppApiKey"];
    })
    .AddAuthenticationClient(true)
    .AddSessionClient();
builder.Services.AddHttpForwarder();
With middleware:
app.UseSystemWebAdapters();

app.MapDefaultControllerRoute();
app.MapForwarder("/{**catch-all}", app.Configuration["ProxyTo"]).Add(
    static builder => ((RouteEndpointBuilder)builder).Order = int.MaxValue);
Along with migrating the authentication piece and all related middleware, we'll remove the above from our application startup, as well as the package references to all the proxy and System.WebAdapters packages. Once that's complete, our .NET application should now handle all requests. There might still be a few extra features to enable in .NET 8, such as Session:
builder.Services.AddSession();

// later

app.UseSession();
With all that complete, our .NET 8 application should now serve all requests and host all features needed to run our entire system.
Turning off the lights
While our .NET 8 application may now be "complete", we're not quite done yet. In my typical last phase we will:
Deploy the completed .NET 8 application to production
Monitor for any errors and any activity from the .NET 4.8 application
Adjust our .NET 8 application as necessary
If we don't see any issues, then the final final cleanup is:
Remove all .NET 4.8 code from the repository
Remove any shims to bridge from .NET 8 to .NET 4.8
Remove all .NET 4.8 application pipelines and deployments
Remove all .NET 4.8 production resources
And we should end with something like:
So what's next? There's still probably quite a bit to do to ".NET-8-ify" our existing system - all those architectural improvements we skipped in order to fast track migration. But most important - celebrate!


Upcoming Training on DDD with Vertical Slice Architecture in Munich
Wed, 28 Aug 2024 10:28:04 +0000
I've got another training event coming up focusing on Domain-Driven Design with Vertical Slice Architecture in Munich on October 21-23rd.
A little different than the previous times I've given this course is an option for either a 2-day or 3-day version. I had received feedback that folks were also interested in larger-scale design concepts such as bounded contexts, messaging, integration patterns, microservices, and modular monoliths. So I've included a 3rd day that covers these topics, where we look at encapsulation and cohesion at larger and larger scopes.
We'll cover:
Refactoring an existing system to leverage Vertical Slice Architecture
Applying Domain-Driven Design techniques to model complex business needs
Communication between slices
Exploring Validation and Testing (and other cross-cutting concerns) using Vertical Slice Architecture
Examining various design patterns, code smells, and refactoring techniques
Implementing the Vertical Slice Architectural pattern in various enterprise application scenarios (minimal APIs, Blazor, Web APIs, etc.)
And on the final day:
Service boundaries and bounded contexts
Communication between bounded contexts
Microservices and modular monoliths
Studying distributed systems patterns, tools, and libraries such as NServiceBus
The course pulls together my experiences building such systems for nearly 20 years now. And if you can't make the course during the day, I'm also hosting a networking event during the evening where you can meet myself and the other attendees and ask me questions. I hope to see you there!
Register Now


SSH on WSL
Fri, 01 Jul 2022 08:00:00 +0000

  


I recently set up a Windows machine to allow me to ssh into its WSL network from another box. I found a couple of useful guides here and here, but still ran into a few snags along the way, so thought I’d publish my configuration in case it might be useful to someone else (or perhaps even myself) in the future. Here are my steps:

Step 1: Install OpenSSH in WSL

Our first step will be to ensure openssh-server is installed. If not, issue the following and follow the prompts:

$ sudo apt install openssh-server


Step 2: Configure SSHD

Edit the file /etc/ssh/sshd_config to allow the desired users or groups. You’ll need to edit this with root access:

$ sudo vi sshd_config


To allow specific users, you can add the following with a list of users where  is replaced with the desired user:

AllowUsers <user1> <user2> <userN>


To allow all users in one or more groups, add the following:

AllowGroups <group1> <group2> <groupN>


Note that these are users and groups known to WSL, not your windows users and groups (i.e. /etc/password, /etc/group).

Step 3: Setup Startup Script

Create a new file named startup-ssh.sh in /usr/local/bin with the following contents:

#!/bin/bash

WSL_IP=$(ip addr show eth0| grep -oP '(?<=inet\s)\d+(\.\d+){3}')
NETSH_CMD=/mnt/c/Windows/System32/netsh.exe
SSL_PORT=22
FIREWALL_RULE_NAME="SSH Port ${SSL_PORT}"

echo -n "Resetting port proxy settings ... "
${NETSH_CMD} interface portproxy reset all 2>&1 1>/dev/null

[ $? == 0 ] && echo "OK" || echo "Error"

echo -n "Forwarding port ${SSL_PORT} to ${WSL_IP} ... "
${NETSH_CMD} interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=${SSL_PORT} connectaddress=${WSL_IP} connectport=${SSL_PORT} 2>&1 1>/dev/null
[ $? == 0 ] && echo "OK" || echo "Error"

echo -n "Adding firewall rule if not present ... "
if ${NETSH_CMD} advfirewall firewall show rule name="${FIREWALL_RULE_NAME}" 2>&1 1>/dev/null
then
echo "OK"
else
${NETSH_CMD} advfirewall firewall add rule name="${FIREWALL_RULE_NAME}" dir=in action=allow protocol=TCP localport=${SSL_PORT} 2>&1 1>/dev/null
[ $? == 0 ] && echo "OK" || echo "Error"
fi

echo -n "Starting WSL ssh server ... "
sudo /etc/init.d/ssh start 2>&1 1>/dev/null
[ $? == 0 ] && echo "OK" || echo "Error"


This script does the following things primarily:


  Forwards traffic going to port 22 from your Windows system to port 22 on the WSL virtual machine
  Adds a Windows firewall rule to allow port 22 traffic
  Starts the ssh server


We will be configuring Windows to execute this script on startup. The reason this is necessary is that WSL obtains a new IP address each time the system starts. This results in the need to reset the port forwarding and reapply with the latest WSL IP address.

Step 4: Configure Super User Execution

As indicated in step 5 of this guide, we need to allow the ssh command to be started without prompting for a password. We do this by editing the /etc/sudoers file. This can be done with the following command:

    $ sudo visudo



Note:

The purpose of editing the /etc/sudoers file using the visudo command is to validate the syntax before saving. You could edit the file directly, but if you screw something up then you could lock yourself out of gaining root access.

When I first used this command, it launched using the nano editor with which I’m not familiar. You can configure which editor is used by executing the following command:

    
    $ sudo select-editor    


Alternately, you can set your EDITOR environment variable to the desired editor and use the following command:

    $ sudo -E visudo



Add the following as the last line of the file:

%sudo ALL=NOPASSWD: /etc/init.d/ssh


Step 5: Configure Windows Task Scheduler

Our final step will be to configure Windows Task Scheduler to launch our startup script when the system starts. Use the following steps:


  
    Open the Task Scheduler app from the Windows Start Menu
  
  
    Select Create Basic Task from the right panel
  
  
    Create task with the following parameters:

    Name: Start SSH Server

    Description: Task to automate sshd startup

    Trigger: Select When the computer starts

    Action: Select Start a program

    Program/script :%windir%\System32\wsl.exe
Add arguments (optional): -d Ubuntu -e "/usr/local/bin/startup-ssh.sh"
  
  
    Confirm everything is correct and click Finish
  


Step 7: Verify Configuration

Our last step is to verify we have everything configured correctly. In Task Scheduler, locate the “Start SSH Server” task and in the right panel click “Run”. If successful, you should be able to ssh from another machine to your Windows WSL virtual machine:

$ ssh dgreer@dgreer-pc



Perhaps Too Much Validation
Wed, 22 Jun 2022 08:00:00 +0000
Several factors have influenced my coding style over the years leaving me with a preference toward lean code syntax. I’ve been developing for quite a while, so it would be hard to pinpoint exactly when, where, or from whom I’ve picked up various preferences, but to name a few, I prefer: code that only includes comments for public APIs or to provide explanation of algorithms; code that is free of the use of regions, explicit default access modifiers, and unused using statements; reliance upon convention over configuration (both to eliminate repetitive tasks, but also just to eliminate unnecessary code); encapsulating excessive parameters into a Parameter Object, avoidance of excessive use of attributes/annotations (actually, I’d eliminate them completely if I could), and of course deleting dead code. There is one other practice I tend to see by other developers that I dislike and that’s too much validation.

Perhaps you’ve seen code like this:

public class MyService
{
    public DoSomething(IDependencyA dependencyA, IDependencyB dependencyB, IDependencyC dependencyC)
    {
        if(dependencyA is null)
        {
            throw new ArgumentNullException(nameof(dependencyA));
        }

        if(dependencyB is null)
        {
            throw new ArgumentNullException(nameof(dependencyB));
        }

        if(dependencyC is null)
        {
            throw new ArgumentNullException(nameof(dependencyC));
        }
    }

    …
}


Perhaps you even think this is a best practice. Is it? As with many things, the answer is really: It depends. One of the things that has greatly shaped my views on several aspects of software development over the years is adopting Test-Driven Development. The “test” part of the name is really a hold-over from adapting the practice of writing Unit Tests for driving design. With Unit Testing, you’re testing the code you’ve written. With Test-Driven Development, you’re constraining the design of the code to meet a set of specifications. It’s really quite a difference and one you may not fully appreciate unless you fully buy in to doing it for an extended period of time.

One of the side-effects of practicing TDD is that you don’t write code unless it’s needed to satisfy a failing test. The use of code coverage tools are basically superfluous for TDD practitioners, not to mention rendering far superior regression test suites. What, however, does this have to do with validation?

When driving out implementation through a series of executable specifications (i.e. an objective list of exactly how the software should work), we may end up writing code which technically could be called a certain way which would result in exceptions or logical errors, but in practice never is. As it relates to this topic, all code we write can be grouped into two categories: public and private. In this sense I’m not talking about the access modifiers we place upon the code artifacts themselves, but the intended use of the code. Is the code you’re writing going to be used by others, or is it just code we’re calling internally within our applications? If it’s code you’re driving out through TDD which others will be calling, then you should have specifications which describe how the code will react when used correctly as well as incorrectly and thus will have the appropriate amount of validation. If it isn’t code anyone else will be, or currently is calling (see also YAGNI), then the components which do call it will have been designed such that they don’t call the component incorrectly rending such validation useless.

Let’s consider our code again:

public class MyService
{
    public DoSomething(IDependencyA dependencyA, IDependencyB dependencyB, IDependencyC dependencyC)
    {
        if(dependencyA is null)
        {
            throw new ArgumentNullException(nameof(dependencyA));
        }

        if(dependencyB is null)
        {
            throw new ArgumentNullException(nameof(dependencyB));
        }

        if(dependencyC is null)
        {
            throw new ArgumentNullException(nameof(dependencyC));
        }
    }

    …
}


If this is an internal service that isn’t going to be called by any other code except other components within your application, we have 14 lines of code that are unneeded and are just adding noise to our code. I’ve worked in shops where every class in an application or library was coded this way, effectively adding hundreds to thousands of lines of unneeded code. Like regions, comments, or poorly factored code, this adds to the cognitive load required for reading through and understanding the code and ultimately is unnecessary. So the next time you reflexively start adding such validation, consider the possibility that perhaps you may be adding too much validation.


For Whom is this Container?
Wed, 01 Jun 2022 08:00:00 +0000
Several of the Messaging platforms in the .Net space have pretty rudimentary APIs (e.g. RabbitMq, Kafka) which require quite a bit of boiler-plate code to be written to get a simple message published and subscribed. You could turn to one of the Conforming Abstraction libraries such as NServiceBus or MassTransit, but perhaps you don’t really want a lowest-common denominator API, you don’t like something about how it creates the messages or topic/queue artifacts, or you simply want a fluent API expressed in terms of the native platform’s nomenclature and behavior. This might lead you down the road of creating your own KafkaBus, SQSBus, RabbitMqBus, etc. that feels like the API you wish the original development team had just provided for you to begin with. Ah, but now you have a dilemma: Frameworks such as this tend to require a number of components you’ll need to compose, many of which you may want to allow users to configure (e.g. serialization needs, consumer class conventions, logging, produce and consume pipelines, etc.). You could write hand-rolled factories, builders, singletons, etc. to facilitate the configuration and building of instances of your components, but you know that using a dependency injection container would make both development and long-term maintenance of your library much easier. But now you have another dilemma: Are you going to tie your project to some open-source container? If so, which one? Should you support a handful of the most popular ones? Should you just rely upon the Service Locator pattern and provide configuration for end users should they want to resolve from their own containers?

This was essentially the dilemma the ASP.Net Core team found themselves in when they set out to develop .Net Core. They had a fairly sizable framework with a lot of moving parts, many of which they wanted to allow the end user to configure. Earlier versions of ASP.Net MVC were built using a Service Locator pattern implementation which facilitated the ability to configure resolving from an open-source container of your choice. This, however, would have no doubt presented various design limitations in addition to the resulting lack of elegance to the resulting codebase, so the team decided to build the new platform from the ground up using dependency injection. They couldn’t, however, feasibly decide to couple their framework to one of the already mature and successful open source DI containers for various reasons. This prompted them to write their own.

One of the keys to understanding the capabilities offered by .Net Core’s container compared to other libraries is recognizing that they built it for their needs, not yours. There is no doubt that there was recognition of the usefulness for some developers to have an out-of-the-box DI container, but they didn’t set out to build a container to compete with the already extremely mature frameworks such as Autofac, StructureMap, or Ninject. For instance, because they weren’t developing user interactive client-facing applications, they didn’t have needs such as convention-based scanning registration, multi-tenancy support, the need for decorators, etc. Their needs pretty much were limited to known types with lifetime scopes of transient, singleton, or scoped per request.

Oddly, there is now a whole new generation of .Net developers which have never used a DI container other than that provided by the Microsoft Extensions suite which are missing out on being exposed to solutions to problems for which containers like Autofac, Lamar, and others facilitate fairly easily, largely I believe because no one has ever really told them: Microsoft didn’t really write that for you.


Pragmatic Deferral
Tue, 31 May 2022 13:00:00 +0000
Software engineering is often about selecting the right trade offs. While deferring feature development is often somewhat straight-forward, based upon a speculation about the return on investment, and generally decided by the customer; marketing; sales; or product people; low-level implementation decisions are typically made by the development team or individual developers and can often prove to be a bit more contentious among teams with a plurality of strong opinions. This is where principles like YAGNI (You’re Aren’t Going to Need It), or the Rule of Three have often been set forth as a guiding heuristic.

While I generally advise the teams I coach to allow the executable specifications (i.e. the tests) to drive emergent design and to defer the introduction of ancillary libraries, frameworks, patterns, and custom infrastructure, until you need it, there is a level of pragmatism that I employee when determining when to introduce such things.

I’ve been a fan of Test-Driven Development for some time now and have practiced it for over a decade. One of the primary benefits of Test-Driven Development is having an objective measure guiding what needs to get built. For example, if the acceptance criteria for a User Story concerns building a new Web API for a company’s custom B2B solution, your specs are going to drive out some sort of HTTP-based API. What the specs won’t dictate, however, are decisions such as whether to use an MVC framework, an IOC container, whether to introduce a fluent validation library or an object mapping library. Should we adhere strictly to principles like YAGNI or the Rule of Three for guidance here? My answer is: it depends.

Deferring software decisions comes with quite a range of consequences. Some decisions, such as whether to select ASP.NET MVC at the outset of a .Net-based Web application, could cause quite a bit of rework if you were to defer such a decision until working with lower-level components started to reveal friction or duplication. Other decisions, such as deferring the introduction of an object mapping library (e.g. Automapper) until the shape of the objects you’re returning actually differ from your entities essentially have only positive consequences. But how do we know?

The YAGNI principle is very similar to the firearm safety rule “The Gun is Always Loaded”. No, the gun isn’t always loaded … but it’s best to treat it like it is. Similarly, “You aren’t going to need it” doesn’t really mean you may not need it, but it’s intended to help you avoid unnecessary work. That is, until it causes more work.

In software engineering, the more you code, the more you’ll have to maintain. The Art of Not Doing Stuff, when correctly applied, can save companies as much or more money than building the right things. While I’m not religious these days, there’s a definition of the term “Hermeneutics” that I heard years ago from a Christian radio personality, Hank Hanegraaff. He would say: “Hermeneutics is the art and science of biblical interpretation”. He would go on to explain, it’s a science because it’s guided by a system of rules, but it’s an art in that you get better at it the more you do it. Having heard that explanation years ago, I have long felt these properties are equally descriptive of software development.

For myself, I take a pragmatic approach to YAGNI in that I make selections for a number of things at the outset of a new project which I’ve recognized, through experience, has resulted in less friction down the road; and I defer choices which I reason to have little to no cost by implementing at the point implementing a given User Story’s acceptance criteria drives the need. For example, I do start off setting up a Web project using ASP.NET MVC. I do set up end-to-end testing infrastructure. I do add an open source DI container and set up convention-based registration. These are things which I’ve found actually cause me more friction if I pretend I’m not going to need them. I don’t want to implement my own IHttpHandler and wait until I see the need for a robust routing and pipeline framework and have to go back and reimplement everything. I don’t want to be hand-rolling factories over and over and have to go back and modify code at the point enough duplication reveals the need for dependency injection, and I don’t want to edit a Startup.cs or other bootstrapper component each time a component has a new dependency. Outside of these few concerns, however, I do typically defer things until needed.


Magical Joy
Fri, 27 May 2022 13:00:00 +0000
In a segment of an interview with host Byron Sommardahl on The Driven Developer Podcast, recorded in the summer of 2021, Byron and I discussed a bit about a pattern I introduced to our project when we worked together in 2010 which Byron later dubbed “The Magical Joy Bus”


Nine Years Remote
Thu, 26 May 2022 13:00:00 +0000
A recent inquiry from a recruiter about accepting a partially-remote position prompted me to reflect upon 9 years of working remotely as a software developer.

When I first started working from home, attitudes were quite different than they are in today’s post COVID-19 world. Full time remote software development jobs were few and far between, and most employers that allowed working remotely full time did so due to factors other than a belief that it was more productive and cost-effective. Studies since have overwhelmingly shown that the majority were simply wrong.

One interesting side-effect of the previous year’s COVID-19 political entanglement is the degree to which it forced an entire generation of closed-minded, micro-managing executives to consider (through necessity) that remote work forces, especially for primarily thoughtwork-based positions, were not only viable, but perhaps even superior.

When our entire society started shutting down due to concerns over the COVID-19 virus, I actually hardly noticed at first. Having transitioned to full-time remote work in early 2014, I had long since become accustomed to working remotely by the time society started shutting down. Prior to landing my first full-time remote position, I had worked at a couple of prior companies which allowed working remotely a couple of days a week, so I had some notion of its viability even before then.

While I was already used to working remotely, the whole pandemic thing actually helped to improve the lives of remote developers by remedying many of the productivity nuciences that plagued fully-remote as well as mixed-teams. To a large extent, the primary issues that remote workers had to face prior to everything being shut down was the lack of remote workforce accommodations, namely: mature or provided collaboration tools (e.g Slack, Zoom, Miro, etc.) and equal participation of remote workers on mixed-teams. While David Fullerton, in a StackOverflow blog article written back in 2013, had proffered up the wisdom that “If even one person on the team is remote, every single person has to start communicating online”, joining any mixed team for many still resulted in the remote worker likely being marginalized in meetings as they were the only one on a call while all their co-workers debated approaches around a conference table, were forced to watch some white boarding design session over a video camera while you tried to make out what everyone was saying, or were simply being left out of key social interactions resulting in being professionally disadvantaged in key business decisions due to the formation of clicks, or simply not being present during unplanned discussions, etc. Conscientious employees working from home already knew they were far more efficient at home than in the office, as well as knowing that non-conscientious workers were just a likely or more so to screw off at work as they were at home, but it took everyone being forced to do it for an extended period of time to hammer than into the heads of many executives that felt uncomfortable with conducting business differently than they had in the 20th century.

One absolutely huge thing that goes seemingly undiscussed is the financial impact of working remotely vs. commuting. While I commuted to the office for 20 years before transitioning to full-time remote, it wasn’t until I had become accustomed to working from home and was confronted with the idea of returning back to the world of the commuting zombies that my perspective changed with respect to that commute time. Prior to accepting a full time remote job in early 2014, my commute time was approximately 1 hour one way, and that was on a good day when there wasn’t some minor traffic incident which could easily (and fairly regularly did) add an extra 20-30 minutes to my time. Once I had become accustomed to working remotely, the idea of tacking on an extra 5-10 hours a week in commute time to switch back to a job requiring you to work in the office seemed more like giving my time away for free. Prior to that, all those hours in the vehicle dealing with idiots on the road was just an assumed necessity. Driving to work was like driving anywhere else. Of course in the 20th century you had to drive to buy a new pair of shoes. Of course you had to drive to see a newly released movie. Of course you had to drive to go get a cheeseburger meal at McDonald’s. And of course, you had to drive to get to work. You didn’t think twice about it. You didn’t view commuting to work as 5-10 hours of your personal time given over to your employer for free for the privilege of employment any more than you’d have thought that McDonald’s owed you money for driving to their store to eat. Sure, you could listen to music, or talk radio, or a podcast, or an audio book. It wasn’t, however, really what you would have chosen to be doing at 6:30 in the morning. It wasn’t your time.

Prior to COVID, trying to explain this perspective to those still in the office world was very much like Morpheus trying to explain to Neo that he’s in the Matrix. Sure, recruiters or employers could understand the logic of an argument that commuting is time given to an employer essentially for free, but many would just think it ridiculous for you to go so far as to demand a higher salary for accepting a position requiring a commute (when you knew is wasn’t really required to do the job). This doesn’t even account for wear and tear on vehicles, gas expenses, or the little micro-batches of time you end up spending doing things like food prep, additional “get ready” time, more laundry, etc. that you wouldn’t otherwise do if you were staying home for the day. Moreover, just because you compensate someone for their time, there’s a threshold beyond which your standard hourly rate isn’t worth the time. Okay, you may be willing to commute if your employer is going to compensate you for the extra 5-10 hours on top of the 40 you’re going to spend sitting in their cube farm under their fluorescent lighting (“Not near a window, Jim, because those seats are reserved for managers!”). Are you, however, willing to exchange that extra 5-10 hours a week for money to sit in the office for 45 hours? How about 50 hours? 60? At some point, it isn’t about whether you’re compensated or not. Hell, 40 hours a week really is too damn many hours to begin with. Add to that the insane perspective on time off that Americans get on average compared to much of the rest of the developed world. Hell, even plumbers and HVAC workers get paid for their commute time, and their job isn’t something that can be done remotely.

Imagine if everyone actually accounted for these additional expenses when factoring in the pay they are willing to accept. If so, this would likely account for an extra 25-30% pay increase, accounting for time and travel expenses. For businesses on the fence about whether remote is better than on-site for their bottom line, this would certainly tip the scales. Currently, however, they aren’t forced to think this way. Or at least, many are still operating in a mindset that they don’t have to think this way. When it really comes down to it, a culture of requiring anyone that can do their job remotely to work in the office is really stealing from your employees. Fortunately, COVID has corrected this situation given there have been enough eyes opened to the benefits of remote work and enough businesses which have seen the waste that goes into buying or renting commercial real estate that, even after many business have begun attempting to force employees back into the office, there’s enough employers who now offer remote opportunities to give people a real choice.


User Stories
Wed, 25 May 2022 13:00:00 +0000
The use of User Stories has become fairly commonplace in the software industry. First introduced as an agile requirements-gathering process by Extreme Programming, User Stories arguably owe their popularity most to the adoption of the Scrum framework for which User Stories have become the de facto expression of its prescribed backlog.

So what exactly is a User Story? Put simply, they are a light-weight approach to expressing the desired needs of a software system. The idea behind User Stories, which was introduced as simply “Stories” in the book Extreme Programming Explained - Embrace Change by Kent Beck, was to move away from rigid requirements gathering processes in process, form, and nomenclature. Beck explained that the very word “requirement” was an inhibitor to embracing change because of its connotations of absolutism and permanence. At their inception, the intended form of stories was to create an index card containing a short title, simple description written in prose, and an estimation.

The Three-Part Template

In the late 1990’s, a software company named Connextra was an early adopter of Extreme Programming. In contrast to the distinct roles defined by the Scrum framework, XP doesn’t prescribe any specific roles, but is intended to adapt to existing roles within an organization (e.g. project managers, product managers, executives, technical writers, developers, testers, designers, architects, etc.).

The origin of most of Connextra’s stories were from members of their Marketing and Sales departments which wrote down a simple description of features they desired. This posed a problem for the development team, however, for when the time came to have a conversation about the feature, the development team often had difficulty locating the original stakeholder to begin the conversation. This led the team to formulate a 3-part template to help address friction resulting from ambiguous requirement sources. Their 3-part template is as follows:

	As a [type of user]
	I want to [do something]
	So that I can [get some benefit]


Ironically, while the 3-part template has become the defacto standard for authoring User Story descriptions, Scrum’s “Product Owner” role, most often filled by product development specialists acting as customer proxies, along with the use of software agile-planning tools such as Confluence, Planview, Azure DevOps Boards, etc., which captures who created a given story, tends to greatly diminish the need from which the template originated. This template has since become quite the de facto standard in expressing User Story Descriptions. The irony is that many teams, in caro-cult fashion, often utilize the 3-part template where the original need to identify the author of the story to start the conversation no longer exists. Change has occurred, but because many didn’t understand the underlying impetus for the 3-part template, they were incapable of adapting to that change.

Jeff Patton writes the following concerning the prevalent use of the 3-part story template in his book “User Story Mapping”:


  “… the template has become so ubiquitous, and so commonly taught, that there are those who believe that it’s not a story if it’s not written in that form. … All of this makes me sad. Because the real value of stories isn’t what’s written down on the card. It comes from what we learn when we tell the story.”


Mike Cohn, author of many books on agile processes including “User Stories Applied” and “Agile Estimating and Planning” writes similarly:


  “Too often team members fall into a habit of beginning each user story with “As a user…” Sometimes this is the result of lazy thinking and the story writers need to better understand the product’s users before writing so many “as a user…” stories.”


Cohn’s observations are spot on. In my experience, not only does this happen “too often”, it’s the rule, not the exception. It’s really just human nature. The moment a process becomes formulaic, teams will begin to just go through the motions without engaging their minds. This can be good for manual tasks like brick-laying, or cleaning a house, but it is detrimental to processes intended to promote communication. Sadly, many teams spend an inordinate amount of time on the trappings of things like ensuring their requirements follow the 3-part story template rather than using the story as a tool for its original intent: A placeholder for a conversation.

There and Back Again

While not explicitly stated, the original idea behind Stories in Extreme Programming was to facilitate a conversation, not to define an objective goal. The agile movement started as a way to address issues in the industry’s largely failing attempts to apply manufacturing processes to software development. In particular, Stories were intended to address the underlying motivation for requirements (i.e. how teams determine what to build), not to themselves be requirements.

In many ways, today’s User Stories have become the antithesis of what Kent Beck originally intended. Sadly, much of what is marketed as “agile” today has been corrupted by traditional-minded business analysts, product managers, and marketing agencies who never really understood the agile movement fully. User Stories have, to a large extent, become a casualty of these groups. We’ve gone from requirements to stories and back again. As described by Jeff Patton, “Stories aren’t a way to write better requirements, but a way to organize and have better conversations.”

The Better Way

Ultimately, the question companies seek to answer is: How do we determine the features which provide the best ROI for the business? While it may seem counterintuitive to some, customers aren’t generally the best source for determining what features to build. They can be a source, but they aren’t generally a team’s best source. Customers are, however, the best source for determining how customers currently work, what problems they face, and what friction is involved in any current processes. Various analysis techniques can be used to solicit customer opinions on desired features, but it’s best to rely upon such techniques merely as means to distill the problems currently faced by customers. From there, stories are best created with a simple title and a description of the customer’s problem written in prose with the intent for the description to serve as a starting point for a conversation with the team.

The best way to determine what to build is as a member of a mature agile team. The operative word here is mature. What makes for a mature team is a Product Owner with a background in the problem domain space, a Team Coach with deep knowledge of agile and lean processes, and 3-5 cross-functional developers weighted toward senior experience who have gone through a forming, storming, norming, and performing phase.

User Stories shouldn’t be feature requests, but rather a placeholder for a conversation. A conversation with whom? With your team. About what? About how to iteratively solve the problems you learned from customers in small steps with frequent feedback. Product Owners should not bring requirements to a development team. There’s great power in collaboration. A smart team of 5 to 7 individuals including a subject matter expert (what the Product Owner should bring to the table) and a coach are a far better source for what features to build than just the customer or the Product Owner.

An Example

The following is an example story which more closely follows the original intent of Stories.

Our scenario involves a company which provides a website allowing customers to create wedding and gift registries to send to others. In its current form, the site allows customers to pick from among existing vendors, but the company frequently receives requests from customers about specific products they’d like to see included. The current process involves the Sales team creating tickets for their Operations team to add new vendors to the site which involves updating the production database directly. Additionally, the work currently falls to one person whose job entails other operation tasks which often results in a delay to the timely fulfillment of customer requests.

The following represents the story:




Easily Manage Registry Products

Description
Our customers often want to add products that aren't part of our current vendor product list.  This causes the sales team to constantly have to put in tickets and currently Margret is the only one that is working the tickets.  We need a better solution!





Note how the description is written in prose (i.e. in normal conversational language), and doesn’t follow the wooden 3-part template. Note also, the story doesn’t prescribe how to solve the problem. It just provides background on what the problem is and who it affects. It isn’t just that the story doesn’t dictate implementation details, but that it doesn’t dictate the solution at all. This is the ideal starting point for most stories. It’s a placeholder for a conversation about how to solve the problem.

From here, the team would collaborate on the story to determine the best solution that results in the smallest feature increment which adds value to the end user. Several ideas may be discussed. The system could integrate with a 3rd-party content management system, allowing people within the company without SQL experience to update content. Alternately, the team may decide that adding a feature to allow customers to add custom products directly to their personal event registry is both easier, and scales far better than solutions requiring company employees to work tickets.

As part of a story refinement session, the team may update the story with acceptance criteria to guide the implementation:




Easily Manage Registry Products

Description
Our customers often want to add products that aren't part of our current vendor product list.  This causes the sales team to constantly have to put in tickets and currently Margret is the only one that is working the tickets.  We need a better solution!




Acceptance Criteria
When the customer navigates to the edit registry view

   it should contain a link for adding custom products



When the customer clicks the add custom product link

  it should navigate to the add custom product view (note: see balsamiq wireframe attached)



When the customer adds a new custom product with valid inputs

  it should add the custom product to the customers registry

  it should display a success message in the application banner

  it should navigate back to the edit registry page



When the customer enters invalid custom product parameters

  it should show standard field level error messages

  it should not enable the save button





While an Acceptance Criteria section isn’t mandatory, it can often be valuable for helping to frame the scope of the story, a reminder to the team of the high-level plans discussed for deferred work, and/or may serve as the team’s Definition of Done. For small teams involving just a few members, or for highly adaptive and collaborative teams, it may be enough to just just write “We decided to add a feature to allow the customer to add their own products!”. The team may very well take the initial story description and rapidly iterate on a solution, deciding together when they think it’s done! (Gasp!) Of course, this level of informality probably is only best suited to highly cohesive, highly functioning teams. For inexperienced to moderately experienced teams, some denotation of Acceptance Criteria would be advisable. The key point is, the story didn’t arrive to the team in the form of requirements, but as a placeholder for a conversation.

Conclusion

As the adoption of agile frameworks such as Scrum have become more mainstream, a number of practices have become formulaic and adopted by teams via a cargo-cult onboarding to agile practices without truly grasping what it means to be agile. The User Story has all but lost it original intent by many teams who have done little more than slap agile labels onto Waterfall manufacturing processes. User Stories were never intended to be requirements, but rather a placeholder for a conversation with the development team. Let’s do better.


.Net Project Builds with Node Package Manager
Thu, 10 Dec 2020 07:00:00 +0000
A few years ago, I wrote an article entitled Separation of Concerns: Application Builds & Continuous Integration wherein I discussed the benefits of separating project builds from CI/CD concerns by creating a local build script which lives with your project.  Not long after writing that article, I was turned on to what I’ve come to believe is one of the easiest tools I’ve encountered for managing .Net project builds thus far: npm.

Most development platforms provide a native task-based build technology.  Microsoft’s tooling for these needs is MSBuild: a command-line tool whose build files double as Visual Studio’s project and solution definition files.  I used MSBuild briefly for scripting custom build concerns for a couple of years, but found it to be awkward and cumbersome.  Around 2007, I abandoned use of MSBuild for creating builds and began using Rake.  While it had the downside of requiring a bit of knowledge of Ruby, it was a popular choice among those willing to look outside of the Microsoft camp for tooling and had community support for working with .Net builds through the Albacore library.  I’ve used a few different technologies since, but about 5 years ago I saw a demonstration of the use of npm for building .Net projects at a conference and I was immediately sold.  When used well, it really is the easiest and most terse way to script a custom build for the .Net platform I’ve encountered.

“So what’s special about npm?” you might ask.  The primary appeal of using npm for building applications is that it’s easy to use.  Essentially, it’s just an orchestration of shell commands.

Tasks
With other build tools, you’re often required to know a specific language in addition to learning special constructs peculiar to the build tool to create build tasks.  In contrast, npm’s expected package.json file simply defines an array of shell command scripts:

{
  "name": "example",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    "clean": "echo Clean the project.",
    "restore": "echo Restore dependencies.",
    "compile": "echo Compile the project.",
    "test": "echo Run the tests.",
    "dist": "echo Create a distribution."
  },
  "author": "Some author",
  "license": "ISC"
}


As with other build tools, NPM provides the ability to define dependencies between build tasks.  This is done using pre- and post- lifecycle scripts.  Simply, any task issued by NPM will first execute a script by the same name with a prefix of “pre” when present and will subsequently execute a script by the same name with a prefix of “post” when present.  For example:

{
  "name": "example",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    "clean": "echo Clean the project.",
    "prerestore": "npm run clean",
    "restore": "echo Restore dependencies.",
    "precompile": "npm run restore",
    "compile": "echo Compile the project.",
    "pretest": "npm run compile",
    "test": "echo Run the tests.",
    "prebuild": "npm run test",
    "build": "echo Publish a distribution."
  },
  "author": "Some author",
  "license": "ISC"
}


Based on the above package.json file, issuing “npm run build” will result in running the tasks of clean, restore, compile, test, and build in that order by virtue of each declaring an appropriate dependency.

Given you’re okay with limiting a fully-specified dependency chain where a subset of the build can be initiated at any stage (e.g. running “npm run test” and triggering clean, restore, and compile first) , the above orchestration can be simplified by installing the npm-run-all node dependency and defining a single pre- lifetime script for the main build target:

{
  "name": "example",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    "clean": "echo Clean the project.",
    "restore": "echo Restore dependencies.",
    "compile": "echo Compile the project.",
    "test": "echo Run the tests.",
    "prebuild": "npm-run-all clean restore compile test",
    "build": "echo Publish a distribution."
  },
  "author": "John Doe",
  "license": "ISC",
  "devDependencies": {
    "npm-run-all": "^4.1.5"
  }
}


In this example, issuing “npm run build” will result in the prebuild script executing npm-run-all with the parameters: clean, restore, compile and test which it will execute in the order listed.

Variables
Aside from understanding how to utilize the pre- and post- lifecycle scripts to denote task dependencies, the only other thing you really need to know is how to work with variables.

Node’s npm command facilitates the definition of variables by command-line parameters as well as declaring package variables.  When npm executes, each of the properties declared within the package.json are flattened and prefixed with “npm_package_”.  For example, the standard “version” property can be used as part of a dotnet build to denote a project version by referencing ${npm_package_version}:

{
  "name": "example",
  "version": "1.0.0",
  "description": "",
  "configuration": "Release",
  "scripts": {
    "build": "dotnet build ./src/*.sln /p:Version=${npm_package_version}"
  },
  "author": "John Doe",
  "license": "ISC",
  "devDependencies": {
    "npm-run-all": "^4.1.5"
  }
}


Command-line parameters can also be passed to npm and are similarly prefixed with “npm_config_” with any dashes (“-”) replaced with underscores (“_”).  For example, the previous version setting could be passed to dotnet.exe in the following version of package.json by issuing the below command:

npm run build --product-version=2.0.0


{
  "name": "example",
  "version": "1.0.0",
  "description": "",
  "configuration": "Release",
  "scripts": {
    "build": "dotnet build ./src/*.sln /p:Version=${npm_config_product_version}"
  },
  "author": "John Doe",
  "license": "ISC",
  "devDependencies": {
    "npm-run-all": "^4.1.5"
  }
}


(Note: the parameter –version is an npm parameter for printing the version of npm being executed and therefore can’t be used as a script parameter.)

The only other important thing to understand about the use of variables with npm is that the method of dereferencing is dependent upon the shell used.  When using npm on Windows, the default shell is cmd.exe.   If using the default shell on Windows, the version parameter would need to be deference as %npm_config_product_version%:

{
  "name": "example",
  "version": "1.0.0",
  "description": "",
  "configuration": "Release",
  "scripts": {
    "build": "dotnet build ./src/*.sln /p:Version=%npm_config_product_version%"
  },
  "author": "John Doe",
  "license": "ISC",
  "devDependencies": {
    "npm-run-all": "^4.1.5"
  }
}

Until recently, I used a node package named “cross-env” which allows you to normalize how you dereference variables regardless of platform, but for several reasons including cross-env being placed in maintenance mode, the added dependency overhead, syntax noise, and support for advanced variable expansion cases such as default values, I’d recommend any cross-platform execution be supported by just standardizing on a single shell (e.g. “Bash”).  With the introduction of  Windows Subsystem for Linux and the virtual ubiquity of git for version control, most developer Windows systems already contain the bash shell.  To configure npm to use bash at the project level, just create a file named .npmrc at the package root containing the following line:

script-shell=bash


Using Node Packages
While not necessary, there are many CLI node packages that can be easily leveraged for aiding in authoring your builds.  For example, a package named “rimraf”, which functions like Linux’s “rm -rf” command, is a utility you can use to implement a clean script for recursively deleting any temporary build folders created as part of previous builds.  In the following package.json build, a package target builds a NuGet package which it outputs to a dist folder in the package root.  The rimraf command is used to delete this temp folder as part of the build script’s dependencies:

{
  "name": "example",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    "clean": "rimraf dist",
    "prebuild": "npm run clean",
    "build": "dotnet pack ./src/ExampleLibrary/ExampleLibrary.csproj -o dist /p:Version=${npm_package_version}"
  },
  "author": "John Doe",
  "license": "ISC",
  "devDependencies": {
    "npm-run-all": "^4.1.5",
    "rimraf": "^3.0.2"
  

Conventional Options
Fri, 20 Nov 2020 07:00:00 +0000
I’ve really enjoyed working with the Microsoft Configuration libraries introduced with .Net Core approximately 5 years ago.  The older XML-based API was quite a pain to work with, so the ConfigurationBuilder and associated types provided a long overdue need for the platform.

I had long since adopted a practice of creating discrete configuration classes populated and registered with a DI container over direct use of the ConfigurationManager class within components, so I was pleased to see the platform nudge developers in this direction through the introduction of the IOptions type.

A few aspects surrounded the prescribed use of the IOptions type of which I wasn't particularly fond were needing to inject IOptions rather than the actual options type, taking a dependency upon the Microsoft.Extensions.Options package from my library packages, and the cermony of binding the options to the IConfiguration instance.  To address these concerns, I wrote some extension methods which took care of binding the type to my configuration by convention (i.e. binding a type with a suffix of Options to a section corresponding to the option type's prefix) and registering it with the container.

I’ve recently released a new version of these extensions supporting several of the most popular containers as an open source library.  You can find the project here.

The following are the steps for using these extensions:

Step 1
Install ConventionalOptions for the target DI container:

$> nuget install ConventionalOptions.DependencyInjection


Step 2
Add Microsoft’s Options feature and register option types:

  services.AddOptions();
  services.RegisterOptionsFromAssemblies(Configuration, Assembly.GetExecutingAssembly());


Step 3
Create an Options class with the desired properties:

    public class OrderServiceOptions
    {
        public string StringProperty { get; set; }
        public int IntProperty { get; set; }
    }


Step 4
Provide a corresponding configuration section matching the prefix of the Options class (e.g. in appsettings.json):

{
  "OrderService": {
    "StringProperty": "Some value",
    "IntProperty": 42
  }
}


Step 5
Inject the options into types resolved from the container:

    public class OrderService
    {
        public OrderService(OrderServiceOptions options)
        {
            // ... use options
        }
    }


Currently ConventionalOptions works with Microsoft’s DI Container, Autofac, Lamar, Ninject, and StructureMap.

Enjoy!


Collaboration vs. Critique
Fri, 18 May 2018 17:00:00 +0000
While there are certainly a number of apps developed by lone developers, it’s probably safe to say that the majority of professional software development occurs by teams.  The people aspect of software development, more often than not, tends to be the most difficult part of software engineering.  Unfortunately the software field isn’t quite like other engineering fields with well-established standards, guidelines, and apprenticeship programs.  The nature of software development tends to follow an empirical process model rather than a defined process model.  That is to say, software developers tend to be confronted with new problems every day and most of the problems developers are solving aren’t something they’ve ever done in the exact same way with the exact same toolset.  Moreover, there are often many different ways to solve the same problem, both with respect to the overall process as well as the implementation.  This means that team members are often required to work together to determine how to proceed.  Teams are often confronted with the need to explore multiple competing approaches as well as review one another’s designs and implementation.  One thing I’ve learned during the course of my career is that the stage these types of interactions occur within the overall process has a significant impact on whether the interaction is generally viewed as collaboration or critique.

To help illustrate what I’ve seen happen countless times both in catch-up design sessions and code reviews, consider the following two scenarios:

Scenario 1
Tom and Sally are both developers on a team maintaining a large-scale application.  Tom takes the next task in the development queue which happens to have some complex processes that will need to be addressed.  Being the good development team that they are, both Tom and Sally are aware of the requirements of the application (i.e. how the app needs to work from the user’s perspective), but they have deferred design-level discussions until the time of implementation.  After Tom gets into the process a little, seeing that the problem is non-trivial, he pings Sally to help him brainstorm different approaches to solving the problem.  Tom and Sally have been working together for over a year and have become accustomed to these sort of ad-hoc design sessions.  As they begin discussing the problem, they each start tossing ideas out on the proverbial table resulting in multiple approaches to compare and contrast.  The nature of the discussion is such that neither Tom nor Sally are embarrassed or offended when the other points out flaws in a given design idea because there’s a sense of safety in their mutual understanding that this is a brainstorming session and that neither have thought in depth about the solutions being set forth yet.  Tom throws out a couple of ideas, but ends up shooting them down himself as he uses Sally as a sounding board for the ideas.  Sally does the same, but toward the end of the conversation suggests a slight alteration to one of Tom’s initial suggestions that they think may make it work after all.  They end the session with a sense that they’ve worked together to arrive at the best solution.

Scenario 2
Bill and Jake are developers on another team.  They tend to work in a more siloed fashion, but they do rely upon one another for help from time to time and they are required to do code reviews prior to their code being merged into the main branch of development.  Bill takes the next task in the development queue and spends the better part of an afternoon working out a solution with a basic working skeleton of the direction he’s going.  The next day he decides that it might be good to have Jake take a look at the design to make him aware of the direction.  Seeing where Bill’s design misses a few opportunities to make the implementation more adaptable to changes in the future, Jake points out where he would have done things differently.  Bill acknowledges that Jake’s suggestions would be better and would have probably been just as easy to implement from the beginning, but inwardly he’s a bit disappointed that Jake didn’t like his design as-is and that he has to do some rework.  In the end, Bill is left with a feeling of critique rather than collaboration.

Whether it’s a high-level UML diagram or working code, how one person tends to perceive feedback on the ideas comprising a potential solution has everything to do with timing. It can be the exact same feedback they would have received either way, but when the feedback occurs often makes a difference between whether it’s perceived as collaboration or critique.  It’s all about when the conversation happens.

Model	Size	Chat	Code	Tool call	Notes
mistral:latest	7B	3s	1s	proper
llava:7b	7B	4s	<1s	rejected	Vision model
gemma4:latest	~12B	6s	1s	proper
qwen3:14b	14B	4s	1s	proper	think=false required
phi4:14b	14B	5s	1s	rejected
qwen2.5:14b	14B	6s	1s	proper
qwen2.5-coder:14b	14B	6s	1s	text (not structured)	“coder” does not mean tool-aware
gemma4:26b	26B	9s	3s	proper	Partial CPU offload
glm-4.7-flash	30B MoE	8s	4s	proper
qwen3:30b	30B	14s	8s	proper	Slowest in pool

Los Techies

Big Design Up Front Is Responsible Again

Vertical Slice Architecture Webinar

AutoMapper 16.2.0 and MediatR 14.2.0 Released

23 Models, One Weekend, Final Picks

Expanding to 23 Models

The Pi Harness Experiment

The Scoring Expansion

Three New Python Agentic Tasks

The Full Leaderboard

The Surprising Results

The Actual Picks

What Single-Shot Scores Actually Measure

Closing

The Config That Changed Everything

The edit_format Lever

The A/B Results

The Thinking-Mode Problem

The num_ctx Revelation

The Architect Mode Dead End

The Scaffolding Experiment

Where the Leaderboard Stands

Single-Shot Lies

The Task

The Results

What Went Wrong With gemma4

What Went Wrong With qwen3-coder

What It Means

Where This Leaves Us

Building a .NET 10 Benchmark Harness

Architecture

The Code Tests

Hello World: The Real Test

Scoring

Unit Tests

First Complete Run

Search — The Evolution of the Karpathy LLM Wiki

What the Agent Sees

The Full Tool Set

The hybrid_alpha Parameter

How the Search Works

The Vector Query

The FTS Query

The Data Model

The Write Path

Gotchas

Which Local Models Can Actually Code?

The Setup

First Pass: Two Prompts, PowerShell

The Think-Mode Wall

Tool-Calling: Where Things Got Interesting

Mid-Phase Additions

The Baseline Table

What “Works” Actually Means

Back from the dead

AutoMapper 16.1.1 Released

Thread Deadlock

Security

AutoMapper 16.1 and MediatR 14.1 Released

AutoMapper 16.0.0 and MediatR 14.0.0 Released with .NET 10 Support

AutoMapper 15.1 and MediatR 13.1 Released

AutoMapper and MediatR Roadmaps

Tracking official .NET support

AutoMapper Roadmap

MediatR Roadmap

AutoMapper and MediatR Commercial Editions Launch Today

What's the new license?

How much will it cost?

Do you have free licenses for <insert situation here>?

How do I get the commercial versions?

What about the existing versions?

Why Lucky Penny?

AutoMapper and MediatR Licensing Update

Dual Licensing Model

Thoughts on Pricing

AutoMapper and MediatR Going Commercial

How I Got Here

What Will This Look Like?

When Will This Happen?

Final Thanks

The `hybrid_alpha` Parameter