Am Anfang stand die Idee, einen Blog für unser 6-monatiges Sabbatical zu schreiben. Die Frage war lediglich, wie genau? Ein paar Suchen haben im Wesentlichen folgende Beispiele zu Tage gefördert:

  • Verwenden einer spezifischen App wie etwa Polarsteps, Journi oder FindPenguins. Vorteile: man kann sehr einfach eine Reise unterwegs aufzeichnen, automatisch Fotos zuordnen und das Ergebnis dann mit anderen teilen. Nachteile: man ist dauerhaft von diesen Apps und deren Herstellern abhängig und, schlimmer, die eigenen Daten liegen nur dort. Geht die App oder deren Hersteller vom Netz, ist der Blog weg.
  • Mittels eines Redaktionssystems wie etwa WordPress den Blog selbst erstellen. Vorteile: ein solches Redaktionssystem wird zum Beispiel vom Hoster dieser Site (Strato) standardmäßig angeboten. Diese Redaktionssysteme sind meist OpenSource mit breiter Community so dass es unwahrscheinlich ist, dass sie vom Markt verschwinden. Aber die Daten wären unter eigener Kontrolle, schon mal gut, allerdings meist in einer Datenbank im Format des Redaktionssystems und deshalb schwer zu extrahieren falls das notwendig sein sollte. Weitere Nachteile: man muss sich selbst um alles (GPS Aufzeichnungen darstellen, Fotos zuordnen, Struktur erstellen) kümmern und, nicht ganz so schwerwiegend, man muss online sein um etwas zu schreiben da das Redaktionsystem beim Hoster läuft.

Beides erschien mir nicht so richtig optimal. Also einen Schritt zurück: was sind eigentlich die Anforderungen?

  • Datenhaltung: Die Daten sollen auf jeden Fall unter eigener Kontrolle in einem weit verbreiteten Standardformat blieben. Markdown oder Orgmode wären optimal.
  • Struktur: Die Struktur des Blogs müsste möglichst flexibel sein und eine Möglichkeit zum Tagging und der Suche nach diesen Tags enthalten. Beispielsweise soll ein Beitrag zu einer Wanderung in Frankreich sowohl über “Frankreich”, “Wanderung” oder aber auch chronologisch auffindbar sein.
  • Fotos: Die Beiträge sollen Fotos enthalten können.
  • GPS-Aufzeichnungen: Da wir hauptsächlich Wanderungen unternehmen sollen die GPS-Aufzeichnungen als Karte darstellbar sein.
  • Offline: Es ist nicht damit zu rechnen, dass wir immer online sind, daher sollen die Beiträge offline erstellt werden können. Wenn wir dann wieder online sind sollen die Beiträge veröffentlicht werden.

Die oben genannten Ansätze fallen damit weitestgehend aus. Nach einigen Experimenten bin ich bei diesem Ansatz gelandet:

  • Herz des Ganzen ist Hugo, ein in Go geschriebenes Framework für statische Websites (also solche, die nicht mittels eines Redaktionsystems veränderbar sind).
  • Die Beiträge werden offline in einer Orgmode-Textdatei geschrieben. Dieses Format ist einfacher (zumindest für mich) als Markdown, und ich kann es flüssiger schreiben.
  • Anschließend wird der Text mittels ox-hugo in Markdown umgewandelt.
  • Die Fotos werden in die so erzeugte Verzeichnisstruktur der Markdown-Dateien im Original eingefügt und aus den Markdown-Dateien heraus mittels Gallery Shortcode referenziert.
  • Die GPS-Aufzeichnungen werden in Umap, das auf OpenStreetMap basiert, in eine Karte eingefügt. Diese wird dann mit OpenStreetMap shortcode for hugo in den Text eingebunden.
  • Das verwendete Theme ist Hugo PaperMod.
  • Das Ergebnis, also die offline erzeugte Website, wird mit Rsync zum Hoster synchronisiert.

Damit ich allerdings nicht mein Linux-Notebook sondern nur das iPad auf die Fahrt mitnehmen muss gibt es noch ein paar Komponenten, die zur Ausführung benötigt werden:

  • Die Texte schreibe ich lokal auf dem iPad mit Textastic.
  • Alle Komponenten (Text, Bilder, GPX-Dateien) werden in Git lokal auf dem iPad mit Working Copy verwaltet.
  • Dieses lokale Git Repository wird von Working Copy mit einem Repository auf Codeberg synchronisiert.
  • Zwischen den Hoster (Strato) und das Repository auf Codeberg habe ich einen Build-Server bei Hetzner geschaltet. Dieser hat die Aufgabe, die Orgmode-Dateien in Markdown umzuwandeln, die Bilder zu konvertieren, die Site mit Hugo zu erzeugen und dann mit dem Hoster zu synchronisieren. Der Zugriff auf den Build-Server erfolgt mit ShellFish vom iPad aus, die Inhalte werden mit Git von Codeberg geladen.

Das Ganze ist nicht perfekt, funktioniert bis jetzt aber einwandfrei.