Ich bin ja eher ein Casual-Blogger in mindestens dritter Minuspotenz und veröffentliche Beiträge dann, wenn ich Lust darauf habe. Daher habe ich mich schon immer etwas darüber geärgert, dass es für unsere Sorte kaum Blogsysteme gibt, bei denen man nicht mit der sprichwörtlichen Kanone auf Spatzen schießt, aber trotzdem nicht auf die Grundfunktionen eines Blogsystems verzichten muss. Ich fange an dieser Stelle kein WordPress-Bashing an, denn es ist ohne jede Frage immer noch ein sehr vielseitig einsetzbares System, welches sich inzwischen vom reinen Blogsystem zu einem ausgewachsenen CMS weiterentwickelt hat. Ich musste allerdings feststellen, dass WordPress für meine Zwecke mittlerweile beinahe überflüssig geworden ist. Abgesehen vom Robbinär-Blog, das mit Dotclear läuft, schreibe ich in meinem ursprünglichen Hauptblog nur wenige Artikel im Jahr, wenn überhaupt. Meine Arbeit mit WordPress besteht mehr oder weniger nur noch darin, das System und installierte Plugins aktuell zu halten, Hacking-Versuche abzuwehren, ab und zu einen durchgerutschten Spamkommentar zu löschen, und mich zu ärgern, wie langsam das Backend von Version zu Version wird. Letzteres wurde mir umso klarer, als ich kürzlich mal ein uraltes WordPress 2.0 unter die Finger bekam. Während Browser und Screenreader - je nach verwendetem Rechner, Webserver und installierten Plugins - bei aktuellen WordPress-Versionen schon mal etliche Sekunden brauchen, um eine Backend-Seite vollständig aufzubauen, flogen mir bei diesem Museums-WordPress die Unterseiten des Dashboards binnen einer Sekunde entgegen. Hier kann ich natürlich nur den Eindruck beschreiben, den ich als reiner Tastatur-Nutzer dabei habe, visuell mag es sich vielleicht weniger dramatisch verhalten. Jedenfalls wusste ich danach, was ich wollte: Ein WordPress, dass technisch und vom Funktionsumfang den heutigen Standards entspricht, aber mit der Geschwindigkeit von damals bedient werden kann. Weitestgehend dürfte das zwar ein Traum bleiben, aber ich habe mich trotzdem mal wieder nach kleineren Alternativsystemen umgesehen. Gesucht war ein Flatfile- oder auf SQLite basierendes System, denn für meinen Blogging-Bedarf wäre das vollkommen ausreichend.
Den Artikel PluXml: Flatfile-Blogging ohne Überfluss lesen
Stößt man als blinder Nutzer unter Android auf eine App, deren Schaltflächen für die Nutzung mittels TalkBack unbeschriftet sind, lassen diese sich in vielen Fällen über das lokale Kontextmenü manuell mit Labels versehen. Dies setzt natürlich voraus, dass man die Funktion der Schaltflächen vorher selbst oder mit sehender Hilfe ergründet hat. Um nach einer Neuinstallation oder Wechsel des Android-Gerätes die Schaltflächen nicht jedes Mal von vorn beschriften zu müssen, können die Labels in den TalkBack-Einstellungen auch exportiert werden.
Die Android-App Blindo - accessibility ratings macht sich diese Funktion zu Nutze, und stellt für blinde Anwender eine Community bereit, welche den Austausch dieser Label-Beschriftungen erlaubt. Nach Download der derzeit nur englischsprachigen App durchläuft man ein kurzes Nutzungs-Tutorial, und meldet sich mit seinem Google-Konto an. Anschließend erhält man nicht nur die Möglichkeit, für seine installierten Apps - falls verfügbar - Labels herunter- und hochzuladen, sondern kann auch Bewertungen (Ratings) für Apps abgeben. Diese beziehen sich speziell auf die Zugänglichkeit. Bewertet wird auf einer Sterne-Skala von 1 bis 5, getrennt nach Kategorien wie Interface-Zugänglichkeit, Button-Labeling, App-Performance oder Kompatibilität mit TalkBack und ShinePLUS. Hierbei ist aber etwas problematisch, dass ein Rating nur vollständig abgegeben werden kann, d. h. eine Bewertung mit 0 Sternen, weil man z. B. den ShinePlus-Bildschirmleser nicht installiert hat, ist leider nicht möglich.
Es bleibt abzuwarten, ob sich Blindo auch bei deutschsprachigen Nutzern größerer Beliebtheit erfreuen wird. Label-Pakete sind nämlich bisher überwiegend in Spanisch, Portugisisch oder Englisch verfügbar. Die App ist derzeit kostenlos und enthält einige wenige Werbeeinblendungen. Laut PlayStore sind InAPP-Käufe möglich, diese werden jedoch derzeit nirgendwo in der App beworben. Der Erwerb einer Pro-Lizenz zum Abschalten der Werbung wäre damit aber denkbar.
Auf der Suche nach einem einfachen, stabil laufenden Linux-Tool zur Audioaufzeichnung bin ich bei MHWaveEdit hängen geblieben. Vor allem die Möglichkeit, das Aufnahme-Fenster mit seinen Kontrollen vom Rest des Programms zu lösen gefiel mir. Auch die Steuerung per Tastenkombinationen ist sehr gut. Leider gab es zunächst ein gravierendes Problem, welches mich beinahe schon dazu gebracht hätte, das Tool wieder vom System zu entfernen.
Nachdem man mittels F12 das Aufnahmefenster aktiviert und eine neue Aufnahme gestartet hatte, zeigte der Aufnahmezähler wie erwartet die vergangene Zeit an. Allerdings stimmte nach Abschluss der Aufnahme die abgelaufene Zeit nicht mit dem überein, was tatsächlich in der Aufnahme zu hören war. Die Audio-Datei war zwar exakt so lang, wie es der Aufnahmestatus angezeigt hatte, doch die eigentliche Aufnahme begann schon etliche Sekunden früher, und auch das Ende lag an einer viel früheren Stelle. Alles machte den Eindruck, als hätte MHWaveEdit eine Art Vorab-Puffer vor der eigentlichen Aufnahme gestartet, der aber nicht wirklich zuverlässig funktionierte. Mal waren es wenige Sekunden, mal bis zu 10 Sekunden. Eine Möglichkeit, den Puffer zu konfigurieren, fand ich jedoch nicht.
Die Lösung fand sich schließlich in den Programm-Einstellungen auf der Registerkarte Musik. MHWaveEdit hat eine direkte Pulseaudio-Anbindung, erlaubt aber auch die Nutzung anderer Sound-Treiber. Hierzu muss die automatische Treiber-Erkennung ausgeschaltet werden, danach lässt sich aus einer Liste der gewünschte Treiber wählen. Aus einer Vermutung heraus wählte ich hier Alsa, und trug in den Alsa-Einstellungen als Aufnahme- und Wiedergabegerät "pulse" ein. Prompt funktionierte nach einem Neustart des Programms die Aufnahme vollkommen zuverlässig, und ich darf mich über einen netten kleinen Audio-Editor freuen, der um Längen stabiler und komfortabler zu nutzen ist als Audacity.
Trial-And-Error-Productions proudly presents: Ticker, ein RSS-Parser für Yellow CMS.
Mein nächstes Yellow-Plugin, das diesmal sogar etwas umfangreicher ausfällt als meine anderen, die sich überwiegend auf das Umwandeln von HTML-Snippets in einen Yellow-Shortcode konzentrieren. Bei meinem neuen Plugin geht es allerdings auch um PHP-Code. Zwar ist es verhältnismäßig einfach, eigenen Code in die einzelnen, als "Snippets" bezeichneten Design-Bausteine von Yellow CMS zu integrieren, doch wirklich komfortabel ist das trotzdem nicht gerade. Im Falle meiner Projekt-Homepage auf www.robbenradio.de ging es um einen kleinen RSS-Parser, der sämtliche Feeds aller Unterprojekte als gebündelten News-Bereich ausgeben sollte. Also habe ich mich in den vergangenen Tagen mal drangesetzt, und den Code in ein halbwegs ordentliches Yellow-Plugin verwandelt.
Der Parser lief zunächst mittels der in PHP integrierten SimpleXML-Funktionen. Da es lediglich um meine eigenen Projekte ging, benötigte ich die ganzen Zusatzfunktionen wie etwa Caching nicht. Natürlich sollten auch andere Nutzer etwas damit anfangen können, daher habe ich den Parser noch etwas erweitern müssen. Prompt stellte sich nämlich heraus, dass SimpleXML nicht wirklich gut mit z. B. Atom-Feeds umgehen kann. Bevor ich mir aber beim Implementieren der entsprechenden Namespaces den Hals verrenke und auch nicht das Rad neu erfinden wollte, habe ich kurzerhand auf den SimplePie-Parser zurückgegriffen. Dessen API ist leicht verständlich, es werden alle gängigen Feed-Formate samt diverser Caching-Möglichkeiten unterstützt, und der Parser lässt sich bei Bedarf auch in eine einzige PHP-Datei kompilieren. Derzeit liegt SimplePie dem Plugin nicht bei, kann aber schnell nachinstalliert und durch Setzen einer Option ganz einfach aktiviert werden.
Das Plugin bietet einige globale und individuelle Konfigurationsoptionen. So kann die Anzeige des Datums und der Artikel-Zusammenfassung (Description) ein- und ausgeschaltet werden, außerdem lässt sich jedem [ticker]-Shortcode eine CSS-Klasse für individuelles Styling zuweisen. Weitere kleine Verbesserungen werden sicher noch folgen, vor allem um SimplePie besser konfigurieren zu können.
Das nenne ich mal eine interessante Idee. Statt sich darüber zu ärgern, wenn das System mal wieder festhängt, kann man die dadurch entstehende Wartezeit in Klangkunst verwandeln.
CHARM von DraggonApps.org dient genau diesen Zweck. Das Tool ermittelt die Auslastung von Prozessor, RAM, Festplatte und Netzwerk, und wandelt diese Werte in Klangbilder um. Der Fantasie sind hierbei keine Grenzen gesetzt, wie ein Blick in die bereits mitgelieferten Sounds zeigt. Eher klassisch wirken die Ventilatoren, die sich bei steigender Systembelastung schneller drehen. Man kann seinen Rechner jedoch auch in ein Fußballstadeon verwandeln, in welchem die Menge bei zunehmender Arbeit vollkommen ausrastet, als wäre gerade ein Traumtor gefallen. Oder wie wäre es mit einem Vulkan, dessen Lavamassen sich aus den Lautsprechern ergießen, wenn man seinen Rechner zu Höchstleistungen antreibt? Sanftere Naturerlebnisse bieten dagegen Soundpacks mit Regen, Wasser und Windspielen. Sogar die Brücke der Enterprise aus Star Trek TNG lässt sich als kultige Untermalung der täglichen Aufgaben am Computer herbeizaubern. Wem das nicht genug ist, kann ganz einfach eigene Soundpacks erstellen. Was dazu benötigt wird, ist auf der Webseite des Windows-Tools in englischer Sprache detailiert beschrieben.
Artikel-Feed (RSS)