Sperrobjekt Weblog

Frank Sons von www.modix.de stellt uns das altbekannte PHPUnit von Sebastian Bergmann vor und erzählt uns generell über Unit Testing. Nach eigener Ankündigung nutzt er auch viele Beispiele von Bergmann. Nunja

Es können prinzipiell Komponenten-, Akzeptanz- und Nicht-funktionale Tests durchgeführt werden. Unit Tests haben Grenzen bei Integration von fremden Systemen, DB-Abfragen (Stichwort: Mock-Objekte), daher muss der Code schon sauber gekapselt sein. Klassisches Beispiel: Kontostand, der nicht unter 0 fallen darf. Tipp: @assert in den DocBlock, dann erstellt phpunit ein Test-Skeleton. Andersherum kann man sich auch aus einfachen Tests simple Basisklassen generieren lassen.

Best Practices: Ein Test für jeden Testfall; ein Test nach dem anderen; Grenzfälle betrachten; auf Fehler und Exceptions testen; auch mit validen Daten testen; (nur) das testen, was Bugs verursachen kann (z.B. keine Getter/Setter); Teste früh und oft; Bugs: Test schreiben, dann fixen; Code ist fertig, wenn Tests durchlaufen; KISS!

Mit Dennis Winter von den Rheinschafen diskutieren wir nun über OpenID und ZF. Gleich mal ein paar Probleme: OpenID 2.0 wird nur in Draft 11 unterstützt, noch nicht die Final; kein Attribute Exchange z.B. Manche entscheiden sich dafür lieber für die PHP4-Library von JanRain. Vorteile: Storage-Möglichkeiten für Daten in der DB zwischen einzelnen Requests, SREG-Unterstützung. Lebhafte Diskussion im Anschluss Aber eigentlich sind wir uns einig, dass Zend_OpenId die Lösung für PHP5 und OpenId ist, sobald es endlich die Version 2.0 voll unterstützt.

Und wieder ein Konflikt: OpenWeb/OpenID versus "Poken". Da Poken aber gerade das Phänomen dieses Barcamps ist, werde ich mir mal anhören, was die Schokodinatorin und dotdean uns zu erzählen haben. Ein bisschen Erholung nach der theorielastigen "Vertrauens-Session".

Malte Münchert erzählt uns jetzt etwas zum Thema "Facebook-Chat für alle: Ajax-Push Queue (ApuQ). Ich bin gespannt. Er kommt aus Berlin und der Rails-Ecke.

Verbindung zum Server bis zu fünf Minuten offen halten. Client-seitiges Javascript zum Eventhandling, der Server muss die Ereignisse zum Browser schieben können. Malte hat einen Ruby-Server dafür geschrieben.

Herkömmliche Vorgehensweise: Polling vom Client, hat viele Nachteile. Beim eigenen Server muss man hinbekommen, dass er unter der gleichen URL und dem gleichen Port läuft. ApuQ-Framework und mod_proxy (Reverse Proxy) bzw. per PHP - andere Lösungen sind denkbar und werden gerade diskutiert. Der Facebook-Chat ist wohl in Erlang implementiert.

Auch hier der Disclaimer: Verlinkungen und weitere Infos folgen.

Martin Thielecke über Cloud Computing. Weltweite Verteilung der Rechenzentren, extreme Skalierbarkeit, schnelle Verfügbarkeit der Server, man zahlt nur, was man verbraucht. Nachteil: Kein direkter Zugriff auf die Hardware, um Backups usw. muss man sich selbst kümmern. Sinnvoll für Startups von Anfang an!?

Ambieter: Amazon (EC2, S3, SQS, SimpleDB, ECS, FPS), Google, Sun (Grid), Skytap, GoGrid; demnächst Host Europe und andere. Beispiel: Elastic Compute Cloud von Amazon. Es werden sehr viele Amazon Machine Images angeboten, diverse Systeme (Debian, RedHat, usw.), die einfach hochgefahren und dann zur S3 hochgeladen werden und public oder private zur Verfügung stehen. Monitoring, Starten, Beenden ist großteils über APIs möglich.

Persistenter Speicher: Elastic Block Store (EBS). Simple Queue Service ist ideal für asynchrone Computing-Aufträge, wird angesprochen über SOAP-API. S3: Reiner Speicherplatz für Dateien/Objekte bis 5 GB, getaggt mit Location, versehen mit Auth, REST- und SOAP-API. SimpleDB: Nicht-relationale Datenbank; "Domain", "Items", "Key-Value-Attributes"; simple API; ähnlich CouchDB(!).

Anmerkung: Das waren erstmal nur live mitgebloggte Stichworte; der Artikel wird möglicherweise später noch überarbeitet