[an error occurred while processing this directive]

technikum29 

 
 
Letztes Update dieser Datei:
09.01.2008

technikum29 Versionszählung – ein gelungenes Konzept

Die Geschichte der Homepage des Technikmuseums geht bis ins Jahr 2001 zurück. Damals, als das Museum erstmals im World Wide Web unter www.technikmuseum-main-taunus.de erreichbar war (und vermutlich auf diese Weise seinen Namen erhielt), ging die erste Version am 10.04.2001 online. Diese erste Version der Homepage war vermutlich mit Adobe GoLive (o.ä.) erstellt und recht bescheiden im Umfang: Frames, drei Inhaltsseiten. Im September kamen die zwei Detailseiten hinzu. Bis dahin freilich noch kein einziges Bild, abgesehen von dem Design, welches sich die Freiheit nahm, einen Unterordner zu belegen. Die Webspace war vermutlich das kleinste Angebot Stratos zu der Zeit   zu den aus heutiger Sicht knapp erscheinenden Hostingressourcen (vermutlich nur wenige MB Speicherplatz) gesellte sich eine E-Mail-Adresse.

Nach diesem vermuteten Initialereignis verschwimmen die Überlieferungen, deren Rahmen eine Recherche ermöglichen. Ohne Zusammenhang zu Heriberts Homepage kam ich zu dem Buch "Die eigene Homepage erfolgreich gestalten", ein liebevoll ins Detail gehende Buch (2001 erschienen), welches mir die weite Welt des Internets öffnete. Seit dem fand eine rasante Entwicklung statt – ich entwickelte ein halbes ".de.vu-Universum", entdeckte SELFHTML und irgendwie kam es später dazu, dass ich die Pflege der Technikmuseum-Homepage übernehmen musste.

Es kam zu einem umfangreichen Redesign der Webseite, was in Anbetracht meiner damaligen Fähigkeiten natürlich entsprechend ausfiel. Die Website wuchs und wurde mit Bildern angereichert – aus den ehemaligen Überschriften der zwei großen Bereiche wurden nun einzelne Webseiten, die noch heute in der damaligen Struktur vorliegen. Das Hintergrundbild der heutigen Startseite stammt übrigens genau aus dieser Zeit.

Das Wachstum und die Veränderungen der Homepage gingen immer weiter. Die stets statische Homepage wurde recht häufig im Design umgekrempelt, bis sich irgendwann eine framelose Version etablierte, die aber nach wie vor Tabellen zum Layout nutzte (im Nachhinein man merkt den Einfluss des Geistes, der der Webdesing-Szene in der Zeit anhaftete).

Version 4

Mit der "Homepage 4.0" lässt sich erstmals eine Art Versionszählung feststellen. Es gab offensichtlich eine grundlegende Umwälzung der Webseite, das neue Design wurde vermutlich von Grund auf selbst entwickelt. War das Menü zwischenzeitlich z.B. oben gewesen, so befand es sich jetzt wieder links (die Problematik der unzureichenden Browserbreite gab es schon damals). Seit der "4er-Reihe" der Homepage sind sämtliche Ordner- und Dateinamen gleich geblieben. Der grundlegende Aufbau des Designs von damals ähnelt stark dem darauf folgenden Layout der 5er-Reihe.

Der heutigen Zeit überliefert sind 4 Versionen der "Homepage 4": "Homepage 4.0" bis "Homepage 4.3". Bemerkenswert ist auch, dass die Homepage über ein Kontaktformular verfügte, welches von einem auf einem kostenlosen Webhoster gehosteten selbstgeschriebenen PHP-Script ausgewertet wurde.

Version 5.0: Der CHANGELOG beginnt

Mit Version 5 wurde ein Meilenstein gelegt. Das Technikmuseum Main Taunus zieht nun offiziell in ein eigenes Gebäude und nennt sich fortan technikum29, was mit einer großen offiziellen Eröffnung am 05.11.2005 gefeiert wurde.

Allerdings steht schon Anfang 2005 fest: Es wird technikum29 heißen. Mit dem Umzug der Homepage von Strato zu 1und1, wo ein Homepage-Packet über 100MB inklusive ist (der Wechsel zu 1und1 war durch sein DSL-Angebot bedingt, da die ISDN-Einwahl ins Internet sehr teuer wurde), wird ein ganz neues Konzept begonnen. Mit der Entwicklung der Version 5.0 wird die Homepage erstmals dynamisch, da nun SSI zur Verfügung steht – eine Technik, die fortan genutzt wird, um verschiedene Komponenten jeder Seite beim Aufruf aus verschiedenen Dateien zusammenzusetzen. Außerdem werden prinzipielle Standpunkte festgesetzt:

Mit der neuen Homepage wird auch ein neues Konzept eingeführt, um einem sich anbahnenden Problem entgegenzutreten: Das versehentliche Überschreiben gegenseitiger Änderungen an gleichen Dingen ("konkurrierendes Arbeiten"). Eine Datei namens CHANGELOG.txt im Hauptverzeichnis des jeweiligen Homepage-Ordners soll Aufschluss darüber geben, welche Änderungen der vorliegende Ordner seit der letzten offiziellen VERSION erfahren hat. Jeweils beim Hochladen der Homepage tritt eine neue Version in Kraft.

Das Versionierungsschema ist dabei strikt dreiteilig nach dem Schema A.B.C aufgebaut, wobei bei sehr kleinen Edits nur C um eins erhöht werden soll, bei größeren bereits B. Die Änderung der damaligen Hauptversion 5 (=A) war nur in Fällen geplant, indenen eine grundsätzliche Änderung der Denkweise der gesamten Homepage stattfindet. Dazu gab es noch weitere nicht-offizielle Entwicklungsschritte, die aufsteigend nach ALPHA, BETA, etc. gezählt werden. Im Stiele eines RFC wurden diese Regeln in den Dokumenten VERSIONCOUNTING.txt und WHYCOUNTING.txt niedergelegt.

Der CHANGELOG – Segen oder Fluch?

Das Konzept des CHANGELOGs scheiterte so, wie es geplant war, auf voller Länge. Dies lag im Wesentlichen daran, dass Heribert das Ganze ziemlich egal war bzw. er an einer formtreuen Lösung der Versionsproblematik nicht interessiert war. Bis heute hält seine Doktrin an, die Version auf seinem Computer sei Referenzversion, deren Gültigkeit jeder anderen obliege.

Trotzdem setzte ich die Führung der Datei fort – allerdings nicht auf jedem Computer, auf dem eine Kopie der Homepage lag, sondern schon bald (nach nur 5 Monaten) nur noch auf der Homepage. Damit ist die Ursprungsidee de facto einer neuen gewichen: Dem zentralen CHANGELOG, der alle Änderungen dokumentieren sollte, die sich auf der Homepage getan haben. Dadurch, dass Änderungen seitens Heribert alleine nur sehr selten bewerkstelligt werden, lassen sich auch nur selten Kommentare wie "zwischenzeitliche Änderungen Heriberts nicht inbegriffen" feststellen.

Die Problematik, die ständig präsent war, schien kaum lösbar. Zwar gab es verschiedene Lösungsmodelle, um die Homepageentwicklung zu zentralisieren und so die ständige Nötigkeit, alle Computer manuell zu synchronisieren, zu umgehen, doch wurde niemals eine dieser Lösungen verwirklicht. So standen etwa "halbautomatische" Systeme wie ein Synchronisationsprogramm, das inidividuell für dieses Problem geschrieben wäre, zur Debatte; aber auch Netzwerk- oder externe Festplatten waren im Gespräch. Als die perfekte Lösung erschien mir ohnehin ein zentraler Netzwerkserver, auf dem sich eine einzige lokale Homepageinstallation im SVN und als Wiki verwalten ließe.

Letztendlich hielt die elende Problematik bis einschließlich zum Jahre 2008 an, wo die Homepage – immer noch bei Version 5 – nun schon lange über einen gleichberechtigten englischen Teil verfügt, in ihrem Umfang weiter stark gewachsen ist und nun sogar mit Version 5.7 ein weiteres mal komplett neu eingekleidet wurde. Der CHANGELOG hat indes immer den Stand der Dinge angezeigt – mit seiner Hilfe ließ sich beispielsweise überprüfen, ob die Version einer Datei auf der lokalen Homepageinstallation eines Computers aktuell war oder nicht. Außerdem ist der CHANGELOG – trotz der manuellen Pflege, derer er bedarf – ein wahrer Fundus für Recherche nach Änderungen längst vergangener Tage.

Daher lässt sich zweifelsfrei zusammenfassen, dass der CHANGELOG seiner Aufgabe gerecht wird. Akribisch wie ein Logbuch behütet er seit drei Jahren erfolgreich die Homepage des technikum29.

technikum29 in der Gegenwart: Grenzenlose Möglichkeiten

Im Dezember 2007 wurde beschlossen, aufgrund des mittlerweile drei Jahre alten DSL-Vertrages und den seit Jahren fallenden Preisen ein neues Angebot aufzusuchen, zudem die monatliche Traffic-Begrenzung der Homepage, die in den Anfangsjahren in nicht wahrnehmbarer Ferne lag, nun schon fast täglich durchbrochen werden könnte.

Bereits seit 2006 liefen Diskussionen über DSL und Webhosting – ich hatte stets möglichst günstige Webhostingpackete in Erwägung gezogen (um die drei Euro im Monat). Unvermittelt traf mich der Vorschlag eines virtuellen Server, deren Preis mittlerweile bereits mitten im gehobenen Webhosting-Bereich liegt. Mit einem Schlag wurden meine kühnsten Vorstellungen, die ich mir seit Jahren zu machen pflegte, übertroffen.

So kommt es nun, im Jahr 2008, dazu, dass technikum29 auf einen "v-PowerServer" von Strato ziehen wird. Dadurch ergeben sich völlig neue Möglichkeiten.

Auf einmal sind sämtliche Modelle zur Lösung der Versionsproblematik – selbst der unvorstellbar umfangreiche SVN-Server – nur noch eine Frage von Minuten. Ein weiterer Meilenstein im Werdegang der Webpräsenz steht unmittlebar bevor.

Die Zukunft: v6 oder fließender Übergang?

Die unendliche Freiheit eines eigenen Servers stellt einen vom einen Moment zum Nächsten vor Entscheidungen, die zu machen man sich nie geträumt hätte. Sämtliche Möglichkeiten stehen nun zur Verfügung – welchen Weg wird man einschlagen?

Der Königsweg: Das SVN.

Ein SVN (Subversion, eine Art Nachfolger von CVS, dem Content Managing System, also ein RCS, d.h. ein Revision Control System) ist ein Versionsverwaltungssystem, was von Softwareentwicklern für Softwareentwickler gemacht wurde. Ein solches System läuft zentral auf einem Server und ist dafür gedacht, dass mehrere, möglicherweise dutzende oder hunderte von Programmentwicklern gleichzeitig an einem Projekt arbeiten und ständig ihre veränderten Quelltextdateien zum Server schicken oder Kopien von ihm erhalten.
Damit eignet sich ein SVN eigentlich auch vorzüglich, um ein Webseitenprojekt zu hosten. Es würden nie mehr alte Homepageversionen weggeschmissen werden, jederzeit ließen sich verschiedene Versionen vergleichen und jeder könnte unabhängig voneinander an der Homepage arbeiten und seine Änderungen schnell und automatisiert hochladen.

Allerdings hat das ganze einen großen Haken: Es ist nicht DAU-freundlich, sprich es eignet sich nicht für computerunerfahrene Benutzer; genaugenommen ist das System sogar derart komplex, dass man geradezu ein Softwareentwickler sein muss, um damit zurecht zu kommen. Damit trifft es leider allerdings nicht die Vorraussetzungen.

Oder ein Wiki?

Eine Wiki lässt sich am Besten mit nur einem Wort erklären: Wikipedia. Selbstverständlich gibt es die Möglichkeit, ein solches System auch für die technikum29-Homepage einzurichten, mit dem ungeheuren Vorteil, dass das Bearbeiten von Seiten plötzlich kinderleicht wird: Nur noch anmelden, auf bearbeiten klicken und womöglich überhaupt kein kryptisches HTML mehr schreiben zu müssen. Versionskontrolle wird quasi selbstverständlich im Hintergrund betrieben und läuft völlig transparent ab. Damit wäre schließlich die lokale Homepage-Installation überflüssig. Allerdings ist auch dieses Zukunftsbild nur auf den ersten Blick derart rosig.

Auf den zweiten Blick fällt auf, dass man hier sämtliche technische Freiheit und Akkuranz, die man vorher gepflegt hat, zugunsten der Instandhaltung einer mehr oder minder umfangreichen und potentiell langsamen Wiki-Installation aufgibt. Nicht mehr viel Spielraum, an einzelnen Seiten rumzuschrauben; außerdem keine Möglichkeit mehr für das Testen von Bearbeitungen – alles ist gleich online. Die einzige Bearbeitungsmöglichkeit ist nur noch über den Browser. Bei mir dreht sich da ehrlich gesagt der Margen.

Oder doch ein CMS?

Würden wir rational denken, wäre der erste Gedanke sowieso ein Content Managament System, zu deutsch ein Inhaltsverwaltungssystem. Denn innerhalb der letzten Jahre haben solche Systeme einen unheimlichen Boom erlebt und werden mit Vorliebe im Bereich des billigen Webhostings angeboten, da sie die Möglichkeit bieten, mit wenig technischem Know-How bereits komplexe Webanwendungen zusammen zu klicken.

Im Gegensatz zur Wiki liegt der Gedanke hier eher in einem umfassenden System in welchem man die komplette Seitenstruktur bearbeiten kann und Kontrolle über alle Bilder und Inhalte hat. Je nach gewählter CMS-Software ist Versionskontrolle natürlich auch inklusive.

Während man bei der Wiki noch einigermaßen Kontrolle über Seitenstruktur hatte, verwaltet hier das CMS die komplette Website. Im Prinzip begeben wir uns damit zurück auf das Niveau von Frontpage, Adobe GoLive & Konsorten – nur diesmal zentral auf dem Server laufend und nicht auf dem heimischen Computer.

Version 6ff?

Alle diese Wege haben eins gemeinsam: Die momentane Struktur der Homepage wird mehr oder weniger aufgelöst. Mit "Version 6" der Homepage wäre damit der konkreten Versionszählung der vergangenen drei Jahre ein jähes Ende gesetzt – alles Darauffolgende würde sich zwischen fließendem Versionsübergang und einem (versionsmäßig gesehen) Zustand von 2004 irgendwo im Nirwana befinden. Wozu auch Versionszählung, wenn dieses Problem gelöst ist?

Fazit

Der CHANGELOG ist mit dem Begriff v5 ("Version 5") eng verknüpft. Er verkörpert die Ideologie, die mit dieser neuen Version aufgekommen ist. Die Idee, dass die Homepage in ihrer Form vollständig veränderbar ist, dass einem keine Instanz in der gegebenen Struktur Schranken aufweist. Mit einem neuen Konzept, wie es die drei vorgestellten Lösungen sind, wird eine neue Form der Speicherung angenommen, auf die kein Einfluss mehr besteht. Daher ist das Finden einer Lösung, die – etwas ungünstig formuliert – mit meinem Gewissen vereinbar ist, ziemlich schwierig. Vorerst wird es daher auf dem neuen Server erst bei der alten, klassischen Lösung mit FTP-Server und verteilten Kopien bleiben. Vielleicht finden sich ja Mittelwege, die allen Parteien gerecht werden.


Sven, am Morgen des 09.11.2008