Als Chronist in meinem Musikverein ist es meine Aufgabe, die Ereignisse und Termine, ob nun musikalischer Art oder außermusikalischer Art, zeitlich (chronologisch) geordnet niederzuschreiben und einmal im Jahr einen Bericht zu halten.
Um Personen Einblicke in diese Chronik zu geben, und auch, um die Chronik der Nachwelt zu erhalten, wurden anfangs Bücher verwendet, in der die Chronisten handschriftlich ihre Berichte verfassten, und dann noch Bilder oder Zeitungsartikel einklebten.
Mit dem Siegeszug der Personal Computer und der Textverarbeitung ging man dann Ende des 20. Jahrhunderts dazu über, die Berichte am Computer zu schreiben, digitalisierte Bilder einzufügen und dann ein oder mehrere Jahre in Gesamtheit auszudrucken, und als Buch binden zu lassen. Vorbei waren die Zeiten des Tintenkillers und der verklebten Seiten.
So ab 2005 begann ich dann, die Chronik des Musikvereins zu digitalisieren: Es gab kein physikalisches Chronik-Buch mehr, stattdessen war die Chronik ab diesem Zeitpunkt öffentlich einsehbar in einem sogenannten Content-Management-System (CMS) im Internet. Alles ganz praktisch, die einzelnen Ereignisse oder Termine konnte man online als Artikel der Kategorie Vereinschronik verfassen und bei Bedarf ändern, später dann auch noch Fotos hinzufügen. Und die zeitlich geordnete Liste dieser Artikel war dann quasi die Vereinschronik.
Eigentlich doch sehr elegant, oder?
Wir befinden uns im Jahr 2022, rund 17 Jahre Vereinschronik befinden sich im CMS. Das CMS läuft (aus noch unbekannten Gründen) nicht mehr rund, da müsste eigentlich jemand regelmäßig Updates einspielen, auch wegen Security und so, und überhaupt, was ist, wenn mich ein Bus überfährt? Hat jemand überhaupt eine Chance, noch an die Daten zu kommen, oder sind diese 17 Jahre für die Nachwelt verloren?
Wie lange wird es dieses Content Management System (in meinem Fall: Joomla) noch geben?
Und warum kann man keine Videos zu den Berichten hinzufügen? Und warum muss man die Bilder immer manuell auf das Format 640×480 runterskalieren, bevor man sie hochladen kann, wo heutzutage doch eigentlich Bildformate wie 3840×2160 Pixel der Standard sind?
Aber es kommt noch schlimmer: Im Jahr 2005 erschien es noch eine edle und gute Idee, die Vereinschronik allen Interessierten öffentlich bereit zu stellen, um sich ein Bild über den Verein zu machen. Doch die Zeiten änderten sich. Darfst du ohne Genehmigung einen Artikel aus der Online-Ausgabe deiner örtlichen Zeitung übernehmen? Wie ist das mit Bildern aus der Presse? Darfst du bei Ständchen für ein Mitglied den Geburtstag und das Alter des Mitglieds nennen, und vielleicht sogar die Adresse? Und bei selbst aufgenommen Fotos: Ob die Leute auf dem Bild wohl damit einverstanden sind, dass man ihre Bilder öffentlich sieht? Und ich rede noch nicht mal von Kindern …
Kurzum, die öffentliche Online-Chronik war zu einem rechtlichen Minenfeld geworden, und war nur noch für mich selbst online zugänglich. Damit fiel aber auch ein Hauptargument weg, die Chronik in einem CMS zu speichern.
Was im Jahr 2005 als gute Idee erschien, entwickelte sich nach und nach zur Altlast.
Der Schritt war also mehr als überfällig, jetzt (2022) die Berichte und Fotos aus dem Internet wieder auf die lokale Festplatte zu holen, und den Einsatz des CMS generell in Frage zu stellen.
Festplatte heißt in meinem Fall, ein Netzwerkspeicher (NAS) in RAID 1 Konfiguration: Selbst wenn eine Festplatte den Geist aufgibt, sind die Daten noch redundant auf einer zweiten Festplatte. Es gibt keinen Datenverlust.
Aber wie kopieren vom CMS auf die lokale Festplatte? Das sind rund 480 Artikel in den 17 Jahren, das geht nicht manuell! Mein Vorgehen war das folgende:
- Ein Backup der Joomla Datenbank ziehen, und zwar im JSON Format.
- Manuell alle Einträge in der Backup-Datei löschen, die nicht mit mit den eigentlichen Artikeln zu tun hat (Datenbanktabelle Articles).
- Kleines Python Script schreiben, das alle Artikel dieser Backup-Datei nacheinander durchgeht, und dann das Datum im Titel verwendet, um den Dateinamen zu bauen. Dabei Zeichen ersetzen, die in Dateinamen nicht erlaubt sind. Und dann ein Verzeichnis mit diesem Namen auf der Festplatte anlegen.
- In diesem Verzeichnis den eigentlichen Bericht anlegen, mit Dateinamen index.md.
- Ach ja, MD steht für Markdown, eine Auszeichnungssprache für Dokumente, die auch ohne Textverarbeitungsprogramm wie MS Word in einem beliebigen Editor verwendet werden kann. Schnell zu erlernen, und zugegebenermaßen auch eingeschränkt, aber wir wollen ja auch keine Doktorarbeiten schreiben. Auf jeden Fall ist es sehr wahrscheinlich, dass Dateien dieser Art auch in den nächsten 20 Jahren noch gelesen und dargestellt werden können. Bei MS Word wäre ich mir da nicht so sicher.
- Im CMS konnte man HTML Elemente benutzen, um das Dokument zu strukturieren oder einzelne Begriffe hervorzuheben etc. Das konnte ich unmöglich manuell nach Markdown konvertieren. Die Python Bibliothek html2text hat dabei sehr gute Dienste geleistet. Sogar HTML-Tabellen wurden oft in korrekte Markdown-Tabellen konvertiert.
- Wo man gerade schon am konvertieren war, stellte sich die Frage, ob man nicht zu jedem Artikel noch Metadaten speichern will, wie einen Titel, die Namen der Personen, um die es vielleicht im Artikel geht, und den Ort der Veranstaltung.
Es gab verschiedene Optionen, und ich habe mich entschlossen, die Metadaten im Kopf des selben Artikels zu speichern. Das Format nennt sich YAML Front Matter. Das ganze ist (im Laufe der Zeit) beliebig erweiterbar
Fazit:
Die Vereinschronik ist jetzt in einem Format abgelegt, das zwar nicht online bearbeitet werden kann, aber auf jeden Fall die nächsten 50 Jahre übersteht. Eben aus dem Grund, dass die Artikel in ganz einfachen Verzeichnisstrukturen auf der Festplatte abgelegt sind, und als Auszeichnungssprache Markdown verwendet wird.
Die Bildformate sind nicht mehr beschränkt, können beliebig groß sein. Auch Videodateien sind kein Problem mehr.
Der Weg ist offen für neue Features wie Suchfunktionen, ausgefeilten Statistiken sowie vielleicht Gesichtserkennung auf den Bildern mittels KI. Mal schauen …
/i/3333/products/2019-10-20T00%3A35%3A57.784Z-20191019_192224.jpg?1606306133)
espruino.com
2v06 (c) 2019 G.Williams
>
>onInit();
=undefined
["sys get ver\r\n"
] "R"
] "N2483 1.0.5 Oct"
] " 31 2018 15:06:5"
] "2\r\n"
Version: RN2483 1.0.5 Oct 31 2018 15:06:52
["mac reset 868\r\n"
] "o"
] "k\r\n"
["mac set adr on\r\n"
] "o"
] "k\r\n"
["mac set appeui 70B3D57EXXXXXXXX\r\n"
] "o"
] "k\r\n"
["mac set deveui 00022CBFXXXXXXXX\r\n"
] "o"
] "k\r\n"
["mac set appkey 625C109CA95ADA37E9D0EA64XXXXXXXX\r\n"
] "o"
] "k\r\n"
["mac join otaa\r\n"
] "o"
] "k\r\n"
] "a"
] "ccepted\r\n"
Result: accepted
RN2483 go to sleep
["sys sleep 86400000\r\n"
RN2483 sent to sleep
Periodic task started.
RN2483 wake up
] "\u0000"
] "ok\r\n"
["\r\n"
] "inv"
] "alid_param\r\n"
wake up finished
["mac tx uncnf 1 42\r\n"
] "o"
] "k\r\n"
] "m"
] "ac_tx_ok\r\n"
RN2483 go to sleep
["sys sleep 86400000\r\n"
Periodic task done.
>
Wolfgang Klenk 