ALEXA - Nachtrag zum LED-Lichtband IoT Projekt

Über die Ostertage hat sich eine Dame namens Alexa in meinem Haushalt Einzug gefunden. Meine Anschaffung hatte in diesem Fall zweierlei Hintergründe, zum einen die Evaluierung, ob dieses Gerät eine nützliche Bereicherung für meinen Alltagsablauf darstellen kann und zum anderen wie einfach es ist, Alexa aus Sicht der Softwareentwicklung einzubinden.

Alexa im Alltag:

Zum ersten betrachteten Aspekt, der Integration in alltägliche Abläufe, muss ich gesehen, ich bin wirklich positiv überrascht. Alexa lässt sich einfach konfigurieren und nach wenigen Minuten stehen die grundlegenden Funktionen zur Verfügung. Die Spracherkennung funktioniert sehr gut, auch wenn man sich nicht in der direkten Umgebung des Geräts aufhält oder Nebengeräusche um Raum vorhanden sind. Der Umfang der Default-Skills ist durchaus ausreichend um einen guten Eindruck zu bekommen und es macht Spaß zu entdecken, was Alexa alles zu bieten hat. Die mitgelieferte, notwendige App zur initialen Konfiguration hingegen ist auf IOS Seite etwas hakelig aber bedienbar. Nach einer Woche der Nutzung muss ich gestehen, verhält sich Amazons Sprachassistent ähnlich wie die Apple Watch zum Verkaufsstart. Zuerst dachte ich, ich benötige es nicht aber nun ist es aus dem Alltag schwierig wegzudenken. Immer häufiger erwische ich mich im Dialog mit Alexa als schlaues Helferlein, wenn ich in der Küche die Hände voll habe oder ich am Morgen im vorbeigehen ein paar Infos möchte. Zusätzlich hierzu entstehen fast täglich neue nützliche und unterhaltsame Skills aus der community, sodass Alexa nicht langweilig wird.

Alexa Development:

Der für mich eigentlich interessantere Aspekt, ist die Entwicklung von eigenen Skills. Hierzu habe ich mir als Anwendungsfall die sprachgesteuerte Bedienung des Stimmungslichts aus dem vorherigen Artikel vorgenommen. Alexa soll am Ende via "Moodlight einschalten" und "Moodlight ausschalten" in der Lage sein, zu tun was vorher via WebApp-Fernbedierung gesteuert wurde. 

Der Grundsätzliche Ablauf ist einfach, sind die Befehle doch im lokalen Netz bereits via URL verfügbar, somit muss Alexa nur die Ausdrücke zu den richtigen Sprachbefehlen zuordnen und eine URL aufrufen.

Folgende Voraussetzungen erleichtern das Leben bei der Skill-Entwicklung:

Die ersten Berührungspunkte mit dem Skill-Development erzeugten zuerst einige Fragezeichen, wenn man aus der klassischen Java Entwicklung kommt. Das durcharbeiten eines kleinen Tutorials brachte hier allerdings schnell Abhilfe. Mit dem Alexa Demo Skill in Python kann man schnell und einfach nachvollziehen, wie ein Skill gestaltet werden muss.

Über den Amazon Developer Account wird der Skill beschrieben, welche sogenannten Intents im Skill hinterlegt sind, welche Spracheingaben valide sind und auf welche der Intents diese matchen.

Wenn diese Inhalte definiert sind, kann in AWS-Lambda ein, in diesem Falle Python, Skript erstellt werden, welches die Funktionen der einzelnen Intents implementiert. Hierzu stehen auf der Website die Python Bordmittel zur Verfügung. Benötigt man darüberhinaus weitere Bibliotheken, bietet es sich an, den Code extern zu schreiben und via Archiv (Developer Doku beschriebt, wie das Archiv aussehen muss) hochzuladen. Sobald der Code in der Amazon Cloud ausgeführt wird, kann der neue Skill bereits auf der Hauseigenen Alexa getestet werden.

Im nächsten Schritt möchte ich noch versuchen, das ganze mit dem Flask-Ask Framework zu realisieren, um die Implementierung zu vereinfachen.

Bis dahin Alexa, gute Nacht..

 

LED-Lichtband Sonnenaufgang unter dem Bett mit dem Raspberry PI

LED Sonnenaufgang unter dem Bett

  1. Materialliste
  2. Physikalischer Aufbau
  3. Einrichtung Raspberry PI
  4. Anlernen der Fernbedienung
  5. Umsetzen der Steureung als Python-Webservices
  6. Client in JQueryMobie und Deployment auf nginx

Matrialliste:

  • Raspberry PI 3
  • 16GB MicroSD Speicherkarte
  • Netzteil
  • Etwa 7 Meter LED lichtleiste (z.B. 2x LED-Lichtband mit IR Fernsteuerung
  • IR Shield von LinkSprite
  • 10 Meter Klett Klebeband
  • Merhfachsteckdose

Physikalischer Aufbau:

Zuerst müssen Matratzen und Lattenroste aus dem Bettgestell herausgehoben werden. Im unteren Bereich des Bettrahmens wird an der Innenseite eine Seite des Klett-Klebebands ringsherum angebracht, sodass die Beleuchtung im ausgeschalteten Zustand nicht sichtbar ist. an den Ecken werden die mitgelieferten Eck-Verbinder benutzt. Da die Stromversorgung der LED-Leisten auf eine Maximallänge von 5 Metern ausgelegt ist, müssen 2 Netzteile verwendet werden und je eine Leiste für die Hälfte des Bettrahmens genutzt werden. Die von einem Netzteil zur Verfügung gestellte Spannung ist nicht ausreichend um die gesamte Länge zu versorgen (es tritt ein Flackern und falsche Farbdarstellung auf). im Idealfall liegen beide Anschlüsse bzw. IR-Empfänger an einem Ende der beiden Leisten, sodass diese von der Diode des PI aus sichtbar sind (am besten eine der hintern Ecken des Bettes, damit man die Kabel gut verstecken kann). Der Raspberry selbst wird später ebenfalls mit Klettband am Bettrahmen befestigt.

Die LED Leisten werden auf die verbleibende Seite des Klettbandes angebracht und entlang des Rahmens befestigt (Durch das Klett können diese flexibel ausgetauscht werden, falls eine Leiste einmal kaputt geht).

An dieser Stelle ist der Bettrahmen fertig vorbereitet. Entlang des Rahmens sind die Lichtleisten montiert und die IR Empfänger sind beide in einer der hinteren Ecken des Bettes angebracht.

Die Stromversorgung wird durch eine Mehrfachsteckdose zur Verfügung gestellt.

Einrichtung des Raspberry PI:

Nun geht es an den Raspberry. Hier ist eigentlich nicht viel zu tun, außer das besagte IR-Shield auf die GPOI Pins aufzustecken und die SD-Karte für die Nutzung mit Raspbian vorzubereiten (entweder via NOOBS oder Installation per Hand). Nach der Installation und dem ersten Start von Raspbian sollten einige Basis-Einstellungen durchgeführt werden, sodass die weitere Arbeit erleichtert wird. Der Raspberry sollte im lokalen WLan kommunizieren, da ein zusätzliches Netzwerkkabel unter dem Bett eher umständlich ist und die Fernbedienung via website / mobile web App möglich sein soll.

Weiterhin empfiehlt es sich, den PI für einen Zugang über VNC und SSH einzurichten, sodass auf dem Gerät auch im, unter dem Bett montierten Zustand, "deployed" werden kann.

Nun zum spannenden Teil, dem Einrichten des IR-Sensors:

( Es empfiehlt sich, vorher das Betriebssystem des PI auf den neuesten Stand zu aktualisieren )

Zur Interaktion des Betriebssystems mit dem IR Sender / Empfänger wird LIRC verwendet. Die Installation erfolg über

apt-get install lirc -y

Im Anschluss muss der Sender / Empfänger im System bekannt gemacht werden (die verwendeten GPIO Pins registriert). Dies geschieht via Eintrag in der "/etc/modules“ mit den Zeilen

lirc_dev
lirc_rpi gpio_out_pin=18

In der Datei "/boot/config.txt„ wird die folgende Zeile eingefügt:

dtoverlay=lirc-rpi,gpio_in_pin=18,gpio_out_pin=17

LIRC benötigt darüberhinaus eine entsprechende Konfiguration in der Datei: "etc/lirc/hardware.conf“ Folgende Einstellungen werden durchgeführt:

LIRCD_ARGS="--uinput"
LOAD_MODULES=true

DRIVER="default"
DEVICE="/dev/lirc0"
MODULES="lirc_rpi"

Nun wird der Raspberry neu gestartet (shutdown -r now )

Erster Funktionstest des Empfängers:

Zum Testen der Funktion muss der LIRC Dienst kurzzeitig beendet werden. Dies geschieht via:

/etc/init.d/lirc stop

Nun kann mit dem Aufruf:

mode2 -d /dev/lirc0

Der Empfänger gestartet werden. Ein Tastendruck auf der Fernbedienung muss nun zu einer Reaktion in der Ausgabe führen, dann funktioniert euer Empfänger wie gewünscht.

Anlernen der Fernbedienung

Der nächste Schritt umfasst das anlernen der Fernbedienung. Hierbei werden den eingehenden Signalen Bezeichnungen zugeordnet um diese im Nachhinein aufrufen und versenden zu können. Um Signale bzw. Fernbedienungs-Konfigurationen anzulernen bekommen wir Unterstützung vom Tool: irrecord. Seitens LIRC gibt es eine Menge an zu vergebenen Bezeichnungen, die für das anlernen verwendet werden können wie z.B. KEY_OK. Die Liste kann über eine Option von irrecord ausgegeben werden.

Das lernen der Fernbedienung wird gestartet über:

irrecord -d /dev/lirc0 <Pfad zur Datei in der die config abgelegt wird>

Das Tool selbst führt durch den Prozess und am Ende ist die Konfigurationdatei gefüllt. In der entstandenen config Datei kann der Parameter "Name" noch angepasst werden, um die Fernbedienung entsprechend zu kennzeichnen.

Anschließend wird die default config im Verzeichnis /etc/lirc/ durch die neu erzeugte lircd.conf ersetzt.

Hinweis: Es können Mehrere Fernbedienungen in einer Config abgelegt werden.

Nach dem Start des LIRC Service via:

/etc/init.d/lirc start

kann mit dem Aufruf irw getestet werden, ob die Signale der Fernbedienung ankommen und die richtigen Zuordnungen besitzen. Die gedrückten Tasten müssen in der Ausgabe erscheinen.

Da das montierte IR-Shield auch bereits den Sender beherbergt, kann nun via irsend Kommando ein Befehl gesendet werden. Die Syntax lautet:

irsend SEND_ONCE <name der Fernbedienung aus der config> <Key des Kommandos aus der config>

Nun hat der Raspberry das Signal ersetzt, welches eigentlich beim Tastendruck von der Fernbedienung gesendet wird.

Somit wäre die Kommunikation zwischen PI und den Empfängern der Lichtleisten gewährleistet und es geht daran, die Fernbedienung als Web App nachzubauen und mit ein paar sonder-Features zu versehen.

Umsetzen der Steureung als Python Webservices

Code auf github

Für den "Server", der die Kommandos auf dem PI ausführt, habe ich mich für Python mit Flask entschieden, weil es eine einfache und portierbare Möglichkeit darstellt, webservice Endpoints zu erstellen und command line Kommandos abzusetzen. Der Python code enthält nicht viel mehr als je einen Endpoint für jede Taste, sowie eine Möglichkeit, eine Weckzeit zu übergeben. Das Python Skript benötigt dazu die Abhängigkeiten:

Flask
apscheduler
flask_cors (insofern client und server auf dem selben PI und response nicht ordentlich)

Die via pip3 installiert werden können. Das eigentlich Skript besteht bei mir nur aus den Endpoints, den Kommandos die ausgeführt werden, dem Handling für die Uhrzeit (gespeichert in einem File) und einem scheduler für zyklische Ausführung. Das Skript sieht (verkürzt) wie folgt aus:

From flask import Flask
import subprocess
from apscheduler.schedulers.background import BackgroundScheduler
from flask import request
import atexit
import time
from flask_cors import CORS, cross_origin

app = Flask(__name__)
CORS(app)

def execute(keyIdent):
    cmd = ["/usr/bin/irsend","SEND_ONCE","led",keyIdent]
    p = subprocess.Popen(cmd, stdout = subprocess.PIPE,
                            stderr=subprocess.PIPE,
                            stdin=subprocess.PIPE)
    out,err = p.communicate()
    return "200"

scheduler = BackgroundScheduler()

@app.route("/on")
def on():
    return execute("KEY_POWER")

@app.route("/off")
def off():
    return execute("KEY_POWER2")

@app.route("/brightnessup")
def brightnessup():
    return execute("KEY_BRIGHTNESSUP")

@app.route("/brightnessdown")
def brightnessdown():
    return execute("KEY_BRIGHTNESSDOWN")

.... alle Kommandos umsetzen ....

@app.route("/sunrise")
def sunrise():
    #start on
    on()
    #red color
    red()

#brightness down max
for num in range(0,20):
    time.sleep(.5)
    brightnessdown()

#brightnessup slow
for num in range(0,3):
    time.sleep(1.5)
    brightnessup()

#orange
time.sleep(1)
redtwo();

# brightnessup slow
for num in range(0,4):
    time.sleep(1.5)
    brightnessup()

#yellow
time.sleep(1)
redthree()

# brightnessup slow
for num in range(0,6):
   time.sleep(1.5)
   brightnessup()

# daylight
time.sleep(60)
return white()

# schedule new timer
def reschedule(hour,min):
    scheduler.remove_all_jobs()
    scheduler.add_job(sunrise, 'cron', day_of_week='mon-fri', hour=hour, minute=min, second=0)

# set sunrise time
@app.route("/sunrisetime", methods=['POST'])
def sunrisetime():
    request_data = request.get_json()
    file = open("remote.props","w")
    file.write(request_data['time'])
    file.close()
    readprops()
    return "200"

# read props and set new scheduler
def readprops():
    with open("remote.props", "r") as infile:
        for line in infile:
            items = line.split(":")
            reschedule(items[0],items[1])

# Shut down the scheduler when exiting the app
atexit.register(lambda: scheduler.shutdown())

if __name__ == "__main__":
#    request_data = request.get_json()
    file = open("remote.props", "w")
    file.write("6:00")
    file.close()
    scheduler.start()
    scheduler.add_job(sunrise, 'cron', day_of_week='mon-fri', hour=6, minute=0, second=0)
    app.run(host='0.0.0.0', port=8444)

Das Ganze lässt sich sicherlich noch knapper und eleganter formulieren (auch mit vernünftigen responses etc. ;) ), für Anschauungszwecke ist diese Fassung aber ausreichen.

Nach dem kopieren auf den PI und der Ausführung mit dem Kommando

python3 <meinskript.py>

läuft der Server. Nun können die Kommandos bereits im Browser durch Aufruf der entsprechenden URLs ausgelöst werden. Da wir aber wollen, dass der Server bei jedem Start des PI automatisch gestartet wird, ergänzen wir in der Datei: /etc/rc.local

nohup python3 <pfad zum python file> &

Client in JQueryMobie und Deployment auf ngix

Code auf github

Der web client modelliert die Fernbedienung und ist im lokalen WLAN zu erreichen (Webserver kommt ebenfalls auf den PI). Hinter dem client verbirgt sich eine html Seite die mit der Unterstützung von JQuery Mobile und etwas Javascript die Funktionen des Servers anspricht. Der (verkürzte) Code der Seite lautet:

<!DOCTYPE html>
<html>
<head>
    <title>LEDRemote</title>
    <meta name="viewport" content="width=device-width, initial-scale=1">
  <link rel="stylesheet" href="themes/remote.min.css" />
  <link rel="stylesheet" href="themes/jquery.mobile.icons.min.css" />
  <link rel="stylesheet" href="http://code.jquery.com/mobile/1.4.5/jquery.mobile.structure-1.4.5.min.css" />
    <link href="http://cdn.jtsage.com/jtsage-datebox/4.1.1/jtsage-datebox-4.1.1.jqm.min.css" rel="stylesheet" type="text/css">
    <script src="http://code.jquery.com/jquery-1.11.1.min.js"></script>
    <script src="http://code.jquery.com/mobile/1.4.5/jquery.mobile-1.4.5.min.js"></script>
    <script src="functions.js"></script>
    <script src="http://cdn.jtsage.com/jtsage-datebox/4.1.1/jtsage-datebox-4.1.1.jqm.min.js" type="text/javascript"></script>
</head>
<body>
<div data-role="page">
    <div data-role="header">
        <h1>Bed - LED Remote V 1.0</h1>
    </div><!-- /header -->
  <div class="ui-grid-c">
      <div class="ui-block-a"><a id="1x1" href="index.html" data-role="button" data-icon="arrow-u">UP</a></div>
    <div class="ui-block-b"><a id="1x2" href="index.html" data-role="button" data-icon="arrow-d">DOWN</a></div>
    <div class="ui-block-c"><a id="1x3" href="index.html" data-role="button" data-theme="p" data-icon="delete">OFF</a></div>
    <div class="ui-block-d"><a id="1x4" href="index.html" data-role="button" data-theme="b" data-icon="check">ON</a></div>

    <div class="ui-block-a"><a id="2x1" href="index.html" data-role="button" data-theme="b" >.</a></div>
    <div class="ui-block-b"><a id="2x2" href="index.html" data-role="button" data-theme="h" >.</a></div>
    <div class="ui-block-c"><a id="2x3" href="index.html" data-role="button" data-theme="n" >.</a></div>
    <div class="ui-block-d"><a id="2x4" href="index.html" data-role="button" >.</a></div>

  .... alle weiteren buttons ....

   <br>
  <div class="ui-grid-a">
      <div class="ui-block-a"><input id="timebox" type="text" data-role="datebox" data-options='{"mode":"timebox"}' value="6:00"> </input></div>
      <div class="ui-block-b"><a id="setSunriseTime" href="index.html" data-role="button" data-theme="b" >Weckzeit stellen</a></div>
  </div>
</div>
<div data-role="footer">
</div>
</div>
</body>
</html>

Das zugehörige Javascript spricht die Server endpoints an:

function doAjaxCall(ident,url){
    $.ajax({
        url: url,
        error: function(){
            alert("LED Bettbeleuchtung nicht erreichbar")
        },
        success: function(){
            $(ident).removeClass("ui-btn-active");
        },
        timeout: 5000 // sets timeout to 3 seconds
    });
};

$(document).ready(function() {
    // ROW one
    //off
    $( "#1x3" ).click(function() {
      doAjaxCall("#1x3","http://ledremote:8444/off");
    });

    //on
    $( "#1x4" ).click(function() {
        doAjaxCall("#1x4","http://ledremote:8444/on");
    });

    //brightnessup
    $( "#1x1" ).click(function() {
        doAjaxCall("#1x1","http://ledremote:8444/brightnessup");
    });

    //brightnessdown
    $( "#1x2" ).click(function() {
        doAjaxCall("#1x2","http://ledremote:8444/brightnessdown");
    });

    ..... alle weiteren .......

    $("#setSunriseTime").click(function() {

        var value = $("#timebox").val();

        $.ajax({
            type: "POST",
            contentType: "application/json; charset=utf-8",
            url: "http://ledremote:8444/sunrisetime",
            data: JSON.stringify({time: value}),
            error: function(err){
                alert(err)
            },
            success: function(){
                $("#setSunriseTime").removeClass("ui-btn-active");
            },
            dataType: "json",
            timeout: 1000
        });

    });
});

Zum Schluss installieren wir auf dem PI einen kleinen nginx webserver und lassen diesen unseren client zur Verfügung stellen:

sudo apt-get install nginx

Unsere Files legen wir in das Verzeichnis cd /var/www/html/ und entfernen dort die Demo Datei, die per default ausgeliefert wird. Das Kommando

sudo /etc/init.d/nginx start

startet den Service. Nun sollte der client unter der IP oder dm DNS Namen des PI im Browser zu erreichen sein.

Wer möchte kann das blinken der grünen LED am fertigen PI unter dem Bett noch ausschalten wenn es stört:

sudo sh -c 'echo 0 > /sys/class/leds/led0/brightness'

Java Forum Nord 2016

Am 20. Oktober 2016 eröffnete das Java Forum Nord interessierten Zuhörern aus der IT zum zweiten Mal die Möglichkeit zum Austausch über verschiedenste, aktuelle Themen und Strömungen des Berufsfelds. In 4 parallelen Strängen waren verschiedenste, spannende Vorträge aus allen Bereichen in und um die IT-Branche zu finden. Eine ausgewogen verteilte Mischung aus Inhalten aus der Entwicklung und Themen, die eher Prozesse und das IT-Ökosystem, sowie unser gemeinsames Zusammenarbeiten in einem Unternehmen betrachten, sorgten dafür, dass für jeden etwas Interessantes zu finden war. Der Veranstaltungsort in Hannover war ebenfalls angenehm gewählt und bot eine zentral erreichbare, gute Atmosphäre für einen spannenden Austausch, mit anschließendem Community Event im beliebten Mister Q am Hauptbahnhof Hannover.

Da ich im vergangenen Jahr die Chance hatte, auf gleich 2 der größeren deutschen Java Conferences vor Ort gewesen zu sein ( W-JAX / JavaLand ), versuche ich rückblickend darauf ein kurzes persönliches Fazit:

Das Java Forum Nord füllt meiner Meinung nach eine Lücke im norddeutschen Raum, die bereits lange vorhanden war. Wollte man als Entwickler an einer der Conference der Community teilnehmen, blieb einem bisher nicht viel übrig, als die Reise nach Berlin / Köln oder München. Dies ist, in der Regel zum einen Kosten- als auch Zeitintensiv. An dieser Stelle kann das Java Forum meiner Meinung nach seine Stärken ausspielen: Es ist lokal, kompakt und erschwinglich, bietet aber dafür ein durchaus breit gefächertes Spektrum an Themen für den interessierten Zuhörer an. Zu meinen Favoriten zählten unter anderem die Keynote von Uwe Friedrichsen mit dem Titel „Das Leben, die IT und der ganze Rest“, die zum Nachdenken und zum Blick über den Tellerrand der IT-Welt, in der wir jeden Tag agieren, aufgefordert hat. Weitere Highlights für mich waren Oliver Gierke mit einem sehr guten Einblick in die Prinzipien des „Domain Driven Design“ und Spring REST als auch der Vortrag von Mark Heckler mit dem Titel „Cool stuff, but HOW DO I GET MY COMPANY TO DO IT?!“, der Ideen lieferte, mit einem Finanzmathematischen Ansatz zu überzeugen.

Natürlich merkt man der Veranstaltung ihr recht junges Dasein und ihren, eher regionalen Kontext, an. Ich persönlich muss zugeben, dass ich bei einem eintägigen Event nicht so in „conference Stimmung“ komme, als wenn ich mich mehrere Tage mit den aktuellen Themen der IT-Welt auseinandersetzen kann. Andererseits wird hier nahezu direkt vor der Haustür ein guter Kompromiss aus Umfang und Preis geboten. Die einzige Auffälligkeit, wenn man an den JUG Terminen und anderen Conferences teilnimmt ist, dass sich Vorträge zum Teil durchaus wiederholen, aber das bietet die Möglichkeit, in diesem Zeitabschnitt Themen anzusehen, mit denen man noch nicht in Berührung gekommen ist.

Als persönliches Fazit muss ich sagen, ich würde im kommenden Jahr bedenkenlos wieder teilnehmen, da sich der Tag durchaus lohnt und mal wieder den Blick auf unser Business, das Entwickeln von Software, abseits von Alltagstrott, Prozessen und eingetretenen Pfaden, schärft.

Microservices

Vorweg sei gesagt: Ja, das Thema ist ziemlich ausgelutscht, Hype und irgendwie in aller Munde. Grund genug sich auch endlich einmal damit auseinanderzusetzen ..

Nun ist die Frage: Wo fängt man eigentlich an? Ich persönlich bin auf das Thema das erste Mal auf der JavaLand aufmerksam geworden, dort allerdings eher passiv. Zu dem Zeitpunkt wusste ich noch nicht sonderlich konkret etwas damit anfangen. Man hat also erstmal ein paar Begriffe aus diesem Kontext gesammelt, geschaut und mit der Zeit und steigender Beliebtheit des Themas, verdichtete sich auch die Vorstellung davon, was das ganze eigentlich ist.

Für mich persönlich ist es in erster Linie ein Architekturstil, welcher sich ein einer möglichst hohen Flexibilität, Modularität und Wiederverwendbarkeit ausdrückt.

Die genannten Aspekte beziehen sich hierbei nicht nur primär auf die Software selbst, sondern ebenso auf ihren gesamten Lebenszyklus und den Entwicklungsprozess an sich.

Dies ist meiner Meinung nach auch einer der Hauptgründe, weshalb es nicht ohne weiteres möglich ist, diesen Architekturstil großflächig und kurzfristig in bestehenden Strukturen zu etablieren.
Für größere Projekte die neu beginnen, kann eine solche Architektur (insofern sie notwendig erscheint) einkalkuliert werden. Das bedeutet aber nicht, dass es nicht vielleicht einen Mittelweg geben kann..

Eine Idee wäre es, zum Beispiel, Modularisierung bereits im Monolithen zu treiben und zu fokussieren sodass die Trennung und Modularisierung nicht nur auf der Ebene der Schichten (Persistenz / BL / UI) geschieht, welche lose gekoppelt miteinander interagieren, sondern auch Fachlich bereits getrennt wird. Eventuell eine vertikale Fassade, die eine Menge von Fachobjekten die eine bestimmt Funktionalität oder einen Service realisieren, kapselt. 

Jedenfalls würde die beschriebene Variante einer späteren Trennung in einzelne Services in die Hände spielen, die Fassaden werden auf REST Schnittstellen umgelegt, die Logik in eine gekapselte Deployment Unit herausgezogen und die Persistenz auf ein eigenes Schema oder eine eigene DB verlegt.

Allerdings liegt auch hierbei der Teufel im Detail. So unproblematisch das ganze klingen mag, werden hier und dort sicherlich Fallstricke auftauchen.. 

Ein Grund dafür, weshalb sich nicht nur der Fokus auf die Software, sondern auch der Entwicklungsprozess anpassen muss, um diese Konzepte zu unterstützen. Deployment-Zyklen von 1/2 Jahr oder länger, lassen wenig Raum für "Experimente". Teams mit enormer Fluktuation machen es schwierig, die Software zu warten und weiterzuentwickeln. Aufwändige und manuelle Prozesse (Test sowie Deployment) machen es schwierig, Anpassungen zu verteilen und zeitnah zur Verfügung zu stellen.

Technische Werkzeuge und Prozesse funktionieren nur gemeinsam mit den Menschen die sie nutzen. Deshalb ist ein Team, dass hinter dem Gedanken steht und Verantwortung übernehmen möchte, in diesem Zusammenhang genauso wichtig, wie die architektonischen Prinzipien, die Werkzeuge und die Prozesse.

Bereits ohne jetzt zu sehr in die Tiefe zu gehen ( es gibt haufenweise Artikel dazu ) stellt sich heraus, dass es sich hier um eine Umstellung im großen Kontext handelt, anstatt um Feintuning. Die Darseinsberechtigung von Monolithen oder stark verteilten Systemen zu diskutieren würde an dieser Stelle ebenfalls den Rahmen sprengen.

Ich für meinen Teil werde das Thema weiterhin im Auge behalten und hoffentlich auch etwas Praxiserfahrung diesbezüglich einsammeln können. Insbesondere die Netflix-Implementierungen im Zusammenhang mit Spring Boot haben es mir angetan und müssen zu mindestens exemplarisch mal ausprobiert werden. Eventuell werde ich dann auch mal meinen Knoten im Hirn bezüglich Docker los.

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

WJAX 2015 München 01.11.2015 - 05.11.2015

Ich hatte das Glück, durch einen internen Wettbewerb meines Arbeitsgebers, ein Ticket für die ersten 4 Tage der diesjährigen W-JAX zu bekommen. Also Koffer gepackt und am 01.11.2015 ab in den ICE nach München. Nach einigen, wie immer spannenden Erfahrungen mit dem Preis / Leistungsverhältnis der Deutschen Bahn, ging das ganze auch recht reibungslos vonstatten.

Zuerst die Frage: Mit welchen Erwartungen fährt man eigentlich zu einer Konferenz? Nunja, da es sich nicht um den ersten Konferenzbesuch handelte, war dies nun nicht mehr komplettes Neuland. Daher waren die Erwartungen an dieser Stelle schon weitestgehend fachlich geprägt, da der Ablauf nicht so neu und aufregend ist. Ich habe also für mich erwartet, mir einen Überblick über aktuelle Trends und Strömungen im Bereich der Java-Welt, insbesondere im Bereich der Web-Welt im Java Ökosystem zu verschaffen.

Die Vortragsthemen waren im Voraus durch die Agenda bereits bekannt, somit konnte ich mich entsprechend vorbereiten. Meine Schwerpunkte legte ich (insbesondere aus aktuellem Projektkontext heraus) auf die Bereiche: AngularJS, REST, Security, JavaScript. Aber auch abseits davon wollte ich einen Blick werfen, insbesondere auf den "Microservices" hype oder auch auf Frameworks wie "React" von facebook. Kurzum, 4 vollgepackte Tage mit umfangreichem Programm.

Zum Rahmen der Conference ist zu sagen, dass der Veranstaltungsort durchaus imposant wirkt. Das Westin Grand Hotel in München bietet eine edel wirkende Kulisse mit Marmorfußböden, einem Ballsaal und diversen Tagungsräumen auf 3 Etagen. Allerdings wirkte der Ort zu mancher Zeit doch sehr überfüllt. Insbesondere an den Kern-Tagen der Konferenz, von Di-Mi, war es doch ein ziemliches gedrängel auf den Gängen, auf denen auch noch namenhafte IT-Partner ihre Messestände aufgstellt hatten. Das Platzangebot an Stühlen war nicht immer in allen Tagungsräumen ausreichend, so musste bei beliebten Themen auch stehend zugehört werden. Bezüglich der Essensausgabe liegt das Problem wahrscheinlich eher im deutschen Touristen Schwarmverhalten, denn es war auf jeden Fall genug für alle da. Hungrig musste dort niemand in die Vorträge gehen. Die Qualität des Essens war ausgesprochen posotiv zu bewerten, wenn man beachtet, wieviele Personen gleichzeitig versorgt werden mussten.

Aber nun zum eigentlichen Plan: In den Bereichen die ich mir auf den geistigen Zettel geschrieben hatte, besuchte ich die folgenden Vorträge:

Architektur / Sicherheit:

  • So sieht's aus! Architekturüberblicke Tipps und Tricks - Stefan Zörner
  • Sicherheit in Single-Page-Webanwendungen - Philipp Burgmer
  • The Web Application strikes back - Dominik Schadow
  • Know your Enemies: Problembewusstsein als Grundlage von Änderung und Innovationsprojekten - Gernot Starke

Test:

  • Behaviour-driven Develoment in plain Java - Dr. Jan Schäfer

Agile Methodik:

  • Agile Verteilung: Geht nicht, gibts nicht! - Dr. Carola Lillienthal / Henning Schwentner
  • Agil wachsen - Judith Andresen
  • Train your Brain: Google Style - Markus Wittwer
  • Agile Coach zu werden ist nicht schwer... - Gerrit Beine
  • Ich gestalte mein Unternehmen mit - Konstantin Diener

Angular JS 1.x / 2.0 / ES6 / Typescript:

  • Angular JS 2.0 Migrationspfade von 1.x zu 2.0 - Manfred Steyer
  • AngularJS und TypeScript: verliebt, verlobt, verheiratet - Kai Tödter
  • Demystifying AngularJS 2 SPAs für das Web von Morgen - Philipp Tarasiewicz

REST:

  • REST 2015 - Silvia Schreier
  • REST Architekturen erstellen und dokumentieren - Martin Walter

React:

  • ReactJS und JavaScript 2015 Moderne Web-Technologien in Großprojekten erfolgreich einsetzen - Roman Schiefer
  • Mit React UI Komponenten für das Web entwickeln - Nils Hartmann

Mcroservices:

  • Reactive Design Pattern - Roland Kuhn
  • Reaktive Geschäftsanwendungen - Arno Haase

Laxar JS:

  • Einen Sack voll Flöhe hüten, oder: Choose your own Technology bei der Entwicklung modularer Webanwendungen - Tobias Haustein / Michael Kunze

Keynotes:

  • The Journey of a Bank where IT took the lead - ING
  • Application Services that learn - IBM
  • Connecting Things at Scale - SAP
  • Not just DevOps.. BizDevOps! - RedHat
  • Innovation in der Realität - Technologie in 99 Prozent der Projeckt - Accenture

Zu jedem der Vorträge hier ein einzlenes Feedback zu geben, würde hier den Rahmen sprengen. Die Qualität der Vorträge war durchmischt. Es gab informative Vorträge, motivierende Vortrage, Vorträge die begeistern, Vorträge die zum nachdenken anregten und Vorträge die enorme fachliche Tiefe besaßen.

Alles in Allem muss ich sagen, dass die Menge an komprimierter Information für 4 Tage schon wirklich enorm ist. Man kann einfach nicht alles behalten, was dort vermittelt wird. Wer den Anspruch hat, allwissend wiederzukehren wird enttäuscht sein, es bleibt an jedem selbst die Inhalte nun zu festigen, zu vertiefen und ins Unternehmen zu tragen. Ein besonders angenehmer Aspekt ist auf jeden Fall die Verfügbarkeit der Materialien, was die Teilnehmer davon entbindet, hektisch mitzuschreiben und die Möglichkeit schafft, sich wirklich auf die Vorträge zu konzentieren.

Da ich dieses Jahr das Glück hatte, an 2 Konferenzen teilnehmern zu dürfen, könnte man nun die Frage stellen: welche davon war denn besser, die W-JAX oder die JavaLand? Die Antwort ist: Ich denke das lässt sich so pauschal einfach nicht beantworten, beide haben ihre Stärken und Schwächen an verschienden Stellen. JavaLand hat eine tolle Location und familiäre Atmosphäre, man spürt viel stärker, dass die Veranstaltung aus der community heraus kommt, aber ist nicht so umfangreich wie die Wjax es ist (aber was nicht ist kann ja noch werden). Die WJax hingegen wirkt überlaufen und mehr auf kommerzielle Ziele des ausrichtenden Verlags ausgerichtet. Beide haben Vorträge mit guter Qualität die sich sehr gut ergänzen, selbst wenn man beide in einem Jahr besucht.

Ich für meinen Teil, würde jederzeit wieder beide besuchen und hoffe, dass ich auch in Zukunft nochmal wiederkommen werde.

Countdown WJax 2015

Nur noch wenige Tage dann geht es endlich los nach München zur diesjährigen WJax. Ich bin wirklich sehr gespannt, da es mein erster Besuch dort ist. Ich habe bereits das Vortragsprogramm ausgiebig studiert und stehe oftmals wieder vor der Wahl, welcher Vortrag spannender ist, wenn mehrere gleichzeitig stattfinden. Vom Themenspektrum werde ich meinen Fokus wohl auf Agile Methodik , REST und Angular legen, da dies Themen sind, die momentan in meinem Projektalltag wichtig sind. Aber auch der Blick über den Tellerrand im Bereich Microservices oder Lego Mindstorms finde ich spannend. Ich werde mich einfach mal überraschen lassen.

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...

Review: JavaLand 2015

Vergangene Woche war es endlich soweit: die JavaLand Konferenz öffnete Ihre Pforten für etwa 800 Entwickler und ich war live dabei. Wie es dort war und welche Eindrücke ich gewinnen konnte, möchte ich hier gern festhalten.

Bei der Anreise gab es bereits den ersten Höhepunkt zu sehen, das Hotel Ling Bao auf dem Gelände des Phantasialands, mit seinem beeindruckend asiatischem Stil. Dieser zieht sich von der Fassade bis zum Design der Zimmer konsequent durch und schafft ein tolles Ambiente für eine ruhige Nacht vor Konferenzbeginn. Also am Abend nochmals den Plan für die Vorträge des nächsten Tages studiert und ab ins Bett.

Nach einem super Frühstück ging es dann los zum Eingangsbereich des Parks. Was sofort auffiel: kein Gedrängel, keine langen Schlangen, keine ewigen Wartezeiten. Einmal kurz gescannt und schon ist man im Park. Bei all den Eindrücken die man dort beim ersten Rundgang gewinnen konnte, war es schwierig nicht den Anfang der Keynote zu verpassen.

Inhalt der Keynote war ein kurzweiliger Überflug über 20 Jahre Java Geschichte aus einer erfrischend persönlichen Sicht von Marcus Lagergren. Im Anschluss an die Keynote begannen die einzelnen Konferenztracks mit parallelen Vorträgen in verschiedensten Bereichen. Für den Ersten Konferenztag sah meine Zusammenstellung wie folgt aus:

Einführung in Grafik- und UI-Design für Entwickler by Alexander Klein

How Java EE and DevOps Will Work Together by Ivar Grimstad

Code Reviews: Techniken und Tipps by Rabea Gransberger

Lessons Learned from Real-World Deployments of Java EE 7 Arun P. Gupta

Tweet4Beer! Beertap Powered by Java Goes IoT and JavaFX by Bruno Borges

Make or Break: The Big Impact of Small Changes in Performance by Daniel Mitterdorfer

2000 Zeilen Java-Code - oder 50 Zeilen SQL? by Lukas Eder

Nashorn: Javascript on JVM, from Scripts to Full Apps by Bruno Borges

Zum Ausklang eines langen Konferenztags folgte ein weiteres Highlight. Der Open-Park Abend, an dem eine Vielzahl an Fahrgeschäften des Parks nutzbar waren. Auch hier war es fast so als wäre man im Park nahezu allein unterwegs: keine Schlangen, keine Wartezeiten sowie super Essen und Getränke soviel man möchte.

Der zweite Konferenztag begann entspannt nach einem guten Frühstück. Auf meiner Auswahl standen für diesen Tag:

7 Security-Tools und -Bibliotheken für (fast) jede Webanwendung by Dominik Schadow

Hack that Website! by Stefan Schlott

Enterprise-Anwendungen mit JavaFX by Hendrik Ebbers

IoT Magic Show Stephen Chin

Build Game 2048 with JavaFX and Java 8: Lessons Learned Bruno Borges

Java Persistence in Action – jenseits des Entry-Levels Dirk Weil

Sämtliche Vorträge waren auf ihre Art spannend und Lehrreich und man konnte einen Einblick in die einzelnen Themengebiete erlangen. Aber auch abseits der Vorträge gab es jede Menge zu lernen und zu sehen. In unterschiedlichen Bereichen wie z.B dem Hackergarten konnte man seine Kenntnisse vertiefen. Leider fehlte am Ende doch die Zeit, um alles mitzunehmen, was man gern mitgenommen hätte.

Mein persönliches Fazit:

JavaLand bietet eine breites Spektrum an Vortragsthemen aus verschiedensten Bereichen rund um die Java-Entwicklung an. Als Teilnehmer muss man sich auf jeden Fall Prioritäten setzen, denn es besteht keine Chance wirklich alles zu sehen, was einen auch interessiert. Die Vorträge selbst bieten in den 45 Minuten, die pro Talk zur Verfügung stehen, einen guten Einblick in die Themen und viele Ansatzpunkte, um im Nachhinein selbst aktiv zu werden und sich in den Themen weiter zu vertiefen.

Die Location ist für eine Konferenz wirklich einmalig. Ein super entspanntes Setting, abseits vom Alltagsstress. Entspannte Teilnehmer, die Spaß daran hatten sich auszutauschen und eine tolle Organisation, die wirklich reibungslos funktioniert hat. Essen und Getränke mehr als man ja schaffen würde zu probieren und dazu noch der Open-Park Abend als absolutes Highlight.

Wenn ich die Möglichkeit hätte würde ich jederzeit wieder teilnehmen.

Absolute Empfehlung.

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.