Consoler Dark: A Terminal-Themed Zola Blog with Neofetch Logos and In-Browser SurrealDB

2026-06-26T00:00:00+00:00

I wanted my blog to feel like a terminal — not in the lazy "monospace font and a green-on-black palette" way, but structurally. The model I kept coming back to was neofetch</code>: an ASCII distro logo on the left, a tidy key/value table of system info on the right. That layout is a homepage. So I built one.

The result is Consoler Dark, the Zola theme this site runs on. This is how it works, including the two parts I'm fondest of: a script that generates logos by scraping neofetch itself, and a database that runs entirely in your browser.

Starting from after-dark</h2>
I didn't start from scratch. Consoler Dark is a fork of comfusion's after-dark</a>, a minimal Zola theme built on top of hack.css</a>. You can still see hack.css's fingerprints in the SCSS — the .hack</code> utility classes, the no-nonsense defaults. After-dark gave me a clean skeleton; I layered the terminal identity on top.</p>
The taxonomy setup is where I diverged most. Beyond the usual categories</code> and tags</code>, the site indexes series</code>, projects</code>, and authors</code> — that last one so I can credit the AI models I draft alongside as co-authors (this post included).</p>
The neofetch metaphor, in templates</h2>
The homepage and section headers render a .neofetch-header</code>: a logo block next to a tech_info</code> table driven straight from config.</p>
[extra.tech_info]
Title = "parkerjones.dev"
Framework = "Zola"
Theme = "Consoler Dark"
Hosting = "Github Pages"
</code></pre>
The template loops over those key/value pairs the way neofetch prints OS</code>, Kernel</code>, Uptime</code>. The nice property is that any page can override individual fields via page.extra.tech_info</code>, so a project page can advertise its own "system specs" while inheriting the site defaults. It's config-as-content, and it keeps the homepage honest — the chrome describes the actual stack.</p>
A few smaller touches round out the feel: an intro</code> keyframe fade so content boots in rather than flashing, a 16:9 responsive-iframe</code> helper for embeds, and :target</code> highlighting so deep links land with a visible cursor-style focus.</p>
@keyframes intro { 0% { opacity: 0; } 100% { opacity: 1; } }
main, footer { animation: intro 0.3s both; animation-delay: 0.15s; }
</code></pre>
Generating logos by scraping neofetch</h2>
Here's the part I enjoyed most. Neofetch ships ASCII art for hundreds</em> of distros, embedded right in its shell script as heredoc blocks. Rather than hand-draw anything, I wrote a Python script that fetches the raw neofetch source, parses out every logo, and converts each to an SVG.</p>
The parser keys off neofetch's own structure — each logo is a read -rd '' ascii_data <<'EOF' … EOF</code> block, and the distro name is in the case</code> line just above it:</p>
if "read -rd '' ascii_data <<'EOF'" in line:
    # walk backwards to the case label, e.g.  "Ubuntu"|"ubuntu")
    j = i - 1
    while j >= 0 and not re.search(r'\)$', lines[j].strip()):
        j -= 1
    distro_name = re.findall(r'"([^"]+)"', lines[j])[0]

    # collect everything up to the EOF sentinel
    ascii_block = []
    i += 1
    while lines[i].strip() != "EOF":
        ascii_block.append(lines[i]); i += 1
</code></pre>
Converting ASCII to SVG is just laying each line down as a <tspan></code> in a monospaced <text></code> element, sized from the longest line:</p>
char_width, line_height, font_size = 8, 18, 14
width  = max(len(l) for l in lines) * char_width + 10
height = len(lines) * line_height + 10
# one <text> with a <tspan dy="line_height"> per line
</code></pre>
Run it, and static/logos/</code> fills up with a clean SVG per distro — vector, themeable, no image assets to hand-maintain. When neofetch adds a logo, I re-run the script. The art stays in sync with upstream because upstream is the source of truth</em>. That's the kind of automation that pays for itself the first time you'd otherwise have copied ASCII art by hand.</p>
A database that runs in your browser</h2>
The detail that surprises people: Consoler Dark ships a WebAssembly build of SurrealDB</strong> and runs it client-side. There's no backend. The theme's js/main.js</code> boots an in-browser SurrealDB engine, fetches a /site.sql</code> file, pulls the SQL out of a <pre></code> tag, and executes it — all in the visitor's tab.</p>
import { Surreal } from "surrealdb";
import { surrealdbWasmEngines } from "@surrealdb/wasm";

const db = new Surreal({ engines: surrealdbWasmEngines() });
const sql = await fetchSQLFromPreTag();   // read /site.sql from a <pre>
</code></pre>
This is bundled with Vite. A couple of non-obvious settings were required to make a wasm database happy in a static-site context: an es2020</code> target plus top-level-await</code> support (the engine initializes asynchronously at import time), and excluding @surrealdb/wasm</code> from dependency pre-bundling so Vite doesn't mangle the wasm.</p>
build:    { target: 'es2020', outDir: 'static' },
esbuild:  { target: 'es2020', supported: { 'top-level-await': true } },
optimizeDeps: { exclude: ['@surrealdb/wasm'] },
</code></pre>
Why do this on a blog? Because I write about databases in the browser</a> and using SurrealDB as a site cache</a>, and a theme that is</em> the demo beats one that merely links to it. The dev workflow runs Zola and Vite in parallel so the static site and the wasm bundle rebuild together:</p>
"dev": "npm-run-all --parallel vite-serve zola-serve"
</code></pre>
The linkify experiment I rolled back</h2>
Not everything survived. I'd wired up a client-side linkify</a> pass that auto-detected #hashtags</code> in post text and rewrote them into links to the matching /tags/</code> page — Twitter-style tagging, for free, with no changes to how I wrote posts.</p>
formatHref: (href, type) =>
  type === 'hashtag' ? `/tags/${href.slice(1).toLowerCase()}` : href
</code></pre>
It worked, and I turned it off. Scanning every <p></code> and <span></code> on load and rewriting innerHTML</code> is a lot of DOM churn for a cosmetic feature, it fought with code blocks that legitimately contain #</code>, and "clever text rewriting at runtime" is exactly the kind of thing that quietly breaks a year later. The code's still in the repo behind a partial; the lesson is that shipping</em> and keeping</em> are different decisions, and a static site rewards restraint.</p>
Takeaways for rolling your own Zola theme</h2>

Fork something minimal.</strong> after-dark + hack.css gave me a correct baseline so I could spend my effort on identity, not resets.</li>
Drive chrome from config.</strong> The tech_info</code> table means the design describes the real stack and updates itself.</li>
Automate your assets from their upstream source.</strong> The neofetch scraper means I never hand-edit ASCII art.</li>
A static site can do more than you think.</strong> A wasm database in the client turned my theme into a live demo of the things I write about.</li>
Be willing to delete features that work.</strong> Linkify was the most "impressive" thing I built and the right call was to switch it off.</li>
</ul>
The theme is open source under MIT. If you want a blog that boots like a terminal and ships a database to every reader, the pieces are all here.</p>
— Parker Jones, parkerjones.dev</a></em></p>

Hexagonal Chess in Rust: Bevy, WASM, and Serverless WebRTC Multiplayer

2026-06-26T00:00:00+00:00

Chess assumes a square board. But there's a whole family of hexagonal chess variants — Gliński's, McCooey's, Shafran's, and others — played on a board of hexagons where every piece needs new movement rules and your spatial intuition is useless. I built a Rust implementation of eight of them that runs entirely in the browser via WASM, with multiplayer that needs almost no server at all. This post is about the three architecture decisions that made it tractable.

Decision 1: separate the game from the engine from the network</h2>
The repo is three crates, and the split is the most important design choice in the project:
hex-chess/ ├── crates/ │ ├── core/ # pure game logic — no rendering, no networking │ ├── game/ # Bevy WASM app — rendering, input, the actual game │ └── signaling/ # minimal WebRTC signaling server ├── web/ # static web assets └── deploy/nixos/ # production deployment </code></pre> core</code> has no dependencies on Bevy, on WASM, or on the network. It's pure rules: given a board state and a variant, what are the legal moves? That isolation buys two things. First, the rules are testable without a GPU or a browser — cargo test</code> on core</code> exercises move generation directly, which matters enormously when "is this move legal on a Shafran board?" has eight different correct answers depending on the variant. Second, the rules are reusable: the same core</code> that the Bevy app calls could back a bot, a server-side validator, or a puzzle generator later, with zero rendering code dragged along. game</code> is the Bevy app — it owns rendering, input, and animation, and it asks core</code> what's legal. signaling</code> is its own tiny server. Keeping these three apart means a change to how pieces are drawn can't possibly break the rules, and a change to the netcode can't touch either.Decision 2: hex coordinates, not (row, column)</h2> The thing that breaks your brain about hex chess is that a square-grid mental model doesn't transfer. On a square board a piece has 8 neighbors and you index by (row, col)</code>. On a hex board a cell has 6 neighbors and (row, col)</code> produces ugly special-casing everywhere — diagonals aren't diagonals, and "forward" depends on which of three axes you mean. The standard fix (and the right one) is to stop thinking in two axes and use cube or axial coordinates — three coordinates (q, r, s)</code> with the constraint q + r + s = 0</code>. Movement directions become clean vector additions, distance is a single formula, and the six variants' wildly different movement rules all reduce to "which direction vectors does this piece get, and how far." Putting that coordinate system in core</code> is what keeps the eight variants from turning into eight piles of special cases. If you take one idea from this project, it's that the coordinate system is the architecture for a hex game — pick it before you write a single movement rule. Decision 3: peer-to-peer, so I barely run a server</h2> Most multiplayer games need a server in the hot path relaying every move. I didn't want to run (or pay for) that, so hex-chess uses WebRTC for true peer-to-peer play. The only server is the signaling</code> crate, and it does almost nothing: Two players want to connect. WebRTC needs them to exchange connection details (SDP offers/answers and ICE candidates) before they can talk directly.</li> The signaling server is just the broker for that initial handshake. It introduces the peers.</li> Once the peers connect, game traffic flows directly between the two browsers. The server is out of the loop entirely — it never sees a move.</li> </ul> So the "server infrastructure" for an arbitrary number of concurrent games is one tiny process whose only job is matchmaking introductions. It's idle the moment a game starts. That's a dramatically cheaper operational story than a stateful game server, and for a turn-based game like chess the direct peer connection is more than fast enough. Shipping it: WASM, Nix, and CI</h2> The game</code> crate compiles to WebAssembly with Trunk</a>, so the whole thing runs in the browser at near-native speed: nix develop # reproducible toolchain cd crates/game && trunk build --release </code></pre> The entire dev environment and production deploy are defined in Nix — nix develop</code> drops you into a shell with the exact Rust toolchain, wasm</code> target, and Trunk version, and nix build .#game .#signaling</code> produces both artifacts: nix build .#game .#signaling # build both packages </code></pre> Deployment lives in deploy/nixos/</code>, and GitHub Actions handles CI. This is the same declarative approach I use across my whole fleet</a> — the game and its signaling server are just two more Nix packages, built and deployed the same way as everything else I run. No "works on my machine" between my laptop and the box that serves the game. What I'd tell someone starting a hex game</h2> The hard parts of this project weren't the parts I expected. Rendering hexagons is easy; Bevy handles it. The hard parts were getting the coordinate system right before writing rules (retrofitting axial coordinates onto a square-grid assumption would have been a rewrite) and resisting the urge to put a real game server in the middle (the P2P handshake is more setup up front but far less to operate forever after). Pure-logic core, hex-native coordinates, peer-to-peer networking with a near-stateless broker, WASM for reach, Nix for reproducibility. Five decisions, eight playable variants, and a multiplayer game I can run for the cost of a process that sits idle most of the time. — Parker Jones, parkerjones.dev</a>

Parker Jones Dev Blog - wasm

Consoler Dark: A Terminal-Themed Zola Blog with Neofetch Logos and In-Browser SurrealDB

Hexagonal Chess in Rust: Bevy, WASM, and Serverless WebRTC Multiplayer