Plasma Bigscreen ist eine Linux-Distribution vorrangig für den Raspberry Pi 4. Sie integriert Komponenten wie KDE Neon, Mycroft AI, KDE Plasma Bigscreen, libcec und (aktuell noch) Googles Speech-to-Text-Dienst (STT). Es ist aber geplant, für STT auf Mozillas DeepSpeech umzusteigen. In den Worten der Projektwebseite:
This project is using various open-source components like Plasma Bigscreen, Mycroft AI and libcec with a modified KDE Neon img for the Raspberry Pi 4 to allow easy accessing content-related services on your TV.
"Plasma Bigscreen im Beta-Test" vollständig lesen
Auch in diesem Jahr bin ich am Samstag wieder früh aufgestanden, habe mich ins Auto gesetzt, den Unbillen der A3 zwischen Wiesbaden und Siegburg getrotzt, und habe schließlich an der diesjährigen FrOSCon teilgenommen.
In all den Jahren seit meiner ersten FrOSCon 2010 habe ich viele Menschen aus der Open Source- und insbesondere PHP-Community kennengelernt, die ich IRL oft nur einmal im Jahr treffe: eben auf der FrOSCon. Das ist immer wieder schön, und auch diesmal waren viele alte und ein paar neue Bekannte vor Ort. Manchmal reicht es nur kurz zum "Hallo"-Sagen zwischen zwei Talks, manchmal bleibt etwas mehr Zeit, um sich zu unterhalten. In diesem Jahr habe ich es ganz gut getroffen und ein paar nette Begegnungen gehabt.
"FrOSCon 2017" vollständig lesen
Wie in den Jahren zuvor habe ich die FrOSCon auch diesmal nur an einem Tag, dem Samstag, besucht. Dennoch hat sich die Anreise wieder ausdrücklich gelohnt. Die Konferenz hat nicht nur mit interessanten Speakern und einem exzellenten PHP-Track aufgewartet, sondern hat es auch einfach gemacht, sich mit anderen Open Source-Enthusiasten und -Projekten auszutauschen. Der Rahmen stimmt einfach.
Im folgenden möchte ich ganz kurz über die Sessions berichten, die ich besucht habe. Ich war fast durchgängig im PHP-Raum zu Gast, habe aber auch einen Blick über den Tellerrand gewagt und zwischen den Talks ausreichend Zeit gefunden, um mich bei Kaffee oder Mate mit netten Leuten auszutauschen.
"Mein FrOSCon Samstag 2013" vollständig lesen
Nachdem Ende letzter Woche das Leistungsschutzrecht für Presseverleger im Bundestag verabschiedet wurde, spülte meine Timeline das Wordpress-Plugin vom D64 Zentrum für Digitalen Fortschritt wieder in meine Aufmerksamkeit. Das Plugin lädt eine Blacklist aus dem Netz, in der die Domains von Verlagen gesammelt werden, die das LSR unterstützen. Mittels dieser Liste lenkt es Links zu den Verlagsseiten, die in Blogartikeln enthalten sind, auf eine Hinweisseite zum LSR um:
Coole Idee. Ein kurzer Blick auf GitHub sagte mir, dass es nicht schwer sein würde, das Plugin für Serendipity zu adaptieren. Gesagt, getan.
"Leistungsschutzrechtprotestplugin" vollständig lesen
Geben wir es ruhig zu, der PHP-Code von Serendipity ist nicht mehr State of the Art, sondern zum großen Teil noch auf dem Stand von PHP 4. Dass dieser Code immer noch sehr zuverlässig funktioniert, und ob und wie mit dem aktuellen Stand umzugehen ist, soll hier nicht das Thema sein. Ich möchte hier auf die Entwicklung von Serendipity-Plugins eingehen, die nicht umsonst in einem eigenen Repository leben. Deren Qualität lässt sich mithilfe von Unit Tests sicherstellen.
PHPUnit für Plugins
Auch wenn die Grundfunktionalität von Serendipity durch Unit Tests abgedeckt ist: Die Plugin-Entwicklung ist bisher nicht so einfach zu testen. In meinen letzten Projekten waren Unit Tests mit PHPUnit ein zunehmend zentraler Bestandteil der Entwicklung. Entweder damit ich nachträglich sicherstellen konnte, dass Klassen und Methoden bei Veränderungen und Refactoring noch taten, was sie tun sollten; oder weil ich testgetrieben entwickelte, das heißt zuerst die Unit Tests und dann erst den zu testenden Code schrieb. Dieses Vorgehen möchte ich nicht mehr missen, und es hat mich gestört, dass es bei der Entwicklung von Serendipity-Plugins nicht ohne Weiteres möglich war.
Daher habe ich mich hingesetzt und PHPUnit so in meine lokale Serendipity-Installation, die ich zum Entwickeln verwende, integriert, dass ich einzelne (Event-)Plugins separat testen kann. Die spezifischen Herausforderungen ließen sich recht schnell überwinden:
- In Serendipity werden Plugins stark getrennt vom Core über Event-Hooks ausgeführt. Diese Hooks müssen natürlich einzeln getestet werden können.
- Viele Variablen sind als global deklariert oder werden per Referenz "herumgereicht". Das erfordert einige Workarounds, die heute dank Dependency Injection und ähnlichen Entwurfsmustern zum Glück überflüssig sind.
- Data Fixtures: Um Serendipity für die Tests "hochzufahren", wird eine Datenbankverbindung benötigt. Mir ist es bisher nicht gelungen, eine der unter Database Testing aufgeführten Methoden umzusetzen. Besser gesagt: Ich war einfach zu faul und habe die nötigen Daten in einer SQLite-Datenbank hinterlegt.
"PHPUnit für die Entwicklung von Serendipity-Plugins" vollständig lesen
