links for 2007-08-20

Dienstag, 21. August 2007

Wochenende verbraten

Montag, 20. August 2007
Eigentlich wollte ich einiges am Wochenende bloggen. Dann hab ich bei MacUpdate Promo Pax Galaxia entdeckt, und das auch ausprobiert. Den Rest des Wochenendes habe ich dann damit verbracht, fremde Galaxien zu erobern. Spass hat es gemacht, aber geschafft habe ich nichts...

Empfehlen kann ich das Spiel durchaus. Aber vor dem ausprobieren sollte man sich bewusst sein, dass man dann zu nichts anderem mehr kommt...

Magix Blog ohne Piet?

Freitag, 17. August 2007
Der Magix-Blog wird nicht mehr seien, was er mal war. Klar, Dinge verändern sich. Manchmal zum besseren, manchmal aber auch zum schlechteren! Im Magix-Blog wird der Hauptautor gehen. Ich möchte daher kurz sagen: Ciao Piet, werde dich auf dem Magix Blog vermissen!

Wer wird den dein Nachfolger? Und verschwindet dann auch dein Foto aus dem Blog-Header?

So, und jetzt bitte weiter gehen! Es gibt hier nichts weiter zu sehen.

Kommentare wieder offen

Donnerstag, 16. August 2007
Kommentare sind jetzt wieder aktiviert. Als das Gestern mit dem Ausfall begann, dachte ich erst, das währe eine weitere Spamwelle, und habe die Notfall-Blockade aktiviert. Da ich Gestern keine Rückmeldung bekommen habe, dachte ich eigentlich, das Aktivieren hätte nicht geklappt. Egal, nun bitte wieder kommentieren!

Resümee nach einer Woche

Donnerstag, 16. August 2007
Seit einer knappen Woche bin ich mit dem Blog auf einen Shared-Hoster umgezogen. Seit dem gab es bisher zwei größere Ausfälle. Der erste war eher kleiner, und beschränkte sich auf eine knappe halbe Stunde. Da ich scheinbar auf einem neuen Server gelandet bin, gab es dort noch technische Probleme, so dass dieser neu gestartet werden musste. Der Server selber läuft seit dem stabil.

Den zweite Ausfall gab es gestern Abend. Dabei war das gesamte Netz des Hosters betroffen. Es hat also nicht nur mich getroffen, sondern die gesamte Infrastruktur. Alle dort gehosteten Seiten waren zeitweise nicht erreichbar. Waren die Seiten erreichbar gab es dann häufig Schwierigkeiten auf die Datenbank zuzugreifen. Der Ausfall hat mehrere Stunden gedauert und war schon ziemlich heftig.

Außerdem scheint es auch zu Stoßzeiten Probleme mit der Geschwindigkeit zu geben. Zwar reagiert der Blog meistens, aber teilweise doch sehr langsam. Der Hosting-Server scheint dabei aber nicht wirklich unter Last zu stehen. Vielmehr kann ich mir vorstellen, dass die Verbindung zu der Datenbank hier Probleme macht. Das muss ich aber noch mal genauer beobachten.

Sollte ich also von der aktuellen Woche, auf die gesamte Zeit schauen, so müsste ich meinen Account sofort kündigen. Ich hoffe aber, dass es nur gerade eine schlechte Zeit ist, und sich die nächsten Wochen etwas ruhiger darstellen werden. Falls nicht, werde ich doch wieder umziehen müssen...

Anonyme Methoden - ActiveRecord in PHP?

Montag, 13. August 2007
Was mir besonders an Ruby on Rails gefallen hat, ist die Eleganz die die Datenbank-Abstraktion bietet. Die ActiveRecord getaufte Bibliothek ermöglicht einfache Suchabfragen der Art:
Modell.find_by_Tabellenspalte(:first, Wert)
zu machen. Natürlich kann das alternativ auch noch mit and verknüpft werden:
Modell.find_by_Tabellenspalte1_and_Tabellenspalte2(:first, Wert1, Wert2)

Beides gibt ein Objekt zurück, in dem jeweils das erste Objekt der Suchabfrage enthalten ist. Beides sind sehr schöne Möglichkeiten, um lesbaren Code zu bekommen. Es ist sofort klar, was man für Daten haben will. Außerdem muss für diese Abfrage nichts weiter programmieren. Alle Logik für diese Methoden sind in ActiveRecord enthalten. Man muss also keinerlei zusätzliche Entwicklung leisten.

So lange ich jetzt schon PHP programmiere habe ich eine ähnliche Implementierung noch nicht gesehen. Es ist mir kein Framework bekannt, was eine ähnliche Eleganz unter PHP erlaubt. Trotzdem hat es mich interessiert, ob eine solche Lösung auch unter PHP möglich ist.

Ich habe versucht, das ganze zu implementieren, in dem ich ein Objekt mit anonymen Methoden ausstatten will. Ich bin damit zu folgendem Ansatz gekommen. Das ganze stellt hier zwar nur Beispiel-Code dar, könnte aber dann im Endeffekt für das spezifische Problem implementiert werden:
class dynamic_class {
private $methods = array();
public $test = null;

function addMethod($name, $method) {
$this -> methods[$name] = $method;
}

function showTest() {
echo $this -> test . "\n";
}

function __call($method, $parameters) {
if (array_key_exists($method, $this -> methods)) {
array_unshift($parameters, $this);
call_user_func_array($this -> methods['test'], $parameters);
}
else {
// error
die('METHOD NOT FOUND!');
}
}
}

$test = new dynamic_class();
$test -> addMethod('test', create_function('$obj, $args', '$obj -> test = $args;'));
$test -> test('dynamische methoden funktionieren!');
$test -> showTest();

Hier wird als erstes eine dynamische Klasse erstellt. Diese hat zwei normale Funktionen. Zusätzlich implementiert sie die magische Methode __call. Diese wird immer dann aufgerufen, wenn eine Methode in der Klasse aufgerufen werden soll, die bisher nicht existiert.

Innerhalb der Methode wird als erstes geprüft, ob die aufzurufende Methode dynamisch hinzugefügt wurde. Ist das der Fall, so wird die Methode einfach aufgerufen. Wenn nicht, wird das Programm beendet. Zum Schluss wird in dem Script die Klasse und die dynamisch erzeugte Methode geprüft.

Soweit funktioniert das ganze. Man hat den Eindruck, als wenn eine neue dynamische Methode erzeugt wurde. Leider sieht man in dem kurzen Beispiel aber schon ein großes Problem: Die Klassen-Variable $test ist public deklariert. Außerdem wird vor dem Aufruf der dynamischen Methode zusätzlich noch das eigene Objekt in den Parameter-Stack eingeführt.

Das Problem, was sich hier nämlich ergibt ist, dass die neue Methode sich nicht in die Klasse eingliedert, sondern komplett selbstständig ist. Sie wird zwar aus dem Kontext der Klasse aufgerufen, ist selber aber nicht Teil dieses Kontexts der Klasse! Es ist somit nicht möglich auf Variablen zuzugreifen die private oder protected deklariert wurden.

Im Gegensatz zu der Implementierung von Ruby on Rails habe ich hier versucht, ein Objekt mit einer anonymen Methode auszustatten. Das hat nur bedingt funktioniert. Schaut man sich jedoch die Lösung in Ruby an, ist das ganze nicht gelöst worden, in dem anonyme Methoden erstellt wurden, sondern in dem einfach nicht existierende Funktionen abgefangen werden, und diese dann analysiert werden, und die passenden Daten geladen werden.

Interessant ist nun, dass ich genau dieses Vorgehen hier genutzt habe, um anonyme Methoden zu interpretieren. Das heißt aber auch, dass nichts dagegen spricht, ein ähnliches Verhalten, wie es Ruby on Rails mit ActiveRecord zeigt, auch unter PHP zu implementieren. Dann kann man auch auch create_function und call_user_func_array verzichten.

Ich hatte hierbei speziell die Ansprüche, dass das ganze unter PHP5 funktioniert. Meiner Meinung nach ist es heutzutage nicht mehr nötig PHP4 zu unterstützten! Der gezeigte Code wird daher nicht unter PHP4 funktionieren. Ich denke auch nicht, dass es möglich wäre ähnliches unter PHP4 zu implementieren.

Zeichnung Felicitas

Sonntag, 12. August 2007
Karikatur Felicitas

Neues Zuhause

Sonntag, 12. August 2007
Wer diesen Beitrag lesen kann, der hat schon den Blog auf seinem neuen Zuhause gefunden. Dabei sind dann auch alle umgezogenen Blogs in eine Shared-Installation gewandert. Dadurch dürfte sich der Wartungsaufwand zukünftig reduzieren. Hoffe ich jedenfalls...

Server überlastet

Samstag, 11. August 2007
Derzeit wird es auf dem Server relativ eng. Eng vor allem deswegen, weil die Spammer noch immer in mittleren Massen Trackbacks schicken. Dabei schlagen locker bis zu 20 Trackbacks in der Sekunde auf! Damit ist der Server leider etwas überfordert. Er schafft es zwar, die Anfragen zu verarbeiten, aber der gesamte Server wird merklich langsamer. Da auf dem Server nicht nur ein Webserver, sondern auch Email und Jabber laufen, werden damit auch diese Dienste beeinträchtigt.

Wir haben die letzten Wochen mehrere Dinge ausprobiert, um die Last zu reduzieren. Zum einen wurden die Einstellungen für PHP und den Webserver optimiert. Zum anderen haben wir häufige Trackback-Spam-IPs gesperrt. Beide Maßnahmen brachten kurzzeitig etwas Luft. Die Spammer wechseln jedoch regelmäßig die missbrauchten IPs so dass das Sperren in regelrechter Arbeit ausartet.

Eine Möglichkeit, die wir noch nicht genutzt haben, ist das Auslagern des Webservers. Dadurch kann dieser unter Beschuss stehen, während die restlichen Dienste ohne Beeinträchtigung weiter laufen.

Dabei gibt es generell zwei Möglichkeit. Die erste ist das Mieten eines weiteren Servers. Dieses ist jedoch mit reichlich Arbeit und zusätzlichen hohen Kosten verbunden. Die zweite Möglichkeit ist das Mieten leistungsfähigen Webspaces, und die Nutzung eines Shared-Hosting-Anbieters. Dieses bietet zwar nicht die Flexibilität, ist dafür aber mit weniger Kosten verbunden.

Da ich derzeit die Kosten für den weiteren Webserver scheue, und wir die benötigte Flexibilität bereits mit dem vorhandenen Server haben, werde ich die zweite Möglichkeit ausprobieren. Somit werden im laufe des Wochenendes einige meiner Webseiten umziehen. Dazu werden Kommentare auf den Blogs deaktiviert werden. Es wird außerdem einige Zeit dauern, bis die DNS-Einträge aktualisiert sind.

Das ganze ist vorläufig ein Test. Funktioniert das Hosting gut und bin ich zufrieden, so wird das zu einer Dauerlösung. Ist aber die Erreichbarkeit teilweise ebenfalls nicht gegeben, oder wird der Shared-Hoster mit dem Trackback-Spam selber nicht fertig, muss ich in einigen Monaten eine andere Lösung finden. Das bedeutet dann wohl doch in den sauren Apfel zu beißen, und einen weiteren Server zu mieten.

Shared Installation?

Freitag, 10. August 2007
Ich glaube, ich sollte so langsam mal darüber nachdenken, meine Serendipity-Installationen in eine Shared Variante umzukonfigurieren.

Ich habe heute nämlich nur die von mir betreuten Blogs aktualisiert und musste feststellen, dass das inzwischen sieben einzelne Installationen sind. Davon abgesehen sind weitere Serendipity-Blogs auf dem Server gehostet.

Also würde es sich durchaus lohnen. Dann müsste nur noch einmal eine Aktualisierung gemacht werden, und jeder würde davon profitieren. Auch wenn das Update jetzt bei Serendipity nicht so wirklich kompliziert ist, dauert es ein Weilchen, bis man alle Blogs durch hat.