Ralfs Zend Framework und PHP Blog

Stefan Esser hat in seinem Vortrag “Lesser Known Security Problems in PHP Applications” den Schwerpunkt auf weniger bekannter, aber nicht minder gefährliche Sicherheitsprobleme in PHP Anwendungen gelegt. Diese werden in vielen anderen Vorträge zur PHP Security meistens nicht erwähnt oder nur am Rande.

Auch wenn die Folien noch nicht über die IPC Website abrufbar sind (folgt wohl in Kürze), könnt ihr euch diese von einem älteren Vortrag z.B. als PDF hier downloaden oder bei Slideshare anschauen. Inwieweit diese vom gestrigen Vortrag evtl. abweichen, erschließt sich mir nicht auf den ersten Blick. Im wesentlichen stimmen sie aber überein.

Einfach zusammen gefasst kann man seine mit vielen Beispielen gespickten Kernaussagen wie folgt zusammen fassen:

• $_REQUEST nicht verwenden
• auto_globals_jit in der php.ini abschalten
• für jede Anwendung ein eigenes Verzeichnis für die temporären Sessiondaten verwenden und in der Session einen Application Marker verwenden
• Datenbanktransaktionen für Anwendungstransaktionen verwenden, alle Fehler der Datenbank behandeln
• den Random Number Generator nicht selber anstossen (seed), keine erstellten Zufallszahlen ausgeben und vor allem keine Zufallszahlen für sicherheitsrelevanten Daten wie Passwörter verwenden

Viele der genannten Sicherheitsprobleme waren mir bisher tatsächlich nicht bekannt, auch wenn ich sie selber gar nicht nutze (wie z.B. $_REQUEST). So konnte ich aus dem Vortrag so einiges mit nehmen. Wer nicht selber da war, sollte sich zumindest die Slides von Stefan anschauen.

Der Vortrag von Stefan Priebsch zum Thema “Best of Two Worlds: eZ Components & Zend Framework” behandelte (wie überraschend) die eZ Components und das Zend Framework. Stefan berichtete von seinen persönlichen Eindrücken zu beiden Frameworks und stellte einige Komponenten beider Frameworks heraus, die er für besonders erwähnenswert hielt.

Die eZ Components können mit Hilfe von PEAR, aus Subversion heraus oder durch ein komprimiertes Archiv installiert werden. Das Zend Framework kann ebenfalls per Subversion oder durch ein komprimiertes Archiv installiert werden. Es gibt für das ZF aber nur ein inoffziellen PEAR Channel. Eine Besonderheit der eZ Components ist, dass alle Komponenten auf der Klasse ezcBase basieren.

Stefan ist kurz auf die unterschiedlichen Begrifflichkeiten eingegangen. Bei den eZC ist der Name “Components” bereits enthalten und weist darauf hin, dass es sich um eine Komponentensammlung handelt. Beim ZF ist der Name “Framework” enthalten und weist darauf hin, dass es sich um ein Framework handelt. Wenn man mich fragen würde, würde ich sagen, dass beide sowohl als Komponentensammlung als auch als Framework eingesetzt werden können. Was beide nicht sind: Fullstack-Frameworks, die einen mit Konfigurationsdateien erschlagen und jegliches Denken abzunehmen versuchen. Aber zum Glück fragt mich ja niemand… ;-)

Im weiteren Verlauf hat Stefan die jeweiligen Model-View-Controller Implementationen in Form von Grafiken für die eZC und das ZF gezeigt. Kleine Anmerkung dazu: die Grafik zum ZF zeigte im Prinzip nur den Ablauf, wenn man Zend_Controller_Front verwendet. Der Model und der View Part ist dort gar nicht enthalten.

Stefan hat danach einige nützliche Komponenten der eZC ausführlicher vorgestellt:

• ezcArchive
• ezcGraph
• ezcMail
• ezcSearch

Und auch aus dem ZF hat er einige Komponenten herausgepickt:

• Zend_Acl
• Zend_Pdf
• Zend_Mail *)
• Zend_Search_Lucene

Zum Schluss zeigte Stefan kurz auf, wie man beide Welten kombinieren kann, was durch die Autoloader-Funktion schneller geht als Nase putzen.

Auf die Frage, wer denn alles die eZ Components und das Zend Framework einsetzt, gabe es eine leichte Tendenz in Richtung des Zend Frameworks. Ich selber habe meinen Schwerpunkt bekanntlich auf das Zend Framework gelegt. Aber ich empfehle jedem, der noch auf der Suche ist, auch die eZ Components in die engere Auswahl aufzunehmen und diese gründlich auf die eigenen Bedürfnisse hin zu untersuchen.

*) Kleiner Hinweis, der mir erst später eingefallen ist: Zend_Mail bietet natürlich auch die Möglichkeit, Emails per POP3, IMAP, usw. abzurufen.

Als erstes war ich heute im Vortrag “Seven Steps to Better PHP Code” von Stefan Priebsch. Völlig überraschend hat Stefan tatsächlich sieben Schritte für besseren PHP Code präsentiert. Es folgt ein Versuch, diese zusammen zu fassen.

Schritt 1: Formatiere deinen Programmcode einheitlich

Nach ein paar Beispielen für schlecht formatierten Programmcode, empfahl Stefan für die eigenen Projekte einen Coding Standard zu etablieren bzw. einen vorhandenen zu nutzen. Zudem sollte man für bestehenden Code einen Code Beautifier verwenden.

Schritt 2: Führe Namenskonventionen ein

Es empfiehlt sich, in seinen Projekten Namenskonventionen für Variablen, Methoden, Klassen, Funktionen und auch für Dateien festzulegen und durchgehend einzuhalten. Nichts ist unnötiger, als den Lesefluss bei einem Programmcode durch nichtssagende Variablen oder Methoden zu verschlechtern. Besonders bei Dateinamen sollte man aufpassen und diese möglichst einfach halten (Buchstaben, Zahlen, Bindestrich, Unterstrich), da es bei Portierung auf andere Betriebssysteme sonst Probleme geben kann.

Schritt 3: Erstelle API Dokumentation

Viele Entwicklungsumgebungen helfen dem Programmierer bereits dabei, alle Funktionen, Klassen, Methoden und Schnittstellen mit Dokumentblöcken und Document Tags auszustatten. Mit Tools wie PHPDoc kann man daraus prima eine API Dokumentation erstellen lassen. In Zukunft sollte dann schon ein Blick in die API Dokumentation ausreichen, um die Funktionsweise zu verstehen.

Schritt 4: Beseitige redundanten Programmcode

Man sollte doppelten oder ähnlichen Code vermeiden, dabei aber aufpassen, dass man es nicht übertreibt und keine über-generalisierten Funktionsmonster erstellt. Bevor man dies macht, sollte man lieber refaktorisieren. Ziel ist es, dass man Codeänderungen nur an einer Stelle vornehmen muss und nicht an 12 verschiedenen Stellen.

Schritt 5: Kürze Codeblöcke

Programmcodeblöcke sollten so kurz wie möglich sein und 700zeilige Codemonster sollten vermieden werden. Der Programmcode sollte lieber in kleinere Einheiten aufgeteilt werden. Dabei gibt es zwei Faustregeln: erstens sollte eine Methode oder Funktion auf eine Bildschirmseite passen und zweitens sollte man jede Methode oder Funktion in 30 Sekunden erfassen können. Ist dies nicht der Fall, ist das Ganze zu komplex und gehört refaktorisiert.

Schritt 6: Trenne verschiedene Belange

Dinge, die nichts direkt miteinander zu tun haben, sollten aufgeteilt werden. Beispiele sind das Dreischichtenmodell oder das Model-View-Controller Entwurfsmuster. Ausserdem sollte man Funktionalitäten wie Hinzufügen, Ändern und Entfernen separieren und auch keinen SQL Code in die Nähe des HTML Codes lassen. Die Trennung vereinfacht das Unittesting, erlaubt die Wiederverwendbarkeit von Code und erleichtert das Lesen des Codes. Stefan hat auch ein schlechtes Beispiel gezeigt, bei dem Datenbankabfragen, Geschäftslogik und die Ausgabe miteinander vermischt wurden.

Schritt 7: Ersetze Implementationen

Hier geht es ans Eingemachte, weil dies vielen Entwicklern schwer fällt. Stefan empfiehlt, wo immer es möglich ist, eigene Komponenten durch externe Komponenten auszutauschen. Statt einer eigenen Mailklasse kann man auch ezcMail oder Zend_Mail verwenden. Manches was vor langer Zeit nicht möglich war, ist heute in PHP selber implementiert. Da lohnt sich ein Blick ins PHP Manual. Generell ist es empfehlenswert auf Komponentensammlungen wie PEAR, eZ Components oder das Zend Framework zurückzugreifen.

Schritt 8: Refaktorierung

Eigentlich kein eigener Schritt, aber Stefan ist zum Schluss noch auf das Thema Refaktorierung eingegangen. Er gab ein paar Tipps, nannte Gründe für das Refaktorieren, erklärte, wann man es am besten macht und vor allem wie man vorgehen sollte.

Alles in Allem war der Vortrag eine gute Zusammenfassung von Tipps, die jeder PHP Programmierer beherzigen sollte, auch wenn man das meiste schon kannte. ABer im Tagesgeschäft vergisst man das ein oder andere immer mal wieder und daher war die Zusammenfassung sehr hilfreich.

Mein Zwischenfazit nach meinem ersten Tag bei der Internationalen PHP Konferenz 2008 in Mainz fällt durchweg positiv aus. Dies ist meine erste IPC und ich bin besonders über die Organisation und das durchdachte Gesamtkonzept begeistert. Denn wer denkt, die Programmpunkte beschränken sich nur auf die Sessions, Keynotes und die Verpflegung, der irrt gewaltig. Auch der Veranstaltungsort, die Rheingoldhalle in Mainz, gefällt mir sehr gut. Nicht zu eng, aber auch nicht zu weitläufig.

Am gestrigen Dienstag wurde am Abend der so genannte Ballroom eingerichtet, in dem es verschiedene Tische mit vorgegebenen Themen gab. Wer sich für ein Thema interessiert, kann sich an einen der Tische setzen und munter mit Gleichgesinnten darauf los diskutieren. Aber man kann auch seinen eigenen Thementisch aufmachen und auf zahlreiche Teilnehmer hoffen. Daneben konnte an verschiedenen Tischen Roulette, Poker, Black Jack und was auch immer gespielt werden. Obwohl es um nichts ging (d.h. niemand musste sein echtes Geld einsetzen), waren einige sehr bei der Sache. Nur warum innerhalb von 10 Minuten beim Roulette drei Mal die rote 21 kam, wird wohl ein Rätsel bleiben.

Zu den Sessions hatte ich gestern ja schon einiges geschrieben. Bisher fand ich die Sessions, die ich besucht hatte, allesamt sehr interessant. Obwohl ich mich selber mehr oder minder schon seit fast 10 Jahren mit PHP beschäftige, gibt es immer wieder Neues zu lernen. Ich sitze auch gerade schon wieder über den Stundenplan für heute und picke mir die Rosinen raus. Parallel zur IPC starten heute auch die Sessions der Ajax in Action Konferenz. Mal schauen, ob ich da auch mal einen Blick rein werfe. Zudem steht heute Abend das verspätete Oktoberfest an, wobei es ja eigentlich noch Oktober ist.

Markus Wolff hat in seiner Session “Search as a Service” das Projekt Marjory vorgestellt, an dessen Entwicklung er maßgeblich beteiligt ist. Ich habe den Anfang leider verpasst, weil ich etwas aufgehalten wurde.

Marjory basiert auf dem Zend Framework und nutzt vor allem die Zend_Search_Lucene Komponente für die Umsetzung der Volltextsuche. Marjory ist vergleichbar mit Solr und nutzt das gleiche XML Format. Dies erleichtert den Umstieg von Solr auf Marjory und umgekehrt bei Bedarf.

Marjory ist ein Webservice für einen Volltextindex. Dabei bildet der Marjory Webservice die Schnittstelle zwischen der Anwendung und dem Volltextindex. Als Suchmaschine kann eine beliebige verwendet werden, wobei Zend_Search_Lucene als Standard implementiert ist. Dadurch das Marjory als Webservice konzipiert wurde, ist es ein leichtes, die Suchmaschinen auf einem dedizierten Server laufen zu lassen. Dieser dedizierte Server kann sich somit auf die Indizierung und die Suchabfragen konzentrieren und kann sogar die Suchkataloge von mehreren unabhängigen Sites verwalten.

Die Indizierung kann per Übergabe eines XML Strings erfolgen, der die zu indizierenden Daten enthält. Alternativ kann auch eine Url übergeben werden, die dann von Marjory geparst wird. Bisher können nur HTML Dokumente verarbeitet werden, in Zukunft sind auch PDFs geplant. Markus hat in seinem Vortrag dann auch einige Beispiele für das Anlegen neuer Kataloge, das Indizieren neuer Dokumente und das Senden von Suchabfragen gezeigt.

Alles in allem halte ich Marjory für ein sehr interessantes Projekt, auf das ich auch in Zukunft ein Auge werfen werde. Da es zudem noch auf dem Zend Framework basiert, macht die Sache für mich noch interessanter. Die Idee, die Volltextsuche als Webservice auf einen anderen Server fern der eigenen Anwendung aufzusetzen, finde ich sehr gut. Mal schauen, ob ich Marjory auch mal für eigene Projekte einsetzen kann. Markus erwähnt auch, dass Marjory bereits produktiv eingesetzt wird, unter anderem auch von Jimdo. Ab und zu berichtet Markus auch in seinem Blog über den aktuellen Stand von Marjory.

Zu Anfang der Session “Monitor your business” fragte Lars Jankowfsky (CTO von Swoodoo) die Teilnehmer, was sie denn von seiner Session genau erwarten. Eine wirklich klare Antwort fiel mir zuerst auch nicht ein, zumindest konnte ich die nicht genau formulieren. Am Ende der Session wusste ich aber, dass die Session genau meine Erwartungen erfüllt hat, auch wenn ich sie zu Beginn nicht in Worte fassen konnte. Paradox? Ja. Aber das war kein Problem. Doch der Reihe nach.

Lars sagte gleich zu Beginn, dass er hier keine neuen High-End Techniken vorstellen würde, die gerade ganz frisch auf dem Markt veröffentlicht wurden. Es geht eher um Tools, die es schon länger gibt, namentlich sind das Nagios und Cacti.

Nagios ist im Wesentlichen eine Software für das Network Monitoring und wird oft verwendet um Loads, Pings oder Mysql zu testen. Man kann die Software aber auch prima verwenden, um zum Beispiel Bestellungen, Registrierungen oder die Aktivität der Kunden zu messen. Mit Hilfe einer Konfigurationsdaten und eines Skriptes, das wiederholt aufgerufen wird, können Daten erfasst und bei abweichenden Stati können Benachrichtungen versandt werden. Nagios sollte immer auf einer anderen Mschine als der zu prüfende Server laufen, weil im Fall eines Serverausfalls auch Nagios sonst platt wäre.

Cacti wiederum erstellt Grafiken für Bestellungen, Registrierungen, Buchungen, etc. Dabei werden nicht alle Daten dauerhaft gespeichert, sondern nur sondern nur die Differenz, um eine kompakte Datenbank zu erhalten. Die Konfiguration ist etwas komplizierter als bei Nagios und benötigt unter anderem zusätzlich ein Template.

Mit beiden Tools kann man aber eigene Reports für das Management erstellen lassen für Informationen, die sich bei normaler Logfileanalyse nicht unbedingt erfassen lassen. Oder eben auch nicht unbedingt in Echtzeit. Ich werde mir nach meiner Rückkehr, wenn ich mal die Zeit habe, also irgendwann in 2009, die beiden Tools mal anschauen, um zu sehen, wie wir die für unser Geschäft einsetzen können. Wie eingangs erwähnt hat die Session somit meine diffuse Erwartung erfüllt und ich habe tatsächlich was gelernt. Da hat sich das Aufstehen heute morgen also doch gelohnt… ;-)

Wer zur Keynote “Introduction to Drizzle” von Brian Aker pünktlich erschienen ist, war im Prinzip zu spät. Bereits vor dem Start war der Raum schon fast belegt. Habe aber noch einen zentralen Platz gefunden mit Tisch. Später war es dann sehr voll, Keynote eben.

Ehrlich gesagt, wusste ich vorher nicht genau, was mich erwarten würde. Nach und nach aber wurde klar, dass Brian die Erfahrungen aus der langjährigen Entwicklungszeit von MySQL zusammen fasst. Aus diesen Erfahrungen und der Antwort auf die Frage, was die MySQL Anwender wirklich brauchen, wurde Drizzle entwickelt. Wenn MySQL nicht schon Versionsnummern hätte (aktuell MySQL 6.x) könnte man Drizzle auch als MySQL 2.0 bezeichnen. Wer Drizzle einmal anschauen oder sogar testen möchte, kann bei Launchpad einmal nachschauen

Ich fande den Vortrag von Brian insgesamt unterhaltsam und kurzweilig. Mal schauen, was die weiteren Keynotes bringen.

Gleich meine erste Session, die ich besucht habe, war schon sehr interessant. Gehalten hat sie Fabien Potencier, seines Zeichens einer der Köpfe, wenn nicht sogar der Kopf, hinter dem Symfony Framework. Das Thema seines Vortrags war im Wesentlichen, die Abhängigkeit von Klassen in einer Anwendung zu minimieren, um die Wiederverwendbarkeit erhöhen zu können.

Wichtige Vorteile des loose coupling (zu deutsch lose Kopplung) sind die leichtere Testbarkeit des Codes, die zeitsparende, erhöhte Lesbarkeit, die bessere Wartbarkeit und Erweiterbarkeit sowie die leichtere Wiederverwendbarkeit des eigenen PHP Codes. Gerade da die Entwicklung stetig voranschreitet, ist es wichtig, dass man durch eine solide Basis auf bestehender Arbeit aufbauen kann.

Wichtigstes Hilfsmittel, um eine lose Kopplung der Komponenten zu erreichen, ist das Dependency Injection Entwurfsmuster. Zuerst demonstrierte Fabien einige Beispiele für zu hohe Kopplung von Komponenten. Bei einem Beispiel war eine User Klasse mit einer Session Storage Klasse so stark gekoppelt, dass das einfache Ändern des Namens vom Sessioncookie schon Probleme bereitet hat. Ein weiteres Beispiel stellte das Ändern der Storage Enginge für die Sessiondaten vor große Probleme. Zur Lösung wurde die Storage Engine an den Konstruktur der User Klasse übergeben. Details zu den Beispielen könnt ihr am besten den Folien von Fabien entnehmen, die in Kürze auch auf der IPC Website veröffentlicht werden sollen. Ich reiche den Link (sobald bekannt) an dieser Stelle dann nach.

Fabien unterscheidet mehrere Arten, wie man die Dependency Injection umsetzen kann. Zum einen kann man die benötigten Objekte (z.B. die Session Storage Klasse) an den Konstruktur übergeben (z.B. an die User Klasse). Oder man verwendet eine Setter Methode. Letzte Alternative ist das direkte Setzen über eine Eigenschaft der Klasse. Fabien bevorzugt den Ansatz über den Konstruktur für Objekte, die immer und sofort gebraucht werden, und den Ansatz über eine Setter-Methode für Objekte, die nur bei Bedarf benötigt werden.

Fabien brachte auch noch ein weiteres, deutlich komplexeres Beispiel für einen Bootstrapping Prozess, also für die Einrichtung einer Applikation mit Request, Response, User, Storage, Cache und Routing Objekten. Hierfür empfahl er den Einsatz eines so genannten Container Objekts, das sich um die Konfiguration und Verwendung der einzelnen Objekte kümmern soll. Dies hat den Vorteil, dass die einzelnen Objekte nicht mehr in starker Abhängigkeit bestehen.

Im weiteren Verlauf seines Vortrags gab Fabien noch einige Implementationstipps, zeigte ein Beispiel aus der realen Welt mit verschiedenen Konfigurationsdateien im XML oder INI Format und nannte einige Beispiele von Projekten, welche Container verwenden. Zu guter Letzt stellte Fabien auch das Observer Pattern vor, demonstrierte ein paar Beispiele und nannte wiederum Projekte, welche das Observer Pattern einsetzen.

Die Fragestunde fiel mangels Fragen etwas kurz aus. Doch da Fabien wie eingangs erwähnt ein kompetenter Ansprechpartner zum Symfony Framework ist, wurde er kurz gebeten zu erläutern, welche Vorteile Symfony nun gegenüber anderen Frameworks bietet. Seine nicht überraschende Kernaussage war, dass Symfony natürlich das beste PHP Projekt ist. Er konnte sich auch seine Seitenhiebe in Richtung des Zend Frameworks (natürlich alle völlig subjektiv und haltlos und überhaupt) nicht verkneifen.

Alles in allem eine interessante Session und für mich genau das richtige zum Einstieg. Man muss ja auch erst reinkommen in so eine Konferenz. Huch! Die Sonne scheint! Ich muss weg!

Update vom 4.11.2008: Fabien hat die Vortragsfolien veröffentlicht.

Eigentlich ist die Internationale PHP Konferenz 2008 in Mainz schon gestern gestartet, aber ich bin heute erst angekommen. Zuerst wusste niemand etwas von mir, hätte mich wohl auch nicht bei den Firmen Countern anstellen sollen. ;-) Mein Badge musste dann erst ausgedruckt werden und schon war ich drin.

Kurz danach begann auch schon die Eröffnungszeremonie mit wenigen Minuten Verspätung. Habe dann erste mal das WLAN getestet und für gut befunden. Die Zeremonie ging im Wesentlichen darauf ein, was die Teilnehmer in den nächsten Tagen alles erwartet. Unter anderem kamen auch Björn Schotte, Stefan Priebsch und Robert Lippert zu Wort und stellten einige Schwerpunkte der Konferenz wie z.B. Tools, Sicherheit, Architektur oder PHP 6 heraus. Die Einladung zum Ballroom und einem verspäteten Oktoberfest fehlten auch nicht.

Danach habe ich dann meine erste Session besucht (dazu gleich mehr). Jetzt muss ich mich erst einmal etwas akklimatisieren und den Stundenplan für die nächsten 3 Tage anschauen…