ScriptBlogger

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.

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. 

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. :-)

Im Kunden-Support zu arbeiten ist nicht jedermanns Sache. Stets freundlich sein und immer die richtige Antwort wissen kann auf Dauer recht anstrengend sein. Darunter leidet nicht nur die Motivation des Support-Mitarbeiters sondern im Endeffekt auch die Qualität der Support-Arbeit selbst.

Richtig problematisch wird es dann, wenn Support nur einen Teil der Arbeit ausmacht. Da verdrängen dann vermeintlich wichtigere Dinge die Support-Arbeit. Anfragen stauen sich ungelesen und unbearbeitet auf und am Ende sind alle nur noch genervt.

Deshalb ein Tipp an dieser Stelle: Viele Support-Anfragen sind schneller erledigt als man denkt. Und wenn man erst einmal mittendrin ist, dann fällt es einem auch einfacher, die größeren Brocken zu bearbeiten. Wichtig dabei ist, Anfragen sofort beim Eintreffen zumindest erst einmal zu lesen. Wirklich Aufwändiges oder Kompliziertes lässt sich dann immer noch zurückstellen. Aber hoffentlich nicht zu lange. ;-)

Ab und an fragen Neulinge im Geschäft, was ein angemessener Stundensatz wäre und wie man den Preis für ein Projekt berechnet. Nichts einfacher als das.

Stundensatz

Um den eigenen Stundensatz zu berechnen muss man wissen, wie viele abrechnungsfähige Stunden man im Monat schafft zu arbeiten. Dann teilt man sein gewünschtes monatliches Einkommen durch die Stundenzahl und voila - man hat seinen Mindeststundensatz. Den kann man dann noch beliebig nach oben anpassen, abhängig von:

• Eigene Fähigkeiten
• Marktgegebenheiten
• Kunde
• Projektlaufzeit

Projektpreis

Wer meint, in der Lage zu sein, den Arbeitsaufwand realistisch einschätzen zu können, multipliziert einfach seinen Stundensatz mit der Zahl der geschätzten Stunden.

Projektpreis = Stunden _* Stundensatz

Das macht man dann so lange bis man seine Rechnungen nicht mehr zahlen kann. Oder man gesteht sich gleich ein, dass das korrekte Schätzen des Arbeitsaufwandes bei Projekten ab einer gewissen Größe nahezu unmöglich ist. Also fügt man am besten eine Konstante ein, die das schlechte Augenmaß wieder ausgleicht.

Projektpreis = Stunden _* Stundensatz _* 2

Zugegeben, das macht einen recht wahllosen Eindruck. Die Erfahrung hat aber gezeigt, dass das dem Ergebnis am nächsten kommt. Wahlweise kann man es gern auch mit 1,5 oder 2,5 probieren.

Heute haben wir mal wieder die Dollar-Preise erhöht, da der US-Dollar schon seit einiger Zeit rund ein Drittel weniger wert ist als der Euro. Die bisher gleichen Preise für Dollar und Euro waren schon lange nicht mehr gerechtfertigt. In den letzten fünf Jahren ist der Preis für den Dollar von knapp 90 Euro-Cent mit einigem Auf und Ab zwischendurch auf jetzt 66 Euro-Cent gefallen. Das ist zwar gut für den Import, für den Export ist das alles andere als Ideal.

Nachdem wir vor einigen Monaten die Preise auf STADTAUS.com und GentleSource entsprechend angepasst haben, sind wir heute beim Schedule Organizer nachgezogen. Dadurch werden die Preise wieder gerechter für alle, die in Euro bezahlen. Denn wer in USD bezahlte, sparte bislang rund ein Drittel des Preises.

Scripte, deren Konfiguration und Einrichtung online nur sehr schwer zu demonstrieren sind, bieten wir als vollwertige Testversion zum Herunterladen an. Das gilt zum Beispiel für das Form Mail Script oder auch das Kommentar-Script . Die Download-Buttons sind eigentlich kaum zu übersehen und doch gibt es immer wieder Anwender, die gleich kaufen statt vorher auszuprobieren.

Meist geht das gut und der Kunde ist mit dem Produkt zufrieden. Aber manchmal hapert es eben. Da fehlt dann eine wichtige Funktion oder der Kunde (und auch wir) sind partout nicht in der Lage, das Script zum Laufen zu bringen.

Prinzipiell könnte uns das ja egal sein, nur leider kostet uns jede Rückbuchung bares Geld. Außerdem hat der Kunde unnötiger Weise den Kaufprozess durchlaufen und muss dann auch noch ein Auge darauf haben, dass er sein Geld wiederbekommt.

Deshalb unser Aufruf: Wenn es schon die Möglichkeit gibt, kostenlos und risikofrei zu testen, dann sollte man sie auch nutzen. B-)

In der aktuellen ix (8/2008) stellt der Artikel "Lückensuche" Scanner zur Schwachstellensuche in Web-Applikationen vor. Der Autor ist darin der Meinung, dass "[...] als Hauptursache für das Entstehen von Schwachstellen [...] der Kosten- und Zeitdruck [gilt], unter dem Anwendungen in der Regel entwickelt werden müssen."

Unsere Erfahrung ist jedoch, dass unsicherer Code eher auf Grund mangelnden Fachwissens der Anwendungsentwickler entsteht. Das sieht dann auch der Autor des Artikels so, denn ein paar Absätze später widerspricht er seiner ersten Aussage.

Damit Programmierer bei der Entwicklung erst gar keine Schwachstellen entstehen lassen, sollten sie rechtzeitig durch Schulungen sensibilisiert und motiviert werden, auf Sicherheitsaspekte zu achten.

Richtig. Allerdings sollten Projektplaner und Projekt-Manager in diese Schulungen einbezogen werden, denn Software-Sicherheit sollte von Anfang an Bestandteil der Projektplanung sein. Außerdem befinden sich Entscheider eher in der Position, Sicherheitsfunktionen durchzusetzen. Die Entwickler haben in dieser Hinsicht oft die schlechteren Karten.

Kurzer Ausflug in den Bereich Suchmaschinen und die Jagd nach Besuchern. Ab und zu hört man Theorien, dass die Position 11 - also zweite Seite ganz oben - besser sei als Position 10 - erste Seite ganz unten.

Wenn es um hart umkämpfte Suchbegriffe handelt, bei denen das Ergebnis meist sehr homogen ist, trifft diese Theorie erfahrungsgemäß nicht zu. Wenn von zehn Suchergebnissen, acht in etwa dieselben Inhalte bieten, ist die Chance, dass der Suchende bereits bei den ersten zehn Ergebnissen fündig wird, recht groß.

Im konkreten Fall, dümpelte eines unserer Projekte mehrere Wochen auf Seite zwei ganz oben vor sich hin. Erst als die Website den Sprung unter die ersten zehn Ergebnisse geschafft hat, strömten die Besucher. Dauert nicht mehr lange, das sind wir hier alle reich. ;-)

Manchmal hat man den Eindruck als müsste man ein schlechtes Gewissen haben, dass man seine Software nicht als Open Source entwickelt und nur gegen Geld herausgibt. Richard Stallman und seiner Idee von freier Software sei Dank. ;-)

Wir halten es da eher mit Matthias Kalle Dalheimer, der in der ix 6/2008 wie folgt zitiert wird: "Im Gegensatz zu einigen Hardlinern bin ich nicht der Meinung, dass jede kommerzielle Software ein Werk des Teufels ist. Beide haben ihre Berechtigung, und sei es nur, um den Entwicklern einen vollen Kühlschrank zu sichern. Als freischaffender Software-Entwickler spüre ich die Ambivalenz zwischen freien und kommerziellen Anwendungen täglich am eigenen Leibe - und zwar im positiven Sinne. Durch die Entwicklung kommerzieller Applikationen kann ich meine Familie ernähren und habe gleichzeitig die Möglichkeit, freie Software zu schreiben".

Dem ist wirklich nichts hinzuzufügen. B-)

Der Hostblogger plagt sich mit undankbaren Software-Entwicklern herum und den Kommentaren unter dem Beitrag lässt sich entnehmen, dass dies kein Einzelfall ist.

So ganz nachzuvollziehen ist die Einstellung solcher Entwickler tatsächlich nicht. Wenn jemand Zeit und Wissen investiert, ist es doch nur fair, den Code auch zu nutzen. Man kann die neue Option doch standardmäßig ausgeschaltet lassen.

Wir haben bereits jede Menge Code von unseren Kunden und Nutzern bekommen und auch verwendet [1]. Bei einem Fall allerdings waren die Anpassungen dermaßen umfangreich, dass das Übernehmen des Codes recht aufwändig gewesen wäre, beziehungsweise aufwändig sein wird. Noch ist die Sache nicht abgeschrieben und wir hoffen immer noch auf den Moment, dass die Zeitfee uns hold ist und uns ein paar Stunden für die Umsetzung schenkt. ;-)

Immer her also mit den Templates, Sprachdateien, Code-Schnipseln, Anleitungen etc. 

[1] Soweit wir uns erinnern können.

Laut unseren Recherchen ist die Domain scriptblogger.de frisch und war bisher noch nicht in Benutzung. Die Domain ist bislang (Stand 10. Juli) nirgends verlinkt und nirgends eingetragen worden. Trotzdem waren bereits vier Tage nach Registrierung der Domain bereits GoogleBot und der Bot von archive.org da.

Für das Erscheinen des GoogleBot könnte als Erklärung dienen, dass wir den RSS-Feed zum Google Reader hinzugefügt haben. Eine andere Erklärung könnte sein, dass Google generell Domain-Registrierungen überwacht. Letzteres erscheint auch plausibel für den Bot von archive.org. Wie sollte der sonst Wind von dieser Website bekommen haben?