Qualitätsprodukt Vereinheitlichung von Businesslogik durch serverseitiges JavaScript

Liberating my blog :)

Published on Tuesday, April 26, 2016 3:45:57 PM UTC in Announcements

Mit so einer Blog-Software aus der Konservendose verhält es sich ja wie mit der Heizungsanlage im Keller: solange sie im Hintergrund werkelt und ihre Arbeit verrichtet, verschwendet niemand auch nur einen Gedanken daran. Aber wehe, das Ding macht Zicken: dann muss schnell gehandelt werden, auch wenn man leider überhaupt keine Kenntnisse der Funktionsweise und potenziellen Probleme besitzt...

Ein Beispiel für den Bedarf nach Aufmerksamkeit ist, wenn die Software ein Update erbetteln will. Neuerdings kann man diesen Prozess bei BlogEngine.NET direkt aus dem Dashboard heraus vornehmen, sofern man mutig genug ist, die Warnungen in den Wind zu schlagen und die entsprechenden Schaltflächen mit Nachdruck zu beklickern (auf der Webseite, die die Features verkauft, klingt das bei weitem nicht so gefährlich wie es im Backend formuliert ist, ehrlich gesagt). Da ich ein vollständiges Backup zur Hand hatte, wagte ich das kurzerhand und wartete der Dinge, die da kommen mögen. Nach wenigen Minuten war das Update durchgelaufen und, augenscheinlich, die Seite wieder in Betrieb wie zuvor. Lediglich das Suchen-Widget widersetzte sich Gallier-gleich beharrlich jeglichen Versuchen, es zur Zusammenarbeit zu überreden. Tatsächlich war ich nicht der einzige mit diesem Problem, das seit Dezember wohl ungelöst scheint. Auch ich musste erst manuell das Zip-Archiv mit der aktuellen Version herunterladen, entpacken, und schließlich die Dateien händisch hochladen, die beim Update vergessen(?) wurden.

Ebenfalls nicht besonders vertrauenserweckend ist die Tatsache, dass im Backend noch immer angezeigt wird, es stünde ein Update der Software zur Verfügung. Beim Anstoßen desselben erscheint dann nämlich die Versicherung, dass man völlig up to date sei. Vielleicht ist das ein Seiteneffekt des eilig nachgeschobenenen Sicherheitsupdates, das nachträglich auch ins Hauptpaket integriert wurde. Eventuell verschluckt sich der Update-Check daran? Lustig ist auch, dass im schönen, neu gestalteten Dashboard direkt manche Funktionen kaputt sind; so kann man zwar die Titel der News auf DotNetBlogengine.net lesen, beim Anlicken führen die Links aber ins Nirvana. Der Online-Editor, für mich eigentlich das wichtigste Bauteil an so einer Software, ist gelinde gesagt... verbesserungswürdig, und zumindest in Chrome in weiten Teilen (layout-technisch) kaputt und zwar hübsche, aber nichtssagende rote Fehler-Popups ausspuckend. Änderungen in der Code-Ansicht gehen stillschweigend verloren, wenn man diese vorm Speichern nicht wieder schließt. Nunja. Ist eben erst Version 3.2.

Sicherheitslücken? Updateprozess fehlerhaft? Kaputte Funktionalität? "Da hätte ich es ja gleich selbst machen können", wird sich so mancher jetzt denken :). Tatsächlich spiele ich schon seit geraumer Zeit mit dem Gedanken, mich unabhängig zu machen von Dritthersteller-Produkten und eine eigene Seite zu erstellen. Nicht etwa weil ich glaube, dass ich es besser könnte als andere, wohl aber aus diversen anderen Überlegungen heraus:

  • Die Grundinstallation ohne eigene Daten von BlogEngine.NET kommt mit >1700 Dateien und diversen Frameworks bis hin zu einem vollständigen AngularJS daher. Diese Zahl kann natürlich den typischen Node-Entwickler, bei dem für eine Hello World-Anwendung schon mehrere Milliarden Dateien im node_modules-Ordner landen, nicht schrecken - mich aber schon.
  • Natürlich kommen die vielen Dateien (auch) von den vielen Funktionen. Aber... brauche ich die? Unterstützung für verschiedene Datenbanken, mehrere Blogs und Autoren, Newsletter und Visitor Info und und und... ich halte es da immer mit dem Motto: bei viel Schnick-Schnack kann auch viel kaputt gehen.
  • Seit Jahren investiere ich regelmäßig Zeit in die Updates der Software. Und noch jedes einzelne Mal gab es dabei größere und kleinere Probleme, die mich stets dazu gezwungen haben, den Netzwerkverkehr anzusehen, Quelltext zu lesen und zu verstehen und manuelle Nachbesserungen vorzunehmen - teilweise stundenlang. Die Zeit hätte ich auch in ein eigenes Projekt investieren können. Klar, das ist auch mühsam, aber immerhin ist es dann mein eigener Schrott, den ich verstehen und nachbessern muss :), und ich lerne noch was dabei. Außerdem bin ich dann nicht an einen externen Update-Zyklus gebunden, der vom irrationalen Drang nach immer mehr Features getrieben ist, dem man aber gezwungenermaßen nachgeben muss - wer weiß schon, was in alten Versionen noch an (Sicherheits-)Problemen schlummert.

Der größte Dorn im Auge aber ist mir seit langem das liderliche Ablageformat des Contents: HTML. Zwar sind WYSIWYG-Editoren wie Live Writer (bzw. inzwischen Open Live Writer) mittlerweile recht clever. Aber wehe, man benutzt je nach Situation unterschiedliche Editoren und ggfs. auch mal das Web-Frontend zum Bearbeiten von Einträgen. Da werden je nach Philosophie mal Paragraph-Tags, mal Div-Tags verwendet, und manchmal auch gar keine, sondern lediglich Zeilenumbrüche. Schon hat man subtile strukturelle Unterschiede, die sich ggfs. auch auf die optische Formatierung auswirken. Je komplexer der Inhalt, desto schwieriger auch der Umgang damit. Im Lauf der letzten Jahre habe ich beispielsweise mehrfach den Syntax Highlighter gewechselt, was stets einem unangenehmen Abenteuer gleichkommt. Je nach Framework müssen verschiedene Strukturen oder CSS-Klassen eingehalten werden, womit man zwangsläufig entscheiden muss, ob man beispielsweise auf immer und ewig alten Code (z.B. Styles) in seiner Installation belassen möchte (den man streng genommen auch bei jedem Update migrieren und prüfen muss), oder ob eben alte Artikel einfach nicht mehr richtig dargestellt werden. Wehe auch dem, der die Inline-Style-Option mancher Highlighter verwendet hat (wie ich eine Zeit lang), was sich natürlich überhaupt nicht mehr ändern oder sauber auflösen lässt.

Ich denke also schon längere Zeit über Alternativen nach und beobachte andere Sprachen und Ansätze (wie statische Generatoren u.ä.) sehr genau. Immer wieder lande ich dabei bei Markdown, das inzwischen eine wirklich weite Verbreitung hat. Mit CommonMark ist auch zum ersten Mal eine Spezifikation (mit wunderbarer .NET-Implementierung) verfügbar, die nicht bei lächerlichsten syntaktischen Anforderungen in sich zusammenbricht (wie alles andere, was ich dazu bisher angesehen habe). Dennoch ist der Funktionsumfang von Markdown immer noch derart gering, dass man um eine manuelle Vor- oder Nachbehandlung des Inhalts nicht herumkommt, oder aber doch einen der abweichenden "Flavors" nutzen muss, die sich am Markt tummeln und fehlende Features nachrüsten. Beispielsweise nutze ich sehr gerne Stilmittel wie durchgestrichenen Text, an dem die Referenzimplementierung schon mangels Definition in der Spezifikation scheitert.

Dennoch: das letzte Update-Erlebnis, der Wunsch nach wieder mehr Aktivität hier im Blog und ein, zwei andere äußere Umstände haben mich davon überzeugt, das Projekt nun endlich anzugehen. Ideen dazu schwirren mir schon seit Jahren durch den Kopf. Das ein oder andere werde ich dazu hier festhalten; vielleicht ist es ja auch für andere interessant.

Tags: Blog · BlogEngine.NET