Perl
Die Inhalte der Website liegen seit einigen Jahren in einer MySQL-Datenbank und werden durch den Apache-Webserver ausgeliefert. Was genau er ausliefern soll, gebe ich ihm über eine Skriptsprache zu verstehen. Ursprünglich hatte ich jede einzelne Anweisung und sogar die HTTP Headers von Hand in Perl formuliert.
Die erste nicht statische Version meiner Website wurde mit dem bewährten LAMP-Stack realisiert. Sie gruppierte sich im Wesentlichen um eine große MySQL-Tabelle:
CREATE TABLE pages ( page_id int(11) NOT NULL auto_increment, title varchar(255) NOT NULL default '', content mediumtext, author_id int(11) default NULL, page_type tinyint(4) default NULL, mother_id int(11) NOT NULL default '0', user_id int(11) default '0', visible tinyint(4) default '1', texcontent mediumtext, pdfcontent mediumblob, mod_date timestamp(14) NOT NULL, site_id tinyint(4) default '1', position tinyint(4) default '0', syndication_id tinyint(4) default NULL, PRIMARY KEY (page_id), KEY title_index (title) ) TYPE=MyISAM;
Diese Tabelle war mit weiteren Tabellen verknüpft, und eine kleine Schar von Perl-Skripten machten aus einzelnen Datensätzen Webseiten. Der Code bestand zu etwa zwei Dritteln aus Perl-Anweisungen und -Deklarationen und zu einem Drittel aus HTML. Auch unter Sicherheitsaspekten war mein Setup eine Katastrophe - mal abgesehen davon, dass ich online nur einen Nutzer mit Lesezugriff auf die Datenbank verwende, hatte ich mir keine besondere Mühe gegeben, Hacker vor unlösbare Aufgaben zu stellen. Warum auch? Was auf meiner Website steht, war weder geheim noch sensibel oder gar profitabel.
Heute spielt Perl bei der Pflege dieser Website keine Rolle mehr. Aber es wäre kaltherzig, das altgediente Kamel totzuschweigen. Die erste Version dieser Website (a.k.a. „Spaghetti“) bestand aus Perl-Code. Die zweite Version (a.k.a. „Double Rigatoni“) entstand aus einer gewissen Notlage. Durch den Einbau neuer Funktionen („Wäre es nicht praktisch, wenn...?“) war ich an einen Punkt gelangt, an dem sich die CGI-Skripte nicht mehr handhaben ließen: Ich konnte die Konsequenzen einzelner Änderungen einfach nicht mehr absehen, weil ich mich häufig auf Perls berüchtigte Seiteneffekte und Sondervariablen verließ.
Zu diesem Zeitpunkt bestanden alle Skripte aus insgesamt 1663 Zeilen Code, und ich erinnerte mich an Randal Schwartzs Hinweis, dass eine objekt-orientierte Programmiertechnik sich ab etwa 1000 Zeilen lohne. Was hatte ich zu verlieren? Einige Nächte Schlaf. Der Übergang war relativ problemlos, weil ich viele meiner Subroutinen als Methoden übernommen habe. Auf die Trennung von Datenverarbeitung und Darstellung war ich sehr stolz, bis ich die neuen Antwortzeiten meiner Website sah. Sie waren ungefähr doppelt so hoch wie vorher.
Ich hatte zu viel Spaghetti-Code beibehalten und ein gewaltiges Objekt mit enorm vielen Eigenschaften und Methoden konstruiert, um alle möglichen Elemente und Situationen abzudecken. Das allein auf Perls beschränktes OO-Framework zu schieben, wäre etwas selbstgerecht. Andererseits macht eine konsequent objektorientierte Skriptsprache es leichter, sich von eigenen Fehlern zu verabschieden.