ScriptBlogger

Es gibt englische Wörter, für die gibt es einfach keine sinnvolle deutsche Entsprechung. Wie "Link" zum Beispiel Man könnte Verknüpfung oder Verweis schreiben, aber Link ist weniger sperrig und versteht auch jeder.

Allerdings sollte man es sich nicht zu einfach machen und eventuell doch mal ein Wörterbuch bemühen. Dann ist es gar nicht so schwierig, eine Anwendung oder Website komplett in deutsch zu beschriften. Linklift zum Beispiel macht das ziemlich gut und bedient sich durchweg deutscher Wörter bis hin zu Skript (mit k statt mit c).

Leider erlaubt sich Linklift dann aber doch einen stattlichen Aussetzer.

Bevor ein Werbe-Link auf der eigenen Website erscheint, muss dieser vom Betreiber freigeschaltet werden. Statt aber prüfen, bestätigen, akzeptieren, annehmen oder freischalten zu schreiben, heißt es in der URL, der Überschrift und auch in einer Link-Grafik: Anzeige approven.

Liest sich merkwürdig und klingt komisch. Sagt auch sonst kein Mensch. Witzigerweise steht in der Benachrichtigungs-E-Mail dann wiederum folgendes:

Sie haben nun die Möglichkeit, die Anfrage unter https://www.linklift.de/anzeigen-approven/ innerhalb von einem Werktag zu prüfen und entweder zu bestätigen oder abzulehnen.

Geht doch, wenn man nur will. ;-)

Ein Kunde unseres News Scripts schrieb, dass beim Aufruf des Scripts im Browser nichts angezeigt würde.

Eine kurze Recherche zeigte dann auch etwas ungewöhnliches. Normalerweise erstellt die Smarty-Template-Engine die vorkompilierten Scripte mit Dateinamen wie diesem:

%%83^83B^83B7EFCA%%layout.tpl.html.php

Beim Kunden sahen die aber so aus:

wrt490a1737906fe

Kein Wunder also, dass nichts ausgegeben wird, wenn die Template-Dateien nicht gefunden werden. Haben wir dem Kunden auch ausführlich so erklärt und empfohlen, sich an den Webspace-Provider zu wenden.

Darauf kam dann folgendes:

Do you have any idea's on where the problem is coming from?

Hm. Wir dachten eigentlich, es wäre offensichtlich, dass der Server da seine Finger zwischen hat. Hätten wir vielleicht explizit in der E-Mail erwähnen sollen.

Aber der Kunde war uns trotz allem wohlgesonnen, ...

I really feel your product is the best fit for us and I would like to get it to work.

... und konnte dann das Problem sogar selbst lösen:

I reset the permissions on the entire "events" folder to Read/Write & Execute. I also changed the permissions on the cache to Full Control. Since I am working off of an IIS server I checked to apply permissions to all child objects for both the cache folder and the "events" folder.

IIS. Das erklärt natürlich einiges. ;-)

Am Anfang der Woche haben wir eine neue Version des Schedule Organizer veröffentlicht. Das Update enthält eine Menge neuer Funktion, die von den Anwendern schon lange gewünscht wurden.

So ist es nun möglich, standardmäßig alle Termine zu blockieren und nur ausgesuchte Zeiten manuell freizugeben. Und falls diese Freigaben allzu spärlich ausfallen, gibt es einen Button, der den Anwender zum jeweils nächsten offenen Termin führt.

Das Script kann nun mit Zeitzonen umgehen. Die Anwender legen bei ihrer Registrierung ihre Zeitzone fest (kann später noch geändert werden) und das Script zeigt dann alle Uhrzeiten entsprechend den Zeitzoneneinstellungen an. Sehr hilfreich ist diese Funktion für Unternehmen, die Europa- oder Weltweit agieren. Die Funktion verlangt allerdings nach PHP 5.

Die Registrierungsfunktion ist nun vollwertig inklusive Aktivierung des Benutzerkontos. Außerdem lässt sich einstellen, ob Administrator, Operator, Nutzer oder alle bei Registrierung eine Benachrichtigungs-E-Mail bekommen.

Optional kann der Admin jetzt Links zum Script generieren, um den Anwender direkt zu einer bestimmten Woche, einem ausgewählten Reservierungsgrund, Terminbereich oder direkt zum Formular zu leiten. Diese Links können dann auf der Website oder in E-Mails platziert werden.

Im Admin-Bereich kann eine Termin-ID angezeigt werden (inklusive Suchfeld in der Terminliste).

Wenn ein Termin mehrmals reservierbar ist, wird nun farblich gekennzeichnet, wenn bereits Termine gebucht wurden. Dadurch sieht der Anwender, ob für eine bestimmte Uhrzeit bereits Termine gebucht wurden.

Das Script besitzt jetzt eine erneuerte Update-Routine. Die erkennt automatisch, ob der Betreiber die Script-Dateien aktualisiert hat und zeigt ein Update-Formular an. Nachdem der Betreiber die MySQL-Zugangsdaten eingegeben hat, aktualisiert das Script die Datenbanktabellen. Sobald das geschehen ist, hat der Admin wieder Zugang zum Admin-Bereich.

Die neue Version verfügt auch über einen Wartungsmodus, der im Admin-Bereich eingeschaltet werden kann. Dabei wird die Benutzeroberfläche abgeschaltet, damit der Admin eine neue Version des Scripts zum Server hochgeladen und installieren oder andere Einstellungen vornehmen kann, ohne dass es auf Anwenderseite zu Komplikationen oder Fehlermeldungen kommt.

Administratoren können jetzt entscheiden, ob Sie Termine löschen oder lediglich absagen. Im letzteren Fall bleiben die Termine erhalten und erschienen durchgestrichen in der Terminliste. Bisher war nur jeweils eine der beiden Optionen möglich.

In der Vergangenheit kam es ab und zu mal vor, dass ein Admin sich selbst ausgesperrt hat. Deshalb wird vor dem Löschen eines Benutzers mit Admin-Rechten deutlicher als bisher gewarnt.

Das Benutzeroberfläche gibt jetzt valides XHTML aus.

Das Script ist jetzt wieder abwärtskompatibel zu PHP 4 und wird es auch zukünftig bleiben. Einige optionale Funktionen wie Zeitzonen funktionieren dann allerdings nicht.

Und zu guter Letzt eine etwas exotische Funktion. Administratoren können Dateien hochladen und diese einem Benutzer oder Termin zuordnen. Denkbar wäre der Einsatz, um Patienten auf diesem Wege das Ergebnis von Tests oder Untersuchungen zukommen zu lassen.

Weiterführende Informationen  zum Schedule Organizer.

Eine Anwendung funktioniert nicht so wie sie soll. Und an wem liegt das? Eine begehrte These lautet wie folgt:

Der Fehler sitzt meistens vor dem Computer

Gegenthese:

Wenn der Anwender Probleme mit einem Programm hat, waren die Entwickler nicht in der Lage, das Programm entsprechend benutzerfreundlich zu gestalten.

Ein frustrierter Support-Mitarbeiter dürfte ähnlich der ersten These argumentieren. Und für den Programmierer ist es ebenfalls eine recht komfortable Sichtweise.

Entwickler einer Software sollten jedoch jeden Handgriff des Benutzers antizipieren. Für viele Programmierer sind jedoch Dinge wie Usability und intuitiv bedienbare Software nur Buzzwords. Bedienoberflächen, Hilfetexte und Anleitungen müssen jedoch so gestaltet sein, dass sie jeder (wirklich jeder) versteht.

Bei keinem unserer Scripte gab es je einen Fall, bei dem sich der Anwender zu dumm angestellt hätte. Das Problem ließ sich immer auf eine unlogische Benutzerführung, oder eine unklare Anleitung zurückführen.

Wenn man konsequent jede Rückmeldung eines Nutzers in die Verbesserung der Software einfließen lässt, steht am Ende eine Anwendung, die für jeden bedienbar ist und keine Fragen offen lässt. Die Anwender sind zufrieden und es gibt weniger frustrierte Support-Leute. Nicht zu vergessen die finanziellen Vorteile für das Unternehmen.

Ein Thema, dass bereits jetzt schon einen Teil der Support-Anfragen ausmacht und sicherlich in Zukunft eine Rolle spielen wird, ist die UTF-8-Kodierung von Text in PHP-Scripten. Probleme treten immer dann auf, wenn zum Beispiel die UTF-8-kodierten Sprachdateien von Scripten, vom Anwender geöffnet und bearbeitet werden. Nach dem Speichern der Datei befindet sich plötzlich folgendes Zeichen am Anfang der Datei:

   

Das Teil nennt sich Byte-Order-Mark (BOM) und markiert den Text als UTF-8-kodiert. Das Zeichen wird von den Editoren meist automatisch eingefügt. Der Nachteil ist, dass das BOM an den Browser ausgegeben wird (und störend wirkt) und unter Umständen mit Funktionen wie session_start() oder header() in Konflikt gerät.

Möglichkeit 1: Idealerweise bietet der Editor die Möglichkeit, UTF-8-Kodierung ohne BOM einzustellen. Notepad++ zum Beispiel kann das. Einfach eine der Optionen mit ... without BOM auswählen.

Möglichkeit 2: Die UTF-8-kodierten Dateien mit dem normalen Editor bearbeiten und später mit einem einfachen Editor öffnen und das BOM manuell entfernen.

Möglichkeit 3: Ganz normal mit dem bisherigen Zeichensatz (z.B. iso-8859-1) arbeiten und dann die Datei mit Hilfe der PHP-Funktion utf8_encode() umwandeln.

Deutschland lebt manchmal wirklich hinter dem Mond, so scheint's. Besonders stark drängt sich dieser Gedanke auf, wenn man sich die Szene der Seiten für gesellige Neuigkeiten (neudeutsch Social News) ansieht. Für die Betreiber von Yigg oder Webnews muss das frustrierend sein. Da programmiert man sich die Finger wund und schafft es sogar, sich von großen Medienunternehmen kaufen zu lassen, und trotzdem kommt man nicht aus dem Knick. Die Top-Stories bei Webnews reichen kaum mal an 50 Punkte heran und mehr als lediglich eine Handvoll Kommentare ist auch eher selten drin. Wenn überhaupt.

Besonders deprimierend muss der Blick in die Vereinigten Staaten sein. Die dort angesiedelten Digg und Reddit spielen in einer ganz anderen Liga. Hunderte, manchmal Tausende Votes für einen Beitrag. Die Zahl der Kommentare ist meist dreistellig. Diskussionskultur pur.

Der Vergleich mit Digg und Reddit mag vielleicht etwas unfair erscheinen. Schließlich hat die Deutsche Sprache nicht mal annähernd die Reichweite wie die Englische. Aber trotzdem. Gerade mal zweistellige Votes und ein paar Kommentare für eine Top-Story bei über 40 Mio Internetnutzern in Deutschland? Während bei den Amis prächtige Diskussionen gedeihen, herrscht bei den hiesigen Diensten nur tote Hose.

Andere Dienste in Deutschland haben es da besser. Zumindest was die Nutzerzahlen angeht. StudiVZ zum Beispiel. Soll ja recht beliebt bei den Studenten sein, was man so hört.

Es scheint noch nicht einmal was zu bringen, dass Seiten wie Spiegel, Zeit oder Süddeutsche Links zu Yigg und Co. einbauen. Die meisten Leser ahnen wahrscheinlich nicht einmal, wozu diese Links gut sein sollen. Zeit also für Aufklärungsarbeit? Viel Glück dabei!

Andere Website, andere Sorgen. Während bei den einen Flaute herrscht, geht’s den anderen zu gut. Kürzlich kündigte heise.de an, alle Kommentare löschen zu wollen die älter als zwei Jahre sind. Unglaublich. Welche Ressourcen da verloren gehen. Die Community fand das erwartungsgemäß überhaupt nicht witzig. Und wer den Mob in den Heise-Foren kennt, weiß, da war einiges los.

Am Ende scheint sich in den Heise-Foren doch noch eine Lösung abzuzeichnen. Und was die Social-News-Seiten angeht: Für die einen ist es der Arbeitsplatz. Andere haben viel Geld damit verdient. Und wieder andere verbringen Ihre Freizeit (oder vielleicht auch Arbeitszeit, wer weiß) dort. Also doch alles gut?

Nachtrag: Deutscher Reddit-Klon

Ist das nicht nett? O'Reilly bietet einige Bücher kostenlos als PDF-Datei für jedermann zum Herunterladen und Lesen an. Die Liste enthält neben Titeln zu PHP und Ruby auch einiges zu Linux und anderen Open-Source-Projekten.

Neu dabei ist das Werk „Praktischer Einstieg in MySQL mit PHP“ von Sascha Kersken. Das Buch hat 368 Seiten und die PDF-Datei wiegt rund 15 MB.

Wie der Titel schon sagt geht es um MySQL und PHP. Das Buch richtet sich an Anfänger und erklärt neben der Installation von Apache auch die Grundlagen von PHP und MySQL. Inklusive Installationsanleitung. Achja, phpMyAdmin wird auch erklärt.

Die Community ist in Aufruhr. Steffan Esser hat auf Grund der Diskussionen um den Namespace-Separator PHP geforkt.

:-D 

Hintergrund: Vor ein paar Tagen haben die PHP-Entwickler entschieden, statt Doppeldoppelpunkt, den Backslash als Trenner für Namensräume zu verwenden. Dagegen sträubt sich jedoch der eine oder andere. Erinnert angeblich zu stark an Windows-Pfade.

Ich persönlich hätte ebenfalls die Doppelpunkte favorisiert. Nüchtern betrachtet, macht's jedoch keinen Unterschied.

Ein Kunde unseres Kurz-URL-Scripts schrieb uns, dass sein Script einen Server-Fehler verursacht. Auf den ersten Blick schien jedoch alles zu funktionieren. Testweise "asdfasdf" in das URL-Feld des Scripts eingegeben und auch korrekterweise den Hinweis zum fehlerhaften URL-Syntax erhalten. Beim Eingeben einer korrekten URL in das Formular des Scripts meldete Apache allerdings einen Fehler.

Hm. Hin und her probiert und nach einer Weile ließ sich ein gewisses Muster erkennen. Der Server ließ es generell nicht zu, dass "http://" per POST oder GET an den Server übertragen wurde. Wir haben das mit einem einfachen Test-Script bestätigen können. Parameter wie ftp:// und https:// funktionierten interessanterweise.

Antwort vom Kunden:

It was due to the mod_Security rule set on server.

Ah ja.

Seit heute haben wir Kunden im Nirgendwo. Hier der Auszug aus der Bestellbenachrichtigung:

PLZ + Stadt      = Nowhere, NJ 34567
Land             = USA
Staat / Provinz  = New Jersey

:-o

Jeder Software-Entwickler oder Support-Mitarbeiter kennt solche Typen. Erst den hohen Preis bemängeln und dann mit jedem kleinen Problem den Support belästigen, statt die Anleitung zu lesen.

Um die geht es jetzt aber nicht.

Vor zwei Wochen kam eine Bestellung für den Schedule Organizer inklusive Installationsservice herein. Der Fragebogen ging noch am selben Tag an den Kunden. Da wir allerdings auch nach knapp zwei Wochen keine Antwort erhalten haben, hakten wir vor ein paar Tagen nach. War wohl 'ne gute Idee:

Thank you for following up! I really do appreciate that!!!

Außerdem schrieb der Kunde, dass er das Script bereits installiert hat. Er versprach aber, den Fragebogen ausgefüllt zurückzusenden. Na gut, bleibt uns dann wenigstens noch die Konfiguration und die Layout-Anpassung. Außerdem schrieben wir dem Kunden noch:

We hope we can do enough for you to earn the money you've spent for the installation service.

Und es schien sich tatsächlich eine Möglichkeit dafür aufzutun. Der Kunde wollte nämlich bestehende Daten in die Datenbank importiert haben. Wir boten ihm an, das für ihn zu übernehmen. Wir teilten ihm das gewünschte Format mit und erhielten kurz darauf die Daten.

Leider waren wir nicht flink genug.

I've already got the data into the database, but thank you for offering to do it!

Hallo? Das wollten wir doch machen.

Wenigstens blieb dann noch ein Problem mit den Konfigurationsdateien und der Kunde versprach, dass wir uns darum kümmern dürften:

I do need help with my customized config file though. It is giving me some wierd results.

Can I send it to you, along with how I need it set up and can you tell me where I have messed up?

Das las sich vielversprechend. Doch wie groß war später die Enttäuschung.

I've also figured out where I made mistakes on the config files and have corrected those and now ready to publicly deploy! Thanks for the support you offer and have given!

Wieder nix mit Support. Außerdem schrieb er noch:

No problem... it was just an opportunity for me to learn how. Always a good thing to learn more! The more I see how this application is built and configuration, the more I really like it and the doctors I'm setting it up for will really like it also!

Die Auszeichnung "Kunde des Jahres" ist hiermit offiziell verliehen. Die Messlatte für 2009 liegt jetzt ziemlich hoch. 

Es gibt mittlerweile für wohl fast jedes Anwendungsgebiet eines oder mehrere Scripte. Manche sogar kostenlos oder Open Source. Da lohnt es kaum noch, selbst etwas zu entwickeln, richtig? Nun ja.

Kaum ein Programmierer arbeitet gern mit dem Code von jemand anderem. Es dauert seine Zeit, bis man sich mit dem Stil und dem Inhalt vertraut gemacht hat. Und mancher Stil und Inhalt zwingt einen geradezu, alles neu zu schreiben.

Ähnlich sieht es aus, wenn ein Kunde eine derart individuelle Version benötigt, dass bestehende Lösungen nicht in Frage kommen. Und es gibt Scripte, die einfach nicht dafür geschaffen sind, mal eben eine neue Funktionalität hinzufügen.

Die größte Bedeutung für uns hat jedoch folgender Punkt: Wenn man in der Lage ist, selbst ein gutes und nützliches Script zu erstellen, warum sollte man das nicht auch tun? Auf diese Weise kann man als Software-Unternehmen sein Portfolio erweitern und sorgt so langfristig für Umsatz.

Da hat jemand nach einer "inoffiziellen Demo-Version" unseres Schedule Organizer gesucht und ist in diesem Blog gelandet. Und falls derjenige da draußen wirklich fündig wird: Was nützt ihm eine alte Version und kein Support im Fall eines Problems?

Wir arbeiten seit über zehn Jahren im und mit dem Internet. Die meisten geschäftlichen Absprachen betreffen selten größere Beträge und erfolgen formlos per E-Mail. Die Sache ist ja auch meist klar. Kunde schickt seine Liste mit Anforderungen, wir antworten mit Kostenvoranschlag, Kunde bezahlt, und wir erbringen die Leistung. Einfacher geht’s kaum noch.

Ab und zu tauchen in E-Mails dann jedoch merkwürdig deplatzierte Sätze wie diese auf.

Könnten Sie mir noch ein rechtsverbindliches Angebot auf Ihrem Geschäftspapier zukommen lassen?

Ein anderer schloss seine E-Mail, die einige Fragen zu einem Script beinhaltete, mit folgenden Worten ab:

Besten Dank für Ihre ausführliche Stellungnahme.

Wird Zeit, dass die Leute im Hier und Jetzt ankommen. 1950 ist schon etwas länger vorbei.

Ein Anwender schrieb:

My hosting service (network solutions) doesn't allow chmod 777. Do you have a work around?

:-[]