Sucht man bei bing oder Google bekommt man nur Müll. Müll im Sinne von unrelevanten und teils gar falschen Treffen zum Thema JavaScript. Bing stellt sich in dieser Hinsicht besser an und verweist zumindest auf die Wikipedia, während die Ergebnisse von Google komplett unbrauchbar sind.
Deswegen haben sich im Zuge der Entwicklerkonferenz JSConf die sogenannten pirates of JSConf unter Chris Williams zusammengeschlossen und wollen mit dem Projekt Promote JS eine gemeinsame Google Bombe lostreten.
Als JavaScript-Entwickler betrachte ich es als gute Sache und schließe mich dem Projekt an, denn es kann nicht sein, dass wichtige Informationen zu JavaScript hinter unrelevenaten oder gar falschen Themen, wie beispielsweise Java selbst, aufgelistet werden und somit den Weg zur Dokumentation erschweren.
Damit reihe ich mich in die namhaften Referenzen ein, die diese Projekt unterstützen, wie:
Reihe dich auch ein, mit drei Schritten bist Du dabei:
- Geh auf http://promotejs.com/
- Kopiere den für dich erzeugten Quellcode
- Füge den Code in deine Website ein
Damit reinigen wir die Suchergebnisse der großen Suchanbieter und ermöglichen es neuen JavaScript-Entwicklern und -Interessierten einfach an die Dokumentation zu kommen.
Hoffentlich fliegt das JavaScript MDC nicht komplett aus dem Index, sondern wird nur gut gerankt.
Warten wir ab, wie sich diese SEO-Kampagne auswirkt 
Der Tweet vom bösen SEO Fehler auf Financial Times Deutschland erlaubt das Lesen von kostenpflichtigen Artikeln mit dem Verweis auf den Artikel Fehler auf Financial Times Deutschland von Sebastian Klipper hat mich dazu inspiriert einen FTD Free Paid Content Redirect zu schreiben:
FTD Free Content Redirect:
<?php
$url = str_ireplace('www', 'm', $_GET['s']);
header("Location: $url?mode=simple");
?>
Die Quintessenz des Skripts ist oben dargestellt, in meinem Code ist etwas mehr (Sicherheit + Styling) drin, wird aber nicht benötigt.
Über diesen Link könnt ihr also Artikel kostenfrei aufrufen, indem ihr einfach die originale Artikel-URL einfügt und danach weitergeleitet werdet.
Dies ist ein wunderschönes Beispiel, warum clientseitige Redirects bzw. Sicherheitschecks nicht funktionieren.
Auf der User-Seite kann man eben alles modifizieren, schließlich ist es mein Rechner der den Inhalt kontrolliert.
Also liebe Admins von FTD, lest diesen Beitrag und passt daraufhin eure Umleitung anhand der Browser-Identifikation an.
Liebe Leser: sollte die Umleitung von FTD serverseitig gelöst werden, dann stellt einfach euren User-Agent um und kommt trotzdem an der wertvollen Inhalt
Also liebe Admins: solltet ihr zuviele kostenfreie Zugriffe erhalten, baut einen Login/Cookie vor euren Paid Content und zwingt somit alle Leser zum Kauf eurer Inhalte.
UPDATE: Der ursprüngliche Fund stammt von Marko Rogge.
Wer sich auch gerne in das Thema Multitouch auf Apple-Geräten einlesen möchte, dem seien folgende Links empfohlen:
In den obigen 4 Artikel (bzw. 6 Links) wird ausführlich, mit Codebeispielen, erklärt, wie man für das iPhone von Apple oder dem neuen Apple iPad Events erzeugt um Aktionen mehrerer Finger, dem so genannten Multitouch, entwickelt.
Dabei handelt es sich nicht um die üblichen Dreh- und Zoombewegungen, denn das sind eigentich nur Gesten und in der Entwicklung nicht unbedingt als Multitouch anzusehen. Multi kann mehr als 2, 3 oder 10 Finger sein.
Die ersten zwei Videos von Douglas Crockford über Javascript sind raus:
The Early Years
And Then There Was JavaScript
Drei weitere kommen nocht.
Heute habe ich kurz darüber nachgedacht, wie man in JavaScript eine serverseitige Push-Funktion implementieren kann.
Eine Möglichkeit wäre es, den Status ständig abzurufen, wie zum Beispiel mit folgendem Code:
function checkServer() {
new Ajax.Updater('server.php', {
method: 'get',
onSuccess: function(transport) {
if (parseInt(transport.responseText)) checkServer();
else doStuff(transport.responseText);
}
});
}
Die prototype-Library als Framework vorausgesetzt.
Dabei wird im obigen Quelltext solange das serverseitige Skript aufgerufen, bis es denn eine Lösung gibt, als Anwendungsfall kann man sich eine langwierige Datenbankoperation vorstellen, die sonst nichts, nicht mal ein HTML-Template, zurückgibt.
Denn wenn etwas kommt, ist der Prozess zu Ende.
Ein anderer Ansatz ist, vorausgesetzt man kann eine Session lange offen halten, dass man den Status der Übertragung überprüft und eben darauf reagiert.
Dies ist auf jeden Fall die elegantere Lösung die weniger Queries verursacht, aber wegen der langen Sessions etwas unsicherer, bei zum Beispiel schlechten Internetzugängen oder DSL Timeouts, ist, aber schöner funktioniert:
var xmlHTTP = new ActiveXObject("Microsoft.XMLHTTP");
xmlHTTP.onreadystatechange = handleStateChange;
function handleStateChange() {
if (xmlHTTP.readyState == 3) {
alert(xmlHTTP.responseText);
}
}
xmlHTTP.open("POST", "/server.php", true);
xmlHTTP.send();
Oder fällt jemanden auf Anhieb eine bessere Möglichkeit ein, wenn man auf der Seite des Client nur einen Webbrowser mit JavaScript zur Verfügung hat?
Besserung ist wohl nicht zu erwarten, denn wie hier bei heise steht, wird am XMLHttpRequest nichts mehr verändert. Super.
Soeben konnte ich im Yuiblog erfreulicherweise diesen Veranstaltungshinweis lesen:
Crockford on JavaScript
Dabei spricht Douglas Crockford über die JavaScript-Architektur und vieles mehr.
Ich hoffe nur, dass die Vorträge als Mitschnitte verfügbar gemacht werden und ähnlich wie diese Videos veröffentlicht werden.
Zusammengefasst: Man kann Douglas Crockford in Sachen JavaScript unbedingt empfehlen, vor allem sein Buch “JavaScript – The Good Parts” kann sehr erleuchtend sein!
