ZED ist ein neuer Editor / IDE für die Entwicklung von Software. Der Editor wird vom Unternehmen ZED Industries entwickelt. Die Software wurde am 24.01.2024 unter OpenSource (GPL) zur Verfügung gestellt. Davor war die Software Closed Source. Derzeit steht nur eine Version für macOS zur Verfügung. Die Unterstützung anderer Plattformen ist allerdings geplant.

Die Macher stellen heraus, dass der Editor für hohe Performance konzipiert worden ist. Durch die eigens erstellte Library GPUI wird zum Rendering des Texte die GPU statt die CPU verwendet. Auch sonst nutzt der in der Programmiersrpache Rust entwickelt Editor so viel Cores wie möglich, um schnelle Antwortzeiten zu ermöglichen.

Über einen integrierten Chat können mehrere Entwickler:innen gleichzeitig am Code arbeiten. Wer möchte kann ChatGPT von OpenAI mittels seines eigenen OpenAI API keys integrieren.

Für mich besonders angenehm ist der fest in die Software integrierte VIM Modus. Somit entfällt die Suche nach einer entsprechenden Extension. Auch gibt es so weniger Kollisionen zwischen VIM Funktionen und evtl. Short-Cuts.

ZED kann als Nachfolger von Atom gesehen werden. Viele Mitglieder des Teams rund um ZED waren auch an der Entwicklung des Atom Editors von GitHub beteiligt. Es ist somit einiges Wissen rund um die Entwicklung von Editoren vorhanden.

Seit der Freigabe des Codes als OpenSource werden immer mehr Exension veröffentlicht. Auch liest man immer wieder von neuen Entwickler:innen auf dem Projekt bei GitHub. Somit hat sie der OpenSource Schritt mehr als positiv für die Entwicklung des Editors ausgewirkt.

Ein ausführlicher Bericht über den Editor finden sich bei heise.de: Sourcecode-Editor Zed: Erfahrungen aus einem Jahr mit einem Underdog

Die Extension zur Unterstützung der Programmiersprache Java wurde erst vor wenigen Tagen veröffentlicht. Noch sind nicht alle (notwendigen) Funktionen enthalten. Es geht aber schon recht viel.

Die Extension nutzt den von Visual Studio Code verwendeten Language Server, der auf dem Eclipse JDT aufbaut. Damit profitiert die Extension von der langjährigen Erfahrung von Eclipse. Durch die Nutzung des Language Servers fällt der notwendige Code recht gering aus. Einzig für das Syntax Highlightning enthält die Extension entsprechende Definitionen für ZED.

Es funktioniert für das tägliche Arbeiten bereits sehr viel:

Die gesamte Funktionalität wird vom Language Server zur Verfügung gestellt, dessen Integration in ZED ohne Probleme verläuft.

Grundsätzlich kann ZED aber noch nicht als "vollständige" IDE eingesetzt werden. Dazu fehlen dem Projekt noch grundlegende Funktionen, die sich in Konzeption bzw. Entwicklung befinden.

So gibt es noch keine Unterstützung zur Ausführung von Programmen oder Unit-Tests. Das kann derzeit nur durch direkte Kommandos im integrierten Terminal erfolgen. Gerade das Ausführen von Unit-Tests ist dadurch recht umständlich.

Genausowenig wird derzeit das Debugging untersützt. Diese Funktion befindet sich in Diskussion. Es ist nicht abzuschätzen ob und wenn ja in welcher Form das in Zukunft erfolgen wird.

Die Informationen aus der pom.xml eines Maven Projekts werden gelesen und verwendet. Somit werden auch in Maven definierte Dependencies erkannt und können beim Bearbeiten von Java Code verwendet werden. Es gibt aber keine direkte Intregration in ZED um Maven Befehle auszuführen.

Alles in Allem bin ich mit der ersten veröffentlichten Version der Extension recht zufrieden. Ich habe damit schon etwas Code geschrieben und freue mich auf zukünftige Versionen mit weiterm Funtkionsumfangs.

Einige Dinge müssen aber erst von ZED selbst unterstüzt werden. Daher wird es sicherlich noch einige Zeit dauern, bis ich ZED als Alternative zu Visual Studio Code nutzen kann.

Ich finde es aber gut, wenn ein weiterer "PLayer" auf dem Markt erscheint. Ich selbst würde mich freuen, wenn ich irgendwann einmal mit dem wirklich sehr flotten und minimalistisch gestalteten Editor arbeiten könnte.

Um das Alter besser einordnen zu können, habe ich bei Wikipedia‚ einige Ereignisse des Jahres 2003 - dem Gründungsjahr von IT-Consulting Hempel - zusammen gesucht. Dabei finden sich interessante Parallelen zu Ereignissen im Jahr 2023 und den Jahren davor.

Alan Kay bekommt unter anderem für seine Arbeit an der Programmiersprache Smalltalk den Turing Award.

Es ist interessant und erschreckend, dass wir seit 20 Jahren mit Wetterextremen zu kämpfen haben und bis heute nicht gewillt sind, gegen die Ursachen mit aller Kraft vorzugehen. Der Ausbruch von SARS im Jahr 2003 hatte nur einen winzigen Bruchteil der Auswirkungen wie der Ausbruch von SARS-COV2 im Jahr 2019.

Eine der Konstanten in den letzten 20 Jahren ist die stetige Weiterentwicklung des Linux Kernels. Der Kernel ist inzwischen bei der Version 6.6 angekommen.

Vor 10 Jahren konnte ich den 10. Geburtstag von IT-Consulting Hempel und meiner Selbständigkeit feiern. Bei dieser Gelegenheit habe ich ein Ausblick auf die Zukunft gewagt. Vor einem Rückblick auf die letzten 10 Jahre möchte ich prüfen, was von meinen Voraussagen eingetreten ist und was nicht.

Das Interesse am Aufbau von Build Umgebungen ist weiterhin vorhanden. Allerdings hat sich der Schwerpunkt geändert. Waren früher häufig Umgebungen mit Jenkins oder ähnlichen CI-Servern gefragt, werden Build-Umgebungen immer öfter in der Cloud aufgebaut.

Die Nachfrage an Dienstleistungen zum Konfigurationsmanagement System Puppet hat vor 10 Jahren stark angezogen. In den letzten Jahren merkt man aber auch in diesem Bereich den Einsatz von Cloudlösungen. Es werden ab und an noch Schulungen in diesem Bereich nachgefragt. Die große Menge arbeitet aber inzwischen mit Lösungen wie Ansible oder greift auf fertig konfigurierte As-A-Service Dienste zurück. Das Wissen um Puppet ist immer noch wertvoll. Es gibt immer weniger Berater in diesem Bereich.

Die Nutzung von OpenSource Software in Unternehmen hat nicht nachgelassen. Ich würde behaupten, dass OpenSource in so gut wie jedem Unternehmen eingesetzt wird. Es ändert sich allerdings auch hier die Art des Einsatzes. Betriebssysteme und Dienste wie z.B. Apache treten in den Hintergrund. Die Nutzung von speziellen Diensten und Tools dominiert.

Die letzten 10 Jahre haben viele spannende Projekte gebracht. Die Projekte lassen sich in zwei Gruppen aufteilen: Software-Entwicklung und Operations.

Im Bereich Operations habe ich mich vor allem mit dem Konfigurationsmanagement System Puppet beschäftigt. Hier habe ich zwei verschiedene Schulungen konzipiert. Eine Schulung für die Grundlagen und eine mit erweiterten Themen wie eigene Erweiterungen. Die Schulungen habe ich mehrfach für verschiedene Schulungsunternehmen und Kunden durchgeführt. Die Einsatzorte reichten von Karlsruhe im Süden bis Bremen im Norden.

Zwei Kunden habe ich beim Aufbau einer Puppet-Umgebung und beim laufenden Betrieb unterstützt. Dazu gehörte auch ein umfangreiches Modulsystem zur einfachen Konfiguration von JavaEE / JakartaEE Application-Servern.

Es gab in diesem Bereich aber auch Projekte, bei denen ich mit Hilfe des CI-Servers Jenkins eine Lösung zum einfachen Bau von RPM Paketen erstellt habe. Hier habe ich mich intensiver mit den Jenkins Pipelines und der Programmierung in Groovy beschäftigt.

Im Bereich Software-Entwicklung durfte ich mich in den letzten 10 Jahren wieder auf das Java Ökosystem konzentrieren. Besonders reizvoll war hier die Unterstützung eines Kunden beim Umstieg von C# auf Java. Dazu gehörte ein kurzer Ausflug in die Welt von Industrie 4.0 und BigData Architekturen. Hier habe ich viele neue Konzepte kennen gelernt. Bei der Schulung von alteingesessenen C# Entwicklern habe ich selbst Java neue kennen gelernt.

Das wohl größte Projekt war die Entwicklung einer RA (Registration Authority) zur automatischen Ausstellung von TLS-Zertifikaten. Die Anwendung durfte ich von Anfang an konzipieren und entwickeln. In einem zweiten Schritt stand die Implementierung des ACME Protokolls an, das ich während der Corona-Zeit so gut wie alleine umsetzten durfte. Dieses Projekt ist weiterhin am laufen und macht immer noch sehr viel Spass. Das Projekt hat inzwischen mehrere Phasen hinter sich mit wechselnden Projektmitgliedern und Aufgaben. Die Anwendung hat sich von einer JakartaEE Lösung hin zu einer Quarkus Anwendung entwickelt.

Corona hat meinen Alltag beeinflusst und geändert. War ich vor Corona jeden Tag unterwegs um meine Arbeit beim Kunden vor Ort zu verrichten, kann ich jetzt so gut wie alle Projekte aus meinem eigenen Büro erledigen. Während der Pandemie und darüber hinaus werden Schulungen immer öfter rein online abgehalten. Auch Konferenzen nutzten und nutzen diese Konstellation. Ich bin aber froh, seit einiger Zeit auch wieder zur "normalen" Konferenzen zu fahren. Der Austausch mit Software-Entwickler:innen ist mir sehr wichtig.

Rückblickend gesehen, lag ich mit meinen Gedanken für die Zukunft vor 10 Jahren nicht so falsch. Was werden die nächsten Jahre für mich bringen?

Ich möchte weiter versuchen sowohl im Bereich der Software-Entwicklung als auch von Operations tätig zu sein. Den Schwerpunkt möchte ich auf den Bereich der Software-Entwicklung setzen. Konzentrieren werde ich mich auf das Java Ökosystem. Ich bin aber auch noch Sprachen wie Go, Rust oder Swift gegenüber offen.

Neben dem reinen Programmieren möchte ich in Zukunft vermehrt im Bereich der Konzeption und Architektur arbeiten. In den letzten Projekten konnte ich schon die ersten Schritte in diese Richtung unternehmen.

Der Einfluss von KI in den verschiedensten Varianten wird zunehmen. Noch kann ich nicht abschätzen, wie ich in Zukunft mit dieser Technologie umgehen werde. Ich informiere mich laufend über den aktuellen Stand der Dinge. Angst, dass mir diese Technologie die Arbeit weg nehmen wird, habe ich nicht. Es wird sicherlich noch einige Zeit dauern, bis der Einsatz klar wird. Derzeit ist das Thema getrieben vom Hype.

Ich freue mich auf die nächsten Jahre und hoffe bestehende Kunden weiter unterstützen zu können und auch neuen Kunden mit Rat und Tat zur Seite zu stehen.

Ich habe mich an der Crowdfunding Kampagne zur Weiterentwicklung von JUnit im Jahr 2015 beteiligt. Anfang diesen Jahres konnte ich bereits die ersten Neuerungen in Blogbeiträgen erfahren. Der Vortrag von Marc Philipp und Matthias Merdes war die Gelegenheit sich endlich intensiver mit der in diesem Jahr erscheinenden neuen Version von JUnit zu beschäftigen.

Zu Beginn des Vortrags stellte Marc Philipp die neue Architektur von JUnit 5 vor. Innerhalb der Platform findet die eigentliche Ausführung der Unit-Tests statt. Die Kontrolle der Ausführung wurde von der eigentlichen Ausführung entkoppelt. Somit müssen IDEs und Build-Tools nichts mehr über die Ausführung wissen.

Die Plattform nutz verschiedene “Laufzeitumgebungen” für Tests. Neben der Vintage genannten Umgebung für JUnit Tests vor der neuen Version 5 gibt es die neue Jupiter genannte Umgebung. In dieser Umgebung finden sich alle Neuerungen für die Programmierung von Tests.

Es gibt verschiedene neue Annotationen mit denen z.B. eine ausführliche Bezeichnung von Testklassen und Tests gesetzt werden kann. Über @Tag können Tests markiert und anschließend nur mit einem bestimmten Tag versehene Tests ausgeführt werden. Interessant ist auch die Möglichkeit Tests zu verschachteln. So können Test mit einer gemeinsamen “Vorgeschichte” in einer Unterklasse gesammelt werden. Mit der Annotation @TestFactory steht ein interessanter Mechanismus zur dynamischen Erstellung von Tests zur Verfügung. Im Vortrag erwähnten Marc und Matthias noch viele weitere Mechanismen und Annotationen, die am besten den Folien entnommen werden können.

Einen unterhaltsamen Vergleichen zwischen den Big Data Frameworks Spark und Flink stellten Konstantin Knauf und Michael Pisula vor. Sie verglichen anhand einer praktischen Aufgabe die beiden Frameworks aus dem Apache Projekt. So musste in beiden Framework sowohl eine Batch- als auch eine Stream-Verarbeitung umgesetzt werden. Weiterhin sollten bestehende Daten zur Analyse herangezogen werden.

Vorteil von Flink ist dabei, dass es ein “echtes” Streaming Framework ist. Spark hingegen realisiert Streams durch Micro Batches. Die gestellte Aufgabe konnte von beiden Framework realisiert werden. Jedes Framework hat dabei in einzelnen Bereichen seine Stärken und Schwächen.

Die Antwort welches Framework das bessere ist, kann nur mit einem klaren “it depends” beantwortet werden. Für die eigene Entscheidung sollten dabei auch die Größe der Community mit berücksichtigt werden.

Für das konkrete Projekt wurde von den Beiden Apache Flink gewählt.

Sehr viel mitnehmen konnte ich vom Vortrag von Tobias Frech. Er stellte in seinem Vortrag die verschiedenen Werkzeuge des JDK vor, mit denen man Laufzeitproblemen auf den Grund gehen kann.

Nach einer kurzen Beschreibung der Tools jps, jinfo, jstat, jstack, jmap und dem zukünftigen Allrounder jcmd beschrieb Tobias am Beispiel eines konkreten Szenarios deren Einsatz. Mittels Elastic Search wurden die Panama Papers nach bestimmten Personen durchsucht. In der ersten Konstellation lief Elastic Search unter dem (Open)JDK 7. Mittels der Befehle zeigte Tobias den Speicher- und CPU-Verbrauch.

Nun wurde die Umgebung unter (Open)JDK 8 gestartet. In dieser Konstellation wurde ein wesentlich niedriger Durchsatz erreicht. Mittels der Befehle konnte das Bottleneck im Just-In-Time Compiler gefunden werden. Eine Erläuterung der Ursache und Hinweise zur deren Behebung liefert viele interessante Informationen über die Konfiguration der Java Virtual Machine.

Es lohnt sich auf jeden Fall die Folien von Tobias als Grundlage für das weitere Erforschen der JVM-Tools zu nutzen.

Eine Einführung in das Monitoring von Systemen mittels JMX gab Martin Gutenbrunner in seinem Vortrag. Zu Beginn stellte Martin die Unterschiede zwischen Debugging und Monitoring dar. Auch ging er auf die Unterschiede zwischen aktivem Monitoring (JMX) und passivem Monitoring (z.B. Icinga) ein. Danach folgte eine kurze Beschreibung der Geschichte von JMX. Eine Liste mit möglichen JMX Quellen durfte nicht fehlen. Hier kann man feststellen, dass so gut wie alle in der Java Welt eingesetzten Technologien bereits entsprechende MBeans mitbringen.

Interessant waren die Erläuterungen zur Nutzung von JMX. Dabei wurden die Anforderungen an eine Monitoring aus Sicht von Entwicklern (Dev), dem Betrieb (Ops) und der Fachanwender (Business) beschrieben. Für alle Zielgruppen stellte Martin Metriken vor, mit denen Aussagen zum Zustand des Systems für die jeweilige Zielgruppe getroffen werden können. Mit einem interessanten Ausblick auf weitere Techniken zum Monitoring endete der Vortrag.

Guido Schmutz stellt in seinem Vortrag den Message Broker Apache Kafka vor.

Sehr schön fand ich dabei die Überleitung von der klassischen Enterprise Architektur hin zur “modernen” verteilten Architektur mit Micro Services. Auf dem Weg vom klassischen Monolithen zu über Messages kommunizierende Micro Services wird es schnell klar, dass hierzu Broker wie Apache Kafka benötigt werden.

Nach dieser Einführung beschrieb Guido die grundlegende Architektur von Kafka. Die Nutzung von Topics und das dahinter stehende publish subscribe wurden dabei ebenso angesprochen wie die Partitionierung eines Topics im Kafka Cluster. Interessant auch die verschiedenen Strategien zum Löschen von über Kafka verteilten Informationen.

Der Vortrag endete mit einem Einblick in das Kafka Ökosystem mit seinen verschiedenen Connectoren. Es wurde aber auch die neue Entwicklung Kafka Streams kurz erwähnt.

Die SOLID Prinzipien sind sicherlich jedem bekannt. Sie wurden von Robert C. Martin für die Entwicklung stabiler Software definiert. Roland Mast nahm sich jede der fünf Prinzipien an und stellte dar, wie die Prinzipien mit Java 8 genutzt bzw. umgesetzt wurden.

Single Responsibility lässt sich am besten mit den Lambda Ausdrücken von Java 8 realisieren. Lambdas in Streams kapseln dabei die Verantwortlichkeiten “Streamverarbeitung” und “Bearbeitung der Entities”. Das Open Closed Principle wird sehr schön durch die Default Implementierung im Collection Interface implementiert. Das Interface wird um die Methode forEach erweitert ohne die bereits bestehenden Klassen ändern zu müssen. Für das Liskov’s Substitution Principle stellt Roland die “Umwandlung” von IOExceptions in Unchecked Exceptions vor. Das Interface Segregation Principle findet bei der Nutzung von Functional Interfaces Anwendung. So implementiert die neue LocalTime Klasse fünf Interfaces mit verschiedenen Aspekten der Zeitbearbeitung. Schlussendlich fehlt noch das Dependency Inversion Principle. Hier wird auf das Tool jdeps -jdkinternals hingewiesen. Mit ihm lässt sich erkennen, welche internen nicht zu nutzenden Klassen in einem Java Programm verwendet werden.

Zum Abschluss gab es für mich noch einen Vortrag zum Thema Big Data. Nach dem Vergleich von Apache Spark mit Apache Flink stellt Matthias Niehoff weitere Frameworks vor. Er konzentrierte sich aber rein auf die Verarbeitung von Streams.

Zu Begin erläuterte er das Thema des Stream Processing etwas genauer. Die Daten werden hierbei beim Eintreffen sofort verarbeitet. Es findet keine Speicherung und nachgeschaltete Verarbeitung statt. Die Rohdaten werden aber häufig für eine weitere, nachgelagerte Verarbeitung aufgehoben. Das distributed stream processing stellt sicher, dass die Daten kontinuierlich verarbeitet werden. Durch die Verarbeitung in-memory werden sehr geringe Latenzzeiten erreicht.

Problematisch ist die Unterscheidung zwischen Event Time und Processing Time. Die meisten Frameworks arbeiten nur mit der Processing Time. Hierbei wird die Zeit für das Datum verwendet, zu dem es bei der Plattform eingetroffen ist. Im Unterschied hierzu nutzen Frameworks die Event Time wenn die die tatsächliche Zeit des Ereignisses genutzt wird.

Ein weiteres interessantes Feld ist die Art und Weise wie das Windowing durchgeführt wird. In diesem Zusammenhang muss ein State verwaltet werden. Auch hierzu gibt es unterschiedliche Ansätze wie Tumbling, Sliding oder Session. Besonders Problematisch wird die Definition des States, wenn man die Zeit (Event oder Processing) mit ins Spiel bringt.

Im Anschluss vergleicht Matthias die Kandidaten:

basierend auf den Grundlagen.

Man kann die Frameworks grob in Stream und Micro Batches orientierte unterscheiden. Auch kann man aufgrund der API in komponentenbasierte und deklarative aufteilen.

Matthias empfiehlt klar deklarative Plattformen. Weiterhin sollte man seiner Meinung nach die hinter einer Plattform stehende Community nicht unterschätzen.

Ich bin mit dem Besuch des Java Forum Stuttgart sehr zufrieden. Die von mir besuchten Vorträge haben meine Erwartungen erfüllt. Ich konnte neue Informationen mit nehmen und wurde bei bestehenden Themen bestätigt.

Die Veranstaltung fand in einer angenehmen Atmosphäre statt. Trotz der großen Anzahl an Besuchern wirkte das Veranstaltungszentrum nicht überfüllt. Man merkt den Veranstaltern die langjährige Erfahrung bei der Organisation an.

Ich komme wieder.

Eine kurzweilige aber durchaus interessante Einführung in das Thema bot die Keynote am ersten Tag. Andy Stanford-Clark beschäftigt sich sowohl beruflich als auch privat mit dem Thema IoT. Anhand mehrerer Beispiele aus seinem privaten Umfeld stellte er verschiedene IoT Anwendungen vor. Elegant leitete er danach auf die professionellen Aspekte von IoT um. Die Keynote bot für mich wenig neues, stellte aber eine gute Zusammenfassung der Möglichkeiten und der Herausforderungen dar.

Einen Blick aus 10.000 Metern auf die Architektur von IoT Anwendungen und Systemen stellt Michael Stal in seinem Talk vor. Nach einer Schilderung der technischen Herausforderungen präsentierte Michael Stal verschiedenen Pattern zur Lösung der verschiedenen Herausforderungen. Die “Schlagzahl” der Patterns war groß aber äußerst interessant. Ich werde mir die verschiedenen Patterns anhand der Slides noch einmal ansehen. Der Vortrag erfüllte meine Erwartungen zu 100%. Die Auflistung der Herausforderungen und Probleme zusammen mit möglichen Patterns zur Lösung stellt eine gute Grundlage für eigene Architekturen dar.

In zwei Vorträgen stellt Maik Wojcieszak die im IoT Umfeld verwendeten Protokolle vor. Im ersten Teil konzentrierte er sich auf die grundlegenden IP Protokolle. Er betonte dabei vor allem die Unterschiede zwischen UDP und TCP und deren Vor- und Nachteile im Bezug auf IoT. Im zweiten Teil wurden die IoT Protokolle anhand verschiedener Kriterien verglichen. Anstatt der tabellarischen Auflistung hätte mir persönlich eine Auflistung der Vor- und Nachteile pro Protokoll besser gefallen.

Boris Adryan kümmerte sich in seinem Vortrag um die User Experience (UX) in IoT Anwendungen. Anhand eines fiktiven Szenarios stellt er verschiedene Aspekte der UX vor. Es kommt darauf an dem Benutzer immer die erwarteten Informationen anzuzeigen. Dabei ist der richtige Weg zwischen zu wenig und zu viel Informationen zu finden. Wichtig ist die Informationen im aktuellen Kontext des Benutzers einzubetten. Seine Erläuterungen gingen nicht in die Tiefe und waren daher für mich genau richtig. Durch den Vortrag bin ich auf einige Aspekte aufmerksam geworden, die ich in Zukunft beachten sollte.

Einen ersten Praxisbericht boten für mich Thomas Gregg und Negib Marhoul. Sie stellten in ihrem Vortrag eine IoT Anwendung zum Management von Hochsee Containern vor. In den Container wird ein kleines Kästchen eingebaut. Dieses mist laufend Temperatur, Luftfeuchtigkeit und weitere Zustände des Containers. Über einen Hub auf einem Container Schiff werden die Daten zu einem Rechenzentrum übertragen. Dort werden die Daten mittels Apache Cassandra gesammelt und ausgewertet.

Die Daten bieten die Möglichkeit jederzeit über den Ort und den Zustand eines Containers informiert zu sein. Apache Cassandra wird um Apache Spark zu einer schnellen Auswertung kombiniert.

Ein interessanter Vortrag der die für mich bisher "abstrakten" Technologien in der Praxis zeigt.

Der letzte Vortrag am ersten Konferenztag beschäftigte sich mit dem Management von Software Updates auf IoT Geräten. Kai Zimmermann von Bosch stellt dabei das von Bosch entwickelte System vor. Er erläuterte Anhand des Systems die Herausforderungen und die Anforderungen an ein derartiges System. Das System muss zuverlässig tausende von Geräten aktualisieren. Es ist zu beachten, dass die Lebensdauer der Geräte sehr lang sein kann. Auch gehen viele Geräte erst Jahre nach ihrer Fertigung in Produktion.

Ein durchaus praxisnaher Vortrag, der für mich klar gemacht hat, dass dieses Thema nicht zu vernachlässigen ist.

Der zweite Tag begann mit einem unterhaltsamen aber trotzdem sehr informativem Vortrag von Jochen Mader und Jens Deters. Die beiden stellten den von Ihnen eingesetzten Technologiestack für die Fast-Data Pipeline vor. Der Stack besteht aus einem MQTT Broker (Hive MQ) zur “Sammlung” der Daten. Über eine Vert.x Applikation werden die Daten von Diesem nach Kafka transportiert. Die von Kafka gesammelten Daten werden anschließend mittels Apache Spark verarbeitet. Zu persistierende Daten werden mittels Cassandra gespeichert. Der Stack wurde von den beiden mittels Mesos / DCOS betrieben. In einer Live-Demo zeigten sie den Import von Daten sowie die Verarbeitung und Speicherung.

Der Vortrag hat mich stark motiviert in einem Projekt auf den gleichen Stack aufzusetzen. Interessant ist daher, dass die beiden Ihre Lösung (Konfiguration und Scripte) auf Github veröffentlichen werden.

Im anschließenden Vortrag von Matthias Niehoff konnte ich mein Wissen über Apache Spark und Cassandra noch weiter vertiefen. Matthias zeigte anhand von Billboard-Daten die Verarbeitung von Streams mit Spark. Die Daten wurden von Spark in Cassandra gespeichert. In einem weiteren Schritt konnte er aber auch Daten aus dem Stream mit Daten aus Cassandra anreichern und diesen neuen Stream dort wieder speichern.

Zusammen mit dem vorherigen Vortrag von Jens und Jochen hat mich dieser Vortrag davon überzeugt, dass Spark das richtige Tool für mein aktuelles Projekt ist.

Passend zu den beiden vorherigen Vorträgen berichteten Michael Bauer und Henning Böger von ihrem Projekt. Auch dort haben Sie Spache Spark und Cassandra eingesetzt. Der Blick auf diese beiden Technologien aus einem abgeschlossenen Projekt war sehr interessant. Die von den beiden in dem Projekt gelösten Probleme waren sehr aufschlussreich.

Die Ähnlichkeit der in den letzten drei Vorträgen gezeigten Lösungen war sehr überzeugend. Derzeit gibt es für die Verarbeitung von Streamdaten kaum Alternativen.

Die beiden letzten Vorträge auf der building IoT beschäftigten sich mit der Sicherheit.

Christian Zenger zeigte mit seinem Vortrag neue Möglichkeiten zur Nutzung von Kryptographie auf leistungsschwachen Geräten. Durch die Nutzung von Sensoren als Entropie Quellen können auch auf kleinen Microcontrollern relativ starke Verschlüsselungen eingesetzt werden. Für das vorgestellt Verfahren ist erst vor kurzem der Patentschutz abgelaufen. Es ist zu beobachten, wie das Verfahren in nächster Zeit umgesetzt wird.

Sascha Schmidt zeigte anschießend noch Möglichkeiten, vorgefertigte Schlüssel in der Produktion auf IoT Geräte auszurollen.

Die building IoT 2016 hat meine Erwartungen mehr als erfüllt. So gut wie alle Vorträge haben das Thema Internet of Things aus der Perspektive einen Softwareentwicklers oder Architekten beleuchtet. Die Referenten waren durchweg kompetent und kannten sich in Ihren Bereichen aus. Die Atmosphere lud zum Netzwerken und Informationsaustausch ein.

In einer abschließenden Besprechung in meinem aktuellen Projekten haben wir anhand der building IoT 2016 sofort das Conference Driven Development praktiziert.

Am ersten Tag der dreitägigen Schulung drehte sich alles um Apache Maven. Nach einer Einführung in die Konzepte und Ideen von Maven ging es an die Erstellung einer ersten, einfach pom.xml.

Im nächsten Schritt wurde ein Build-Scripts für eine typische JavaEE Applikation erstellt. Das Script besteht aus mehrerem Projekten. Jedes Projekt wird mit einer eigenen POM beschrieben. Alle POMs sind von einer Parent POM abgeleitet. In diesem Parent werden die von allen POMs verwendeten Definitionen zentral abgelegt. Das eigentliche Artefakt (EAR-File) wird ebenfalls durch ein eigenes Build-Script erstellt.

Durch die Abhängigkeit des “ear module” von den beiden eigentlichen Projekten “crm” und “report” wird bei jeder Änderung an diesem Projekten ein neues EAR-File erstellt. Da alle Projekte vom “project” abgeleitet sind, nutzen diese die dort festgelegten Plugin-Versionen und sonstigen Einstellungen.

An den restlichen beiden Tagen wurde das am ersten Tag erstellte Skript in einer Continuous Integration Umgebung mit Jenkins eingesetzt.

Zuvor erläuterte ich die Grundlagen von Jenkins. Dabei wurden die verschiedenen Job-Typen ebenso angesprochen wie die grundlegende Konfiguration von Jenkins. Eingegangen wurde auf die Anbindung von Jenkins an Version Control Systeme wie Subversion oder Git. Dabei kann nicht oft genug wiederholt werden, dass hierzu ein eigener (technischer) Benutzer zu verwenden ist.

Als Übung wurde das am ersten Tag erstellte Script verwendet und hierzu ein Job in Jenkins erstellt. Durch Änderungen in der Quellcodeverwaltung wurde der automatische Bau des Projekts nach dem Einchecken einer Änderung in Subversion getestet.

Jetzt war es an der Zeit eine Einführung in Continuous Integration zu geben. Dabei orientierte ich mich an der Struktur des Buches “Continuous Integration” von Paul Duvall. Damit wird die Motivation zum Einsatz einer Continous Integration Pipeline beschrieben. Jeder einzelnen Schritt wird erläutert und der dahinter stehende Nutzen für die Entwicklung der Software erklärt. Im einzelnen handelt es sich um die folgenden Schritte:

Am Ende der Pipeline steht ein einsatzfähiges Artefakt, dass bereits grundlegende Tests bestanden hat. Durch das Deployment auf ein Testsystem können nun weitere Tests und Prüfungen durchgeführt werden.

Die einzelnen Stufen der Pipeline wurden durch entsprechende Jobs in Jenkins abgebildet. Die Jobs bauen aufeinander auf und sind wie Glieder einer Kette aneinander gehängt. Durch die Nutzung von Plugins werden die Abläufe der einzelnen Stufen realisiert. Zur Visualisierung der Pipeline kommt das Build Pipeline Plugin zum Einsatz.

Das Feedback der Teilnehmer war nach den drei Tagen Schulung durchwegs positiv. Mir hat es viel Spass gemacht eine Schulung zu den Themen zu halten, mit denen ich mich gerne beschäftige. Wie bei jeder Schulung habe auch ich einiges dazugelernt.

Ich beschäftige mich schon länger mit Docker. Auf Konferenzen lerne ich immer wieder neue Dinge zu den verschiedenen Technologien rund um die Virtualisierung von Applicationen mit Docker kennen. Auf den Voxxed Days Anfang des Jahres in Berlin gab es z.B. Vorträge zum Thema Docker Swarm. Im Vortrag “Patterns für Docker” von Roland Huß wurde ein Aspekt beleuchtet, den ich bisher vermisst habe.

Welche wiederkehrenden Muster gibt es beim Einsatz von Docker?

Roland hat seine Erfahrungen beim Einsatz von Docker in drei Patterns zusammen gefasst:

Zur Konfiguration von Images gibt es die Möglichkeit die einzelnen Konfigurationswerte als Environment-Variablen zu definieren. Diese Variablen können beim Bau eines Images oder beim Start eines Containers übergeben werden. Weiterhin besteht die Möglichkeit Konfigurationsdateien in einem sogenannten “Sidecar Container” zu verpacken. Dieser wird beim Starten des Container mit dem eigentlichen Container verbunden. Die letzte Möglichkeit zur Konfiguration von Container besteht durch die Nutzung von Key-Value Stores wie z.B. Zookeeper, Consul, etcd oder Redis.

Docker wird zur Realisierung von Microservice Architekturen eingesetzt. Hierzu ist es notwendig, dass sich die einzelnen Microservices gegenseitig finden können. Zur Lösung dieser Anforderung besteht die Möglichkeit die Adressen der benötigten Services über Environment-Variablen beim Starten zu “injizieren”. In umfangreicheren Installationen kommen Orchestrierungstools wie Kubernetes von Google zum Einsatz. Wie schon bei der Konfiguration können aber auch Key-Value Stores eingesetzt werden. Die einzelnen Dienste registrieren sich bei diesen Services und können umgekehrt andere registrierte Dienste abfragen. Interessant ist auch die Möglichkeit die Abfrage von Services über den guten alten DNS Dienst mittels _srv Records zu realsieren.

Aufgrund der fortgeschrittenen Zeit konnte Roland nur kurz auf die Lösungen zum effizienten Bau von Docker Images eingehen.

Über Dockerfile Templates können sehr einfach mehrere Variationen von Images erstellt werden. So kann ein und dasselbe Image z.B. mit einem JDK7 oder JDK8 erstellt werden. Mit der von Roland “Image Factory” genannten Techniken wird auf bestehende Techniken zurückgegriffen. Basierend auf einem Base Image werden die einzelnen Images automatisiert gebaut. Zum Einsatz kommen klassische Werkzeuge zum Konfigurationsmanagement wie Puppet, Chef oder Ansible. Letzteres hat den Vorteil, dass es direkt von Docker eingebunden wird.

Gleich im Anschluss wurde das Thema “Microservices” von Lars Röwekamp intensiver besprochen. Ich habe schon einiges zu diesem Thema gelesen und gehört. Lars hat das ganze Thema sehr kompakt und anschaulich in einen Vortrag verpackt.

Wichtig finde ich den Bezug zu Domain Driven Design herzustellen. Die Sprache zur Definition der Architektur wird dabei zusammen mit den Fachleuten der Domäne erstellt. Ziel ist es eine für das Problem passende Sprache zu erstellen. Die Sprache umfasst dabei nicht die gesamte Mächtigkeit der fachlichen Domäne. Es werden nur die Aspekte berücksichtigt, die für die Lösung des fachlichen Problems notwendig sind. Das Modell der Anwendung basiert auf dieser von allen entwickelten Sprache. Ändert sich die Sprache muss sich dadurch auch das Modell ändern.

Intensiver hat sich Lars mit dem Begriff des “bounded context” beschäftigt. Diesen Kontext zu finden gehört zur Definition der Sprache. Es handelt sich dabei um einen in sich abgeschlossenen, fachlichen Bereich. Ein Context beschreibt dabei keinen “Service” sondern eher einen Use Case oder einen Business Prozess.

Abschließend hat Lars noch die Frage behandelt, wie mit den Gemeinsamkeiten von mehreren Bounded Context umgegangen wird. Kann hier ein “Haupteigner” der Daten ermittelt werden? Evtl. ist auch der Einsatz eines “shared kernel” interessant. Dieser beinhaltet die gemeinsamen Entities. Ein Microservice wird als federführend für die Entities bestimmt.

Mark Struberg und Thorben Janssen berichteten vom aktuellen Stand der Arbeiten an der neuen CDI Version 2.0. Beide gehören zur “Java EE Expert Group” und arbeiten am neuen Standard für Context und Dependency Injection mit.

Ihr Vortrag behandelte hauptsächlich die Neuerung der asynchronen Events. Neben Beispielen zur Implementierung dieser neuen Events wurde auch auf die Hintergründe der Realisierung eingegangen. Interessant waren dabei vor allem die Aspekte wie die Handhabung der Event-Objekte über mehrere Threads gehandhabt wird. Welche Objekte haben der sendende und der empfangende Teil der Event-Kommunikation gemeinsam?

Noch befindet sich bei der neuen Version von CDI wie bei allen neuen Standards für Java EE 8 alles im Fluss. Die Möglichkeiten klingen aber sehr vielversprechend und machen auf alle Fälle Lust sich möglichst bald mit der neuen Version zu beschäftigen.

Einen für mich sehr aufschlussreichen Einblick in die verschiedenen Möglichkeiten in Java mit Nebenläufigkeit umzugehen lieferte Lutz Hühnken mit seinem Vortrag “Neue JVM-Concurrency-Modelle wie Aktoren und Verticles”. Er stellte verschiedene Modelle vor, mit denen man auf einer abstrakteren Ebene als Threads und dem java.util.concurrent Package arbeiten kann.

Mit dem Modell der Fibers von Quasar lässt sich ähnlich wie mit Threads arbeiten. Fibers dienen hierbei als Abstraktion der tatsächlichen Threads. Diese haben aber keine direkte Bindung an Threads. Man bezeichnet sie als “extended” Threads oder Coroutines. Die Programmierung erfolgt weiterhin imperativ wie bei Threads auch.

Eine höhere Abstraktion bieten Channels, deren Konzept aus dem Jahr 1978 stammt. In der Programmiersprache Go ist dieses Modell fest integriert. Eine Go-Routine lauscht hierbei an einem Channel. Daten werden von anderen Routinen durch das Schreiben in den Channel übergeben. Es wird damit eine Datenfluss orientierte Programmierung realisiert. Die Daten werden hierbei im Channel und nicht im Thread gehalten.

Ein bekannter Vertreter des Modell des Event Loop stellt vert.x dar. Der Code befindet sich in Verticles. Diese kommunizieren über einen MessageBus, über den sie sich gegenseitig Event senden. Der Bus ermöglicht die Kommunikation von Verticles in einem Netzwerk. Für blockierende Aufrufe stellt vert.x sogenannte Worker Threads zur Verfügung.

Als letztes Modell stellt Lutz Actors vor, das ebenfalls aus den 70ern (1973) stammt. Weite Verbreitung findet dieses Modell durch die Programmiersprache Erlang. In der Java Welt setzt Akka dieses Modell um. Aktoren kommunizieren über Messages miteinander. Ein Supervisor überwacht alle laufenden Aktoren.

Der Vortrag hat mein Wissen zu diesem Thema wieder etwas weiter gebracht.

Sehr inspirierend war für mich der Vortrag von David Blevins “Java EE Connectors: The Secret Weapon Reloaded”. Bisher bin ich mit Java Connectors nur selten in Berührung gekommen. Gerade bei der Anbindung von ActiveMQ an einen WildFly Application Server musste ich mich damit beschäftigen. Die API hatte aber auch bei mir den Ruf einer komplizierten Sache.

Mit der Überarbeitung der API mit Java EE 7 hat sich das aber grundlegend geändert. David zeigte in seinem Vortrag wie einfach inzwischen die Erstellung eines Connectors ist. Dadurch, dass der Connector direkten Zugriff auf die Message Driven Bean bekommt, die die vom Connector “empfangene” Nachricht verarbeiten soll, ergeben sich ungeahnte Möglichkeiten.

David stellte in seinem Vortrag verschiedene Connectoren vor. Alle nutzen ein an JAX-RS angelehntes Programmiermodell. Durch Annotationen an die Methoden einer Message Driven Bean wird festgelegt, für welche Art von Messages die Methode aufgerufen werden soll. Das Empfangen der Message übernimmt der Connector. Durch das Evaluieren der Annotationen kann er die passende Methode aufrufen.

In einer Life Demo zeigte David die Verarbeitung von E-Mails. Die Kommunikation ist aber auch über Twitter möglich. Durch die Anbindung an Google Hangouts (Jabber) konnte er mit seinem Application Server - natürlich TomEE - quasi chatten. Fehlen durfte natürlich auch nicht eine Anbindung an Slack.

Der Quellcode der von David vorgestellten Connectoren zusammen mit einer den Connector nutzenden Message Driven Bean findet sich unter https://tomitribe.io/projects/chatterbox.

Weiter geht es mit Microservices. Jochen Mader beschrieb in seinem Vortrag “Mit Vert.x vom Monolithen zum reaktiven Microservice” die Entwicklung von Microservices.

Zu Beginn lieferte Jochen seine Definition eines Microservice. Für ihn wichtig sind die folgenden Gesichtspunkte:

Seiner Meinung nach sind bei der Implementierung eines verteilten Systems die folgenden Mythen zu beachten.

Alle diese Probleme lassen sich mit Vert.x in den Griff bekommen. Die Applikation besteht aus Verticles. Jedes Verticle läuft im (immer gleichen) Thread. Die einzelnen Verticles kommunizieren über einen Bus. Der Bus kann über das Netzwerk verteilt sein. Über einen Broadcast finden sich die Teilnehmer selbst. Durch das dynamische Hoch- und Runterfahren von weiteren Instanzen kann das System elastisch auf veränderte Last reagieren.

Gut findet Jochen, dass eine Applikation als Fat JAR verpackt und damit sehr einfach deployt werden kann. Die Erstellung des JAR erfolgt mit dem Maven Shade Plugin.

Ein Thema, das oft zusammen mit Microservices verwendet wird ist das Event Sourcing. Eine Einführung in dieses Konzept der Speicherung von Daten haben Jörg Herbst und Jan Sauer in Ihrem Vortrag gegeben.

Bei der Nutzung von Event Sourcing werden die Datensätze nicht geändert. Stattdessen werden die Ereignisse, die zur Änderung von Datensätzen / deren Zuständen führen gespeichert. Um den aktuellen Zustand zu ermitteln, müssen alle Ereignisse durchgegangen und daraus der Zustand ermittelt werden. Die Lese- und Schreiboperationen werden voneinander getrennt.

Vorteil dieser Art der Speicherung ist, dass jederzeit die Ursache für die Änderung eines Zustandes / eines Datensatzes ermittelt werden kann. Auch führen Änderungen am Datenmodell nicht zu umfangreichen Migrationen. Die Ereignisse sind weitestgehend vom Schema der Datensätze getrennt.

Zur Verarbeitung werden die Events mit den Änderungen im sogenannten EventStore gespeichert. Die Events werden aber auch auf einen EventBus veröffentlicht. Dort können EventHandler andocken und aufgrund der Ereignisse weitere Operationen durchführen. Die EventHandler bauen somit das Lesemodell auf.

Wie bereits in den letzten beiden Jahren hat sich für mich der Besuch des JavaLand mehr als gelohnt. Ich werde auch im nächsten Jahr auf dem JavaLand sein. Dies findet vom vom 28.03. - 30.03.2017 wieder im Phantasialand in Brühl statt.