Gerade habe ich auf Github ein neues Projekt veröffentlicht: FiLaMr /fi-la-mar/. Es enthält einen rein HTML/JS-basierten Markdown Editor, der komplett in Form einer KI-unterstützen Anwendungsentwicklung entstanden ist, und der ursprünglich aus den folgenden Bedürfnissen entsprungen war:
Warum ein Markdown Editor
Markdown (MD) gewinnt für mich immer mehr an Bedeutung, da es zum einem im Umgang mit KI-Systemen sehr wichtig geworden ist. So haben wir kürzlich einen eKVV Datenexport in diesem Format entwickelt mit dem Ziel diese Daten direkt in Sprachmodelle geben zu können. Auch die Antworten der Sprachmodelle sind heute in MD und wenn man sie weiterverwenden will, dann hat man dieses Format als Ausgangspunkt.
Zugleich hat der an der Uni genutzte Sync-and-Share-Dienst Sciebo im Zuge der Umstellung auf Nextcloud die Option bekommen, direkt in der Weboberfläche Markdown Dateien erstellen und bearbeiten zu können. Für mich, der ich gewohnt bin Google Drive Dokumente mehrmals am Tag auf mehreren Rechnern blitzschnell zu öffnen und zu bearbeiten, ein echtes Geschenk, denn die Bearbeitung von Word oder Open Office Dokumenten im Webbrowser geht zwar, ist aber quälend langsam und für meine regulären Bedürfnisse an Inhaltsstruktur völlig überfrachtet. So geht es mir auch mit Word und dem Open Office Pendant auf dem Desktop.
Markdown hat noch den großen Vorteil keinerlei proprietäre Software zu brauchen um es zu betrachten. Eigentlich braucht es überhaupt keine Software, zur Not kann ich mir den Inhalt mit cat auf der Kommandozeile ausgeben lassen. Und selbst Microsoft hat seinem ollen Notepad Editor unter Windows 11 offenbar einen Markdown Betrachter spendiert.
Endlich Markdown, aber man ist ja nicht allein auf der Welt
So weit, so gut also? Leider nein, denn Markdown ist weit davon entfernt das Standard Dateiformat zu sein, mit dem man sich unter Kolleg*innen austauscht. Hier dominiert weiterhin die Office Welt und manche Dinge sind mit Markdown auch schlicht nicht schön zu lösen, wie zum Beispiel Anmerkungen und Kommentare, wenn man in einer Gruppe an einem Text arbeitet.
Und manchmal braucht man die Dokumente einfach im Word- oder PDF-Format für weitere Prozesse weil ‚es einfach so ist‘. Hier hatte das schöne MD-Tool in Sciebo für mich eine Schwäche: Ich habe keinen für mich regelmäßig mit vernünftigem Aufwand gangbaren Weg gefunden, wie ich aus dem Sciebo Tool diese Formate erzeugen konnte. Und es fehlte mir auch noch ein MD Betrachter oder Editor für den eigenen Rechner.
Warum noch ein Markdown Editor
Da Markdown ein so einfaches und offenes Format ist gibt es Betrachter und Editoren wie Sand am Meer. Warum also selbst etwas bauen? Das kann ich im wesentlichen diese Gründe anführen:
- Sicherheitsfragen: Wenn ich mir auf meinen Rechner eine Software lade, selbst wenn sie auf Github viele Sterne hat, gibt es immer das Risiko sich hier etwas ins Haus zu holen, dass unerwünschte Dinge tut. Das Risiko mag klein sein, aber es sorgt für ein gewisses Unwohlsein bei mir
- Der Webbrowser sollte die Laufzeitumgebung sein: Er läuft sowieso die ganze Zeit, bringt Sicherheitsfunktionen mit, als Webentwickler liegt mir diese Plattform und in einem anderen Projekt hatte ich bereits EasyMDE als webbasierten MD Editor eingebunden
- Exportmöglichkeiten: Das Tool soll es mir einfach machen die Vorarbeiten im Markdown Format dann in Word fortzusetzen oder den aktuellen Stand als PDF zu verschicken
- Lust am Vibe Coding: Seit den ersten Gehversuchen hat sich das sogn. Vibe Coding für mich zu einer Standardvorgehensweise entwickelt, über die ich nochmal separat schreiben werde. Und so habe ich zunächst in BIKI mit diesem Prompt angefangen:
Ich brauche eine HTML Anwendung, die ich lokal auf meinem Rechner ausführen kann, und die mir bei der Anzeige und bei der Bearbeitung von Markdown Inhalten hilft. Sie soll mir diese Funktionen bieten:
* Ich möchte ein Bearbeitungsfeld für den Markdown Inhalt haben, welches im Webbrowser auf Basis des Pakets EasyMDE arbeitet
* Die Anwendung soll schlank sein und jenseits des Eingabefelds nicht viele UI Elemente haben. Aber das Design soll etwas technisch wirken, so wie ich als Informatiker es mag
* Ich möchte in der Lage sein eine Markdown Datei (Endung .md) in den Editor zu laden
* Ich möchte in der Lage sein den aktuellen Inhalt in einer Datei zu speichern, und dabei Speicherort und Dateiname festlegen könnenHast Du dazu Fragen?
Eine Schwäche von BIKI ist es aber aktuell, dass es nicht auf das Internet zugreifen kann, was für die Einbindung aktueller Pakete wichtig war. So bin ich dann zu Antigravity gewechselt und habe das Projekt dort finalisiert:
Das war schon vor einigen Wochen und für mich ist das Tool inzwischen das Mittel der Wahl, wenn ich Markdown betrachten oder bearbeiten will:
- Es ist schnell, da es nur aus einer überschaubaren HTML Datei besteht
- Es löst meine Probleme mit den Exports in andere Formate und kann in der letzten Version umgekehrt auch aus Webseiten oder Word übernommene Inhalte meist mit der kompletten Struktur übernehmen
- Es ist offline-fähig, da die externen Abhängigkeiten im Cache bleiben
- Es hat nur die Features, die mir wichtig sind, und ist damit nicht überladen
- Ich weiß, was es genau tut und das keine Daten meinen Rechner verlassen
Da es Interesse von Kolleginnen und Kollegen daran gab habe ich es nun auf Github veröffentlicht, damit lässt sich die Anwendung auch ohne Download aufrufen und bleibt automatisch aktuell:
https://ihbrune.github.io/FiLaMr
Alles Vibe Coding
Ich habe bei dieser Anwendung nach meiner Erinnerung wirklich keine einzige Zeile Code angefasst. Selbst die im Repository enthaltenen Dokumente (README, INFO) sind von den in Antigravity verfügbaren Modellen nach meinen Vorgaben erstellt worden.
Der Prozess war nicht fehlerfrei, neben der Aufgabe der KI möglichst gut zu beschreiben was ich haben will, bestand ein guter Teil meiner Aufgabe drin zu testen und auf Probleme hinzuweisen.
Lehrreich war auch das Ergebnis des Prompts, welches ich in Vorbereitung auf die Veröffentlichung gestellt habe:
Ich möchte dieses Projekt als Open Source Projekt auf Github veröffentlichen. Bitte mache eine kritische Betrachtung der Codebasis: Ist sie reif für eine Veröffentlichung? Sind die Abhängigkeiten auf dem aktuellsten Stand? Sind noch Sicherheitsprobleme vorhanden, die wir vorher beheben sollten? Ist der Code sauber strukturiert und in ausreichendem Umfang kommentiert?
Hier habe ich auch einen Wechsel von den sonst von mir meist bevorzugten Anthropic Modellen auf Gemini Flash 3.7 im High Thinking Modus gemacht und da kam wirklich nochmal eine ganze Menge an Punkten heraus, die entweder inkonsistent, halbgar oder in Sicherheitshinsicht noch nicht zu Ende gedacht waren. Für den Einsatz nur durch mich auf meinen eigenen Rechnern hätte es wohl auch so gereicht, aber nun hat der Code eine deutlich bessere Qualität.
PS
Wofür FiLaMr steht wird in der Github Seite erläutert. Es ist heute nicht so einfach ein Kurzwort zu finden, welches nicht schon dutzendfach verwendet wird 😏
