programming, life, and everything
In this chapter, we'll quickly go through all the easy series TypeChallenges.
I'll share my thought process, code, and some additional notes.
Let's start with a warm-up problem labeled as warm difficulty.
Due to the large number of medium series questions, in order to facilitate everyone to check, I provide a navigation here for everyone to check.
Minecraft Java Edition has a surprisingly capable scripting layer. Scoreboards act as integer registers. NBT storage is arbitrary heap memory. The execute command chains are conditional branches. People have built working CPUs, ray tracers, and sorting algorithms inside the game. But writing this code directly is miserable — raw .mcfunction files with no variables, no loops, no abstraction.
Minecraft datapacks are programmable, but not pleasant to program. Scoreboards act like registers, execute chains act like control flow, and function calls simulate jumps between basic blocks. It is powerful enough to build mini-games and server logic, but raw .mcfunction authoring is still closer to wiring a finite-state machine than writing software.
This project is still under development!
Type Challenges is a project that aims to provide a collection of type challenges with the goal of helping people learn TypeScript.
The Leverage OJ rewrite ended with a working platform: backend, frontend, judge engine, ELO system, real-time human-vs-bot matches. The natural next question was whether an AI agent could use it autonomously — not just run code against an API, but design an entire game from scratch.
The answer turned out to be yes, with one key ingredient: a machine-readable protocol document and an MCP server.
It was 2 AM. The Leverage OJ frontend had been happily serving pages for hours, then something caused it to crash. A quick restart later, every route returned the default Nuxt welcome screen:
Remove this welcome page by replacing
<NuxtWelcome />in app.vue with your own code...
I've been documenting the evolution of sandbox_exec into something more general. This post covers Sandlock v1.4.0 — the point where it became a proper multi-layer security system rather than a clever wrapper.
Update 2026-03-09: sandbox_exec has since evolved into Sandlock — a modular, full-stack sandbox with strict mode, language-level sandboxes (Python/JS), a source scanner, and LD_PRELOAD hooks. See Sandlock v1.4: From Single File to Full-Stack Sandbox and the GitHub repo.
The previous two posts covered the threat model and the seccomp sandbox. This one is about going further: a WebAssembly execution environment where the security properties come from the compilation target, not from OS-level filters.