Blog

The Bio-Dynamics dashboard exposes a lot of buttons: regional stressors, inoculations, environment sliders, and four catalog tabs for strains, prebiotics, postbiotics, and products. The trick is not rendering HTML — it is keeping the catalog honest as content grows. This post explains the data-first layout and the action impact preview panel. Live demoFull sourceInteractive lab Bio-Dynamics: Microbiome Sandbox Hover strains and products in the live lab to see impact preview, or browse the catalog TypeScript files on GitHub. Open live lab View source on GitHub Data catalogs, not hard-coded panels Almost every control maps to a typed catalog under src/data/: ...

Most microbiome diagrams are flat. Bio-Dynamics tries the opposite: a single Three.js scene that starts as a rotatable body map, then animates into a tissue cross-section when you pick a region — with microbe meshes, SCFA particles, and fog density tied to live simulation state. This post covers the visualization layer. Companion source and the full architecture write-up are in the repository. Live demoFull sourceInteractive lab Bio-Dynamics: Microbiome Sandbox Open the live lab, zoom into gut or nasal tissue, then inspect the Three.js scene code on GitHub. Open live lab View source on GitHub One scene, two modes SceneManager owns a single WebGL scene with two interaction modes: ...

Bio-Dynamics is an educational 3D lab, not a clinical simulator. That constraint shaped every decision in the simulation layer: reproducible ticks, scalar tissue state, capped agent counts, and inflammation that emerges from pressure instead of jumping on every button press. This post walks through the engine design. Live demoFull sourceInteractive lab Bio-Dynamics: Microbiome Sandbox Run the live lab or inspect the simulation source — tick engine, golden tests, and full docs in the repository. Open live lab View source on GitHub Why deterministic? Interactive demos fail the educational test when the same button sequence produces different outcomes on refresh. Readers cannot build intuition from noise. ...

I write a lot about Angular platforms, monorepos, and production frontends. Bio-Dynamics is different: a browser-only educational lab where you rotate a 3D body map, zoom into tissue, and run deterministic probiotic scenarios tied to health articles on omid.dev. It started for three reasons — a human one, a developer-story one, and a career one. This post is the anchor for that project. Deeper technical posts follow in a short series linked at the end. ...

Most frontend teams do not have a testing problem because they lack tests. They have a testing problem because nobody can explain why a specific test exists. The result is familiar: hundreds of unit tests that prove implementation details; a few end-to-end tests that fail whenever timing changes; component tests that duplicate what unit tests already cover; slow CI pipelines that people stop trusting; high coverage numbers with very little confidence. This is especially common in large Angular codebases. Angular gives teams a serious testing toolbox: TestBed, standalone components, dependency injection, router testing, HTTP testing utilities, harnesses, and good compatibility with tools like Jest, Vitest, Cypress, and Playwright. The tooling is not the hard part. ...

Flaky tests are worse than failing tests. A failing test tells the team something broke. A flaky test teaches the team to negotiate with reality: “Run it again.” “CI is weird today.” “It passes locally.” “That test always fails on Mondays.” “Merge it, the failure is unrelated.” That is how a test suite loses authority. The first few flakes feel harmless. Then people stop reading failures carefully. Then a real regression hides inside the noise. ...

I wanted an excuse to build a small real Linux app. Not a shell script. Not a giant desktop application. Not a kernel module. Just a focused program that talks to Linux through the interfaces the system already exposes, gives that data a shape, and presents it as something a normal desktop user can run. Desktop stutter turned out to be a good excuse. My own machine is not slow: modern CPU, fast NVMe storage, plenty of RAM, KDE Plasma on Wayland, and a current kernel. Most of the time it feels excellent. Then, once in a while, the pointer hesitates, a window animation misses a beat, audio gets a tiny crackle, or the browser pauses while a package update or build is running. ...

I have not switched back to Kubuntu yet. I am still daily-driving Manjaro KDE on my ASUS Vivobook Pro 15, with Plasma 6.6.5, Wayland, btrfs, and a hybrid Intel Arc + NVIDIA RTX 3050 setup. But I have been running Kubuntu 26.04 LTS in VirtualBox, comparing the two side by side, and asking a question I did not expect to ask again after several happy years on Arch-based rolling release: ...

Open almost any mature Angular screen and you will find the same shape: 1 2 3 4 5 loading = false; error: string | null = null; data: Account[] | null = null; retrying = false; submitted = false; The template then becomes a negotiation: 1 2 3 4 5 6 7 8 9 @if (loading) { <app-spinner /> } @else if (error) { <app-error [message]="error" /> } @else if (!data?.length) { <app-empty-state /> } @else { <account-table [rows]="data!" /> } This looks fine. It ships. It passes review. And then production teaches you that the screen was never modeled as one thing. It was modeled as five independent switches that sometimes agree and sometimes do not. ...

One thing I have always found frustrating in technical writing is the gap between a nice explanation and code you can actually explore. A post can explain an idea clearly, but if the code is only a few isolated snippets, the reader still has to imagine the project around it. Where does this file live? What package versions were used? How do the pieces connect? Can I run it, or is it only illustrative? ...

Cursor is distributed for Linux as an AppImage, which works well on Manjaro because you do not need to wait for a package in the official repositories or the AUR. Before writing this post, I tried installing Cursor from the AUR, but it was not stable enough for me. I also did not love the extra Electron dependency, although that was not the main reason I moved away from that method. At the time of writing, there is no official Snap release, no official Manjaro or Arch package for Cursor either. ...

Angular has always had a complicated relationship with tooling. People call it “heavy” when they want something lighter, but that same weight is often what helps large teams keep moving without reinventing the architecture every sprint. That is why Angular’s MCP server work in the Angular 21 cycle is more interesting than another code-generation headline. This is not just “AI can write Angular now.” AI could already write Angular, often badly. The real question is whether Angular can give AI tools enough project-aware context to stop generating outdated, half-remembered patterns. ...

Every framework eventually discovers the same truth: developers love nice syntax until nice syntax becomes a hiding place. Angular’s recent template improvements are genuinely useful. Multiple consecutive @case blocks make some @switch statements cleaner. Spread and rest support in templates removes awkward helper code in small cases. Angular 21.2’s template additions, such as arrow functions and exhaustive @switch checks with @default never, continue the same direction: templates are becoming more expressive and more type-aware. ...

Most forms discussions start in the wrong place. They compare syntax. Reactive Forms gives us FormGroup, FormControl, validators, status flags, and a lot of well-known muscle memory. Signal Forms gives us fields, signal-shaped state, form-level submission, custom controls, and migration tools. It is tempting to treat this as a cleaner API for the same old job. But that misses the bigger shift. Signal Forms are not only about filling inputs and showing validation messages. They push forms into the same mental model as the rest of modern Angular state: explicit signals, derived values, and state transitions that can be composed instead of chased through subscriptions. ...

It happened to me this morning. After 15 years in the trenches—building frontend architectures, dipping into the backend, leading teams, and surviving countless framework wars—I hit a wall. Not a technical wall, but a conceptual one. I realized I didn’t know what Corepack was. I’ve never actually used Yarn. I’ve heard of modern test runners like Playwright and code‑generation tools like Orval, but I’ve never managed to actually run one in a production pipeline. ...