Ein neues Technology-Projekt im Eclipse Ecosystem

Willkommen EGerrit: Code Reviews mit Eclipse

Dr. Philip Langer, Jonas Helming, Maximilian Kögel
Willkommen EGerrit

© S&S Media

Gerrit ist nicht nur der Vorname eines niederländischen Technikers namens Gerrit Blaauw, der in den frühen 60er-Jahren richtungsweisend an der Entwicklung der Großrechnerarchitektur System/360 bei IBM beteiligt war. Gerrit ist auch der Name eines äußerst populären Code-Review-Systems. Beide teilen sich jedoch nicht nur ihren Namen. Während Gerrit Blaauw den Weg für die 8-Bit-Rechnerarchitektur als Nachfolger der damals vorherrschenden 6-Bit-Architektur ebnete, so hat Gerrit, das Code-Review-System, maßgeblich dazu beigetragen, Code-Review als fixen Bestandteil des Softwareentwicklungsprozesses einzuführen und salonfähig zu machen.

In vielen hochrangigen Softwareprojekten, wie z. B. Android, LibreOffice und Eclipse, ist Gerrit nicht mehr wegzudenken. Das populäre Code-Review-System bietet selbst jedoch „nur“ eine webbasierte Benutzerschnittstelle. Es ist daher wenig überraschend, dass Entwicklerinnen und Entwickler, die die Vorzüge von erstklassigen IDEs wie Eclipse zu schätzen wissen, auch Code-Reviews innerhalb von Eclipse durchführen wollen. Und genau das hat sich EGerrit zum Ziel gesetzt: die nahtlose Eclipse-Integration des kompletten Code-Review-Workflows von Gerrit. EGerrit ist gerade in der Project-Proposal-Phase und kurz davor, als neues Mitglied der Eclipse-Familie geboren zu werden. Grund genug, einen genauen Blick auf die Ziele und Pläne von EGerrit zu werfen und zu erfahren, was von EGerrit zu erwarten ist.

Der Code-Review-Workflow von Gerrit

Bevor wir uns nun ganz EGerrit widmen, wollen wir die Gelegenheit nutzen, um die Funktionsweise von Gerrit selbst sowie dessen Workflow einzuführen. Wenn Sie bereits ein routinierter Gerrit-User sind, können Sie diesen Abschnitt ruhigen Gewissens überspringen.

Im Herzen eines Gerrit-Projekts arbeitet ein zentrales Git-Repository, in dem der Quellcode einer Software lebt. Jede Contribution zu diesem Git-Repository wird von Gerrit in Form eines Reviews verwaltet. Ein Review selbst durchläuft dabei folgende Zustände: Ein neues Review wird mit dem Zustand Needs Code-Review eröffnet, bis die notwendige Zustimmung von typischerweise zumindest einem dazu berechtigten Reviewer vorhanden ist. Ist die Zustimmung gegeben, wechselt der Zustand des Reviews auf Ready to Submit, sodass dessen Contribution in den Entwicklungsbranch des Git-Repositories mittels Git-Merge geschickt werden kann. Der Merge selbst kann dann von dazu berechtigten Entwicklerinnen oder Entwicklern mit einem Knopfdruck in Gerrit durchgeführt werden, wodurch der Zustand des Reviews auf Merged wechselt und der Review geschlossen wird. Selbstverständlich gehen dadurch nicht alle Informationen des Reviews verloren, wie etwa seine Revisionsgeschichte und zugehörige Diskussionen, sondern können zu jedem Zeitpunkt später noch im Sinne der Nachvollziehbarkeit (Traceability) von Codeänderungen abgerufen werden. Sollte die Reviewentscheidung negativ ausfallen, kann der Review von den Entwicklerinnen oder Entwicklern in den Zustand Abandoned verbannt werden.

Abb. 1: Ein offener Review in der Webschnittstelle von Gerrit

Abb. 1: Ein offener Review in der Webschnittstelle von Gerrit

Die Einheit eines Reviews in Gerrit ist immer ein einzelner Git-Commit (Abb. 1). Damit macht sich Gerrit einen mächtigen Mechanismus von Git zu Nutze. Entwicklerinnen und Entwickler können dadurch mit den gewohnten Werkzeugen von Git Codeänderungen in zusammengehörige Einheiten in Form von Commits verpacken. Da jeder Review nur genau einen Commit betrifft, kann Gerrit darüber hinaus auch die Abhängigkeiten zwischen Reviews von den Abhängigkeiten der zugehörigen Commits ableiten (d. h. Vorgänger- und Nachfolgerbeziehungen). Abhängige Reviews werden in Gerrit unter Related Changes in der Webschnittstelle angezeigt (Abb. 1). In diesem Zusammenhang verwendet Gerrit auch einen weiteren Mechanismus von Git. Wenn eine neue Revision einer Codeänderung innerhalb eines Reviews an Gerrit gesendet werden soll, da z. B. Review-Kommentare eingearbeitet wurden, so kann der zugrunde liegende Commit schlicht mit git commit –amend verändert und erneut an Gerrit geschickt werden. Gerrit erkennt aufgrund einer in der Commit Message angeführten Change-Id, dass es sich um eine neue Revision desselben Commits handelt, und hängt diesen daher an den bereits bestehenden Review an. Selbstverständlich hat eine Veränderung des Commits einen Einfluss auf alle womöglich existierenden nachfolgenden Commits und deren Reviews. In Gerrit hat man dieses Problem elegant über die Verwendung von git rebase gelöst, sodass Entwicklerinnen und Entwickler damit abhängige Reviews mit einem Klick auf die neue Version von Vorgängerreviews umschreiben können. Sollte ein Rebase aufgrund von Konflikten mit Änderungen in Vorgänger-Commits oder bereits in den Entwicklungsbranch integrierten Commits nicht möglich sein, wird dies in der Gerrit-Webschnittstelle angezeigt (siehe Cannot Merge in Abb. 1).

Abb. 2: Der Workflow eines Code-Reviews in Gerrit

Abb. 2: Der Workflow eines Code-Reviews in Gerrit

Der zugrunde liegende Workflow eines Codereviews in Gerrit ist in Abbildung 2 dargestellt und beginnt damit, dass eine Entwicklerin oder ein Entwickler das zentrale, von Gerrit verwaltete Git Repository klont (1) oder die aktuelle Version über git pull holt und die gewünschten Änderungen an der Codebasis vornimmt. Sobald die Änderungen bereit für das Review sind, werden diese zuerst in ein oder mehrere Commits gepackt (2). Dies geschieht üblicherweise innerhalb eines lokalen Branches (featureX in Abb. 2), um die Änderungen von anderen parallelen Änderungen zu isolieren. Um nun ein Review für Commits zu eröffnen, werden die Commits schlicht über git push <gerrit-remote> an Gerrit geschickt (3). Gerrit agiert hierfür wie ein ganz normales Remote-Repository, nur dass für jeden neuen Commit ein neues Review eröffnet wird. Nun liegt der Ball bei den Reviewern, die die Codeänderungen nun entweder direkt im Browser begutachten oder den gesamten Commit in das lokale Dateisystem ziehen können (4). Gerrit stellt hierfür spezielle „Git-Refs“ für jedes Review und jede Revision der Codeänderungen innerhalb eines Reviews zur Verfügung, sodass der Commit beispielsweise über git fetch <gerrit-remote> refs/changes/<change-id>/<revision-id> bezogen werden kann.

Abb. 3: Diff Viewer mit Kommentarfunktion in der Gerrit-Webschnittstelle

Abb. 3: Diff Viewer mit Kommentarfunktion in der Gerrit-Webschnittstelle

Im Zuge eines Reviews können Reviewer nicht nur ein Gesamtrating geben (5), sondern die Änderungen auch auf Zeilenebene kommentieren, um beispielsweise Feedback für eine erneute Überarbeitung der Codeänderungen zu geben (Abb. 3). Sobald das Review in Form von Zeilenkommentaren und eines Ratings über die Webschnittstelle hochgeladen wurde, wird die Autorin oder der Autor der Codeänderung benachrichtigt und kann nun – abhängig von der Entscheidung der Reviewer – entweder das positive Feedback genießen und sich auf den Merge seiner Contribution freuen oder, und das ist der häufigere Fall, mit der Einarbeitung des Reviewer-Feedbacks beginnen. Wenn die Überarbeitung der Änderungen abgeschlossen ist, kann die neue Version der Codeänderungen an den Review angehängt werden, indem der ursprüngliche Commit über git commit –amend verändert und an Gerrit geschickt wird, sodass der Reviewprozess von Neuem beginnen kann (Schritte (3) – (6)).

Gerrit bietet ein weiteres nützliches Feature, das die Arbeit der Reviewer maßgeblich erleichtert. Gerrit kann Continuous-Integration-Server integrieren und automatisch einen neuen Build inklusive automatische Tests für jedes neue Review sowie jede neue Revision innerhalb eines Reviews anstoßen und das Ergebnis in den Review einbinden (7). Der Continuous-Integration-Server agiert damit als eine Art automatisierter Reviewer, der die Änderungen vorab verifiziert.

Bevor Gerrit den Merge eines Reviews zulässt, muss in der Standardkonfiguration das Votum mindestens eines Reviewers mit +2 ausfallen, und es darf keinen weiteren Reviewer geben, der gegen die Codeänderung mit -2 gestimmt hat. Stimmen, die dazwischen liegen, d. h. -1, 0 und +1, dienen nur dazu, Meinungen kundzutun, haben aber keine Auswirkung darauf, ob ein Merge von Gerrit letztlich zugelassen wird. Sind die notwendigen Kriterien für einen Merge erfüllt, kann der Merge mit nur einem Mausklick in Gerrits Webschnittstelle durchgeführt werden (8).

Die Beweggründe für EGerrit

Die Webschnittstelle von Gerrit ist ohne Frage nützlich. Es gibt jedoch eine Reihe an guten Gründen, die für eine nahtlose Integration von Gerrit in Eclipse sprechen und nahelegen, dass eine solche Integration das Leben von Entwicklerinnen und Entwicklern erleichtert, egal ob in der Rolle eines Reviewers oder Contributors. Das wohl stärkste Argument ist, dass es für das Lesen und die Analyse von Code schlichtweg nichts Besseres gibt als die erstklassige IDE, mit der wir täglich arbeiten. Syntax-Highlighting, Codenavigation, wie etwa auf Knopfdruck zu verwendeten Klassen oder Methoden zu springen, Problemmarker und viele andere Features der Eclipse-IDE sind genauso wertvoll beim Durchführen von Codereviews, wie sie für die Softwareentwicklung selbst sind. Außerdem ist es als Reviewer oft notwendig, den veränderten Code im Debugging-Modus schrittweise auszuführen oder Ad-hoc-Tests durchzuführen. All dies ist in der Eclipse-IDE – im Gegensatz zu Gerrits Webschnittstelle – ohne Umwege möglich. Natürlich kann man den Commit eines Reviews in das lokale Repository ziehen, in Eclipse öffnen und nur das Ergebnis des Reviews im Webbrowser eintragen. Das ständige hin und herwechseln zwischen der IDE und Gerrit im Webbrowser, um beispielsweise Kommentare zu speziellen Codeänderungen hinzuzufügen, ist jedoch alles andere als angenehm und effizient. EGerrit ist daher das natürliche Komplement zu Gerrits Webschnittstelle und hat das Potenzial, die Effizienz der Reviewer, vor allem wenn diese bereits zufriedene Eclipse-User sind, erheblich zu steigern. EGerrit hat es sich daher zum ambitionierten Ziel gemacht, das gesamte Funktionsspektrum der Webschnittstelle von Gerrit innerhalb von Eclipse anzubieten.

In diesem Zusammenhang darf selbstverständlich die Gerrit-Integration von Mylyn Reviews, ein Teilprojekt des populären Top-Level-Projekts Mylyn, nicht unerwähnt bleiben. Mit Mylyn Reviews können bereits gewisse Teile des zuvor genannten Workflows von Gerrit innerhalb von Eclipse durchgeführt werden. Warum wird dann ein weiteres Eclipse-Projekt mit teils überlappenden Zielen gestartet? Zuallererst ist natürlich Diversität und ein gesundes Maß an Alternativen ein wichtiger Bestandteil der freien Softwarebewegung („free as in speech“); und Diversität ist unter anderem auch das, was Open Source interessant und spannend macht. Mylyn ist großartig, und auch Mylyn Reviews mit seinem Connector für Gerrit erleichtert die Durchführung von Gerrit-Reviews in Eclipse erheblich. Mit Mylyn Reviews wurde eine Reihe an Plug-ins in Mylyns Softwarefamilie eingebettet, die generischen – d. h. von der eigentlich Codereviewsoftware unabhängigen – Support für Codereviews zur Verfügung gestellt. Auf Basis dieser generischen Grundlage liefert Mylyn Reviews auch eine Implementierung dieses Rahmenwerks für Gerrit aus. Im Gegensatz dazu will sich EGerrit ausschließlich der Gerrit-Integration widmen und letztlich das gesamte Funktionsspektrum von Gerrits Webschnittstelle innerhalb von Eclipse unterstützen. Auch wenn generischer Support und die Möglichkeit, in Zukunft auch weitere Codereviewsoftware zu unterstützen, etwas Gutes ist, ist es jedoch nachvollziehbar, dass die Entwicklung einer erstklassigen Eclipse-Integration von Gerrit an sich schon ausreichend anspruchsvoll ist – auch ohne sich dabei zusätzlich noch über die Entwicklung und die Einbettung in ein generisches Rahmenwerk Sorgen machen zu müssen. Schließlich ist auch das Ziel von EGerrit, nämlich die Unterstützung des vollen Funktionsumfangs von Gerrit in Eclipse zu realisieren, in vielerlei Hinsicht inkompatibel zu dem Ziel, ein generisches Rahmenwerk zur Verfügung zu stellen, wie es von Mylyn verfolgt wird. Demzufolge will sich EGerrit exklusiv der Eclipse-Integration von Gerrit zuwenden und – vergleichbar mit EGit (ein Projekt, das sich ausschließlich um die Integration von Git kümmert) – die Aufmerksamkeit auf jene Gerrit-spezifischen Schnittstellen, Features und Workflows richten, die Gerrit so populär gemacht haben wie es heute ist.

Was dürfen wir von EGerrit erwarten?

EGerrit hat das ambitionierte Ziel, den vollen Funktionsumfang der Webschnittstelle von Gerrit ab Version 2.9 zu unterstützen. Dabei will EGerrit ebenso Gerrit-Neulinge, die erfahrene Eclipse-User sind, als auch Eclipse-Neulinge, die bereits Erfahrung mit Gerrit haben, für sich gewinnen. EGerrit konzentriert sich vorrangig auf die Bedürfnisse von Entwicklerinnen und Entwicklern in ihrer täglichen Arbeit mit Gerrit und hat es sich zum Ziel gemacht, deren Produktivität bei Codereviews durch eine nahtlose Eclipse-Integration zu optimieren. Administrative Aufgaben, wie etwa die Verwaltung von Gerrit-Projekten, werden vorerst hinten angestellt, da die Integration derartiger Aufgaben in Eclipse nur begrenzten Mehrwert im Vergleich zu Gerrits Webschnittstelle liefern würde.

Abb. 4a: Mockups des Change Viewers von EGerrit

Abb. 4a: Mockups des Change Viewers von EGerrit

Abb. 4b: Mockups des Dashboards von EGerrit

Abb. 4b: Mockups des Dashboards von EGerrit

Aus der Anwendersicht besteht EGerrit aus einem speziellen Change Viewer (Abb. 4a) und dem Gerrit Dashboard (Abb. 4b). Das Dashboard von EGerrit ist eine direkte Eclipse-Integration des Dashboards, das auch in Gerrits Webschnittstelle verfügbar ist, und erlaubt es daher, Benutzerinnen und Benutzer einen Ausschnitt an Reviews von aktuellem Interesse übersichtlich darzustellen. Um den Ausschnitt an angezeigten Reviews auszuwählen, wird EGerrit dieselbe Abfragesprache unterstützen, die auch in Gerrit zur Verfügung steht. Beispielsweise liefert status:open (reviewer:self OR owner:self) alle offenen Reviews, bei denen Sie entweder selbst Reviewer sind oder deren Contribution Sie selbst verfasst haben. Selbstverständlich wird über einen Doppelklick auf einen Review im Dashboard der jeweilige Review in EGerrits Change Viewer geöffnet.

Der Change Viewer selbst strukturiert alle Details eines Reviews in vier Reitern: Summary, Message, Files und History. Der Reiter Summary liefert alle relevanten Metainformationen zu einem Review auf einen Blick, wie etwa den aktuellen Status des Reviews (z. B. Needs Codereview), das Projekt und den Ziel-Branch, die eingetragenen Reviewer und deren bereits abgegebene Stimmen sowie Abhängigkeiten zu anderen Reviews und Reviews, mit denen der angezeigte Review in Konflikt steht. Abhängig vom Status des Reviews können über den Change Viewer Aktionen gestartet werden, um beispielsweise den Review abzuschicken (Submit) oder zu verwerfen (Abandon), auszuchecken (Checkout) oder einen Cherry-Pick der Änderung auf den lokalen Workspace mit einem Klick durchzuführen (Cherry-Pick). Selbstverständlich werden diese Aktionen nach Möglichkeit mit den Benutzerschnittstellen von EGit integriert. Der Reiter Message zeigt die Nachricht des zugehörigen Commits und erlaubt es, diese direkt zu ändern.

Abb. 5: Mockup des Diff Viewers von EGerrit

Abb. 5: Mockup des Diff Viewers von EGerrit

Der Reiter Files ist zweifelsohne eines der wichtigsten Teile des Change Viewer, da er die Liste der veränderten Dateien innerhalb eines Reviews anzeigt und mittels eines speziellen Diff Viewers auch die Änderungen innerhalb der veränderten Dateien feingranular darstellen kann. Das EGerrit-Team hat für diesen Diff Viewer Großes vor und will damit einige sehr beliebte Features des Diff Viewers von Gerrits Webschnittstelle in die Eclipse-IDE bringen. Zum Beispiel soll EGerrits Diff Viewer die nach Zeilen ausgerichtete Darstellung der Änderungen anbieten. Anstatt korrespondierende Textblöcke mit Linien zwischen der linken und rechten Seite zu kennzeichnen, wie es der klassische Diff Viewer in Eclipse heute macht, soll der Diff Viewer in EGerrit, wie auch in Gerrits Webschnittstelle, korrespondierende Zeilen horizontal mithilfe von leeren Platzhalterzeilen zueinander ausrichten (Abb. 5). Man verspricht sich davon mehr Übersicht und ein aufgeräumteres Gesamtbild. Der Diff Viewer soll darüber hinaus nicht nur die Unterschiede zwischen der veränderten und der ursprünglichen Version zeigen können, sondern auch auf Knopfdruck die Unterschiede zwischen den einzelnen Revisionen innerhalb des Reviews sowie die Unterschiede zum aktuellen Workspace aufzeigen können. Selbstverständlich darf bei diesem Viewer auch die entsprechende Funktionalität für das einfache und effiziente Hinzufügen und Ansehen von Zeilenkommentaren fehlen. Der Viewer soll darüber hinaus auch unterschiedliche Navigationsmöglichkeiten durch die Änderungen erlauben, wie z.B. zwischen Dateien zu springen, von Änderungen zu Änderung innerhalb von Dateien zu navigieren oder um direkt zum nächsten Kommentar innerhalb der Datei zu gelangen. Den Abschluss des Diff Viewers macht der Reiter History, der über die vergangenen Updates eines Reviews Aufschluss geben soll. Dazu zählen etwa neue Kommentare, neue Codebegutachtungen, neue Revisionen etc.

Ein Aspekt, der dem EGerrit-Team ebenfalls besonders am Herzen liegt, ist Performance. Im Vordergrund steht in diesem Zusammenhang die effiziente Kommunikation mit dem Gerrit-Server, sodass durch ein wohlüberlegtes Design des Datenaustauschprotokolls trotz Netzwerklatenzen stets eine flüssige Bedienung von EGerrit sichergestellt werden kann. Um dieses Ziel zu erreichen, werden gerade unterschiedliche Strategien evaluiert, um den optimalen Umfang an Daten, der bei Anfragen vom Server geholt werden soll, eine ökonomische Abfragefrequenz und das richtige Ausmaß an Prefetching und Caching zu ermitteln; schließlich muss der Sweet Spot zwischen einer reaktiven Benutzerschnittstelle und der Synchronisierungshäufigkeit der Daten gefunden werden.

Ausblick: Review von EMF-basierten Modellen

Wir freuen uns ganz besonders, dass wir mit EGerrit auch ein Zuhause für den geplanten Support von Modelreview im Zuge der Collaborative Modeling Initiative [5] gefunden haben. Das Ziel dieser Erweiterung von EGerrit ist, die nahtlose Unterstützung von EMF-basierten Modellen über den gesamten Reviewworkflow hinweg zu realisieren. Dies umfasst nicht nur die Anzeige von Änderungen innerhalb eines Reviews auf Modellebene (im Vergleich zu textuellen Differenzen; selbstverständlich mithilfe von EMF Compare), sondern auch Unterstützung von Modelreviewkommentaren, die an Modellelemente anstelle von Zeilen gehängt werden können (Abb. 6).

Abb. 6: Prototyp für Modelreviews

Abb. 6: Prototyp für Modelreviews

Dabei sollen nicht nur Reviewkommentare in EMFs generischen Baumeditor hinzugefügt und angezeigt werden können. Geplant sind darüber hinaus auch spezielle Erweiterungen für GMF-basierte Diagrammeditoren und den UML-Editoren von Papyrus, die es erlauben, spezifische Kommentarnotationen – passend zu der jeweiligen Diagrammart – zu definieren, um ein konsistentes Look and Feel bei der Durchführung von Modelreviews mit Diagrammen zu erzielen. Am Beispiel von UML-Klassendiagrammen mit Papyrus können damit Modelreviewkommentare mit der gewohnten UML-Notation für Kommentare realisiert werden (Abb. 7). Selbstverständlich werden jedoch, wie bei Gerrit üblich, jene reviewspezifischen Daten, wie die Kommentare selbst, als auch beispielsweise die Position der Kommentare am Canvas als Teil des Reviews getrennt von den eigentlichen Modellen und Diagrammen am Gerrit-Server abgelegt.

Abb. 7: Prototyp für UML-Diagram-Reviews

Abb. 7: Prototyp für UML-Diagram-Reviews

Zum Abschluss

Mit EGerrit gibt es eine Menge an neuen und spannenden Entwicklungen, denen man mit Vorfreude entgegenblicken kann. Wenn man die Popularität von Gerrit innerhalb sowie auch außerhalb der Eclipse-Community betrachtet, wird schnell klar, dass EGerrit mit seinem klaren Fokus auf die optimierte Eclipse-Integration von Gerrit durchaus großes Potenzial hat, sich einen nennenswerten Nutzerkreis in der Community zu erschließen. Da bleibt nur noch die Frage offen, wann wir mit einer ersten Version von EGerrit rechnen dürfen. Wie so oft ist es schwierig, darauf eine klare Antwort zu geben. Das EGerrit-Team strebt jedoch das zweite Quartal 2015 für ein erstes Release an.

Wir heißen jedenfalls EGerrit als neues Mitglied der Eclipse-Tooling-Familie herzlich willkommen und freuen uns darauf, erste Resultate von EGerrit in die Hände zu bekommen. In der Zwischenzeit werden wir selbstverständlich unsere Arbeit an der Entwicklung und Integration von Modelreview in enger Zusammenarbeit mit dem EGerrit-Team fortsetzen und halten Sie gerne über den Fortschritt von EGerrit auf dem Laufenden. Behalten Sie daher die Website des EGerrit Project Proposals sowie die Collaborative Modeling Initiative im Auge!

Verwandte Themen:

Geschrieben von
Dr. Philip Langer

Dr. Philip Langer ist Geschäftsführer der EclipseSource Services GmbH in Wien. Als Software Engineer und Consultant verfügt er über umfangreiche Erfahrung mit Eclipse RCP und Eclipse EMF. Seinen Doktor-Titel erhielt er von der Technischen Universität Wien für seine Forschungsarbeit im Bereich Model-Versionierung und Model-Transformation.

Jonas Helming
Jonas Helming
Dr. Jonas Helming ist Geschäftsführer der EclipseSource München GmbH sowie Consultant, Trainer und Software Engineer im Bereich Eclipse-Technologie. Seine Schwerpunkte liegen neben Java auf den Technologien Eclipse RCP, Eclipse-Modellierung und Eclipse 4. Weiterhin verfügt er über mehrjährige Erfahrung in der Etablierung und Anwendung von agilen Prozessen. Jonas ist aktives Mitglied der Eclipse-Community, leitet mit der EMF Client Plattform und dem EMFStore zwei bei der Eclipse Foundation gehostete Open-Source-Projekte und ist in einigen weiteren aktiv beteiligt. Als Berater und Trainer verfügt er über mehrjährige Erfahrung in der Vermittlung von Themen rund um Java und Eclipse sowie agilen Prozessen und hält einen Lehrauftrag der Technischen Universität München. Darüber hinaus ist er als Speaker regelmäßig auf Kernkonferenzen wie der JAX oder der EclipseCon. Kontakt: jhelming@eclipsesource.com
Maximilian Kögel
Maximilian Kögel
Dr. Maximilian Kögel ist Geschäftsführer der EclipseSource München GmbH und arbeitet als Senior Software Architect im Bereich Eclipse- und Web-Technologie. Neben seiner Fokussierung auf das Eclipse Modeling Framework und Eclipse RCP ist er auch mit der Entwicklung von Webapplikationen mit AngularJS, Web Components und JSON Schema vertraut. Ein Kernthema seiner Arbeit ist das Erstellen von Modellierungswerkzeugen basierend sowohl auf einem Eclipse- als auch einem Web Technologiestack. Er ist ein aktives Mitglied der Eclipse-Community, regelmäßiger Sprecher auf EclipseCons, Leiter und Committer bei mehreren Eclipse Projekten, u.a. EMFForms und EMF Core und nicht zuletzt Mitglied im Eclipse Architecture Council. Auch außerhalb des Eclipse Ökosystems ist er in Open-Source-Projekten aktiv und leitet z.B. das JSONForms-Projekt zur Entwicklung von Web-Applikationen. Als Berater und Trainer verfügt er über langjährige Erfahrung in der Anwendung und Vermittlung von Expertenwissen rund um Java, Eclipse und Web-Technologien sowie agilen Prozessen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: