Student developer in Japan
Linux-first / performance-minded / infrastructure-oriented
Building software around Minecraft, rendering, containers, and compatibility
I enjoy working below the surface of an application: render pipelines, protocol gateways, process lifecycles, persistent storage safety, compatibility layers, and reproducible deployment.
My goal is not merely to make something run. I want to understand why it works, measure whether it is actually better, and make failure modes explicit.
Compatibility before novelty. Evidence before performance claims. Safety before automation.
|
Experimental Fabric client optimization mod that accelerates eligible Minecraft
|
A predictable, fail-fast Minecraft Java server container image designed for Kubernetes, GitOps, persistent volumes, and S3-compatible asset delivery.
|
|
Compatibility patches, reproducible build scripts, diagnostics, and an interactive setup flow for running AviUtl2 on x86_64 Linux.
|
A Go-based Minecraft Java Edition gateway that routes one public TCP entry point to multiple backend servers using the hostname from the Minecraft handshake.
|
performance:
- benchmark before claiming improvement
- optimize real bottlenecks, not impressive-looking microcases
reliability:
- fail fast when state is ambiguous
- preserve user data and provide safe fallback paths
compatibility:
- integrate with the existing ecosystem
- keep unsupported behavior explicit and recoverable
workflow:
- automate repeatable work
- keep builds and diagnostics reproducible- Expanding Threadium from dense-entity wins toward broader real-world Minecraft performance
- Hardening Minecraft server delivery and routing for Kubernetes environments
- Improving Windows creative software compatibility on Linux without hiding unverified assumptions
- Building development environments where Linux is treated as a first-class platform
