qrios

WordPress unterstützt von Hause aus kein Geotagging für Artikel oder Fotos. Da hätte ja vor Jahren auch keiner dran denken können. Allerdings bietet z.B. die iOS-App die Möglichkeit, die aktuellen Koordinaten als Metainformationen mit in der Datenbank zu speichern. (In der App kann man jedoch keinen abweichenden Ort für den Artikel hinterlegen.)

Mit ein wenig Phantasie kann man sich jedoch etliche Anwendungsfälle für eine solche Information vorstellen. Von Restaurantkritiken, über lokalisierte Google-Suche und Reiseblogs könnten von Ortsgebundenen Posts profitieren. Man stelle sich nur eine Fahrt ins Grüne vor bei der man seinen RSS-Feedreader öffnet und die Posts verschiedener Blogs nach Entfernung sortiert werden. Aber auch die RSS-Formate haben von Hause aus keine Felder für Latitude und Longitude (Hier gibt es ein Beispiel, wie man mit .Net Feeds um Geoinformationen erweitert.) Nichts desto trotz gibt es aber auch (noch) keinen RSS-Reader, der die Koordinaten auch verarbeiten kann. Ein typisches Henne-Ei-Problem.

Für unser neues Blog-Projekt umberlinrum.de haben wir eine Lösung gesucht, die mit den Meta-Informationen umgehen kann. Erstens sollen zu den Artikeln Karten eingebettet werden, die den beschriebenen Ort oder die Route darstellen können, zweitens sollen die Posts nach Entfernung sortiert werden können, respektive Artikel aus der Nähe automatisch verlinkt werden und drittens soll WordPress später mal ein KML-File anbieten, das Orte und Routen verlinkt.

Die Wanderdüne in der Nähe von Jüterbog als eingebettete Google-Maps in einem WordPress-Post.

Für die Karten fand sich das sehr gute WortPress-PlugIn Google Maps GPX. Mit seiner Hilfe kann man mit kurzen Angaben wie

[map lat=51.493 lon=7.45 z=15 maptype=satellite]

eine Karte in einem Post positionieren. Karten von Google Maps und OpenStreetMap sind möglich, Marker und Routen. Man kann sogar Fahrradwege und die aktuelle Verkehrslage einbinden. Mit Hilfe von GPX-Routen-Daten (z.B. aus Track für iOS) oder KML-Files lassen sich auch Routen incl. Höhenverlauf darstellen.

Allerdings braucht das PlugIn immer noch die manuelle Eingabe der Koordinaten und kann diese leider nicht aus eventuell vorhandenen Meta-Informationen oder gar aus den EXIF-Daten von eventuell vorhandenen Fotos extrahieren und als Basis für die Karten verwenden.

Für die Sortierung der Ergebnisse nach Entfernung bietet sich das WP-PlugIn “WP Smart Sort” an. Damit kann man beliebige Felder aus der WP-Datenbank (native ebenso wie Meta-Informationen) auswählen und als Widget für eine Sortierungsoption in die Seite einbauen. Es ist relativ rudimentär und liefert nur ein Pull-Down-Menue. Es verwendet jedoch echte URLs ohne dynamische Parameter, so dass es sich leicht überall als Link einbauen lässt.

Für die Sortierung nach Entfernungen tritt jedoch ein etwas komplexeres Problem zu Tage. Die Koordinaten sind natürlich als Latitude und Longitude angegeben und es macht keinen Sinn, Artikel erst nach Breite und dann nach Höhe sortieren zu lassen. Als einfache Lösung bietet sich Pythagoras an: WURZEL((ORIGIN-LAT – TARGET-LAT)^2 + (ORIGIN-LON – TARGET-LON)^2). (Wobei die Längen- und Breitengrade natürlich noch normalisiert werden müssten. )

Trägt man diesen Wert dann als zusätzliches Feld in die Meta-Informationen ein, kann man Smart Sort so konfigurieren, dass der Wert als Sortierungsparameter verwendet wird. Dabei kommt dann zum Beispiel eine solche Liste hier raus: Liste der Artikel sortiert nach Entfernung von Berlin aus. An dem KML-Export und den Daten im RSS-Feed muss nun noch gearbeitet werden.

Mein typisches Vorgehen bei der technischen Evaluation bei einem Projekt läuft in etwa immer gleich. Können wir XSLT einsetzen: Ja? Ok! | Nein? Glaub ich nicht! In den meisten Fällen bedeutet das jedoch, dass entweder nur libxslt und damit XSLT-Version 1 zum Einsatz kommt oder über einen System-Call Java mit Saxon gestartet werden muss. XSLT 1 ist allerdings sehr beschränkt da die Unterstützung für Gruppierungen und Sequenzen nicht gegeben ist. Und der Umweg über Java/Saxon scheidet wg. der dafür anfallenden Zeitkosten in den meisten Fällen aus.

XSLT 2.0 ist seit 2007 definiert und nach wie vor gibt es keinen Prozessor, der es vollständig unterstützt. Mit Ausnahme von Saxon gibt es eigentlich gar keinen Prozessor der es irgendwie unterstützt. Und Saxon gibt es nur für Java und .Net. Eine Implementierung durch libxslt scheint gescheitert und wird offensichtlich nicht weiter betrieben. Und damit steht es für alle hippen Techniken wie Ruby oder Node nicht zur Verfügung.

Robbert Broersma hat sich nun zum Ziel gesetzt XSLT 2 für node.js umzusetzen. Unter XSLT2.org kann man sich für einen Betatest anmelden. Denn derzeit hat er den Code noch nicht zur Verfügung gestellt. Laut eigener Aussage soll dies im Laufe des Jahres geschehen. Da die Implementierung nicht auf node.js beschränkt ist sondern auch in den Browsern arbeiten soll dürfte es sich um eines der spannendsten Projekte aktuell handeln.

Als ein spannendes Anwendungsgebiet kann man sich zum Beispiel die Chartgenerierung oder Sprites vorstellen. Während ein node-Prozess sich um die Transformation aus Templates zu HTML beschäftigt wird aus den XSLTs ein weiterer node-Service aufgerufen der zum Beispiel dynamische Images aus einer Datenbankabfrage generiert und diese für den direkt folgenden Aufruf durch den Browser cached. Da bei einem solchen Setup sowohl zum Beispiel canvas und Flot zum Einsatz kommen kann, könnte der Server in Abhängigkeit von den Fähigkeiten oder der Geschwindigkeit des Browsers die Arbeit an den Browser übergeben oder sie selbst durchführen.

Hier und da poppt seit Jahren eine mehr oder minder starke Furcht vor Algorithmen auf. Egal ob von Meckel, Schirrmacher oder anderen Fuilleton-Natives ist der Tenor immer ähnlich: wir werden alle störben Algorithmen sind dabei den Menschen einzuschränken. Da freut es denjenigen, der sich im Studium mal intensiv mit Technikkritik beschäftigt hat dann doch, dass auch mal eine etwas kenntnisreichere Stimme zu Wort kommt. In der SZ erschien ein Artikel von Kathrin Passig mit dem Titel “Warum wurde mir ausgerechnet das empfohlen?“.

Nun ist Kathrin Passig nicht unbedingt ausgewiesene Algorithmus-Expertin hebt sich aber durch digitale Erfahrung erfrischend von den Mahnern ab. Nur leider hat sie das Thema auch nicht verstanden. Was schade ist, da mspr0 ihr gleich zur Seite springt und ihre (Falsch-)Aussagen kunstvoll in seine These vom Kontrollverlust und der darauf zwangsläufig folgenden Postprivacy einflechtet. Warum Falschaussagen? Weil sie zum Beispiel eine Bestsellerliste einem Algorithmus gegenüberstellt. Dabei ist eine Bestsellerliste genau das: das Ergebnis eines Algorithmus. Den können zwar alle verstehen aber dadurch wird er nicht zum Nicht-Algorithmus.

Für sie ist – wie für die Mahner – ein Algorithmus etwas, das (bei genügend großer Komplexität) ein Mensch nicht mehr verstehen kann. Dazu wird ein (unverlinktes) Zitat bemüht:

Die am Wettbewerb beteiligten Teams [die Programmierer der Algorithmen] gaben in Interviews an, nicht mehr nachvollziehen zu können, wie ihre eigenen Algorithmen zu manchen Ergebnissen gelangen.

Diese Aussage kann man jetzt in mindestens drei Richtungen deuten. Die Programmierer verwenden Code, den sie nicht selbst geschrieben haben (Framework, Compiler) und dies führt zu einem Black-Box-Verhalten, die Programmierer haben Code geschrieben, der sich selbst verändert oder die Programmierer kennen nicht mehr alle Werte, der zu diesem Ergebnis geführt hat.

Der erste Fall kommt recht häufig vor ist aber sicher nicht gemeint, da die konkrete Implementierung egal ist, solange das gewünschte Ergebnis produziert wird. Sollte mein Code trotz eingehender Prüfung nicht mehr das tun, was ich gerne hätte, würde ich überprüfen, ob die beteiligten Frameworks nicht das tun, was ich erwarte und im letzten Schritt, ob der Compiler merkwürdige Seiteneffekte produziert. (Aber normalerweise würde ich erst mal schlafen gehen, weil sich das Problem am nächsten Tag meistens in Luft aufgelöst hat.)

Der zweite Fall ist schon etwas komplizierter. Selbstveränderlichen Code gibt es bereits und wird insbesondere von Virenprogrammierern eingesetzt. Dabei geht es aber nicht um eine Veränderung der prinzipiellen Funktionsweise im Sinne von Evolution sondern lediglich um Mimikri. Ein solcher Code würde im Idealfall tatsächlich dazu führen, dass selbst die Entwickler ihn nicht mehr ohne eingehendes Studium von jedem anderen Code unterscheiden könnten und nicht sagen könnten, was der Code tut. Und dies obwohl sie ihn selbst geschrieben haben.

Es ist mit hoher Wahrscheinlichkeit in dem Zitat der dritte Fall gemeint. Eine Liste von Eingabewerten wird immer wieder durch die Maschine geschickt und kalibriert die vorgegebenen Schwellwerte an Hand von Erfolg und Misserfolg. Dabei kommt in den einzelnen Zwischenschritten viel Stochastik zum Einsatz und ab und zu wird mal der Zufallsgenerator angeworfen, um das ganze System vor der zwangsläufigen Stasis zu beschützen. Die eingesetzen Algorithmen sind in den meisten Fällen mit den mathematischen Fähigkeiten eines Realschülers zu verstehen. Die anscheinende Komplexität entsteht nur aus der Anzahl der Eingabedimensionen und der Anzahl der Iterationen.

Wichtig an diesem Punkt ist besonders der Begriff des Schwellwertes. Denn hierbei handelt es sich nicht um ein einzelnes Bit, dass gesetzt ist oder nicht. (Aber selbst bei solchen Systemen kommen schon komplexe Verhalten zu Stande. Dazu möge man sich die dreißig Jahre alten Arbeiten über zelluläre Automaten von Stephen Wolfram ansehen.)

Schwellwerte werden normalerweise als Fließkomma implementiert. Computer und damit auch Algorithmen sind allerdings recht ungenau im Umgang mit Zahlen wie 1/3 oder Wurzel aus 2. Da es sich um endlose Zahlen handelt muss eine CPU diese Werte runden. Und je nach dem, in welchen Zustand (z.B. in welchem Speicher sich die Werte befinden) kommt eine etwas andere Zahl bei der Operation raus. Genau genommen haben wir es hier mit einer Heisenbergschen Unschärfe zu tun.

Da ein Algorithmus jedoch nichts anderes ist als eine Aneinanderreihung von Operationen ist, werden selbst bei exakt bekannten Eingangswerten die Ergebnisse um so unverhersagbarer je öfter eine solche Rundung stattfindet.

Einer der wichtigsten aktuell im Einsatz befindlichen Algorithmen ist die Page-Rank-Berechnung von Google. Obwohl bisher nicht nach aussen gedrungen ist, wie er exakt aufgebaut ist, basiert darauf die ganze SEO-Branche. Für viele handelt es sich um reines Google-Voodoo. Dabei kann man an Hand unterschiedlicher Ergebnisse eine Art Verhaltensforschung betreiben. Und obwohl ich noch niemanden gehört habe, der meint, es würde sich um ein Lebewesen handeln verhält er sich dennoch anscheinend so. Ich kann ihn untersuchen an Hand möglichst vieler Parameter, die er auch (vielleicht) sieht. Seine vollständige Funktionsweise könnte ich jedoch nur ermitteln, wenn ich ihn immer wieder in den gleichen Zustand versetzen könnte, was ginge. Ich müsste allerdings auch seine Umwelt wieder in den gleichen Zustand versetzen, was nicht ginge.

Nichts desto trotz ist der Page-Algorithmus einfach und Lerry Page versteht ihn sicher nach wie vor und etliche seiner Mitarbeiter auch.

(Quelle animiertes Gif: http://de.academic.ru/dic.nsf/dewiki/279011)

CouchDB in der Version 1.2.0 respektive die Adminoberfläche Futon hat einen Bug, um den sich offensichtlich keiner kümmert, weil die ganzen Leute ja sowieso das Interface insbesondere für die Views nicht benutzen. Für mich war das allerdings nervig, weil ich die Views tatsächlich unter Futon teste. Wollte man einen View speichern kommt die Meldung:

Cannot save view because the design document language is “undefined” not “javascript”.

Nun ist Undefined tatsächlich nicht JavaScript aber daran sollte sich doch keiner stören. Egal. Hier ist der Workaround (nicht schön aber …):

Man gehe zu der Datei futon.browse.js im CouchDB-Paket. Dort findet sich in der Zeile 558 “success: function(doc) {“, man füge danach

doc.language = ‘javascript’;

ein und gleiches tue man nach der Zeile 506. Danach hat man keine Probleme mehr mit dem Sichern von Views. Ist natürlich dann auf JavaScript für die Map- und Reduce-Funktionen angewiesen.

Mit dem vorhergesagten Ende von Flash auf mobilen Geräten und dem damit ebenso vorhergesagten Ende von Flash auf den meisten anderen Geräten hat die Content-Industrie plötzlich ein Problem, das sie eigentlich als schon gelöst angesehen hatte:

Wie vertreiben wir unseren Content im Netz ohne jegliche Kopiermöglichkeit?

Die drei wichtigsten Distributionskanäle (Kino, Silberscheibe, TV) sind alle – trotz hartnäckiger Bemühungen – geknackt. Daher finden sich alle dort veröffentlichten Filme innerhalb kürzester Zeit auf allen Verbreitungsplattformen im Netz.

Ein sicherer Channel im Netz hätte die Chance geboten, wenigstens die Filme die es nicht ins Kino schaffen, weil sie dort keinen großen Erfolg versprechen, längere Zeit im Netz laufen zu lassen, ohne dass die Kunden andere als die kostenpflichtigen Quellen nutzen könnten. Das hätte eine schier unerschöpfliche Quelle ewigen Reichtums sein können.

Nun ist Flash tot und ausser Apple hat nur Microsoft ein qualitativ hochwertiges Video-Format wie H.264 im Bundle mit einem halbwegs sicheren DRM. Daher verwundert es nicht, wenn die Content-Leute auf die abstruse Idee kommen, von den Distributions-Plattformen zu verlangen, dass nun Silverlight verwendet wird. Nach Netflix wird auch Lovefilm Silverlight verwenden. Ob diese Entscheidung Microsoft wirklich freuen kann, darf ernsthaft bezweifelt werden. Denn eigentlich steht Silverlight bei MS schon länger auf der Abschussliste.

Die User von Lovefilm sind offensichtlich verärgert über diese Entscheidung und so hat es diese Dinosaurierindustrie mal wieder geschafft, an den Bedürfnissen der User vorbei Entscheidungen durchzusetzen und sich ins Abseits zu manövrieren.

Der Google-Motorola-Deal zeigt offensichtlich Wirkung. HP stellt die komplette webOS-Linie ein.

Im letzten Jahr kaufte HP Palm. Palm hatte es vorher nicht geschafft, den Wechsel auf die neue Plattform signifikant in den Markt zu bringen. Aber offensichtlich hat HP aber offensichtlich ebenfalls nicht den Atem, eine neue Plattform langfristig aufzubauen.

Schade.

Denn webOS ist nach meiner Meinung die Plattform mit dem größten Potential. Denn früher oder später werden VM-basierte Script-Sprachen die wichtigste Basis für Programmentwicklung sein. Und offensichtlich gibt es keine andere Sprache, die in absehbarer Zeit JavaScript den Rang ablaufen könnte.

Der Tod von webOS macht nun aber plötzlich an der anderen Seite den Weg für Google frei. Denn mit ChromeOS betreibt Google ein vergleichbares Konzept. Aber derzeit scheint JS weder auf der Hardware-Seite noch auf der VM-Seite wirklich in der Lage zu sein, die Erwartungen der User zu erfüllen. Google hat mit Android allerdings die Basis, in absehbarer Zeit einen weiteren Layer einzuziehen und sich damit aus dem Stand die JS-Entwickergemeinde zu erschliessen.

Es gab ja schon einige Versuche, Betriebssystemoberflächen in JavaScript nachzubilden, aber eine komplett virtuelle Maschine gab es meines Wissens bisher noch nicht. Fabrice Bellard hat inzwischen eine Implementierung online gestellt. Ruft man die Beispielseite auf startet direkt ein Linux mit dem Kernel 2.6.20 mit einer Command Line. Neben einer Shell und etlichen Unix-Tools ist selbst emacs vorhanden.

Allerdings hat das Gastsystem keinen Zugriff auf das Netzwerk. Was aber laut Forumsdiskussion kein weiteres Problem sein dürfte, da aktuelle Browser über Sockets alle notwendigen Resourcen bieten. Selbst ein einfacher XServer dürfte sich mit Hilfe von Canvas umsetzen lassen.

In der öffentlichen Wahrnehmung hat Apple Google mal eben rechts überholt und das ohne zu blinken. Streetview war gestern, heute ist “consolidated.db”. Diese Datenbank der Positionen des iPhone/iPad existiert offensichtlich schon länger und wurde laut verschiedenen Quellen bereits von Forensikern genutzt. Die breite Öffentlichkeit und damit auch die tagesschau, heise, golem und ich erlangte erst Kenntnis davon als letzte Woche das Programm iPhoneTracker veröffentlicht wurde. (Sonst hätte ich mir damals nicht die Mühe mit dem iPhone moblog gemacht …). Wiedermal ein sehr schönes Beispiel dafür, dass das Verständnis von IT mit dem Userinterface steht und fällt (Hallo SAP?).

Meine Fahrradrouten durch Berlin in optimierter Auflösung von iPhoneTracker.

Ursprünglich klang für mich das ganze sehr stark nach einem typischen “Programmierer braucht für die Entwicklung ein Log und keiner denkt beim Release daran”. Immerhin basierte lange Zeit die ganze Webtracking-Branche auf den Serverlogs, die eigentlich nur zum debuggen gedacht waren.

Inzwischen kristallisiert sich aber raus, dass es sich keineswegs um ein Versehen handelt und die daraus zu ziehenden Schlussfolgerungen sind nicht schön, at least für Apple. Hervorragend zusammengefasst von Frank Rieger. Aber ich hätte mich nicht erst seit den aktuellen Erkenntnissen geweigert, mein Telefon am Empfang der US-Botschaft abzugeben, wie es – laut Max Winde im letzten mobilemacs-Podcast – mspro vor einiger Zeit machen musste.

Unabhängig von der Bewertung und dem extrem negativen Impact für Apple (den die echten Fanboys schäumen lassen) freue ich mich natürlich, dass ich ohne Jailbreak und entsprechende Tools jetzt eine Datenbank meiner Positionen habe.

Aber warum sind die Daten so ungenau und warum werden mir nur ganze Wochen angezeigt? Geht’s auch etwas genauer?

Read the rest of this entry »

Googles Chrome-Browser springt von einer Version zur nächsten und ist inzwischen bei Nummer 9 angelangt. Die Neuerungen halten sich meistens in Grenzen und es ist unklar ob in Googles Entwicklungsabteilung nur einige emacs-Gegner arbeiten, die möglichst schnell an dem Editor vorbeiziehen wollen.

Per Default ausgeschaltet: Google Instant

Mit Google Chrome 9 wurde jetzt eine Funktion eingeführt, die erheblichen Einfluss auf das Verhalten der Nutzer haben könnte. Schaltet man in den Einstellungen “Google Instant” ein wird bereits während der URL-Eingabe die jeweils wahrscheinlichste Seite geladen. Je nach Historie des Surfens wird also bei ‘sp’ entweder spiegel.de oder spreeblick.com geladen.

Mir ist momentan nicht klar, ob eine solche Funktion aus User-Sicht wirklich sinnvoll ist, da ich insgesamt den Eindruck habe, dass viele neue Funktionen zu einer immer kürzer werdenden Aufmerksamkeitsspanne führen.

Auswirkungen hat diese Funktion jedoch auf die Webanalyse und damit auch auf den Betrieb einer Site. Denn in Zukunft werden mehr Seiten aufgerufen und direkt danach wieder verlassen. Die bisher schon sehr schwierig zu beurteilende Bounce Rate wird also steigen. Solange diese Funktion nicht von den anderen Browsern übernommen wird, kann man deren Bounce Rate benutzen, um den Chrome-Faktor zu berechnen. Leichter wird Webanalyse dadurch sicher nicht. Aber es fließen bestimmt noch mehr interessante Daten zu Google.

In Deutschland ist es per Gesetz untersagt, IP-Nummern zu speichern. Daran hält sich jedoch kaum jemand. In meiner Praxis habe ich bisher kaum eine Apache-Konfiguration gesehen, die als Log-File-Format nicht ‘combined‘ oder ‘common‘ verwendet hat. Beide Einstellungen speichern die IP-Adressen der User dauerhaft. Es hat mich jedesmal Überzeugungsarbeit (mit Hinweis auf die Probleme, die mal eine Justizministerin hatte) gekostet, dies zu ändern.

Wenn ein Gesetz und Strafandrohung bei Anbietern nicht dazu führen, dass IP-Nummern nicht gespeichert werden, wie bitte sollte ein http-Header mit der Aussage ‘do not track me’ dazu führen, dass Werbetreibende kein Targeting durchführen.

“Do not Track” soll in Zukunft im http-Header übermitteln, dass der User vor diesem Browser nicht wünscht, analysiert zu werden. Sozusagen eine Tarnkappe mit dem Hinweis “Falls Sie mich doch sehen, ignorieren Sie mich doch bitte!“.

Nun könnte man natürlich vermuten, dass Firmen wie Doubleclick sich in Zukunft hüten werden, Cookies an den Browser zu schicken. Natürlich werden sie das tun. Aber das hindert sie nicht daran, trotzdem profilierte Werbung auszuliefern. In Zukunft wird ein Retailer von seinen Werbenetzwerken einfach verpflichtet (respektive Preisnachlässe erhalten), Cookies verschiedener Partner durchzureichen. Dieses Durchreichen geschieht schon heute. Denn die Anbieter sind schon heute nicht unabhängig. Netzwerk X arbeitet bezüglich Branche Y mit Netzwerk Z zusammen.

Wenn ein User dann bei Shop A (wg. der Funktionen des Shops, zwinker, zwinker …) gezwungen wird, Cookies zu akzeptieren, werden diese an das Netzwerk durchgereicht. Wenn es nicht anders geht mit Hilfe von Mengenabfragen à la History-Hijacking.

Aber selbst dieses recht komplizierte Szenario muss eigentlich nicht bemüht werden. Denn mit dem Browser-Fingerprint gibt es eine funktionierende Methode der Wiedererkennung eines Systems an Hand von Browser- und Systemumgebung, ohne eine ID auf dem/vom Rechner des Users zu speichern/abzufragen.

Schlussendlich gibt es aber niemanden (am wenigsten einen Richter), der in der Lage wäre, zu unterscheiden, ob die technischen Umgebungsvariablen so sind wie sie sind, weil jemand wollte, dass sie so sind wie sie sind oder weil eine Standardkonfiguration meinte, dass es eine gute Idee wäre, dass sie so seien, wie sie sind.

Und – ganz ehrlich – glaubt irgendwer im Raum, dass facebook seine Like-It-Funktion disabled, wenn ein User die DNT-Funktion eingeschaltet hat? Mit jedem Recht kann facebook behaupten, dass diese Funktion nicht dem Tracking dient sondern der Kommunikation. Wenn diese Argumentation funktioniert, werden in Zukunft auch lauter Googles, Zanoxes und andere eine Community aufbauen. Haben sie schon versucht? In Zukunft werden sie wissen, warum es sich lohnt, selbst wenn sie NULL User haben …