Eine Ode an die Softwareentwicklung – wir basteln wieder!
-
Tobias Scholze
- 27. Dezember 2022
Die Tage werden kürzer, die Nächte länger und auch sonst beginnt erneut die stade Zeit Einzug in unsere Häuser zu finden. Wie schön wäre jetzt ein spannendes Hobby, welches einem nicht nur Freude, sondern auch noch einen gewissen Mehrwert hervorbringt. In der aktuellen Zeit sollte es möglichst auch ein größeres Loch in das Portemonaie schlagen. Kurzum: Es wird Zeit, dem abwechslungsreichen Zeitvertreib der Softwareentwicklung nachzugehen.
Wir basteln wieder einmal etwas
Auf Dr. Windows haben wir schon viele Basteleien miteinander geteilt. So haben wir nicht nur Home Automation-Sensoren, sondern auch einen Podcast, YouTube Kanal, einen TikTok Account, mehrere Apps für das Surface Duo (DuoBahn, RSSBook, #rTsd, etc.) und vieles weitere in den letzten Jahren gebastelt.
Für diese winterliche Abendbeschäftigung besinne ich mich zurück darauf, wieso ich Nerd, Geek und Softwareentwickler wurde. Etwas bauen, was man braucht, es aber so noch nicht gibt. So etwas zu finden ist im Jahr 2022 nahezu unmöglich geworden, und so schätze ich mich glücklich, zu meinen Wurzeln zurückzukehren.
Der Unterschied zwischen Hobby und damit Geld verdienen
Bei Basteleien habe ich die vollkommene Freiheit. Es macht nur das, was ich will, und nichts anderes? Vollkommen ok! Es geht nur auf Systemen, welche ich nutze? Vollkommen ok! Ich habe einen Monat keine Lust daran zu arbeiten? Vollkommen ok!
Der Großteil meiner Basteleien steht auf GitHub bereit, entweder als Referenz oder anderen eventuell eine Idee zu geben, was man bauen kann. Nichtsdestotrotz ist keines dieser Programme dafür gedacht, außerhalb meiner Rechner zu funktionieren, und ich stelle auch nie Support dafür zur Verfügung. Nicht weil ich böse bin, sondern weil dies nie die Intention dieser Experimente war. Dies gilt auch für das nun folgende.
Kotlog – Kotlin Blogging Helferlein
Ich wollte mein Wasserkopf an Diensten und Servern und überhaupt allem, was Geld kostet, verschlanken. Ein Punkt, wie ich das für mein „Internetpräsenz“ machen konnte, war, auf einen realen Server zu verzichten – auch wenn ich Uberspace beziehungsweise die Ubernauten immer noch sehr als humanistischen Hoster schätze.
Für mich war klar, dass ich hin zu einem „Static Site“-Hoster wie beispielsweise GitHub mit deren Pages, Google Firebase Hosting oder Amazons Amplify wechseln möchte, um erstens Kosten zu senken und zweitens, damit andere sich um Sicherheitsaktualisierungen und Co. kümmern. Dies bedeutete vor allem, dass ich mein fast zwei Dekaden lang geführten Blog von WordPress weg hin zu statisch, also vorgebauten, Seiten migrieren muss.
Am Markt gibt es hierfür eine große Anzahl an Alternativen. Jekyll (Ruby), Hugo (Go), Ghost (JavaScript), Publish (Swift) und noch viele mehr. All diese Programme hatten eines gemeinsam: Sie tun genau das, was ich möchte, sie können jedoch noch sehr viel mehr, was ich nie benötige, und fügen somit wieder einen großen Wasserkopf hinzu, nur diesmal nicht an Kosten, dafür an Komplexität. Was ich wiederum nicht wollte.
Aus diesem Grund entschloss ich mich, auch um einen realen Einsatzzweck für Kotlin zu finden, mir etwas Eigenes zu schreiben, was genau das erbringt, was ich möchte. Nicht mehr und nicht weniger.
Wieso Kotlin?
Eine sehr berechtigte Frage – vor allem da wir uns hier auf einer Microsoft-nahen Community befinden. Die Antwort ist einfach: Microsoft hat mich für C# erst einmal verloren. Mit dem nicht glücklichen Start von MAUI, dessen Plattformunabhängigkeit und in meinen Augen mittlerweile etwas antiquierten Syntax ist C# nach Jahren nicht mehr meine präferierte Wahl für Bastelprojekte. Sehr schade, man sollte sich aber vor allem in der Freizeit zu nichts zwingen, was man nicht wirklich mag.
Etwas ausgeholt muss hier auch angesprochen werden, dass ich anfangs Kotlog in Swift schreiben wollte. Ich bin Senior Software Engineer für iOS und iPadOS und da lag diese Wahl für mich am naheliegendsten. Leider hat nicht nur Microsoft, sondern auch Apple sich in den letzten Jahren nicht mit Ruhm bekleckert. Swift außerhalb von Apple Betriebssystemen oder gar für das Terminal ist beinahe nicht existent und wirkt nicht als „hier fühlt sich die Sprache zu Hause“.
Da ich nun von Berufs wegen in diesem Jahr auch ein Blick Richtung KMM (Kotlin Multiplatform) geworfen habe und das Tooling seitens JetBrains mit IntelliJ und Co in Vergleich zu Xcode oder Visual Studio for Mac eine Offenbarung in Produktivität ist, entschloss ich mich, Kotlin eine Chance zu geben. Somit beschränken wir uns hier vorerst auf GitHub, welches ja mittlerweile zu Microsoft gehört.
Was macht Kotlog?
Kotlog an sich ist eine CLI-Anwendung. Dies bedeutet, dass Kotlog über das Terminal aufgerufen wird und ermöglicht entweder einen neuen Blogbeitrag zu schreiben oder Änderungen Richtung GitHub zu transferieren, wo schlussendlich dann die erstellte html-Seite via Browser aufgerufen werden kann.
#1 Beitrag erstellen
Mittels dem Kommando kotlog -c ‚Das ist mein neuer Beitrag‘ erstellt Kotlog anhand einer Vorlage eine Markdown-Datei mit vorgefertigtem Inhalt, welcher dann mit dem eigentlichen Inhalt erweitert werden soll. Hierzu stehen alle Markdown-Tags zur Verfügung, welche in der „GitHub Flavored Markdown“ (GFM) Spezifikation enthalten sind. Um Meta-Informationen im *.md-File zu hinterlegen, nutzt Kotlog „Frontmatter“, welches beispielsweise aus Jekyll bereits bekannt ist und oberhalb des eigentlichen Inhalts hinterlegt wird.
Kotlog an sich bietet keine Möglichkeit, direkt Assets wie Bilder zu hinterlegen. Diese können jedoch händisch im entsprechenden Ordner von Kotlog abgelegt und mittels der entsprechen Tags im Beitrag eingebunden werden. Diese menschenlesbaren Dateien sind die eigentliche Datenbank des Blogs. Alles basiert auf diesem Format. Da es einfach zu parsen ist, wäre auch eine Erweiterung von Kotlog mit einer grafischen Oberfläche denkbar.
#2 Blog erstellen
Nachdem alles erstellt ist, kann nun der Blog an sich gerendert werden. In diesem Schritt werden sowohl alle Markdown-Dateien eingelesen und in html-Artikel umgewandelt, als auch in eine Listenansicht aller Beiträge – die index.html, sowie eine Feed-Datei und, für mich sehr wichtig, zu jedem Beitrag werden auch Social Media Preview Images erstellt.
Social Media Preview Images sind für mich deswegen wichtig, da ich die meisten Beiträge auf Plattformen wie Twitter oder LinkedIn teile und dort immer eine grafische Repräsentation des Beitrages ebenfalls angezeigt wird. Da ich dies nicht irgendwelchen Automatismen überlassen möchte, erstelle ich in diesem Schritt pro erstellten html-Datei auch noch ein entsprechendes *.png Bild.
#3 Blog bereitstellen
Kotlog kann natürlich auch dann den Blog hochladen. Dies ist technisch gesehen eine Kombination aus einem git commit und einem git push. Auf Seiten von GitHub starten im Anschluss Actions, um diese als „Pages“ zur Verfügung zu stellen.
Das Resultat
Schlussendlich ist nun der erstelle Markdown-Beitrag so umgewandelt und zu GitHub hochgeladen, dass dieser für jedermann aus dem Web aufrufbar ist. In meinem Falle unter tscholze.github.io/blog. Ganz ohne Kosten und verstecke Komplexität. Durch die simple Kombination aus Markdown und Frontmatter bin ich auch in keinem Vendor-Lock gefangen, falls ich wieder zu etwas anderem wechseln wollen würde, sondern habe alle Daten meiner Beiträge leicht maschinenlesbar immer vor mir liegen.
Das dies nicht für alle zufriedenstellend ist, war und bleibt mir immer bewusst, nur manchmal ist die Meinung anderer einfach auch einmal egal. Es geht um Spaß und am Ende etwas sinnvolles gemacht zu haben. Dass dabei noch eine Menge gelernt wurde, ist ebenso ein schöner Nebeneffekt der Softwarebastlerei.
Was kann Kotlog nicht?
Alles andere. Es kann sprichwörtlich nur das, was es können muss und oberhalb aufgeführt ist. Kotlog ist nicht einmal multiplattform, da es auf Bash-Befehlen beruht und somit unter anderem nicht in einer PowerShell-Umgebung ausführbar ist. Es ist nicht größer konfigurierbar als das, was ich es benötige. Kotlog ist simpel, stabil und erlaubt mir auch in Zukunft weiter daran zu werkeln.
Ein Beispiel hierfür ist der Feed. Er ist mit Absicht nicht „WordPress“-kompatibel, da ich erstens kein XML-Feed wollte und zweites, damit es in anderen Apps, welche ich eventuell in ferner Zukunft plane, Informationen von meinem Blog einfach konsumieren kann. Im Sinne von DSGVO und dem Google-Font Problem könnte es – wenn ich es denn in einem kommerziellen Einsatz hätte – unter Umständen auch für Probleme sorgen.
Gebaut auf den Schultern von Giganten
Dies alles soll nicht darüber hinwegtäuschen, dass die eigentliche Arbeit andere geleistet haben. Ich nutze – anders als in meinem Dayjob – eine Menge an Abhängigkeiten, um Dinge nicht selbst zu schreiben. So holte mich mir das Terminalbefehl, Markdown und Frontmatter einlesen oder beispielsweise auch das Erstellen der JSON-Datei so einfach ins Boot, ohne das Rad neu zu erfinden. Eine Liste aller verwendeten Abhängigkeiten findet ihr entweder in der Präsentation weiter unten oder direkt im Repository von Kotlog.
Da ich jegliche Art von Webentwicklung verabscheue, verzichtete ich auf jegliche Art von JavaScript. Allerdings kam ich nicht um eine gewisse Darstellung herum. Hierzu nutze ich so genannte „Drop-in-CSS“-Styles. Also von erfahrenen Entwicklern erstellte CSS-Dateien, welche aber nur auf den klassischen DOM-Tags arbeiten und somit keine Klassen oder IDs benötigen. Neben reinem Code hatte ich auch sehr viel Hilfe bei meinen ersten Schritten mit Kotlin in einer kleinen, aber feinen Community zum Kotlin Webframework „Kobweb“. Im englischsprachigen Discord wurde mir immer wieder weitergeholfen. Schaut gerne einmal vorbei.
Diese Hilfestellungen als Gesten von erfahrenen Entwicklern machen für mich die Würze im Communityleben aus und treiben mich auch an, Artikel wie diese zu schreiben.
Fazit: Ich liebe es, ein Nerd zu sein
Die Entwicklung von Kotlog hat mir wieder gezeigt, dass ich es liebe, ein Nerd zu sein. Es gibt etwas nicht, was ich brauche? Na, dann schreib ich es einfach! Auch wenn es nicht perfekt ist, es tut genau, was ich möchte. Dr. Frankenstein würde wohl sagen: „Es lebt!“
Was war das Letzte, was ihr gebaut habt? Egal ob Software, Hardware, 3D- Druck oder Schreinerei und Co. Auf was seid ihr stolz, es erschaffen zu haben?
Mehr Informationen
Zum Thema Kotlog und wie ich es aufgezogen habe, fand ein interner Talk meines Arbeitgebers statt. Die hierfür erstellten, mehr auf Technik fokussierenden, Folien findet ihr hier.
Thema:
- Entwicklung
Über den Autor
Tobias Scholze
Bayrischer Open Source- und Community-Enthusiast, Verfechter des neuen Microsoft und Wandler zwischen den Betriebssystemwelten. #communityrocks Von Herzen ein Nerd mit der festen Überzeugung, dass man gemeinsam und durch den Einsatz von moderner IT die Welt für jeden ein Stückchen besser machen kann.
