Sehr geehrte Headhunter, liebe Personalvermittler

Aus aktuellem Anlass und in der Hoffnung, dass ihr - neben meinem Xing Profil - auch meinen Blog lest, schreibe ich euch diese Zeilen. Ich habe zum Anfang September den Job gewechselt, das habt ihr sicherlich bemerkt. Ich gehe zwar nicht davon aus, dass ihr es in eure "sprech ich ihn jetzt an?"-Überlegung einbezieht, aber ich wollte in meiner grenzenlosen Naivität trotzdem mal darauf aufmerksam machen. Ich frage mich manches Mal ernsthaft, ob ihr nicht lieber hättet weiter euren gelernten Beruf weiter ausüben sollen. Vielleicht wart ihr ja gut darin? Und selbst wenn ihr diesen Beruf gelernt habt, scheinen die Meisten doch wo anders besser aufgehoben. Die Ignoranz, mit der ihr jedoch über mich und mein öffentliches Profil herfallt, kennt leider kaum eine Grenze. Warum hat euch keiner beigebracht Profile auch mal zu interpretieren, nicht nur zu lesen? Selbst Google reagiert besser auf Keywords als ihr! Nur weil ich "XYZ" in meinem Profil stehen habe, seht ihr die Chance mich zum Experten zu erheben und in euer Suchprofil zu pressen? Ich bin gerade von einer Agentur zu einem völlig anders strukturierten Unternehmen gewechselt. Habt ihr mal nachgedacht, ob das vielleicht ... Absicht war? Würde ich in eine Agentur wollen, hätte ich nicht dann auch eine Agentur gewählt? Meint ihr ernsthaft, ich wechsle nach nicht mal zwei Monaten direkt wieder den Job? Kennt ihr das Wort "Treue" oder auch "Nachhaltigkeit"? Wäre es euch nicht genauso wichtig, dass ein Mitarbeiter in dem Unternehmen bleibt, an den ihr in vermittelt? Nunja, die Erwartungshaltung, dass Psychologie oder auch nur grundsätzliches analytisches Verhalten in eure Arbeit mit einfließt, ist wohl doch zu viel erwartet, schließlich ist der Mensch eure Ware und Nachhaltigkeit nicht euer Problem. Leider wandelt sich euer Verhalten mehr und mehr zu dem eines Spam-Bots und meine Reaktion darauf entspricht auch immer mehr diesem Schema - leider gibt es bei Xing noch keinen Spamfilter. Persönliche Ansprachen sind selten geworden, die Stiefelleckerei in euren Texten und eure Penetranz kotzen mich an. Die Zeiten, wo ihr Nerds und Geeks mit Schmeicheleien hinterm Ofen hervor locken konntet, sind nun seit Jahren vorbei.

Ich suche mir meinen Job selbst aus. Und das habe ich bereits getan.

Ich weiß, dass ich einigen Vertretern eurer Zunft Unrecht antue. Leider sind mir bis zum heutigen Tage nur ein oder zwei von euch begegnet, von denen ich das oben gesagte nicht behaupten kann.

Ein Newsletter Tool selbst gebaut - Neo4J, RabbitMQ, Vaadin

Seit einiger Zeit arbeite ich jetzt als Java Developer bei der trivago GmbH. Zum ersten Mal durfte ich nun auch an den trivago Developer Days teilnehmen, welche vom Konzept her etwas an die Google'sche 20% Regelung erinnern. Wir Developer bekommen in regelmäßigen Abständen 3-4 Tage Zeit, sich ein Projekt auszuwählen (aus dem internen Ideenportal oder aus eigener Motivation) und dieses Umzusetzen. Für mein erstes DevDays Projekt habe ich mich, zusammen mit Christian Krause (@redbrick) an ein Mail Delivery System gesetzt. Drei Tage (plus ein Halber für das Vorbereiten der Präsentation und ein weiterer Halber für das Setup) sind nun nicht viel, auch wenn man die Definition von "Tag" irgendwo zwischen acht und 14 Stunden ansiedeln kann. Wir haben uns also auf die Kern-Features beschränkt, die wir selbst von einem solchen System erwarten würden. Klar war, dass Mail-Delivery die Kernkompetenz sein sollte. Wir wollten jedoch, auf der Delivery Schicht basierend, auch eine Applikation erstellen, damit der Nicht-Tekkie auch etwas davon hat. So ist die Idee des Newsletter Systems entstanden, welchem wir den Arbeitstitel Mail-Pigeon verpasst haben. Die Wunsch-Features im Überblick: Mail-Delivery:

• Versand über mehrere Clients (horiz. Skalierbarkeit)
• Kein Datenverlust beim Absturz einer oder aller Sending-Daemons
• Bounce Handling (zumindest erst mal rudimentär)
• Ein Datenformat, dass sowohl von PHP und JavaScript, als auch von Java beherrscht wird. Bleibt nicht viel: XML und JSON. Und XML war es nicht ;)

Newsletter System:

• Absender Management (Durch die vielen Nationen und Sprachen bei trivago haben wir sehr verschiedene Absender)
• Empfänger und Empfängergruppen
• Newsletter und Vorlagen für neue Newsletter sowie Personalisierungsmöglichkeiten
• Wirkungsgradbestimmung durch Trackingpixel und Kampangen
• Live Versandstatus und Fortschritt
• Tagging für einen Versand

Als Technologien kamen Neo4J, eine GraphDB, RabbitMQ, eine MessageQueue und Vaadin, ein auf GWT basierendes UI Framework zum Einsatz. Ich werde alle Technologien, deren Verwendung und eine kurze Begründung zur Wahl im Folgenden anreißen.

RabbitMQ ist ein MessageQueue Server, der von VMWare's SpringSource Devision in Erlang entwickelt wird. Die Wahl fiel auf RabbitMQ, weil er sowohl AMQP und JSONRPC over AMQP, als auch STOMP unterstütz und damit für alle bei trivago eingesetzten Sprachen erreichbar ist. RabbitMQ ist zudem hochperformant und kommt unserem Vorhaben, Tonnen von Mail zu versenden, zu Gute.

Neo4J ist eine Graphdatenbank, geschrieben in Java. Neo4J unterstützt sowohl gerichtete, als auch gewichtete Kanten, ebenso wie Eigenschaften an Knoten. Das Konstrukt wird ergänzt durch einen Lucene Index für Knoten, über den man recht schnelle Key-basierte Lookups durchführen kann. Die Wahl fiel deswegen auf eine GraphDB, weil sie am sinnvollsten unsere Daten abbildet. Es entstehen sehr viele Beziehungen zwischen den Entitäten unserer Applikation, die durch RDBMS - JOIN - Konstrukte sicherlich nur unter hohem Rechenaufwand abbildbar wären.Ein Beispiel ist die Relationsmenge zwischen Empfänger (E), Empfängergruppe (G) und versendetem Newsletter (N). Hier gibt es folgende Relationen abzubilden:

• N -> versendet an -> G
• E -> hat empfangen -> N
• E -> hat geöffnet -> N
• G -> enthält Empfänger -> E

Nehmen wir noch einen weiteren Knotentype "Bounce" (B) hinzu, wird das Konstrukt noch etwas interessanter:

• N <- ist hard-bounced <- B -> ist hard-bounced -> E

• N <- ist soft-bounced <- B -> ist soft-bounced -> E

Damit lässt sich also recht schnell darstellen, welcher Bounce-Typ bei welchem  Newsletter oder Empfänger vorkam. Kanten lassen sich übrigen mit linearem Aufwand zählen, wenn man den Knoten kennt!

Vaadin ist ein auf dem Google Web Toolkit basierendes UI Framework. Ich bin kein großer HTML/CSS Künstler, also musste etwas anderes her, was erwachsen und optisch ansprechend war. Mit Vaadin konnte ich im Liferay - Bereich schon mal Erfahrungen sammeln und fand es schon damals sehr ansprechend. Wer mal Swing oder AWT benutzt hat, der wird sich bei Vaadin recht schnell heimisch fühlen. Jedenfalls bekommt man bei Vaadin jede Menge "geschenkt", was Optik, Kompatibilität und Technologie angeht. Ich kann euch nur den Sampler ans Herz legen, dann versteht ihr was ich meine ;)

Personalisierung  haben wir durch das Einbetten von Apache's Velocity erreicht. Die Mail Templates, aus denen man neue Newsletter erstellen kann, können in Velocity geschrieben werden. Beim Versand wird der Template-Context mit den Daten des Empfängers, der Gruppe, der Kampange und Metadaten befüllt und für jeden Empfänger evaluiert. So wird eine komplette Personalisierung ermöglicht.

Tracking wird durch das automatische Einfügen eines <img /> Tags in die HTML Version der Mail erledigt. Das Image ruft ein separates Servlet auf, welches den Newsletter und die Empfänger ID benötigt. In der Folge kann dann die gerichtete Kante E -> hat geöffnet -> N erstellt werden.

Tagging erscheint vielleicht auf den ersten Blick für einen Newsletter ein wenig sinnfrei. Wenn man jedoch die GraphDB in die Rechnung
mit einbezieht und das Tracking hinzu nimmt, dann entsteht die Möglichkeit "User-Interest-Tracking". Die Kobination Tag (T) sieht dann z. B. folgendermaßen aus (Die Pipe soll zwei Kanten darstellen):

T <- hat Tag <- N <- hat empfangen | hat geöffnet <- E.

Aus diesen Relationen können wir also, bei entsprechender Skalierung, ablesen, für welche Tags sich ein Empfänger interessiert.