Skip to content
▓AVZILABS_

./stack

What I actually use, and what I use it for. Listed with the honest caveat rather than the flattering one: some of these I live in daily, others I reach for a few times a year.

$languages and data7
  • Pythonscraping, ETL, valuation models, Monte Carlo, geospatial
  • TypeScriptauction platform, this site, the game servers
  • SQLwarehouse modelling, panel schemas, query tuning
  • C#Unity gameplay, netcode, editor tooling
  • PHPthe earlier generation of auction platforms
  • Rregression and econometric work
  • VBAbid-tracking toolkits people could actually run
$AI and agentic tooling7
  • Claude Codeprimary harness. Custom MCP servers, skills, hooks
  • OpenCodesecond harness, run against alternative models
  • llama.cpplocal inference for anything commercially sensitive
  • Qwengeneral local model for coding and retrieval work
  • Gemmasmaller local model where speed matters more than depth
  • MCPservers written for Unity, Photoshop and FL Studio
  • RAG and embeddingsstructure-aware chunking, cited retrieval, OCR front end
$creative and 3D6
  • Unityfour game projects, plus a fair amount of editor tooling
  • Blendermodelling, and headless batch rendering for asset previews
  • Photoshoptexture and UI work, scripted through UXP
  • Illustratorvector UI, icons, print-ready artwork
  • FL Studiomusic and sound design, partly automated over MCP
  • EZCADlaser marking and engraving control
$infrastructure and shell7
  • Linux / Ubuntuwhere everything server-side actually lives
  • Amazon EC2ran the previous auction and data platform in production
  • CloudflarePages, Workers, Durable Objects, DNS, Zero Trust
  • Git and Git Bashday-to-day on Windows without pretending it is Linux
  • Bash and PowerShellautomation, deploys, and the pre-agentic workflow
  • nginx and systemdvhosts, units, and keeping services up
  • SQLite and Postgresfrom single-file demos to production schemas

./security

Not a certification list. These are the decisions actually taken across the projects on this site, including the ones that came from finding my own mistakes.

  1. 01Reduce the attack surface before hardening it

    This site runs with no inbound ports at all. The dynamic services reach the internet through an outbound tunnel and administration goes over a private mesh, so there is nothing exposed to scan. A port that does not exist needs no patching.

  2. 02Secrets never enter the repository

    The public repo runs gitleaks on every push. Real credentials live in environment variables and a password manager, and the generated CV is deliberately ignored by git because it carries a personal phone number. The gate matters because older projects on the same machine do contain real .env files.

  3. 03Least privilege on API tokens

    Scoped, single-zone API tokens rather than global keys, and expanded only when a specific operation actually needs it. Where a task could be done through a narrower account-level endpoint instead of a broader zone permission, it was.

  4. 04The server is not the trust boundary

    In the multiplayer game the server owns the clock, the letters and every scoring decision, and never sends other players their opponents’ answers. Client-side validation is a convenience; anything that decides an outcome is computed where the player cannot reach it.

  5. 05Transport and origin hygiene

    TLS 1.2 floor with 1.3 enabled, HTTPS enforced, strict origin validation, and CORS that echoes only the allowed origin rather than reflecting whatever asks. Databases belong outside the web root, which is worth saying because that is a mistake I have found in my own older deployments.

  6. 06Sanitisation as a design decision

    Published demos are rebuilt in an invented domain rather than redacted from client code. Find-and-replace leaves comments, identifiers and business logic intact, and you cannot un-publish it. Rebuilding is less work than auditing a redaction you can never fully trust.