RackBlogger

Heute habe ich den lieben Tag damit verbracht, endlich mal gescheite XSL-Stylesheets für die Doku unserer neuen Verwaltungssoftware zu basteln. Die komplette Dokumentation (Installation, Verwendung, Schnittstellen, etc.) ist in DocBook-XML “programmiert” (natürlich auf Deutsch und Englisch). Damit können wir auf Knopfdruck die aktuelle Doku jeweils als HTML (einzelne bzw. viele kleine Dateien) sowie als PDF erzeugen, und neuerdings auch eine HTML-Version die direkt in die neuen Webseiten integriert wird.

So macht Dokumentation fast wieder Spaß…

(ok, ein paar Texte müssen noch geschrieben werden…)

Für unser neues Verwaltungssystem habe ich eben mal wieder einen Graphen des Datenbankschemas generieren lassen. Schaut nett aus:

Das Datenbankschema ist in einer “Meta-Sprache” definiert; ein kleines Perl-Script erzeugt daraus die entsprechenden DDL-Statements für SQLite, MySQL etc., sowie eine .dot-Datei, die als Input für DOT (GraphViz) dient und o.g. Graphen erzeugt.

Unsere neue Verwaltungssoftware durchläuft gerade das “Clean-Up”, einhergehend mit allen möglichen Optimierungen. Unter anderem wurde gaaanz tief in die Trickkiste gegriffen, um die Zugriffe auf die Weboberfläche bis auf’s Letzte zu optimieren.

Das dürfte nun erreicht sein:

Wenn die Seite einmal geladen wurde, werden alle statischen Elemente (Bilder, CSS, Javascript etc.) vom Browser gecached. Hierzu empfiehlt sich ein großzügiger Wert im “Expires”-Header. Damit nach einem Software-Update aber keine veralteten Elemente aus dem Browsercache verwendet werden, sind alle Elemente jeweils mit einer Versionsnummer adressiert (z.B. /images/v1.2/logo.gif). Außerdem werden alle dynamisch erzeugten Inhalte mit GZip komprimiert (sofern der jeweilige Browser das unterstützt), was gerade bei vielen Ajax-Anfragen dazu führt, daß die komplette Antwort in ein einzelnes TCP-Paket passt. Durch die spezielle HTTP-Engine können wir außerdem das HTTP-KeepAlive auf einen sehr großzügigen Wert setzen, was dazu führt, daß die TCP-Verbindung zwischen Browser und Software minutenlang offen bleiben kann. Das Ergebnis ist eine wirklich blitzschnelle Oberfläche, auch über etwas langsamere Verbindungen.

Wer seine eigenen Webseiten oder Programme optimieren will, dem sei neben dem obligatorischen Firefox-Plugin Firebug auch das Plugin YSlow empfohlen - insbesondere für die Cache-Analyse.

Seit gut einer halben Stunde läuft - als Ergebnis monatelanger Vorbereitungen - ein Script zur Migration all unserer Kundendaten vom “alten” WebConfig ins neue Kundenverwaltungssystem. Aus dem alten System werden die Daten direkt über die MySQL-Datenbank ausgelesen, ins neue System werden sie ganz elegant per WebService-Aufruf gespeichert. Dieser Vorgang dauert deshalb so lange, weil die Datenstrukturen relativ komplex sind. Zu jedem Kunden existieren ein oder mehrere Verträge und Kontaktdaten, zu jedem Vertrag eine oder mehrere Leistungen (wie z.B. Hosting-Pakete), welche wiederum mit Domains verknüpft sein können. Dazu kommen noch Postfächer, Datenbanken, SMS-Accounts und vieles mehr. Der Umzug der Buchhaltungs-Posten wird derzeit noch vorbereitet.

Bei dieser Gelegenheit war übrigens festzustellen, daß der in PHP5 integrierte SOAP-Client spürbar schneller ist also die SOAP::Lite-Bibliothek von Perl. Keine Ahnung warum.

Mit all diesen Daten im neuen System kann dann in Kürze der erste Live-Test des neuen Verwaltungssystems durchgeführt werden *freu*

Auch mal wieder eine interessante Sache, die Microsoft da abgeliefert hat: viele in POSIX standardisierte Befehle der Standard-C-Bibliothek wurden in neueren VisualC-Compilern als “deprecated” erklärt (siehe MSDN).

Unter dem Decknamen “Security Enhancements in the C Runtime” sorgt die neue Policy nun dafür, daß der Compiler standardmäßig bei typischen C-Befehlen wie strcpy eine Warnung ausgibt und den Programmierer bittet, doch besser die “sicherere” Version (z.B. das MS-proprietäre strcpy_s) zu verwenden. Da rollen sich einem doch die Zehennägel auf!

Warum sollte die Software deshalb “sicherer” werden, wenn man es ausgerechnet Windows überlässt, auf so oder so vorhandene Fehler des Programmierers zu prüfen? Ich befürchte eher, daß somit noch schlampigere Programmierung erfolgt (nach dem Motto “wenn da ein Fehler drin ist wird die Runtime sich schon darum kümmern) und Code noch unportabler wird.

Wir entwickeln derzeit ein Produkt unter Linux und Windows; wenn der (Standard-C-)Code unter Linux einwandfrei compiliert und in den Debuggern&Profilern alle Modultests durchsteht, dann läuft’s fast automatisch auch unter Windows…

Unsere Verwaltungssoftware hat nun ein weiteres kleines, aber feines Feature: die Unterstützung von Zeitzonen. Um ausländischen Kunden die Anzeige zu erleichtern, werden intern alle Uhrzeiten in GMT/UTC abgespeichert und während der Anzeige an die jeweilige Zeitzone des Kunden angepasst.

Die ursprüngliche Idee war, im Kundenprofil jeweils nur die entsprechenden GMT-Offset-Stunden zu speichern (z.B. “2″ für GMT+2). Wenn da nicht so Länder wie Nepal wären, die als GMT-Offset 5:45 Stunden haben… In diesem Fall speichern wir das also in Minuten (es gibt auch sekundengenaue Zonenwechsel im Rahmen der jeweiligen Angleichung an GMT, aber uns interessieren eh erst Zeiten ab dem Computer-Urknall am 01.01.1970).
Das nächste Problem sind die Sommerzeiten. Dafür gibt es keine feste Regelung; die einen Länder schaffen die Sommerzeit gerade spontan ab, andere orientieren sich am Ramadan, andere haben wiederum gesetzlich festgelegt daß der Sommer mindestens 150 Tage lang sein muß, und so weiter… Wir könnten nun zusätzliche Eingabemasken definieren, mit denen die Kunden das selber pflegen können, aber zum einen wird das auf Dauer lästig (und Fehleranfällig), zum anderen möchten wir auch in zehn Jahren noch wissen wann dieses Jahr die Sommerzeit angefangen hat (die Daten müssten also historisch gespeichert werden, was das Ganze auch nochmal komplexer macht).

Also wurde das Ganze gleich ganz ordentlich gemacht: mit der frei verfügbaren Zeitzonen-Datenbank, die u.a. auch Basis für die GNU glibc ist. In einigen großen Textdateien sind (fast?) alle Zeitzonen sowie deren Regeln definiert.

Ein kompaktes Perl-Script (immerhin auch 300 Zeilen) parst diese Dateien, filtert nur Regeln ab dem 01.01.1970 heraus, und schreibt das in SQL-Befehle um, mit denen wiederum die Backend-Datenbank gefüttert wird.

Daraus wird dann beim Laden des Benutzerprofils (z.B. beim Login) die gewünschte Zeitzone und alle relevanten Regeln in eine spezielle Datenstruktur im Speicher geladen (sind nur wenige Byte). Die Datums-Klasse (C++) konvertiert dann mit einem Befehl eine GMT-Zeitangabe in die gewünschte Zeitzone um und stellt daneben auch das jeweils gültige Zeitzonen-Kürzel (z.B. “CEST”) bereit. Der Overhead ist somit absolut minimal.

Und so schaut’s dann aus, wenn ich meine Zeit auf Nepal einstelle…

Heute früh hatte ich eine aller aller aller erste Pre-Alpha-Vorab-Demo-Test-Version unserer neuen Web-basierten Verwaltungssoftware einem Interessenten zugesendet. Der Kontakt zu ihm hat sich übrigens über den Businessplan-Wettbewerb ergeben.

Die Vorbereitung dieser kleinen Demo hat ein bisschen mehr Aufwand mit sich gebracht als ursprünglich erwartet - schließlich sollte alles perfekt laufen. Entsprechend gespannt habe ich dann auf die Reaktion des Interessenten gewartet.

Die kam heute Nachmittag per E-Mail:

Very nice …
Installiert ganz schwubs und ist sofort ansprechbar … das wäre was für uns!

Schön…

So auch Confixx - das Administrationspanel von SWSoft?

Ich habe das ja noch nie gemocht, aber das brauchte ich auch nicht weil wir hier unser eigenes System nutzen. Nun ist eine ziemlich gravierende Sicherheitslücke bekannt geworden, und bei dem Artikel auf heise.de lässt sich Interessantes zwischen den Zeilen lesen:

1&1 weist daraufhin, dass Confixx vom Hersteller SWSoft und von 1&1 nicht mehr voll unterstützt wird.

Ist es nun mutig oder fahrlässig, eine Software nach wie vor aktiv zu verkaufen und zu bewerben, wenn diese nicht mehr “voll unterstützt” wird? Und was sollen die Webhosting-Kollegen von so einer Mitteilung halten, die Confixx einsetzen?

Auf Plesk wechseln?

Oder warten bis wir unsere Hosting-Software verkaufen?