ScriptBlogger

Ständig dieser Hype um ReCaptcha. Oder zumindest positive Berichte darüber. Spiegel Online schreibt etwas von Schwarmintelligenz und lobt die Kostenlosigkeit. Dabei hat die Sache weniger mit Intelligenz, sondern eher etwas mit Arbeitskraft für lau zu tun.

ReCaptcha wurde an der Carnegie Mellon University in Pittsburgh, Pennsylvania, USA, entwickelt und soll beim Übersetzen von Büchern helfen. Website-Betreiber können ReCaptcha in ihr Forum/Weblog/Formular einbauen und so vor Spam schützen. In dieser Hinsicht funktioniert ReCaptcha wie ein ganz normales Captcha.

Zusätzlich wird jedoch noch ein zweites Wort angezeigt, das es zu erkennen gilt. Es stammt aus einem gescannten Buch und konnte von der Texterkennungs-Software nicht erkannt werden.

Problem Nummer 1: Das ansich schon nervige Captcha wird verkompliziert und benötigt mehr Zeit zum Lösen. Okay, man kann sich das zweite Wort sparen und kommt trotzdem durch. Wenn denn nur immer klar sein würde, welches das richtige Wort ist. Der Strich quer durchs Wort ist meistens eine Hilfe. Meistens.

Problem Nummer 2: ReCaptcha funktioniert nur mit JavaScript im Browser aktiviert. Was aber andererseits fast wieder egal ist, denn das halbe Internet funktioniert nur mit JavaScript aktiviert.

Einziger Lichtblick ist, dass ReCaptcha sich auch auf Ton umschalten lässt und so keine Barriere für Menschen mit eingeschränkter Sicht darstellt. Theoretisch zumindest, denn die Tonqualität steht der Bildqualität in nichts nach. 

Und schließlich wirft sich die Frage auf, wem das Ganze nützt, außer der Carnegie Mellon University. Wenn denn wenigstens eine deutsche Uni etwas in dieser Art anbieten würde. Es ist kaum anzunehmen, dass es hierzulande nichts zu digitalisieren gäbe. Aber das wird warscheinlich erst passieren, wenn Captcha Schnee von gestern ist und Spam entweder der Vergangenheit angehört oder auf andere Weise bekämpft wird.

Nachtrag:

ReCaptcha ist prinzipiell keine schlechte Idee, nur nervt der undifferenzierte Hype darum. Außerdem noch eine Korrektur zum Thema JavaScript. Wie zum Beispiel Twitter und die Website von ReCaptcha beweisen, kann man ReCaptcha so einbinden, dass es auch ohne eingeschaltetes JavaScript funktioniert. Das allerdings macht die Angelegenheit noch um einen Schritt komplizierter, da man nun nach erfolgreicher Lösung des ReCaptchas noch einen zufallsgenerierten Code in ein anderes Textfeld eingeben muss.

Damit Weblog Expert Google Chrome in seine Auswertung einbezieht, muss folgende Zeile in die Config/Browsers.cfg eingefügt werden. Neustart von Weblog Expert nicht vergessen. Andernfalls haben die Änderungen keinen Effekt.

Chrome = Google Chrome

Wichtig dabei ist, dass der Eintrag oberhalb des Eintrags für Safari erscheint.

Chrome = Google Chrome
Safari = Safari

Sieht dann in der Auswertung so aus.

Vor einiger Zeit meldete sich ein Kunde bei uns. Das von ihm erworbenen Wegwerf-E-Mail-Script funktionierte nicht. Wie sich herausstellte lag das Problem beim US-Webhoster GoDaddy, der Scripten keine Verbindung zu externen E-Mail-Accounts erlaubt. Unser Vorschlag, den Webhoster zu wechseln, kam nicht so gut an und der Kunde wollte sein Geld wiederhaben. Das war am 2. Februar.

Am 4. Februar haben wir ihm den Kaufpreis erstattet. Zum Dank hat er das Script in einem Raubkopiererforum zum allgemeinen Herunterladen freigegeben. Ist doch klar, dass wir uns dafür artig bei ihm bedankt haben.

Thanks for posting our Temporary E-mail script in a warez forum despite the fact that we spend hours trying to get the script running on your server and refunded your money on February 4. It's really great that we can trust our customers and that our effort is rewarded. 

Und wir haben sogar eine Antwort erhalten:

i posted it because i didn`t got my refund and it passed like 2 weeks and didn`t heard nothing from you ... i posted on the forum and nothing .. not an answer! 

Zwei Wochen? Der Thread im Forum sagt etwas anderes. Nach der letzten Forumsnachricht ging es übrigens per E-Mail weiter.

Seitdem fragen wir bei Support-Anfragen zum Wegwerf-E-Mail-Script stichprobenartig nach den Zahlungsinformationen. Die eine oder andere Anfrage hatte sich danach erledigt.

Vor ein paar Tagen haben wir von "stichprobenartig" auf "durchgehend" umgestellt. Wer von nun an Support erhalten möchte, muss bei der Registrierung im Forum die Zahlungs-ID/ Rechnungsnummer angeben. Allerdings gilt das nur für Scripte, die erst nach dem Kauf erhältich sind, wie Link Manager, Wegwerf-E-Mail, Schort URL und News Script.

Gerade eben wollte ich auf einer Website ein Formular absenden und sah mich mit folgender Frage konfrontiert:

What color is the sky.

Kurzer Blick aus dem Fenster und folgendes eingetippt:

grey

Das Formular hat mir nicht geglaubt und das Absenden verweigert. ;-)

Schocken kann uns gar nichts mehr, nicht mal folgende an Dreistigkeit kaum zu überbietetende Nachricht in einem Diskussionsforum irgendwo im Netz.

Die Links "USER DEMOS CLICK HERE" und "Admin Demo CLICK HERE" führen auf unsere eigene Demoseite. Die haben wir dann gleich mal entsprechend geändert und nun ist deutlicher gekennzeichnet, wo man das richtige Script kaufen kann. Außerdem haben wir als Antwort auf die Forumsnachricht unsere Web-Adresse gepostet. Mal sehen ob's was bringt. ;-)

Und noch ein Hinweis: Wir vergeben keine Master Resell Rights (MRR) und schon gar keine, die dermaßen günstiger als unsere eigenen Preise sind. B-)

Genaugenommen ist es keine unendliche Geschichte, sondern eher eine ziemlich langwierige.

Am Anfang ging's noch recht flink. Am 31. Mai traf die Anfrage zum Schedule Organizer ein und am 2. Juni die Bestellung für den Installationsservice. Fragebogen zusenden, Script hochladen, Layout anpassen, Änderungswünschen nachkommen - normalerweise ist das recht zügig erledigt. Und selbst wenn es nicht ganz so zügig geht weil es Unklarheiten gibt, ist das mitnichten ein Problem. Die paar extra E-Mails sind schnell geschrieben und nicht jeder Kunde ist vertraut mit den Dingen die das Webhosting so mit sich bringt. Unsere einzige Sorge ist, dass der Kunde irgendwann die Geduld verliert.

3. Juni - Leider fehlten im ausgefüllten Fragebogen die Zugangsdaten für FTP und MySQL, so dass da noch einmal nachgehakt werden musste.

4. Juni - Die FTP-Daten waren nun da, funktionierten aber nicht.

9. Juni - Bei der Rückfrage hatte ich mich missverständlich ausgedrückt und nach den korrekten Daten für den FTP-Server gefragt. Darauf die Antwort: "We do not have a ftp server."

10. Juni - Ich gab mir nochmal Mühe mit der Erklärung und erfuhr, dass der Kunde sich immer per Microsoft Frontpage einloggt. Der Kunde wollte mir dann die dafür verwendeten Zugangsdaten geben.

11. Juni - Die FTP-Zugangsdaten sind da.

Irgendwie war die Sache hier untergegangen, so dass sechs Tage bis zur nächsten Aktion vergingen.

17. Juni - Ich fand heraus, dass der FTP-Login auf ein anderes Verzeichnis auf dem Server zeigte, als die URL. Nach ungefähr zehn E-Mails war das Problem verstanden und gelöst.

19. Juni - Alles funktionierte soweit, so dass ich die Script-Dateien zum Server hochladen konnte. Der Aufruf der Installationsroutine zeigte allerdings: Es lief kein PHP auf dem Server.

23. Juni - PHP funktionierte jetzt, allerdings fehlte nun die MySQL-Extension.

24. Juni - Der Kunde hatte MySQL per php.ini aktiviert. Es kam leider immer noch diese Fehlermeldung: PHP Fatal error: Call to undefined function mysql_connect()

2. Juli - Jetzt wird's interessant. Der Kunde fragte:"Where do you need mysql installed on the server?" Da ich kein Windows System-Administrator bin und auch deren Infrastruktur nicht kenne, konnte ich nicht helfen.

7. Juli - Der Kunde meldet sich mit: "I've installed MySQL essentials build 5.0.51b on the web server." Leider hat das auch nichts gebracht. Die MySQL-Extension ist immer noch nicht verfügbar.

9. Juli - "I reinstalled PHP this time, and now I can see the MySQL extension when I load the phpinfo.php page." PHP hat jetzt tatsächlich Zugriff auf die MySQL-Extension. Leider stimmen die vom Kunden übermittelten MySQL-Zugangsdaten nicht. Access denied etc.

9. Juli - Die neuen MySQ-Zugangsdaten sind da - und sie funktionieren sogar. Das Script ist jetzt endlich installiert und funktioniert weitestgehend. Weitestgehend heißt in diesem Fall, dass das Script auf einem Windows-Server läuft und erwartungsgemäß kein Mailer installiert ist. Kein Problem, für diese Zwecke hat das Script eine SMTP-Funktion. Brauche ich vom Kunden nur noch die Daten für ein E-Mail-Konto. Ein Test mit einem unserer E-Mail-Konto verlief negativ (Timeout mit Fehlermeldung). Das lässt darauf schließen, dass externe E-Mail-Konten nicht genutzt werden können.

11. Juli - Weitere Details nachgefragt

26. August - Bisher keine Antwort erhalten und mal nachgehakt

26. August - "I am not sure if i want to continue with the installation. If is starting to become a problem with our server."

27. August - Script wieder vom Server gelöscht, Bestellung storniert und Geld zurückerstattet. :-[]

Ein Kunde aus Sydney (Australien) hatte kürzlich Probleme mit seinem Schedule Organizer. Angeblich waren alle bislang reservierten Termine auf einmal verloren gegangen. Vorfälle dieser Art hatten wir bereits dreimal zuvor, aber bislang konnten wir nicht viel dagegen ausrichten. Glücklicherweise handelte es sich jedesmal um ein einmaliges Ereignis und die Kunden konnten damit leben.

Nichtsdestotrotz wurde es Zeit, die Ursache des Problems zu finden und zu eliminieren. Das Gemeine an der Sache war, dass sie nicht durch falsche Einstellungen in der Konfiguration des Scripts hervorgerufen werden konnte. Andernfalls wäre es einfach gewesen, diese abzufangen. Also musste die Schuld irgendwo beim Server liegen.

Nach einigem Testen und Anzeigen aller möglichen Umgebungsvariablen probierten wir es mal mit date_default_timezone_get().

Ergebnis: America/Chicago. Was zum Henker?

Nun ist eine falsche Zeitzone kein Problem, solange sich nichts ändert. Aber genau das ist wohl geschehen, denn eine Änderung der Zeitzoneneinstellung verursacht exakt das oben beschriebene Verhalten. Die Lösung ist date_default_timezone_set(). Danach kann der Provider die Server-Einstellungen ändern wie er möchte, ohne das Script zu beeinflussen. Seit PHP 5.1.0 wird im E_STRICT-Modus sogar davor gewarnt, den Zeitzoneneinstellungen des Servers zu vertrauen. Offensichtlich sind den PHP-Entwicklern die Probleme bekannt.

Aus den reservierten Terminen ließ sich übrigens erkennen, dass sich die Zeitzone des Servers um fünf Stunden verschoben hatte. Chicago und Sydney liegen allerdings acht Stunden auseinander. Die Zeitzoneneinstellungen müssen also schon vorher falsch gewesen sein.

Gerade kam 'ne E-Mail von Tausendreporter .

[...] ein Administrator von Tausendreporter hat den Status Ihres Beitrags 
aus folgendem Grund geändert: spam

Gemeint war der Beitrag rel="nofollow" gehört verboten. Was an diesem Beitrag Spam sein soll, weiß wohl nur der Admin bei Tausendreporter. Absender der E-Mail war übrigens webmaster@pligg.com.

Tipp 1 an Tausendreporter: Beiträge (genau) lesen.

Tipp 2 an Tausendreporter: Pligg vernünftig konfigurieren.

Das freut doch zu lesen.

Sehr geehrte Damen und Herren,

wir haben letzte Woche eine Form-Mail Lizenz erworben und sind vom Script sehr begeistert. [...]

:-)

Kein Spammer schert sich darum, ob Links das Attribut rel="nofollow" besitzen oder nicht. Spammer scheren sich nicht mal darum, ob ein Formular überhaupt Felder für Links enthält oder ob ein Link auch tatsächlich auf der Seite erscheint. Formulare jeglicher Art werden wahllos mit Spam zugeschüttet. Das von Google erfundene Attribut ist völlig nutzlos.

Und wen triffts am Ende wieder mal? Den normalen Anwender. Man zwingt ihm JavaScript auf, um Kommentare schreiben zu können. Man stellt ihm unlesbare Captcha-Bilder in den Weg. Man gibt ihm Rechenaufgaben auf. Man sagt ihm, dass er bestimmte Felder ausfüllen muss, andere Felder aber auf keinen Fall ausfüllen darf. Und am Ende belohnt man ihn noch nicht einmal mit einen vernünftigen Link. 

Es wird Zeit, dass dieser Link-Geiz ein Ende hat. 

Subversion ist nicht nur generell ganz hilfreich, es macht sich auch besonders gut, wenn man in einem Branch eine neue Funktion einbauen möchte und später Branch und Trunk wieder zusammenfügen möchte.

Wir nutzen hier Tortoise SVN, welches das Arbeiten mit Subversion zum Kinderspiel macht. Was das Zusammenfügen zweier verschiedener Entwicklungsbäume angeht, ist die Doku allerdings nicht hundertprozentig klar.

In both the From Revision field and the To Revision field, enter the last revision number at which the two trees were synchronized. 

Oder mit anderen Worten, man fügt Branch und Trunk an der Stelle (Revisionsnummer) wieder zusammen, an der man Branch und Trunk ursprünglich getrennt hat.

Ist ja auch logisch. Subversion wird erst die Änderungen aus dem Branch in den seinerzeit unveränderten Trunk übertragen und dann die am Trunk gemachten Änderungen sukzessive nachholen. Im Buch "Version Control with Subversion" ist das Vorgehen übrigens besser erklärt.

Der Scriptblogger arbeitet so selten per Kommandozeile auf dem Server, dass er jedes mal die Kommandos für crontab und vi nachsehen muss. Damit er sich für die Zukunft das Suchen spart, sind hier die wichtigsten Kommandos aufgeführt:

Von Zeit zu Zeit tauchen in Weblogs oder Foren Listen mit Wegwerf-E-Mail-Diensten auf. Von diesen Dingern kann man übrigens nicht genug Auswahl haben, denn die Domains werden öfters mal von Website-Betreibern blockiert.

Viele Dienste dieser Art haben eine äußerst geringe Halbwertzeit, wie oben verlinkte Liste beweist. Ein guter Teil der Seiten ist nicht mehr erreichbar oder zeigt völlig andere Inhalte.

Und jetzt wird's interessant. Auf der Liste befinden sich mehrere Websites, die unser Wegwerf-E-Mail-Script einsetzen, und das gilt es zu zelebrieren. Wer zuerst die korrekte Anzahl dieser Websites in den Kommentaren hier unter dem Artikel schreibt, erhält eine Script-Lizenz kostenlos. Wichtig: E-Mail-Adresse zur Kontaktaufnahme nicht vergessen.

Nachtrag: Gewinnspiel beendet - Gewinner benachrichtigt

Aus dem Support:

Danke für Ihre Mühe und vor allem sensationell schnellen Reaktion, Wahnsinn!

B-)

Meistens hören wir von unseren Kunden und Nutzern nur, wenn Sie Probleme mit ihrem Script haben. Deshalb ist uns in den meisten Fällen auch gar nicht bekannt, ob das Script überhaupt noch in Benutzung ist.

Letztens kam mal wieder eine Bestellung aus Sleepy Hollow. Im darauf folgenden E-Mail-Verkehr trudelte dann dies hier ein:

A former coworker of mine got the schedule organizer for another building in my district in 2005. They are still using it today.

:-)