Felix Boers – Blog

Mein Obsidian-System nach über 1000 Notizen

2026-05-08T00:00:00Z

Mein Obsidian-Vault ist mittlerweile über 1000 Notizen groß – Meeting-Protokolle, Trainingspläne, Bewerbungen, gelesene Paper, halbfertige Gedanken. Damit das trotzdem benutzbar bleibt, halte ich mich an ein paar einfache Regeln, die ich hier kurz zeige.

Ein Vault, fast ohne Ordner

Fast alle Notizen landen im selben Ordner: Notes/. Kein Arbeit/, kein Privat/, kein Sport/. Themen-Ordner zwingen jede Notiz in genau eine Schublade, aber die meisten Gedanken gehören eigentlich in mehrere. Statt Ordnern bekommt jede Notiz im Frontmatter ein categories-Feld, das auf eine andere Notiz verlinkt:

---
categories:
  - "[[Meetings]]"
date: 2026-07-01
people:
topics:
---

Eine Notiz kann so auch mehrere Kategorien gleichzeitig tragen – ein Gesprächsprotokoll ist gleichzeitig [[Meetings]] und über das org-Feld einer bestimmten Organisation zugeordnet.

Kategorien statt Hierarchie, dargestellt mit Bases

Jede Kategorie ist selbst eine ganz normale Notiz (Journals.md, Papers.md, Evergreens.md, Trainingsfokus.md, …), die per Bases – Obsidians eingebauter Tabellen-/Datenbank-Ansicht – alle Notizen mit dieser Kategorie live auflistet:

filters:
  and:
    - categories.contains(link("Categories"))
    - '!file.name.contains("Template")'
views:
  - type: table
    name: Table
    sort:
      - property: file.name
        direction: ASC

Damit ist jede Kategorie automatisch eine gefilterte, sortierbare Übersicht, ohne dass ich eine Index-Seite von Hand pflegen muss. Neue Kategorien lege ich über eine eigene Vorlage an, die genau eine solche Base einbettet.

Vorlagen und Automatisierung mit Templater

Neue Notizen entstehen fast nie leer. Templater füllt Frontmatter-Felder wie created automatisch aus – bei manchen Vorlagen benennt es die Datei nach dem Speichern sogar gleich passend um. Aus der Meeting-Vorlage:

## 🎯 Purpose/Objective

## 📝 Notes
-

<%*
await tp.file.rename(tp.file.creation_date("YYYY-MM-DD HHMM") + " Meeting");
%>

Ich muss beim Anlegen also nicht mehr an Datum oder Dateiname denken – ich schreibe direkt los.

Zettelkasten-IDs für flüchtige Gedanken

Für Notizen, bei denen ich beim Anlegen noch nicht weiß, was daraus wird, gilt eine eigene Regel: Das zk-prefixer-Plugin vergibt automatisch einen Zeitstempel als Dateiname (YYYY-MM-DD HHmm), sobald ich eine neue "Unique Note" erstelle. Kein Titel, keine Kategorisierungs-Entscheidung – nur ein Gedanke, schnell festgehalten.

Reift so eine flüchtige Notiz zu etwas Eigenständigem heran, bekommt sie einen echten Titel und die Kategorie [[Evergreens]] – angelehnt an Andy Matuschaks Konzept der Evergreen Notes: Notizen, die ein Thema atomar und dauerhaft festhalten, statt nur ein Gesprächsprotokoll zu sein.

Daily Notes als Eingangstür

Jeder Tag bekommt über das Calendar-Plugin eine eigene Notiz mit Links zum Vor- und zum nächsten Tag sowie einer eingebetteten Base, die alle Notizen zeigt, die an diesem Kalendertag entstanden sind.

Die übrigen Plugins, die den Alltag tragen

Ein paar weitere Plugins, ohne die das System nicht so reibungslos liefe:

obsidian-git – das Vault ist selbst ein Git-Repo und committet sich automatisch, quasi als Backup mit Versionshistorie.
dataview – für Abfragen, die (noch) keine Base sind.
tag-wrangler und note-refactor-obsidian – Tags aufräumen und flüchtige Notizen in atomare Evergreens aufteilen.
darlal-switcher-plus – schneller Sprung zwischen über 1000 Notizen.
obsidian-excalidraw-plugin, drawio-obsidian, obsidian-plantuml – Skizzen und Diagramme direkt in Notizen.
pdf-plus – Paper annotieren, ohne die PDF zu verlassen.

Kein Obsidian-Plugin, aber genauso wichtig: Syncthing hält das Vault zwischen Laptop, Desktop und Handy synchron – direkt Geräte-zu-Geräte, ohne Cloud-Anbieter dazwischen.

Vom Notiz zum Blogpost

Auch dieser Blog fängt in Obsidian an: Eine Notiz mit Kategorie [[Blog Idee]] trägt als Titel schon die Arbeitsüberschrift, dazu ein status-Feld (Idee → im Schreiben → veröffentlicht) und ein leeres channels-Feld für später, falls aus einem Post noch Social- oder Video-Content wird. Der eigentliche Text entsteht aber nicht in Obsidian, sondern direkt hier im Repo als Markdown – ein Copy-Paste-Schritt weniger ist ein Schreib-Widerstand weniger. Dieser Post hier war so eine Notiz.

Wie diese Website gebaut, getestet und veröffentlicht wird

2026-05-03T00:00:00Z

Diese Seite ist bewusst einfach gehalten: eine statisch generierte Website ohne Backend und ohne Client-seitiges JavaScript (abgesehen von den üblichen Drittanbieter-Skripten wie Google Tag Manager und Cookiebot). Hier ist ein kurzer Überblick, wie das Ganze aufgebaut ist.

Templating: 11ty mit Nunjucks

Die Seiten sind einfache HTML-Dateien, die ein gemeinsames Layout erweitern. 11ty (Eleventy) übernimmt das Rendering, Nunjucks liefert die Template-Syntax:

{% extends "layout.html" %}
{% block title %}Blog – Felix Boers{% endblock %}
{% block content %}
<section>...</section>
{% endblock %}

Das Layout definiert Blöcke für Titel, Meta-Tags, Open-Graph-Daten und den eigentlichen Inhalt, sodass jede Seite nur überschreibt, was sie wirklich braucht.

Styling: Tailwind v4 ganz ohne Config-Datei

Seit Version 4 konfiguriert man Tailwind direkt in CSS statt in einer tailwind.config.js. Die Design-Tokens dieser Seite (Farben, Schriftart) stehen in einem @theme-Block:

@theme {
  --color-accent: #4a9edd;
  --color-surface: #161f2e;
  --color-base: #0d1117;
  --font-sans: "Montserrat", ui-sans-serif, system-ui, sans-serif;
}

Diese Tokens tauchen dann als normale Utility-Klassen auf, z. B. text-accent oder bg-surface.

Build: 11ty und Tailwind CLI Hand in Hand

Der Build besteht aus zwei unabhängigen Schritten – Tailwind kompiliert das CSS, 11ty rendert die Seiten – beide schreiben in dasselbe dist/-Verzeichnis:

"build": "rm -rf dist && npm run build:css && npm run build:eleventy",
"build:css": "tailwindcss -i src/styles/main.css -o dist/styles/main.css --minify",
"build:eleventy": "eleventy"

Tests: Playwright und ein selbstgebauter Kontrast-Check

Die Test-Suite läuft mit Playwright gegen einen echten Produktions-Build. Neben Navigation, Links und Inhalten prüft ein selbstgeschriebener WCAG-Kontrast-Test jeden sichtbaren Textknoten gegen seinen tatsächlichen Hintergrund:

function contrast(fg, bg) {
  const l1 = relLuminance(fg);
  const l2 = relLuminance(bg);
  const lighter = Math.max(l1, l2);
  const darker = Math.min(l1, l2);
  return (lighter + 0.05) / (darker + 0.05);
}

So fällt sofort auf, wenn eine neue Farbe (zum Beispiel für das Syntax-Highlighting in diesem Blog) nicht genug Kontrast zum Hintergrund hat.

Deployment: Docker, Gitea Actions und semantic-release

Ein mehrstufiges Dockerfile baut die Seite und liefert sie über nginx aus:

FROM node:24-alpine AS build
WORKDIR /app
COPY . .
RUN npm run build

FROM nginx
COPY --from=build /app/dist /usr/share/nginx/html

Jeder Push auf main läuft durch Tests und Build; basierend auf Conventional Commits ermittelt semantic-release die nächste Version und setzt bei Bedarf einen Git-Tag. Ein Tag-Push löst den Deploy-Workflow aus: Docker-Image bauen, in eine eigene Registry pushen, per SSH auf dem Server den Container neu starten. Ein vorgeschalteter Caddy-Reverse-Proxy kümmert sich um TLS und leitet Anfragen an den Container weiter.

Am Ende ist es ein sehr kleines, aber vollständiges System – und genau der richtige Rahmen, um jetzt auch regelmäßiger zu bloggen.