In einem anderen Artikel habe ich bereits vor einer ganzen Weile schon über die so nützlichen SVN Hooks geschrieben, die standardmäßig bei jedem Repository mitgeliefert werden. Damals habe ich ausschließlich das post-commit Hook, also dem Script, was nach dem erfolgreichen Commit ausgeführt wird, an einem Beispiel vorgestellt.

Heute möchte ich mich dem pre-commit Script widmen. Dieses Script wird, wie der Name vermuten lässt, vor dem entgültigen Commit ins Repository ausgefürt. Wie auch beim post-commit Hook gibt es keine Grenzen in der Umsetzung. Es kann den Code auf Syntax-Fehler prüfen, den Commit verweigern, wenn der Comment nicht den eigenen Standards entspricht oder die Einhaltung der internen Programmierstandards checken.

Inwieweit diese Prüfmechanismen sinnig oder überlüssig sind, hängt ganz vom angewandten System und natürlich jedem Team selbst ab. Ich habe da meine klaren Regeln, was in das Hook gehört, und was nicht.

Die Prüfung auf Syntax-Fehler ist im Produktivsystem unverzichtbar. Was live geht, muss wenigstens vom Syntax her stimmen (von der Logik her natürlich auch). Im Developing ist das allerdings nicht so wichtig, als das eine Prüfung den Commit verweigern sollte. Ebenso ist es im Branch weniger wichtig, dass die Comment-Standards eingehalten werden. Im trunk allerdings schon, denn gerade im hitzigen Gefecht zwischen Bugs und Fixes ist es wichtig, dass irgendjemand auch nach Wochen noch durchblickt, was in welcher Revision eigentlich eingespielt wurde, ohne die History durcharbeiten zu müssen.

Anders sieht es mit den Programmierrichtlinien aus. Diese Prüfung gehört definitiv ausschließlich in den Entwicklungsbereich. In das Produktivsystem kommt so nur standardkonformer Code. Im Falle eines schnellen Bugfix direkt im Live-System, bei dem das Motto "Zeit ist Geld" zählt, sind die Richtlinien ersteinmal Nebensache.

Im Folgenden möchte ich also meine Lösung vorstellen, die die eben geschriebenen Regeln berücksichtigt und umsetzt.

[ganzen Beitrag lesen …]

... auf unseren Internetseiten mache ich mir mittlerweile sehr viele Gedanken. Viele Entwickler und Usability-Fanatiker sind der Meinung, dass JavaScript ausschließlich optional angewendet werden sollte und die uneingeschränkte Nutzung eines Portals auch ohne aktiviertes JavaScript möglich sein muss. Andere wiederum sind Verfechter der gegenteiligen Meinung. Hier spalten sich also die Lager der Entwickler, und so recht will ich mich nicht festlegen.

Das ich mir darüber Gedanken gemacht habe, war noch nicht immer so. Als ich vor zehn Jahren die ersten Gehversuche mit der eigenen Internetseite machte, waren alle Scripts, die ich nur irgendwo gefunden habe und die mir ansatzweise gefallen haben, auf meiner Seite verbaut - frei nach dem Motto "viel hilft viel". Wie das Resultat aussah kann man sich heute kaum noch vorstellen. Die Title-Zeile scrollte am linken Bildschrimrand unaufhaltsam vor sich hin; die Fenstergröße veränderte sich wie durch Zauberhand auf maximale Größe; überall blinkte und bewegte sich etwas. Als ich dann auch noch den alert()-Befehl entdeckte, habe ich meine - zum Glück nur wenigen - Besucher auf eine niemals enden wollende Reise des OK-Klickens geschickt. Und wer sich einfach dem Enter-Taste-Drückens bediente, durfte gleich nochmal anfangen.

Bei meinen Überlegungen habe ich die Vor- und Nachteile beider Möglichkeiten gegeneinander aufgewogen. Wenn man anhand dieser Fakten entscheidet, benötigt man keine Alternativen für die JavaScript-Funktionen.

Moderne Internetseiten wie Facebook, Twitter und Co. leben förmlich von JavaScript, also warum komplett darauf verzichten? Das nun mit den Nutzern, die JavaScript browserseitig deaktiviert haben, argumentiert wird, war klar. Aber wer sind diese Nutzer überhaupt? Diese und andere Fragen möchte ich im Weiteren noch genauer erörtern.

[ganzen Beitrag lesen …]

Wie der Zufall es wollte, hat mich unser Monitoring System am 30. November gegen 17:30 Uhr über ein Problem der Datenbank-Replikation informiert, als ich gerade einer Master Lecture in der FH Schmalkalden über Datenbank Sicherheit und Redundanz zuhörte. Da ich meinen Laptop ohnehin gerade auf hatte, wollte ich mich dem Problem schnell annehmen.

Da ich das Problem nicht ausfindig machen konnte, wollte ich die Replikation schnell neu aufsetzen. Mit meiner Anleitung hätte das nur wenige Minuten gedauert. Ich trennte also die Verbindung zwischen beiden Master-Servern und löschte auf dem Problemserver die Datenbank. Warum auch immer hatte die Replikation sich derweil wieder hergestellt und meinen Lösche-Befehl auch an die Live-Datenbank geschickt. Resultat: Die Datenbank war komplett weg!

Nachdem der erste Schock verkraftet war, habe ich meine paar Sachen gegriffen und bin im Eiltempo ins Büro gefahren. Aufgabe war es, die Datenbank bis zum Zeitpunkt der Löschung wieder herzustellen. Wie ich das erreicht habe, möchte ich im Folgenden genauer erklären.

[ganzen Beitrag lesen …]

Datensicherheit ist wichtig - und zwar von der Übertragung zwischen Client und Server bis hin zu Speicherung auf letzterem. Da ich dieses Thema sehr ernst nehme, erzwinge ich bereits seit Jahren auf vielen Projekten die verschlüsselte Übertragung per SSL. Die Verschlüsselung ist zwar rechenintensiver, jedoch ist es mir die Mehrlast wert. Dabei setze ich überwiegend auf das domainidentifizierte SSL123 Zertifikat von Thawte.

Ist die Einrichtung eines SSL Zertifikates unter Apache sehr einfach, kann sie beim Lighty-Webserver doch mal einige Stoplersteine mit sich bringen. Da ich mich mit diesem Thema letzte Woche wiedereinmal beschäftigt habe, möchte ich meine Lösung gleich veröffentlichen.

[ganzen Beitrag lesen …]

Zu Testzwecken musste ich diese Woche mal wieder ein Zertifikat selbst erstellen und signieren. Normalerweise nutze ich dazu die Zertifikat-Verwaltung von Plesk und ein 90-Tage-Testzertifikat von zum Beispiel Comodo.

Leider schien wohl aber was mit meiner letzten Testbestellung nicht geklappt zu haben. Das Zertifikat wurde einfach nicht ausgestellt. Also musste ich selbst ein Zertifikat erstellen, was aber kein Problem sein sollte, da es ohnehin nur in der Test-Umgebung eingespielt wurde und Browserhinweise keine Rolle spielten.

Da einige Fehlversuche dabei waren, möchte ich im Folgenden meine entgültige Lösung nun auch online stellen, damit anderen Entwicklern die Testerei erspart bleibt.

[ganzen Beitrag lesen …]