Sperrobjekt Weblog

Seit Kubuntu mit KDE4 ausgeliefert wurde, bin ich am Hadern. Die neue Version mag eine noch so schöne, modulare und saubere Architektur besitzen, sie ist einfach noch nicht gut benutzbar (und sieht nicht schön aus). Daran hat sich auch mit Jaunty und der Version 4.2 nichts geändert. Ich bin mittlerweile auf Gnome umgestiegen und fühle mich ganz gut aufgehoben, zumal ich ja auf KDE-Programme wie Digikam oder Amarok nicht verzichten muss. Gerade weil ich mich sehr viel mit Musik beschäftige, möchte ich Amarok nicht missen, da dieser Player der einzige ist, der meine Ansprüche erfüllt (wobei ich Banshee doch mal wieder ausprobieren muss, dort hat sich einiges getan).

Nun ist aber mit Jaunty endgültig die Version 2 von Amarok ausgeliefert worden, welche dem halbgaren Status des KDE-Projekts in nichts nachsteht. Viele liebgewonnene Features fehlen oder funktionieren nicht. Auch wenn das ein kompletter Rewrite ist, der von der Pflegbarkeit und der Erweiterbarkeit des Codes besser ist, möchte ich nicht mit einem solchen Usability-Rückschritt leben müssen. Womit ich gar nichts über die neue Dreiteilung des User Interface sagen will; damit könnte ich leben. Mit meiner Ablehnung stehe ich im Übrigen nicht alleine.

Meine Lösung ist vorerst, zumindest solange Amarok2 nicht besser ist als die "alte" Version 1.4.x: Downgraden! Es gibt ein PPA bei Launchpad, das die 1.4 auch für Jaunty anbietet. Einfach Amarok2 per Synaptic, aptitude oder was auch immer deinstallieren, die Paketquelle deb http://ppa.launchpad.net/bogdanb/ppa/ubuntu jaunty main hinzufügen (den OpenPGP-Schlüssel nicht vergessen!), die Paketquellen neu laden und Amarok1.4 installieren. Läuft.

Endgültig befriedigend ist diese Lösung natürlich nicht. Sollte Amarok2 nicht bald nachziehen, muss ich wohl früher oder später auf Alternativen umsteigen. Neben Rhythmbox, das ich gar nicht mag, gibt es wie oben schon erwähnt Banshee, außerdem kämen noch Exaile oder das ebenfalls sehr gute, Java-basierte aTunes in Frage. Oder gibt es noch weitere, ausgereifte Alternativen?

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.