Angular 2 - Erste Eindrücke

Vorweg sei gesagt, dass dieser Artikel nicht den Anspruch hegt, zu diskutieren, ob JavaScript Frameworks oder JSF Komponentenframeworks der "bessere" Weg sind, um ein Web-UI zu erstellen. Die Diskussion der für und wieder würde den Rahmen an dieser Stelle sprengen. Daher gibt es hier nur eine kurze aber persönliche Meinung zum Thema Angular 2:

Angular 2 hat seit einiger Zeit das Beta-Stadium erreicht und steht in den Startlöchern für erste Projekteinsätze in 2016. Ich perönlich habe Angular 2 spätestens seit dem Besuch der W-JAX 2015 auf der Liste der Frameworks, an denen man in 2015 / 2016 im Bereich JavaScript Rich Web Applications nicht vorbeikommt.

Zu Beginn ein kurzer Rückblick auf die Nutzung von Angular 1.x. Meine persönlichen Erfahrungen mit AngularJS beginnen erst ca. Ende 2014 / Anfang 2015. Zuerst in mehreren Anläufen via Büchern und Tutorials, später an einem konkreten Beispiel. Rückblickend habe ich dabei in Angular 1.x jede Menge der Fehler begangen, die derzeit nicht als gute Praxis in der Verwendung von Angular gelten. Dazu gehören meiner Meinung nach vorallem die exzessive Nutzung des scope als zentrales Sammelbecken für alle Variablen, permanente 2-Wege Datenbindung aus Bequemlichkeit und Aufteilung der Verantwortlichkeiten nach Fachlichkeiten anstatt einem komponentenorientierten Ansatz.

Aufgrund dieser falschen Sicht auf Angular, fiel mir das Umdenken auf Angular 2 anfangs sehr schwer. Die Konzepte erschienen ungewohnt. Nach einigen Wochen der Auseinandersetzung mit der neuen Version muss ich allerdings sagen, dass ich diese nicht mehr vermissen möchte. Insbesondere der Fokus auf Komponenten gefällt mir persönlich sehr gut. Die für mich wichtigsten Neuerungen belaufen sich auf:

* Komponentenorientierung
* Kein globaler Scope
* Automatischer Value-Update Mechanismus
* Granularere Steuerung des Value-Binding
* Zusammenwachsen von Direktiven und Controllern
* Struktirierter Code durch ECMAScript 2015 Features
* Nutzung von TypeScript
* Animationen (die noch nicht implementiert sind und daher noch spannender)

All diese neuen Features, die komplette Neuimplementierung, der Fokus auf Mobile, Performance und und der Komponentengedanke führen meiner Meinung nach dazu, dass sich AngularJS 2.0 nicht hinter anderen Vertretern der JavaScript Rich Web Application frameworks wie ReactJS verstecken muss. Ich perönlich habe bereits jetzt Lust, Angular 2.0 in einem ersten produktiven Kontext einsetzen zu können. 

AngularJS und Java EE - Hochzeit mit Hindernissen

Wer kennt die Aktuellen Trends im Bereich Web-Entwicklung nicht ? JavaScript Client Frameworks für die Verlagerung des Rendering vom Server auf den Client. Komponentenbasierte Entwicklung und Single Page Applications. Im Server geht der Trend zu Microservices und reaktiven Systemen auf Grundlage des reaktiven Manifests.

Kehrt man nun in die echte Realität seiner Projektlandschaft zurück wird man in den seltensten Fällen "grüne Wiese" Projekte vorfinden, in die man derartige Konzepte problemlos einfließen lassen kann. Meistens sieht man sich eher mit Altsystemen konfrontiert, die über Jahre gewachsen sind und in denen die verschiedensten Stile und Architekturen eingeflossen sind.

Der Folgende Artikel zeigt am Beispiel eines Angular JS Web-Client für eine Bestandsapplikation eine Möglichkeit diesen in eine bestehende JavaEE Applikation zu integrieren:

Hat man einen JavaEE konformen Application Server zur Verfügung ( JBoss / Websphere o.ä. ), spricht prinzipiell erstmal nichts dagegen, diesen zusätzlich als simplen Webserver zu nutzen. Somit wird alles was für den HTML-Client nötig ist, in ein war Projekt verlagert.

Dies hat an dieser Stelle zwei interessante Aspekte: Zum einen können die Security-Mechanismen der Middleware verwendet werden um den Zugriff auf den Client zu beschränken, zum anderen besteht auch im Nachhinein ohne größere Probleme die Möglichkeit, dass war Modul herauszulösen und z.B. auf einen Tomcat oder ähnliche Produkte zu deployen, wenn leichtgewichtigere Lösungen gefragt sind. Im einfachsten Fall extrahiert man den entsprechenden Ordner und lässt diesen von einem beliebeigen Webserver ausliefern.

Dank eigenem Build Ökosystem verhält sich die Client Applikation im normalen JavaEE Kontext nicht als Fremdkörper. Prinzipiell kann man den Ordner, der die Angular Inhalte beherbergt, einfach in einer beliebigen IDE importieren, via node.js einen kleinen lokalen Webserver starten und das UI recht autark bearbeiten. Für die Versorgung mit Daten sorgen zur Entwicklungszeit meist statische Dummies. Solange die Schnittstellen und deren Inhalte definiert sind, stellt dies aber erstmal kein Problem dar. Es birgt sogar den Vorteil, dass der Client losgelöst und ohne Netzwerkverbindung entwickelt werden kann.

Wie bringt man die beiden Welten nun zusammen, wenn am Ende des Build-Prozesses ein komplettes, gemeinsames EAR entstehen soll, mit dem eingebetteten .war File des Web-Clients? Dafür gibt es ein praktisches Maven Plugin um Grunt Jobs auszuführen. Das Plugin erledigt automatisiert im Kontext von Maven sämtliche arbeiten, die ein lokales ausführen von Grunt erledigen würde. Während der Bearbeitung werden die Inhalte in ein Arbeitsverzeichnis kopiert. Somit kann man dort z.B. die Tests ausführen lassen, Transpiling durchführen lassen, uns am Ende das mittels "uglify" ein kompaktes, komplettes JavaScript auszuliefern, das mit dem Maven war-plugin im ear verpackt wird und ausgeliefert (deployed) werden kann.

Der Vorteil bei diesem Vorgehen liegt meiner Meinung nach daran, dass es sich sehr nah an monolithischen, bestehenden Build-Strukturen etablieren lässt, aber trotzdem eine ausrechend loose Kopplung besitzt, um ohne größeren Aufwand als einzelnes Projekt / Produkt / Artefakt extrahiert werden zu können.

Ein Beispiel, wie das ganze aussehen könnte, findet man auf Github unter:

angular ear example

Sommerloch

Wie sicherlich unschwer zu erkennen ist, liegt der letzte Beitrag bereits eine ganze Weile zurück. Das Sommerloch hat zugeschlagen und eine Verschiebung von Prioritäten verursacht. So ganz Stillstand ist allerdings nicht. Am meisten Zeit frisst derzeit die Modernisierung von Pub Buddy, die sich mittlerweile als Neuentwicklung Pub Buddy 2 manifestiert hat. Man darf also gespannt sein, wann die App fertig ist, jedenfalls ist das ganze nun komplett in Swift und das Konzept ist ebenfalls überarbeitet. Allerdings kommen auch permanent neue Ideen auf, weshalb sich das ganze noch eine Weile in die Länge ziehen wird...

Einfach mal wieder reinschauen..

Offene Enden...

Heute gibt es mal einen eher nicht technischen Beitrag. Ich persönlich stelle fest, das ich als Person die im IT-Kontext agiert und versucht, technologisch einen Überblick über die aktuelle Themen in der Softwareentwicklung zu behalten, so viele offene Baustellen generiert, dass es scheinbar unmöglich ist, diese tatsächlich abzuarbeiten, ohne das mindestens 2 neue Hinzukommen. Als jemand, den das Thema: IT und aktuelle Trends interessiert, nicht nur da man in dem Metier seine Brötchen verdient, sondern auch aus eigenem Antrieb für den Blick über den Tellerrand, stelle ich mehr und mehr fest, dass die eigenen Interessen breit gestreut sind. Es wird neben dem normalen Alltag zunehmend schwieriger, einigermaßen up to date zu bleiben.

Wenn ich darüber nachdenke welche Themen ich gern mal ausprobieren / weiterentwickeln / lernen würde wird die Liste schnell lang...

  • IoT- Raspberry PI oder RFDuino
  • Bluetooth LE
  • Java 7 / 8 + JavaFX
  • Swift / Swift 2.0
  • Neuheiten von der WWDC
  • Architektur Podcast
  • Blogging
  • Angular on Meteor
  • Kotlin
  • Framework Idee zum Thema EJB-Timer Monitoring

Zusätzlich dazu noch die nicht-technischen Themen des Lebens wie z.B.

  • Versuchen erfolgreich Chilis auf dem Balkon zu züchten
  • Grill-Skills erweitern

Dazu kommen dann noch Familie und Haushalt.

Dabei Frage ich mich wie andere das alles unter einen Hut bekommen. Effektives Zeitmanagement könnte ein Ansatz sein, jedoch sollte man nicht zu statisch planen da viele Dinge einfach immer wieder dazwischen kommen.

Wie geht ihr damit um ? Habt ihr auch jede Menge offene Enden herumliegen ?

Würde mich jedenfalls sehr interessieren wie andere es schaffen, effektiv neben Job und Privatleben auf einem aktuellen Stand zu bleiben.

Das nächste Mal dann hoffentlich wieder zu eher technischen Themen.

Einzelkämpfer oder Teams vermarkten ?

Das Bilderbuch Projekt, in dem alle Anforderungen klar sind, die Architektur steht, die Infrastruktur zur Verfügung steht und das Backlog sofort gut gefüllt ist, gibt es nur auf dem Papier. Das dürfte jedem sehr schnell klar werden, der einige Jahre im Projektalltag unterwegs ist. Agile Methoden haben die Situation in vielen Bereichen verbessert. Rahmenbedingungen und Anforderungen sind nicht mehr in Stein gemeißelt und werden gemeinsam erarbeitet. Aber wie hängt man an eine derartige Situation ein Preisschild ? Werden einzelne Features verkauft ? Featurepakete ?

Bei so vielen Variablen wäre es erstrebenswert, zumindest in den Bereichen auf die man einen gewissen Einfluss hat, ein möglichst großes Maß an Konstanz zu etablieren.

Je nach Umfang beginnt das Projekt mit einem oder mehreren Anforderungsanalytikern / Architekten, die die Rahmenbedingungen klären und ein gemeinsames Verständnis für das was in dem Projekt entstehen soll, mit dem Kunden zusammen entwickeln.

Steht ein grober Rahmen dessen, wohin die Reise gehen soll, kommen die ersten Entwickler ins Spiel, entweder auf der grünen Wiese oder im Rahmen von bestehenden Frameworks etc. . Es werden Technologien evaluiert, Erfahrungen gewonnen und know how aufgebaut. Langsam kommt das Projekt ins Rollen, es entstehen erste sichtbare Inhalte.

Das Projekt nimmt Fahrt auf, eventuell werden weitere Entwickler hinzugezogen und Budgets freigegeben, da man merkt es geht voran und man ist auf dem richtigen Weg. Die ersten Sprints sind gelaufen und das Team beginnt sich einzuspielen. Die Teammitglieder lernen die Stärken und Schwächen der anderen kennen, Aufgaben werden sinnvoll verteilt und im Mittel ist auch schon der Trend einer Team-Velocity auf dem Burndown-Chart zu erkennen.

Einige Sprints später pendelt sich Konstanz ein, Der PO weis wie er die Inhalte ins Backlog geben muss, damit das Team die nötigen Informationen hat. Die Infrastruktur steht, Testumgebungen und Szenerien zum automatisierten Testen wurden geschaffen, die Team Velocity erreicht immer mehr Konstanz sodass relativ gut vorausgesagt werden kann, wie viele Inhalte im kommenden Sprint geschafft werden.

Mit Fortschritt und Wachstum des Projekts sind bald alle Hauptfeatures und Anforderungen umgesetzt. Kosmetische Themen und die berühmten "goldenen Wasserhähne" wurden im Backlog niedrig eingestuft und werden umgesetzt, wenn am Ende noch genügend Budget zur Verfügung steht.

Mit wachsendem Fertigstellungsgrad, wird der Wind aus den Segeln genommen und auch der Kundenfokus ist nicht mehr so zentral auf der Applikation wie zu Beginn. Eventuell wurden schon neue Projekte begonnen, die vielleicht nun eine höhere Priorität haben. Somit schwindet auch das Budget für Wünsche, die vielleicht während der Entwicklung aufkamen, aber nicht im Ursprungsbudget kalkuliert waren. In vielen Fällen führt dies dazu, dass das Projekt nicht in der vollen Teamstärke weitergeführt werden kann. Eventuell werden 1-2 Kollegen abgezogen und im Nachhinein mehr und mehr, bis irgendjemand übrig bleibt, der das Projekt in Wartungs- und Gewährleistungsthemen betreut.

Nun ist das Team zerstreut, in neuen Projekten und in laufenden Projekten, in denen eventuell Bedarf besteht.

Welche Aussage kann man aber für das nächste Angebot treffen, wenn man das Team nicht mehr in der Konstellation besitzt, in der es tätig war? Prinzipiell sind die Erfahrungen über die Velocity dahin und müssen im Kontext eines neuen Teams auch neu ermittelt werden, da es sich nicht um einen Wert handelt, den man an einem einzelnen festmachen könnte.

Das eingespielte Team ist auseinandergerissen und alles muss sich von vorn finden. Daher stellt sich die Frage was ist höher, die Kosten für ein Team das sich neu einarbeiten muss oder die Kosten dafür das Team als Einheit aufrechterhalten zu können? Der Erhalt des Teams mag zwar für das Unternehmen zu dem Zeitpunkt ein Kostenfaktor sein, aber durch das Wegfallen des Lehrgelds für kommende Projekte eventuell zu verschmerzen.

Der alte Konflikt zwischen nachhaltiger Investition und schnellem Umsatz...

JavaLand 2015

Knapp 3 Wochen noch bis zur diesjährigen JavaLand in Brühl und endlich bin ich live mit dabei. Ich bin sehr gespannt auf die Inhalte, da die Vortragsthemen interessant klingen und von der Breite der Themen her auch für jeden (jedenfalls für jeden der irgendwas mit Java zu tun hat) etwas dabei ist.

Ich persönlich werde den Fokus wohl auf die Bereiche Enterprise, Frontend, Mobile, Security und Architecture streuen und hoffe von allem ein bisschen interessantes mitnehmen zu können. Mehr dazu und ein persönliches Feedback gibt es hier dann in 3-4 Wochen zu finden.

Gedanken zum Thema AppleWatch

Seit dem Tag der Keynote in der Tim in altbekannter Tradition das "One more thing" ankündigte, beschäftige ich mich mit dem Gedanken, ob eine Smartwatch für meinen Alltag Sinn ergibt. Wenn ich zurückdenke an die Vorstellung des ersten iPad, gestalteten sich die Gedanken zu diesem Zeitpunkt sehr ähnlich.. Braucht man das wirklich wenn man ein Notebook und ein Smartphone hat.. Wenn man im Prinzip den ganzen Tag lang die Möglichkeit hat online zu sein, da man eh in der IT arbeitet.

Also habe ich mich entschlossen nicht zu den "early adoptern" zu zählen und abzuwarten, wie auf dieses Gerät reagiert wird. Bei späteren Generationen war die Entscheidung viel einfacher z.B. beim Umstieg auf das iPad mit Retina.

Ich denke mit der Uhr wird es ähnlich laufen. Ich bin der Meinung, dass die Features, die diese Smartwatch mir derzeit bieten können (bezogen auf Features die ich auch nutzen würde),  nicht über den Funktionsumfang von derzeit auf dem Markt vorhandenen Fitness-trackern hinausgehen. Diese haben aber wenigstens eine mehrtägige Akkulaufzeit. Ich möchte ungern ein Bouquet an Ladekabeln in meiner Tasche mit mir herumtragen.

Daher aus der Entwicklerperspektive sicher sehr sehr interessant und mit der API werde ich im Simulator sicher spielen, aber für eine private Anschaffung werde ich warten bist die ersten feedbacks aus längerer Nutzung vorhanden sind. Solange das FitBit seinen Dienst tut.