Rückblick Herbstcampus 2013

Ich war dieses Jahr eingeladen, auf dem Herbstcampus einen Vortrag über Java-Security zu halten und konnte bei dieser Gelegenheit zwei weitere Konferenztage „mitnehmen“. Insgesamt konnte ich so den ersten Workshop-Tag sowie die darauffolgenden beiden Konferenztage besuchen.

Was zählt ist auf’m Platz

Als Workshop hatte ich mir die „Testautomatisierung im Browser“ ausgesucht. Einen Tag lang domptierten wir den Browser mit Hilfe von Geb, einer Groovy-DSL/Bibliothek für Selenium. Geb machte einen gut abgehangenen und soliden Eindruck; die Dokumentation („the Book of Geb“) ist ausführlich und hilfreich.

Um Tests möglichst sauber zu strukturieren und eine hohe Wiederverwendbarkeit zu erreichen, ist es sinnvoll, seine Tests mittels Modules und Pages zu organisieren. In letzteren werden die eigentlichen Aktionen auf der Seite abgebildet, die eigentlichen Unit-Tests rufen die semantisch höher gestellten Funktionen dieser Klassen („trage als Name XY ein“ oder „sende das Formular ab“) auf.

In meinem aktuellen Projekt kommt das Play Framework zum Einsatz; ich konnte keine Möglichkeit finden, Groovy geeignet in das SBT-Buildsystem von Play zu integrieren. Glücklicherweise gibt es hier als Alternative Fluentlenium. Fluentlenium fühlt sich sehr ähnlich zu Geb an, allerdings scheint hier die Trennung in Modules und Pages zu fehlen (es gibt nur Pages).

Dabei würde sich insbesondere bei Play die Gliederung in Modules anbieten: Jedes Seiten-Snippet, das von anderen Seiten inkludiert wird, wird auf ein Module abgebildet; entsprechend der Inkludierung werden Page-Objekte zusammengestellt, welche dann letztlich für die Tests verwendet werden. Ob sich das Erzeugen des zugehörigen Codes (zumindest teilweise) automatisieren läßt? Ein Gedanke, den ich mal im Hinterkopf behalte ;-)

In den Fängen des Wirtschaftsdarwinismus

Auftakt zur Konferenz bildete der Vortrag von Uwe Friedrichsen; den Vortrag hatte er unter dem Titel Dr. hectic und Mr. Hype bereits an anderer Stelle gehalten. Seiner Beobachtung nach sind agile Entwicklungsmethoden zwar der zu bevorzugende Weg, den man momentan beschreiten sollte, in der aktuellen ökonomischen Situation reicht das alleine allerdings nicht mehr. Agilität ist auch an weiteren Stellen erforderlich. Sein Vortrag war ein Plädoyer war für den Einsatz von agiler Softwareentwicklung zusammen mit DevOps, Continuous Delivery, der Entwicklung für Deployment in Cloud-artige Infrastruktur (und einige weitere Schlagworte).

Ich gebe Uwe recht, vieles wird in Zukunft in diese Richtung gehen.

Macht der Gewohnheit

Integrationsserver mit einer Anbindung an Sonar, Checkstyle, etc. sind sicher gut, um eine „Verschmutzung“ der Quelltextbasis zu verhindern; insbesondere für Projektneulinge wäre es aber sinnvoller, dem Entwickler ein unmittelbares und direktes Feedback in der IDE zu geben, ähnlich den rot unterringelten Worten mit Rechtschreibfehlern in einer Textverarbeitung. Diese Idee verfolgt das Project Usus. Usus ist ein Eclipse-Plugin, das automatisiert Codeanalyse ausführt und den Entwickler über Fehler sowie über den Trend seiner Codequalität informiert.

Klingt interessant, habe ich auf meine Liste der auszuprobierenden Dinge gesetzt.

Hallo JS

Javascript ist anders ;-) Da ich nicht der JS-Routinier bin, dachte ich mir, ein Einstiegsvortrag in die Sprache kann nicht schaden. Das Prototypen-Objektmodell von JS war mir zwar schon bekannt, über die Sichtbarkeit von Variablen (es gibt nur Function Scope und Global Scope) wäre ich aber sicher früher oder später gestolpert. Nein, ich glaube nicht, daß JS in naher Zukunft meine Lieblingssprache wird.

Unter Beobachtung

Dieser Vortrag stellte unter dem Untertitel „Ausweg aus der Callback-Hölle“ einen Überblick über die Idee des „reactive Programming“ und dem Reactive Manifesto vor. Eine der Grundideen ist es, die Denkweise und Sicht des Entwicklers von Pull-Mechanismen auf Push-Mechanismen zu verschieben. Als Beispiel wurde im Vortrag ein Iterator mit einem Iterable verglichen. Der Iterator durchläuft eine Datenmenge, die Programmierung ist imperativ und üblicherweise synchron. Bei einem Iterable hingegen wird der Code immer dann aufgerufen, wenn Daten zur Verfügung stehen – der Programmcode „reagiert“ (asynchron) auf die eingehenden Daten, anstatt zu warten.

Die Rx-Domäne scheint zu einem guten Teil von Scala belegt zu sein, der Vortrag verwies auf mehrere Scala-Bibliotheken:

Aber auch für Java gibt es eine Bibliothek, die nach Aussage des Referenten gut abgehangen und angenehm zu benutzen ist: RxJava.

JS on Steroids

TypeScript ist eine Obermenge von Javascript, das zu reinem Javascript kompiliert. So können auf der einen Seite bestehende JS-Bibliotheken 1:1 übernommen werden, Erweiterungen mit der erweiterten Syntax und Typenprüfung von TypeScript implementiert werden. Für viele bestehende Bibliotheken stehen zusätzliche Typeninformationen bereit, um auch hier von den Vorzügen von TypeScript profitieren zu können.

TypeScript wird von Microsoft vorangetrieben und besitzt insbesondere in der Microsoft-Entwicklungsumgebung eine gute Unterstützung. Mit ähnlichen Zielen (ein „besseres JS“) sind auch CoffeeScript und Dart angetreten – CoffeeScript übersetzt ebenfalls nach JS, Dart bietet entweder seine eigene VM oder einen Compiler nach JS; im Vortrag gab es leider keinen Vergleich der Technologien, was für ein Projekt am besten geeignet ist, hängt von verschiedenen Faktoren ab.

Unabhängigkeitserklärung

Wie sorgt man als Architekt in einem Team dafür, daß die Teammitglieder Archtitekturvorgaben einhalten? Wie überprüfe ich, welches Paket Abhängigkeiten auf welches andere Paket besitzt? Degraph bietet hier eine Lösung.

Mit Degraph lassen sich sogenannte „Slices“ anhand von Paketnamen definieren. Über solche Slices lassen sich dann erlaubte Abhängigkeiten prüfen. Die Teilung in Slices erfolgt oft in mehreren Achsen, so macht es beispielsweise Sinn, in einer MVC-Anwendung Calls vom Model an eine der anderen beiden Schichten zu verbieten und gleichzeitig zwischen Views und Controller verschiedener Bereiche der Anwendung (z.B. Admin-Seiten und Rest der Anwendung) keine Queraufrufe zu gestatten.

Während des Vortrags konnte ich mehrfach nur schwer den Impuls unterdrücken, aufzuspringen und laut „Ja! Genau so!“ zu rufen ;-) Degraph werde ich definitiv auf dem Radar behalten.

You are not Facebook or Google?

Diesen Vortrag habe ich leider als Verkaufsveranstaltung verbuchen müssen. Der Untertitel „warum Sie sich trotzdem mit Big Data beschäftigen sollten“ hatte zwar neugierig gemacht, blieb mir persönlich aber die Antwort schuldig. „Kaufen Sie nicht irgendeine Big-Data-Lösung!“ lautete der Aufruf zu Beginn des Talks, denn jedes Problem sei individuell und es gäbe keinen Big-Data-Alleskönner. Dennoch wurde später Hadoop als der „De-Facto-Standard“ angepriesen. Es fanden sich noch weitere solcher Widersprüche – an sich schade, gebe ich dem prinzipiellen Tenor des Vortrags (die Big-Data-Technologien sind einen Blick wert, aber betreibe kein Big Date um seiner selbst willen, sondern betrachte den Anwendungsfall) doch recht.

Web-Anwendungen? Aber sicher!

Zum Abschluß meines Herbstcampus-Besuchs durfte ich meinen Vortrag über Java-Websecurity vom Javaforum in einer überarbeiteten XXL-Fassung halten – ein Hoch auf die 60 Minuten langen Slots! So war mehr Zeit für Demonstrationen, auch wenn die Vorführungen einen Großteil der Fragezeit kannibalisiert haben… ich hoffe, meine (rund 45) Zuhörer sahen es mir nach. Den Feedback-Bögen nach haben sie Milde walten lassen, wurde der Gesamteindruck des Vortrags im Durchschnitt mit einer 1,3 bewertet. Ja, es stimmt mich ein klein wenig Stolz ;-)

Fazit

Alles in allem hat es mir auf dem Herbstcampus wieder sehr gut gefallen. Im Vergleich zum Vorjahr (da konnte ich nur einen Tag besuchen) hatte ich den Eindruck, daß das technische Niveau nicht mehr ganz so tiefgehend war; auch hatte mir der dedizierte Scala-Track des Vorjahres sehr gut gefallen. Dennoch hoffe ich, daß es 2014 wieder mit einem Besuch klappen wird.