Oracle JDK im Unternehmenseinsatz?

Wie Stefan Waldmann in seinen Blogpost „Java 11 ist erschienen“ schon kurz angeschnitten hat, herrscht zurzeit Verwirrung darüber, was den zukünftigen Einsatz von Java anbelangt. So steht z.B. oftmals die Frage im Raum, ob Java weiterhin kostenfrei bleibt. Einfach gesagt: Java bleibt kostenlos, aber nicht so wie bisher. Was sich genau ändert und welche Optionen sich daraus für Unternehmen ergeben, habe ich in diesem Beitrag zusammengefasst.Mehr

AR/IoT-Prototyp: IoT in Verbindung mit Augmented Reality

Ich hatte das Glück bei doubleSlash meine Master Thesis im Bereich der Augmented Reality in Verbindung mit dem Internet of Things zu schreiben: „Exploring new worlds using Mixed Reality and the Internet of Things“. Zur Zeit gibt es viel Neues aus dieser Sparte zu berichten, deshalb teile ich hier gerne meine Erkenntnisse, auch wenn die Thesis schon etwas her ist.

Angefangen hat es mit der Auswahl des passenden Frameworks für Augmented Reality. Vuforia in Verbindung mit der Unity Game Engine hat sich damals als beste Basis ergeben. Als IoT-Platform habe ich ThingWorx eingesetzt, da wir damit im Unternehmen bereits Erfahrung hatten[1]. Sowohl Vuforia als auch ThingWorx sind Produkte von unserem Partner PTC. Als IoT Beispielgerät wurde neben einer SmartBulb die M2M-Demo-Box[2] verwendet.

Folgend will ich einen kleinen Einblick in die Ergebnisse der Thesis geben. Zunächst aber ein kleiner Überblick über Endgerät Typen.

Endgerät Typen von Augmented Realtity/Virtual Reality Anwendungen

Es gibt verschiedene Typen von Endgeräten für AR/VR Anwendungen:

  • Monitor based: Der Nutzer hält z.B. ein Smartphone in der Hand und erlebt durch das Display die Augmented Reality
  • Video see-through: Der Nutzer verwendet z.B. ein Google Cardboard (Halterung mit der man ein Smartphone vor die Augen schnallen kann) und sieht sowohl die reale Welt, als auch die digitale Erweiterung durch das Display
  • Optical see-through: Der Nutzer verwendet z.B. die Microsoft HoloLens und sieht die reale Welt durch die Brillengläser, erweitert durch Einblendungen eines Displays

 

Monitor based

Eine Monitor based Lösung ist die preiswerteste Lösung gewesen. Daher wurden auch die ersten Versuche mit einer Smartphone Lösung gemacht. Ein Image Marker wird als Referenz für das AR-Framework verwendet und dient gleichzeitig auch als Identifizierung des Gerätes, an dem er angebracht ist. Ein solcher Marker ist ein beliebiges Bild, das bestimmt Eigenschaften enthält.

Der Status einer SmartBulb wird an der Lampe angezeigt. Auch ist eine Steuerung der Lampe durch Touch-Interaktion möglich.

Video see-through

Die Versuche mit der Monitor based Lösung waren sehr erfolgversprechend. Ein Nachteil ist, dass der Nutzer das Smartphone immer mit einer Hand halten und es mit der anderen bedienen muss. Eine zusätzliche reale AR unterstützte Interaktion mit dem IoT-Gerät ist so schwierig. Daher wurde im nächsten Schritt eine Video see-through (Brillen-) Lösung angestrebt. Die Frage die bei einer solchen Lösung aufkommt ist, wie man ohne Controller in der Hand mit dem System interagieren kann. Ich habe mich für eine Gestenbasierte Interaktion entschieden, die durch z.B. Sprachbefehle erweitert werden könnte. Die Lösungen wurden mit einem Leap Motion Controller[4] umgesetzt.
Im Rahmen der Thesis habe ich zwei Möglichkeiten einer Video see-through Lösung evaluiert:

Portable Smartphone Lösung Kabel gebundene Lösung mit einer Oculus Rift[3]
GoogleCardboard Style Brille + Smartphone + Leap Motion Oculus Rift DK2 + Leap Motion + Webcam

Die Smartphone Lösung war präferiert, um möglichst portabel zu sein. Leider war diese Lösung nicht erfolgreich, da AR + Gesten Erkennung das (HighEnd) Gerät überlastet haben und es nach wenigen Minuten heiß wurde und herunter-getaktet hat. Eine flüssige Darstellung von empfohlenen 60 Bildern pro Sekunde (fps) war nicht ansatzweise möglich. Eine mindest-Anzahl von fps ist nötig, da der Nutzer die Welt mit dieser Lösung nur über diese Bilder wahrnimmt. Ist diese Darstellung nicht flüssig, führt dies zu Desorientierung und Motion Sickness.

Daher wurde die zweite Möglichkeit mit einer Oculus Rift aufgegriffen. Folgend sind die Ergebnisse möglicher UseCases aufgeführt.

Datenwerte auf realer Maschine

Die Werte der Maschine werden auf dieser angezeigt. Auch ist eine Interaktion möglich. Dies ist aktuell ein sehr verbreiteter Ansatz von AR. So kann ein Techniker z.B. mögliche Fehlerquellen direkt an der Maschine sehen und evtl. auch darauf reagieren. Dies könnte z.B. bei Predictive Maintenance Projekten interessant sein.

Virtueller Klon in der realen Welt

Ein Klon der realen Maschine wird eingeblendet und eine Interaktion ermöglicht. Dies ist im Prinzip ein ‚realer‘ Digital Twin des Geräts, der z.B. eine Fehlersuche vereinfacht.

Virtuelle Inspektion der Geräte

Das Gerät kann in der Virtual Reality inspiziert und gesteuert werden. Durch eine eigens entwickelten Fortbewegungsmethode ist es möglich, das Gerät aus jedem gewünschten Winkel zu begutachten, sogar in es hineinzuschauen.

Erweiterungen

Zusätzlich zu den UseCases oben, habe ich auch die folgenden Erweiterungen entwickelt.

Menü

Es wurde auch die Möglichkeit geschaffen, Maschinen durch ein an der Hand befindliches Menü zu steuern. So kann man auch mit Maschinen interagieren, ohne einen ImageMarker scannen zu müssen.

Warnungen

Es bietet sich auch die Möglichkeit, Warnungen darzustellen sollte man einem Objekt zu Nahe kommen. In Verbindung mit IoT könnte man sich eine solche Warnung vorstellen, sollte eine Oberfläche heiß sein (z.B. ein Herd).

Fazit

Ein Video, das leider nicht alle entwickelten Funktionen zeigt, ist in unserem youtube Kanal verfügbar:

Was 2016 bereits mit Mixed Reality und Gesten Erkennung möglich war ist sehr beeindruckend. Auch das es mit handelsüblicher Hardware umsetzbar war. Leider konnte ich keine Optical see-through Lösung testen, da es keine passenden Brillen gab (und die Zeit eh knapp war ;)).

Was wohl nun zwei Jahre später möglich ist? Wir finden es gerne mit Ihnen gemeinsam heraus.

 

Mehr zu IoT erfahren

Referenzen:
[1] IoT mit PTC ThingWorx
[2] IoT live erleben mit der M2M-Demo-Box
[3] Oculus Rift
[4] Leap Motion Controller

Browser Cache richtig löschen – aber wie?

In Ausnahmefällen kann es vorkommen, dass geänderte Inhalte einer neuen Version einer Webapplikation nicht direkt sichtbar sind. Die Erklärung dafür ist fast immer dieselbe: Weil der Browser Cache nicht geleert wurde. Dieser Beitrag liefert eine kurze Anleitung und geht dem Thema „Browser Cache leeren“ auf den Grund.Mehr

IoT Prototyp: Entwicklung einer IoT Tunnellösung für Azure und ThingWorx

Im Rahmen meiner Bachelorarbeit habe ich Netzwerktunnellösungen von IoT Plattformen untersucht und selbst eine Tunnellösung entwickelt. Zu den untersuchten IoT Plattformen gehören Microsoft Azure, PTC ThingWorx und die Eurotech Everyware Cloud. Herausgekommen ist eine Client-Server-Anwendung in Java. Sie kann im Standalone-Modus und im Zusammenspiel mit bestehenden IoT Plattformen genutzt werden.

Mehr

Mob Testing: Kollaboratives Testen und Wissenstransfer

Als Test Manager, der vor allem fachliche, manuelle Tests betreut, habe ich insbesondere ein Thema des diesjährigen German Testing Days in Frankfurt mitgenommen: Mob Testing aus einem Vortrag von Katharina Warak und Benedikt Wörner (beide Maiborn Wolff).

Beim Mob Testing handelt es sich um eine kollaborative explorative Testmethode. Kollaboratives Testen hat per se schon den Vorteil, dass mehrere Tester einfach mehr sehen. Dies ist jedoch nicht der einzige Vorteil, den Mob Testing zu bieten hat.


Doch zunächst einmal zur Vorgehensweise:

Beim Mob Testing gibt es folgende vier Rollen, die möglichst cross-funktional besetzt sein sollten (Projekt Manager, Fachbereich, Entwickler, Anwender, Tester, …):

  • Facilitator: beobachtet die Testsession, notiert die gefundenen Abweichungen (Findings) und achtet darauf, dass Regeln und Zeit eingehalten werden. Diese Rolle wird innerhalb einer Session als einzige nicht ausgewechselt.
  • Navigator: bestimmt die Vorgehensweise und gibt dem Driver Anweisungen.
  • Driver: führt die Anweisungen des Navigators aus, ohne sie infrage zu stellen oder mitzureden. Und das ist nicht so einfach, wie es klingt.
  • Mob: zwei bis fünf Personen im Mob beraten (auf Anfrage) den Navigator.

 

Mob Testing doubleSlash Christian Spohr
Bild: doubleSlash Christian Spohr

Nach einer fest definierten Zeit (meist zwischen 4 und 7 Minuten) werden die Rollen durchgewechselt, immer in der gleichen Reihenfolge. Je nach Größe des Teams wird also jeder mehrere Runden im Mob sein, aber immer nur einmal in Folge Navigator oder Driver.


Mob Testing bietet zahlreiche Vorteile:

  • Vier(oder mehr)-Augen-Prinzip: Mehr Tester entdecken mehr Fehler und kommen im explorativen Test auf mehr Ideen, auch abseits der Standardprozesse zu testen.
  • Vielfältige Perspektiven: Wenn die Besetzung des Test-Teams möglichst breit gefächert ist, führen die unterschiedlichen Blickwinkel nicht nur zu einer breiter gestreuten Durchführung des Tests, sondern helfen auch, andere Herangehensweisen bzw. Perspektiven als die eigenen kennenzulernen.
  • Wissenstransfer: Durch die unterschiedlichen Blickwinkel und Vorgehensweisen wird auch Wissen gestreut. Beispielsweise sieht ein Entwickler, wie der Fachbereich mit der Applikation umgeht und entwickelt ein Verständnis dafür und umgekehrt.
  • Interdisziplinär: Die Kommunikation zwischen den Teilnehmern und damit ihren Arbeitsbereichen wird gefördert.
  • Group Thinking: Aus dem gemeinsamen Erlebnis von Problemstellungen und daraus resultierenden Anforderungen zieht das Team an einem Strang und findet sich leichter in einer gemeinsamen Lösung wieder.
  • Rotation: Eher zurückhaltende Kollegen finden sich ohne großen Stress in einer Rolle wieder, in der sie Entscheidungen treffen (als Navigator). Andere, die sonst eher im Vordergrund stehen, müssen damit leben, nur auf Nachfrage zu beraten (in der Mob-Rolle) oder Dinge wider (vermeintlich) besseren Wissens durchzuführen (als Driver).
  • Nicht zuletzt: eine Mob Testing Session macht Spaß! Für viele Beteiligte ist das ein Raus-aus-der-Routine, etwas Neues kennenlernen – und der Zusammenhalt wird gestärkt.

 

Mob Testing bietet sich an:

 

  • als ganzheitlicher Prüfstand für ein Produkt.
  • als regelmäßiger Event, um allen im Projekt Beteiligten das Produkt, an dem sie arbeiten, greifbar zu machen und up to date zu bleiben. Das betrifft auch Bereiche, an denen sie in ihrer täglichen Arbeit selbst nicht tätig sind.
  • als Einführung für Kollegen, die neu in ein Projekt / Team kommen. So lernen sie das Produkt auf einfache Art und Weise praktisch kennen.

 

Ich bin sehr gespannt, wie sich Mob Testing in unterschiedlichen Projekten bewährt. Im Gespräch mit Entwickler-Kollegen hat sich übrigens herausgestellt, dass sie dieses Vorgehen in ihren Coding Dojo Sessions ebenfalls anwenden, um so Wissen im Bereich Softwareentwicklung zu verteilen.
Ich denke, diese vielversprechende Methode ist so vielseitig einsetzbar, dass es sich lohnt, sie als Option zu betrachten, wenn es um Tests oder Wissenstransfer in unterschiedlichen Bereichen geht.

Mehr zu Testmanagement erfahren

 

Was ist eigentlich TypeScript?

TypeScript etabliert sich zur neuen Standard-Programmiersprache im Webfrontend. In diesem Blogpost möchte ich die Herkunft und die Grundlagen dieser Sprache, sowie die Vorteile und Unterschiede gegenüber JavaScript erläutern.

Was ist ECMAScript?

Bevor wir über TypeScript reden, muss erklärt werden, woher die Spezifikation von TypeScript kommt. Die ECMAScript-Spezifikation wird seit jeher von der European Computer Manufacturers Association festgelegt und definiert quasi, wie JavaScript funktioniert.
Die ECMA-Organisation beschäftigt sich jedoch nicht nur mit JavaScript, sondern auch mit anderen Standards, wie z.B. die gute alte CD-ROM, die Floppy-Disk oder das Office-Open-XML-Format. Hier eine Liste aller ECMA-Standards).

ECMA-Script (kurz ES) wird – seit 2015 – jedes Jahr im Juni neu Released und trägt auch den entsprechenden Jahresnamen in der Spezifikation. Die aktuelle Version ist z.B. ECMAScript 2017.
Aber Vorsicht (!) ECMAScript 2017 heißt in der Kurzform ES8 oder ECMAScript 8 (für 8th Edition) – ziemlich verwirrend, oder?

Versionsname (kurz) Versionsname (lang) Name der Spezifikation Signifikanteste Änderungen
ES6 ECMAScript 6 ECMAScript 2015 Added classes and modules.
ES7 ECMAScript 7 ECMAScript 2016 Added exponential operator (**). Added Array.prototype.includes.
ES8 ECMAScript 8 ECMAScript 2017 Async Functions, Shared memory and atomics.
ES.Next Generischer Name für die nächste, kommende Spezifikation.

JavaScript ist also nichts weiter, als eine Implementierung der ECMAScript Spezifikation.
Was ist mit dem Browser-Suppport? Siehe: caniuse.com/#search=ES6 oder w3schools.com/js/js_versions.asp

Was ist TypeScript?

TypeScript (kurz: TS) ist ein Superset von JavaScript. Das bedeutet, TS ist ebenfalls eine Implementierung von ECMAScript, erweitert aber JavaScript mit zusätzlichen „Features“.
Jeder JavaScript-Code funktioniert auch in TypeScript, aber nicht jeder TypeScript-Code funktioniert auch in JavaScript.

Wie der Name schon verrät, erweitert TypeScript JavaScript um Typings (und Annotations). Das heißt die Programmiersprache ist Typsicher – wie z.B. auch Java oder C#.
Hier ein Beispiel zur Verdeutlichung:

JavaScript TypeScript
var companyName= "doubleSlash"; let companyName: string = "doubleSlash";

Die Typsicherheit unterstützt in erster Linie den Entwickler und resultiert somit in einer höheren Code-Qualität, obwohl am Ende die Software in einer „alten JavaScript-Umgebung“ lauffähig ist. Durch statische Codeanalyse kann die Softwarequalität noch weiter gesteiert werden.

Die Typings gehen nach dem Kompilieren verloren (da JavaScript keine Typings kennt) und müssen eigentlich gar nicht genutzt werden. Sie sind laut TS-Spezifikation optional (beim Thema Clean Code sind sie natürlich Mandatory!).
Auf der Homepage typescriptlang.org heißt es übrigens: „TypeScript – JavaScript that scales.„.

Aber nicht nur das: Die von Microsoft entwickelte Sprache kompiliert TypeScript-Code „herunter“ zu einer (fast) beliebigen Ziel-ECMAScript Definition (JavaScript-Version), z.B. ES5 – was von so gut wie allen Browsern unterstützt wird. Dies kann in den Compiler-Options (tsconfig.json) konfiguriert werden. Das bedeutet, in der produktiven Webapp läuft am Ende immernoch JavaScript im Browser, kein TypeScript.
Somit schafft TypeScript in Webfrontend-Projekten auch eine gewisse Browser-Unabhängigkeit, da der/die Entwickler/in sich nicht mehr darum kümmern muss, welche ECMAScript-Features er in welchen Browsern verwenden darf, und welche nicht.

Wie der Code nach der Kompilierung aussieht, kann hier live ausprobieren:

FAQ zu TypeScript

  • Gibt es auch Browser, die TypeScript direkt verstehen (ohne Kompiliervorgang zu JavaScript)?
    → Ja, z.B. Firefox, Chrome oder sogar der IE ab Version 11! Dadurch ist es z.B. möglich über die sog. Source-Maps den TypeScript-Code direkt im Browser zu debuggen.
  • Gibt es auch Konkurrenz zu TypeScript?
    → Ja, z.B. Flow von Facebook – kann im Prinzip genau das gleiche.
  • Mit welchen Frameworks kann ich TypeScript nutzen?
    → Mit so gut wie allen aktuellen, z.B. Angular, React, Electron, Ionic, …

 

Zusammenfassung (tl;dr)

  • die Benamung der ECMAScript Spezifikationen ist äußerst kompliziert und verwirrend
  • TypeScript ist eine Implementierung der ECMAScript-Spezifikation und erweitert JavaScript um Typen, Annotationen und mehr (Superset von JS)
  • man kann als Faustregel sagen, TypeScript ist der aktuellen ECMAScript Spezifikation immer etwas vorraus.
  • der TypeScript Compiler ermöglicht es, zu einer bestimmten Target-Language (JavaScript-Version) zu kompilieren, z.B. ES5 → Stichwort „Browser-Unabhängigkeit“.
  • Debugging von TypeScript ist über Source-Maps direkt im Browser möglich

 

Mehr zum Thema Webfrontend Entwicklung erfahren