supergarv

Isotopp hat auf seinem Blog von flattr berichtet. Das war für mich der tipping point, um mich auch selbst ernsthaft mit flattr zu beschäftigen, das derzeit behypt wird.

Flattr ist eine Social-Micropayment-Service, auf dem man ein Budget verwalten kann, das anderen Leuten (und auch einem selbst) zu Gute kommen kann, die kostenlosen Content produzieren. Wie der Dienst schon selbst sagt, es ist etwas zum Liebe zurückzugeben. Solche hehren Weltverbesserungsziele unterstütze ich immer gerne.

Daher habe ich auch für Serendipity ein Flattr-Plugin gebastelt, dass nun auch hier zum Einsatz kommt. Wer es gerne benutzen will findet es beim üblichen Verdächtigen Spartacus. Man kann damit pro Eintrag bestimmen ob ein Eintrag geflattrt werden soll, mit welchen Attributen etc.

Mehr zu dem Plugin gibt es im s9y blog.

Stefan Esser, Rächer der Exploitierten, Injection-Schnüffler Extraordinaire und Fiebertraum aller Entwickler hat im Rahmen des diesjährigen Month of PHP Security mal wieder zugeschlagen, und unter anderem eine größere Sicherheitslücke in Xinha gefunden.

Xinha ist ein WYSIWYG-Editor, der angenehm komfortabel ist und dessen Vorgänger htmlarea seit Urzeiten in Serendipity integriert war. In Version 1.4 haben wir den Umzug auf Xinha gemacht, der mittlerweile einiges an neuen und coolen Features bietet. Viele davon nutzt Serendipity garnicht unbedingt, und das wurde uns jetzt zum Verhängnis.

Ein Sicherheitsleck in deren Plugin-API ermöglicht die Übermittlung von dynamischen Parametern zur Konfiguration des Xinha-Backends, das unter anderem das ImageManager und ExtendedFileManager-Plugin einsetzt. Diese PHP-Dateien sind auch leider extern aufrufbar, und ermöglichen den Upload von beliebigem PHP-Code.

Klingt ätzend, ist es auch. Serendipity's neue Version hat diese Funktionalität nun kurzerhand deaktiviert, und alle Serendipity-Nutzer sind aufgefordert entweder auf 1.5.3 zu aktualisieren oder kurzerhand die Datei htmlarea/contrib/php-xinha.php zu löschen. Wenn das Xinha-Team den Bug etwas genauer inspiziert und behoben hat, wird es sicher nochmal einen korrekteren Fix als unseren geben.

Bitte weitersagen, schnell fixen, und Stefan für das Finden danken. Nur durch derartigen, unermüdlichen Einsatz werden OpenSource-Systeme im täglichen Einsatz sicherer, und die Entwickler sensibler auf derartige Lücken hingewiesen. Auch wenn solche Lücken kurzfristig immer weh tun, derartige Full Disclosures sind unabdingbar. Danke, Stefan!

Ich bin ein großer Nörgler, und reize das Spektrum an konstruktiver Kritik immer gerne voll aus. Ausserdem lese ich gerne Fachliteratur über PHP/Web-Entwicklung.

Da liegt es nahe, meine 2 Cents in Form von technischen Reviews oder Übersetzungen zu Büchern beizutragen, wie z.b. beim PHP kurz&gut Handbuch oder der Übersetzung des phpMyAdmin-Handbuchs - oder natürlich dem eigenen Serendipity Handbuch.

Das erste Mal überhaupt habe ich für den PacktPub-Verlag das phpMyAdmin-Buch reviewed. Die Zusammenarbeit mit dem phpMyAdmin-Projektleiter Marc Delisle war damals schon sehr angenehm, und das erste richtige Buch zu PMA konnte in vielen Feedback-Iterationen entstehen. Später hat mich PacktPub auch noch für andere Bücher angefragt, vor einem Jahr ein Buch zu Moodle.

Das Thema interessierte mich, ich habe Kommentare beigetragen und das ein oder andere Kapitel verrissen, nur um am Ende rauszufinden dass mein Feedback ignoriert wurde. Daraufhin hab ich meinen Namen aus dem Teaching Moodle-Buch entfernen lassen und war etwas frustriert (was ich dem scheinbar mittlerweile indischen Verlag auch mitteilte).

Vor einigen Monaten fragte man mich erneut ob ich diesmal ein Buch namens PHP Team Development reviewen wollte. Ich wollte, denn das Thema ist für mich natürlich auch sehr wichtig, und man versprach mir diesmal viel Sorgfalt walten zu lassen. Immerhin gibt es ja auch einige recht gute Packt-Bücher.

Die ersten Entwurfs-Kapitel dieses Buches waren grausam.

Zum einen merkte man deutlich, dass ein Non-Native Speaker seinen Text zum besten gibt, zum anderen waren die Kapitel voll inhaltsleeren buzzword-droppings, falschen Vereinfachungen und auch ohne relevanten Praxisbezug. Das Buch schien ausgerichtet für den "Human Resources Manager", der von Programmierung keine Ahnung hat, und nur gerne für's nächste Team-Meeting ein paar weise Zitate loswerden kann.

Also habe ich mir die Finger wundreviewed und meine Meinung abgelassen, die auch jedesmal dankend angenommen wurde.

Gen Ende des Buches wurden die Tipps und Alltags-Beschreibungen von PHP-Entwicklung im Team etwas konkreter und auch besser zusammengefasst. Nach etwas Funkstille folgte dann der Hinweis, dass die erste Reviewrunde zu Ende sei, ich bekam eines der späteren Kapitel zum probelesen, und sah in dem Kapitel mein Feedback sogar auch teilweise implementiert.

Hurrah, dachte ich mir - Feedback ist doch produktiv. Da ich den Sommer über mit einem neuen Projekt ausgelastet war, fehlte mir die Zeit den zweiten Schwung Entwürfe durchzulesen, das Buch ging in den Druck, mein Reviewer-Name steht im Cover, ich kriege das Final-Exemplar und:

Verdammt.

Ein Großteil der Kapitel ist nach wie vor Buzzword-geschwängert, schmeißt mit teilweise realitätsfernen Empfehlungen oder unlogischen Schlüssen um sich.

Einerseits denke ich mir, "Ich bin ja nur der Reviewer, mehr als meine Meinung sagen geht nicht". Auf der anderen Seite sehe ich ein Buch vor mir, dass ich in weiten Teilen nicht gut finde. Auf der einen Seite hätte ich mir die Zeit nehmen sollen die zweite Reviewrunde zu nehmen, auf der anderen Seite kriege ich dafür kein Geld, mache es zum Spaß, habe meine Kritik konkret und konstruktiv geäußert, und bin ja auch nicht der Autor.

Wie auch immer, aus solchen Fehlern lernt man. Wer etwas Spaß haben möchte und vom Fach ist, wird mit diesem Buch übrigens dennoch Freude haben!

Heute ein PHP 5.3 update gemacht und danach einige Schwierigkeiten bekommen.

Abgesehen davon, dass PHP 5.3 mit seinen E_DEPRECATEDs mit sich herumschmeißt als seien die im totalen Ausverkauf, hatte ich danach einige Probleme die Anwendungen auf dem Server wieder ans laufen zu kriegen.

Letztlich war das Problem einfach nur, dass die neu aufgespielte php.ini (im Debian-Paket) zwar sessions konfiguriert, aber keinen default session.save_path gesetzt hat. Darauf aufsetzende Anwendungen haben also alle gedacht sie könnten Sessions nutzen, obwohl nirgends etwas geschrieben wurde.

Das nur mal so als Memo an mich.

Andy wollte gerne einen eigenen Linktrimmer, um so etwas wie TinyURL, Tr.Im und Bit.ly lokal abzubilden. Das hat Sinn, denn wie man just an Tr.im gesehen hat, kann ein derartige Service jederzeit ausfallen und die liebgewonnenen URLs töten. Da ist man in manchen Fällen also lieber selber für seine Daten und Backups verantwortlich.

Eigentlich wäre es ein leichtes, ein dediziertes PHP-Script dafür aufzusetzen. Aber weil ich sowas auch gerne haben wollte und es eine 30-Minuten-Fingerübung wäre, habe ich es als Serendipity-Plugin implementiert.

Das Plugin kümmert sich darum, ein Kürzungsinterface direkt im Backend vom Blog einzubinden, und auch als zusätzlicher Button beim Erstellen von Blog-Einträgen. In der Eingabemaske trägt man die zu kürzende URL ein, ggf. optional den eigenen Hash, klickt auf den Go-Button und erhält einen Link zum eigenen Blog zurück, der dann auf die eingebene URL per 301 Redirect weiterleitet.

Die Links werden automatisch durchnummeriert (sind daher also auch "iterierbar" durch Besucher) udn mit meinem Base62-Verfahren gekürzt. Aus einer Zahl wie "10" wird daher "A", aus "61" wird "y" - und bis die URL also lang wird, hat man viele Links gesammelt.

Das ist derzeit alles noch sehr grob und für meine/Andys Bedürfnisse geschnitzt. Aber vielleicht hilft es ja dem ein oder anderen. Denkbar wäre in einer weiteren Ausbaustufe noch eine Art bookmarklet für noch einfachereres wandeln - das sind nämlich derzeit Komforts, die man sich bei der Nutzung von externen Diensten noch erkauft.

Vielleicht wäre es später auch noch nett, das Plugin mit dem tollen Twitter-Plugin von Grischa zu verheiraten, um die Links mit dem eigenen Trimmer zu kürzen. Das wiederum macht aber dann Tweetbacks schwerer. Naja, das Leben ist ein ständiger Kompromiss.

Das Plugin liegt derzeit als serendipity_event_linktrimmer im Spartacus-CVS und kann hier runtergeladen werden:http://php-blog.cvs.sourceforge.net/php-blog/additional_plugins/serendipity_event_linktrimmer, ein ZIP-Archiv für besonders hastige habe ich temporär auf meinen Server geladen. Auf meinem Server regelt eine zusätzliche .htaccess dann die Weiterleitung von Links im Stammverzeichnis auf meine s9y-Installation.

Meinungen?

Ich hätte da gerne ein Stück Software, was für mich IMAP-Konten unterschiedlicher Server als "virtuellen" Unterordner eines unabhängigen IMAP-Servers mappt.

Oder verbose formuliert:

Ich habe einen lokalen Courier IMAP Server auf meinem Heimserver. Der enthält mein maildir, dass via fetchmail mehrere POP-Accounts abgreift, die ich dann einfach via IMAP gruppiert darstellen kann.

Da ich jetzt einen Kollegen mit zwei Mailaccounts urlaubsmäßig vertrete, möchte ich dessen Mails (IMAP-Konto) gerne in meinen Master-Account reinziehen. Da aber auch andere Kollegen sein Mailfach abrufen, darf ich die Mails nicht beim Abruf löschen - und vor allem sollte der "Gelesen"-Status bei Abruf egal welcher Person beibehalten werden. Wenn ich z.b. Mails lese oder Spam lösche, sollen die anderen Kollegen das nicht auch nochmal tun müssen.

Daher kann ich nicht einfach per fetchmail auch noch den IMAP-Account abrufen, denn wenn ich dann die Mails lokal bei mir lese werden sie auf dem Remote-Server ja nicht als gelesen markiert.

Am coolsten stelle ich mir einen virtuellen IMAP-Folder vor, der dann nicht in meinem ~maildir/ liegt, sondern bei jedem Aufruf quasi die IMAP-Kommandos an den remote Server weiterleitet. Mein Googlen hat leider nichts derartiges hervorgebracht, aber ich bin überzeugt dass die Grundidee was ziemlich cooles sein könnte.

Technisch sollte das vielleicht auch nicht so schwer sein, da das ganz ja quasi nur ein Proxy ist, der die Client-Request und Remote-Server-Response 1:1 an den Client weitergibt. Es gibt zwar IMAP Proxy-Software, aber die integriert sich halt nicht innerhalb meines normalen IMAP-Servers.

Ziel soll halt sein, alles auf meinem iphone mit einem einzigen Server lesen und synchen zu können.

Geht das, gibt's das?

Liebes Interdings,

ich hätt' da mal ne Frage.

Gegeben ist Browser F auf Netbook N, das auf Webseite W zugreift. Webseite W nutzt $InsertFavoriteJavaScriptFrameworknamehere um per Ajax Daten nachzuladen.

Diese Daten möchte ich gerne mit meinem eigenen Inhalt anreichen, im besten Fall mit einem eigenen AJAX-Request-Ergebnis vermengen.

Ich vermute, dass so etwas mit GreaseMonkey funktionieren könnte. Am liebsten würde ich dem Browser gerne sagen "nimm anstelle der Funktion get_stuff() im Inhalt von W die folgende javascript-Funktion" und dann mit meiner eigenen austauschen.

Soweit die Theorie, praktisch hab ich erstmal keinen Ansatz wie ein derartiges Userscript auszusehen hätte, und bin gleichzeitig auch nicht in der Lage die richtigen Keywords zu nutzen um rauszufinden, wer sonst noch mal so ein Problem wie ich hatte.

Abseites von Greasemonkey wäre so etwas wie ein Adblocker cool, der eine URL mit einem speziellen Muster (z.b. www.domain.de/ajax.php?modus=1) abfängt und dann eine eigene Funktion (JavaScript) im Browser sozusagen als Wrapper ausführt.

Theoretisch könnte man sowas sicher auch mit nem dazwischengeschalteten Proxy lösen, aber diese Spatzenkanone möchte ich erstmal nicht zücken.

Hat da jemand Ideen für mich?

Irgendwann diese Woche hat mich Absynth auf den SaaS APS-Service hingewiesen. Dieser Paketstandard ermöglicht es Hostern und damit den Kunden wohl (in der Theorie) relativ einfach, Web-Software zu installieren. Auch von Serendipity gibt es ein derartiges APS-Paket, auch wenn mir unbekannt ist, wer dieses Paket herstellt.

Da das Paket veraltet ist, wollte ich gerne meine Hilfe beim Paket-Maintainer anbieten, Serendipity hier sinnvoll zu unterstützen. Da 1&1 als Deutscher Internet-Dienstleister scheinbar mit federführend bei den Paketen zu sein scheint, und auch Serendipity anbietet, habe ich die Vermutung dass dort vielleicht das APS-Paket erstellt wurde. Daher habe ich eine E-Mail an 1&1 geschrieben. Schon auf der Homepage war es nicht wirklich möglich, eine zuständige Mailadresse dafür zu finden, und ich habe die globale info@einsundeins.de genommen, und dort nett nachgefragt wo man mir denn helfen kann.

Überraschenderweise erhielt ich heute die Antwort:

Sehr geehrter Herr Hiking [sic],

vielen Dank für Ihre Nachricht.

Wir bitten Sie Ihre Anfrage schriftlich einzureichen unter folgender
Adresse: ...

Das kann ja wohl nicht mein Ernst sein. Ein Internet-Dienstleister, bei dem ich meine Anfrage SCHRIFTLICH richten soll? Am liebsten wohl noch mit Einschreibe-Rückbrief und persönlicher Übergabe? Spaß beiseite. Das intern an die richtige Adresse weiterzureichen oder gar die E-Mail im Hause auszudrucken und an einen Postverteiler weiterzugeben kann ja wohl nicht so schwer sein. Ich werde hier nicht anfangen und deshalb zur Post gehen, Porto bezahlen, Briefumschläge kaufen etc. Dann ist die Sache wohl eher an Bürokratie gescheitert.

Etwas ähnliches habe ich als E-Mail Antwort geschrieben, ich vermute allerdings eher, dass sowas nicht auf Gehör stößt. Arbeitet einer meiner Leser bei 1&1 und mag mir beim Vitamin-B-Weg behilflich sein, dass Serendipity-Anliegen auf Gehör zu stoßen?

UPDATE 14:00 Uhr, auf meine Mail antwortete man:

Sehr geehrter Herr Hicking,

vielen Dank für Ihre Nachricht.

Ihr Angebot kann nur intern weitergeleitet werden. Dieses erfolgt am
besten schriftlich.

Wir bitten um Verständnis für unsere Entscheidung.

Also bei mir in der Firma habe ich eine E-Mail-Adresse, so dass ich auch intere Mitteilungen erhalten kann.

UPDATE 18:00 Uhr, jetzt hat sich dann doch der rumänische Produktmanager bei mir gemeldet. Perfekt, und ich danke Kris' und Cruiser's Bitamin-B - was auch immer da jetzt ausschlaggebend war.

Am Wochenende habe ich die Zeit mal genutzt, um ein Kernel-Update des etwas riechenden 2.6.17 auf 2.6.27 zu machen, ausgelöst durch ein udev-Update von Debian Etch.

Das ganze Vorhaben ging eigentlich halbwegs gut: Die alte .config vom alten System in die neu entpackten Kernelsourcen reinkopiert, ein make oldconfig und einige Stunden Konfigurationsoptionen lesen später konnte ich mit make-kpkg buildpackage modules modules_config modules_image --revision 20081019 --verbose das Kompilieren eines .deb-Pakets auslösen.

Das wurde dann per dpkg -i ... installiert, danach noch grub für den neuen Kernel eingerichtet, neugebootet - und die Kernel Panic angestarrt.

Grund dafür war, dass ich beim kompilieren wohl nicht den richtigen HDD-Treiber in den Kernel kompiliert hatte. Also Reboot mit dem alten Kernel (den ich glücklicherweise noch hatte) und nochmal neu kompiliert, diesmal mit allem was mir nach SATA und PIIX aussah. Der Reboot lief etwas besser, diesmal wurde mir gesagt ich müsse einen korrekten boot=-String beim Booten angeben. Mit /dev/sda2 wie vorher klappte es nicht, dmesg sagte mir es stünde nur zur Verfügung. Nun gut, mit boot=/dev/hdb2 klappte dann alles, auch wenn ich dann einige fstab's anpassen durfte.

Später fiel mir dann auf, dass die I/O-Werte des Systems alles andere als rosig waren. Dateien zu kopieren dauerte Ewigkeiten, und ein kurzes Konsulat mit Andy und dem Herrn Linuxtigger war ich aufgeklärt: Da hat sich wohl der alte Generic IDE Treiber das SATA-Interface geschnappt und libata keine Luft zum Atmen gelassen.

Also den Kernel nochmal neu konfiguriert: EIDE-Kram überall raus, und nur das neue SATA-PIIX-Interface (libata) aktiviert, Kernel neu kompiliert, Paket installiert, Kernel-Optionszeile angepasst und rebootet: Et voila, alles war schneller.

Soviel also zu den Dingen, die mich so nebenher beschäftigen.

1. Superschnell.


2. Die Tabverwaltung rockt megamäßig. So ist das viel konsequenter. Me Likey.


3. JavaScript ist zügig, scheint bisher kompatibel zu allen meinen Tests. Auch Rendern der Seiten sieht verhältnismäßig gut aus, wie von Safari gewohnt.


4. Drag and Drop von Tab-Reitern ist spaßig.


5. Das lightweight Interface gefällt mir gut, auch die Farbgebung. Weniger das Taskleisten-Symbol.


6. Derzeit Windows-Only builds verfügbar? Fail.


7. Mir fehlen Optionen in dem Browser, ich will Optionen! Man kann scheinbar noch nichtmal die Rechtschreibkorrektur in Textareas ausschalten.


8. Chrome hat scheinbar dieselbe fehlerhafte Input-Autospeicherung wie Firefox3: In einigen Applikationen werden Felder mit Username/Passwort vorausgefüllt, wo es keinen Sinn macht. Serendipity inklusive.


9. Überall resizable Textareas, das macht Sinn.


10. Die Suchfunktion innerhalb einer Seite ist praktisch. Trotzdem fehlt mir das "Type ahead" von Firefox


11. Firebug und LiveHTTPHeader fehlen mir gewaltig. Ich bin gespannt, was Chrome/WebKit in Sachen Plugins so zulässt.


12. Der Task-Manager ist cool, aber ich hätte mir Speicheraufteilung nach Javascript-Dateien z.B. gewünscht. Auch scheint mir der Memory-Footprint pro Tab eher zu groß zu sein.


13. Schön, dass Ctrl-K und Ctrl-L wie in Firefox funktionieren.


14. Die Popup-Verwaltung pro Tab ist optimal. Auch liebe ich, dass ein amoklaufendes javascript alert() Fenster keine Auswirkungen auf andere Tabs mehr haben sollte. In der jetzigen Beta ist das aber leider dennoch immer der Fall, alerts sind modal.

Hauptsächlich die Textarea-Syntaxhighlighting-Sache macht mich gerade fuchsig und ist der Hauptgrund, warum ich's wohl erstmal nicht produktiv einsetzen werde. Auch die Auto-Completion von Input-Feldern ist fatal.

Naja, erstmal googlen ob man es nicht ausgeschaltet kriegt.

Update: Ich sammle erstmal an Punkten, bevor ich die derzeit schon überlaufene Discussion-Liste noch weiter aufblähe. Größte Kritik: Textarea-Syntaxhighlighting, Falsches Auto-Remember, modale Alerts, fehlendes LiveHTTPHeader.