Serverside Locking, Clientside Merging, Distributed (Darcs, Mercury, Git, Monotone, etc.): Zustand des Repositories als Verkettung von Patches. Ein Vorteil: Man kann auch offline arbeiten. Gute Delta-Compression, Garbage Collection, Mehr-Protokoll-Fähigkeit (Git Protokoll, SSH, HTTP, ...). Tools: gitweb, gitosis. Da ich ja schon mit git gearbeitet habe, fällt mir gerade wieder auf, dass es schon ein sehr schönes System ist. Und Github scheint definitiv einen Test wert zu sein, zumal es für Open Source-Projekte kostenlos ist.
Ein mobiles Braille-Zeilen-Anzeigegerät kostet mal locker 7.000 €, was in Deutschland von Krankenkassen bzw. Rentenversicherung bezahlt wird. Open Source-Screenreader NVDA, unter Linux vor allem Orca. Als Browser sind lynx/links am nächsten dran an der Art und Weise, wie auch Blinde Webseiten nutzen.
Gerade haben wir JAWS mal was vorlesen lassen, das war schon recht schnell und viel Information auf einmal - nur was für geübte Nutzer. Offenbar gibt es sogar Möglichkeiten, OCR in Screenreadern zu nutzen. Wir testen jetzt mal die BarCamp-Seite bei mixxt.de auf ihre Tauglichkeit, müssen nun aber schon zum Ende der Session kommen.
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".