DEV Community: martinimarcello00

How this site is built

martinimarcello00 — Tue, 25 Aug 2026 17:46:44 +0000

Every personal site I built before this one died the same way. A CMS I stopped updating, a database I had to back up, a plugin that broke on a version bump. The fix was to make the site something I already maintain every day: a repository.

There is no server, no database, nothing to patch. The whole thing is text files that get turned into HTML on a machine that lives for forty seconds.

Hugo, because the preview is instant

Hugo — A website that is just files in a repository.

This site is Hugo: Markdown for the words, YAML and JSON for the structured parts, Go templates for everything else. Builds finish in under half a second, which matters more than it sounds, because a preview that is instant is a preview you actually look at. No database, no runtime, nothing to patch at three in the morning.

Markdown for the words, YAML and JSON for the structured parts, Go templates for everything else. The full site rebuilds in about four hundred milliseconds.

That number is not vanity. A preview that is instant is a preview you actually look at, so you fix the spacing you would otherwise have shrugged at.

The part that took longest to appreciate is the data/ directory. Anything that is a list belongs there, not in a template:

# data/post_categories.yml
- id: terminal
  label: Terminal
  icon: fa-terminal

Adding a category is now a three line diff instead of a hunt through layouts.

Pages that keep themselves current

The pages I would forget to update are the ones nobody wants to see out of date: publications, repositories, what I have been reading.

So they update themselves. A handful of Python scripts, standard library only so CI needs no install step, fetch from ORCID, Semantic Scholar, GitHub and Open Library and write plain JSON into data/. Hugo reads it at build time.

The tip worth stealing is the failure mode:

- name: Refresh auto-updating data
  # Non-fatal: on API failure the committed data/*.json is used as fallback
  continue-on-error: true
  run: python3 scripts/update_data.py

The generated JSON is committed. If ORCID is down, the step goes red, the build carries on and the site shows yesterday's data. A stale publication list beats a failed deploy.

GitHub Actions — The only deploy button, and it is a git push.

The same workflow runs weekly on a cron, so the site refreshes even in a week where I push nothing.

The logos on this page downloaded themselves

The tool cards above carry real brand marks, and not one of them costs a request. A script reads data/tools.json, resolves each entry to a Simple Icons slug, downloads the SVG into assets/ and records the brand colour next to it:

"githubactions": { "file": "icons/tools/githubactions.svg", "hex": "#2088FF" }

Hugo inlines that file during the build, so the page ships with the icon already in the markup. No CDN, no call from the browser, nothing for a content security policy to argue with. Adding a tool is one JSON entry and one script run.

The photo wall goes further. A script parses the EXIF out of the originals, reverse geocodes the coordinates once, caches the answer so the geocoder is never asked twice, and writes the result as JSON. The source photos keep their metadata in the repository. The published copies do not:

[imaging.exif]
  disableLatLong = true

The place name reaches the page. The coordinates stay behind.

Social cards drawn at build time

This is my favourite trick in the repository. Every page has its own 1200x630 preview image, and nothing renders a screenshot.

Hugo can draw text onto an image, so the card is a base gradient plus the page title, stamped during the build:

{{ $base := resources.Get "images/og-base.png" }}
{{ $font := resources.Get "fonts/SpaceGrotesk.ttf" }}
{{ $card := $base.Filter (images.Text $title (dict
     "x" 80 "y" 160 "size" 68 "color" "#f8fafc" "font" $font)) }}

Two details cost me an afternoon. images.Text does not wrap, so the title has to be split into lines in the template. And the variable font renders at its lightest weight, so the text looked anaemic until I drew it three times at one pixel offsets to fake a bold.

Search is a build step, not a service

I wanted search without a third party and without shipping an index of the whole site to every visitor. Pagefind reads the finished HTML after Hugo runs and writes an index next to it:

hugo --gc --minify && npx -y pagefind --site public

One attribute decides what gets indexed, which is also how the pages I do not want in search stay out of it:

<div class="content"{{ if not .Params.noindex }} data-pagefind-body{{ end }}>

Press cmd+K anywhere on the site and it opens.

Copilot, and why the GitHub part matters

GitHub Copilot — A fast first draft, never the final word.

Used the way it is good: a fast first draft on code I can review, never on decisions I have not made yet.

The useful part was not autocomplete. It was that Copilot talks to GitHub through MCP, so it reads the repository, the issues and the workflow runs directly instead of me pasting context into a chat window.

Asking why a deploy failed and having it read the actual run is a different activity from describing the failure from memory.

It is still a draft machine. It wrote a breadcrumb partial for me and put the styling on a selector that only existed on half the pages, which I found by measuring the rendered page rather than by reading the diff. Verify, then keep.

GitHub — The site is a repository, and that is the whole trick.

The crosspost that cannot duplicate itself

A post opts in to dev.to with one line of front matter:

devto = true

A script renders it, rewrites the Hugo shortcodes into portable Markdown and sends it with a canonical_url pointing back here, so the copy never competes with the original in search results. The version that lands there also gets a closing link home that this page does not have.

The hard part was running it from CI, where there is no local state. Before sending anything the script asks dev.to what the account already holds and indexes it by canonical URL, so an article that exists is updated and never created twice, even on a fresh runner. The state file is only a cache plus a hash of the Markdown last sent, which is what stops an unchanged post being pushed back to the top of the feed on every deploy.

Two things bit me. dev.to renders Markdown with hard wrapping on, so my eighty column source lines each became a <br> and the indented continuations of a list were torn out of their bullets, which is why paragraphs are unwrapped before they are sent. And the API returns 429 well before its documented limits, so writes are spaced out and retried on the Retry-After header.

If you are reading this on dev.to, that is how it got here.

What I would tell myself at the start

Put the content in data/ before you think you need to. Let the scripts fail loudly and the site fail quietly. And measure the thing in a browser, because the bug is usually in the gap between what the template says and what the page does.

Every snippet above is the real thing, copied out of the repository rather than written for the occasion. Take what is useful.

The rest of the toolbox

This one first appeared on my site, where I write about the systems I build and the tools I actually use — the rest of the posts live here.

The tools I actually use

martinimarcello00 — Tue, 25 Aug 2026 15:38:09 +0000

Most "my setup" posts are shopping lists. This one is not, because the tools below earned their place by surviving contact with a bad week: a deadline, a broken laptop, a paper due, an evening where I could not stop scrolling. Everything else got uninstalled.

Three of them are worth telling properly.

chezmoi: my machine is a git clone

I used to keep dotfiles in a repo with a install.sh that symlinked things into place. It worked right up until my laptop and my home server needed almost the same configuration: same aliases, different git email, different paths, and one of them absolutely must not carry a work SSH config.

chezmoi solves exactly that. The dotfiles live in one repository, the machine-specific bits are templates, and secrets are pulled from a password manager at apply time instead of sitting in git. Bootstrapping a new machine is now one command and a coffee.

The unglamorous benefit is the one I care about: I stopped being afraid of reinstalling. When the setup is a git clone away, wiping a machine is a chore rather than a decision.

chezmoi — Dotfiles in git, secrets left out of it.

Keeps my shell, editor and git configuration in one repository and templates the parts that differ per machine, so a work laptop and a home server share a setup without sharing their secrets. Bootstrapping a new machine is a single command instead of an afternoon of copy-paste.

Atuin: my shell history became searchable

Every developer has a moment of typing history | grep and hoping. Shell history is one of the most valuable datasets you generate, and by default it is a flat file that truncates, forgets which directory you were in, and vanishes when you open two terminals at once.

Atuin replaces Ctrl-R with a real search over a SQLite database of every command, recorded with its directory, its exit code and how long it took. It syncs end-to-end encrypted between machines, and you can run the sync server yourself if you would rather not trust anyone with it.

What changed is subtle. I stopped writing throwaway shell scripts for things I do twice a year, because "the ffmpeg command from that conference talk" is now a two-second lookup instead of an archaeology project.

Atuin — Shell history as a searchable database.

Replaces Ctrl-R with a real search over every command I have ever run, recorded with its directory, exit code and duration. History syncs end-to-end encrypted between my laptop and my servers, and you can host the sync server yourself. The obscure ffmpeg invocation from eight months ago is now a two-second lookup.

A brick, and the app behind it

The one that is not software. I was properly hooked on my phone: in hand before my eyes were open, thumb scrolling through dinners and lectures. Willpower never fixed it.

What fixed it was a small orange square on my desk, a magnet and an NFC tag. Tap the phone against it and the apps I chose disappear. Tap again and they come back, but only if I walk to wherever I left the brick. That tiny bit of friction is the entire trick.

Underneath it is Foqos, an open-source iOS app that ties Apple's Screen Time restrictions to an NFC tag. No account, no subscription, no streak to protect. Two weeks in, my screen time had halved and I had stopped missing it, which says more about the reflex than about the willpower.

Focus Brick — A magnet, an NFC tag, two taps.

Foqos — The open-source app behind the brick.

The rest of the toolbox

These three are the ones with a story. The rest of what I use every day lives on the toolbox page: editor, terminal, research and focus tools, each with a note on why it earned its place, filterable by category.

See the full toolbox

Nothing here is sponsored and nothing is permanent. If one of these stops earning its place, it comes off the list.

This one first appeared on my site, where I write about the systems I build and the tools I actually use — the rest of the posts live here.

Rebuilding my terminal from a git clone

martinimarcello00 — Tue, 25 Aug 2026 15:27:05 +0000

I spend more hours in a terminal than in any other window, and for years the configuration behind it lived nowhere: a .zshrc I had edited so many times I no longer knew which line did what, a colour scheme picked in a preferences dialog, an SSH config that only existed on one laptop.

What follows is what that turned into. Not a list of everything installed on my Mac, but the terminal I actually type in and the two-part trick that keeps it reproducible: every setting is a plain-text file, and every plain-text file is in a repository.

The terminal: Ghostty

I moved off iTerm2 because I wanted a terminal that was fast and, more importantly, one whose entire appearance I could describe in text.

Ghostty — A fast terminal with no tabs of its own to manage.

Native on macOS, GPU-accelerated, and quick enough that a long build log scrolls without the fan spinning up. The configuration is a single plain-text file with one setting per line, which means the whole appearance of my terminal is a handful of lines in my dotfiles rather than a screenshot of a preferences pane I would have to redo on the next machine.

Ghostty's config is a single file, ~/.config/ghostty/config.ghostty, with key = value on each line and # for comments. That is the whole format:

theme = dracula
font-family = "MesloLGS NF"
font-size = 14
window-padding-x = 8
window-padding-y = 6
macos-option-as-alt = true
copy-on-select = true

The interesting part is theme. A Ghostty theme is just another config file, so any file dropped in ~/.config/ghostty/themes/ can be selected by name. Mine is Dracula and starts like this:

palette = 0=#21222c
palette = 1=#ff5555
palette = 2=#50fa7b
background = #282a36
foreground = #f8f8f2
cursor-color = #f8f8f2
selection-background = #44475a

Sixteen palette entries and a handful of colours: that is the difference between "my terminal looks right" and "my terminal looked right on the old machine". cmd+shift+, reloads the config without restarting, so tuning it is a live loop rather than a quit-and-relaunch cycle.

The shell: zsh, Oh My Zsh, Powerlevel10k

macOS ships zsh, Oh My Zsh handles plugin loading, and Powerlevel10k draws the prompt.

Oh My Zsh — A shell that tells me where I am.

Two lines do most of the work in my .zshrc:

ZSH_THEME="powerlevel10k/powerlevel10k"
plugins=(git zsh-syntax-highlighting z fzf-tab)

Those four plugins are the ones that survived. git for the aliases and the branch state, zsh-syntax-highlighting because a command turning red before I press Enter has caught more typos than I would like to admit, z to jump to a directory I visited last week by typing three letters of its name, and fzf-tab to hand tab-completion over to fzf, turning a wall of candidates into a fuzzy-searchable list.

Powerlevel10k is configured with p10k configure once, and the wizard writes ~/.p10k.zsh — which then goes into the dotfiles repo like everything else. Mine runs in nerdfont-v3 mode with the lean prompt, which means the prompt shows the git branch, the Python environment and the exit code of the last command. Most of my terminal mistakes used to be context mistakes: wrong branch, wrong virtualenv, wrong machine.

One detail that is easy to miss: the p10k instant-prompt block has to stay at the very top of .zshrc, above anything that might print or ask for input. It is the reason the prompt appears immediately instead of after the plugins finish loading.

History that is actually searchable

The single biggest upgrade is not the prompt. It is replacing Ctrl-R with something that remembers.

Atuin — Shell history as a searchable database.

Replaces Ctrl-R with a real search over every command I have ever run, recorded with its directory, exit code and duration. History syncs end-to-end encrypted between my laptop and my servers, and you can host the sync server yourself. The obscure ffmpeg invocation from eight months ago is now a two-second lookup.

One line in .zshrc:

eval "$(atuin init zsh)"

After that, every command is recorded in SQLite along with its directory, exit code and duration, and Ctrl-R becomes a real search across all of it — end-to-end encrypted between machines, with a sync server you can host yourself.

The small stuff that adds up

Aliases live in their own file rather than sprawling through .zshrc, sourced at the end:

if [ -f ~/.zsh_aliases ]; then
    source ~/.zsh_aliases
fi

Most of them are unremarkable — gs, ga, gc, gp for git, grep --color=auto, rm -i because I would rather be asked. The ones I actually notice are the navigation shortcuts:

alias .="cd .."
alias ...="cd ../../.."
alias ....="cd ../../../.."

Two more lines worth stealing. micro as the editor, because I want a terminal editor that behaves like every other text field when I am editing a commit message at 11pm:

export EDITOR='micro'
export VISUAL='micro'

And the binding that opens the current command line in that editor, which turns a long unreadable one-liner into something you can actually see:

autoload -U edit-command-line
zle -N edit-command-line
bindkey '^x^e' edit-command-line

Making all of it reproducible

Everything above is text files. The part that makes it a setup rather than a collection is chezmoi.

chezmoi — Dotfiles in git, secrets left out of it.

Keeps my shell, editor and git configuration in one repository and templates the parts that differ per machine, so a work laptop and a home server share a setup without sharing their secrets. Bootstrapping a new machine is a single command instead of an afternoon of copy-paste.

My dotfiles repository maps one-to-one onto my home directory — dot_zshrc becomes ~/.zshrc, dot_config/ghostty/themes/dracula becomes ~/.config/ghostty/themes/dracula — plus three scripts that only run the first time chezmoi is applied on a machine:

one installs Homebrew if missing and runs brew bundle against a Brewfile that carries every formula, cask, App Store app and VS Code extension;
one clones Oh My Zsh, Powerlevel10k, fzf-tab and zsh-syntax-highlighting into the right places;
one applies the macOS defaults I would otherwise click through in System Settings — dark mode, Dock size, Finder path bar, key repeat.

The naming does the work: a file called run_once_install-deps.sh runs once and chezmoi remembers its hash, so applying the dotfiles again does not reinstall Homebrew.

Secrets stay out of the repository

The reason a dotfiles repo usually stops at "shell config" is SSH keys. chezmoi solves that with templates: a managed file can call out to a password manager at apply time. My signing key is a two-line file in the repo that contains no key at all:

{{- (bitwarden "item" "ssh-git-signing").sshKey.privateKey }}

The public keys and ~/.ssh/config are committed as plain files, the private halves are rendered from Bitwarden at apply time and never touch git. The same mechanism fills in per-machine values — my .chezmoi.toml.tmpl pulls a few cloud subscription IDs from a Bitwarden item so the helper scripts in ~/.local/bin know which subscription to talk to without those IDs living in a public repo.

Once the keys are in place, git signs commits with SSH rather than GPG, which is three lines and no keyring:

[user]
    signingkey = ~/.ssh/id_ed25519_signing.pub
[gpg]
    format = ssh
[commit]
    gpgsign = true

A new machine, start to finish

# 1. Homebrew
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# 2. The three tools needed to bootstrap the rest
brew install chezmoi bitwarden-cli gh

# 3. Auth: gh for the private repo, Bitwarden for the secrets
gh auth login && gh auth setup-git
bw login && export BW_SESSION="$(bw unlock --raw)"

# 4. Everything else
chezmoi init --apply gh:<user>/dotfiles
exec zsh

Step two is the whole bootstrap surface: chezmoi, the Bitwarden CLI and the GitHub CLI. Step four clones the repo, installs the Brewfile, applies the macOS defaults and renders every dotfile including the secrets. It takes as long as Homebrew takes.

Day to day it stays out of the way: chezmoi edit ~/.zshrc to change something, chezmoi diff to see what would change, chezmoi apply to commit to it, chezmoi update on the other machine to pull it down.

The part that is still manual

Powerlevel10k needs a Nerd Font, and mine is not in the Brewfile — I installed MesloLGS NF by hand at some point and never went back. So on a fresh machine the prompt comes up with boxes where the icons should be until I fix it, which is exactly the kind of thing this whole setup is supposed to prevent. It is one line:

cask "font-meslo-lg-nerd-font"

Which is a decent summary of how this works in practice. The setup is not finished and never will be; it just gets one line less manual every time something annoys me enough.

See the full toolbox

This one first appeared on my site, where I write about the systems I build and the tools I actually use — the rest of the posts live here.