Hallo! Mein Name ist Roger Braun und ich bin Entwickler, Japanologe, Übersetzer, Podcaster, Karaokesänger, Serveradministrator und noch manches mehr. Ich bin mit meinem Studium der Japanologie und Informatik ein halb geistes-, halb naturwissenschaftliches Wesen und hoffe zur Zusammenarbeit zwischen den beiden beitragen zu können. Der Schwerpunkt der meisten meiner Projekte liegt darin, Nutzern einen leichten Zugang zu ihnen vorher nur schwer zugänglichen Daten zu schaffen.

Ich bin seit einigen Jahren zusätzlich zu meinem Studium freischaffender Entwickler. Mein Interesse gilt allen Technologien, die eine agile und reaktive Entwicklung ermöglichen, um dem Nutzer einen möglichst barrierenfreien Zugang zu seinen Interessen zu schaffen. Insbesondere sind dies in letzter Zeit Ruby, Rails, HTML5, Javascript, Apps und verwandte Technologien. Besonders gerne entwickle ich mit funktionalen Techniken und TDD.

Die obligatorische Auflistung der von mir verwendeten Programmiersprachen und Technologien folgt. Zusätzlich stelle ich aber einige meiner größeren und kleineren Projekte vor. Bei allen gibt es eine Beschreibung der Projektentstehung, der verwendeten Software und der Probleme und Herausforderungen. Bei den meisten gibt es auch einen Link zum Code auf GitHub. Ich hoffe, das man so einen guten Eindruck meiner Arbeit gewinnen kann. Und wenn ihnen meine Arbeit gefällt: Schreiben sie mir eine Mail!

Kontakt

Am schnellsten erreicht man mich über Email oder Twitter. Mein Code liegt größtenteils auf GitHub. Ich schreibe ein eher technisches Blog und mache mit Freunden einen eher lustigen Podcast.

Lebensdaten

• Grundlegendes
• Name: Roger Braun
• Geburtsort: Bonn
• Geburtsdatum: 22.11.1984
• Nationalität: Deutsch
• Wohnort: Tübingen
• Familienstand: Ledig, eine Freundin, zwei Katzen
• Studium
• seit 2005: Magister Japanologie/Informatik an der Eberhard-Karls-Universität Tübingen
• 2007/2008: Ein Semester Auslandsaufenthalt an der Doshisha-Universität in Kyoto
• 2013: Voraussichtlicher Abschluss

Fähigkeiten

Meine Kenntnisse und Fähigkeiten auf einen Blick.

Meine größeren Projekte, mit ausführlicher Beschreibung. Bei Projekten mit offenem Quellcode ist dieser verlinkt.

WaDoku.eu

Ein laufendes Projekt des WaDoku e.V. Das offizielle Web-Interface zum größten japanisch-deutschen Wörterbuch. Start des Projektes war 2011.

Quellcode

• WaDokuWeb: Das ursprüngliche Rails-Projekt.
• WaDokuAPI, WaDokuClient: Die aktuelle Version, getrennt in API-Server und Client. Der Client ist beinahe vollständig in Javascript implementiert.

Mein Beitrag

Ich war und bin verantwortlich für jeden Aspekt der Entwicklung der Software und der Pflege des Servers. Alle drei Systeme (WaDokuWeb, WaDokuAPI, WaDokuClient) sind vollständig von mir konzipiert und entwickelt worden.

Videoeinführung

Projektgeschichte

Das japanisch-deutsche Wörterbuch WaDokuJT begann als FileMaker-Datenbank, die von Ulrich Apel erstellt und gepflegt wurde. Ursprünglich wurde es auch als FileMaker-Datei bzw. als Runtime-Version derselben veröffentlicht. Mit der zunehmenden Popularität webbasierter Wörterbücher wurde jedoch klar, dass auch WaDokuJT in einer Onlinevariante verfügbar sein muss. Thomas Latka entwickelte daher in Zusammenarbeit mit Ulrich Apel die Webseite wadoku.de, die eine einfache Suche ermöglicht.

Mit der Zeit erweiterte sich jedoch der Umfang des WaDokuJT stark, so dass es nun nicht nur 250.000 Einträge erfasst, sondern auch SVG-Schaubilder und MP3-Aussprachebeispiele. Ebenso gibt es Querverweise zu anderen Wörterbüchern, Wikipedia, Firmenhomepages etc. Diese wurden und werden von wadoku.de nur teilweise verwendet. Auch die Darstellung der Einträge ist für einen Lexikologen teilweise unbefriedigend.

Um den Stillstand zu beenden wurde 2011 das WaDoku.eu-Projekt ins Leben gerufen. Es soll ein modernes Webinterface für WaDokuJT darstellen, das alle Inhalte des Wörterbuchs über das Web zur Verfügung stellen soll. Ein weiterer Wunsch war die Bereitstellung eines API, über die andere Projekte auf den jeweils aktuellen Datensatz von WaDokuJT zugreifen können, ohne selbst die Daten vorhalten und synchronisieren zu müssen.

Die erste Version, WaDokuWeb, wurde in Rails implementiert. Die Suche wurde mit Picky realisiert. Der größte Teil der anfänglichen Entwicklungszeit musste jedoch für das Parsing das WaDokuJT-Markups aufgewendet werden. Hierzu würde ein PEG-Parser implementiert und laufend mit TDD erweitert.

Die aktuelle Version ist geteilt in einen API-Server, der den Suchserver beinhaltet und einen reinen Client. Der Client lädt seine Daten über die API vom Server und zeigt sie entsprechend aufbereitet an. Durch die Trennung soll eine höhere Modularität und eine Verbesserung der API erreicht werden, da die API nun immer das erste ist, was implementiert wird. Dem aktuellen Client fehlen noch ein paar Funktionen des Rails-Servers, die in naher Zukunft nachimplementiert werden sollen. Weitere Client-Anwendungen wie Browser-Extensions, Bookmarklets und Apps sind in Planung und können durch die API leicht umgesetzt werden.

Technische Herausforderungen

• Das Parsen der Einträge in einen abstrakten Syntaxbaum war anfangs das größte Problem. Das WaDokuJT-Markup ist im Laufe der Jahre entstanden, es gibt keine Definition außer den Daten selbst. Der Entwicklungsprozess lief wie folgt ab:
  • Finden eines nicht-parsenden Eintrags.
  • Erstellen eines Testfalls mit diesem Eintrag.
  • Erweitern der Grammatik, bis der Testfall ebenfalls parsed.
  • Und von vorne...
  Ursprünglich wurde Citrus für den Parser verwendet, nach einiger Zeit wurde aber zu Parslet gewechselt, dass wesentlich einfacher zu verwenden war. Parslet trennt die Parsing-Phase von der Übersetzung in Ausgabeformate (HTML, Plain Text, usw...), was die Programmierung deutlich erleichtert. Zur Zeit parsen ca. 97% der Einträge.
• Zur Vereinfachung der Oberfläche wurde endloses Scrolling in Javascript implementiert. Die Seite lädt neue Einträge nach, sobald der User nach unten gescrollt hat. In der Rails-Version holte sich die Funktion die Daten vom Rails-Server über AJAX, in der aktuellen Version bekommt die Funktion die Daten direkt vom API-Server über einen JSONP-Request.

• Ein Wunsch war es, die Darstellung wörterbuchartiger zu gestalten und den Bildschirmplatz besser auszunutzen. Daher wurde eine zweispaltige Darstellung implementiert. Leider waren (und sind) die CSS-Möglichkeiten für ein balanciertes, zweispaltiges Layout nicht optimal. Daher werden die zwei Spalten vom Server erstellt (WaDokuWeb) bzw. von Javascript (WaDokuClient).

  Auf dem Server wurde dabei die Textlänge der Einträge zur Balancierung genutzt, was aber Probleme bei der Verwendung von Bildern oder verschiedenen Schriftgrößen verursachen kann. Immerhin konnten die beiden Spalten dadurch ungefähr balanciert werden.

  In der neuen Version wird zuerst eine einzige Spalte erstellt, die dann von einem einfachen Algorithmus per Javascript in zwei ungefähr gleich hohe Spalten eingeteilt wird. Das Padding der Einträge in der kleineren Spalte wird danach so erhöht, das beide Spalten im Ergebnis die selbe Höhe haben. Dieser Ansatz funktioniert deutlich besser und liefert gute Ergebnisse, erfordert aber Javascript.

Zenodotos

Zenodotos ist ein Online-Katalog, ein Nutzerverwaltungs- und ein Ausleihsystem für Bibliotheken. Es wurde für die Japanologie Tübingen entwickelt und ersetzte dort ein bestehendes FileMaker-basiertes System. Projektzeitraum war 2010~2012.

Quellcode

• Zenodotos, Zenodotos-Picky-Server: Die Rails-Anwendung und der zugehörige Picky-Server.

Mein Beitrag

Alle Projektbestandteile wurden vollständig von mir durchgeführt. Dazu gehören:

• Analyse der alten Datenbank (FileMaker).
• Erstellen der MySQL-Version, Import der alten Daten.
• Einrichtung des Servers.
• Programmierung des neuen Systems, Import der Daten aus der MySQL-Datenbank.
• Schulung der Bibliothekskräfte.

Projektgeschichte

Das Büchereisystem der Japanologie Tübingen basierte bis vor kurzem noch auf einer FileMaker-Datenbank. Dies hatte historische Gründe, da FileMaker die erste Endnutzer-Datenbank war, die eine halbwegs ordentliche Unterstützung für gemischt westlich-japanische Einträge bieten konnte. Etliche gewünschte Funktionen ließen sich jedoch mit FileMaker nicht oder nur sehr schwer umsetzen. Beispiele:

• Eine Online-Katalogfunktion war nur durch manuellen Export und Import möglich. Der Online-Katalog war daher nur so aktuell wie der letzte Export, und daher meist einen Monat oder mehr hinterher.
• Dadurch war es unmöglich dem Nutzer anzuzeigen, ob ein Buch gerade entleihbar war oder nicht.
• Da alle Felder reine Textfelder ohne Validierung waren, war die Datenbank in einem inkonsistenten Zustand. So gab es etwa mehrere verschiedene Datumsformate im selben Feld. Eine nachträgliche Validierung hätte viel manuelle Arbeit bei der Konsolidierung der Daten erfordert.
• Da der aktuelle Entleiher nur mit seinem Namen über ein Feld im Bucheintrag selbst referenziert war, verschwand diese Information bei Rückgabe des Buches. Es war also unmöglich zu sagen, ob ein Nutzer ein Buch bereits ausgeliehen hatte, wie oft er überzogen hatte usw.

Das bestehende System wurde in drei Schritten durch den neu entwickelten Katalog ersetzt:

1. Export der Daten in eine MySQL-Datenbank. Gleichzeitig wurden mehrdeutige Felder (etwa Datum) möglichst vollständig automatisch umgewandelt. Der Rest wurde von Hand korrigiert. Das resultierende Datenbankschema nutzte im Gegensatz zur FileMaker-Datenbank die verschiedenen vorhanden Typen und Validierungsmöglichkeiten aus und sorgte so bereits für eine höhere Konsistenz der Daten. Die MySQL-Datenbank wurde als externes Backend für FileMaker konfiguriert, so dass die Bibliotheksmitarbeiter ohne Änderung weiter arbeiten konnten.
2. Implementierung des Zenodotos-Systems und einer Import-Funktion für die bestehenden Daten. Beim Import wurde insbesondere darauf geachtet, inkonsistente oder mehrdeutige Daten verlustfrei zu importieren. So wurde etwa aus dem "Ausleiher"-Feld in Zenodotos ein eigenständiges Modell, dass eine Relation zwischen Entleiher und Buch repräsentiert. So können später alle Leihvorgänge aller Nutzer nachvollzogen werden.
3. Einrichtung des Systems, Import der alten Daten, kurze Schulung der Mitarbeiter und Umstellung auf das neue Bibliothekssystem.

Little Snake vs. the almighty dinosaur kingdom

Litte Snake vs. The Almighty Dinosaur Kingdom ist eine moderne Variante des bekannten Snake-Spiels mit bunter Grafik, Musik, Story und einem Combosystem. Das Spiel ist in ActionScript implementiert und verfügbar auf iOS, Android und Facebook. Der Projektzeitraum war das letzte Quartal 2012.

Homepage

• Homepage
• Pressekit

Mein Beitrag

Ich war als leitender Programmierer tätig. Bestandteile meiner Arbeit waren:

• Evaluierung der möglichen Basistechnologien
• Entwurf und Implementierung der Spieleengine
• Entwurf und Implementierung des Levelsystems
• Entwurf und Implementierung der Leaderboards
• Portierung nach Android, Facebook (Flash)
• Musik im Arcade-Modus
• Optimierung der Performance

Trailer

Projektgeschichte

Little Snake entstand aus einigen Experimenten mit HTML5-Javascript-Spielen. Wir (Dinomite Rexploitation Games) entschlossen uns, ein modernes Snake-Spiel für iOS zu entwickeln. Als Basis wählten wir Adobes Air, eine Cross-Platform Flash-Umgebung, die uns hardwarebeschleunigte 2D-Grafik auf iOS, Android und PC ermöglichte. Das Spiel wurde Ende 2012 fertiggestellt.

Kurze Zeit später folgte die Android-Version. Eine Facebook-Demo wurde ebenfalls aus der selben Codebasis erstellt.

Dieses Projekt stellt meine längste Erfahrung mit tagtäglicher Teamarbeit dar. Die Arbeit mit verlässlichen und kompetenten Teamkollegen macht mir große Freude und erleichtert die Konzentration ungemein, da man sich nicht mehr um jedes Detail selbst kümmern muss. Die nötigen Kompromisse, die man im Team schließen muss, sind kein Problem. Durch ständige, ehrliche Kommunikation aller Streitfragen konnte immer eine Lösung gefunden werden, mit der alle Teammitglieder zufrieden sein konnten.

Technische Herausforderungen

• Adobe Air wurde von uns gewählt, um eine plattformübergreifende Entwicklung zu ermöglichen. So konnten wir auch mit bestehenden Windows- und Linux-Rechnern für iOS entwickeln. Da Air die tatsächliche Hardware abstrahiert, konnten wir den Großteil der Entwicklung und des Debuggings direkt am Rechner ausführen, ohne zuvor auf die Endgeräte deployen zu müssen. Dies war eine große Zeitersparnis bei der Entwicklung. Der Code läuft außerdem nahezu ohne Änderungen auf allen Plattformen, so dass wir in allen Märkten gleichzeitig mit guter Performance vertreten sein konnten.
• Ein iOS-Gerät wurde erst im Laufe der Entwicklung angeschafft. Davor wurde auf dem Rechner und auf Android-Geräten getestet. Leider erwies sich die Performance auf dem iOS-Gerät als vollkommen unzureichend, was wir auf Probleme mit dem Shader-Code und Ineffizienz in der gewählten Basisengine zurückführen konnten (siehe dieses Issue). Beide Probleme konnten durch einen Wechsel der Basisengine behoben werden. Auch das neue Framework (Starling) musste aber aus Performancegründen von uns angepasst werden
• Das Problem der verschiedenen Displayauflösung und -formate wurde, gleichzeitig mit dem Android-Port, durch selektives Resizen der verschiedenen Schirme im Spiel gelöst. So wird das eigentlich Spiel nicht vergrößert oder verkleinert, sondern mehr oder weniger Spielfeld wird angezeigt. Die Menüs werden jedoch auf Bildschirmgröße gezogen, da hier eine leichte Verzerrung nichts ausmacht. Das Ergebnis ist die volle Ausnutzung der Bildschirmgröße auf allen System, vom iPad bis zum kleinsten Android-Gerät.
• Der Combo-Code wurde mit TDD entwickelt und nutzt reguläre Ausdrücke zur Identifizierung der einzelnen Combo-Varianten.

Zui

Zui ist eine Webanwendung zur gemeinsamen Textübersetzung, insbesondere für japanische Texte. Es integriert Textverwaltung, Kommentare, Wörterbuchzugriff und Ausgabe als PDF. Zui ist das Thema meiner Magisterarbeit. Vorversionen wurden und werden im Unterricht und zur Textübersetzung eingesetzt. Ein mit einer Vorversion übersetztes Buch wird voraussichtlich 2013 erscheinen.

Quellcode

• Zui auf GitHub

Mein Beitrag

Zui und alle Vorversionen wurden vollständig von mir konzipiert und entwickelt.

Videoeinführung

Projektgeschichte

Zui ist mein längstes Projekt und erstreckt sich mit allen Vorversionen inzwischen über 4~5 Jahre. Die Idee zu einem integrierten Web-Übersetzungssystem für den japanologischen Bereich entstand spontan im Unterricht, da ich es als problematisch empfand, dass alle Übersetzungen allein gefertigt wurden, eine Diskussion nur im Unterricht stattfinden konnte und nach dem Kurs alle Übersetzungen in den Müll wanderten.

Daher entstand als erstes eine Art Blog mit japanischen Lesehilfen, zu dem die Kursteilnehmer ihre Übersetzungen und Anmerkungen als Kommentare schreiben konnten. Später folgte dann die Klassifizierung der Kommentare nach Grammatik, Vokabel, Übersetzung...

Das ursprünglich in PHP geschriebene System wurde in Ruby auf Basis von Sinatra neu geschrieben. Neu hinzu kam die Nutzerverwaltung, das "Adoptieren" einzelner Textteile, ein einfaches Translation-Memory-System und die Ausgabe der fertigen Übersetzung als druckfertiges PDF via LaTeX. Mit dieser Variante wurde bisher am meisten gearbeitet, sie war im Unterrichtseinsatz und wird auch für die Übersetzung eines demnächst erscheinenden Buchs genutzt.

Die aktuelle Version ist in Rails implementiert und fügt ein AJAX-basiertes Wörterbuch und eine halbautomatische Glossarfunktion hinzu. Teile der Vorversion sind noch nicht implementiert, etwa fehlt die PDF-Ausgabe.

Technische Herausforderungen

• Die Speicherung der getaggten Übersetzung in einer Datenbank ermöglicht einem viele Ausgabevarianten, etwa als reine Übersetzung oder sogar als Paralleltext. Um dies zu verwirklichen wurde ein LaTeX-basiertes Template-System erstellt, das anhand von einfachen Vorlagen die gewünschte PDF-Ausgabe erstellen kann.
• Zui ist in weiten Teile eine klassische CRUD-Applikation mit Userverwaltung, Upload von Daten, Bearbeitung derselben usw. Allerdings ist der Anwendungszweck, die gemeinsame Übersetzung japanischer Texte, relativ unerschlossen. Durch die hohe Entwicklungsgeschwindgkeit mit Rails und den diversen Rubygems ist es auch für solch kleinere Bereiche möglich, maßgeschneiderte Webanwendungen zu entwickeln.

Die hier aufgeführten Projekte sind meist in wenigen Tagen entstanden. Sie zeigen meine kreative Arbeit.

WaDokuKogo

WaDokuKogo ist ein klassisch-japanisches Onlinewörterbuch. Es basiert auf der Digitalisierung des "Wörterbuch[s] zur altjapanischen Liedersammlung Kokinshū" von Karl Florenz. Eine einfache Sinatra-Anwendung ermöglicht die Verwaltung der Daten und die Suche und Anzeige der Ergebnisse. Das Projekt liegt zur Zeit auf Eis, ist aber schon im derzeitigen Zustand nützlich.

Homepage

• WaDokuKogo

Maxixe

Maxixe ist ein Textsegmentierer, der den Tango-Algorithmus aus dem Paper "Mostly-unsupervised statistical segmentation of Japanese kanji sequences" implementiert. Dadurch kann er beinahe alle Sprachen segmentieren, solange nur ein Textkorpus der nötigen Größen vorhanden ist. Eine längere Erklärung findet sich in meinem Blog. Maxixe ist als Rubygem verfügbar. Aus Zeitgründen wurde es seit Projektbeginn nicht mehr weiterentwickelt.

Quellcode

• Maxixe auf GitHub

Videoeinführung

HNBayes

HNBayes ist eine Implementierung eines naive Bayes classifiers, die vollständig auf Clientseite in Javascript läuft und Artikel auf Hacker News nach wahrscheinlichem Interesse bewertet. Es wird dabei einfach als Bookmarklet auf die Lesezeichenleiste gezogen und muss nicht installiert werden. Gelernte Daten merkt sich HNBayes über das WebStorage API.

Inspiriert wurde es von einem RSS-Feed-Generator für Hacker News, der nach einer manuellen Bewertung einiger Artikel einen maßgeschneiderten RSS-Feed generiert. Eine ausführliche Erklärung findet sich in meinem Blog. Einen Thread auf Hacker News gibt es natürlich auch.

Quellcode

• HNBayes auf GitHub

Codebrawl

Codebrawl ist ein Online-Wettbewerb für Ruby-Programmierer, an dem ich einige Male teilgenommen haben. Die Wettbewerbe bestanden größtenteils aus Bildmanipulationen. Mein Code und meine ausführlichen Kommentare dazu finden sich auf den jeweiligen Wettbewerbsseiten.

Besonders interessant fand ich den Wettbewerb "Selective color with ChunkyPNG", bei dem ein Algorithmus zur selektiven Farbwahl in einem Bild entwickelt werden sollte. Meine Ruby-Lösung gewann den ersten Platz, außerdem portierte ich das ganze auch nach CoffeeScript/Canvas.

Quellcode

• Selective color with ChunkyPNG und die CoffeeScript-Version
• Content-aware image cropping with ChunkyPNG
• Pixelizing images with ChunkyPNG
• Methods taking multiple blocks

In meiner Freizeit arbeite ich gerne an Open-Source-Projekten. Es ist immer schön, die Projekte unterstützen zu können, die einem selbst viel geholfen haben. Meine Beiträge in den folgenden Projekten sind nicht immer besonders groß, aber sie zeigen die Art, wie ich mit anderen entwickeln und Problemlösungen finden möchte. Mein Code ist auch bei den meisten Beispielen einsehbar, da es sich größtenteils um GitHub-Pull-Requests handelt.

Picky

Picky ist eine nahezu vollständig in Ruby implementierte semantische Suchmaschine. Sie ermöglicht die schnelle Suche in strukturierten Daten, wie etwa Adressen, Bibliotheks- oder Wörterbucheinträgen. Mehr Informationen gibt es auf pickyrb.com.

Mein Beitrag

• Japanische Indexe: Die Diagnose der diversen Fehler, die verhinderten, dass Picky ordentlich mit japanischem Text umgehen konnte. Eine gute Dokumentation meines Problemlösungsprozesses, von der ersten Sichtung des Codes über die Diagnose bis zur Lösung.
• SQLite3-Backend, Erweiterung: Die Implementierung eines neuen Backends für Picky. Picky kann die nötigen Indexe in verschiedenen Backends verwalten, etwa direkt im Hauptspeicher oder in Redis. Dieses Backend erweitert Picky um SQLite-Unterstützung.

Project Tegaki

Tegaki ist ein Programm zur Handschriftenerkennung von japanischen oder chinesischen Texten. Es ist das momentan beste freie System dieser Art und unterstützt Mac, Windows und Linux. Mehr Information gibt es auf Tegaki.org.

Mein Beitrag

• Parser für KanjiVG Zeichendaten: Dieser Parser ermöglichst es, die SVG-Zeichendaten des KanjiVG-Projekts als Trainingsdaten für Tegaki zu nutzen. Dazu muss das XML der KanjiVG-Einträge und das darin enthaltene SVG geparsed und in Punktdaten umgewandelt werden. Der Code enthält einen Parser für eine SVG-Untermenge.

Kleinere Bugfixes

Parslet

Parslet ist eine PEG-Parser Bibliothek.

• [0]: Die Diagnose eines echten Fehlers (der Parser funktionierte nicht mit Multibyte-Zeichen) und einer unschönen Ausgabe, sowie Code um die Probleme zu beheben.

Axel

Axel ist eine hardwarebeschleunigte 2D Spieleengine für Adobes Stage3D.

• [0], [1], [2]: Diverse kleine Bugfixes.

Yajl-Ruby

Yajl-Ruby ist das Ruby-Interface für den Yajl-JSON-Parser.

• [0]: Bei der Diagnose des UTF-8-Fehlers von Picky (s.O.) fand ich auch einen Fehler in Yajl-Ruby. Der Code im Pull-Request behebt das Problem.