Books

One Server, Three Languages

Learn C, Go and Rust from scratch by building the same Redis-compatible server three times, and understand the power and the weakness of each

• C17 · Go 1.27 · Rust 1.99
• One server, built three times
• 43 exercises with solutions
• 101-row scorecard
• Every listing compiled and tested

You learn by building, you used C at university and Go a few years ago and forgot both, and you have heard that Rust is the systems language now. This book teaches all three from scratch by building one project three times: kv, a key-value server that speaks the Redis protocol, so that the real redis-cli and redis-benchmark can talk to it from chapter 4 on. It starts in 1969 with why C exists, then why Google made Go and why Mozilla made Rust, and builds the server one feature at a time, always in C first, then Go, then Rust: an echo server, the protocol parser, GET and SET, your own hash table, modules and packages, abstraction and generics, fifty clients at once on poll, kqueue and epoll, keys that expire, a clean shutdown on a signal, a log that survives a crash with its own fsync thread. Then it does what a working programmer must: tests, fuzzers and sanitizers, benchmarks and profilers, cross-compiling and static binaries, and calling C from the other two with the structs and unions that cross the border. Every chapter opens on a real scene at the terminal, teaches each language with an exercise whose full solution is folded underneath, recounts an incident you can reproduce, and closes with a scorecard that names a real weakness of each. The last chapter gathers the 101 rows into one table and says when to choose C, Go, Rust, or none of them. Every listing is pulled from code that is compiled and run against the same protocol tests on every change, with ThreadSanitizer on Linux. Read it in about eight and a half hours, and keep the appendices: a rosetta cheat card, a glossary, and C, Go and Rust each in one chapter, every construct of the language in a sentence or two with a link to its reference. Press ⌘K to search, and 1, 2 or 3 to put your language first.

Read online

Computer Networks: The Sorting Office

A short story about one Friday outage and eighty years of networks: what every piece is, why it exists, what it replaced, and where it breaks

• ARPANET to Kubernetes
• AWS and Azure names
• 125 named traps
• 69 diagrams
• No code, no labs

You type 10.0.0.0/16 into a form and hope, paste a DNS record someone gave you, open port 443 because the tutorial said so, and nod when someone says it's a BGP thing. This book is one story in thirty-one short chapters, told in two timelines. In the present, Nadia, a junior DevOps engineer on call for her first weekend, chases a checkout outage at Kettle, a small coffee-subscription business, from Friday at 16:02 to Monday's review, one layer at a time: the server that is forty-one pods, the packet that was dropped and not refused, the name that gives two answers, the route that is fine, the guard with a list, the address block nobody mentioned. In the past, Ruth, a network engineer two weeks from retirement, answers each why is it like this with how it came to be, as a scene with names and dates: time-sharing in 1961, the first message across ARPANET in 1969, the flag day of 1983, DNS, the worm of 1988, the web, NAT, the VPC in 2009, Kubernetes in 2014. Every chapter explains its concept in plain words with diagrams in one fixed palette, places it in one running metaphor (the postal system: envelopes, addresses, sorting offices, gated estates), gives you a one-line hook, and ends with where it breaks: the misconceptions and the attacks that live at that layer, from ARP spoofing and DNS poisoning to BGP hijacks, DDoS, open security groups and lateral movement, each with its tell-tale sign and what stops it. The cloud chapters are vendor-neutral with the AWS and Azure names at each concept's first use. The mystery is fair: every clue is given before the reveal. Read it in about three and three-quarter hours, and keep the epilogue: the incident review, one request followed from a phone to a pod and back, the metaphor table, three timelines, a checklist of 125 traps by hop, and a glossary of what is what.

Read online

Maintainable Playwright Tests

Data-driven, DRY, multi-locale end-to-end tests with TypeScript

• Playwright 1.63 · TypeScript 7
• en-GB · en-US · de-DE · ja-JP
• 43 named traps
• 15 diagrams
• Every snippet type-checked

You can write decent code, you have probably written Selenium tests, and now you have to test a long, branching web app in several languages with Playwright. This book is one story in fourteen short chapters. Tomas, a Selenium veteran, rebuilds the suite for Kestrel Insure, a car-insurance quote journey of about forty screens sold in the UK, the US, Germany and Japan. Every chapter opens with something breaking and fixes it the Playwright way: auto-waiting instead of sleeps, locators by role, small page objects, fixtures instead of a BaseTest, scenarios that hold both inputs and expected outputs, a screen registry and driver loop that answers whatever screen the app shows and asserts the path it took, starting mid-flow, market profiles that keep locale differences out of the specs, sessions saved once, third parties mocked at the boundary, and sharded runs that treat flaky tests as bug reports. Each chapter names its traps, with the tell-tale sign, what to do instead and the lint rule that catches them, and ends with a spot-the-flaw exercise and three questions for code review. The last chapter compares Playwright with Cypress and Selenium fairly, including where each of them wins. Every TypeScript snippet is compiled against Playwright 1.63 before publication. Read it in about two hours, and keep the epilogue: a Concept Atlas of every feature with links to the docs, the catalogue of all 43 traps, a baseline config and ESLint setup, and a glossary for Selenium users. Press / to search.

Read online

Cybersecurity: The Keep

A short story about defending one company, from the wax seal to the machine learning model: how each control actually works, the traps it falls into, and what every vendor calls it

• Ciphers to zero trust and AI
• Microsoft · AWS · Google · IBM
• 204 named traps
• 37 diagrams
• Laptop-only demos

You have heard encryption, hashing, RBAC, mTLS, zero trust and EDR in meetings and nodded. This book is one story in thirty-six short chapters. Thistle is a small savings app that starts with a spreadsheet emailed to four hundred customers and ends with an architecture that would survive most of what it met on the way: a settlement file with one row changed, a forged invoice, a domain nobody had looked at since it was installed, a role that could start eleven instances, a laptop taken from a café table, a dependency three levels down that phones abroad, an AI assistant asked to read customer tickets, and an alert at 02:41 on a Sunday. Every chapter opens with something breaking; the fix is the chapter's idea, and it arrives with a place in one running metaphor (a medieval keep that modernises without ever being demolished), a diagram of what is actually sent and checked, a one-line hook, and a dated account of who invented it and what they were reacting to — Kerckhoffs in 1883, Diffie and Hellman in 1976, the confused deputy in 1988, zero trust in 2010, prompt injection in 2022. Then it does what a mentor would do: names the traps and their tell-tale signs, hands you commands you can run on your own laptop with no cloud account, tells you what Microsoft, AWS, Google, IBM and the independents each call the thing, and gives you three questions to ask whoever proposes it next, plus the point on which the field still genuinely disagrees. The metaphor is retired on purpose in chapter 23, because a keep has an inside and an outside and no real system does any more. Read it in about five hours, and keep the epilogue: the full vendor map, an A–Z glossary, every command grouped by task, and a review checklist of all 204 traps. Press / to search any term.

Read online

DDD and Microservices: The Atlas

A short story about drawing the right borders: domain-driven design, the architecture styles and microservices, with their history, their traps and the arguments on both sides

• DDD · hexagonal · CQRS · sagas
• Java 21 snippets
• 114 named traps
• 30 diagrams
• Second edition

You have heard bounded context, aggregate, hexagonal, saga and outbox in meetings and nodded. This book is one story in twenty-one short chapters. Bramble is an online shop that starts as a monolith that works, splits itself badly into a distributed monolith, is rescued by strategic and tactical DDD, learns to integrate across borders with events, the outbox and sagas, reshapes its teams around its contexts, strangles its legacy, and ends with the judgement to build its next product as a modular monolith. Every chapter opens with something breaking; the fix is the chapter's idea, and it arrives with a place in one running metaphor (an atlas of countries, languages and treaties), a diagram of the mechanism, a one-line hook, and a dated account of who thought of it and what they were reacting to. Then the book does what a mentor would do at a whiteboard: names the traps and their tell-tale signs, gives you a small design with one planted flaw to find, and hands you three questions to ask whoever proposes the pattern next, plus the point on which experts still disagree, argued fairly from both sides. Layered, hexagonal, onion, clean, vertical slices and Spring Modulith get one chapter as one idea. Read it in about two and three-quarter hours, and keep the epilogue's review checklist of 114 traps and its 21-question card. The second edition (October 2026) names the mechanisms the first left out: optimistic concurrency and set-based invariants, overload protection, dead-letter queues, saga timeouts, deploy versus release, and service level objectives.

Read online

System Design: The Depot

A short story about load, data and staying up: scaling, replication, transactions, partitioning, caching, queues, consistency, consensus and overload, with their history, their traps and the arguments on both sides

• Scale · data · reliability
• Java 21 and SQL snippets
• 91 named traps
• 31 diagrams
• One set of numbers throughout

You have heard replica, shard, quorum, CAP and p99 in meetings and nodded. This book is one story in twenty short chapters, and it picks up where DDD and Microservices: The Atlas ends. Bramble, an online stationery shop with tidy boundaries and a system that has never been busy, meets real load: a television feature, a back-to-school sale, a launch on a second continent, and a limited-edition drop with half a million people arriving at 09:00. Every chapter opens with something breaking; the fix is the chapter's idea, and by the end the fix has opened a new crack. Measure before you scale, estimate on one sheet of paper, scale out, index, replicate, make stock safe with one conditional update, partition only when a number says so, cache, push work to the edge, level load with queues and a log, decide which copy is right, elect one leader and fence the old one, distrust clocks, put a doorman on the gate, lose a region on purpose, promise with numbers, and read the bill. Each idea has a place in one running metaphor (a network of depots holding stock and serving lorries), a diagram of the mechanism, a one-line hook, and a dated account of who thought of it and what they were reacting to, from Erlang in 1909 to Raft in 2014. Then the book does what a mentor would do at a whiteboard: names the traps and their tell-tale signs, gives you a small design with one planted flaw to find, and hands you three questions to ask whoever proposes the mechanism next, plus the point on which practitioners still disagree, argued fairly from both sides. Bramble has one set of figures and every calculation uses them, so when the consultant proposes what the largest companies run, the answer is a number, and so is the load at which he becomes right. The last chapter designs the drop end to end with an eight-step method and reviews the alternative with questions from the earlier chapters. Read it in about two and three-quarter hours, and keep the epilogue: the review checklist of 91 traps, a numbers card and the design method on one card.

Read online

Software Architecture: The Town Plan

A short story about choosing an architecture and keeping it true: quality attributes, trade-offs, eight system-level styles, decision records, diagrams and fitness functions, with their history, their traps and the arguments on both sides

• Nine styles compared
• Decision records · C4 · fitness functions
• 69 named traps
• 37 diagrams
• Java 21 snippets

You have been asked 'monolith or microservices?' as if those were the only two answers, and you have sat through the same design argument three times because nobody could find why the decision was made. This book is one story in eighteen short chapters, the third about Bramble after DDD and Microservices: The Atlas and System Design: The Depot, and it can be read alone. Bramble buys Quill, a wholesaler whose software is fifteen years old, works, and has almost none of its decisions written down. The failures here begin as decisions: one nobody can explain, one that cannot be made because nobody knows what matters, one made by fashion, one argued three times, one silently reversed by a pull request that every reviewer approved. Each chapter's fix is its idea: quality attributes and the three that drive a system, trade-off analysis, coupling and the architecture quantum; then the styles (layered, pipeline, microkernel, service-based, event-driven, space-based, serverless), each answering the same five questions and drawn with the same five capabilities, so that any two can be laid side by side; then granularity, choosing a style for each system from one comparison table, decision records, C4 diagrams, fitness functions and the architect's role. Every idea has a place in one running metaphor (a town and its buildings), a diagram, a one-line hook and a dated account of who thought of it and what they were reacting to. Every chapter names its traps, plants one flaw for you to find and hands you three questions for the meeting, plus the point on which experienced people still disagree, argued from both sides. The consultant who wants one standard and the architect who wants to keep what works are each right about something by the end. Read it in about two and a half hours, and keep the epilogue: the review checklist of 69 traps, the style comparison table, and blank templates for a scenario and a decision record.

Read online

From Docker to Kubernetes

A short story from one container to a self-running cluster, with the commands that matter

• Docker 27 · kind 0.33
• Kubernetes 1.37
• Helm · Istio · Prometheus · Argo CD
• 36 diagrams · 60 gotchas
• ⌘K search

You have run docker run and heard of Pods, and you would like a clear picture instead of a vague one. This book is one story in twenty short chapters and two interludes. Maya ships a small app called Pantry, and every chapter opens with something breaking or someone asking for what the current setup cannot do; the fix is the chapter's concept, and by the end a new crack has appeared. Six chapters of Docker, nine of Kubernetes, four on the tools real clusters run alongside it (Helm, Istio, Prometheus and Grafana, Argo CD), and an epilogue with the whole map. Every concept gets a place in one running metaphor, a diagram of how it actually works, and a one-line hook to remember it by. Every chapter ends with the twenty percent of commands that do eighty percent of the work, a hands-on section against the companion app, the traps that bite silently (every one reproduced), and five recall questions with answers in the epilogue. An interlude called Old Maps tells the history of containers, orchestrators and moving YAML through an inherited repository, so that docker-compose, Tiller, master nodes and extensions/v1beta1 all make sense when you meet them, and the epilogue's old-words glossary lets you look any of them up. Read it in about an hour and three quarters.

Read online

AWS for Azure Architects and Developers

Design enterprise AWS systems end to end, whatever you know of Azure

• AWS as of September 2026
• Terraform 1.16 · Java 25
• 125 figures with official icons

You design and build on Azure, or know only part of it, and your next system runs on AWS. This book teaches AWS on its own terms and uses Azure only as a bridge, so no page depends on knowing Azure well. Follow MegaCorp's payments team from its first account to a platform across two Regions: accounts, identity and networks; compute, data, messaging and the edge; then security, resilience, cost, delivery and operations. Each service is told as a story: how it works, when to use it and when not, its limits, cost, security and traps, and the history that lets you date what you inherit. Words that mean something else on AWS are flagged where they appear. Three end-to-end designs and a set of review drills pull it together, and 125 figures use the official AWS and Azure icons. Read the teaching chapters in under three hours; the appendices add a service map, an IAM policy cookbook, an error index and a cheat card, and ⌘K looks up any Azure term or AWS error message.

Read online

GOV.UK Stack, Fast

Nunjucks, Express and Fastify, GOV.UK Frontend and CASA for React and .NET developers

• GOV.UK Frontend 6.5
• Express 5 · Fastify 5
• CASA 10, optional

You build React front ends on ASP.NET Core APIs, and your next project is a UK government service on a different stack. This book maps what you know onto it, layer by layer: the request loop, the plumbing, Nunjucks templates, GOV.UK Frontend's components, journeys, validation and the standards you will be assessed on. No Node experience is needed. Express, Fastify, Nunjucks and CASA are each taught from zero, then in depth, so that you can read the code you inherit and write new code without looking anything up. Each depth chapter ends with real code annotated line by line and a new feature built step by step, and the Express 4, Fastify 4 and CASA 9 code in older services is covered too. Two optional parts go further: CASA, and accessibility and security, with an automated accessibility check on every page and a tested sign-in, ownership check and rate limit. Every server example shows Express and Fastify side by side, in TypeScript or JavaScript, quoted from one tested example app. Read it in about 1 hour 10 minutes, or about 1 hour 45 minutes with both optional parts.

Read online

GitLab CI/CD, Decoded

Write, read and fix your team's pipeline, from commit to cluster

• GitLab 19.3
• Handbook in an hour
• Node, Java and OpenTofu labs
• Flux and Argo CD
• AWS and Azure

Your team's pipeline file is twenty lines long; the pipeline it produces is not, and keeping it working is now your job. Start with the Handbook: every keyword of a GitLab pipeline file on one small project, explained in comments on the lines and run on a real GitLab; a what-is-what table with every word in one line; and a card that goes from any symptom to the right fix. About an hour, and you can read, write and debug any pipeline. Then the textbook, when you have the time, told as a story: every chapter opens with something going wrong in a real pipeline and ends with what you can now do about it. Write your team's pipeline step by step, in Node or Java, with labs on your own GitLab; learn to read everything the central team's templates and policies add, with 94 symptom cards; and, in its own part, follow your change to the cluster with Kubernetes, Helm, Kustomize, Flux and Argo CD on AWS and Azure. Times are measured for a technical reader, and press ⌘K to look up any keyword, variable or error message.

Read online

Java for C# Developers

A working handbook for .NET engineers moving to Java and Spring Boot

• Java 25 LTS
• .NET 10 · C# 14
• Spring Boot 3 & 4

Where your C# instincts carry over to Java, and where they are confidently wrong. Every chapter gives its answer first: a table of the differences between C# and Java, with each trap shown as code whose result you predict before you look. The book is written in plain sentences, so it is easy to read if English is not your first language. Read the essentials in about 3 hours 45 minutes, or everything in about 10 hours. To refresh later, there are tours of Java, Spring Boot and modern C# as annotated code, and a review deck that brings back the questions you missed. Press ⌘K to look up any C# name and land on its Java answer.

Read online