Leider ist der Eintrag nur auf English verfügbar.

Man könnte sagen, dass es prinzipiell zwei Wege gibt, bestimmte komplexe aber unabhängige Teilfunktionalitäten eines Systems zu entwickeln:

1. Alles selbst entwickeln
2. freie Frameworks, APIs und SDKs nutzen und zu einem größeren Ganzen zusammenstecken.

Natürlich ist das auch abhängig von der Art der Software, die man entwickelt, für welche Firma man entwickelt und wie die Rahmenbedingungen aussehen. In meinen Erfahrungen zeigte es sich oft so: Man steht vor einen riesigen Aufgabe, der man aufgrund fehlender Resourcen (sei es Wissen, Zeit oder die Teamgröße) als nicht lösbar erachtet. In einigen Fällen wird man diese Aufgabe komplett ablehnen, in einigen Fällen wird man sich für eine leichtgewichtige Version entscheiden, die nur einen Teil der gestellten Aufgabe abbildet und in einigen Fällen wird man anfangen zu entwickeln und am Ende kläglich an den hohen Anforderungen scheitern.

Der oft einfachste Weg solche Aufgaben ohne Probleme mit den gegebenen Resourcen lösen zu können ist die Nutzung von OpenSource Frameworks. Für beinahe jede Aufgabe gibt es bereits eine angemessene Lösung beziehungsweise eine unterstützende Komponente, die es dem Entwicklerteam ermöglicht sich auf das wichtige konzentrieren.

Ich möchte fünf Beispiele nennen, in denen mir und meinem Team ein oder mehrere OpenSource Produkte halfen Problemlösungen zu entwickeln, für die man normalerweise weitaus mehr Zeit und Manpower benötigen würde.

Beispiel 1: Implementierung einer flexiblen Enterprise-Datenbanksuche für ein bestehendes PHP-MySQL System

Das Problem: Wir hatten es mit einer sehr großen, absolut unperformanten MySQL - Datenbanklösung zu tun: Ein Verbund von ca. 200 Tabellen mit bis zu 18 Mio Einträgen und jeweils 50 Feldern. Die Tabellen sind weder normalisiert noch auf Feldebene optimiert. Suchanfragen können ausschließlich über zwei statische Hash-Werte durchgeführt werden. Jede andere Suchanfrage legt die Datenbank für mehrere Minuten lahm. Dieser Zustand war für den Bestand des Gesamtsystems inakzeptabel, ein komplettes Re-Design der Lösung jedoch aus Kostengründen nicht möglich. Aufgrund der hohen Komplexität des Systems spielt hier auch das Risiko des Unverhersehbaren eine bestimmte Rolle. Des weiteren musste berücksichtigt werden, dass das gesamte Restsystem, in dem Datenbankzugriffe stattfinden, in PHP programmiert wurde. Was tun?

Die Lösung: Lesende Anfragen sollen von der Datenbank gelöst werden. Im gleichen Atemzug sollen Suchanfragenunschärfen zulassen und idealerweise schnell sein, die Datenbank aber nicht weiter belasten. Nach langem überlegen und planen, nach dem Ausschluss diverser zunächst vielversprechender dann aber nicht tauglicher Alternativen sind wir auf eine Lösung gestoßen:

Apache Lucene Solr

Apache Solr. Dabei handelt es sich um einen auf Lucene basierenden Enterprise Suchserver. Durch dieses Produkt konnten wir unsere Ziele allesamt erreichen und benötigten dafür geradeeinmal 2 Entwickler, die drei Wochen an der Integration arbeiteten. Solr erlaubt es anhand einer Webserviceähnlichen Schnittstelle über HTTP Anfragen zu stellen und die flexible Konfiguration der Indexstruktur. Wir haben eine auf Suchanfragen optimierte Struktur geschaffen, und damit die gesamte Datenbankstruktur auf Solr abgebildet. Die Aktualität des Index wird gewährleistet indem wir mit Hilfe von Triggern eine Update Tabelle füllen, die in lurzen Zeitabständen ausgelesen und auf den Index übertragen wird. Um doppelte Datenhaltung zu vermeiden und die Einhaltung der Datenschutzrichtlinien zu gewährleisten sind im Index ausschließlich die Primärschlüssel der Suchergebnisse gespeichert. Im bestehenden System mussten alle lesenden Prozesse durch Anfrage an den Solr-Server abgelöst werden. Mit den Ergebnislisten werden dann die Daten aus der Datenbank geholt. Eine Suchanfrage, für die man bisher ca. 20 Minuten benötigte dauert heute nur noch 0,1 Sekunde. Wir können komplexe Auswertungen erstellen und flexibel auf spezielle Datenbankanfragen von Kunden reagieren. Der größte Vorteil von Solr aber ist seine Unabhängigkeit. Das System, in dem die Suche integriert werden musste, war in PHP geschrieben. Die standardisierte HTTP Schnittstelle, die es erlaubt neben XML auch JSON oder HTML als Ergebnis zu erhalten erlaubte es uns den Dienst separat auf einem eigenen Server aufzubauen und dann einfach über einen HTTPClient einzubinden.

Beispiel 2: Implementierung eines Text-Analyse-Systems zur Extraktion und Überführung von strukturieren Daten aus Freitexten in eine relationale Datenbank.

Das Problem: Bestimmte Prozessentscheidungen beim Kunden erfordern die Einbeziehung srukturierter Informationen, die lediglich in Textform vorliegen. Der manuelle Aufwand der Strukturierung dieser Texte ist allerdings so enorm, dass der Einsatz der Daten sehr teuer ist. Die Implementierung eines Text-Information-Retrieval Systems, welches die Strukturierung automatisiert wäre für ein kleines Team von ca. 10 Programmierern kaum durchfürbar. Eine einfache Lösung ist für die Komplexität der Texte und der Vielfältigkeit der zu strukturierenden Informationen kaum denknar.

Die Lösung: Von der Universität Sheffield wird ein OpenSource System angeboten, welches genau diese Aufgabe lösen kann. GATE.

Hierbei handelt es sich um ein Framework zum einlesen und verarbeiten textueller Information. Neben des eigentlichen Prozessframeworks besteht GATE aus zahlreichen Plugins verschiedener Anbieter, die zu diversen Zwecken eingesetzt werden können. Die wichtigsten GATE Plugins sind unter ANNIE (A Nearly-New Iniformation Extraction system) zusammengefasst. Für unsere Aufgabe haben uns insbesondere zwei Mechanismen geholfen: Der JAPE-Transducer und der sogenannte Gazetteer. Grundlegend ist GATE aus Sprachresourcen (LR) und Processing Resources (PR) aufgebaut. Letztere werden in Pipelines beliebig zusammengebaut und verarbeiten genannte Sprachresourcen (Dokumente bzw. Korpora). Die Inhalte eines Dokuments werden entlang der Processing Pipeline annotiert.

Der Gazetteer fügt Named Entity Annotationen zum Text hinzu. Dazu haben wir diverse Lookupdatenbanken aufgebaut: Vornamen, Nachnamen, Städte, Postleitzahlen, Bundesländer, Rechtsformen, Toplevel Domains etc. Diese Annotationen wiederum werden in diversen JAPE Regeln in ihren Kontexten betrachtet, so dass man auf den Inhalt und Zweck der Daten schließen kann.

Die so ermittelten Daten werden analysiert und rückwirkend auf ihre Qualität bewertet.

Das Ergebnis: Wir können in weniger als 20 Minuten 4000 Dokumente einlesen, auswerten, strukturieren und in einer Datenbank speichern. Aufgrund bestimmter Muster lassen sich sichere von unsicheren Strukurierungen trennen. Unsichere Ergebnisse werden in einem manuellen Prozess nachgeprüft und ggf. angepasst, so dass wir insgesamt eine 100%ige Erkennunsrate erreichen.

Leidenschaft ist eine der in meinen Augen wichtigsten Fähigkeiten, die ein Entwickler mitbringen sollte. Leidenschaft für Technologie, Leidenschaft für Lösungen, Leidenschaft für Fortschritt. Mike Peters hat dies kürzlich in seinem Artikel “How to pick a GREAT Software Engineer” eindrucksvoll präzise verdeutlicht. Er schreibt, dass sich “passionierte Entwickler” besonders dadurch auszeichnen, dass Sie in Ihrer Freizeit DZone oder Techcrunch lesen, neue Software testen oder Code schreiben:

Love what you do and pass that love to everyone you deal with.

Always be positive, energetic and make progress, no matter what.

What do you do in your spare time? If you’re not writing code, installing a virtual machine, reading TechCrunch/Slashdot/DZone or testing out the latest version of Windows 7, you are not passionate about technology.

Ich stimme ihm prinzipiell zu. Natürlich gibt es wichtigere Dinge als Technologie (Familie, Freunde, Gesundheit etc.), aber ich denke, dass Passion in diesem Zusammenhang einfach heißt, dass Technologie nicht einfach nur der Job ist, sondern ein Hobby, ein Hobby welches man glücklicherweise zum Job machen konnte. Und wie das so ist mit Hobbies: Sie bestimmen den Charakter, das alltägliche Handeln und sind allgegenwärtig. Vielleicht kann man es so sagen:

Ein Triathlet, ein Fussballfan und ein Technologist (um einen Begriff  zu nutzen, der die Leidenschaft besser als die Berufsbezeichnung Sofwareentwickler ausdrückt) machen Strandurlaub mit ihren Kindern und Ehefrauen. Der Triathlet wird, während die Kinder im Meer baden und die Frau sich der Sonne hingibt, seine Beine in die Hand nehmen und am Strand ein paar Kilometer laufen gehen. Der Fussballfan wird sich am Wochenende in Zeitungen, bei anderen Urlaubern oder im Internet über die Ergebnisse seiner Lieblingsmannschaft erkundigen. Und so wird sich der Technologist genüsslich mit einem Buch über Technologie an den Strand legen (letztes Jahr in Südafrika begleitete mich das Buch: The Big Switch von Nicholas Carr) oder sogar den Laptop dabei haben um am Abend, wenn die Familie schläft auf dem Balkon mit Meerblick die wichtigsten Blogs zu verfolgen und vielleicht sogar kurz Eclipse zu starten um das Tutorial für ein ihm noch unbekanntes Framework oder SDK durchzugehen. Alle drei werden mit solchen Tätigkeiten ganz ähnliche Erfahrungen machen: Sie selbst empfinden dabei eine persönliche, subjektive, intrinsisch motivierte Zufriedenheit wobei Freunde oder der Partner nur schwer nachvollziehen können, wie man sich so für etwas anscheinend unwichtiges begeistern kann. Die Frage nach dem Sinn stellt sich dem Triathleten, dem Fussballfan und dem Technologist aber erst als zweites. Und speziell dem Technologist ist es zunächst auch egal ob man Geld damit verdienen kann: Es ist eher ein netter Seiteneffekt.

Um zu dem oben angesprochenen Artikel zurückzukommen. Ich denke, dass es in der Software-Entwicklung sehr wichtig ist passioniert zu sein. Ich selbst habe die Erfahrung gemacht, dass zu viele Entwickler mit denen ich zusammengearbeitet habe, ihren Job tatsächlich als 9to5 Job verstanden. Man kann Projektziele erreichen und durchaus schöne Systeme implementieren. Aber eines fehlt: Spaß und innovatives Potential. Man bleibt auf der Stelle stehen.