Auf der anderen Seite: Haben sie derzeit aber auch dringen nötig =)

leute vom #26c3 habt ihr sie noch alle? ne seite hacken ist eine sache, aber daten der benutzer ins netz stellen? so viel zum datenschutz…

Mhm. Irgendwo hat sie doch Recht. Setzt man sich doch für Datenschutz ein, will dem Staat keinen uneingeschränkten Zugriff auf sein digitales Bewegungsmuster gestatten. Wettert gegen die Datenkrake, weint aber rum, wenn die Suche mal down ist. Ich bin jemand, der seine Ansichten gerne mal hinterfragt. So auch in diesem Fall. Darf man sowas?Nach reiflicher Überlegung: Ja, darf man. Ich würde es als einen Fall von “digitaler Notwehr” bezeichnen. Lässt man Menschen mit rechtsextremen Gedankengut Freiraum, so macht man sich indirekt schuldig für das, was dieses anrichtet. Was das ist, kann man so gut wie täglich in der Zeitung lesen: Da werden “Schwarzafrikaner” die eigentlich Italiener sind totgeprügelt, da werden Brandsätze auf Asylbewerberunterkünfte geworfen, da werden Menschen an der freien Entfaltung Ihrer Persönlichkeit gehindert, weil Ignoranz und Fremdenhass wie Gift dem nach Polarisierung lechzenden Mob entgegengespuckt wird. Ich persönlich möchte mich dafür nicht verantwortlich zeichnen.

Die Welt ist nun einmal nicht schwarz und nicht weiß, die Welt ist nach wie vor ein Sammelsurium von vielen verschiedenen Grautönen und man muss jeden Schritt den man tut, jeden Gedanken den man denkt und jede Meinung die man hat immer wieder neu bewerten und kann keine Schablone anwenden. Tut man das doch, hat man einen Punkt erreicht, den man guten Gewissens als “geistigen Stillstand” bezeichnen kann. Damit will ich keinesfalls sagen, dass Leute, die sich negativ über die Verbreitung der oben genannten Daten äußern dem entsprechen. Was ich aber damit sagen will: Man kann nicht mit einer- oder zweierlei Maß messen. Man braucht für jede Situation ein neues.

Für die, die nicht wissen, was ein Headhunter ist oder ich damit meinen könnte: Headhunter sind Menschen, die versuchen fachlich qualifizierte und passende Menschen in ihr oder das beauftragende Unternehmen zu holen. – so jedenfalls die Theorie.

Zurück zu meinem Rant: Das erste mal in Kontakt mit einem Headhunter bin ich gekommen, als ich mein XING-Profil das erste mal komplett ausgefüllt habe. Wenige Tage später erhielt ich einen Anruf auf der Arbeit(!). Die Person gab sich als ein Kunde der Firma aus, für die damals gearbeitet habe und ließ sich zu mir durchstellen. Als er mich dann an der Strippe hatte, ging es ohne Umwege direkt zum Kern der Sache: “Sind die zufrieden in ihrem Unternehmen?”. Zu dem Zeitpunkt war ich das und lehnte das Angebot für ein persönliches Gespräch dankend ab. Mächtig Stolz war ich. So hat ein anderes Unternehmen einfach so interesse an mir gezeigt. Wow, und das, als die Arbeitslosenzahlen (mal wieder) einen Höchststand markierten.

Es dauerte eine Weile, und dann kam schon der nächste … oder eher DIE nächste. Das Schema blieb das selbe: Mit Tricks und Schummeleien zu mir durchgestellt werden und dann die Katze aus dem Sack lassen. Es wurde nervig. Aber es war auch noch im Rahmen … immerhin war da so etwas wie ein persönlicher Kontakt. So sollte es nicht bleiben.

Kurze Zeit später trudelten mehr und mehr ungefragte eMails, Kontaktanfragen und ähnliches ein. Immer ist von “mittelständischen” Unternehmen die Rede, die aber immer geheim bleiben. Immer sind die Leute selbst erst seit kurzem bei XING und haben ein kaum ausgefülltes Profil geschweigedenn einen Werdegang. Zum Mäusemelken. Aber mitlerweile landen diese Mails einfach im Papierkorb.

Seit ich aber ein Blog betreibe, wird es wieder zunehmen persönlich. Nicht unbedingt im positiven Sinne. Nach langer Zeit ging ich auf diese – oftmals recht freundlichen und auch nicht so anonymen – Anfragen ein. Am Ende wurde dann doch schnell klar: Die Leute suchen junge, talentiere Leute, die sich über den Tisch ziehen lassen. Mit einem Jahresgehalt, dass nur knapp über dem liegt, was man zum Leben braucht und in Arbeitsverhältnissen, in denen keiner glücklich wird: OS-Zwang (als Entwickler?), Editor-Zwang (WTF?), Chefs die von sich selbst behaupten mal Programmierer gewesen zu sein, aber auf neumodischen Schnickschnack wie OOP, XHTML und Technologien wie AJAX, JSON und Komparsen lieber verzichten. Läden, in denen “Server” für Behördenprogramme aus vergilbten Desktoprechnern bestehen, die altersschwach vor sich her rattern. Ausgebrannten Kollegen, die jeglichen Enthusiasmus verloren haben. Nein, Danke.

Unter den vielen “Anfragen” kann ich die in Frage kommenden an einer Hand abzählen. Es waren genau zwei. Einmal hat es räumlich nicht geklappt, und einmal war ein anderer Job nicht viel – aber besser. Ich mag meinen Job. Und ich mag ihn da, wo er ist. Also bitte, liebe Abwerber: Lasst mich in Ruhe!

All das soll mich aber nicht daran hindern, meine Signatur unter das zu setzen, was ich schaffe. Damit meine ich nicht meinen Namen in den Kommentaren, damit meine ich auch nicht, dass ich ans Dokumentende ein pubertäres „hacked together by Cem Derin“ klatsche. Oftmals ist das ja auch gar nicht möglich. Nein, ich meine, dass ich meine Handschrift so hinterlasse, dass Sie zwar Sichtbar ist – aber trotzdem auch Unsichtbar. Dazu bediene ich mich dem, was gemeinhin als „Easteregg“ bekannt ist. So stelle ich sicher, dass meine Software von den Leuten gewürdigt werden kann, die dazu auch in der Lage sind.

Viele Seiten beinhalten einen kleinen Scherz, einen Kommentar, einen Witz oder ähnliches, wenn man bestimmte Tastenkombinationen auf einer Seite betätigt. Das hat den Nachteil, das ein gewisser Anteil JavaScript nachgeladen werden muss und man ggf. auch Resourcen einbettet, die kein Mensch freigegeben hat. Da man sowas natürlich auch nicht mit seinem Gewissen vereinbaren kann, hatte dies zur Folge, dass meine Eastereggs so versteckt waren, dass sie keiner Gefunden hat.

Irgendwie hat auch das geschlaucht. Da gab es dann aber noch eine andere Möglichkeit, wie man ein Easteregg unterbringen kann: ASCII-Art. Obwohl, nicht direkt. Im Grunde meine ich nur das hinzufügen von zusätzlichem Whitespace. Man verändert den Inhalt nicht, sondern lediglich die Formatierung, so dass dem Betrachter eine Botschaft ohne jegliche Nebenwirkungen übermitteln kann.

Dazu habe ich ein kleines Programm geschrieben, dass zwar noch alles andere als ausgereift ist, aber seinen Zweck trotzdem schon erfüllt. Zu finden ist es hier. Und wer sich nun fragt, was das Ding macht – der schaue sich den Quelltext dieses Beitrags an =)

Übrigens: Die Textbasis ist derzeit die, die ihr hier grade lest. Das wird sich aber bald ändern. Außerdem stehen die Einstellungsmöglichkeiten noch nicht zur Verfügung – denn um ein halbwegs zufrieden stellendes Ergebnis zu erzielen, muss man ganz schön den Parametern rumjustieren.

Gefunden bei focus.com durch einen Schubs von Sergej.

Folgt man diesem, so landet man auf einer sehr rudimentären (bzw. definitiv von einem Entwickler gestalteten) Eingabemaske, die eine URL, einen Namen sowie ein Passwort annimmt. Versucht man allerdings das Formular auszufüllen und abzuschicken, passiert – nix.

Das könnte natürlich daran liegen, dass unter dem Formular in roten Lettern darauf hingewiesen wird, dass das ganze Teil (noch) nicht für den öffentlichen Gebrauch bestimmt ist. Wie dem auch sei.

Wirklich interessant ist: Wie kommt man an eine Domain “to.”? Viele werden wahrscheinlich wegen dem Punkt am Ende verwirrt sein. Prinzipiell kann man aber jeden TLD mit einem Punkt am Ende aufrufen. Und im DNS stehen sie sowieso genau so drin. Hier ist er allerdings wichtig, da die eingegebene URL nur so vom Browser als FQDN erkannt wird. Was macht der Browser nun? Er lässt im DNS nachschauen, wohin die Domain to. auflöst. Und das ist auch schon der Knackpunkt: to. wurde als Ressource eingetragen, löst korrekt auf eine IP auf und hinter dieser verbirgt sich ein Webserver. Padabing!

Und warum kam das nicht eher? Weil es eher unbequem, verwirrend und die Auswahl der möglichen Domains eher eingeschränkt ist

Heute ist das aber anders: Vor ein paar Tagen fragte sich Nils, wie man wohl Exceptions korrekt verwendet. Jetzt finde ich endlich mal genug Zeit, meine Meinung zu dem Thema niederzuschreiben.

Nils versuchte sich mit folgendem Grudsatz aus der Affäre zu ziehen

Excpetions (Ausnahmen) werden immer dann geworfen, wenn etwas unerwartetes passiert.

Die meisten gestandenen Entwickler werden dem Zustimmen. Die meisten Anfänger werden sich fragen, wie man unerwartete Vorfälle berücksichtigen kann. Diese werden dann müde belächelt, Erklärungen bleibt man ihnen dann aber meist dennoch schuldig. Nils immerhin gibt sich Mühe, eine Reihe solcher Ereignisse beispielhaft aufzuzählen. Am Ende weiß er dann aber selbst nicht, was man für eine Regel an die Hand geben könnte. Ich ich könnte wetten, die meisten Entwickler sind etwas ratlos, was das Thema Exceptions angeht.

Versuchen wir also einfach einmal, zu erörtern, wie man Exceptions am besten einsetzen könnte. Vorher will ich aber mit einer ziemlich falschen Behauptung aufräumen: Exceptions stellen keine unerwarteten Ereignisse dar, sondern Ausnahmen (wie der Name ja auch sagt). Somit hat sich der Hirnknoten, wie man unerwartetes Berücksichtigen kann hoffentlich auch aufgelöst.

Wer die Kommentare in Nils Beitrag gelesen hat, dem wird nicht entgangen sein, dass ich dort der Verwendung von Exceptions für strukturelle Prüfungen wie Nils negativ gegenüberstehe. Diese Meinung lege ich an dieser Stelle (vorläufig) ab (das sollte man übrigens öfter mal tun, wenn man einen Objektiven Blick auf ein Thema erhalten will).

Alles ist eine Klasse – Jeder Fehler eine Exception

Ich persönlich finde den Ansatz, dass alles durch eine Klasse repräsentiert wird ziemlich bequem. Beherzigt man diesen Grundsatz konsequent, kann man verdammt flexible Anwendungen bauen. Refactoring wird auf einmal extrem bequem, und wenn man dann noch das Template Pattern benutzt, ist man komplett auf der sicheren Seite. Es wäre nur Konsequent, wenn man hier Fehlerfälle durch Exceptions abbildet. Aber wie macht man so etwas richtig?

Einfach zu sagen „Prüfungen liefern nicht mehr true oder false sondern werfen von nun an eine Exception, wenn etwas nicht zutrifft“ ist leider etwas zu einfach. Nehmen wir das Beispiel einer User-Klasse: Wollen wir wissen, ob der Benutzer online ist, werden wir dafür eine Methode bemühen, die etwas isOnline heißen könnte. Ist der Benutzer nicht online, stellt dies natürlich keine Ausnahme dar. Hier ist ein Boolescher Wert (oder wenn man ganz penibel sein möchte auch die Repräsentation durch eine Klasse) vollkommen in Ordnung.

Nehmen wir aber an, dass wir Änderungen den Stammdaten eines Benutzers vorgenommen haben und diese nun speichern wollen. Dann haben wir für so etwas sicherlich eine Methode die save heißen könnte. Natürlich könnte es vorkommen, dass aus verschiedenen Gründen der Speichervorgang fehl schlägt: Die Datenbank ist plötzlich nicht mehr verfügbar, die angegebenen Daten können nicht eingetragen werden (vielleicht weil gegen Constraints verstoßen wird).

In diesem Fall einen Booleschen Wert als Indikator zu liefern klingt erst einmal plausibel. Der entsprechende Code könnte ungefähr so aussehen

if($user->save()) {
	// Der Speichervorgang war erfolgreich
} else {
	// Der Speichervorgang war nicht erfolgreich
}

Eine Reihe von Gründen sprechen allerdings gegen ein solches Vorgehen. Legt man beispielsweise Wert auf ein Fluent Interface (das bedeutet, dass eine Methode wenn möglich immer die Instanz des eigenen Objektes zurückgibt), ist dieser Ansatz schon einmal nicht möglich. In diesem Fall bleibt uns nichts anderes übrig, als mit Exceptions zu arbeiten.

Folgender Code könnte verwendet werden

try {
	$output = $user->save()->getId();
	echo 'Der User hat die ID: '. $output;
} catch(UserException $e) {
	echo 'Bitte prüfen Sie Ihre Angaben';
} catch(DbQueryException $e) {
	echo 'Bitte prüfen Sie Ihre Angaben';
} catch(DbException $e) {
	echo 'Leider ist die Datenbank zur Zeit ausgefallen. Versuchen Sie es zu einem späteren Zeitpunkt noch einmal'.
} catch(Exception) {
	echo 'Ein unbekannter Fehler ist aufgetreten. Wir arbeiten 'dran';
}

Das Programm versucht das Benutzerobjekt zu speichern und liest direkt die ID aus, um diese später an den Benutzer auszugeben. Wird in diesem Prozess nun eine Exception geworfen, gibt es eine Reihe von Fängern – je nach dem, welche geworfen wird. Man kann hier also auch eine tolle Fallunterscheidung treffen. Für den Fall, dass eine Komponente einen nicht dokumentierten oder hier evtl. tatsächlich nicht erwarteten Fehler in Form einer Exception auslöst, sollte man diesen Fall auch immer vorsehen und einen Catch-Block für die Basisklasse erstellen.

Unter der Haube

Innerhalb der Userklasse könnte der Code ungefähr so aussehen:

class User {
	public function save() {
		$this->validate();
		$this->writeToDb();
		return $this;
	}

	public function validate()  {
		if(!$this->isValidUserName($this->data->username)) {
			throw new UserException('Username not valid');
		}
	}

	public function writeToDb() {
		$this->databaseAdapter->query($this->createInsertQuery());
	}
}

Wir sehen, das in der Methode validate durchaus ein Boolescher Wert ausgewertet wird. Die Answendung macht hier insofern Sinn, dass hier eine Prüfung stattfindet. Im Falle der Methode save wird angenommen, dass alle Daten korrekt sind, unabhängig von einer evtl. erneuten Prüfung.

In der Methode writeToDb sehen wir, dass ein Query erzeugt wird, welcher an einen Datenbankadapter weitergereicht wird. Dieser wird im Falle eines Fehler eine Exception werfen. Diese fangen wir absichtlich nicht innerhalb der Modellklasse.

Exception-Codes

Nehmen wir nun einfach einmal an, beim Speichern unseres Benutzerobjektes wurde gegen einen Contraint in der Datenbank verstoßen. Die Datenbank meldet dies, unser Adapter wird eine Exception werfen. Wir wissen nun, dass etwas schief gelaufen ist, wir wissen auch ziemlich genau wo. Aber wir wissen nicht, was genau muckiert wird.

Die erste Überlegung die sicherlich nun viele haben (und die ich leider auch schon in Produktivsystemen angetroffen habe) ist, dass man Informationen in der Message des Exception-Objekts ablegt. Das ist zwar durchaus möglich und das habe ich auch schon gesehen, aber das ist eine eher unsaubere und unschöne Methode.

Wenn ich die Message einer Exception auslese, will ich, dass diese in einem Menschenlesbaren Format in einer definierten Sprache (und explizit nicht in einer Übersetzung) vorliegt. Ich will, dass sie für mich als Entwickler Aussagekräftig ist und nicht so weit verallgemeinert wurde, dass ein Endbenutzer auch noch etwas damit anfangen kann.

Wie bekomme ich nun also Informationen in die Exception verpackt, mit der das Programm arbeiten kann um so stets qualifizierte Fehlermeldungen erzeugen zu können? Ein kleiner Blick in das PHP-Handbuch hätte es verraten: Exceptions bieten die Möglichkeit neben einer Message auch einen Fehlercode zu hinterlegen. Dieser kann Eindeutig gemacht werden und so in catch-Blöcken detaillierte Fehlerausgaben ermöglichen.

Fazit

Während unserer kleinen Übrlegung hat sich folgendes herauskristallisiert: Es ist ziemlich entscheidend, an welcher Stelle Exceptions geworfen und an welcher sie gefangen werden. Konkret kann man resumieren: Geworfen werden Exceptions aus tieferen Programmschichten, gefangen und ausgewertet in höheren. Auf das MVC-Muster angewandt könnte man sich als Faustregel festhalten, dass Exceptions aus Modellen oder tieferen Hilfsklassen geworfen werden und von Controllern oder entsprechenden Hilsklassen gefangen werden.

Somit klärt sich neben dem Wie nun auch das Wo.

Das Problem Debugging

Nun haben wir doch eigentlich einen ziemlich klaren Anwendungsbereich für Exceptions erarbeitet. Trotzdem gibt es ein kleines Problem: Das fangen von Exceptions kann dazu führen, dass auftretende Fehler evtl. nicht mehr korrekt ausgegeben werden. Aus diesem Grund ein kleiner Kniff auf meiner Trickkiste: Exceptions mitloggen.

In einem Projekt solltet ihr für jede Klasse eigene Exceptions anlegen, die sich allerdings auch wieder von einer eigenen Exception Klasse ableiten. Diese könnte dann ungefähr so aussehen:

class MyException extends Exception {
	public function __construct($message, $code = null) {
		parent::__construct($message, $code);
		MyLogger::log('Exception thrown with message "'. $message. '"');
	}
}