/notes (GitHub-gated, same login as /admin) isn't a list. Every note is a node on a canvas, connected to other notes by links you draw yourself, and the whole thing behaves like a tiny physics simulation — notes repel each other, links pull connected notes together like springs, everything settles toward the center of the view. It's overkill for "write things down," and that's sort of the point: the graph is the organizing structure, not a visualization bolted onto one.

The physics

There's no library here — tick() is a hand-rolled force simulation that runs on requestAnimationFrame whenever the graph is disturbed:

• Every pair of notes repels the other with a force proportional to REPEL / distance², clamped by a minimum distance so two notes can never fully overlap.
• Every link pulls its two notes toward a resting distance (LINK_DISTANCE) like a spring — too close and it pushes apart, too far and it pulls in.
• A weak constant force pulls every note toward the origin, so the graph doesn't drift off toward infinity as repulsion accumulates.
• Velocity is damped each frame (DAMPING = 0.82) so the whole thing settles instead of oscillating forever.

The loop keeps scheduling itself only while something's still moving faster than SETTLE_EPS, or while a note is actively being dragged — once it's calm, simRunning goes false and the browser stops doing any work at all. Node radius scales with connection count (22 + connections × 5, capped at 46), so a heavily-linked note visibly reads as a hub without any separate "importance" field to maintain.

Positions aren't recomputed from scratch on every load, either — x/y are real columns on the notes table (added via an ALTER TABLE migration in notes.ts), and dragging a note debounces a save back to the server 400ms after it stops moving. A note you haven't manually placed falls back to a golden-angle spiral (scatterPoint) so a fresh database doesn't start with every note stacked at the origin.

A tool dock instead of remembering modifier keys

Four interactions live on the same canvas — move a note, link two notes, trace the shortest path between two notes, box-select several notes at once — and they all start with a pointer-down on a node. Early on that meant memorizing which modifier key meant what. The fix was a small dock of sticky tool modes (Pointer / Link / Path / Select) so the current mode is always visible and doesn't need to be held down. The modifier-key shortcuts still work underneath (effectiveTool() checks shiftKey/ctrlKey/altKey before falling back to whatever's selected in the dock) — the dock just made the feature discoverable instead of being the only way to reach it.

Path mode is the one with actual logic behind it: click a start note, click an end note, and bfsPath() runs a breadth-first search over the link graph (undirected, since path-finding doesn't care about link direction) and highlights every link on the shortest route between them. It's a genuinely useful question once a graph has more than a dozen notes — "how are these two ideas connected" — answered with a plain BFS over an adjacency map built fresh from the current links array each time.

Select mode turns multi-select into a bulk-linking tool: box-select or shift-click a set of notes, then click one more note as the "hub" and every selected note gets linked to it in one pass (linkSelectedTo) — useful for "all of these relate to this one," which used to mean drawing the same link by hand N times.

Wiki-links and revisions

Typing [[Note Title]] in a note's body and saving auto-creates a real graph link to the matching note (autoLinkWikiRefs, matched case- insensitively by title) — so a habit borrowed from Obsidian/Roam-style tools becomes an actual edge in the same graph the canvas draws, not just a clickable in-text reference.

Edits also snapshot into note_revisions before being overwritten — throttled server-side to once per two minutes per note (shouldSnapshot in notes.ts) so autosave firing on every second-long pause while typing doesn't flood the table with near-duplicate snapshots. A note's last 20 revisions are browsable and one-click restorable from the panel. Deletes are soft (deleted_at, filtered out of every read path but not actually removed) specifically so a same-session "Undo" can bring a note straight back, links and all, with no separate trash/restore flow to build.

Then: none of this works on a phone

The canvas assumes a mouse. Dragging a node, drawing a link by dragging from one note to another, holding a modifier key, hovering to see a tooltip — none of it has a touch equivalent that isn't worse than the desktop version. Rather than trying to retrofit touch gestures onto a pointer-driven simulation, /notes now branches early: isMobile is set from window.matchMedia('(max-width: 768px)') (with a change listener so rotating a tablet or resizing a window updates it live), and mobile gets an entirely different view — a plain scrollable list of notes with a search box, and tapping one opens a full-screen editor with a title field, a comma-separated tags field, a write/preview toggle for the markdown body, and image attach, instead of the floating side panel desktop uses.

The interesting constraint wasn't building the list-and-editor view itself — that part's straightforward — it's that both branches have to share the same state. nodes, links, selectedId, panelBody, autosave timers, all of it. A note edited from the mobile list view needs to show up correctly if you resize the window past 768px without a page reload, and vice versa. So the split is a CSS class toggle on the same <main> (class="{isMobile ? 'flex' : 'hidden'} …") rather than two separately mounted trees, plus a couple of guard clauses elsewhere — the force simulation's $effect bails out early on mobile, since there's no point running physics nobody can see or interact with — never a duplicated copy of the data layer. Even the small stuff carried over deliberately: the mobile "Back" button flushes any pending autosave before closing the editor (mobileBack), mirroring the exact flush selectNote already did on desktop to avoid a debounced save landing after the panel had already moved on to different content.

One graph, two very different ways to touch it, zero duplicated state.

Three separate admin-area problems, fixed in quick succession, that turned out to share one root cause: the private tooling around this site had grown faster than its plumbing.

Images had nowhere real to live

The devlog and project editors' cover/gallery fields were plain text paths — whatever you typed had to already exist under static/, which meant manually dropping a file into the repo before you could reference it. That's fine for a handful of images added at commit time, and useless from a running prod session: static/ is baked into the Docker image at build time, so anything added there doesn't survive a redeploy and can't be touched by the running server at all.

The fix mirrors a pattern the site already had for note attachments: a media library backed by the persistent data volume. media.ts is deliberately small — save/list/delete against a data/media/ directory, filenames are {uuid}-{slugified-original-name}.{ext} so collisions can't happen and the original name survives for readability, uploads are capped at 8MB and restricted to PNG/JPEG/GIF/WebP by MIME type. An admin-gated API route handles upload/list/delete, a public /media/[filename] route serves the files, and /admin/media is a browsable explorer with drag-and-drop upload and multi-select bulk delete. A MediaPicker component then plugs into the devlog/project cover field, the gallery field (multi-select), and the post body itself.

The admin area itself needed the same care its data model got

Once there was real functionality worth protecting, the rough edges around it stood out more: no link back to the dashboard from any sub-page, saves that did a silent full-page reload with no confirmation, deletes gated by a native window.confirm(), and nothing to filter with once the devlog/project lists grew past a handful of entries. All fixed together — a shared +layout.svelte with a back-to-dashboard link, use:enhance-based save feedback instead of relying on the reload itself as confirmation, a reusable ConfirmDialog component, and client-side filter/sort on the list and watchlist-cache pages. Small, but it's the difference between an admin area that feels maintained and one that just happens to work.

Backups that diff instead of just existing

The persistent Coolify volume protects data/ across a redeploy, but not against losing the server itself — a host failure, a bad migration, a fat finger against the volume. /api/backup (same secret-gated, hit-on-a-schedule pattern as the Spotify scrobble endpoint) closes that gap by dumping the SQLite databases and pushing them to a private git repo.

The interesting decision is how it dumps them. Committing the raw .db files would work, but SQLite's on-disk format means a single changed row can shuffle bytes across the whole file — every backup would look like a full rewrite in git diff, and years of backups would compress and diff badly. Instead, dumpDatabaseToSql reproduces what sqlite3 <file> .dump does: schema statements plus one INSERT per row, in plain text. Two details made that not-quite-trivial:

• pragma_table_list() distinguishes real tables from FTS5's internal shadow tables (notes_fts_data, notes_fts_config, etc.) — those have reserved names SQLite refuses to CREATE/INSERT into directly, and they're rebuilt automatically alongside their parent virtual table, so they have to be skipped rather than dumped.
• Virtual tables themselves (the FTS5 index) hold no data of their own to dump — only their schema statement is written; the app backfills the index from the real table on next startup anyway.

The result: five SQLite databases (notes, simkl-cache, spotify-history, status, newtab-settings) as five .sql files, plus the note-attachments and media directories copied wholesale, all committed to a fresh temp clone of the backup repo and pushed. git status --porcelain after staging tells it whether anything actually changed — a no-op run skips the commit instead of creating an empty one every time the schedule fires. /admin/backups surfaces the last commit's timestamp (read via a shallow clone of the backup branch, no extra state of its own needed) and a "run backup now" button for out-of-band peace of mind.

Three features, one commit, no shared code between them — but the same underlying reason they were each cheap to build.

A weekday × hour listening-habits heatmap

/listens already had a GitHub-style yearly activity heatmap and an hour-of-day listening clock. The natural next chart cross-references them: weekday on one axis, hour-of-day on the other, play count as intensity — answering "am I actually a Sunday-morning or Friday-night listener" in one glance instead of inferring it from two separate charts.

getWeekdayHourBreakdown is the whole implementation server-side: strftime('%w', played_at) and strftime('%H', played_at) grouped together, one GROUP BY over a table that already exists. Like every other aggregate on that page, it's sparse — weekday/hour combinations with zero plays are just absent from the result rather than present with a zero, and the client fills in the gaps when it renders the grid. Optionally scoped to a single year via the same yearRange() helper the yearly heatmap already used.

Adding the new chart also meant rebalancing /listens' card layout — the grid had grown one card at a time across several earlier passes and had started to show mismatched-height dead space between cards. Nothing algorithmic, just a manual pass at grouping the cards that visually belong together.

A lightbox for project galleries

Project pages had gallery images that opened at native size with no zoom — click one, get a big image inline, no way to page through the rest of the gallery without scrolling back up. Lightbox.svelte is a small, self-contained overlay: click-to-expand, arrow-key and on-screen prev/next navigation, an image counter, Escape or a click on the backdrop to close. open and index are $bindable props, so the project page itself just needs an array of image URLs and a click handler that sets the index — no gallery-specific logic lives in the component.

Swapping the homepage's top-track callout for a sparkline

The homepage previously surfaced "top track" as a static callout — accurate, but static in a way that didn't reflect anything about recent listening, and a single track name doesn't say much at a glance. It's replaced with a 14-day listening-activity sparkline: a small inline chart showing daily play counts for the last two weeks, which reads as "here's what I've actually been doing" rather than a single frozen fact.

getRecentDailyPlayCounts backs it — almost identical in shape to the yearly heatmap query, just a rolling days-sized window anchored on today (UTC) instead of a calendar year. Same sparse-result convention, same memoization pattern as everything else in that file. The homepage query is cheap enough to run on every request because, like the rest of /listens, the data's already sitting local in SQLite — no external call, no separate cache layer, just another GROUP BY.

/newtab started as a simple pitch: replace the browser's blank new-tab page with something that's actually mine — a clock, a search box, the same Now Playing / Discord / GitHub widgets already living on the homepage, and a nice background photo. Login-gated behind the same GitHub OAuth as /notes and /admin, since none of this needs to be public.

The constraint that mattered most

A new-tab page isn't a page you visit — it's a page that reopens itself constantly, often dozens of times an hour, and it needs to feel instant every single time. That ruled out anything that leans on a slow first paint or an env-var-gated config that needs a redeploy to change. Two decisions fell out of it directly:

• The Unsplash background query is a setting stored in newtab-settings.db, editable from an in-page settings panel, not an environment variable. Wanting a different photo theme shouldn't mean touching Coolify's env UI and redeploying.
• The fetched photo itself is persisted to the same DB as a durable fallback, not just held in an in-memory cache.

Why the photo needed a durable cache

The first pass cached the fetched Unsplash photo in memory, keyed by search query. That worked until it didn't: every server restart — every redeploy, and in dev, every file save that bounces the Vite server — wiped the cache and forced an immediate re-fetch on the next load. Unsplash's demo tier caps out at 50 requests/hour, and a page that gets reopened as often as a new-tab page burns through that fast when every restart resets the counter to zero.

Persisting the last-fetched photo (URL, blur hash, credit) to newtab-settings.db fixed that: a restart still loses the in-memory cache, but the DB fallback means the very next request serves the last-known photo instead of triggering a fresh fetch. The actual re-fetch only happens once the cache's own TTL expires, restart or not.

The same commit also switched from Unsplash's urls.regular (capped at 1080px) to urls.raw with explicit width/quality params — the difference is obvious at anything wider than a laptop screen, and it was worth the one-line change once the caching was solid enough that fetching a bigger image wasn't also fetching it more often.

Everything a dashboard accumulates

Once the shell existed, /newtab grew the way these things do — one useful thing at a time, each cheap to add because the persistence layer was already there:

• Quick links and search history, both trivial once there's somewhere to put them — quick links later grew into its own small feature, below.
• A favoritable, cyclable background photo history instead of a single cached photo — click through past backgrounds, star the ones worth keeping.
• A pomodoro-style focus timer with daily stats, because a new-tab page is exactly where you'd glance to start one.
• Quick note capture straight into the notes graph — type a thought, it lands as a real note without a context switch.
• A small watchlist widget pulling from the same Simkl-backed data as /watchlist.
• Client-side persisted drag/dock layout for the widgets — where you put things stays where you put them, stored in localStorage rather than the server since it's purely a per-browser display preference.

None of these needed new infrastructure. newtab-settings.db already held one blob of durable state; everything after the background-photo cache was just more columns and more UI on top of a page that was already fast.

Quick links outgrew their popover

"Quick links" started as exactly what it sounds like — add a label and a URL, remove one you don't want anymore. That was fine for five links; it stopped being fine once reordering, editing, and picking something better than a bare text label all turned out to matter too. Rather than keep wedging features into the small popover it lived in, the management UI moved out into a dedicated QuickLinksModal component with actual room: click-count-based sort (so frequently used links can float to the top without dragging anything), up/down reordering without a drag-and-drop library, inline editing, per-link keyboard shortcuts, and a curated Lucide icon picker — a hand-picked subset (dev tools, media, finance, productivity, social/web, misc) rather than the full icon set, stored as the same kebab-case name Lucide ships it under so the value is portable and self-describing rather than an opaque index into some list.

The one thing that had to be handled carefully: links added before the icon picker existed had emoji stored in what's now the icon column. Rather than a migration script to convert them, the icon component just falls back to rendering the raw stored value as text if it isn't a recognized Lucide icon name — an old emoji renders exactly as it always did, no data touched.

The Watchlist page opened as three static grids off one Simkl API call. By the end of the day it had search, sorting, genre filters, a stats section, and a caching layer underneath all of it — same page, same day, just a lot more of it by the time it shipped.

The shape of it

getLibrary() in simkl.ts hits Simkl's sync/all-items endpoint once per media type (shows, anime, movies) with status=all, which returns every bucket — watching, completed, plan-to-watch, on hold, dropped — in one call per type instead of one call per bucket. Korean dramas and movies mostly live under the "shows"/"movies" buckets rather than "anime" on Simkl, but querying all three keeps the page correct even for a title filed somewhere unexpected.

One thing the bulk response gets wrong on its own: poster links. Simkl's detail URLs need the numeric id (/tv/<id>/<slug>), not just the slug — a slug-only link 404s into the generic discover page instead of the title.

Genres and overviews aren't in that call

Genres, overview text, and per-episode runtime are a separate, per-title request — and the library has around 250 titles. Firing all of them on every page load isn't an option, so enrichLibrary() only ever tops up a small, bounded batch (DETAIL_BATCH_SIZE = 15) of missing or stale entries per request, caching results in simkl-cache.db's simkl_details table keyed by (simkl_id, media_type). A library this size fully warms over a handful of page loads; anything beyond the batch just renders without genres until its turn comes up — the same degrade-gracefully approach as the rest of the site. Cached entries go stale after 60 days (genres don't change often), and rows cached before runtime existed are treated as stale too, so they backfill instead of waiting out the full window.

Surviving a Simkl outage

Simkl's API rules explicitly permit caching user data locally, so alongside the per-title cache, simkl-cache.ts also keeps a single-row snapshot of the entire enriched library in simkl_library_snapshot. getLibraryWithFallback() tries the live sync call first and saves a fresh snapshot on success; if the call throws, it serves the last saved snapshot instead of an empty page, with a stale flag the UI turns into a small banner ("showing a cached copy from…"). simkl-refresh.ts also runs the same refresh on a 24-hour timer independent of page traffic, so the fallback doesn't go stale just because nobody visited the page in a while.

What it adds up to

The stats section reads like Simkl's own stats page: watch time in days and hours (from real per-title runtimes, not an estimate), peak year, most active weekday, average rating, backlog size with hours-to-clear, completion rate, and a top-5 genre breakdown — all computed from the same enriched library the grids already have in memory, no extra queries. It's also the one page on the site that breaks out of the usual narrow, centered column — search, sort, and stats all use the full width, since a six-column poster grid needs the room.

Surprise me isn't a one-line text pick that pops a new tab either — it reveals a full spotlight card in place: poster, rating, genres, overview, an "Open on Simkl" link, and a "Try another" button to reroll without leaving the page.

Two tabs, because anime showed up

Anime titles started showing up in the library alongside the kdramas and movies, and mixing Isekai/Seinen genre chips in with kdrama tags didn't read well as one filter set. The page split into TV & Movies and Anime tabs, each with its own stats, its own filters, its own "Surprise me" — scoped so the shuffle button never hands a TV-and-movies session an anime pick by accident. Go see for yourself.

The Listens page isn't backed by a live feed. Spotify's own API only exposes the last ~50 recently-played tracks — fine for a "now playing" widget, useless for "what have I actually listened to since 2019." Real history only exists in one place: Spotify's own "extended streaming history" export, the one you request from their privacy settings and wait a few days for.

The shape of it

The export lands as a pile of JSON files, one play per entry — track, artist, album, timestamp, milliseconds played, the works. spotify-history.ts parses and normalizes them; spotify-history-db.ts writes the result into spotify-history.db, a SQLite file on the persistent data volume. /spotify-import (gated behind the same GitHub login as /admin) is where the files actually get uploaded.

Inserts are idempotent on (played_at, spotify_uri, ms_played), which matters more than it sounds like it should — Spotify's exports overlap at the edges, and re-uploading the same file (or a newer export that reaches back further) needs to be a no-op for anything already in the database, not a pile of duplicate plays.

Filling the gap between exports

An export is a snapshot, not a subscription — the moment it's imported it starts going stale. /api/spotify/scrobble closes that gap: a secret-gated endpoint that polls Spotify's recently-played on a schedule (a Coolify Scheduled Task hits it periodically) and inserts anything new. Its ms_played is only an estimate, so importing a fresh export later calls deleteScrobbledRange first — anything scrobbled that the new export's date range now covers for real gets replaced rather than double-counted.

What the data turns into

Once a few years of plays are sitting in SQLite, the interesting part is what you can compute from them cheaply: total listening time broken into days/hours/minutes, peak year, most active weekday, top artists and tracks (with a drill-down into which tracks made up an artist's plays), a GitHub-style activity heatmap per year, an hour-of-day listening clock, and an "on this day" section pulling matching dates across every year in the history. All of it's just GROUP BY and a bit of date math over one table — no external calls, no caching layer needed, because it's already local.

Search, twice

The search box went through two versions. The first was a dropdown list of text results — functional, but it needed a click-outside handler to dismiss and gave you nothing to look at but track names. The second pass replaced it with an inline grid of cards, each lazily fetching its own album art from Spotify's public oEmbed endpoint — no auth, no token, just a fetch keyed and cached by track URI, degrading to a plain music icon if it fails. A proper "no matches" state and a clear button replaced the dismiss-by-clicking- elsewhere behavior along the way.

Same idea as building Watchlist: a page that started as "just show the data" kept growing search, filters, and visual polish on top, one pass at a time, because once the underlying data's already sitting in a local database, adding another way to look at it is cheap.

The projects page started as a single hardcoded object in the page component — fine for one project, awkward the moment there's a second one worth writing more than two sentences about.

The shape

Same pattern as the devlog: frontmatter'd markdown in src/content/projects/, read off disk at request time.

export interface ProjectMeta {
	slug: string;
	name: string;
	description: string;
	href?: string;
	live?: string;
	cover?: string;
	images: string[];
	tags: string[];
	stack: string[];
	status: ProjectStatus;
	featured: boolean;
	readingTime: number;
	searchText: string;
	draft: boolean;
	date: string;
}

getAllProjects() lists them for the grid, getProject(slug) renders one in full at /projects/[slug] — a straight copy of how devlog.ts already works, down to reusing gray-matter for frontmatter and marked for the body.

What this unlocks

Each project now gets its own page instead of just a card that links out to GitHub — room for a real writeup, screenshots, a live-site link, source link, and tags, without touching a single line of Svelte. Add a .md file, redeploy, done. Exactly the same deal the devlog already had.

This post is itself the first entry that isn't a devlog post about something built — it's the writeup for a feature that's also visible one click away, on the projects page itself.

Update: the copy became a share

That "straight copy" didn't stay a copy for long. devlog.ts and projects.ts ended up with byte-identical readEntryFile() and toDateString() functions — same gray-matter call, same slug-from-filename logic, same fix for gray-matter parsing unquoted frontmatter dates into Date objects instead of strings. Two copies of the same fix is one more place for it to drift, so both now import readEntryFile/toDateString from a shared src/lib/server/content.ts instead of defining their own.

Their toMeta()/getAll()/get() functions stayed separate, though — devlog posts have grown series, a table of contents, search text, and footnotes that projects don't need, so forcing both into one shape would've cost more than the duplication it removed. Share the part that's actually identical, not the part that just looks similar today.

Getting this shipped to Coolify meant a Dockerfile, and two things in it turned out to be less obvious than they looked.

--prod doesn't mean what it sounds like

The build stage installs everything — devDependencies included — compiles the app, then the runtime stage only needs the production deps. The obvious move is a fresh pnpm install --prod there. That doesn't actually shrink anything here: the icon packages (@lucide/svelte, @icons-pack/svelte-simple-icons) declare svelte as a peerDependency, and pnpm's autoInstallPeers resolves that whole peer chain — svelte → @sveltejs/kit → vite → esbuild/rollup/lightningcss — regardless of --prod, since peerDependencies aren't classified as dev dependencies. The entire dev toolchain comes back anyway, just through a different door.

The fix is to prune the already-resolved tree from the build stage instead of asking pnpm to resolve a fresh one:

pnpm prune --prod alone still leaves the dev toolchain physically on disk, for the same peer-chain reason — so the leftover .pnpm directories get removed explicitly afterward. Confirmed nothing on that list is ever require()'d at runtime by grepping the compiled build/ output: adapter-node's output is self-contained.

No curl for the HEALTHCHECK

Both stages run on node:22-slim, which doesn't ship curl or wget — and installing either just for a HEALTHCHECK isn't worth the extra image layer. Node itself can make the request instead:

Dropped straight into the Dockerfile as the HEALTHCHECK CMD, polling /healthz — a route that already existed for exactly this — so Coolify (and docker ps) can see whether the container is actually serving, not just that the process is alive. --interval, --timeout, and --start-period keep it from flapping while the server boots.

Didn't want to invent a new visual language just for a link hub, so this site reuses the same near-black surface system as the other projects — same spacing scale, same radii, same motion timing. The one deliberate change is the accent color.

Lime is spoken for

RG Digital's #ccff00 lime is specifically that brand's accent — it doesn't show up anywhere else. This site uses cyan instead, split into two tiers rather than one flat accent color:

• --color-primary (#22d3ee) for anything on screen at rest: links, borders, button chrome, focus rings
• --color-action (#00e5ff) reserved for triggered/live moments — a flash, a fill animation, something reacting to an event that just fired

The rule of thumb is just "if it's on screen at rest, use primary; if it's reacting to something that just happened, use action." .flash-in and .pill-fired are already defined in tokens.css for exactly that, but nothing on the site fires them yet — a rule with no exceptions is easy to follow later, so it's sitting there waiting rather than getting retrofitted once something actually needs it.

One token file, two themes

Light mode isn't a second design system — it's the same token file with a [data-theme='light'] override that only touches the neutral surface and text tokens (--bg, --surface, --border, --white, --gray, --dim). The accent color, the spacing scale, the radii, and every motion timing stay byte-identical across both themes. ThemeToggle.svelte just flips an attribute on <html> and persists the choice to localStorage; there's no separate light-mode variant of any component to keep in sync.

Borrowed the boring parts wholesale

Spacing is a 4px-based scale (4, 8, 12, 16, 20, 24, 32, 40, 48, 56, 64), radii are 6/8/12px plus a full for pills, and the easing curves are the same three cubic-beziers RG Digital already uses. The one convention worth naming: UI-level transitions (hovers, toggles) stay under 300ms, page-level transitions land around 400ms — copied straight from the source motion guideline rather than reinvented per component. prefers-reduced-motion turns off the ambient CTA glow and the flash-in animation for anyone who's asked for less motion.

Kept it that simple on purpose. A personal devlog doesn't need a component library — just enough consistency that it doesn't look like a template.

This is the first entry in the new devlog. The old razerghost.xyz was a static portfolio; that content moved to rg-digital.dev. This site is a smaller, personal thing: a link hub plus a running log of whatever random project I'm poking at.

How it works

Posts are plain markdown files in src/content/devlog/, read straight off disk on every request — no static build step, no CMS, no database. Push a new .md file, redeploy, done.

const entries = getAllDevlogEntries();

Some things worth noting:

• No comments, no analytics
• Runs as a real Node server (SvelteKit + adapter-node), not a static export
• Posts can embed real, interactive Svelte components — see below

A live component, embedded right here

Drop <div data-embed="Counter"></div> into a post's markdown and it gets hydrated client-side into an actual Svelte component after the page loads:

Embeds can also take props via data-* attributes on the placeholder:

Mostly this exists so I have somewhere to write things down.