Einen Preis haben und dazu stehen

Es kommt ab und zu vor, dass potenzielle Kunden mit völlig außer Frage stehenden Preisvorstellungen zu mir kommen. Vor einigen Monaten hatte ich einen schon recht außergewöhnlichen Fall, wo das Projektbudget bei einem niedrigen dreistelligen Betrag lag.

Was tun? Den potenziellen Kunden wegschicken wollte ich natürlich nicht — jedenfalls nicht, ohne um ihn gekämpft zu haben. Sowas entscheide ich völlig unabhängig von der Auftragslage, also egal ob sie gut oder schlecht ist. Die Auftragslage war zu dem Zeitpunkt nicht schlecht, aber ich halte es für kurzsichtig, *nicht* um einen Kunden zu kämpfen.

Also habe ich ausführlich erklärt, warum 1. ich zu diesem Preis bei dem Projekt nicht mitmachen kann und 2. er bei einem solch niedrigen Budget niemand anderen finden wird, der ihm ein repräsentatives und qualitativ hochwertiges Ergebnis liefern wird. Als voraussichtliches Budget habe ich einen Euro-Wert geschätzt, der dem siebenfachen (!) des ursprünglich angesetzten Betrags entspricht. Dieser Betrag reflektiert deutlich besser den Aufwand, den jemand für gute Arbeit aufwenden muss.

Ehrlich gesagt habe ich bei dieser großen Differenz nicht damit gerechnet, von dem Kunden nochmal zu hören. :) Da habe aber diesmal ich mich getäuscht – zum Glück.

MySQL macht “Peng”…

Heute hatte ich es wieder einmal mit einem abgeschossenen MySQL-Server zu tun, dieses Mal von einem Neukunden. Zur Abwechslung hat dieses Mal der Hoster (!) an der Maschine herumgespielt und sie ohne den Kunden zu informieren während des Betriebs neu gestartet — ohne die Dienste herunterzufahren.

Da fässt man sich nur noch an den Kopf. Das Resultat war natürlich klar — die Datenbank war kaputt.

Was tun… Einen Dump des aktuellen Stands der Datenbank ziehen ging nicht. Schreibzugriffe verhindern per LOCK ging nicht. Per MySQL reparieren ging auch nicht, denn die betroffenen Tabellen waren zum Teil InnoDB-Tabellen, die man lt. MySQL nicht reparieren kann. Ich habe dann den MySQL-Server neu installiert und vorher /var/lib/mysql aufgeräumt. Nun wirds interessant: Ein einige Stunden altes Backup, von dem ich annahm, dass es keine Fehler hatte, konnte ich zwar einspielen. Beim ersten Starten des MySQL-Daemons wurde kein Fehler angezeigt — bei den folgenden Neustarts aber schon: Fehlerhafte Tabellen…. WTF?

Das konnte nicht sein. Ein Problem mit dem Dateisystem konnte es auch nicht sein. Testweise habe ich die MySQL-Dateien auf eine andere Partition geschoben. Das Ergebnis war das gleiche. So langsam gingen mir die Ideen aus, wie ich das Problem schnell beheben konnte. Die nächste Idee: Wenn InnoDB-Tabellen nicht repariert werden können, nehmen wir eben MyISAM-Tabellen. Also den Dump entsprechend manipuliert und wieder eingespielt — voila. Ohne REPAIR wohlgemerkt.

Der Kunde war gerettet und der Abend gleich mit.

Zensur im Internet

Bei Dr. Web ist ein schöner Beitrag zum Thema Zensur im Internet erschienen.

Nicht nur aus politischen Gründen interessiere ich mich für dieses Thema, sondern auch aus technischen Gründen. Meinem Eindruck zufolge kann man es als Admin oder Web-Entwickler mittlerweile nicht mehr sicherstellen, dass ein Produkt, eine Website, eine Web-Applikation von überall auf der Welt genutzt werden kann — egal, wieviel Sorgfalt man dem Produkt angedeihen lässt. Was ist, wenn aufgrund bestimmter Schlüsselbegriffe eine Website oder ein Server im Netz eines Zensors hängenbleibt? Was ist, wenn auf einem Shared-Hosting-Server der “Nachbar” ein schwarzes Schaf ist und man einfach “mitzensiert” wird?

Zensur bleibt natürlich primär ein politisches Problem. Über die technischen Implikationen mache ich mir aber zunehmend Gedanken.

Elektronischer Datenaustausch: Lassen Sie uns das per CSV machen…

Ich bin immer wieder erstaunt darüber, wie oft ich auf Projekte stoße, bei denen Daten in völlig ungeeigneten Formaten elektronisch ausgetauscht werden oder werden sollen. Ohne nähere Spezifikation natürlich. CSV ist so ein Klassiker. Das läuft dann so:

Ich: “Wie sollen die Daten denn ausgetauscht werden?”

Kunde: “Per CSV.”

Ich: “Haben Sie eine genaue Spezifikation des Formats?”

Kunde: “???”

Es ist weiter kein Problem, wenn der Kunde sich von mir beraten lässt und wir dann eine geeignete Lösung finden. Bei CSV-Daten ohne Spezifikation ist natürlich Ärger vorprogrammiert. CSV-Daten kann man nicht vernünftig validieren, man kann keine Typen definieren und standardisiert ist es im Grunde auch nicht.

Auch der elektronische Datenaustausch via Excel- oder generell Office-Dateien ist problematisch, und ganz besonders dann, wenn der Austausch bidirektional ist. Aus eigener, schmerzhafter und zum Glück bereits etwas zurückliegender Erfahrung weiß ich, dass das nicht gut geht — außer man hat eine Middleware zur Verfügung, die das nachweislich kann und einfach in einen automatischen Prozess integriert werden kann.

Was sind geeignete elektronische Austauschformate?

Weitschweifige philosophische Betrachtungen, wie sich XML zu EDI verhält oder ob XML disjunkt zu EDI ist oder auch nicht, lasse ich hier mal außen vor. Darüber kann man nämlich lange streiten. Klassisches EDI ist bei meinen Kunden bislang kein Thema.

XML. XML. XML. XML. XML. Ein XML-Format ist bisher eigentlich immer meine Empfehlung gewesen. XHTML, RSS und ATOM sind wohl die derzeit am häufigsten eingesetzten XML-Formate. Es ist auch relativ einfach, selbst ein Format zu definieren, zum Beispiel per DTD oder XSD. XML ist flexibel, einfach zu definieren und zu validieren.

Ein Medienbruch zwischen zwei Systemen ist immer mit Kosten verbunden, egal ob nun CSV, Excel oder XML zum Einsatz kommt. Die Frage ist nur, mit welchem Format die Kosten am niedrigsten sind. Meine Erfahrung ist, dass ein Medienbruch mit einem vernünftig definierten XML-Format wesentlich kostengünstiger ist als mit einem anderen Format.

Noch kostengünstiger wäre es natürlich, Medienbrüche ganz zu vermeiden.

Online-Erlebnis bereichern — ohne den IE6

Slashdot meldet, dass Youtube seit kurzem offenbar Internet Explorer 6-Nutzern ein Banner anzeigt. Auf dem steht:

Führe ein Upgrade auf einen modernen Browser durch, um dein Online-Erlebnis zu bereichern. Der Support für Internet Explorer 6 wird nach und nach eingestellt. Führe am besten jetzt ein Upgrade durch.

Danach folgen Links — verständlich als zu Google gehörendes Unternehmen — zu Chrome, aber auch zum Internet Explorer 8 und zu Firefox 3.5.

Slashdot berichtet von “jubilation breaking out all over the Net”. Dem schließe ich mich spontan an.