28

Feb

2015

Der Lehmlawine-Blog im Wandel


6℃, bewölkt


Ein kurzes Vorwort: Dieser Blogeintrag ist technischer Natur und beinhaltet keinerlei Bautipps oder sonstige Informationen zur Sanierung eines Fachwerk-Hauses. Es wurd versucht, die sehr technischen Details weitesgehend zu abstrahieren und so zu erklären, dass auch diejenigen, die nicht vom Fach sind, die Zusammenhänge verstehen können.

Ich hoffe, es findet interessierte Leser!

Die Baudokumentation begann mit Fotos

Ein unveröffentliches Foto aus dem ersten Jahr

Als wir 2008 mit den Baumaßnahmen am Haus begannen, da wurde sehr schnell klar, dass der Prozess irgendwie dokumentiert werden müsste. Schnell war die Kamera gezückt und fortan wurden regelmäßig Fotos von der Baustelle geschossen. Selbstverständlich reichte uns das, weil wir wussten ja immerhin, was auf der Baustelle geschah.

Es dauerte nicht lange, da wurden die ersten Stimmen aus der Verwandschaft bzw. dem Bekanntschaftskreis laut. "Wie läuft's?", "Wann ist die Einweihungsfeier?" und "Schickt doch mal Bilder". Also wurden die ersten Fotos verschickt und dann hörten wir Stille, gefolgt von dem tösenden Geschrei: "Riesenprojekt!", "Das bekommt ihr nie hin!", "Reißt die Bude ab!", "Lebensaufgabe!" und dergleichen. Wenn wir einen Euro für jedes Mal bekommen hätten, an dem uns jemand empfahl, das Haus dem Erdboden gleich zu machen, dann hätten wir die Sanierungskosten schnell gedeckt bekommen.

Was uns (überwiegend mir) aber auch schnell klar wurde, war, dass es Menschen gab, die das Thema interessierte, welche aber nichts mit den – aus dem Kontext des Gesamtbauvorhabens gerissenen – Fotos anfangen konnten. Heute waren wir dort am Abreißen, morgen an einer anderen Stelle am Aufbauen. Ohne Text würde da niemand den roten Faden finden können.

Den Baufortschritt bloggen, aber wie?

Obwohl ich mich bis dato dagegen gewehrt hatte, etwas im Umfeld von "Social-Media" zu unternehmen (ich zähle das Blogging prinzipiell zu dieser Gattung der Informationsverteilung), sah ich hier einen tatsächlichen Nutzen für Andere. Es war nicht der tausendste Blog zum Thema "Website-Programmierung" oder gar der hunderttausendste zum Thema "einen Spiele-PC bauen". Es ging um etwas Handfestes und darum, meine Erfahrungen schonungslos ehrlich und mit allen Höhen und Tiefen zu vermitteln, damit Andere ihre ganz persönliche Wahrheit finden und den Blick auf ihr Bauwerk erweitern könnten.

Daher werden hier auch keine Fehler vertuscht, sondern offen dargestellt.

So hatte ich den inneren Kampf mit mir geführt und die Entscheidung war gefallen einen (weiteren) Blog ins Internet-Leben zu rufen - es sollte mein erster sein. Die Suche nach der Software konnte beginnen. Es sollte einfach sein und schnell gehen, da ich keine Zeit haben würde selbst etwas zu programmieren. Also schaute ich mich um und stellte fest, dass ich keine Lust hatte, eine der vielen freien Dienste in Anspruch zu nehmen. Ich mag Daten und ich liebe saubere Daten. Es gibt wenig, dass ich mehr verabscheue als proprietäre Datenformate und meine Daten bei irgendjemandem abzulegen, dessen Verwaltungsstruktur ich nicht kenne. Das ist für Menschen ohne Computeraffinität schwer verständlich aber es geht im Wesentlich um die Fragen:

  1. Wo liegen meine Daten?
  2. In welchem Format kann ich sie dort extrahieren um sie wieder bei mir zu haben?

Im Zeitalter von 'kostenlosen' Blogs und 'Cloud-Storage' erscheint diese Denkweise stark veraltert aber das macht nichts, weil ich weiß wo mein Handtuch meine Fotos und meine geschriebenen Texte sind.

Als nächstes kam die Alternative auf, eine vorhandene Software auf meinem Internet-Server zu installieren um dann dort den Blog aufzuziehen. Allerdings ist es utopisch zu glauben, dass man andere Software 'einfach' oder gar 'schnell' verstehen und verwenden könne. Ich rede hier nicht von der simplistischen Desktop-Software, sondern von Kommandozeilen-Programmen die Rechte haben wollen, Verzeichnisse oder Datenbanken als Ablage benötigen und zusätzlich noch in weitere Software wie z.B. den Webserver oder sonstige Dienste integriert werden möchten. Da geht nichts 'schnell' und die Lernkurve kann von Produkt zu Produkt stark variieren. Danach kann man sich noch mit dem Molloch der Wartung / Instandhaltung auseinandersetzen – alles zeitintensiv und die mangelt mir am meisten.

Ich versuchte es mit iWeb von der Apple iLife-Suite, nur um festzustellen, dass es nicht zum Bloggen geeignet war (2008 zumindest noch nicht, ich kenne den jetzigen Stand nicht). Es wurden ein paar Bilderstrecken damit ins Web gepustet, zusammen mit einigen Bildunterschriften und das war's.

Etwas eigenes musste entwickelt werden

Insgesamt musste fast ein Jahr vergehen, bis mir klar wurde, dass ich auch diese Aufgabe selbst würde lösen wollen. Das sage ich bewusst so, weil es ja offensichtlich ist, dass ich gerne selbst die Dinge in die Hand nehme und nicht Anderen überlasse. Es sollte aber möglichst keine Arbeit machen, also zurrte ich an einem Wochenende und nach der Arbeit ein Perl-Programm zusammen, um eine HTML-Seite nach meinen Ideen zu zaubern. Ein Design gab es nicht aber dafür war die Seite für Suchmaschinen optimiert und schnell – mehr wollte ich nicht.

Im Laufe der Zeit kamen Komfort-Funktionen für mich dazu und bald konnte der Blog meine Fotos automatisch einlesen und für die Webseite auszeichnen. Diese Technik war so erfolgreich, dass ich über lange Zeit hinweg die Google-Bildersuche mit meinen Fotos dominierte (und immer noch tue) – selbst große Hersteller von Beton-Schalungssteinen mussten meinen Blogeinträgen auf der ersten Seite weichen. Klein, leicht und wendig war sie aber es gab auch einige Nachteile, die im Laufe der Zeit begannen zu überwiegen.

Der Blog auf www netrogü de

Es war der alten Fassung des Blogs nicht anzusehen, dass ich Softwareentwickler im Web-Umfeld bin. Abgesehen davon, dass sie syntaktisch korrektes HTML und CSS enthielten, gab es kein Design und keine besonderen Funktionen aber vor allem keinerlei Dynamik. Die Website bestand aus starrem HTML, welches von einem Programm generiert wurde und alles anschließend per rsync (Kopierbefehl) auf den Internet-Server übertragen wurde. Die Navigationsleisten (der Kalender links und die 'vorherige' und 'nächste' Links) wurden per SSI (server side includes) – einer ziemlich alten aber robusten Technik – vom Webserver bei der Auslieferung eingebunden und so verfügbar gemacht.

Gab es einen neuen Eintrag, so war der Workflow folgendermaßen:

  • Fotos auswählen, betiteln und in einen bestimmten Ordner kopieren
  • Blog-Programm aufrufen und die HTML-Seite generieren lassen mit den Fotos
  • Text in das HTML-Grundgerüst schreiben
  • Navigation generieren lassen (das dauerte fortwährend länger mit steigender Anzahl an Blogeinträgen)
  • Alles mittels rsync auf den Internet-Server kopieren

Die Kommentar-Funktion war ein Experiment meinerseits, mich mit der objektorientierten Programmiersprache Smalltalk (Squeak) und dem Web-Framework Seaside auseinanderzusetzen. Mich fasziniert Smalltalk, weil es viele Dinge von Grund auf richtig macht und gleichzeitig eine recht alte Sprache ist. Viele der moderneren Programmiersprachen haben sich an Smalltalk orientiert. Leider war das Experiment nie wirklich erfolgreich und so brauchte ich einige Zeit bis die Kommentar-Funktion stabil lief und selbst dann wollte die Kommunikation zwischen meinem Mailserver und der Smalltalk-VM nicht wirklich rund laufen.

Es wurde Zeit für eine Neuentwicklung.

Die Geburtsstunde der Lehmlawine

Lehmlawine Logo

Annika und ich arbeiten gemeinsam bei einem Zeitschriftenverlag und gestalten (Annika) und programmieren (ich) Teile der Website. Daher lag es auf der Hand, dass wir – nachdem sich unsere neue Beziehung gefestigt hatte – Zeit mit einem Redesign verbringen würden. Annika entwarf daher ein Design für den Blog und wir machten uns gemeinsam Gedanken zu den Anforderungen. Heutzutage ist das Internet voll mit überladenen Seiten an dessen Javascript selbst moderne Rechner ordentlich zu arbeiten haben. Auch leiden viele Seiten an der Überheblichkeit ganz viel darstellen zu wollen ohne den Inhalt in den Mittelpunkt zu rücken. Es ist ein Zerren und Ziehen um die kurze Aufmerksamkeit des Lesers in einer hektischen Welt mit zu viel Information. Das wollten wir nicht.

Es sollte (natürlich) keine Werbung geben. Wenn wir Werbung machen, dann für Bekannte oder Websites die wir für inhaltsrelevant erachten – auch leiden wir nicht so sehr an Geldmangel, dass wir uns die 15 Euro/Monat Unkosten über nervende Werbung finanzieren müssten. Wir wollten auch keine hektischen Inhaltselemente wie blinkende Bilder, abspielende Videos oder sich automatisch ändernde Inhalte. Doch was war uns wichtig? Wo wollten wir hin und was wollten wir aussagen?

Das Design der Lehmlawine in der Entwicklung

Ein altes Haus zu sanieren ist eine lebenslange Aufgabe. Wenn diese Aufgabe zur Last wird, dann ist man mit der Aufgabe überfordert und das sollte nicht sein – es war uns also wichtig den Spaß- und Abenteueraspekt aufzunehmen und zu übermitteln. Eine bekannte und von allen in unserer Familie geliebte Filmfigur stand Pate als Annika sich an das Design machte. Mir war in diesem Zusammenhang der visuelle Aspekt sehr wichtig, weil ich die Fotos für das wichtigste und zentralste Element im Blog erachte. Nicht jeder will unbedingt mein Gefasel zu einem Thema lesen, zumal es meine subjektive Betrachtung einer Sachlage ist und jeder sich seine eigene Wahrheit in dem jeweiligen Kontext konstruieren muss – doch jeder braucht dazu objektive Information und diesem Wunsch kann nichts besser gerecht werden als ein (unretuschiertes) Foto. Obwohl ich diesem Paradigma bereits in der Urfassung des Blogs gefolgt bin (die ersten Einträge sind sehr wortkarg aber immer bebildert), sollte es in der neuen Fassung noch weiter getragen werden und das Foto-Karussell (oben) war geboren. Für die Zukunft sind noch weitere Features zur gezielten Betrachtung der Bilder vorgesehen, ganz besonders seitdem wir die Bildgröße etwas verkleinern mussten um in das neue (Layout-)Format zu passen (aber nur ein wenig).

Die Suche nach der passenden Backend-Technik

Mit dem neuen Layout und den Wünschen nach Veränderung bzw. Vereinfachung beim Erstellen von Blog-Einträgen kam auch der Bedarf nach neuer Technik. Bisher habe ich offline ein HTML-Grundgerüst programmatisch erstellen lassen, dieses mit Text gefüllt und anschließend auf den Server kopiert. Der Server hatte nichts weiter zu tun, als die Anfrage (in Form einer URL) entgegenzunehmen und die entsprechenden Dateien von seiner Festplatte über das Internet an den Browser des geneigten Lesers zu senden. Sehr einfach, sehr robust und sehr schnell. Wollte ich eine Änderung an allen Blogeinträgen gleichzeitig vornehmen (z.B. eine Grafik einfügen oder etwas HTML-Code ändern), so musste ich alle Blogeinträge durchforsten und ändern. In den Anfängen habe ich das noch von Hand gemacht, doch sehr bald musste ein Programm herhalten um die 500+ Beiträge anzupassen – womit letztendlich die Stagnation eintrat. Änderungen waren mühsam und aufwändig, also wurden keine mehr gemacht; so spielt das Leben.

XSLT ein Auszug

Zuerst wollte ich gerne etwas in der Programmiersprache Smalltalk machen, doch die Erfahrungen mit der VM auf meinem Linux-Server brachten schnell Ernüchterung und so schweifte mein Blick in Richtung XML und XSLT. XML kann man als ein Format für die Daten betrachten und XSLT als ein Werkzeug mit dem die XML-Daten in jede andere Form – also auch HTML für den Browser – gebracht werden können. Obwohl ich mit der Umsetzung sehr weit kam, wurde auch klar, dass ich mir damit neue Probleme aufhalsen würde; an erster Stelle behinderte mich meine eigene Unerfahrenheit. Bei jeder kleinen (Blog-)Pause (4+ Wochen) musste ich mich grundlegend in die Materie wieder eindenken und als es mal zu einer längeren Pause kam, gab ich das Vorhaben auf – zu hoch war der kognitive Aufwand den Blog mittels XML/XSLT umzusetzen, neben den bereits vorhandenen Aufgaben. Auch entpuppte sich XSLT als behäbige, unhandliche Übersetzungssprache.

Perl Code ein Auszug

Letztendlich fiel die Entscheidung auf das Werkzeug mit dem wir unser Brot verdienen: Perl und Template-Toolkit. Die Vorteile lagen auf der Hand: Sowohl Annika, als auch ich arbeiteten täglich damit und wussten wie die Probleme anzugehen waren. Neue Erkenntnisse auf der Arbeit würden den Blog befruchten, genauso wie neue Erfahrungen während der Blog-Programmierung auf der Arbeit von Vorteil sein würden. Um es im Manager-Technokratus-Speak zu sagen: Haben-Win-Win-Situation-geschaffen!

Die Krux der Technik-Spirale

Mit der Verwendung einer Templating-Engine (Template Toolkit) holt man sich viele Vorteile ins Projekt:

  • Sich wiederholender HTML-Code braucht nur einmal geschrieben, dafür mehrfach verwendet werden
  • Inhalte können dynamisch angepasst und hinzugefügt werden (auch neue Blogeinträge oder neue Navigationspunkte)
  • Die Struktur der Website wird für die Entwickler übersichtlicher

Allerdings gibt es nicht nur Vorteile, denn mit dem Wunsch nach Dynamik (und das ist oftmals die treibende Kraft hinter der Verwendung einer Templating-Engine), steigt auch der Bedarf an serverseitiger Rechenzeit. Diese Rechenzeit steigt mit der Vielfalt der Inhalte; ein Problem mit welchem wir uns regelmäßig auf unserer Arbeit konfrontiert sehen.

  • Anrisstext, Anrissbild und URL für die Monatsübersichten
  • Welche Einträge gehören zum Monat X?
  • Welcher ist der nächste und welcher der vorherige Eintrag?

Schnell, schneller, 50ms!

Wenn man an diesem Punkt angekommen ist, dann beginnt ein Softwareentwickler für gewöhnlich die möglichst weit aufbereiteten Daten zwischenzuspeichern, um Rechenzeit zu sparen. Meistens wird das salopp als "Caching" bezeichnet und ist eigentlich ein wenig wie Schummeln, weil man damit wunderbar Unzulänglichkeiten im Programm vertuschen kann, indem vieles im unglaublich schnellen Hauptspeicher abgelegt wird. Doch alles hat seine Grenzen, weil der Hauptspeicher begrenzt ist – besonders bei gemieteten, virtuellen Servern.

Eine Form des Caching, die ich nicht als "Schummeln" bezeichnen möchte ist es, das Programm (nicht die Daten) im Hauptspeicher zu halten; es ist dann "persistent". Dadurch wird der Start bzw. das "Hochfahren" der Software auf ein einziges Mal begrenzt. Danach ist es sofort bereit, dem User (Blogleser) zu antworten und es muss nicht bei jeder Anfrage "Zeige mir die Seite mit dem Kalkputz vom 10.08.2013" gestartet, aus der Garage geholt und warmgefahren werden. Diese Zeit kann man sich dadurch sparen, indem der Wagen einfach laufen gelassen wird. Die Analogie hinkt ein wenig, denn was in der Realität eine Umweltsünde wäre, ist in der Welt der Computer gängige Praxis: Das Programm schläft mit laufendem Motor und quasi ohne Spritverbrauch. Praktisch, oder?

Die Antwortzeit des persistenten Perl-Blogs (auf FastCGI-Basis) fiel drastisch auf unter eine Sekunde, doch mittlerweile gab es Datenhalden im Programmspeicher die besser zentral aufgehoben würden anstatt jedes im Speicher laufende Programm damit zu belasten. Man kann es sich wie ein Kalktrupp vorstellen, in dem jeder Arbeiter seine eigene Kalkgrube vorhält. Es wäre sinnvoller, wenn sich alle aus einer Kalkgrube ihren Werkstoff holen würden. In dieser Analogie ist jeder Arbeiter im Trupp ein Programm und die Kalkgrube die Datenhalde. Der Grund für mehrere gleichzeitig laufende Programme ist schnell erklärt: Treffen gleichzeitig mehrere User ein und wollen lesen, so könnte ein Programm die Anfragen nur nacheinander abarbeiten während mehrere Programme parallel die Blogeinträge ausliefern können. Dadurch bekommt der Leser schneller seine Information und wird nicht mit langen Ladezeiten gefrustet.

Diese Datenhalden packen viele Softwareentwickler einfach in eine Datenbank. Datenbanken sind eine feine Sache, weil sie die Daten strukturiert vorhalten und eine einfache Abfrage erlauben. Es gibt gute Gründe für Datenbanken aber die Anforderungen des Blogs ließen sich nicht wirklich mit den Fähigkeiten einer Datenbank in Einklang bringen; es wäre das Schießen mit Kanonenkugeln auf Spatzen gewesen. Stattdessen schwebte mir eine leichtere Lösung vor, die das "böse" Wort Cache bereits in sich trug: Memcache. Diese Software hält prinzipiell Daten im Hauptspeicher vor – sie können gelesen oder verändert werden mit einem Schlüssel, welcher jeden Datensatz (hoffentlich eindeutig) identifiziert. Memcache ist verteufelt schnell…

XML ein Auszug

Nun war ich mit der Software vorerst zufrieden. Die Daten kamen noch immer aus dem Dateisystem (also "von der Platte") und wurden im menschenlesbaren XML-Format vorgehalten (im Gegensatz zu den nicht lesbaren Formaten gängiger Datenbanken). Alle strukturellen Daten wurden beim Programmstart vorberechnet und im Memcache abgelegt. Ein neuer Blogeintrag kann jederzeit hinzugefügt werden ohne das laufende Programm anhalten zu müssen und dauert nur wenige Sekunden – ein Traum, wenn man aus der Welt der Mammut-Business-Software kommt.

Das Beste zum Schluss: Die Auslieferungszeit der Blogsoftware liegt im Mittel über 655 000 Aufrufen bei 0,05 Sekunden pro Abruf eines Blogeintrags. Manchmal langsamer aber meistens schneller.

Es wird laufend an der Software weitergearbeitet, doch das oben genannte Konstrukt stellt den Stand unserer Technik dar bis ich etwas anderes erkläre und dann werde ich es hier auch verlinken ☺.

Ich hoffe, dass der Beitrag interessant war – auch wenn er sich ausnahmsweise nicht mit dem Hausbau befasst hat, und bedanke mich für die Aufmerksamkeit.