Weiterentwicklung oder stabiles API

Das Ansinnen, das API stabil zu halten, steht natürlich im direkten Widerspruch zu der Tatsache, dass sich Code ständig ändert. Wie bereits erwähnt, wird diesem Phänomen häufig mit dem architektonischen Pattern begegnet, eine Mapping-Schicht zwischen Businesslogik und Schnittstellencode einzuziehen. Die Objekte, die in dieser Mapping-Schicht verwendet werden, werden häufig Schnittstellenmodell oder DTOs (Data Transfer Objects) genannt. Je länger ein API existiert, ohne dass es weiterentwickelt wird, umso komplexer wird in der Regel diese Mapping-Schicht. Oft es gibt niemanden, der sich so richtig in der Mapping-Schicht auskennt. Das führt dazu, dass jede Änderung in der Mapping-Schicht nur mit hohem Entwicklungsaufwand zu realisieren ist. Häufig, weil die Mapping-Schicht mit einem alten, selbstgeschriebenen Mapping-Framework realisiert ist. Alternativ kommt auch existierende Mapping-Frameworks wie Dozer [1] vor, dann aber mit einer komplizierten Konfiguration.

Bei einer weiteren Variante – und die kann sich für Unternehmen als noch schlimmer herausstellen – gibt es genau einen Experten für die Mapping-Schicht, der das Mapping schon immer gemacht hat und auch für immer machen wird. Eine solche Konstellation ist natürlich aus Unternehmenssicht extrem problematisch [2]. Aus Entwicklersicht kann sie durchaus gewünscht sein. Wer ist nicht gerne Experte auf einem Gebiet? Erst recht, wenn dieses Expertentum gewissermaßen Jobsicherung bietet.

Ein weiteres Problem des langen Festhaltens an einem alten API ist häufig, dass sich API und Businesslogik irgendwann so weit voneinander entfernt haben, dass ein sinnvolles Weiterentwickeln des API nicht mehr möglich ist. Häufig ist das der Punkt, an dem eine Version 2.0 des API angegangen wird. Diese entspricht dann wieder zu 100 Prozent der Businesslogik. Die Mapping-Schicht ist entweder überflüssig oder leicht wartbar. Und alles wäre wieder gut, wenn, ja wenn das alte API nicht weiterhin unterstützt werden müsste.

Es stellt sich also die Frage des Abkündigens des alten API. Ist das nicht möglich, läuft man bei diesem Vorgehen Gefahr, sich immer weiter in die Falle zu begeben. Denn mit Version 2.0 des API ist die Entwicklung ja in der Regel nicht abgeschlossen. Die Businesslogik entwickelt sich auch dann noch weiter. Mit dem großen Problem, dass jetzt bei jeder Änderung der Businesslogik zwei Mapping-Schichten angepasst werden müssen, nämlich die zum API in der Version 1 und die zum API in der Version 2. Das Ganze lässt sich natürlich mit neuen Versionen so fortsetzen. Mit jeder neuen Schnittstellenversion kommt man dem Abgrund einen Schritt näher. Wie kann man diesem Problem begegnen? Wie können APIs sinnvoll weiterentwickelt werden, ohne Abwärtskompatibilität zu vernachlässigen?

Warten von APIs: eine Problemanalyse

Beginnen wir zunächst mit einer Problemanalyse: Der erste offensichtliche Fehler, der bei dem beschriebenen Vorgehen gemacht wird, ist das Mapping der Businesslogik in jede Version. Das führt dazu, dass bei jeder Änderung der Businesslogik der Code für jede API-Version angepasst werden muss. Eine Lösung für dieses Problem wäre eine leichte Veränderung im Mapping-Vorgehen: Das Mapping von der Businesslogik aus sollte immer nur in die neueste Version des API erfolgen. Von dort aus kann dann ein Mapping in die nächstältere Version realisiert werden. Ist z. B. Version 4 die aktuelle Version, gibt es ein Mapping von der Businesslogik in Version 4, ein Mapping von Version 4 in Version 3 usw. Der große Vorteil ist nun, dass bei der Änderung der Businesslogik nur das Mapping in Version 4 angepasst werden muss.

Ein weiterer Fehler in dem oben beschriebenen Vorgehen ist die grundsätzliche Angst der Entwickler vor Updates der API-Version. Die Ursache hierfür ist häufig die Unwissenheit der Entwickler, wie abwärtskompatible Schnittstellenänderungen durchzuführen sind. Dabei ist die abwärtskompatible Weiterentwicklung einer Schnittstelle gar nicht so schwer, wie das Beispiel in den Listings 1 und 2 zeigt.

{

  ”street”: {

    “streetName”: “Poststrasse”,

    “houseNumber”: “1”

  },

  “city”: “26122 Oldenburg”

}

{

  ”street”: {

    “streetName”: “Poststrasse”,

    “houseNumber”: “1”,

    “addressLine1”: “Poststrasse 1”,

    “addressLine2”: “”

  },

  “addressLine1”: “Poststrasse 1”,

  “addressLine2”: “”,

  “city”: “26122 Oldenburg”,

  “cityName”: “Oldenburg”,

  “zipCode”: “26127”

  “location”: {

    “cityName”: “Oldenburg”,

    “zipCode”: “26127”

  }

}

{

  “addressLine1”: “Poststrasse 1”,

  “addressLine2”: “”,

  “location”: {

    “cityName”: “Oldenburg”,

    “zipCode”: “26127”

}

}

Der Software Architecture Track auf der JAX 2018

In Listing 2 wurden zunächst Straße und Hausnummer zu addressLine1 zusammengefasst, die dann auch noch eine Ebene nach oben verschoben wurde, zusammen mit der neu eingeführten addressLine1. Zusätzlich wurde city in cityName und zipCode aufgeteilt und dann auch noch eine Ebene nach unten in das Location-Objekt verschoben. Das Beispiel zeigt: Eine Schnittstellenversion ist dann abwärtskompatibel, wenn sie keine Attribute entfernt, sondern nur welche hinzufügt. Eine Umbenennung eines Attributs kann z. B. dadurch erfolgen, dass ein Attribut mit dem neuen Namen hinzugefügt wird, das alte aber beibehalten wird. Ein solches Vorgehen stellt allerdings Anforderungen an Client und Server. Der Client muss das Tolerant-Reader-Pattern [3] implementieren. Es darf also nicht zu einem Fehler führen, dass der Server mehr Attribute liefert als der Client erwartet. Der Server hingegen muss sich nach dem Magnanimous-Writer-Pattern [4] richten. Wenn er Daten geliefert bekommt, muss es egal sein, ob das eine oder das andere Attribut befüllt ist, und wenn er selbst Daten liefert, müssen beide Attribute befüllt sein.

Das dritte Problem, das beim Warten von APIs häufig entsteht, ist das komplexe und damit unwartbare Mapping zwischen verschiedenen Versionen. Komplexe Mappings sind leider bei der Schnittstellenweiterentwicklung nicht ganz zu vermeiden. Nehmen wir das einfache Beispiel aus Listing 2, dass die Schnittstelle für ein Adressobjekt ursprünglich zwei Felder für Straße und Hausnummer hatte. Im Laufe der Zeit wurde aber klar, dass das Konzept von Straße und Hausnummer nicht für alle Anwendungsfälle tragbar ist, z. B. ist es international häufig nicht anwendbar. Und bereits ein Blick in einige deutsche Städte zeigt, dass selbst hierzulande lange nicht jede Adresse eine Straße und eine Hausnummer hat [5]. Also wurden Businesslogik und Schnittstelle geändert, sodass statt Straße und Hausnummer nur noch eine addressLine gespeichert wird. Um alte Schnittstellen weiter bedienen zu können, muss nun irgendwo im Mapping aus dieser addressLine wieder die Straße und die Hausnummer extrahiert werden. Diese Logik kann beliebig komplex werden. In besagtem Beispiel kann z. B. weitere Kontextinformation benötigt werden wie die PLZ, um herauszubekommen, ob sich die Adresse zufällig in der Innenstadt von Karlsruhe befindet [5].

Die Lösung, um solch komplexer Mapping-Logik Herr zu werden, ist eine Trennung dieser Logik vom Mapping zwischen Versionen. Diese Logik sollte immer als abwärtskompatible Änderung innerhalb einer Version implementiert werden. Das Mapping zwischen Versionen hingegen sollte immer ein 1:1-Mapping sein, um automatisiert durchgeführt werden zu können. Die Listings 1, 2 und 3 zeigen die Versionen 1 bis 3 einer Adressschnittstelle. Zwischen Version 1 und 2 kann 1:1 gemappt werden, ebenso zwischen Version 2 und 3. Lediglich innerhalb von Version 2 muss komplexe Logik existieren, um alle Felder korrekt zu befüllen. Und zwar unabhängig davon, welche Felder initial befüllt sind. In dieser Logik sind teilweise fachliche Entscheidungen nötig, die die Komplexität des Mappings beeinflussen, z. B. „Wie muss das Aufteilen der AddressLine in Street und HouseNumber erfolgen?“. Ein Framework, das einem solches Mapping zumindest teilweise abnimmt, lässt sich unter [6] finden.

Die hier beschriebene Architektur, in der das Mapping zwischen unterschiedlichen Versionen ein 1:1-Mapping ist und das Mapping innerhalb einer Version die Komplexität enthält, hat mehrere Vorteile. Erstens kann theoretisch jede Version bis hin zur Version 1 für alle Zeiten unterstützt werden. Zweitens werden komplexe Mapping-Themen explizit gemacht und finden innerhalb einer, nämlich der aktuellen, Version statt. Dadurch kann leichter explizit über das Vorgehen entschieden werden. Drittens hat eine Änderung der aktuellen Version des API auch nur Codeänderungen im Mapping-Code der aktuellen Version zur Folge. Ist eine Version einmal abgeschlossen, indem eine neue Version eröffnet wurde, muss der Code der alten Version nie wieder angefasst werden, sofern in der aktuellen Version auf Abwärtskompatibilität geachtet wird.

Fazit

Die Weiterentwicklung von APIs war schon immer ein wichtiges Thema in der Softwareentwicklung, gewinnt aber durch die wachsende Verbreitung von Microservices nochmals an Bedeutung. Um damit eingehenden Problemen frühzeitig zu begegnen, sollte bereits beim initialen Design eines API dessen Weiterentwicklung geplant werden. Wichtig ist, das Thema nicht nur bei Schnittstellen zu betrachten, die nach außen gegeben werden. Um Unabhängigkeit bei Entwicklung und Deployment zu gewährleisten, muss Abwärtskompatibilität auch bei internen Schnittstellen sichergestellt sein, z. B. zwischen zwei Microservices im selben System.

In diesem Sinne, take care.

The post Enterprise Tales – APIs weiterentwickeln appeared first on JAX.

Kevin Goldsmith, CTO bei Avvo, gab mit seiner Keynote den offiziellen Startschuss für die JAX. Unter dem Titel „Fail Safe, Fail Smart, Succeed!“ gab er dem Auditorium mit in die Konferenzwoche, dass Innovationen Fehlschläge brauchen. Denn wer sich nicht traut, zu scheitern, traut sich auch nicht, Neues auszuprobieren. Deswegen ist für den Softwareentwickler, in dessen Lebenslauf so klangvolle Namen wie Adobe, Microsoft und Spotify stehen, eine Arbeitsumgebung wichtig, die „fail-safe“ ist.

Für ihn bedeutet fail-safe aber nicht, dass Fehler nicht vorkommen, sondern, dass es sicher ist, zu scheitern. Es darf nicht darum gehen, Fehler unter den Teppich zu kehren oder einen Sündenbock zu finden.

„Nehmt den schnellsten und günstigsten Weg zum Lernen“, war ein weiterer seiner Tipps. Dann bleiben das Risiko und die Kosten von Fehlschlägen überschaubar. Als Gegenbeispiel nannte er den grandios gescheiterten Assistenten von Microsoft Karl Klammer. Er entstand im stillen Kämmerlein ohne jegliches Nutzerfeedback, und auch wenn die Idee dahinter gut war, fanden die Anwender den Assistenten einfach nur nervtötend.

Im Anschluss an seine Keynote haben wir Kevin zum Interview gebeten. Im Gespräch mit Sebastian Meyen geht er auf die Notwendigkeit ein, eine Experimentalkultur im Unternehmen zu etablieren, die Innovation fördert. Wie kann ein Unternehmen es schaffen, Fehler zuzulassen und sie als Gelegenheit zu begreifen, zu lernen? Wie lassen sich Systeme bauen, die, anstatt nur auf Fehlervermeidung ausgelegt zu sein, Fehler antizipieren und diese verarbeiten?

2. Mehrsprachigkeit macht glücklich

Keine Angst vor der polyglotten Programmierung war die Botschaft der Session von Mario-Leander Reimer, Cheftechnologe bei QAware. Er zeigte seine Idealvorstellung einer Anwendungsentwicklung, samt Tools und Sprachen. Unter anderem brach er eine Lanze für Kotlin. Die Sprache treffe genau „den Sweet Spot zwischen Java und Scala“. Er ermutigte seine Zuhörer, mit Sprachen zu experimentieren. Man müsse nicht jede Sprache so gut beherrschen wie die Muttersprache Java. Oft reiche ein Grundverständis aus, um „langweiliges Zeug“ beispielsweise in Groovy mit Skripten wegzuautomatisieren.

Interview zu Sinn und Grenzen des polyglotten Programmierens mit @LeanderReimer https://t.co/8bnh8II7S5

— JAXenter (@JAXenter) May 12, 2017

3. Sein oder Nichtsein: Java 9 und die Debatte um Jigsaw

Punktgenau zur Eröffnung der JAX 2017 ließ das Exekutivkomitee des Java Community Process (JCP) die Bombe platzen: Das Java-Kerngremium hatte sich in einer Abstimmung gegen den Entwurf des Java-9-Modulsystems (aka Jigsaw) entschieden. Lange Gesichter bei Oracle. Ergebnis dieses negativen Votums: Die Jigsaw-Spezifikation muss nochmals überarbeitet werden. Und, wie sich dann herausstellte, wurde dadurch auch eine erneute Verschiebung des gesamten Java-9-Release notwendig.

Das Thema wurde auf der JAX natürlich ausführlich diskutiert. Da prominente Vertreter aus dem Java-Kernteam vor Ort waren, haben wir die Gelegenheit für Interviews genutzt. Rémi Forax aus der Jigsaw-Expertengruppe machte deutlich, dass an dem Modulsystem an sich kein Weg mehr vorbei führt.

Die Weichen für Jigsaw sind längst gestellt: Bereits seit Java 8 ist ein Modulkonzept Teil des JDK, viele der geplanten Features für Java 10 bauen auf Jigsaw auf. Nicht zuletzt hängt die Strategie, neue Java-Versionen zukünftig häufiger und agiler zu veröffentlichen, von Jigsaw ab. Fazit: Das Modulsystem wird kommen – daran führt kein Weg vorbei!

4. Modularisierung – aber bitte mit Fokus auf die Fachlichkeit!

Entspannt sieht übrigens Java-Champion Adam Bien die Jigsaw-Debatte: „Ich warte schon seit 2007 auf Jigsaw“, hat er uns im Interview verraten. Kommt es da also wirklich auf weitere acht Wochen Verschiebung an? Aber Adam äußerte auch Bedenken: Mit Jigsaw sollte man nicht in die Falle tappen, sich mehr mit der Modularisierung als mit der eigentlichen Fachlichkeit auseinanderzusetzen!

Denn um genau diese Fachlichkeit ging es Adam in seiner Session „Bare Metal Design“. Ausgangspunkt war hier die Idee der Microservices, die Adam auf das Prinzip der Shared-Nothing-Architekturen zurückführt. Wenn wir es mit voneinander unabhängigen Komponenten zu tun haben, von deren interner Organisation die anderen nichts wissen, so lässt sich das Design des Quellcodes extrem optimieren. Viel Boilerplate, den gerade Java mit sich bringt, kann entfallen. Vorhang auf für das Bare Metal Design!

Starten sollte man aber nicht gleich mit einer verteilten Microservices-Architektur. Für Adam ist es sinnvoller, zunächst mit einem schlanken Monolithen zu beginnen – den er auch Thinlith oder Minilith nannte –, um dann Anforderungen aus den Fachabteilungen zu sammeln. Erst durch dieses Domänenwissen lassen sich kohärente Microservices schneiden, die auch abgeschlossene Einheiten in der realen Welt abbilden.

Das Take-away hier: Modularisierung und Microservices sind kein Selbstzweck. Nur wenn die Fachlichkeit es hergibt, sollte man diesen Ansatz wählen. Microservices zahlen sich aber dann aus, wenn eine Software aus unterschiedlichen Teilen besteht, die unabhängig voneinander ausgetauscht werden müssen oder wenn verschiedene Entwicklerteams autonom an bestimmten Komponenten arbeiten wollen.

5. Öfter mal Nein sagen

Wieder und wieder werden agile Teams, aber auch Stakeholder und Scrum Master, mit Anforderungen konfrontiert, die so nicht erfüllbar sind: ein fixer Abgabetermin bei festem Budget und Scope, die sehr dringende Anforderung an der Kaffeemaschine, am besten gestern. Viele Entwicklerteams kennen solche Schwierigkeiten.

Die Speaker des Agile Days der JAX 2017 waren sich in dieser Sache einig: Ein „Nein“ ist an der richtigen Stelle gar nicht schlimm. Volker Schmidt, Agile-Coach bei Cegeka Deutschland, verwies bereits in seinem Talk darauf, dass man sich als Entwickler kaum Sorgen darum machen muss, seinen Job zu verlieren. Und, wie im Abschlusspanel zur Sprache kam, erst Recht nicht dann, wenn man Recht hat. Agile funktioniert nämlich nur dann, egal ob auf Team- oder auf Organisationsebene, wenn eine ehrliche Kommunikation stattfindet und nicht zu bewältigende Anforderungen offen benannt werden. Die 59. Idee des Stakeholders sollte man also lieber ablehnen, falls man eh nicht vor hat, sie jemals anzugehen. Das ist besser für den gesamten Prozess und alle Beteiligten.

Zum Abschluss des #agile days der #jaxcon – das alljährliche Expertenpanel. #agility pic.twitter.com/nAQ4VZauE4

— JAXenter (@JAXenter) May 8, 2017

6. Diversität ist Trumpf

Was bedeutet Diversität für dich? Sind diverse Communitys effizienter oder innovativer? Im BoF-Panel haben wir darüber gesprochen, warum wir Diversität in unseren Unternehmen und Teams dringend brauchen. Jeder Teilnehmer hatte die Chance zu erläutern, was Diversität für ihn bedeutet und ob seine Firma versucht, Diversität nahtlos in die Unternehmenskultur zu integrieren.

Wir sprachen über die Teilnahme der Männer in der Diskussion und kamen zu dem Schluss, dass sie ihre Kolleginnen unterstützen und dabei helfen müssen, die Mauern des sogenannten Männerclubs einzureißen. Unser Panel war der lebende Beweis dafür, dass Männer Teil der Diskussion sein wollen. Denn es gab mehr männliche als weibliche Teilnehmer und sie äußerten deutlich, dass Diversität nicht nur zu einer besseren Arbeitsumgebung, sondern auch zu besserer Performance und Innovationen führt.

Unser Fazit war, dass wir die Unterhaltung weiter führen müssen, um Diversität wirklich nicht nur auf einem Makrolevel (Unternehmen), sondern auch auf einem Mikrolevel (Teams) zu implementieren.

Mit der JAX-Keynoterin Tracy Miranda haben wir uns über die Rolle von Diversität in der modernen Gesellschaft unterhalten. Auch die Fragen, was man tun kann, um die Dinge wirklich zu verändern und wie man Inklusion, Diversität und Gleichheit vorantreiben kann, werden besprochen.

7. Omen auf der JAX: Die Roboter-Challenge

Auch in diesem Jahr war der einzigartige Bernhard Löwenstein mit seiner LEGO MINDSTORMS Challenge ein substanzieller Teil der JAX in Mainz. Seit vielen Jahren begeistert er mit diesem festen Segment der JAX die Besucher, für viele ist der Workshop das Highlight unserer Konferenz.

Nachdem bei der W-JAX im vergangenen November die Roboter gegeneinander im Ring angetreten sind und sich gegenseitig herausschubsen mussten, ging es in Mainz diesmal friedlicher zu: Gleich zwei Herausforderungen galt es für die LEGO-Roboter zu meistern, zum einen die sichere Fahrt entlang einer vorgelegten Strecke, zum anderen die korrekte Auslieferung eines Java-9-Startpakets in Form einer Streichholzschachtel.

Treffenderweise konnten nur wenige Pakete abgeliefert werden – war das etwa ein Omen für die nahende Verschiebung von Java 9? Möglich wäre es. Dennoch waren die Einfälle wieder einmal grandios und die Teams kombinierten ihr Fachwissen um die Programmierung auf höchst professionelle Weise mit kreativen Konstruktionsideen. Fast jedes Team hatte eine individuelle und kreative Idee dafür parat, wo die Sensoren in den Roboter eingebaut und wie die Transportproblematik gelöst werden sollte. Die Gewinner konnten sich am Ende über ein kostenloses Tutorial aus unserem entwickler.tutorials-Angebot und eine Tasse mit dem Schriftzug I Java freuen.

8. Ohne Feedback kein Big Data

Früher entschied der Chef, und er hatte entweder ein gutes Gespür oder es ging eben schief. Heutzutage fallen immer mehr Entscheidungen auf der Grundlage von gesammelten Daten, wie Hendrik Saly, Senior IT Consultant bei codecentric, in seinem Talk zum Datengoldschürfen erklärte.

Aber damit wirklich aus Daten Gold wird, setzt er auf den OODA-Loop. OODA steht für „observe“, „orient“, „decide“ und „act“. Das Konzept beschreibt eine Feedbackschleife, die aufgrund von neuen Ereignisse immer wieder durchlaufen wird. Entscheidungen und Änderungen, die zu Taten führen, die dann aber nicht erneut gemessen werden, sind nur der halbe Weg. „Big Data ohne Feedbackzyklus lohnt nicht“, war sein knappes Statement.

9. Container drinnen und draußen

Das reichhaltige Aufgebot an Containerschiffen, die während der JAX aus der Rheingoldhalle beobachtet werden konnten, war ziemlich auffällig. Es kam einem fast so vor, als seien sie ganz speziell von den Reedereien in dieser Woche auf die Reise geschickt worden, um die Besucher der Konferenz in die richtige Stimmung zu versetzen.

Aber um Container ging es auch in zahlreichen Sessions, zum Beispiel in Philipp Garbes Talk. Er sprach über Continuous Delivery von Docker-Containern mit Amazon ECS. Im Interview mit JAXenter erläuterte er dann auch, dass sich ECS vor allem durch die gute Weboberfläche und das ECS CLI auszeichnet. Gerade Letzteres sorgt für angenehmes Arbeiten, da man mit einem Befehl ganze Cluster erzeugen und deployen kann.

10. Serverless heißt nicht less Server

Längst werden Anwendungen und Microservices zu einem großen Teil in der Cloud erstellt. Seit einer Weile geht das sogar serverless, wobei das nicht bedeutet, dass gar keine Server zum Einsatz kommen. Im Vergleich zur klassischen Methode kümmert sich allerdings der Cloud-Anbieter um das gesamte Servermanagement, nicht mehr das Unternehmen oder der User selbst.

Wie man die neue Technologie einsetzen kann, hat Niko Köbler in seinem Workshop und seiner Session auf der JAX eindrucksvoll vermittelt. Für Best Practices, so verriet uns der freiberufliche Softwareentwickler, sei es allerdings noch zu früh. Daran liegt es auch, dass das Tooling der Technologie noch nicht besonders ausgereift ist. Ein paar „Lessons Learned“ gibt es aber, nämlich unter anderem, dass es wichtig ist, auf die Latenz und das Caching zu achten.

Wir sehen uns im November!

Viel los war wieder auf der JAX. Und unser kleiner Rückblick ist sicher kein umfassendes Spiegelbild von über 170 Sessions, Workshops und Keynotes. Wir sehen uns wieder in München zur W-JAX 2017. Dann hoffentlich mit Java 9 und einer ganzen Wagenladung weiterer Themen aus und von der Java-Community.

The post 10 Take-aways von der JAX 2017: Microservices, Container, Java 9 & More appeared first on JAX.

User Interfaces: Welche Webtechnologie passt zu mir? from JAX TV on Vimeo.

The post User Interfaces: Welche Webtechnologie passt zu mir? appeared first on JAX.

Für IT-Profis steht die Welt nie still: Neue Technologien gibt es immer zu entdecken, vorhandenes Wissen auszubauen, Lücken zu schließen. In unserer Jahresumfrage wollen wir deshalb herausfinden, mit welchen Sprachen, Tools und Architektur-Themen Sie sich 2017 verstärkt beschäftigen möchten.

Nehmen Sie sich 5 Minuten Zeit und bewerten Sie die unteren Technologien und Trends nach ihrer Relevanz für Sie im Jahr 2017!

Wir sind gespannt auf Ihre ganz persönlichen Technologie-Trends 2017!

The post Mit welchen Sprachen, Frameworks & Tools wollen Sie sich 2017 beschäftigen? appeared first on JAX.