The important constraint is that every note is composed and synthesized live in the browser. There are no prerecorded loops, no server, no account, and no backend generation job.

Why it is not mainly an AI app

The interesting origin story is that driftloop came after an earlier model-first attempt. That earlier direction tried to distill a multi-instrument music model and sample from it for the listening experience. The output was structurally chaotic in a way that sampling tweaks did not fix.

driftloop starts from a different premise: for continuous background music, structure matters more than model capacity.

Algorithmic composition handles the load-bearing parts:

• chord progression
• voice leading
• bass motion
• rhythm
• drum pattern
• section shape

A small model can still help with lead melody, but it should not be responsible for making the whole piece coherent.

Runtime shape

The app has two layers:

1. Vanilla JavaScript composition logic that keeps the music in key, on grid, and structurally coherent.
2. An optional MelodyRNN path through TensorFlow.js for lead melody.

Synthesis uses js-synthesizer, a WebAssembly port of FluidSynth, with a General MIDI SoundFont through the WebAudio API.

The SoundFont is large, so deployment has a practical constraint: Cloudflare Pages has a single-file size limit smaller than the SoundFont. The app fetches the SoundFont from a public upstream mirror on first launch, then the service worker caches it for offline reuse.

What I learned

Generative music is not only generation. It is arrangement, continuity, transitions, repetition management, and sound rendering.

The most important product question is not “is it AI?” It is “can I leave this playing without getting annoyed?” That favors simple, controllable structure over model novelty.

Current status

driftloop is private but product-shaped. It is a static PWA candidate, and the current architecture is intentionally deployable without backend secrets or runtime infrastructure.

The whole point is that it should keep working with no network.

Why build it

Airplane mode is a useful product constraint. It removes a lot of lazy assumptions:

• no backend calls
• no CDN dependency during play
• no login
• no remote save
• no ads
• no analytics requirement

What remains is the app itself: local assets, local state, and games that are worth playing in short sessions.

Template shape

AeroPlay is also designed as a template. The repo can be used to bootstrap another offline game hub without carrying old issues or unrelated history.

That makes the project more useful than a single app. It becomes a base pattern:

• Vite and TypeScript
• local game modules
• service worker
• manifest
• localStorage progress
• mobile-first layout

Product boundary

The project should not become a general gaming platform. Its strength is the opposite: a small set of local games, predictable input, and no network requirement.

For this kind of app, “more features” can easily make the experience worse. If the user opens it in flight mode, the app should not show half-broken online features.

What I learned

Offline-first is easiest when it is a requirement from the beginning. Retrofitting offline behavior onto an app that assumed servers and remote assets is much harder.

AeroPlay also shows that simple games still need polish:

• touch controls
• stable layout
• saved state
• fast startup
• no accidental scroll
• clear pause and restart behavior

Those details matter more on a phone than in a desktop demo.

Open source status

AeroPlay is public because it is self-contained, harmless to share, and useful as a template. It is a good example of a small project whose constraints make it more reusable.

The project is not meant to be a large mod. It is a rules sandbox.

What it changes

The pack includes features such as:

• sprint regeneration
• random player effects
• torch drops on non-player entity death
• local snow effect on player death
• random material drops from broken blocks
• adjusted fishing loot weights

These are intentionally playful mechanics. The point is to test how small rule changes affect the feel of a world.

Why behavior-only matters

Keeping the pack behavior-only lowers the setup cost. There is no custom client asset pipeline and no experimental toggle requirement.

That makes it easier to share across devices:

• package as .mcpack
• import on iOS or Windows
• activate in world settings
• play immediately

For a small personal pack, install friction matters more than architectural elegance.

The design lesson

Game modding is a good reminder that systems can be fun without being complicated. A simple rule like “breaking blocks produces random materials” changes the entire resource economy.

The engineering lesson is to make each rule easy to remove. If a mechanic stops being fun, it should not be tangled with the rest of the pack.

What I learned

Small game experiments should be packaged early. A mechanic that only works in a local development folder is not really tested. It needs to be imported, activated, and played in the actual environment.

Bedrock Lab’s value is that it turns ideas into a package quickly. That makes it easier to decide whether a mechanic is worth keeping.

Current status

Bedrock Lab is private and small. It is the kind of project that is more useful as a personal sandbox than as a maintained public mod.

This is the kind of project where the most useful public topic is not the trading strategy. It is the guardrail design.

Why risk first

Trading code has a dangerous failure mode: a bug can become a position.

That changes the engineering priority. Before clever strategy logic, the system needs operational controls:

• dry-run mode
• explicit venue adapters
• heartbeat checks
• halted state
• read-only mode
• data freshness checks
• position and exposure constraints
• clear separation between research and live execution

The project name reflects that priority. The guard matters before the CTA.

System shape

The maintained path is a modular trader stack:

• runtime orchestration
• risk app service
• strategy app service
• backtest app service
• domain models and ports
• SQLite repositories
• venue adapters and stubs

There are separate binaries for live or dry-run runtime, health checks, ingestion, historical import, backtest, and walk-forward validation.

That separation is important. A backtest binary should not have the same operational authority as a live execution process.

What should stay private

Some details are not appropriate for a public blog:

• strategy parameters
• production configuration
• account or venue details
• exact deployment topology
• operational thresholds
• anything that could imply a trade recommendation

The safe public layer is architecture: how to keep execution constrained, observable, and stoppable.

What I learned

Risk control is not one module. It is a state machine that should shape the whole runtime.

A good trading system needs to answer boring questions quickly:

• is data fresh?
• is the venue reachable?
• is the runtime allowed to trade?
• what happens after an error?
• can the system stop without making things worse?
• can research code accidentally reach execution?

If those answers are unclear, the system is not ready for live use.

Current status

cta-guard is private. I may continue writing about its engineering lessons, but only at the level of risk design, runtime isolation, and validation workflow.

The product sounds tiny: count taps for 10, 30, or 60 seconds. The interesting part is making that count credible.

Why a custom tool

Most tap-speed apps are built for casual play. Competition use has different requirements:

• work offline
• run well on an iPad
• avoid accidental browser gestures
• count multi-finger input correctly
• preserve enough raw data to audit a run
• keep history locally without accounts

For this use case, simplicity matters more than visual novelty.

Input model

TapSurge uses pointerdown and active pointer tracking. The key rule is that holding a finger down should not count repeatedly. A tap is a new press, not a frame, animation event, or repeated touch state.

The app records:

• total taps
• average CPS
• one-second live CPS
• maximum live CPS
• maximum simultaneous fingers
• raw timestamps and pointer IDs

That raw data is important. It lets a run be inspected after the fact instead of trusting only the final number.

Offline design

The app is intended to work in a PWA-like mode. It has a local app shell, a service worker, and no backend dependency during play.

This is one of those projects where offline support is not a nice extra. It is part of the user story. If the tool is used at a booth, in a classroom, or during a small event, network dependency is unnecessary risk.

UI constraints

The UI has to be obvious under pressure. A player should not be reading instructions while the timer is running.

The controls are intentionally few:

• choose duration
• start
• tap
• see result
• review history
• export evidence if needed

The harder work is preventing the browser from interfering: double-tap zoom, scroll gestures, safe-area issues, and fullscreen behavior all matter more on a real iPad than in a desktop browser.

What I learned

Small event tools benefit from being boring. The best version is not the most animated one; it is the one that produces trustworthy results with minimal setup.

TapSurge is a good example of a private tool that could be public, but does not need a large roadmap. Its scope is the feature.

The goal of this series is not to pretend every small repository should become a product. The goal is to leave a useful engineering record: why each project exists, what design choices mattered, what I learned from it, and where the boundary is between a good private tool and a project worth publishing.

I will keep this page updated as projects change.

Project map

Why write about private projects?

Open source is not the only useful form of sharing. A private project can still contain lessons worth publishing:

• how the problem was framed
• which constraints shaped the architecture
• what was deliberately left out
• where a prototype became too complex
• what I would do differently next time

For private repositories, these notes avoid secrets, private network details, exact production configuration, personal data, and sensitive business or trading parameters. The public artifact is the engineering story, not a dump of implementation details.

How I classify these projects

Some projects are small tools that should stay small. tapsurge, good-fishing-day, and bedrock-lab are in that category. Their value comes from being built for one specific situation.

Some are experiments in system shape. agentd, scale-kv, quacklake, tegdb, and tegdb-server are more about understanding boundaries than shipping a polished product.

Some are workbench infrastructure. qwen-local, tailgate, PocketBabel, canopy, and ob-skills exist because I want AI tools to fit into my own environment instead of depending entirely on remote services.

Some are creative-system prototypes. driftloop, mood-midi-mlx, and nightfall are less about CRUD-product shape and more about how rules, local models, and browser runtimes can create a coherent experience.

Some projects sit close to professional or sensitive domains. ob-sizer is safe to discuss at the methodology level. cta-guard needs more caution: the interesting public topic is risk control and operational design, not trading edge.

Maintenance rule

When a project changes meaningfully, I will update this index first. If the change is only implementation detail, the individual post can stay as a snapshot. If the project changes direction, graduates into a product, or gets retired, the index should say so plainly.

That makes this page the map, and each project post a field note.

Recommended Usage

• Compile all Go files in the current directory:

  go build
  

• Compile all Go files explicitly:

  go build *.go
  

Common Pitfalls

Compiling a Single File

Running:

go build main.go

will only build main.go. This can lead to errors if main.go depends on other Go files in the same package, as those files won’t be included in the build process.

Including Non-Go Files

Using:

go build *

will cause an error if the * wildcard includes non-Go files. The compiler will output an error message stating that only Go files can be compiled. This serves as a precise reminder to exclude non-Go files from the build command.

By using go build correctly, you can ensure that all necessary files in your package are compiled together, avoiding missing dependencies and other common compilation issues.

Initially, I didn’t think this was something worth writing about, because CTex was previously working smoothly for everyone. However, it turns out that CTex hasn’t been updated since 2016. So, I wanted to find a replacement for Chinese LaTeX on Windows in 2021.

Configuration Method

1. Install MiKTeX (TexLive should work as well). MiKTeX can automatically download dependency packages and you can also proactively install the ctex package.
2. Install the VSCode LaTeX extension.
3. Configure the LaTeX extension. I found a powerful configuration on Zhihu, but it’s quite complex, so I simplified it a bit.

A brief explanation: the core components here are the recipes and tools. Tools are the compilation toolchain, specifying which tools to use for compilation and the options to use, without regard to order. Recipes define how to combine the above tools to generate the final document, where the order does matter. I’ve put XeLaTex first here because it’s the most compatible for compiling Chinese. If you use pdflatex to compile Chinese documents, you’re likely to encounter issues.

{
   "latex-workshop.latex.recipes": [
         {
            "name": "XeLaTeX",
            "tools": [
                "xelatex"
            ]
        },
        {
            "name": "latexmk 🔃",
            "tools": [
                "latexmk"
            ]
        },
        {
            "name": "latexmk (latexmkrc)",
            "tools": [
                "latexmk_rconly"
            ]
        },
        {
            "name": "latexmk (lualatex)",
            "tools": [
                "lualatexmk"
            ]
        },
        {
            "name": "pdflatex ➞ bibtex ➞ pdflatex × 2",
            "tools": [
                "pdflatex",
                "bibtex",
                "pdflatex",
                "pdflatex"
            ]
        },
        {
            "name": "Compile Rnw files",
            "tools": [
                "rnw2tex",
                "latexmk"
            ]
        },
        {
            "name": "Compile Jnw files",
            "tools": [
                "jnw2tex",
                "latexmk"
            ]
        },
        {
            "name": "tectonic",
            "tools": [
                "tectonic"
            ]
        }
    ],
    "latex-workshop.latex.tools": [
        {
            "name": "xelatex",
            "command": "xelatex",
            "args": [
                "-synctex=1",
                "-interaction=nonstopmode",
                "-file-line-error",
                "%DOCFILE%"
            ]
        },
        {
            "name": "latexmk",
            "command": "latexmk",
            "args": [
                "-synctex=1",
                "-interaction=nonstopmode",
                "-file-line-error",
                "-pdf",
                "-outdir=%OUTDIR%",
                "%DOC%"
            ],
            "env": {}
        },
        {
            "name": "lualatexmk",
            "command": "latexmk",
            "args": [
                "-synctex=1",
                "-interaction=nonstopmode",
                "-file-line-error",
                "-lualatex",
                "-outdir=%OUTDIR%",
                "%DOC%"
            ],
            "env": {}
        },
        {
            "name": "latexmk_rconly",
            "command": "latexmk",
            "args": [
                "%DOC%"
            ],
            "env": {}
        },
        {
            "name": "pdflatex",
            "command": "pdflatex",
            "args": [
                "-synctex=1",
                "-interaction=nonstopmode",
                "-file-line-error",
                "%DOC%"
            ],
            "env": {}
        },
        {
            "name": "bibtex",
            "command": "bibtex",
            "args": [
                "%DOCFILE%"
            ],
            "env": {}
        },
        {
            "name": "rnw2tex",
            "command": "Rscript",
            "args": [
                "-e",
                "knitr::opts_knit$set(concordance = TRUE); knitr::knit('%DOCFILE_EXT%')"
            ],
            "env": {}
        },
        {
            "name": "jnw2tex",
            "command": "julia",
            "args": [
                "-e",
                "using Weave; weave(\"%DOC_EXT%\", doctype=\"tex\")"
            ],
            "env": {}
        },
        {
            "name": "jnw2texmintex",
            "command": "julia",
            "args": [
                "-e",
                "using Weave; weave(\"%DOC_EXT%\", doctype=\"texminted\")"
            ],
            "env": {}
        },
        {
            "name": "tectonic",
            "command": "tectonic",
            "args": [
                "--synctex",
                "--keep-logs",
                "%DOC%.tex"
            ],
            "env": {}
        }
    ],
    "latex-workshop.view.pdf.viewer": "tab"
}

1. Create a folder.
2. Use VSCode to open this folder and create a .tex file with the following content:

\documentclass[UTF8]{ctexart}

\begin{document}
OK, it’s all set...
\end{document}

It should automatically start compiling. Confirm to download any required dependencies if prompted. The compiled effect is as follows:

When I first started writing Golang, I was always looking for a convenient debugging tool. Back then, I came across documentation about using gdb to debug and also tried delve, but neither felt easy to use. Later, on someone’s advice, I went back to the good old print statements…

Over the past couple of days, I was debugging go test and found that tests would always hang when run per package. I couldn’t think of a suitable method at first, so I thought of delve again. After giving it a try, I found it has become much more mature than before.

Usage

dlv attach ${pid} is the method I use most often. After attaching, you can use debugging commands similar to gdb. You can use help to view specific commands.

(dlv) help
The following commands are available:
    args ------------------------ Print function arguments.
    break (alias: b) ------------ Sets a breakpoint.
    breakpoints (alias: bp) ----- Print out info for active breakpoints.
    call ------------------------ Resumes process, injecting a function call (EXPERIMENTAL!!!)
    clear ----------------------- Deletes breakpoint.
    clearall -------------------- Deletes multiple breakpoints.
    condition (alias: cond) ----- Set breakpoint condition.
    config ---------------------- Changes configuration parameters.
    continue (alias: c) --------- Run until breakpoint or program termination.
    deferred -------------------- Executes command in the context of a deferred call.
    disassemble (alias: disass) - Disassembler.
    down ------------------------ Move the current frame down.
    edit (alias: ed) ------------ Open where you are in $DELVE_EDITOR or $EDITOR
    exit (alias: quit | q) ------ Exit the debugger.
    frame ----------------------- Set the current frame, or execute command on a different frame.
    funcs ----------------------- Print list of functions.
    goroutine (alias: gr) ------- Shows or changes current goroutine.
    goroutines (alias: grs) ----- List program goroutines.
    help (alias: h) ------------- Prints the help message.
    libraries ------------------- List loaded dynamic libraries.
    list (alias: ls | l) -------- Show source code.
    locals ---------------------- Print local variables.
    next (alias: n) ------------- Step over to next source line.
    on -------------------------- Executes a command when a breakpoint is hit.
    print (alias: p) ------------ Evaluate an expression.
    regs ------------------------ Print contents of CPU registers.
    restart (alias: r) ---------- Restart process.
    set ------------------------- Changes the value of a variable.
    source ---------------------- Executes a file containing a list of delve commands.
    sources --------------------- Print list of source files.
    stack (alias: bt) ----------- Print stack trace.
    step (alias: s) ------------- Single step through program.
    step-instruction (alias: si)  Single step a single CPU instruction.
    stepout (alias: so) --------- Step out of the current function.
    thread (alias: tr) ---------- Switch to the specified thread.
    threads --------------------- Print out info for every traced thread.
    trace (alias: t) ------------ Set tracepoint.
    types ----------------------- Print list of types.
    up -------------------------- Move the current frame up.
    vars ------------------------ Print package variables.
    whatis ---------------------- Prints type of an expression.
Type help followed by a command for full documentation.

Many of these commands are the same as those in gdb. Another command I use frequently is grs, which outputs all goroutines. You can also use grs -t, which is equivalent to gdb’s t a a bt. The only slight drawback is that it only outputs 10 stack frames, and any additional ones are truncated.

Additionally, it seems that processes forked by go test can’t be attached to. If you want to test, you must first compile it into a test file and then execute it. You can refer to this issue for more details.

$ dlv attach 19654
could not attach to pid 19654: decoding dwarf section info at offset 0x0: too short

Furthermore, by default, Go’s test caches results, which can be controlled via environment variables. However, with Go modules (go mod), it’s recommended to use ./ddl.test -test.count=1 to disable caching. It doesn’t feel very elegant.

package main

import (
	"fmt"
	"os"
	"runtime"
	"time"
)

func main() {
	runtime.GOMAXPROCS(2)
	a := make(map[int]int)
	go func() {
		i := 0
		for {
			a[1] = i
			i++
			time.Sleep(1000)
		}
	}()
	for {
		if a[1] > 1000000 {
			fmt.Println(a[1])
			os.Exit(1)
		}
	}
}

After compiling and running it (assuming your machine has 2 or more cores), you will get the following error:

fatal error: concurrent map read and map write

goroutine 1 [running]:
runtime.throw(0x10c3e05, 0x21)
        /usr/local/Cellar/go/1.10.3/libexec/src/runtime/panic.go:616 +0x81 fp=0xc42004bf00 sp=0xc42004bee0 pc=0x10263f1
runtime.mapaccess1_fast64(0x10a5b60, 0xc42007e180, 0x1, 0xc42008e048)
        /usr/local/Cellar/go/1.10.3/libexec/src/runtime/hashmap_fast.go:101 +0x197 fp=0xc42004bf28 sp=0xc42004bf00 pc=0x1008d27
main.main()
        /Users/yusp/test/panic3/main.go:22 +0x7c fp=0xc42004bf88 sp=0xc42004bf28 pc=0x108e28c
runtime.main()
        /usr/local/Cellar/go/1.10.3/libexec/src/runtime/proc.go:198 +0x212 fp=0xc42004bfe0 sp=0xc42004bf88 pc=0x1027c62
runtime.goexit()
        /usr/local/Cellar/go/1.10.3/libexec/src/runtime/asm_amd64.s:2361 +0x1 fp=0xc42004bfe8 sp=0xc42004bfe0 pc=0x104e501

goroutine 5 [runnable]:
time.Sleep(0x3e8)
        /usr/local/Cellar/go/1.10.3/libexec/src/runtime/time.go:102 +0x166
main.main.func1(0xc42007e180)
        /Users/yusp/test/panic3/main.go:18 +0x61
created by main.main
        /Users/yusp/test/panic3/main.go:13 +0x59

It seems straightforward; Golang’s map is not thread-safe, and concurrent read and write cause a panic. However, look at the error information on line /Users/yusp/test/panic3/main.go:18 +0x61, which points to line 18 of main.go where Sleep is called, not the actual point of concurrency issue. In a vast stack trace, it becomes even harder to locate the problem.

A workaround that comes to mind is if you only see the read stack and want to see the write stack, set a variable at the read position, reset it after reading, and check the value of this variable at the write position. If reading is currently happening, panic will be triggered.

The English font set in Microsoft’s VS Code is monospaced, while the Chinese font is not.

Method

1. Download and install the fonts from here. This font combines Source Han Sans and is said to align punctuation strictly.
2. Use the method described here to set up VS Code.

PS: It is indeed aligned, although the English text appears a bit narrow.