RackBlogger

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?

Schonmal probiert, auf einem virtuellen XEN-Server die Systemzeit zu ändern (z.B. mit ntpdate)? Nein? Na dann viel Spaß.

Gerade ziehe ich ein größeres Softwareprojekt (~40.000 Zeilen C/C++ Code) vom bisherigen Versionsmanagement CVS in ein neu eingerichtetes Subversion-Repository um. Eigentlich war das schon längst überfällig, die neuen Möglichkeiten mit Subversion sind wirklich sehr verlockend. Allerdings habe ich bisher einfach die Arbeit gescheut (und eventuelle Migrationsprobleme).

Ich bin mal gespannt wie sich’s nun mit svn so arbeiten lässt…

Der Artikel ist gedruckt

Ich beschreibe darin verschiedene Ansätze, wie man in Ajax-Anwendungen mit möglichst geringer Latenz Daten asynchron vom Webserver zum Browser senden kann. Ein einfaches Anwendungsbeispiel hierfür wäre ein Browser-Chat-System.

Wer mehr wissen will: aktuelles ix-Magazin (Ausgabe 6/2007), Seite 122.

Wir arbeiten ja derzeit an einer ganz tollen neuen Software. Diese läuft nicht nur unter Linux, Solaris usw., sondern auch unter Windows. Bei den Unix-Systemen als Daemon, unter Windows eben als Dienst.

Und ab sofort kann diese “Konsolenanwendung” auch Fenster anzeigen. Bis vor wenigen Stunden hätte ich das noch nicht so ganz für möglich gehalten, aber es geht wirklich. Mittels der WIN32-API kann man auch “normale” Konsolenanwendungen dazu bringen, Fenster etc. zu erzeugen. Wenn der Dienst nun also startet, kommt erstmal ein informativer Splash-Screen, und solange er läuft steht im System Tray ein Icon, über welches dieser Dienst zur Laufzeit beobachtet und evtl. später auch konfiguriert werden kann. Und das alles ohne .Net oder MFC.
Zugegeben - an sich ist das nur eine kleine Spielerei, aber ich denke dass die Bedienung des Dienstes dadurch ein wenig intuitiver wird. Und es schaut einfach toll aus.

Für eine ganz bestimmte Anwendung habe ich nach einem technologischen Lösungsansatz gesucht. Es ging dabei um eine ziemlich spezielle Sache - im Grunde wie man auf Windows-Systemen von einem Programm aus den I/O eines anderen Programmes zuverlässig kontrollieren kann. Das ist leider nicht ganz so trivial wie auf Unix-Systemen (dank Pseudo-Terminals), aber es geht. Es muss gehen. Irgendwie.

Also habe ich mich schrittweise vorangearbeitet, die relevanten WIN32-API-Befehle herausgefunden und nach Beispielcode gegoogelt. Schließlich fand ich quasi den perfekten Anwendungscode, also genau das was ich gesucht hatte. Programmiert in zuckerfeinem C, dezent dokumentiert, ohne Geschnörksel. Keine 1000 Zeilen Programmcode, die compilierte Executable nur wenige Kilobyte groß. Was war das nur für ein Programm? … Der Quellcode eines Trojaners!

Ich muss schon sagen - DAS war sicher nicht die Arbeit eines “Script-Kiddies”, sondern über eine über etliche Programmversionen hinweg optimierte Arbeit eines oder mehrerer Profis. Egal - ich will ja schließlich keinen Trojaner schreiben, aber der Code hat mir bei meinen Aufgaben definitiv weitergeholfen.