UPDATE:
Aufgrund von Krankheit und Abwesenheiten wird der geplante Termin auf einen noch festzulegenden Termin verschoben.
Der Termin für das dritte Usertreffen der PHPUG Halle steht fest. Es findet am 01.06.2010 um 19:00 Uhr in der Gaststätte “Goldenes Herz” in der Mansfelder Straße 57 in Halle statt. Alle PHP-Begeisterten aus Halle und Umgebung sind wie immer herzlich dazu eingeladen.
Geplante Kurzvorträge sind:
– Vergleich Git / SVN
– das Strategy Design Pattern mit PHP (Nachholung vom letzten Mal) – ein weiteres Thema (wird nachgetragen)
Auch dieses Jahr findet wieder im Zeitraum vom 15. April bis 31. Mai die European WinPHP Challenge statt, die von der Dutch PHP Conference und Microsoft veranstaltet und von Leaseweb und Zend unterstützt wird. Es handelt sich dabei um einen Coding-Wettbewerb, bei dem im angegebenen Zeitraum eine PHP-Applikation für Windows erstellt werden muss, die auch Windows-spezifische Funktionalitäten integriert. Parallel zum laufenden Entwicklungsprozess muss wöchentlich darüber gebloggt werden.
Die Anmeldefrist ist zwar leider schon weg, die Ergebnisapplikationen dürften aber dennoch interessant werden.
Man kann durchaus geteilter Meinung sein, ob die Kombination von Windows und dem IIS eine gute Applikationsplattform für PHP ist. Dass diese Plattform in der Praxis aber recht häufig vorkommt, ist nicht von der Hand zu weisen. Darüber hinaus ist der Wettbewerb aber noch aus einem ganz anderen Grund erwähnenswert: auch Microsoft hat wohl nun die Marktmacht und Verbreitung von PHP erkannt. Und das ist gut so.
Der Termin für das nächste Usertreffen der PHPUG Halle steht fest. Es findet am 06.04.2010 um 19:30 Uhr im “Zimmer frei” (ehemals Nexus) in der Kohlschütter Straße 9 statt. Alle PHP-Begeisterten aus Halle und Umgebung sind herzlich dazu eingeladen.
Geplante Kurzvorträge sind:
– LAMP Deployment Strategien – best practices
– gettext und Mehrsprachigkeit in PHP-Applikationen
– das Strategy design pattern mit PHP
Dank Twitter und Planet PHP kam heute mal wieder ein Hinweis auf ein wirklich spannendes PHP-Projekt reingeflattert: Neural Mesh. Dabei handelt es sich schlicht und ergreifend um die Umsetzung des nicht neuen Konzepts neuronaler Netze mit den Mitteln von PHP und MySQL.
Neuronale Netze haben den Anspruch, das menschliche Gehirn mit mathematischen Mitteln nachbilden zu wollen. Ob der Algorithmus nun wirklich mit dem menschlichen Gehirn vergleichbar ist, möge jeder selbst entscheiden, aber eine Gemeinsamkeit haben sie schon: sie sind lernfähig. Und genau dort liegt das Anwendungsfeld von neuronalen Netzen und dem besagen Projekt Neural Mesh. Man kann es für einen bestimmten Anwendungsfall trainieren. Dabei füttert man Neural Mesh mit Eingabewerten und den darauf erwarteten Ausgabewerten. Nach einiger Trainingszeit liefert Neural Mesh dann zu zufälligen Eingabewerten die korrekten Ausgabewerte.
Das Schöne an diesem Projekt ist, dass man eben den Algorithmus von neuronalen Netzen nicht verstanden haben muss, um es trotzdem anwenden zu können. Na gut, auch wenn die API einfach ist, sollte man sich zumindest grundlegende Kenntnisse über Layer und Neuronen anlesen. Ein guter Einstieg dazu ist hier zu finden.
Auf der nach oben offenen Nerd-Skala trotzdem definitiv eine 8!
Es tobt ein Religionskrieg im PHP-Land! Ihr glaubt es nicht? Dann outet Euch mal in der PHP-Community als Unit-Tester von protected/private Methoden. Die Mehrheit unserer PHPUG tut es hiermit. Wir tun es auch schon recht lange und fahren gut damit. Und wir haben auch unsere Gründe es genauso zu tun. Wir sind keineswegs allein mit unserer Ansicht.
Doch zunächst zu den vermeintlichen Gegenargumenten. Fragt man einen Vertreter der anderen Seite, warum man es nicht tun sollte, hört man grundsätzlich nur ein Argument: “Man testet nur das public interface einer Klasse.” “Eine Klasse ist eine black box, was intern passiert interessiert nicht.” Hinterfragt man dann konkret, warum man nur das public interface testen soll, bekommt man außer Verweise auf Leute, die es so propagieren, kaum fundierte Argumente.
Allenfalls noch “So viel Zeit haben wir nicht, auch protected/private Methoden zu testen.” Kommt Euch das bekannt vor?
Genau, das sind auch die Ausreden der Leute, die Unit-Tests grundsätzlich für überflüssig halten.
Wir setzen Unit-Tests ein, um möglichst fehlerfreie und verlässliche Software für die Praxis zu schreiben. Und genau deswegen testen wir auch private/protected Methoden. Die eifrig propagierte Alternative dazu ist, nur das public interface und den Code der protected/private Methoden damit nur indirekt über die public Methoden zu testen. Doch Hand auf’s Herz: was ist naheliegender?
In diesem Punkt widersprechen sich die Vertreter der anderen Seite übrigens mehrfach selbst: es ist bei Unit-Tests zum Einen eben sehr wohl von Belang, was innerhalb der Klasse geschieht, auch und besonders in den protected/private Methoden.
Zum Anderen gehören protected Methoden zwar nicht direkt zum public interface, sie können aber innerhalb der Vererbungskette mehr oder weniger doch von außen aufgerufen werden. Und dann würde eben eine Methode außerhalb der deklarierenden Klasse eingesetzt, die nur indirekt getestet wurde.
Das Testen von private/protected Methoden – noch ein gern genommenes Gegenargument – bedeutet auch ganz und gar nicht, das Klassendesign an das Unit-Testing anzupassen. Das wäre sicherlich falsch und das muss man auch nicht, wenn man das Proxy design pattern und Reflection einsetzt.
Das einzige plausible Gegenargument, das uns z. B. bei Zend aufgefallen ist, ist die Tatsache, dass beim Refactoring gerade private Methoden gern mal schnell geändert und – was wesentlich problematischer für unsere Methode ist – entfernt werden.
Das ist in der Tat nicht so ohne weiteres von der Hand zu weisen. In diesem – und nur in diesem Fall – hätten wir einen Unit-Test, den wir anpassen oder sogar wieder entfernen müssten. Doch auch hier sollte man kritisch hinterfragen, wie oft man Klassen einem derartigen Refactoring unterzieht, wie oft man selbst das public interface ändert oder Unit-Tests für das public interface in der Praxis ändern oder anpassen muss. Ehrlicherweise entschärft sich dann dieses Gegenargument recht schnell von allein. Ein Hindernis für das grundsätzliche Refactoring einer Klasse ist unsere Methode jedenfalls nicht.
Und ein weiterer Punkt wird bei dieser Diskussion außer Acht gelassen: der Unit-Test-Code, auch wenn er heutzutage in guten Open-Source-Projekten mitgeliefert wird, gehört nicht zum Applikationscode. Das kann man nicht deutlich genug sagen. Natürlich sollte man auch hier grundlegende Programmierregeln einhalten. Das bedeutet aber nicht, dass man zum Testen nicht doch einige Regeln bewusst brechen darf, insofern es bessere Tests ermöglicht (Beispiel: direkter Zugriff auf $_GET oder $_POST). Auch die Vertreter der anderen Seite tun soetwas. Warum also nicht auch das Dogma “public interface” beim Unit-Testing (und nur dort) in Frage stellen, wenn es keine schwerwiegenden Gegenargumente gibt und fast nur Vorteile bringt?
Das Testen von private/protected Methoden hat übrigens noch einen anderen positiven Effekt: man findet Bugs wesentlich schneller. Probiert es einfach aus.
Die Einführung von ReflectionMethod::setAccessible in PHP5.3 zeigt, dass dieser Bedarf in der Praxis offensichtlich besteht. Nicht ohne Grund haben auch wir ein kleines Tool, mit dem man auch ohne PHP5.3 sowohl protected als auch private Methoden testen kann, den SuperProxy.
In diesem Sinne: traut Euch einfach mal, neue Wege zu gehen! Es tut nicht weh…
