Aufgabe: Migration – Cruisecontrol + phpUnderControl von CentOS zu Debian – Fehler: java.net.SocketException: Network is unreachable – Lösung:

Nachdem wir eine Migration eines Servers mit lauffähiger Cruisecontrol- + phpUnderControl-Installation, von CentOS auf Debian, durchführen mussten, sind wir auf folgendes Problem gestoßen:

Die Weboberfläche war nicht unter dem Standard-Port 8080 erreichbar. Normalerweise sollte sich Cruisecontrol aber auf Port 8080 binden.
Ein Blick in den Logfile von Cruisecontrol verriet uns folgendes:

Ein:

zeigte uns, dass sich Cruisecontrol zwar auf Port 8080 gebunden hat, aber nur unter IPv6.

Nach stundenlangem googlen fanden wir folgende Lösung:

Und nun bindet sich Cruisecontrol auch auf Port 8080 unter IPv4!

Im Buildprozess eines meiner Projekte kommt seit kurzem ein neues, hilfreiches Werkzeug zur Optimierung von PNG-Grafiken zum Einsatz. Die von den Grafikern gelieferten Dateien entsprechen zwar optisch den Anforderungen, jedoch besteht immer ein wenig potenzial die Größe der Dateien noch ein wenig zu reduzieren. Auch wenn durch die Optimierungen nur ein paar Kilobyte pro Datei gespart werden, ist der Aufwand zur einmaligen Einrichtung dieses Werkzeuges absolut gerechtfertig. Wenn man die eingesparten Kilobytes auf die Gesamtanzahl der Besucher im Monat hochrechnet, merkt man schnell, dass Traffic eingespart wird und der Server insges. weniger belastet wird, da er “kleinere” Dateimengen ausliefern muss.

Für alle, die ein Buildtool wie zB. phpUnderControl im Einsatz haben, sollte die Integration relativ schnell durchzuführen sein. Nach der einmaligen Einrichtung hat man mit jedem Build nun top-optimierte PNG-Grafiken. Ich steuere OptiPNG aus dem Ant-Buildskript (Aufruf Shellskript) heraus über ein kleines Shellskript (Suche nach PNG-Grafiken + Optimierung) an.

OptiPNG findet ihr hier

Den Frontend-Entwicklern unter euch, wird “JSLint” von Douglas Crockford sicherlich ein Begriff sein. Auch ich setze für die schnelle Prüfung auf Verletzung von Coding-Conventions JSLint ein.  Bisher habe ich auf die Java-basierte Kommandozeilenversion gesetzt Im Buildprozess werde ich dies auch beibehalten, allerdings habe ich in meiner IDE soeben die Kommandozeilenversion (testweise) gegen die JSLint-Pugin-Version ausgetauscht. Mal sehen ob sich das Plugin bewährt. Auf den ersten Blick sieht es jedenfalls ganz OK aus:

Abb. 1 JSLint Options

Abb. 2 JSLint Menu

Abb. 3 JSLint Editor

Es lässt sich halt sehr viel einfacher aber vor allem schneller (Um-)konfigurieren und die Fehlerausgabe erfolgt, wie gewünscht unter “Problems” in der IDE, anstatt als Konsolenoutput.