Developer

Aktuelle Themen

OpenShift Pods mittels Java starten

Um in der OpenShift dynamisch neue Kubernetes Objekte zu erzeugen, kann der Java Client für Kubernetes und OpenShift 3 von fabric8.io verwendet werden. Dieser Client nutzt die REST API der Kubernetes/OpenShift Plattform, um verschiedene Aktionen auszuführen.

Wir verwenden den Kubernetes Client beispielsweise, um in der OpenShift neue Pods zu starten und nach der Berechnung diese wieder zu beenden. Wir haben uns ganz bewusst für den Kubernetes und nicht für den OpenShift Client entschieden. So sind wir plattformunabhängig und können auf andere Kubernetes Plattformen wechseln, ohne unsere Implementierung ändern zu müssen (Open-Closed Prinzip).

Beispiel

Zu Beginn erstellen wir einen Kubernetes Client. Dafür wird die Kubernetes URL der Plattform benötigt:

Mit dem Client starten wir jetzt einen neuen Pod:

Damit auf den soeben erstellten Pod zugegriffen werden kann, legen wir jetzt noch ein Service an:

Wenn der Pod nicht mehr benötigt wird, wird zuerst der Service wieder gelöscht:

Und danach den Pod:

Fazit

Der Client ist sehr mächtig. Er bietet die Möglichkeit eine Kubernetes Plattform dynamisch mittels Java zu orchestrieren. Wenn man sich mit Kubernetes auskennt, wird man keine Probleme bei der Anwendung des Java Clients haben.

Versucht es doch einfach selber.

April April! (Entfernung der Time API ;-)

In Zeiten der „Fake News“ sollte man stets den Wahrheitsgehalt von dem hinterfragen was man liest – insbesondere an einem bestimmten Tag im Jahr, wie gestern einer war. :-)

Der JEP-472 und die Entfernung der neuen Date & Time API aus meinem gestrigen Beitrag waren natürlich frei erfunden. Spätestens beim Anklicken der Quellen-Links wäre dies klar geworden.

Tatsächlich ist die java.time-API ein Beispiel für sehr gutes Code Design. Unter anderem werden die folgenden Prinzipien darin konsequent eingehalten:Mehr

Neue Time API wird wieder aus Java entfernt

(Achtung! Bitte nach der Lektüre unbedingt auch diesen Folgebeitrag lesen!)

Wie Oracle verlauten ließ, soll die mit Java 8 eingeführte Date & Time API wieder aus Java entfernt werden (JEP-472, JEP = Java Enhancement Proposal).

Komplexe API

Wie es aussieht wird die neue API, die auf Joda-Time basiert, von der Entwicklergemeinde nicht angenommen. Grund dafür ist, dass die API übermäßig komplex ist und aus zu vielen Klassen und Interfaces besteht, was die Anwendung der API sehr unhandlich macht. Oft weiß man nicht, welche Klasse bzw. welches Interface man nun eigentlich verwenden soll.

Laut Umfrage einer repräsentativen Gruppe von Java-Entwicklern setzen lediglich 3,42% der Entwickler bereits die neue API ein. Zusätzlich würden 2,11% der befragten Entwickler die API einsetzen, „wenn sie irgendwann einmal die Zeit fänden, sich einzuarbeiten“. Über 90% antworteten, dass sie die von Anfang an enthaltene API mit Date und Calendar gewöhnt seien und sich nicht umstellen wollten.

Stimmen der Vordenker

Bereits im Vorfeld hatten sich Größen aus der Entwicklerszene negativ über die API geäußert. So schrieb Martin Fowler in seinem Bliki (Mischung aus Blog & Wiki): „Who wants to learn an API with that many classes and interfaces? We had all we needed before Java 8, with Date and Calendar from the java.util package. And all experienced Java developers know how to use them and what their pitfalls are.“

Robert C. Martin, auch bekannt als „Uncle Bob“, twitterte: „It’s nearly impossible to write clean code with the Java 8 Time API“.

Brian Goetz, Java Language Architekt bei Oracle, begründete die Entscheidung damit, dass es den Aufwand nicht wert sei, eine Bibliothek zu pflegen, die so gut wie gar nicht genutzt würde. Weiter meinte er, „Finally with Java 9, we started to actually remove old stuff from the JDK. Why shouldn’t we also throw away newer libraries that aren’t actually used much? And for those who really need something like it, there’s stil Joda-Time.“

Weiteres Vorgehen

Wie geht es nun weiter? Zunächst sollen alle Klassen der API als „deprecated“ markiert werden. Das wird laut JEP-472 bereits in Java Version 13 der Fall sein, die im Herbst 2019 erscheint. Endgültig entfernt werden sollen die Klassen in der nächsten LTS-Version 17, die ab Herbst 2021 verfügbar sein wird. So haben alle, die die neue API schon einsetzen, genug Zeit, ihre Anwendungen wieder auf die herkömmlichen Klassen zurück zu migrieren.

Ich selber finde es schade, da ich mich mittlerweile recht gut an die neue API gewöhnt habe :-(

Quellen:

jaxEnter-Artikel: Die Java Time API soll wieder weg!

JEP-472

Vielfalt oder Uniform? Eclipse und IntelliJ im selben Projekt

Wenn wir mit neuer Besetzung in ein Projekt starten, stellen sich viele Fragen: welche Sprachen werden verwendet? Wie soll die Pipeline aussehen? Welche Tools verwenden wir?

Für die meisten Punkte findet sich schnell eine gemeinsame Lösung. Oft hat sich bereits ein Vorgehen oder Muster etabliert und kann so wiederverwendet werden – zum Beispiel beim Thema Codeformatierung. Doch mit unterschiedlichen Menschen kommen auch unterschiedliche Vorlieben. Viele Entwickler gewöhnen sich über lange Zeit an eine IDE und kennen sich damit sehr gut aus. Das Problem ist nur, dass selten alle die gleiche Entwicklungsumgebung nutzen möchten und hier muss eine Entscheidung getroffen werden – setzen alle das gleiche Werkzeug ein oder bleibt jeder bei dem, was er kennt? Hier ein paar Argumente für beide Seiten. (Hinweis: ich gehe hier nur auf die beiden verbreitetsten IDEs Eclipse und IntelliJ ein, die bei uns im Java-Umfeld Relevanz haben.)

Eine IDE für alle

Die einfachste Möglichkeit ist es, eine IDE als Standard festzulegen, die alle im Team dann nutzen (müssen). Daraus ergeben sich folgende Vorteile:

  • Alle Einstellungen, von Codeformatierung über Templates bis zu Save Actions, müssen nur an einer Stelle gepflegt werden. Dazu kann man noch je nach IDE bequeme Verteilungsmechanismen nutzen, z.B. Oomph oder Yatta bei Eclipse oder das Settings Repository bei IntelliJ.
  • Tiefergehendes Know-How im Umgang mit der Entwicklungsumgebung kann sich gut im Team verteilen – es gibt keine fragenden Gesichter, wenn jemand ein Feature erklärt, sondern eher den „Aha-Effekt“.
  • Jeder findet sich beim Anderen zurecht – das hilft gerade bei Pair Programming Sessions. So vermeidet man den Klassiker: „Welche Tastenkombination ist das denn hier?“

 

Gemischte Welt

Der Gegenentwurf: jeder arbeitet mit dem, was er kennt und liebt. Da kommt folgendes in den Sinn:

  • Wer sich nicht umstellen muss, kann effizient arbeiten. Bis die ganzen Menüwege, Tastenkürzel und Verhaltensweisen einer neuen IDE in Fleisch und Blut übergegangen sind, vergeht viel Zeit und die ist ja bekanntermaßen Geld. Hier gilt es also dringend abzuwägen, ob der erhöhte Abstimmungsaufwand bei gemischten IDEs das rechtfertigt.
  • Es entsteht ein Know-How Austausch über den eigenen Tellerrand hinweg. Je nach Anwendungsfall bieten verschiedene Werkzeuge objektiv betrachtet eine bessere Unterstützung und da ist es gut, wenn man weiß, welches das richtige Werkzeug ist. Nicht umsonst gibt es das Sprichwort: „Wer nur einen Hammer hat, sieht in jedem Problem einen Nagel.“

 

Möglichkeiten zur Zusammenarbeit

Für beide Vorgehensweisen gibt es gute Gründe. In einem aktuellen Projekt haben wir den zweiten Weg gewählt und sind nach anfänglichen Startschwierigkeiten inzwischen ganz zufrieden. Wie bekommt man aber nun eine Zusammenarbeit einfach hin?

Doppelte Pflege

Die schlechteste Variante – jede Einstellung separat für die IDEs festlegen und pflegen. Die Abweichung voneinander ist quasi vorprogrammiert und man ärgert sich schnell über riesige Diffs im Pull Request.

EditorConfig

Das Projekt editorconfig.org hilft dabei, grundlegende Konventionen für den Code IDE-übergreifend einhalten zu können. Es wird von sehr vielen Editoren unterstützt (teils über Plugins, teils nativ) und bietet eine Konfiguration über .ini Dateien nach folgendem Muster:

Solange die gemeinsamen Regeln für den Code im Team nicht zu umfangreich sind, ist das eine tolle Sache. Sobald die Regeln aber über die unterstützten Features hinausgehen, scheitert der Ansatz leider.

Eclipse Settings in IntelliJ importieren

IntelliJ unterstützt seit Version 13 von Haus aus den Import von Eclipse Formatierungseinstellungen. Leider gab es hier recht schnell Ernüchterung bei uns, denn immer wieder fanden wir einzelne Punkte, die dann doch nicht übernommen wurden. Als Alternative nutzen wir inzwischen die beiden IntelliJ Plugins Eclipse Code Formatter und Save Actions. Dadurch konnten wir tatsächlich (fast!) alle unsere Regeln durch einen einfachen Import übernehmen. Eine 100% Lösung haben wir zwar immer noch nicht, aber dieser Weg funktioniert für uns ausreichend gut. Die festgelegten Regeln ändern sich ja im Laufe des Projekts eher wenig, daher ist uns vor allem wichtig, dass neue Entwickler sich schnell einrichten können.

 

Würde ich es im nächsten Projekt nun genauso tun? Ganz klar: es kommt drauf an – und zwar auf die Teammitglieder. Wenn es eine halbwegs gleiche Verteilung an Präferenzen gibt, dann ist das Mischmodell ein guter Weg, um früh effizient arbeiten zu können und die Erfahrung hat gezeigt, dass es funktioniert. Bei einem homogeneren Team mit wenigen Ausreißern würde ich wohl eine IDE vorgeben, um die dadurch entstehenden Vorteile für das Projekt mitnehmen zu können.

IoT Use-Case: Statuserkennung der Dusche


Das Internet der Dinge erhält Einzug in die Dusche an unserem Hauptsitz in Friedrichshafen. Mitarbeiter, die beispielsweise an unserer Fahrradaktion teilgenommen haben, möchten nach dem Sport die Dusche im Unternehmen benutzen. Kaum ist man zur Dusche gelaufen, muss man oftmals feststellen, dass die Dusche bereits belegt ist. Als Dienstleister für IoT-Services sehen wir hier Optimierungsbedarf.Mehr