onli blogging

Wenn Google Reader am 1.7 schließt, wird das sicher niemanden mehr überraschen. Über diese seltsame Entscheidung von Google wurde ausführlich geschrieben. Am Anfang stolperte ich auch fast täglich über Artikel, die alternative Feedreader vorstellten. Doch jetzt, kurz vor Ende, sehe ich kaum noch solche Artikel, dabei gibt es inzwischen neue Alternativen. Also stelle ich diese neuen von mir angetesteten Feedreader mal kurz vor.

CommaFeed

CommaFeed läuft nun schon eine Weile, und ich bin hängen geblieben. Es ist einfach ein Klon von Reader und macht seinen Job im Grunde gut. Alle notwendigen Funktionen sind drin, die Oberfläche ist passabel, mit der user.css in den Einstellungen kann der große Patzer, die Schriftgröße, behoben werden. Es wird versucht, mit Spenden den Dienst zu finanzieren, sonst ist er kostenlos und Open Source.

Probleme: Die Seite war jetzt öfter mal offline und die Feedaktualisierung war sehr langsam. Manche Feeds wurden scheinbar noch nie gelesen seit dem Import, dann kommt plötzlich ein Block mit x alten ungelesenen Artikeln, das passierte sogar noch vor ein paar Tagen. Angeblich soll das nun besser werden, und tatsächlich ist die Seite ja auch schon einen weiten Weg gegangen, von dem Zusammenbruch beim Launch und dem damals nicht funktionierenden Import zu einem halbwegs soliden System.

go read

go read (Edit: Link entfernt, da mittlerweile eine Follower-Kaufseite) benutzt sogar das gleiche Styling wie CommaFeed, wohl ein Bootstrap-Standard. Genauso ein Reader-Klon wie Commafeed, vll noch näher am Original, mit dem gleichen Finanzierungsmodell und ebenfalls frei. Als go read auf HackerNews vorgestellt wurde fand ich es beeindruckend, wie die Seite unbeeindruckt weiterlief statt zusammenzubrechen. Der Import meiner Feeds klappte problemlos und ihre Aktualisierung war in wenigen Minuten erledigt.

Ich denke, dass ich hierdrauf wechseln könnte, wenn in ein paar Tagen die eine für mich notwendige Funktion drin ist: Das Ausblenden von Feeds ohne ungelesene Artikel.

BazQux

bq habe ich mir eigentlich nur angeguckt, weil ich schauen wollte, wie sich ein unfreier Reader schlägt (30-Tage umsonst, danach ab 9€ im Jahr). Und ich muss sagen: nicht schlecht. Es fehlt die user.css von commafeed, aber sonst sind alle notwendigen Funktionen da und etwas mehr, z.B. das direkte Anzeigen von Kommentaren und das Holen gekürzter Feeds, was sehr gut zu funktionieren scheint. Gar nicht so wenige Einstellungen und netterweise eine Benachrichtigung per Mail, dass die Feeds fertig importiert sind. Könnte sein Geld wert sein, vor allem wenn die Feedaktualisierung angemessen schnell für einen kostenpflichtigen Dienst funktioniert.

Dafür gefällt mir das Aussehen nicht, das ist mir alles zu fitzelig klein und eng. Und F5 wird blockiert, es öffnet eine Tageingabe, anstatt damit die Seite neu laden zu können - was mich vermuten lässt, dass da noch weitere Macken schlummern.

Macken und die Zukunft

Insgesamt ist der Wegfall von Google Reader natürlich schade, selbst wenn das Aufkommen von so vielen Alternativen was gutes ist. Aber was Verlässlichkeit und schnelle Feedaktualisierung angeht, sind die neuen Feedreader noch nicht so weit und es bleibt fraglich, ob sie je mit der Infrastruktur Googles hätten konkurrieren können. go read unterstützt nichtmal pubsubhubbub! Und bei CommaFeed merkt man nichts davon. Ob bq wirklich besser ist, muss sich erst noch zeigen. Selbst wenn, dafür hat der andere Macken.
Generell, Macken: Woher kommen alle diese Webdesign-Fehler? So setzen alle drei die Schrift kleiner, go read und CommaFeed auf 14 px und bq schlicht auf 90%, und nur CommaFeed gibt eine Möglichkeit, das zu korrigieren (und die ist nicht für Anfänger geeignet). Gut, den Unsinn hat schon Google Reader gemacht, aber muss man das 2013 wirklich wieder händisch korrigieren? Ausgerechnet bei Seiten, die zum langen Lesen gedacht sind.

Statt wieder auf möglicherweise wegfallende Webanwendungen zu setzen wäre eine selbst hostbare Alternative eigentlich interessant. Ich scheue das noch, aus zwei Gründen:

1. Ich merke an music-streamer, dass es gar nicht so einfach ist, einen Dienst auf dem Pogo dauerhaft verlässlich am Laufen zu haben (u.a. macht mein Router Probleme, was zu reparieren sich jetzt nicht mehr lohnt)
2. Die beiden Alternativen sind nicht besonders verlockend. Tiny Tiny RSS und selfoss sind beide PHP-Software, nur selfoss sieht gut aus, die Feeds werden entweder per separatem Daemon oder Crontab aktualisiert - nein, das klingt nicht gut.

Vor allem, weil wenn ich mir schon die Mühe machen würde das selbst zu hosten, dann wollte einen Reader haben, der rsspusher nutzt. Mit Ruby/Sinatra und rsspusher sollte ein 1-Personen Feedreader eigentlich in kürzester Zeit geschrieben sein - und wenn ich ihn selbst schreibe, hat der wenigstens keine Designfehler, die mir auffallen…

Falk hat im Forum eine Reihe von größeren Projekten vorgeschlagen

* Ich möchte die 1.7er und die 2.0er zusammenfügen (am besten bis KW 27)
* Danach baue ich Composer-Unterstützung ein
* Datenbank-Schema-Überarbeitung (mysql)
* Die veralteten PEAR-Bibliotheken werden ausgetauscht (gegen aktuelle oder andere Bibliotheken weiß ich noch nicht).

Dann entscheide ich mich zwischen:

* neuem Datenbank-Layer
* neuer Setup-Routine
* neuem Event-System

Garvin hat explizit um Nutzerfeedback gebeten

Wie sehen die anderen das? Und was sagen vor allem Nutzer dazu?

Also, nur zu!

Ich halte die Pläne für sehr sinnvoll, aber zu wie man z.B. am besten mit den Plugins umgeht würde mich Nutzermeinung auch interessieren.

CKEditor scheint ein ganz ordentlich wysiwyg-Editor zu sein, der als Plugin schon für Serendipity verfügbar war und den ich jetzt in den Kern eingebaut habe. Eine Herausforderung dabei war, dass ich beliebige Buttons einbauen können musste. Im Forum fand ich aber nur die Aussage, dass man dafür ein Plugin erstellen müsse, inklusive Platzieren einer plugin.js im passend benannten Ordner unter ckeditor/plugins/. Das war natürlich keine Lösung.

Tatsächlich kann man die Plugins problemlos auch bei der Initialisierung per Javascript erstellen, und das CKEditor-Plugin hatte dafür sogar schon passenden Code. Zuerst erstellt man ein Plugin. Hier als Beispiel eines, das in einem Popup die Medien-Library lädt:

CKEDITOR.plugins.add('s9y_medialibrary', {
    init: function( editor ) {
        editor.addCommand( 'openML', {
            exec : function( editor ) {    
                window.open('...');
                }
        });
        editor.ui.addButton('s9y_medialibrary', {
            label: 'Media',
            command: 'openML',
            icon: 'media_thumbnail.png'    // einfach ein Pfad zu einem Bild
        });
    }
});

Dann beim Aufruf des Editors das Plugin laden und platzieren:

CKEDITOR.replace($('textarea')).get(0), {
                extraPlugins : 's9y_medialibrary',
                toolbar: [
                    ...
                    { name: 'insert', items: [ 'Image', 's9y_medialibrary', 'Table', 'HorizontalRule', 'SpecialChar' ] }, // hier wurde es platziert, sonst kommt es ans Ende
                    ...
                ]
            }
);

Vor nun fast 2 Wochen habe ich den aktuellen Stand unserer Entwicklungsbemühungen für ein moderneres Serendipity 2.0 vorgestellt. Mir ist es wichtig, dass der Entwicklung möglichst einfach gefolgt werden kann. Die Commitliste ist dafür nur begrenzt geeignet, deswegen werde ich jetzt einfach öfter mal vorstellen, was ich inzwischen getan habe. Immer gilt: Wenig davon ist unumstößlich.

Datumseingabe

Die Datumseingabe im Eintragseditor ist ein Textfeld, das nur funktioniert, weil es vorgefüllt wird. Ansonsten ist es ein normales Textfeld und der Nutzer müsste ein valides Datumsformat erraten. Das Vorfüllen mitsamt dem Button zum Setzen auf die aktuelle Zeit ist eine solide Lösung.
HTML5 bietet eine andere Lösung an: Ein datetime-local Eingabefeld:

Das zu nutzen führt jedoch gleich zu zwei Problemen: Das smartygenerierte Datumsformat zum Vorfüllen des Eingabefeldes muss anders werden, unlesbarer (von YYYY-MM-DD HH:MM zu YYYY-MM-DDTHH:MM) und es wird derzeit von Firefox und mobilen Browsern nicht unterstützt. Für solche Browser wäre das also ein Rückschritt, sie würden das neue Datumsformat in einem normalen Texteingabefeld sehen (alle anderen nicht!). Deswegen brauchte es ein Fallback in der serendipity_editor.js.tpl:

if($entryEditor.size() > 0) {
    $('#serendipityNewTimestamp').val($('#serendipityNewTimestamp').val().replace("T", " "));
}

Durch das Entfernen des T wird das Datumsformat wieder lesbar in Browsern, die datetime-local nicht unterstützen. Bei allen anderen hat der Code keinen Effekt, weil es kein valides Format for datetime-local ist.

Ich hätte lieber ein Polyfill genutzt, aber fand kein funktionierendes - genau genommen fand ich nur ein echtes Polyfill, das jedoch jquery-UI benötigt, und eine JS-Alternative, die jedoch in FF bei mir nicht solide funktioniert.

serendipity_define.js.php

Die serendipity_define.js.php liegt im Hauptverzeichnis und scheint nur eine Funktion zu haben: Die Javascript-Variable xhtml zu setzen. Die Variable wird nicht mehr benötigt und der ganze Mechanismus ist in meinen Augen durch die serendipity_editor.js.tpl, die klarere Strukturierung des Admin-Javascripts und den neuen JS-Hook (siehe unten) gut ersetzt. Sollte ich mich da täuschen, wäre hier und jetzt ein guter Moment mir das mitzuteilen. Fürs Erste habe ich die Datei und ihre Einbindung entfernt.

JS-Hook

Für CSS gibt es einen Plugin-Hook, über den Plugins ihr CSS der vom Kern generierten serendipity.css hinzufügen können. Das macht es für Pluginautoren wesentlich einfacher, CSS-Code auszugeben und führt dazu, dass er weniger häufig einfach stumpf ins HTML geschmissen oder über mehrere Dateien verteilt wird (was zu mehreren GET-Requests beim Seitenaufbau führt). Für Javascript gab es noch keinen solchen Mechanismus, er wäre aber durchaus genauso nützlich. Deswegen habe ich einen Hook namens js zum Kern hinzugefügt, der eine serendipity.js mit dem gesammelten Code aller ihn nutzenden Plugins erzeugt. Ich denke, es wäre auch überlegenswert, den Code des Adminbackends darin zu bündeln. Eventuell fehlt hier noch Logik, um parallel zum CSS eine serendipity_admin.js mit nur dem Code das Backends zu erzeugen, das würde ich hinzufügen wenn es sich als nötig erweisen sollte.

Layout.php Überbleibsel und API-Stabilität

Vor meiner Zeit mit s9y gab es eine layout.php, die wohl statt der Smarty-Templates zur HTML-Codegenerierung genutzt wurde. Es gibt immer noch ein Template im Kern, das eine solche nutzt, das Template newspaper. Die Überbleibsel im Kern zur Unterstützung dieser layout.php habe ich nun entfernt - ich glaube nichtmal, dass diese Methode noch einwandfrei funktionierte, aber selbst wenn ist das einer der alten Zöpfe, die ich für eine bessere Wartbarkeit des aktuellen Kerns gerne los wäre.
In diesem Zusammenhang habe ich die Parameter der generate_plugins-Funktion verändert, nämlich den zweiten Parameter $tag entfernt, der keinen Effekt mehr hatte. Das führt dazu, dass fast alle Aufrufe dieser Methode (zwei im Kern) verändert werden müssen, weil sich ja die Reihenfolge der Parameter danach ändert (PHP kennt nativ keine named parameter). Dagegen hat Garvin zurecht protestiert, und ich habe (in meinen Augen ebenso zurecht) für diese Änderung argumentiert. Das ist kein Streit, sondern eine berechtigte Diskussion um die Frage, ob solche Änderungen im Kern für Nutzer, die ggf gegen den Kern ihre eigene PHP-Seite geschrieben haben, zumutbar und ob sie nötig sind. Ich würde das immer noch bejahen, was aber nicht heißt, dass ich Garvin überzeugt habe. Aber wenn mir jemand mitteilen will, wieviel Mehrarbeit eine solche Änderung für ihn bedeuten würde - ich will sowas noch bei ein paar Funktionen machen - wäre wieder hier und jetzt ein guter Moment.

Das absurde am NSA-Abhörskandal ist, dass nichts davon neu ist. Wir wussten schon lange, dass die NSA allen Internettraffic versucht abzuhören, dass sie Zugriff auf die Server von Facebook und Google haben, dass keiner der US-Dienste sicher ist. Und auch, dass deutsche Firmen keine echte Alternative sind - wenn die USA an Daten will, dann kriegt sie die.

Aber es zu wissen und es wirklich zu wissen ist noch einmal ein Unterschied. Wenn offen darüber geschrieben wird, wenn Deutsche an der Grenze ganz offiziell wegen privaten Facebooknachrichten abgewiesen werden, ist eine neue Stufe erreicht.

Ich hatte vor kurzem schonmal die Erkenntnis, dass meine Daten auf Googles Servern nicht sicher sind, auch wenn es da um den sicheren Fortbestand der Daten ging, nicht ums Ausspionieren. Tatsächlich dachte ich irgendwo schon, dass ein mächtiger Konzern wie Google es verhindern könnte, und mit seiner Hackervergangenheit auch wollen würde, den amerikanischen Geheimdiensten direkten Zugriff auf ihre Server zu geben. Zumindest, solange kein Verdacht besteht, ich oder jemand in meinem Umkreis würde gegen die USA Waffen erheben wollen. Letzter Glaube an das Funktionieren des Systems.

Natürlich sind es nicht nur die Server. Was unverschlüsselt durch die Leitung geht ist öffentlich, dass predigen ja nicht nur SSL-Verfechter seit Jahren. Berichte, welche Probleme die NSA damit hat, all den aufgezeichneten Internettraffic auszuwerten, standen schon vor Jahren in so untergründigen Magazinen wie dem Spiegel. Inklusive Details wie den verschiedenen Datenspeicherarten, dem hierarchischen System von Daten mit direktem Zugriff (=Festplatten) und Daten für später (=Bandlaufwerke und Zeug) und den daraus folgenden Analyseproblemen.

Selbst zu hosten und zu verschlüsseln scheint der einzige Weg, eine halbwegs sichere Existenz aufzubauen - und nein, nicht Internet-Existenz, die Auswirkungen reichen weiter. Ich überlege nur, wie weit man gehen muss. Mail als Beispiel, denn Mail ist für mich der Kernpunkt der Internetexistenz: Ein Mailhosting bei einem anderen deutschen Anbieter ist doch genauso unsicher. Wenn zu PRISM Beteuerungen kommen, dass es keinesfalls gegen US-Bürger gerichtet ist, nur gegen alle anderen, ist doch der logische nächste Schritt, dass nicht nur die US-Gigantenfirmen Ziel der Datensammlung sind, sondern gerade ausländische Hosterfirmen das Primärziel amerikanischer Hackingattacken sein dürften.

Nein, was man absichern kann, muss abgesichert werden. Das braucht eine gewisse Infrastruktur. Dazu gehört die eigene Mailadresse (malte@paskuda.biz). Dazu gehört auch die Software, um Mail von einem beliebigen Mailserver abzuholen (Roundcube derzeit, obwohl das mit gmail nicht in akzeptabler Geschwindigkeit funktioniert. Eventuell muss ich da schon wegen PGP und sicherem Datentransport zu meinem Computer doch zu Thunderbird zurück - kennt jemand gute Alternativen?). Doch der Kern davon muss der auf einem verschlüsselten Heimserver laufende Mailserver sein. Die Hardware dafür hätte ich mit dem Pogo, was fehlt ist die statische IP. Was meine Kommunikationskosten durchaus erheblich erhöhen dürfte.

Gehen wir weiter. Instant-Messaging betrachte ich als gelöstes Problem, der Jabber-Account existiert und das OTR-Plugin in Pidgin ist aktiviert.
Der Blog hier läuft auf seinem eigenen Server, das ist schonmal ein Schritt besser als ein Bloganbieter wie Wordpress.com. Nächster Schritt wäre das Ausliefern über https.
Mailhosting ist nur der eine Angriffspunkt,der andere ist die Mailübermittlung selbst, die muss verschlüsselt werden. Also muss der PGP/GPG-Key erstellt und verteilt werden.
Und dann ist da noch das Handy. Völlig klar, dass dies ein Angriffspunkt ist, Stallman predigt das seit Jahren. Wie ich damit umgehen soll weiß ich noch nicht. Festnetztelefon? Als ob das nicht abgehört werden würde. Vielleicht eine per Telefonnummer erreichbare Skype-Alternative.

Generell wird es wohl Zeit, sich mit den Crypto-Anarchisten mal näher zu befassen.

Für Serendipity 2.0 wurde einiges geplant. Was ist der aktuelle Stand?
Zusammenfassend: Das HTML im Backend ist modernisiert, das Javascript ist zu jQuery portiert und dabei aufgeräumt worden, und es gibt ein neues Admin-Design.

Vorab: Alles, was ich im Folgenden zeige, ist vorläufig. Nicht alles ist abgesprochen mit den anderen, nicht alles wird so kommen, viel kann noch dazukommen. Sowohl funktional als auch auf Designseite.

Das Adminbackend ist von Ian und mir smartifiziert worden. Vorher war das HTML und Javascript in den PHP-Dateien enthalten und wurde von dort ausgegeben, wenn eine Seite aufgerufen wurde. Jetzt macht das PHP seine Aufgabe und stellt die Daten den Smarty-Templates zur Verfügung, die sich dann um die Präsentation kümmern. Wir haben sogar einen neuen Mechanismus, um Javascript-Dateien des Designs per Smarty generieren zu lassen, um dort ebenfalls direkt auf die Daten des PHP zugreifen zu können.

Das heißt: Während in 1.7 das Adminbackend aus den PHP-Dateien in include/admin/ generiert wurde, war der Frontend-Part zwischenzeitlich in include/admin/tpl/ und ist jetzt in templates/templatename/admin/.

Das alles erleichtert uns die Aufgabe, das Admin-Backend zu modernisieren - HTML5, jQuery und allgemeine Verbesserungen. Das wird im Rahmen des hervorragenden 2k11-Designs von Yellowled gebündelt, der auf der Designseite auch im Backend den Großteil der Arbeit gemacht hat. Dieses 2k11-Design soll bulletproof als Default-Design ersetzen und ist auch schon als solches gesetzt.

Die genutzten Smarty-Templates sind jetzt Teil des Designs, nicht mehr Teil des Kerns. Das ermöglicht es theoretisch, sehr unterschiedliche Adminbackends zu designen. Aber auch der Installer gibt jetzt sein HTML per Smarty-Template des Designs aus (wodurch die serendipity_admin.php um 200 Zeilen schrumpfen konnte).

Von den Code-Änderungen sieht man als Nutzer natürlich wenig, sie führen vor allem zu besser wartbaren Code. Aber was man durchaus wahrnimmt ist das 2k11-Adminbackend:

Ich fand es beeindruckend, wie deutlich anders das Backend alleine durch die Verbesserungen beim HTML und die andere Farbgebung wirkt. Mir gefiel der Effekt sehr gut.

Ansonsten ist es bisher größtenteils das alte Backend. Wir kommen jetzt erst an den Punkt, an dem wir grundlegendere Änderungen ausprobieren können, wie beispielsweise eine andere Navigationsstruktur. Ein paar Änderungen boten sich direkt an. So wurden die Einstellungen des Designs auf eine eigene Seite verfrachtet:

Und in der Mediendatenbank gibt es eine Reihe von Änderungen, wie ein Anzeigen der Informationen per Overlay und Buttons zum Filtern nach Dateityp:

Generell wurden die Filter versteckt, auch in der Eintragsliste:

Soviel zum Backend.

Ein Serendipity 2.0 könnte auch Änderungen auf anderer Ebene bringen, inklusive neuer Funktionen. Gleichzeitig soll natürlich nicht alles umgeschmissen werden und als altes System ist der Großteil dessen, was man sich vorstellen kann, schon umgesetzt. Ich werde mich aber sicher noch am Caching probieren und ein Autospeichern des Editors per localStorage implementieren. Was sich noch ändern wird ist die Auswahl mitglieferter Plugins, beispielweise ist der Kalender inzwischen ein Relikt einer vergangenen Blogzeit. Aber in der Richtung ist noch nichts großes passiert, daher kann ich da auch nichts zeigen.

Yellowled wollte den aktuellen Stand auch vorstellen - er kann sicher viel mehr zu den Details des Admindesign sagen als ich - das würde ich dann hier verlinken.