ScriptBlogger

Ein Kunde schrieb:

Ralf you rock! Wish I could buy you a drink!

Wenn ich mal wieder in Minnesota, USA, bin bestimmt. :-)

Scripte auf Windows-Servern (IIS und so) zu installieren ist immer eine Freude. Meistens ist kein MTA (Mail Transfer Agent) installiert, so auch im folgenden Fall. Der Kunde wollte sich drum kümmern und meldete sich wie folgt:

I put a simple SMTP service on to the server itself as a localhost. Can you put that in place?

Kein Problem. Änderungen vorgenommen und ausprobiert. Als Fehlermeldung spuckte mail() dann allerdings dies hier aus:

PHP Warning: mail() [function.mail]: SMTP server response: 555 This freeware lets you send not more than 10 messages a day

Der Kunde meinte dann

Ok. I'll fix that.

und schob dann später nach

BTW, This is getting embarrassing now.

:-)

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.

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.

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. [...]

:-)

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.

:-)

API-Keys (oder auch API-Hashes) gibt es allerorten. Man benötigt zum Beispiel einen, um Google Maps in seine Website einzubinden. Für Akismet braucht man ebenfalls einen. Die Liste ließe sich beliebig fortsetzen. Die Betonung liegt hier übrigens auf einem Api-Key. Kürzlich hatten wir es jedoch gleich mit drei API-Keys für dieselbe Anwendung zu tun. 

Ein Kunde von uns tauscht regelmäßig und automatisch per E-Mail Informationen mit seinen Geschäftspartnern aus. Die Zahl der teilnehmenden Partner ist dabei so groß, dass eine Standardisierung des E-Mail-Formats nicht möglich ist. Das ist auch kein Problem, denn die Systeme passen sich dann eben den E-Mails an. Das ist technisch keine große Hürde und funktioniert schon seit Jahren zuverlässig.

Ein neuer Geschäftspartner übermittelte kürzlich zusammen mit der eigentlichen E-Mail-Formatvorlage auch gleich noch drei API-Keys. Der erste war Teil der Ziel-E-Mail-Adresse. Der zweite war dem Geschäftspartner zugeordnet. Und der Dritte gehörte zu unserem Kunden. Alle drei Keys waren Bestandteil der E-Mail. :-o

Nun ja, die werden schon Ihre Gründe dafür haben, aber technisch sollte eigentlich auch ein einziger API-Key ausreichen. Alles andere schafft nur Verwirrung und erhöht die Fehleranfälligkeit. Weniger ist also mehr oder um es mit J.R.R. Tolkien zu sagen: One key to rule them all. :-)

Ein Kunde von uns betreibt eine Geschäftsplattform, die zwar einen halben Tag Auszeit verkraften kann, danach wird es aber kritisch. Um für den Fall der Fälle gewappnet zu sein, wird stündlich eine Sicherheitskopie der Datenbank erstellt. Zudem gibt es von der Anwendung generierte Dateien, die einmal wöchentlich gesichert werden.

Die Datenbank ist knapp ein Gigabyte groß; das ergibt eine rund 130 Megabyte große Zip-Datei. Bei den Dateien kommen wir insgesamt auf über 12.000 Stück - gepackt sind das 180 Megabyte. Die Backups werden dann regelmäßig per FTP auf einen Backup-Server übertragen.

Wir sind vor kurzem den Prozess der Wiederbelebung mal durchgegangen. Zuerst wurde die aktuelle Version der Anwendung auf den für den Ernstfall bereitstehenden Server übertragen. Rund 600 Dateien. Dann die Datenbank eingerichtet und das Datenbank-Backup eingespielt. Als nächstes wurden die von der Anwendung erstellten Dateien in das entsprechende Verzeichnis entpackt.

Das Ganze hat keine Stunde gedauert. Nun kann eigentlich gar nichts mehr passieren. B-)

Nicht nur Anwender schreiben merkwürdige Dinge. Hier eine Antwort auf eine Support-Anfrage zum Schedule Organizer (vorletzter Satz):

When switching between appointment areas the value of the current week is being passed on. This won't work well if area B has a $future_last of 10 weeks but area A has only 3. The user will arrive in week 10 of area A only to realize that there is no week 10 in area A. Kind of a twilight zone.

Aus einer E-Mail:

I just want to thank you so much for creating an affordable and easy way to implement such useful scripts. A few months ago I stumbled onto this site (gentlesource.com) and found exactly what I was looking for in the comment script. However, I had absolutely no idea what I was doing as I was very new to php. You responded so quickly to me via email and even advised me to try before I buy. Well, it took me a very short time to figure out how to use the script and now I have a comment section to go along with every single video on my site! Thank you again for everything! I honestly couldn't be happier!

Christine - http://www.wetranslated.com/

Unsere Kunden kommen aus aller Herren Länder. Statistik gefällig? Die Daten stammen aus den Jahren 2003 bis 2008. Die Werte sind gerundet

Nach einer gewissen Zeit im Geschäft überraschen einen immer weniger Dinge. Für etwas Abwechslung in dieser Routine sorgte vor einigen Monaten ein neuer Kunde, dessen Projekt mit über 100 Datenbanktabellen daher kam.

Von Konfigurationstabellen mit weniger als zehn Datensätzen bis hin zu Log-Tabellen mit Millionen von Datensätzen war alles dabei.  Auf einem unserer Rechner (2 Ghz, 2 GB RAM) brauchte phpMyAdmin rund 15 Sekunden, um die Tabellenübersicht zu laden. :-o

Zugegeben, ich bin an der folgenden Geschichte nicht ganz unschuldig. Manch einer mag das sogar für eine Untertreibung halten. ;-)

Am 1. Dezember kam eine Bestellung für das Form Mail Script (19 EUR) per PayPal herein, die auch sofort von mir ausgeliefert wurde. Damit war die Sache eigentlich für mich erledigt.