Latest
The complete chronological feed across writing, projects, talks, and judging. Most recent first.
143 entries
Turn any OpenAPI spec into an MCP server
Turns an OpenAPI 3.x specification into a working Model Context Protocol server, exposing the generated tools over Streamable HTTP for any MCP client with no glue code.
Computers find each other by number, not by name. DNS is the phone book that turns guptasachinn.com into an address a machine can dial, and it is quietly one of the most important systems on the internet.
A deep look at DNS, the building block introduced in the request-path overview. How a name becomes an IP address, the lookup chain from your resolver up to the authoritative server, why answers are cached (TTL), and how DNS does more than lookups: sending you to the nearest server and routing around a dead one. Everyday analogies, a hand-drawn diagram, and a visualizer per idea.
What the Model Context Protocol is, the pieces it is made of, and the map of the rest.
The Model Context Protocol is how an AI application reaches the tools and data it needs. By mid-2026 it is a Linux Foundation standard with an official registry and support across the major platforms. This opening piece lays out the problem, the client-host-server architecture, the six primitives, and the map, anchoring a five-part series.
Exact match fails two ways users hit every day, typos and half-typed queries. Here is the machinery that forgives both.
Part three of the search series. The inverted index only matches literal keys, so a typo or a half-finished word returns nothing. Fuzzy search fixes typos with edit distance (Levenshtein), computed by a small dynamic-programming grid and run at scale with automata or n-grams. Prefix search fixes as-you-type with tries and FSTs. Worked examples throughout, plus an interactive edit-distance grid.
One web address, but many identical servers behind it. The load balancer is the host that decides who goes where, notices when a server dies, and can even read a request to route it. Here is everything it does.
A dedicated look at load balancers, the building block introduced in the request-path overview. How it chooses a server (round-robin, least-connections, weighted, sticky), how health checks notice a dead server and route around it, the difference between layer 4 and layer 7 balancing (route by the envelope or open the letter), and how the load balancer itself avoids being a single point of failure. Everyday analogies, a hand-drawn diagram, and a visualizer per idea.
What a framework makes easy, and what it hides.
An Agent SDK is a packaged harness: the run loop, tool interface, memory, model abstraction, and tracing, ready to wire together. The value is what it makes easy. The risk is what it hides.
Type a web address, hit enter, and a page appears. Behind that is a small journey: your request must find one server out of millions, then get past the front door. Three things make it happen: DNS, a load balancer, and a gateway.
Day three of the System Design series, and the first building blocks. When someone uses your system, the very first thing that happens is their request finding a server. This walks the journey: DNS turns a name into an address, a load balancer spreads requests across servers, and a gateway is the shared front door for auth, rate limiting, and routing. Each explained with an everyday analogy first, a hand-drawn diagram, and its own interactive visualizer.
How a search engine turns a match into a score. The workhorse ranking function, and the two knobs that tune it.
Part two of the search series. Matching finds candidates; ranking decides the order. BM25 is the default text scorer, and it is really three forces: term frequency with saturation, document-length normalization, and term rarity (IDF). This walks the intuition with worked examples, the exact formula, and the k1/b knobs, then hands you an interactive score explorer.
Before a word can be indexed, it has to be prepared. The quiet pipeline that decides what your search can ever match.
Part of the search series. The inverted index does not store raw text; it stores terms, and text analysis is the pipeline that turns one into the other: tokenize, lowercase, drop stopwords, stem to a root, expand synonyms. The same analyzer must run on the query, and getting it wrong silently breaks search. With an interactive analysis pipeline.
How big is this thing? You do not count, you estimate, the same way you guess jelly beans in a jar. Three quick multiplications tell you whether you need one server or a thousand.
Day two of the System Design series, and step two of the routine on its own: estimation. Learn to size a system with three numbers, throughput (requests per second), storage, and bandwidth, using rounded napkin math. Worked all the way through on the link shortener from day one. With a jelly-bean analogy, a hand-drawn diagram, and an interactive visualizer that rolls the numbers up as you go.
