Eclipse Che und Neon wie Kartoffeln und Apfelsaft!

Eclipse Che ist auch diese Woche wieder Thema meines Blogs. Letzte Woche habe ich in meinem Beitrag beschrieben wie man Eclipse Che einrichtet. Als Vorbereitung für meinen Vortrag beim Kunden gehe ich in diesem Beitrag auf die Unterschiede zwischen Che und Neon ein.

Wie bereits im Ausblick meines letzten Beitrags angekündigt werde ich mich mit den folgenden 4 Fragestellungen beschäftigen:

  • Mit welchen Funktionsabstrichen muss man bei Che rechnen?
  • Sind meine gewohnten Tastenkürzel ebenfalls in Che vorhanden?
  • Gibt es Features, worüber ich mich ausschließlich bei Che darüber freuen kann?
  • Wie einfach ist die Integration von bestehenden Projekten auf einen Che workspace?

Worauf ich in diesem Beitrag nicht eingehen werde sind workspace Optionen, die während dem Einrichten möglich sind. Oder die Bedienung des workspace Managers (Resourcenverteilung, Start/Stop von workspaces). Meine weiteren Ausführungen und Vergleiche gehen von einem bereits aufgesetztem workspace mit dem Java Stack (Java, JDK, Maven, Tomcat, Subversion, Ubuntu, Git) aus. Im Zuge des Vergleichs habe ich Eclipse Neon.1 benutzt, anstatt das bereits veröffentlichte Neon.2. Spezielle Gründe hatte ich dafür nicht, bis auf die fehlende Motivation neben meinem bestehenden Neon.1 eine zweite IDE auf meiner Arbeitsstation zu installieren.

Cloud IDE – Reduzierter Funktionsumfang

Nachdem ich meinen ersten workspace aufgesetzt habe, ging es auch direkt los mit ein paar kleinen Code Katas, die ich aus der Clean Code Developer School kannte. Weitere Gedenkenbeispielen für Katas sind hier zu finden CodingDojoCodeKata und CodeKatas. Schon beim erstellen der ersten Java Dateien fällt der Unterschied zu Neon auf. Während Neon entsprechend der Perspektiven die Auswahl von möglichen Dateien anpasst/eingrenzt, wird mir bei Che in einem Java Stack Dateiformate angeboten, für die mir aktuell in diesem Stack keine Verwendungsmöglichkeiten einfallen. Die Rede ist von Dateiformaten wie C#, C++C. Neben den Java Class und Java Package gibt es sinnvoller Weise auch die Option generelle Dateien (FileFolderXML File) zu erzeugen.

grün=Stack relevante Optionen / orange=Stack verwandte Optionen / rot=Stack fremde Optionen / violett=doppelte Einträge

Auch in dem Wizard zur Erzeugung von neuen Java Class Dateien fehlen so einige Optionen (Package, Vererbung, Interfaces, etc.), die man aus Neon und seinen Vorgängern gewohnt ist.

Auch an so manch anderen Stellen erkennt man als langjähriger Desktop IDE Nutzer Unterschiede zur Che Cloud. Was besonders hervorzuheben ist, sind die Funktionen Refactor und Source des Kontext Menüs, wobei letzteres im Che Kontext Menu gänzlich fehlt.

Cloud IDE – die Tastenkürzel stehen Kopf!

Was mir in meiner Coding Kata am stärksten aufgefallen ist, sind die unterschiedlichen Tastenkürzel. Bei bekannten (und häufig verwendeten) Tastenkürzeln habe ich drei Ausprägungen kennen lernen dürfen in meiner Coding Session. Zum einen gibt es einzelne (wenige) Kürzel, die auch in Che ihre gewohnten Funktionen ausführen (z.B. Strg+Leertaste). Einige (viele) Kürzel sind mit neuen / anderen Funktionen belegt. Zum Beispiel wirkt sich Strg+Shift+F in Neon mit dem Auto-Format auf den aktuellen Editor aus, während in Che der Dialog für Suchen/Find aufgerufen wird. Und zu guter letzt gibt es Funktionen, denen gar kein Tastenkürzel zugewiesen ist. Wie auch in Neon (muss man fairer Weise sagen), doch bei Che empfand ich (subjektiv betrachtet) die Relation zu Ungunsten von Che.

Mir hat es aber trotzdem Spaß gemacht meine Coding Kata auf Che auszuprobieren, da mir vor Augen geführt wurde welche Leistungseinbrüche ich durch fehlende/andere Tastenkürzel in Kauf nehmen muss. Das ist für mich im Umkehrschluss ein großes Lob für die bisherige Integration meiner Entwicklungsumgebung. Für all diejenigen, die sich mit den anderen Tastenkürzeln in Che anfreunden möchten, gibt es eine Liste in der Menüleiste mit allen gebundenen Funktionen mit Tastaturkürzel. Als einen dicken Malus empfinde ich die (mir nicht bekannte) fehlende Möglichkeit bestehende Tastenkürzel zu ändern.

Eclipse Che – erweiterte Funktionen

Wen die bisher aufgeführten Unterschiede zu Neon stören, darf sich gerne mit seiner gewohnten IDE per Mount-and-Sync Funktion mit dem Eclipse Che workspace verbinden (egal ob mit Eclipse oder einer anderen IDE). Aus Zeit Gründen konnte ich diese Funktion jedoch leider nicht ausprobieren. Laut der Feature Webseite von Che können zusätzlich Services dem bestehendem oder zukünftigen workspace hinzugefügt werden, welche den reduzierten Funktionsumfang (siehe oben) eventuell/teilweise wieder gut macht.

Die Hauptargumente für Che hingegen sind für mich die integrierte Team Entwicklung innerhalb eines workspaces und die mögliche Nutzung von Software Stacks.

Durch individuelle Anpassungen können die Stacks auf die aktuelle Zielumgebung zugeschnitten werden. Neue Technologien oder Versionen von Software nach belieben zugeschaltet werden oder für Validierung neu erstellt werden. Die Stacks sind konfigurierbar und beliebig oft reproduzierbar (nur die Hardware setzt Grenzen). Ein neues Team soll das bestehende unterstützen? Kein Problem, lass uns einfach den bestehenden Stack duplizieren oder neu generieren.

Neben der einfachen Reproduzierbarkeit sind die workspaces generell für mehrere Benutzer des Teams gleichzeitig nutzbar. Ob die Mitarbeiter/Kollegen nun ohne lokale IDE Installation über einen beliebigen Browser die Cloud IDE nutzen oder sich remote mit dem workspace verbinden, arbeiten diese dennoch auf der selben (virtuellen) Umgebung. Durch dieses Feature kann gleichzeitig an unterschiedlichen Dateien gearbeitet werden, ohne das sonst übliche Einchecken von Code. Die Multi-User Funktionalität habe ich bei mir lokal durch Chrome simuliert, indem ich mich neben meiner normalen Session mit einem Inkognito-Fenster von Chrome zu meinem Eclipse Che verbunden habe. Beide Sessions waren fähig auf ein und die selbe Datei zuzugreifen. Bearbeitungen waren in beiden Fenstern möglich, doch persistiert wurden nur die Änderungen der ersten Session. Unabhängig von der Einschränkung der simultanen Bearbeitung einer Datei sind trotzdem die Vorteile dieser Entwicklung offensichtlich gewesen.

Änderungen von Kollegen:

  1. wirken sich direkt (ohne Einchecken) auf die Compile-Fähigkeit aus
  2. sind ohne Patchs ersichtlich
  3. könnten vor dem Einchecken kontrolliert werden

Auch Coaching ist über diesen Weg mit geringer Latenz möglich. Denkbar wäre es, durch die Nutzung von Video-/ oder Telefonkonferenzen, die Face-to-Face Kommunikation aufzubauen und den restlichen Bildschirm für die Einsicht des Codes zu nutzen.

Eclipse Che – Integration von bestehenden Projekten

Ich muss leider berichten, dass ich ausschließlich Probleme hatte. Keiner meiner Versuche hat gefruchtet. Da ich nicht all zu viel Zeit investiert habe für die Integration, hat meine Erfahrung jedoch nicht viel Gewicht. Nichtsdestotrotz möchte ich hier kurz die Schwierigkeiten, welche mir untergekommen sind, dokumentieren.

Als erstes habe ich versucht innerhalb meines workspaces ein bestehendes Git Repository einzubinden. In der Menüleiste gibt es die Möglichkeit den Import Project Wizard zu starten. Unter Source Control habe ich GIT ausgewählt und die URL meines Raspberry-Pi Repository angegeben, wie ich es sonst über Neon einbinde.

Die Fehlernachricht hat mich in Richtung der SSH-Keys geleitet. Deshalb habe ich mich ein wenig mit der vorgeschlagenen Einstellung in der Cloud IDE beschäftigt.

Leider war die angegebene Einstellung nicht so wie angegeben in den Preferences verfügbar. Auf gut Glück habe ich mich an den VCS Einstellungen bedient und einen SSH Key generiert für das angegebene Gerät. Leider auch hier keinerlei Erfolge zu verzeichnen. 

Bevor ich aufgegeben habe wollte ich eine ZIP meines Projekts in Che hochladen. Der Che workspace arbeitet nach dem pull-Prinzip und läd sich, bei Angabe einer validen URL, die Datei herunter. Da mir dieses Konstrukt der Dateifreigabe aktuell nicht zur Verfügung steht habe ich diesen Punkt vorzeitig für mich abgehackt.

Ergebnis

Nachdem ich die beiden Produkte verglichen habe, muss ich im nachhinein sagen, dass ein Vergleich sich nicht ganz richtig anfühlt. Als Metapher bietet sich Kartoffel und Apfelsaft an. Wenn man Aspekte sucht, die man vergleichen will, dann wird man welche finden (Nährwert, Geschmack). Aber ein direkter Vergleich ist schlicht und ergreifend nicht möglich. Dazu ist Che auch nicht konzipiert. Che soll keine Alternative von Neon werden. Che bewegt sich in anderen Bereichen, in denen Neon keine Aktien hat. Dafür bietet Che mit einem Teil seines Ganzen ein Produkt (Cloud IDE) welches man mit Neon vergleichen kann.

Ausblick

Noch habe ich Che nicht aufgegeben und werde mich, in nicht all zu ferner Zukunft, wieder mit Eclipse Che beschäftigen. Bisher habe ich nur an der Oberfläche gekratzt und wenig Zeit investiert. Für die nächsten Anläufe muss ich mir jedoch noch überlegen was für ein Aspekt / Thema ich dabei beleuchten will. Wobei mir jetzt schon das Prinzip des mount-and-sync einiges an Neugier aufkommen lässt. Vielleicht wird es aber auch nur ein weiterer Erfahrungsbericht, sobald ich eins meiner privaten Projekte versucht habe mit Eclipse Che umzusetzen.

Die nächste Woche habe ich Urlaub und mehrere Themen in der Pipeline. Welches Thema/Projekt ich beleuchten möchte kann ich somit heute noch nicht sagen. Des Weiteren fällt es mir ohne Vorarbeit immer schwerer mein eigenes Ziel (jeden Freitag Nachmittag den nächsten Beitrag zu veröffentlichen) pünktlich einzuhalten. Aus diesem Grund werde ich mir in meinem Urlaub das Ziel nochmal durch den Kopf gehen lassen und eventuell für die nächsten Wochen (geringfügig) anpassen.

Der Artikel ist auch in english verfügbar.

Schreiben Sie einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.