The Anatomy of a Project
Each chapter walks through one project in five moves, in the same order every time:
Problem states what the program has to do, in plain terms, before any Nex appears — the way you would describe it to a colleague at a whiteboard.
Design as Contract turns that description into a public interface: the classes, the method signatures, the require and ensure clauses, the invariants. This is the step the other three Nex books spend most of their pages on individually; here it happens once per project, deliberately compressed, because the point of this book is what comes after it.
Build is the implementation — not a full listing of every line (the complete, current source for every project lives in the book's companion example directory, linked from each chapter), but the parts worth walking through: where the design met a real constraint, where a match had to be exhaustive, where a boundary needed a real check instead of a hope.
Test shows the project's own hand-rolled check suite — a small Checker class with a check(label, expected, actual) method and a summary(), run through a plain checks.nex script. It is a deliberately low-tech pattern, chosen because it needs nothing beyond the language itself, and every project in this book uses the identical one.
Takeaways closes each chapter — not a recap of what was built, but the general lesson worth carrying into your own code, the thing this project's particular design happened to prove.
The File Layout Convention
Every project separates its library from its entry point: one file (or a small handful) holds the pure, host-free logic — the part with no file I/O, no console output, no network call — and a separate, thin entry-point file wires that logic to the outside world. A project's checks.nex exercises the library directly, never the entry point, which is what lets every check suite in this book run in well under a second with nothing to set up. Appendix C gives the convention in full, file by file, with the reasoning behind each piece.
Building and Running
Every project in this book runs the ordinary way — nex <file>.nex, compiling to the JVM by default — and every check suite passes on that default backend. One thing is worth knowing before Chapter 1:
A bare relative path (nex nexwc.nex sample.txt) resolves against the nex launcher's own installation directory, not wherever you actually ran it from. This is documented behavior, not a bug, and four projects in this book route around it the same way — read in full where it first comes up, in Chapter 1.
Appendix B covers packaging a project as a standalone jar, for anyone who wants to hand one to someone without a Nex install.