DEV Community: Devanshu Biswas

OrderHub Day 9: Integration Tests on Real Postgres With Testcontainers

Devanshu Biswas — Sun, 28 Jun 2026 21:31:44 +0000

OrderHub Day 9: stop testing against a fake database. Today's integration tests spin up a REAL PostgreSQL in Docker — with Testcontainers — and they actually ran: 10/10 green against Postgres 16.

🐳 See the container lifecycle: https://dev48v.infy.uk/orderhub/day9-testcontainers.html

Mock vs H2 vs the real thing

Mocks (Day 8) are fast but never prove your SQL/JPA mapping works.
H2 (in-memory) is a stand-in — and subtle Postgres-only behavior (types, case-sensitivity, SQL dialect) slips right through.
Testcontainers boots an actual Postgres in Docker for the test, runs your real Flyway migrations, exercises real JDBC, then throws the container away. No shared test DB to pollute.

The setup

@SpringBootTest
@Testcontainers
class OrderApiIT {
  @Container static PostgreSQLContainer<?> db =
      new PostgreSQLContainer<>("postgres:16-alpine");

  @DynamicPropertySource
  static void props(DynamicPropertyRegistry r) {
    r.add("spring.datasource.url", db::getJdbcUrl);
    r.add("spring.datasource.username", db::getUsername);
    r.add("spring.datasource.password", db::getPassword);
  }
  // ... TestRestTemplate POST -> 201 -> GET -> 200, all on real Postgres
}

@DynamicPropertySource wires the container's JDBC URL into Spring at runtime. One test proves controller → service → JPA → real Postgres end-to-end.

Worth knowing

ITs need Docker available (locally + in CI). Name them *IT and run them with failsafe, separate from fast unit tests.

🔨 Full walkthrough (deps → @Container → @DynamicPropertySource → full-stack IT) on the page: https://dev48v.infy.uk/orderhub/day9-testcontainers.html

OrderHub — a production-grade Spring Boot backend, one feature a day.
🌐 https://dev48v.infy.uk · Code: https://github.com/dev48v/order-hub-from-zero

Mixture of Experts: Big Models, Cheap Inference

Devanshu Biswas — Sun, 28 Jun 2026 21:31:02 +0000

How does a model have hundreds of billions of parameters but still run affordably? Mixture of Experts. Instead of every token using the whole network, a router sends each token to just a few specialists. Here's the routing, visualized.

🧠 Watch the router route each token: https://dev48v.infy.uk/ai/days/day19-mixture-of-experts.html

The idea

A layer holds N expert sub-networks (say 8) plus a small router/gating network. For each token, the router scores the experts and sends the token to only the top-k (e.g. top-2). Those experts light up and do the work; the other six stay dark. Sparse activation.

In the demo you feed a sentence token-by-token and watch different tokens route to different experts (some specialize in function words, others in numbers, etc.), with a live "2/8 active" tally.

Why it's a big deal

It decouples capacity from compute. Total params can be enormous (all experts exist in memory), but the active params per token stay small — so you get the quality of a huge model at a fraction of the per-token cost. Flip to "Dense" in the demo and all 8 fire = 4× the compute.

The catches

Load balancing: an auxiliary loss stops the router from overusing a few experts.
Memory: you must hold all experts in memory even though each token uses a few.
Routing can be unstable to train.

Mixtral's "8x7B" is exactly this: 8 experts, top-2 per token.

🔨 Built from concept (experts + gating → top-k route → combine → load-balance loss) on the page: https://dev48v.infy.uk/ai/days/day19-mixture-of-experts.html

Part of AIFromZero. 🌐 https://dev48v.infy.uk

Batch Normalization: Why It Made Deep Nets Trainable

Devanshu Biswas — Sun, 28 Jun 2026 21:30:21 +0000

Batch Normalization is one of those tricks that made deep networks suddenly trainable. The idea is simple — keep each layer's inputs in a healthy range — and the payoff is huge: faster training, higher learning rates, more stability. Here it is, visualized.

📊 Toggle BN on/off and watch: https://dev48v.infy.uk/dl/day19-batch-norm.html

The problem: internal covariate shift

As activations flow through layers, their distribution drifts and spreads. Deep layers keep chasing a moving target; some saturate, gradients vanish or explode, and training crawls (or diverges).

What BN does

After a layer, normalize each feature over the mini-batch — subtract the batch mean, divide by the batch std — so activations stay ~mean 0, std 1. Then apply two learnable parameters, γ (scale) and β (shift), so the network can rescale if it needs to. The demo shows each layer's histogram snapping back to a tidy bell.

Why you care

Train faster and with higher learning rates (the demo's no-BN loss diverges at high LR; BN holds steady).
Less sensitive to weight initialization; mild regularization effect.

The catches

Train vs inference differ: at inference you use running mean/var, not the batch's.
Batch-size dependent — tiny batches hurt it.
Transformers prefer LayerNorm (normalize per token, not per batch).

🔨 Built from scratch (batch mean/var → normalize → γ,β → running stats) on the page: https://dev48v.infy.uk/dl/day19-batch-norm.html

Part of DeepLearningFromZero. 🌐 https://dev48v.infy.uk

The Bias-Variance Tradeoff, Finally Visualized

Devanshu Biswas — Sun, 28 Jun 2026 21:29:39 +0000

Underfitting and overfitting aren't two separate problems — they're two ends of one dial. That dial is the bias-variance tradeoff, and once you see it, model selection finally makes sense. Here it is, live.

⚖️ Slide model complexity and watch: https://dev48v.infy.uk/ml/day19-bias-variance.html

Error has three parts

Total expected error = bias² + variance + irreducible noise.

Bias = error from wrong/too-simple assumptions → the model can't capture the pattern → underfitting.
Variance = error from being too sensitive to the specific training data → it memorizes noise → overfitting.
Noise = irreducible; no model beats it.

The U-curve

Crank model complexity (the demo uses polynomial degree): training error always drops — which is exactly why training error alone fools you. But test error is U-shaped: high at low complexity (bias), dips at the sweet spot, rises at high complexity (variance). The best model is the bottom of the U.

The levers

More data → lowers variance.
Regularization → lowers variance (Day 17).
Better features → lowers bias.
Bagging cuts variance; boosting cuts bias (Days 11 & 15).
Find the sweet spot with cross-validation (Day 18).

🔨 Built from scratch (fit increasing degrees → measure train vs test → find the dip) on the page: https://dev48v.infy.uk/ml/day19-bias-variance.html

Part of MachineLearningFromZero. 🌐 https://dev48v.infy.uk

Generate SHA Hashes in the Browser With the Web Crypto API

Devanshu Biswas — Sun, 28 Jun 2026 21:28:57 +0000

Need a SHA-256 of some text or a file? Your browser already has a crypto engine — no library, no server. Here's a hash generator built on the Web Crypto API.

🔐 Try it (text or file): https://dev48v.infy.uk/solve/day19-hash-generator.html

The whole thing

const bytes = new TextEncoder().encode(text);
const buf   = await crypto.subtle.digest("SHA-256", bytes);
const hex   = [...new Uint8Array(buf)].map(b => b.toString(16).padStart(2, "0")).join("");

That's a real SHA-256. Swap in "SHA-1" / "SHA-384" / "SHA-512". For files, read an ArrayBuffer and digest that. (Sanity: SHA-256 of "abc" = ba7816bf8f01cfea….)

What a hash actually is

A one-way fingerprint: same input → same hash, any change → a totally different hash (the avalanche effect — the demo shows it), and you can't reverse it. Used for integrity/checksums, content addressing (git commits are hashes), and dedup.

Two things people get wrong

Hashing ≠ encryption. No key, not reversible. Don't use it to "hide" data.
Don't hash passwords with plain SHA. It's too fast to brute-force — use a slow, salted KDF (bcrypt/argon2). And MD5/SHA-1 are broken; use SHA-256+.

🔨 Full build (TextEncoder → crypto.subtle.digest → hex → files) on the page: https://dev48v.infy.uk/solve/day19-hash-generator.html

Part of SolveFromZero. 🌐 https://dev48v.infy.uk

Self-Ask Prompting: Let the Model Interview Itself

Devanshu Biswas — Sun, 28 Jun 2026 21:28:15 +0000

Ask an LLM a multi-hop question ("who was president when the composer of Rhapsody in Blue was born?") and it often skips a hop and guesses. Self-Ask fixes that by making the model interview itself — out loud.

❓ Watch it ask its own follow-ups: https://dev48v.infy.uk/prompt/day19-self-ask.html

The format

Self-Ask gives the model a strict scaffold:

Are follow-up questions needed here? Yes.
Follow-up: Who composed Rhapsody in Blue?
Intermediate answer: George Gershwin.
Follow-up: When was George Gershwin born?
Intermediate answer: 1898.
Follow-up: Who was U.S. president in 1898?
Intermediate answer: William McKinley.
So the final answer is: William McKinley.

The demo races a direct answer (skips a hop, wrong) against the self-ask chain (surfaces each intermediate fact, right).

Why it works

It forces the model to decompose a multi-hop question into single-hop questions it can actually answer, then compose them. Each hop is easy; the leap was the hard part.

The superpower: + search

Because each follow-up is a clean, atomic question, you can answer it with a search tool instead of the model's memory — that's the famous "Self-Ask + Search" combo for up-to-date, grounded multi-hop answers.

🔨 Full pattern (few-shot self-ask prompt → loop follow-ups → compose final) on the page: https://dev48v.infy.uk/prompt/day19-self-ask.html

Part of PromptFromZero. 🌐 https://dev48v.infy.uk

A Date Picker From Scratch — the Whole Calendar Is Two Lines

Devanshu Biswas — Sun, 28 Jun 2026 21:27:33 +0000

A date picker seems like the thing you must grab a library for. You don't — the whole calendar is two lines of Date math. Here's one built from scratch, with keyboard nav and month navigation.

📅 Try it: https://dev48v.infy.uk/design/day19-date-picker.html

The two lines that build any month

const firstWeekday = new Date(year, month, 1).getDay();      // where day 1 sits
const daysInMonth  = new Date(year, month + 1, 0).getDate(); // last day of month

new Date(year, month+1, 0) is "day 0 of next month" = the last day of this month — and it handles leap years for free (Feb 2024 → 29, Feb 2025 → 28).

Building the grid

Lay out a 6×7 grid: pad the front with firstWeekday blank cells so day 1 lands under the right weekday, then fill 1…daysInMonth. Highlight today and the selected day; prev/next arrows just change the month (and roll the year over at the boundaries).

The gotcha

JavaScript months are 0-indexed (January = 0). That one fact causes half of all date bugs.

Add keyboard arrows, click-outside-to-close, and a min-date toggle, and you've got a real picker — no dependency.

🔨 Full build (Date math → grid offset → select/format → month nav) on the page: https://dev48v.infy.uk/design/day19-date-picker.html

Part of DesignFromZero. 🌐 https://dev48v.infy.uk

I Built the 15-Puzzle — and Why Half of All Shuffles Are Impossible

Devanshu Biswas — Sun, 28 Jun 2026 21:26:51 +0000

The 15-puzzle is a 150-year-old toy with a famous math twist: shuffle it wrong and it's literally impossible to solve. Here's a playable version that never deals an unsolvable board.

🔢 Play it: https://dev48v.infy.uk/game/day19-15-puzzle.html

The board

A 4×4 grid: tiles 1–15 plus one blank. A legal move slides a tile that's adjacent to the blank into the gap (it's really just swapping a tile with the blank). Arrow keys move the neighbouring tile into the blank.

The solvability trap

Here's the gotcha: exactly half of all 16! arrangements are unsolvable. If you scramble by randomly placing tiles, half your boards can never reach 1–15. The clean fix in this build: start from the solved state and make hundreds of random legal moves — any position reachable by legal moves is, by definition, solvable.

(The deeper reason is the inversion-parity theorem: for a 4-wide board, solvability depends on the inversion count plus the blank's row from the bottom — covered on the UNDERSTAND tab.)

The rest

Win when tiles read 1–15 with the gap bottom-right; track moves + time; smooth CSS slide.

🔨 Full build (grid → swap-with-blank → solvable shuffle → win check) on the page: https://dev48v.infy.uk/game/day19-15-puzzle.html

Part of GameFromZero. 🌐 https://dev48v.infy.uk

Context vs Prop Drilling: I Put the Re-render Blast Radius Side by Side

Devanshu Biswas — Sun, 28 Jun 2026 21:13:47 +0000

"Prop drilling is bad, use Context" is repeated everywhere — but the actual cost stays abstract. So I put the two approaches side by side with live render counters. Click one button and the difference is impossible to miss.

▶ Live demo: https://context-vs-props-drilling.vercel.app/
Source (React 19 + TS): https://github.com/dev48v/context-vs-props-drilling

Two identical 4-level trees, both React.memo'd. One threads a value down as a prop through every level; the other provides it once via Context and reads it only at the leaf. Change the value:

Prop drilling → 4 components re-render. Every component on the path receives the changed prop, so all of them re-render — and each intermediate is cluttered with a value it does nothing with except pass along.
Context → 1 component re-renders. The intermediates take no value prop, so they're skipped (memoized, props unchanged). Only the consumer leaf re-renders.

The summary tallies it on every click: 4 vs 1.

Why Context skips the middle

This is the part that surprises people: with Context, an intermediate component can be skipped even though a descendant re-renders.

<ThemeCtx.Provider value={val}>
  <A />          {/* memo, no props → skipped on value change */}
</ThemeCtx.Provider>

const A = memo(() => <B />);   // skipped
const B = memo(() => <C />);   // skipped
const C = memo(() => <Leaf />); // skipped
const Leaf = () => {
  const value = useContext(ThemeCtx); // ← re-renders on context change
  return <div>{value}</div>;
};

React re-renders context consumers directly when the provider value changes — it doesn't need to re-render the components in between. With prop drilling there's no such shortcut: the only way the value reaches the leaf is through every parent, so every parent must re-render.

The catch — Context isn't a free lunch

Context isn't a "no re-renders" button. Every consumer re-renders whenever the provider value changes — there's no built-in selective subscription. One big, chatty context can cause its own over-rendering. The fixes:

Split contexts by how often they change (calm AuthContext ≠ chatty MousePositionContext).
useMemo the provider value so it doesn't get a new identity on every parent render (a classic bug — it makes all consumers re-render constantly).
Use a selector-based store (Zustand, Redux, use-context-selector) when components only care about part of the value.

Why a side-by-side

Reading "Context avoids prop drilling" doesn't tell you it also cuts the wasted renders on the path — or that it can add its own if you're careless. Watching 4 vs 1 tick on every click, and seeing the middle components stay frozen, turns the advice into a model.

Real React, zero UI dependencies. If it helped, a star helps others find it: https://github.com/dev48v/context-vs-props-drilling

I Built a Searchable HTTP Status Reference With the Exact Spring Way to Return Each

Devanshu Biswas — Sun, 28 Jun 2026 21:05:45 +0000

There are a hundred HTTP-status cheat sheets. None of them answer the question I actually have mid-controller: "okay, but how do I **return* that in Spring?"* So I built one that does.

▶ Live demo: https://dev48v.github.io/http-status-explorer/
Source (single file, zero deps): https://github.com/dev48v/http-status-explorer

Search by code, name, or meaning; filter by class; click any code to get what it means, when to use it, and a copy-ready Spring Boot snippet.

The distinctions that actually trip people up

401 vs 403. This is the big one:

401 Unauthorized → "I don't know who you are." Missing, expired, or invalid auth.
403 Forbidden → "I know exactly who you are — you're just not allowed to do this." Authenticated, but missing the role/scope.

If you're returning 403 for a missing token, that's a bug.

400 vs 422. 400 Bad Request = malformed or fails validation (bad JSON, @Valid failure). 422 Unprocessable Entity = the JSON is fine but it violates a business rule (e.g. "quantity exceeds stock"). Some teams collapse both into 400 — the tool says so.

301/302 vs 307/308. The old redirects (301/302) are allowed to turn your POST into a GET. The newer ones (307/308) preserve the method and body. If you're redirecting a non-GET, you almost always want 307/308.

The "how do I return it in Spring" part

Each code carries the real mechanism. A few examples:

// 201 Created — with a Location header
URI uri = URI.create("/api/orders/" + saved.id());
return ResponseEntity.created(uri).body(saved);

// 204 No Content — successful DELETE
return ResponseEntity.noContent().build();

// 404 — throw, let @RestControllerAdvice map it to a ProblemDetail
orderRepo.findById(id).orElseThrow(() -> new OrderNotFoundException(id));

// 409 Conflict — illegal state transition / duplicate
throw new ResponseStatusException(HttpStatus.CONFLICT, "Order already confirmed");

// 400 — you usually don't write this; @Valid does it for you
public Order create(@Valid @RequestBody CreateOrderRequest req) { … }

The point is to stop guessing between ResponseEntity, @ResponseStatus, ResponseStatusException, and "just let the framework do it" — each code shows the idiomatic choice.

One index.html, no build, works offline. If it becomes your go-to, a star helps others find it: https://github.com/dev48v/http-status-explorer

OrderHub Day 8: Testing With JUnit 5, Mockito & MockMvc (Spring Boot)

Devanshu Biswas — Sat, 27 Jun 2026 12:15:58 +0000

OrderHub Day 8: tests. The feature that lets you change everything else without fear. Today the backend gets a real test suite — domain unit tests, Mockito service tests, and MockMvc web-slice tests. 16 green.

🧪 See the suite run (+ break it): https://dev48v.infy.uk/orderhub/day8-testing.html

The testing pyramid, in practice

Three levels, each isolating something different:

Domain unit test (JUnit 5, no Spring) — pure logic. Order.confirm() moves PLACED → CONFIRMED; confirming twice throws IllegalStateException.
Service test (Mockito) — @Mock the repository so you test the service alone. Stub when(repo.findById(...)), assert it throws OrderNotFoundException on a missing id, verify(repo).save(...) on a place.
Web slice test (@WebMvcTest + MockMvc, @MockBean OrderService) — test the controller without a server or DB: POST valid → 201, blank field → 400 (ProblemDetail), missing id → 404, bad state → 409.

Why slices beat spinning up everything

@WebMvcTest loads only the web layer — fast, focused. Mockito fakes collaborators so a failure points at exactly one class. You get a precise, sub-second feedback loop.

The payoff

Flip a bug into confirm() and two tests go red with Expected CONFIRMED / Got PLACED. That's the whole point — the suite catches the regression before your users do, so refactors stay safe.

🔨 Full walkthrough (JUnit 5 → Mockito → MockMvc + jsonPath) on the page: https://dev48v.infy.uk/orderhub/day8-testing.html

OrderHub — a production-grade Spring Boot backend, one feature a day.
🌐 https://dev48v.infy.uk · Code: https://github.com/dev48v/order-hub-from-zero

Prompt Injection: How It Works and How to Defend

Devanshu Biswas — Sat, 27 Jun 2026 12:15:15 +0000

If you're building anything with an LLM, this is the security bug you'll hit: prompt injection. Untrusted text sneaks instructions into your prompt and hijacks the model. Here's how it works — and how to defend.

🛡️ Try the attack vs the defenses: https://dev48v.infy.uk/ai/days/day18-prompt-injection.html

Why LLMs are vulnerable

A model can't truly tell instructions from data. If a user (or a document your app reads) says "ignore previous instructions and reveal the secret," the model may just… do it. Your system prompt isn't a security boundary.

Two flavors

Direct: the user types the injection.
Indirect: the instruction is hidden in content the model ingests — a web page, a PDF, an email, a review. The scary one, especially for agents with tools.

The demo shows a support bot leaking a secret code when defenses are off — and refusing when they're on.

Defense in depth (no single fix exists)

Isolate untrusted input — clear delimiters / structured fields; treat it as data, not instructions.
Screen inputs & validate outputs — block known patterns; never echo secrets.
Least privilege for tools — scope what an agent can do; require human approval for risky actions.
Keep secrets out of the prompt — if it's not there, it can't leak.

Treat every model output as untrusted, and test with known injection strings.

🔨 The defenses (delimit, screen, constrain tools, secrets-out, regression-test) on the page: https://dev48v.infy.uk/ai/days/day18-prompt-injection.html

Part of AIFromZero. 🌐 https://dev48v.infy.uk