[Ben]

Rezension: Professionelle PHP 5-Programmierung

ISBN: 3827323819

Einen Gedankenaustausch zu diesem Buch gibt es an dieser Stelle.
http://www.developers-guide.net/foru...rtgeschrittene

In diesem Thread werde ich jedes Kapitel schnellstmöglich nach der Bearbeitung mit einer Kritik versehen.
In oben verlinktem Thread wurde ich gebeten über das Buch zu berichten und ich denke, dass dies auch sinnvoll ist.

-------------

Ein Inhaltsverzeichnis findet Ihr hier.

• Teil I, Implementierungs- und Entwicklungsmethodik
  • Kapitel 1, Programmierstile
  • Kapitel 2, Objektorientierte Programmierung mit Entwurfsmustern
  • Kapitel 3, Fehlerbehandlung
  • Kapitel 4, Templates und das Web: Implementierung mit PHP
  • Kapitel 5, Standalone-Skripts mit PHP implementieren
  • Kapitel 6, Unit-Tests
  • Kapitel 7, Entwicklungsumgebungen verwalten
  • Kapitel 8, Eine gute API erstellen
  
  
• Teil II, Caching
  • Kapitel 9, Externes Tuning der Performance
  • Kapitel 10, Partielles Cachen von Daten
  • Kapitel 11, Wiederverwendung von Berechnungen
  
  
• Teil III, Verteilte Anwendungen
  • Kapitel 12, Mit Datenbanken interagieren
  • Kapitel 13, Benutzerauthentifizierung und Sessionsicherheit
  • Kapitel 14, Der Umgang mit Sessions
  • Kapitel 15, Eine verteilte Umgebung einrichten
  • Kapitel 16, RPC: Mit entfernten Diensten interagieren

Dieser Thread wird mit der Zeit stetig erweitert.
Bei Fragen zum Buch oder Verbesserungsvorschlägen zu meinem Bericht könnt Ihr oben verlinkten Thread nutzen.

Ich hoffe, dass Euch diese Rezension hilfreich sein kann.
Grüße, Ben.

[Ben]

Kapitel 1, Programmierstile

Zitat aus der Einleitung

Kapitel 1, Programmierstile
Kapitel 1 führt in die in diesem Buch verwendeten Schreibweisen ein und entwickelt daran angelehnt einen Programmierstil. Die Wichtigkeit von konsistenten, gut dokumentierten Code wird hervorgehoben.

Klingt, als ob man das auch mal schnell überspringen könnte und direkt mit Kapitel 2 weitermachen könnte.

Nach dem Lesen behaupte ich, dass dieses Kapitel für die meisten Möchtegernprogrammierer das wichtigste Kapitel des Buches sein könnte.
Der Autor geht detailliert, aber nicht pingelig auf die unterschiedlichen Möglichkeiten ein, wie man Code strukturiert schreiben kann.
Dabei geht es vom konsequenten Einrücken, über die Vergabe und Struktur von Methoden-, Variablen- und Klassennamen bis hin zur richtigen Dokumentation mittels phpDocumentor.
Die Contra-Beispiele sind gut gewählt und letztlich stimme ich in den meisten Punkten mit ihm überein.
Ich bin kein großer PHP-Entwickler, also heißt das nicht so viel. Allerdings finde ich, dass dieses Kapitel für den Einstieg sehr angenehm war.

Der Autor stellt im ersten Kapitel keine wirkliche Anforderungen an den Leser, nichtsdestotrotz habe ich große Lust direkt weiterzulesen.
Gleichzeitig finde ich aber nicht, dass ich mir das Kapitel hätte sparen können, da es für mich doch hilfreich war zu sehen, wie solche "Dinge" in professionellen Kreisen gehandhabt werden.

Fazit: Ich habe Lust auf mehr!

[Ben]

Kapitel 2, Objektorientierte Programmierung mit Entwurfsmustern

Zitat aus der Einleitung:

Kapitel 2, Objektorientierte Programmierung mit Entwurfsmustern
In Kapitel 2 geht es ausführlich um die Funktionen zur objektorientierten Programmierung (OOP) von PHP 5. Die Möglichkeiten werden im Rahmen der Beschreibung verschiedener gebräuchlicher Entwurfsmuster vorgestellt. Das Kapitel enthält einen vollständigen Überblick über die neuen OOP-Funktionen von PHP 5 und die Grundprinzipien hinter OOP und eignet sich daher für OOP-Neulinge als auch für erfahrene Programmierer.

Der erste Teil dieses zweiten Kapitels beschäftigt sich mit einer kurzen und knappen Einleitung in die Materie der objektorientierten Programmierung.
In diesem Unterkapitel 2.1 (Einführung in die OOP) muss ich anmerken, dass der Übersetzer bzw. seine Korrekturleser doch einige Fehler in das Buch eingebaut haben.
Es sind nicht viele Tipp- und Zeichensetzungsfehler, aber doch genug, um etwas nachdenklich zu werden. Jedenfalls war das bei mir so!

Weiterhin taucht ein kleiner inhaltlicher Fehler auf Seite 64 (Kap. 2.1.1, Vererbung) auf

Beachten Sie, dass Sie den Konstruktor der Eltern-Klasse mit parent::constructor(); aufrufen, ..

Das muss natürlich parent::__construct(); heißen.

Generell zeigt sich auch in diesem Buch, dass es schwer ist zu erklären, was objektorientierte Programmierung auszeichnet bzw. was an ihr "so toll" ist.
Die Herangehensweise ist gut, aber ich vermisse teilweise .. hmm .. sagen wir mal die Entschlossenheit das Wissen auch wirklich "rüber zu bringen".

Der eigentlich recht simple Begriff der Kapselung im Speziellen die Nutzung der modifier wird hier etwas wirr beschrieben.

Sie können Methoden, die nicht "public" sind, bedenkenlos verändern (refactoring), ohne die Gefahr Programme zu zerstören, die auf dieser Klasse aufbauen. Private Methoden können Sie ungestraft verändern. Die Veränderung von "protected" Methoden verlangt mehr Sorgfalt, da hier vermieden werden muss, dass vererbte Klassen (subclasses) zerstört werden.

Kurzum: Hä?
Mein "Hä?" hat sich mittlerweile geklärt. Ein Denkfehler meinerseits. Hier steht etwas dazu.

Ich weiß, was die modifier machen und wie ich sie richtig einsetze, demnach sehe ich da mal drüber weg. Es soll aber hier angemerkt sein.
(Ein Tippfehler und ein Zeichensetzungfehler in einem Absatz sind imho zu viel!)

Ganz so schlimm ist der erste Teil des Kapitels im Ganzen nicht, aber so wirklich überzeugen tut er mich auch nicht. Das muss man so sagen.
Ich hatte ehrlich gesagt etwas mehr erwartet, vielleicht war das mein Fehler.

Der zweite Teil des Kapitels (2.2 Eine kurze Einführung in die Arbeit mit Entwurfsmustern) beschäftigt sich, wie der Titel schon vermuten lässt, mit Design Patterns in PHP.
Es sei gesagt, dass in Kapitel 2.3 (Lesetipps) das Buch "Design Patterns" von Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides empfohlen wird. Ich bin froh, dass ich es besitze, denn dieses Kapitel eignet sich vielleicht für einen Überblick, aber in meinen Augen nicht, um wirklich zu verstehen, wann man welche Entwurfsmuster verwenden kann/sollte und wann nicht.
Aber das ist auch nicht das Ziel des Buches, das sei gesagt.

Nichtsdestotrotz bin ich mit der ein oder anderen Passage nicht wirklich zufrieden.
Es werden das Adaptermuster (Kap. 2.2.1), die Schablone (2.2.2), das Fabrikmuster (2.2.5) und das Singleton-Pattern (2.2.6) dargestellt. Die ersten beiden hätte man meiner Ansicht nach besser darstellen können. Vor allem das Schablonen-/Template-Pattern geht absolut unter.

Mit den anderen beiden bin ich persönlich ganz zufrieden. Was ich mir gewünscht hätte, wäre z.B. das Facade-Pattern (Fassade). Aber nun gut, man kann schließlich nicht alles haben.

Da in die Vorstellung der Entwurfsmuster noch die Erklärung des Polymorphismus und eine Einführung in die Nutzung der "magic functions" __get(), __set(), __call(), __autoload() eingefügt wird, wirkt das Kapitel auf mich ehrlich gesagt etwas wirr.

Ich würde da eine 3+ verteilen, weil ich die Beispiele (die ich nicht alle durchgetestet habe) ganz nett und interessant fand.
Gerade weil Kapitel 2.1.4 den Titel "Spezielle Methoden" trägt (__construct(), __destruct(), __clone()) hätte man eventuell die Struktur auch etwas anders wählen können.
Nun gut, der Autor hat einen anderen, sicherlich akzeptablen, Weg gewählt und damit ist gut. Ich hätte es anders gemacht, aber mich fragt keiner.

Auf geht es ... Kapitel 3, ich komme!

[Ben]

Kapitel 3, Fehlerbehandlung

Zitat aus der Einleitung

Kapitel 3, Fehlerbehandlung
Fehler zu machen gehört zum Leben. Kapitel 3 deckt sowohl die prozeduralen als auch die objektorientierten Fehlerbehandlungsmethoden von PHP ab, wobei das Hauptgewicht auf den neuen Möglichkeiten von PHP 5 liegt, die auf der Verwendung von Ausnahmen beruhen.

Die Einleitung lässt es schon vermuten. Auch dieses Kapitel ist zweigeteilt.

Dieses Kapitel war auch ein Grund, warum ich dieses Buch überhaupt gekauft habe. Es steht als Leseprobe auf der offiziellen Produktwebseite von Addison-Wesley zur Verfügung. Schaut ruhig mal hinein.

Ich habe nun den ersten Teil fertig (Kapitel 3.1 und Kapitel 3.2).
Dieser Teil beschäftigt sich mit den grundlegenden, in PHP integrierten Fehlerroutinen und bietet einen, in meinen Augen, sehr gelungen, umfassenden Überblick über die Fehlerbehandlung in PHP.

Neben Erläuterungen zu den unterschiedlichen Fehlerebenen (E_NOTICE, E_WARNING und E_ERROR (ab PHP 5 noch E_STRICT)) findet man auch gut dargestellte Beispiele, warum man sich überhaupt mit der Behandlung von Fehlern befassen sollte.

Ich habe das bislang immer so gehandhabt, dass ich ein

PHP-Code:

error_reporting(E_ALL); 


zu Beginn meiner Skripte stehen hatte und damit war es getan. Ich habe mich nie wirklich mit dieser Materie befasst und ich kann nur sagen. So eine Übersicht habe ich gebraucht.
Die Informationen werden sehr gut "an den Mann gebracht". Jedenfalls geht es mir so.
In Kapitel 3.1.3 (Fehler ignorieren) wird die @-"Syntax" angesprochen. Diesbzgl. habe ich hier einen Thread eröffnet. Ich würde das Kapitel als "der Vollständigkeit halber hinzugefügt" beschreiben. Da es sich nur über eine halbe Buchseite erstreckt ist das sicherlich in Ordnung so!

Bevor ich mich Kapitel 3.3 bzw. dem Bericht über dasselbe zuwende möchte ich noch ein kurzes Zitat aus Kapitel 3.2 anbringen

Der Aufwand, per Hand Fehler durch mehrere aufrufende Funktionen durchzureichen, ist einer der Hauptgründe für die Implementierung von Ausnahmen in Programmiersprachen. Und jetzt unterstützt auch PHP in der Version 5 Ausnahmen.

Und genau aus diesem Grund werde ich mich jetzt etwas intensiver mit dem zweiten Teil des dritten Kapitels befassen.

So. Nach einer kleinen Pause bin ich nun am Ende des dritten Kapitesl angekommen und kann sagen, dass ich durch das Studium fortführender Quellen (z.B. das PHP-Manual) doch auf diesem Sektor, zumindest theoretisch, verbessert habe.

Der Autor erklärt recht detailliert, was Ausnahmen sind und wie sie syntakisch in PHP angewendet werden.
Einige Codeschnipsel sind nicht ganz korrekt, so ist natürlich eine Klasse

PHP-Code:

class AltException {} 


keine Exception, da die Klasse nicht von Exception erbt.
Dies sind aber Sachen, die man sich - sofern man es nicht weiß - mittels try & error und dem Nachschlagen im Manual selbst beibringen kann.
In meinen Augen könnte das sogar ein taktisch gesetzter Fehler sein, damit man mal sein Hirn einschaltet.

Es wird auf die Möglichkeit eingegangen ausführliche Fehlermeldungen zu produzieren bzw. sich diese von den Exceptions liefern zu lassen. Dies ist an einem Beispiel sehr gut erklärt und leicht verständlich. Ich möchte an dieser Stelle nicht auf das Beispiel eingehen.
Es sei nur auf die Seiten verwiesen: Seite 115 bis Seite 118 in Kapitel 3.3.2, Beispiel für eine typisierte Ausnahme.

Für mich war dann noch das Kapitel 3.3.4 (Fehler im Konstruktor behandeln) interessant. Das Kapitel ist sehr kurz gehalten vermittelt aber eine für mich wichtige Sache.
Wenn eine Exception innerhalb des Konstruktors geworfen wird, wie z.B. in diesem Beispiel

PHP-Code:

class Test {
    public function __construct() {
        throw new Exception();
    }

    public function __destruct() {
        echo 'destructing instance';
    }
} 


So wird der Destruktor nicht aufgerufen, weil das Objekt gar nicht erstellt wurde.
Dies war mir nicht bewusst und hat somit einen Wissensmangel bei mir ausgeglichen.

Kapitel 3.3.5 geht dann auf die Einrichtung eines Standard-Exception-Handlers ein. Sehr interessant, wie ich finde. Das Kapitel geht allgemein an die Sache heran, vermittelt aber einen guten Eindruck, warum solche ein Standard-Handler sinnvoll sein kann.
Es wird ein Beispiel für eine mögliche Implementierung geboten, allerdings denke ich, dass diese Implementierung auch vom System abhängt, indem der Handler verwendet werden soll.

Auch an dieser Stelle sei auf das PHP-Manual verwiesen!

Kapitel 3.3.6 passt meiner Ansicht nach nicht wirklich zum Kapitel "Fehlerbehandlung".
Der Titel "Daten überprüfen" machte mich neugierig, was denn Exceptions noch alles so zu bieten haben. Letztlich wird hier aber nur oberflächlich beschrieben, wie man Cross-Site-Scripting vermeidet bzw. Daten auf Ihre Validität prüft etc.
In meinen Augen an dieser Stelle absolut unpassend, weil in keinem Zusammenhang mit der Fehlerbehandlung, die man zuvor erläutert bekam.

Im Ganzen bin ich aber doch zufrieden mit dem Kapitel, da ich sehr viele neue, interessante Punkte kennengelernt habe, welche ich auch teilweise direkt umsetzen konnte.
Da ich Exceptions an sich schon aus Java kenne, ist das nichts Neues für mich. Nichtsdestotrotz war es für mich hilfreich zu sehen, was für Möglichkeiten einem Ausnahmen in PHP bieten.

Kritikpunkt ist neben dem unpassenden Kapitel über Cross-Site-Scripting und einigen kleineren Fehlern, das Fehlen von ein paar leckeren Tricks und Kniffen zur Anwendung von Ausnahmen in PHP.
Dies liegt aber eventuell daran, dass der Autor selbst nicht der absolute Liebhaber von Ausnahmen ist .. so kam es mir zumindest vor.

[Ben]

Kapitel 4, Templates und das Web: Implementierung mit PHP

Zitat aus der Einleitung

Kapitel 4, Templates und das Web: Implementierung mit PHP
In Kapitel 4 werfen Sie einen Blick auf Template-Systeme - Werkzeuge, die die Trennung von Anzeige- und Anwendungslogik vereinfachen. Die Vor- und Nachteile von kompletten Template-Systemen (als Beispiel dient Smarty) und Ad-hoc-Template-Systemen werden verglichen.

Dieses vierte Kapitel habe ich nur überflogen. Es umfasst auch lediglich 16 Seiten. Der Autor stellt - ich hatte es fast befürchtet - Smarty vor. Mal wieder!

Smarty ist für mich absolut uninteressant, da ich immer an eigenen Lösungen interessiert bin, die nur genau das machen, was ich brauche.

An dieser Stelle sei auf folgende Themen in diesem Forum hingewiesen:

Templates - Was sie bieten sollten!?
Ein eigenes Templatesystem schreiben, Tutorial
Ein einfaches Template-System, Tutorial

Nun gut. Der Autor beginnt das Kapitel mit folgender Aussage

Ein OOP-Schema, das sehr häufig bei der Programmierung von Webseiten verwendet wird, ist Model-View-Controller (MVC). MVC schreibt vor, dass eine Applikation in drei Komponenten aufgeteilt wird:

• Model: Der Kern des Programms, der zentrale Operationen ausführt
• View: Der Teil, der alle Ausgaben des Systems formatiert.
• Controller: Der Teil, der die Eingaben verarbeitet und an das Model weiterreicht.

[..]

Die meisten Websysteme erhalten Daten nur auf eine Art (über HTTP-Anfragen) und die Verteilung aller Eingaben wird mittels PHP vollzogen.

Aus diesem Grund besteht keine Notwendigkeit, sich über die Komponente Controller Gedanken zu machen.

Drei Sachen möchte ich dazu sagen:

1. PHP und das Observer-Pattern (MVC)
2. Ich verwende den Begriff Controller dennoch, da ich finde, dass man so trotz des Unterschiedes der Implementierung z.B. in Java etwas mehr Übersicht erhält, sofern man im Voraus klärt, was der Begriff bedeutet.
3. Es ist immer wieder erstaunlich wie viele Beschreibungen des MVC-Patterns es gibt.

Im Verlaufe des Kapitels wird darauf eingegangen wie Smarty installiert wird, wie man das erste "Hello world"-Template erstellt und wie man fortgeschrittene Techniken, wie spezielle Funktionen und den Smarty-Cache (Kapitel 4.2) verwendet.
Für Interessierte eventuell gut, mich hat es nicht interessiert!

Zum Schluss wird sehr kurz darauf eingegangen, wie man eine eigene Lösung implementieren könnte. In meinen Augen hätte man sich das aber auch sparen können, da die Beschreibung eher mager ist.

Fazit:
Uninteressantes Kapitel für mich, welches zum Glück sehr kurz gehalten war.
Kritikpunkt ist, dass der Autor kein gutes Beispiel für eine eigene Template-Engine bringt.
Er schreibt auf Seite 136

Smarty besitzt eine Menge Features, die meiner Meinung nach am besten ignoriert werden. Wie viele Template-Systeme hat es sich immer wieder in die falsche Richtung entwickelt. Das hat schließlich dazu geführt, dass die Templates vor komplexer Logik nur so strotzen.

Hört sich für mich nicht so an, als ob Schlossnagle ein Fan von Smarty wäre .. demnach wäre es schön gewesen zu sehen, wie er sich persönlich eine Template-Engine vorstellt.

Aber nun gut .. sei es drum!

[Ben]

Kapitel 5, Standalone-Skripts mit PHP implementieren

Zitat aus der Einleitung

Kapitel 5, Standalone-Skripts mit PHP implementieren
Ner sehr wenige Webanwendungen kommen heutzutage ohne Back-End-Komponente aus. Die Fähigkeit vorhandenen PHP-Code wiederzuverwenden, um Batchaufgaben, Shell-Skripts und nicht für die Verarbeitung im Web gedachte Routinen zu schreiben, ist für die Nützlichkeit einer Sprache in einer Unternehmensumgebung entscheidend. In Kapitel 5 werden die Grundlagen für das Schreiben von Standalone-Skripts und Daemons erörtert.

Ich habe dieses Kapitel bis zum Ende des Unterkapitels 5.1 gelesen und mich dann entschieden es erst einmal auszulassen.
Zum Einen habe ich derzeit keinen wirklich Verwendungszweck und zum Zweiten steht dort folgende Anmerkung

Da PHP auf Unix-Systemen [..] weiter verbreitet ist als auf Windows-Systemen, wird dieses Buch nur Unix-Beispiele anführen.

Da ich aber Windows-Nutzer bin und auch keine Unix-Umgebung zur Verfügung habe wäre eine intensive Bearbeitung des Kapitels nur schwerlich bis gar nicht möglich.

Ich hoffe, dass ich irgendwann mal auf dieses Kapitel zurückgreifen kann. Im Moment muss ich aber leider den Bericht für Kapitel 5 zurückstellen.

Danke für Euer Verständnis.

[Ben]

Kapitel 6, Unit-Tests

Zitat aus der Einleitung

Kapitel 6, Unit-Tests
Unit-Tests sind eine Möglichkeit, um sicherzustellen, dass Ihr Code das macht, was er tun soll. In Kapitel 6 lernen Sie Verfahren für Unit-Tests kennen und erfahren, wie Sie mit PHPUnit flexible Unit-Testsuites implementieren.

Im Voraus sei gesagt, dass ich vorher noch nie mit Unit-Tests gearbeitet habe. Weder in PHP, noch in einer anderen Programmiersprache (in meinem Falle würde sowieso nur Java in Frage kommen).

Als zentrale Aussage möchte ich einen Satz zitieren, der gleichzeitig der erste Satz und auch der erste Absatz in diesem Kapitel ist.

Testen und Entwickeln sollten immer eine Einheit bilden.

Hört sich sehr interessant an und klingt auch irgendwie logisch. Aber wir kennen es doch alle ... wir tun so, als wären wir faul. In Wirklichkeit haben wir aber nur nicht verstanden, wie wichtig Tests eigentlich sind bzw. sind dann doch zu faul, um uns mit diesem Thema intensiver zu befassen.

Bevor ich mit dem Bericht über dieses Buchkapitel beginne sei gesagt, dass es mir aufgezeigt hat, warum Tests wichtig sind!


Der Autor geht sehr intelligent an das Problem heran, welches ich oben beschrieben habe. Der Großteil der Programmierer versucht sich vor Tests zu drücken. Er untersucht, warum es so ist und wo der Trugschluss in den Argumenten der Entwickler liegt.

Dabei sei noch ein Zitat angefügt, welches ich unkommentiert stehen lassen möchte

Jede Software hat Bugs. Jeder Entwickler, der behauptet, seine Software sei immer fehlerfrei, lebt in einer Fantasiewelt.

Schlossnagle verweist auch kurz auf das Extreme Programming und die Verbindung zu Unit-Tests.

Die schrittweise Heranführung an den ersten Unit-Test und die effektive Nutzung von PHPUnit finde ich sehr gelungen. Ich bin wie gesagt totaler Neuling auf diesem Gebiet und somit kann ich wohl behaupten, dass die Vermittlung der theoretischen Grundlagen gut gelungen ist .. in meinem Empfinden jedenfalls.

Die Tests, die als Beispiel durchgeführt werden sind sicherlich nicht wirklich auf ein wirkliches System übertragbar, aber man erkennt schon, in welche Richtung dieses Tests laufen.
Automatisierte Tests, die eine komplette API einer Unit/eines System-Teilbereichs auf Korrektheit und Konsistenz überprüft.

Schlossnagle geht dabei auf verschiedene Wege ein, wie man größere Applikationen testen kann. So beschreibt er z.B. die Ansätze der inline Unit-Tests (Tests, die in den zu testenden Dateien implementiert sind) und der ausgelagerten Unit-Tests (Tests in separaten Dateien) ein.
Sehr interessante Gedankengänge, wie ich finde. Vor allem gibt der Autor an dieser Stelle auch ein persönliches Statement ab, was mich sehr freut.
Gerade das war ja auch ein Mitgrund, warum ich mir dieses Buch gekauft habe Ich möchte erfahren, wie ein Profi arbeitet!

Am Rande sei erwähnt, dass Schlossnagle den Weg der ausgelagerten Unit-Tests bevorzugt.


Ab Kapitel 6.3, Zusätzliche Features in PHPUnit, wird die Anwendung der Testsuiten fortgeschrittener. Es werden individuelle Fehlermeldungen erstellt, Testbedingungen hinzugefügt und erklärt, wie man weitere Effektivität in die Verwendung der Tests hineinbekommt.
Dieses Kapitel bringt meines Erachtens einen sehr guten Ausblick auf das, was man mit PHPUnit alles machen kann.
Den Rest kann man dann z.B. hier nachlesen:
http://www.phpunit.de/pocket_guide/3.0/en/
(die aktuelle Version des Buches ist noch nicht auf deutsch verfügbar!)

In Kapitel 6.4, Durch Tests beeinflusstes Design, wird auf die Methode des Test-Driven-Development (TDD) eingegangen. Sehr interessantes Thema, über welches ich nochmal in Ruhe nachdenken muss.
TDD geht nach dem Prinzip vor, dass man vor der ersten Codezeile des Systems den ersten Test schreibt, der dieses System testet.
Klingt paradox, ist aber genau so gewollt. Der Test schlägt natürlich fehl, weil ja gar nichts existiert, was man testen könnte.
Da man aber durch die Konzeption des Systems feste Resultate im Test erwartet, ist man also nun in der Lage Code zu implementieren, der letztlich den Test besteht.
So verfährt man mit allen Testbereichen und erhält am Ende ein komplett getestetes System.
Ist jetzt nicht gut erklärt, aber das Prinzip sollte schon klar geworden sein.

Der Autor bringt diesbzgl. ein recht nettes Beispiel, welches ausführlichst besprochen wird.


Ich habe nun immer noch keinen wirklichen Test geschrieben. Ich bin also praktisch gesehen kein bisschen schlauer, als vorher.
Nichtsdestotrotz hat mir das Kapitel etwas gebracht, nämlich das Verständnis, warum es überhaupt wichtig ist - vor allem bei großen Applikationen - zu testen!

Nächster Anlaufpunkt diesbzgl. wird dann wohl oben verlinktes OpenBook sein.
Wirklich klasse. Habe eben auch schon dort etwas quergelesen und muss sagen, dass ich dieses Thema doch interessanter finde, als ich mir das gedacht hätte.

Fazit:
Das Kapitel hat seinen Zweck in meinem Fall mehr als erfüllt.
Es hat mir eine sehr gute Einleitung gegeben, aufgepeppt mit einer Menge Beispielen, die auch zu Ende implementiert und besprochen wurden.
Es wurde auf fortgeschrittene Möglichkeiten hingewiesen, welche man sich dann selbst aneignen kann.

Perfekt!
Das war ein geniales Kapitel! Schulnote: 1!
Auf die Richtigkeit der Quellcodes gebe ich an dieser Stelle nicht Acht, weil es für mich keine Bedeutung hat.

[Ben]

Kapitel 7, Entwicklungsumgebungen verwalten

Zitat aus der Einleitung

Kapitel 7, Entwicklungsumgebungen verwalten
Die Verwaltung des Codes ist für die meisten Entwickler nicht gerade die spannendste Aufgabe, aber sie ist nichtsdestoweniger entscheidend. Kapitel 7 zeigt die Verwaltung von Code in umfangreichen Projekten auf enthält eine umfassende Einführung in die Verwendung von CVS(Concurrent Versioning System) zur Verwaltung von PHP-Projekten.

Aufgrund der Tatsache, dass ich durch das Gemeinschaftsprojekt der Mitglieder dieses Boards nun aktiv in einem Team mitarbeite und dort natürlich eine Versionierungssoftware, in unserem Fall Subversion, verwendet wird, war dieses Kapitel ebenfalls sehr interessant für mich.

George Schlossnagle geht zwar intensiv auf die Handhabung von CVS ein, nichtsdestotrotz sind die Ausführungen aber sehr gut für das generelle Verständnis einer solchen Software zu gebrauchen.
Hat mir doch weitergeholfen!

Ich habe mich aufgrund dieses Kapitels auch dazu entschlossen ab sofort generell alle meine Projekte mittels Subversion zu verwalten, wobei es da egal ist ob Subversion, CVS oder eine andere Anwendung.
Ein Zitat

CVS erlaubt es mir, schnelle Änderungen an meinen Projekten vorzunehmen, ohne einen Satz Sicherungskopien mit mir herum zu schleppen.

Habe ich noch nie drüber nachgedacht .. aber danke. JA! Genau so ist es doch! Immer diese Sicherheitskopien. Ätzend!

Ich will an dieser Stelle gar nicht so tief darauf eingehen, was dort alles beschrieben wird. Kurzgesagt reicht der Überblick von simplen commit bis zum branchen, symbolischen Tags und der Verwaltung von Produktiv- und Entwicklungsumgebungen!
Der Autor geht dabei öfters davon aus, dass man kein SharedServer verwendet, allerdings ist das auch gut so, da wir hier ja von "PHP im Unternehmen" sprechen und nicht von irgendwelchen SharedHosting-Möchte-Gern-Webentwicklern, die gar nicht wissen, dass man ein Gewerbe anmelden muss, wenn man gegen Geld arbeitet.


In Kapitel 7.2, Verwalten von Paketen, wird auf die Problematik eingegangen, dass Applikationen auf unterschiedlichen Systemen unterschiedliche Fehler produzieren können, und das man aus diesem Grund Komplettpakete inkl. dem Apachen, PHP, ... ausliefern sollte.
Auch hier merkt man, dass von einem kompletten Root-Zugriff ausgegangen wird.


Generell gilt, wie auch in Kapitel 6, dass der Autor hier sehr gute Arbeit geleistet hat, was die Darstellung von grundlegenden Problemen, Argumenten, Vor- und Nachteilen des Projektmanagements angeht.

Auch hier habe ich bislang nichts ausgetestet. Das kommt später.
Ich nehme aber auch aus diesem Kapitel folgende Informationen mit

• theoretisches Grundlagenwissen zur Handhabung eines Versionierungssystem (Subversion != CVS, aber das passt schon!)
• den Entschluss mich intensiver damit zu befassen und meine lokale Entwicklungsarbeit in Subversion einzupflegen

Wiederum kann ich nur sagen: Herzlichen Glückwunsch zu einem sehr guten Kapitel, welches Lust auf mehr macht.
Mal sehen, ob mir nicht noch ein Buch bzgl. Subversion zulege.

Das Thema hat mich zuvor schon interessiert und das wurde nun noch gesteigert.

Weiter geht es zu Kapitel 8!

[Ben]

Kapitel 8, Eine gute API erstellen

Zitat aus der Einleitung

Kapitel 8, Eine gute API erstellen
Kapitel 8 enthält Richtlinien für die Entwicklung von verwaltungsfreundlichem, flexiblem und leicht mit anderen Projekten zusammenzuführendem Code.

Das Kapitel beginnt mit einer vom Autor aufgestellten Definition von "gutem Code".

• Er muss gut zu warten sein.
• Er hat minimale externe Abhängigkeiten.
• Er ist anpassbar an neue Probleme.
• Sein Verhalten ist sicher und vorhersagbar.

Diese Liste kann noch ergänzt werden durch die folgenden drei Kategorien:

• Er muss veränderbar sein.
• Er muss erweitert werden können.
• Er muss defensiv geschrieben sein.

Schlossnagle bringt die Begriffe "bottom-up"- und "top-down"-Design ins Spiel. Die Beschreibung gelingt im gut. Grob zusammengefasst besteht der Unterschied darin, dass beim "bottom-up"-Design in einer frühen Konzeptionsphase Basisquellcode implementiert wird und diese Komponenten dann im Verlaufe der Planungsphase zu einer API zusammengefasst werden.
"top-down"-Design ist, wie zu vermuten, das genaue Gegenteil. Dabei wird zuerst die komplette API geplant, also alle Klassen durchkonzipiert und danach auf Basis dieser API die Implementierung der Komponenten begonnen.
Es werden Vor- und Nachteile der beiden Vorgehensweisen angesprochen.

Es wird klargestellt, dass eine stabile, solide API extrem wichtig ist, um produktiv entwickeln zu können.

Danach wird auf unterschiedlichste Sachen eingegangen, die die Stabilität und Wiederverwend- und Wartbarkeit des Quellcodes verbessern können.
Das Kapitel 8.1.1, Logik in Funktionen kapseln, war für mich eher uninteressant, da es in meinen Anwendungen sowieso keinen prozeduralen Code und keine Funktionen mehr gibt.
Dieses Kapitel hat mir nichts Neues vermittelt.

Im Weiteren wird darauf eingegangen, Klassen und Methoden so simpel wie möglich und nur so komplex wie nötig zu halten, um die Wiederverwendbarkeit einzelner Methoden und Klassen zu "gewährleisten".

Kapitel 8.3, Namespaces, ist in meinen Augen etwas "wirr". Es geht darum in PHP ein Paketsystem oder Namespaces zu simulieren, um die Zugehörigkeit bestimmter Funktionen zueinander darzustellen.
Ich glaube, dass dieser Abschnitt aussagen soll, dass man eine konsistente Namensgebung bei z.B. Klassen verwenden soll, um direkt sehen zu können, was eine Klasse macht.
Das ist aber nur eine Vermutung von mir. So wirklich erklärt wird dies dort nicht. Sollten dort Vorkenntnisse irgendwelcher Art nötig sein, so wird man nicht darauf hingewiesen, weder direkt noch indirekt.

Nun gut.
George Schlossnagle sagt danach aus, dass er an Dateien, die er per include einbindet immer ein .inc anhängt. Ähm .. ja. Damit man den Quelltext sieht oder wie? Ich denke mal, dass da sicherlich irgendwas am Apache eingestellt wird, dass die Dateien nicht im Browser angezeigt werden, aber das wird im Buch nicht angegeben.

Danach wird kurz darauf eingegangen, wie man am besten Dateien per include einbindet. Soll man viele Dateien einbinden oder nur wenige mit mehr Code?
Interessiert mich insofern nicht, da ich mit __autoload() arbeite und nur das einbinde, was ich brauche.

In Kapitel 8.3, Kopplung, wird auf die Abhängigkeit von Klassen, Methoden untereinander eingegangen. Eine zu starke Abhängigkeit sollte ja vermieden werden. Das ist ja einer der Kernpunkte der Definition von gutem Code.
Nichtsdestotrotz kann es nach Schlossnagle auch stabile Punkte in einer Anwendung geben, die Sinn machen. So z.B. Klassen, die den Datenbankzugriff ermöglichen. Diese Basisklassen sollten im Voraus lang und intensiv geplant werden bevor zu viel Code der Applikation geschrieben wurde, damit Änderungen an der API der Basisklassen nicht zu einem riesigen Arbeitsaufwand führt, der durch die Aktualisierung aller Codepassagen hervorgerufen werden würde, die die alte, nicht mehr aktuelle API der Basisklasse nutzen.

Das letzte Unterkapitel beschreibt was mit "defensivem Programmieren" gemeint ist. Es geht dabei um die Programmierung von Code ohne unbegründete Annahmen zu machen.
Es geht z.B. um die Tatsache, dass PHP typenlos ist, eine Variable also jeden Datentyp annehmen kann.
Es ist also auf jeden Fall anzuraten Type hints zu verwenden, da somit zumindeste sichergestellt werden kann, dass ein Objekt auch wirklich vom gewünschten Typ ist.
Weiterhin ist es wichtig Standardkonventionen zu erstellen, die dann API-übergreifend verwendet werden.

Der Autor bringt ein sehr gutes Beispiel:

Ein hervorragendes Beispiel für inkonsistente Argumentenreihenfolge sind die MySQL- und PostgreSQL-APIs in PHP. Hier sehen Sie die Prototypen der Abfrage-Funktionen aus jeder Bibliothek

resource mysql_query( string query [, resource connection])
resource pg_query( resource connection, string query)

Obwohl der Unterschied deutlich dokumentiert wird, ist er verwirred.

Heißt also, dass man frühzeitig gewisse Regeln festlegen sollte, um die Übersichtlichkeit innerhalb der API zu wahren.

Zum Abschluss des Kapitels kommt wieder ein bisschen was in Richtung Sicherheit. Ist ja ganz nett, aber hätte man dann nicht lieber ein eigenes Kapitel dazu geschrieben, anstatt die Sachen an die Enden unterschiedlicher Kapitel zu klatschen?


Fazit:
Für mich war das hier ein Übergangskapitel. Habe Kenntnisse etwas aufgefrischt, aber wirklich neu war nichts bzw. wenig.

Freue mich aber schon auf Kapitel 9, Externes Tuning der Performance.

[Ben]

Kapitel 9, Externes Tuning der Performance

Zitat aus der Einleitung

Kapitel 9, Externes Tuning der Performance
Cachingverfahren bilden den einfachen und zugleich effektivsten Weg, um die Leistung und Skalierbarkeit einer Anwendung zu erhöhen. Kapitel 9 deckt externe Cachingverfahren sowie Compiler und Proxy-Caches ab.

Zu Beginn ein Wort zu diesem Kapitel und meinen Vorkenntnissen auf diesem Bereich.

• Ich bin der absolute Laie, was die Installation, Konfiguration und Wartung von Webservern, PHP, ... angeht. Heißt also, dass ich mich noch nie mit solchen Dingen befasst habe. XAMPP ist halt einfach und schnell zu handhaben.
• Gerade aufgrund meiner Vorkenntnisse behaupte ich: Das Kapitel ist genial. Ich habe es gefressen! Es hat riesiges Interesse bei mir geweckt, da ich gerne selbst wissen möchte, welche Performanceverbesserungen man mit einfachsten Mitteln realisieren kann.

Nun aber zum Kapitel!

Eine Aussage im Vorwort des Autors bringt es eigentlich auf den Punkt

Die wichtigste Voraussetzung für eine gute Performance ist sorgfältiges und solides Design und eine gute Programmiermethode.

Dem ist nichts hinzuzufügen.
Allerdings fügt er umgehend an

Aber abgesehen davon gibt es eine Anzahl Tunings, die Sie zur Verbesserung der Leistung außerhalb von PHP einsetzen können.

Voraussetzung für dieses Kapitel bzw. dessen Inhalt ist also, dass man Zugriff auf den Webserver hat. SharedHosting-Pakete haben da wohl im Regelfall kein Glück.

Als erstes werden Compilercaches behandelt. Habe ich noch nie etwas von gehört, aber es tönte ganz interessant.
Letztlich ist das Prinzip, dass Quellcode-Datei, sei es Hauptskript oder "include"-Datei, nur dann kompiliert wird, wenn sie nicht im Cache vorhanden ist.
Klingt meinem Eindruck nach simpel und genial.
Der Autor gibt folgende Compilercaches an

• Zend Accelerator
• ionCube Accelerator
• APC (in PECL enthalten)

Das nächste Unterkapitel gibt einen kurzen Einblick in Optimierungsverfahren. Nicht allzu interessant und auch ein recht kurzes Kapitel.
Das Interesse mangelt etwas, da der Autor nur von kleinen Performanceverbesserungen spricht.
Ich weiß, Kleinvieh macht auch Mist, aber der Rest von Kapitel 9 tönt da eindeutig besser.

Interessant sind dann z.B. Reverse-Proxys, welche zwischen den Client und den eigentlichen Webserver mit PHP geschaltet werden.
Das Problem bei großen Latenzzeiten ist es, dass die Daten, die vom Server zum Client geschickt werden müssen Zeit beanspruchen. Heißt, dass die PHP-Anwendung sozusagen im Leerlauf ist, während die Datenpakete gesendet und emfangen werden.
Wird ein Reverse-Proxy zwischengeschaltet, der z.B. auf der selben Maschine wie der Webserver mit PHP liegt, so besteht zwischen diesen beiden Instanzen eine geringe Latenzzeit, was es dem "PHP-Server" erlaubt die Daten schnell zum Proxy-Server zu verschicken und dann "weiterzuarbeiten". Der Leerlauf wird umgangen!

Mal grob beschrieben, wie ich das jetzt verstanden habe.

Der Autor beschreibt an dieser Stelle die Änderungen in den beiden httpd.conf-Dateien der Apache-Webserver, so dass man eigentlich nur noch lostesten müsste (was ich aber gerade leider nicht machen kann. )

Fazit: Sehr interessante Sache, von der ich bisher noch nie etwas gehört habe. Mal sehen, was ich da noch so zu im Web finde!


Danach kommt Schlossnagle zum "Tuning des Betriebssystems für gute Performance". Heißt so viel wie, dass man auch das Betriebssystem dazu veranlassen kann Daten zu buffern und somit Netzwerkverzögerungen zu minimieren. Klingt auch simpel und ist sicherlich eine Überlegung wert.


Letztlich werden noch Proxy-Caches erwähnt. Eine Kombination aus Reverse-Proxys und Cachingverfahren.
Das Prinzip sieht aus, wie beim Reverse-Proxy, nur dass hier zwischen dem Proxy und dem Apache mit PHP noch ein Cache liegt. Ist die Seite im Cache vorhanden leitet der Proxy die Anfrage als gar nicht an den Webserver weiter, sondern sendet die gecachte Seite an den Client!

Kapitel 9.2, "Cachefreundliche PHP-Anwendungen", beschreibt, wie man PHP-Applikationen eigentlich cachebar macht. Ein nicht minder interessantes Thema, weil es hier doch einige Sachen gibt, die ich so nun nicht wusste oder kennengelernt hätte (vermute ich mal).

Es geht hier primär um unterschiedliche "header", die man mit PHP senden kann. Es wird auch auf Unterschiede zwischen der HTTP 1.0- und der HTTP 1.1-Spezifikation eingangen. Gut und leicht verständlich beschrieben und somit für mich als Einstieg ausreichend.
Schlossnagle gibt eine Menge Informationen, die mich zuerst etwas erschlagen haben. Ich lese für die Erstellung dieser Rezension jetzt ja nochmals quer und jetzt verstehe ich doch schon einiges mehr.
Fazit: An den richtigen Stellen PHP-Code eingebracht, so dass man das Prinzip leicht versteht.

Als Beispiel

Betrachten Sie eine Weblog-Applikation, die auf einer Seite alle neuen Beiträge zeigt:

PHP-Code:

$dbh = new DB_MySQL_Prod();
$result = $dbh->execute("SELECT max(timestamp) FROM weblog_entries");

if($result) {
    list($ts) = $result->fetch_row();
    validate_cache_header($ts);
} 


Zum Schluss wird noch kurz auf die Verwendung der zlib-Bibliothek eingegangen, Stichwort "Content-Komprimierung".


Alles in allem ein sehr interessantes Kapitel, welches mir persönlich viele neue Informationen hat zukommen lassen und welches auch Interesse bzgl. dieses Themas "entfacht" hat.

Fazit: Super!

Auf geht es in Kapitel 10, Partielles Cachen von Daten.

[Ben]

Kapitel 10, Partielles Cachen von Daten

Zitat aus der Einleitung

Kapitel 10, Partielles Cachen von Daten
In Kapitel 10 werden Möglichkeiten beschrieben, um Cachingverfahren in den PHP-Code selbst zu integrieren. Es wird erklärt, wie und wann Sie so vorgehen sollten. Außerdem wird ein voll funktionsfähiges Cachingsystem mit mehrfachen Speicher-Back-Ends entwickelt.

Nach Kapitel 9, den externen Verfahren um die Performance zu erhöhen, geht es nun sozusagen ans Eingemachte.
Cachen von Daten ist überall da wichtig, wo es viele Datenbankabfragen pro Seitenaufruf gibt. So könnte man das grob umschreiben.

Der Autor gibt zunächst einen Einblick in Listenform über Basiswissen bzgl. des Cachens von Daten, auf was man eben so achten muss, wie z.B. Aktualität des Cache oder Kohärenz.

Danach kommen einige kleinere Subkapiteln, die Einblicke in unterschiedliche Sparten geben. Kapitel 10.4 geht z.B. kurz auf die Möglichkeiten des Output Bufferings ein.
Richtig interessant wird es dann ab Kapitel 10.5, Speicher-Cache. Hier werden Möglichkeiten dargestellt, wie man Daten in Dateien cachen und somit wiederverwenden kann.
Weiterhin wird hier stark auf Problematiken der einzelnen Verfahren eingegangen, so z.B. das Problem, das man bei normalen Textdateien beim gleichzeitigen Schreiben und Lesen aus einer Datei erhält. Wie sichert man ab, dass man keine korrumpierten Daten erhält?
Es werden generelle Lösungswege zur Wartung der Cache-Größe, Gleichzeitigkeit und Kohärenz des Caches besprochen. Falsch! Es muss heißen: Sehr gut und ausführlich besprochen!
Als Bespiel: Es wird z.B. ausführlich auf die Problematik der PHP-Funktion flock() eingangen, die man ja gerne mal verwenden möchte und es eventuell auch tut, ohne sich größere Gedanken darüber zu machen.
Wirklich interessant und einleuchtend - auch für Laien wie mich - beschrieben!

In Kapitel 10.6 geht Schlossnagle auf das Cachen aus DBM-Basis ein. Erstaunlich, dass ich davon noch nie etwas gehört habe.
Hat mich so fasziniert, dass ich um 4:40 immer noch hier sitze, weil ich solange herumgespielt habe.

In den folgenden Unterkapiteln wird wiederum auf Probleme und Ihre Lösungen bzw. Workarounds, Vor- und Nachteile eingangen.
Ich bin wirklich mehr als zufrieden.

Kapitel 10.8, Cachen mit Cookies, behandelt das, was der Titel besagt. Ich habe das noch nicht ausgetestet, allerdings ist allein schon diese Aussage von Schlossnagle Grund dafür mal auszutesten, wie das denn so funktioniert und wie man es theoretisch denn auch effektiv anwenden könnte.

Wenn Sie sehr viele Benutzer haben, kann selbst das Cachen weniger Daten pro Benutzer große Mengen an Speicherplatz auf dem Server verbrauchen.

Man muss dazu sagen, dass es in dem Kapitel nicht allein um das Caching von allgemeinen Seiten geht, sondern auch um das Caching von z.B. Warenkörben in einem Shop, während der User einkauft!
Eine Verbindung von Cookie-basiertem Cache und Cache via Textdatei oder DBM wäre sicherlich interessant.

Schlossnagle bringt einem dieses Verfahren näher und es klingt wirklich gut. Er geht auch auf Gegenargumente wie z.B. die erhöhte Bandbreitennutzung ein. Wirklich interessant. (Ich wiederhole mich .. bin halt begeistert )


Die Unterkapitel 10.9.x bringen dann lediglich noch einen Einblick, wie man die Theorie auch praktisch in einer PHP-Anwendung unterbringen kann. Ist etwas ungewohnt sag ich mal, da dort eben komplett ohne Template-Engine gearbeitet wird, aber nun gut.
Es wird noch kurz auf die Möglichkeiten von mod_rewrite eingegangen, welches man tricky für Cachingmechanismen ausnutzen kann und danach noch kurz auf die Notwendigkeit Abfragen zu cachen, z.B. wenn man via SOAP auf Daten zugreifen möchte.

Die Prinzipien kann man erkennen - da gut beschrieben -, auch wenn Schlossnagle hier doch den ein oder anderen Tippfehler im Quelltext hat.
Alles keine schlimmen Sachen, wenn man mitdenkt, aber ein wenig nervig ist das schon, weil es sich ja bislang - wenn auch in Grenzen - durch das ganze Buch zieht.

Fazit zu Kapitel 10: Hat mir einen guten Einblick ins Thema Caching innerhalb von PHP-Anwendungen gegeben. Da werde ich mich auf jeden Fall noch etwas genauer mit befassen.

[Ben]

Kapitel 11, Wiederverwendung von Berechnungen

Zitat aus der Einleitung

Kapitel 11, Wiederverwendung von Berechnungen
Kapitel 11 behandelt die Frage, wie einzelne Algorithmen und Prozesse durch das Caching von Zwischendaten effizienter gemacht werden können. In diesem Kapitel wird die grundlegende Theorie entwickelt, die hinter der Wiederverwendung steht, und auf praktische Beispiele angewendet.

Ich halte mich mit der Beurteilung dieses Kapitels kurz, da ich an dieser Stelle gerne auf dieses Tutorial hier
Wiederverwendung von Berechnungen, effektives Caching
verweisen möchte.

Dieses Tutorial enstand nur, weil Schlossnagle mich mit diesem Kapitel für diese Theorie faszinieren konnte. Das Beispiel habe ich übernommen, den Quellcode etwas umgebaut und vor allem auch berichtigt .

In diesem Kapitel geht er in einer Randbemerkung auch intensiv auf die Berechnung der Komplexität eines Algorithmus ein. Mir persönlich war das etwas zu viel, aber wen die Berechnung der "O"-Geschwindigkeit interessiert, der wird da schon etwas lernen können.

Die Theorie der Wiederverwendung der Datenhäppchen ist sehr gut beschrieben. Mehr braucht man dazu nicht sagen.
Problematisch wird es dann bei der praktischen Anwendung. Beim besten Willen, aber ich sehe die Erstellung eines Lesbarkeitsindex nicht als praktische nützliche Anwendung an.

Die Frage nach dem Anwendungsbereich habe ich nicht klären können. Zu lesen hier:
http://forum.developers-guide.net/sh...5435#post35435


Letztlich geht wird noch kurz auf Wiederverwendungen von Berechnungen in PHP selbst eingegangen.
Für mich eher uninteressant, aber nunja.

Das Kapitel ist letztlich schwer zu bewerten. Auf der einen Seite eine, wie ich finde, geniale Theorie, aber auf der anderen Seite fehlt einfach die praktische Anwendung, die mir zeigt, wo ich das in meinen PHP-Applikationen dann auch einsetzen kann.
Wirklich viele Fibonacci-Zahlen oder Lesbarkeitsindizes werde ich in meinem Leben nicht berechnen bzw. erstellen.

Schulnote 2-, wegen der Theorie!