RackBlogger

Die Telekom bietet auf ihrem neu eröffneten Entwicklerportal Developer Garden Programmierschnittstellen für einige Dienste wie z.B. SMS-Versand oder Aufbau einer Telefonverbindung.

Wer statt der bereitgestellten SDKs die Webservice-Schnittstelle nutzen will (oder muss) wird es aber nicht leicht haben, wie die Dokumentation zeigt. Diese Lösung mag technisch zwar sauber sein, und in hochkomplexen Systemen wie bei der Telekom auch sicher berechtigt sein, aber vielleicht schießt diese doch etwas am Ziel vorbei. Für den Versand einer SMS-Nachricht werden mindestens 4 SOAP-Nachrichten hin- und hergeschickt, und insgesamt rund 20 kB Daten ausgetauscht…

Für unser SMS-Gateway reicht ein einziger HTTP-Request. Die Authorisierung erfolgt über ein Hash, welches das Passwort, einen Timestamp, alle Nutzdaten sowie eine fortlaufende Seriennummer umfasst. Somit wird kein Klartextpasswort übertragen (unabhängig von der SSL-Verbindung), und der Sendeauftrag kann nicht mehrfach ausgeführt werden. Und ein PHP-Client dafür ist in weniger als 5 Minuten programmiert.

Das ich kein großer Freund von PHP bin ist wahrscheinlich nicht neu. Inzwischen fällt es mir aber schwer, PHP überhaupt als Programmiersprache ernst zu nehmen.

Wer mir zuerst sagen kann, welches Ergebnis man denn nach Schritt 5 erwartet (und welches man tatsächlich bekommt), gewinnt einen Kugelschreiber.

$betrag = ‘34.04148′; # Betrag in CHF
echo “Input: $betrag\n”;

# Schritt 1: *20
$betrag = $betrag * 20;
echo “Schritt 1: $betrag\n”;

# Schritt 2: Rundung
$betrag = round($betrag);
echo “Schritt 2: $betrag\n”;

# Schritt 3: / 20
$betrag = $betrag / 20;
echo “Schritt 3: $betrag\n”;

# Schritt 4: * 100
$betrag = $betrag * 100;
echo “Schritt 4: $betrag\n”;
var_dump($betrag);

# Schritt 5: intval
$betrag = intval($betrag);
echo “Schritt 5: $betrag\n”;

Kürzlich hat MySQL die neue Version 5.1.24-rc (Release Candidate) veröffentlich. Trotz der langen Liste mit Änderungen scheint das aber trotzdem ein Schnellschuss gewesen zu sein: in den .tar.gz-Archiven fehlen alle notwendigen Dateien für den Start des MySQL-Clusters (ndbd), und die RPMs mit den Cluster-Binaries stehen nach wie vor erst in 5.1.23-rc bereit…

NACHTRAG: It’s not a bug, it’s a feature - oder so ähnlich…

Mein Bug-Report bei MySQL wurde mit folgendem Kommentar als “Not a bug” klassifiziert und geschlossen.

We will not support MySQL Cluster in MySQL 5.1. There will be a separate MySQL Cluster product based on MySQL 5.1, and much more advanced ndb source than MySQL 5.1 contains by default.
Community binaries for this are just around the corner, too.

Suboptimale Kommunikationspolitik…

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…