Java Forum Stuttgart 2013

Das Forum begann direkt mit einem Highlight, vert.x : Polyglott - modular - Asynchron von Eberhard Wolff (@ewolff). VertX, ein Framework für die JVM, wurde eingeführt, und gezeigt, dass es polyglott, modular und asynchron ist. Für mich besonders interessant war,  dass man es direkt mit Groovy benutzen kann. Der Speaker hat auch besonders betont, dass der Code mit Java komplizierter ist durch die fehlenden Closures. VertX hat einen Core, welches in Java geschrieben ist, und einen sprachenspezifischen Layer. Vert.X implementiert Asynchronizität über Events, die von einem Event Loop verarbeitet werden. Der Event Loop ist ein Thread. Es wird die gleiche Anzahl Event Loops instanziiert wie es CPU Cores gibt. Jedes Teil von Vert.x kann alleine laufen oder als Modul verpackt werden. Module tauschen Nachrichten über gemeinsam benutzte Collections aus, die nur unveränderbare Daten enthalten oder über JSON (bevorzugt für Skalierung). Der Vortrag hat mich angeregt, bald was mit Vert.X auszuprobieren. Die Präsentation des Talks kann man unter http://prezi.com/bfusjp5ruxxd/vertx-polyglot-modular-asynchronous ansehen.

Als zweiten Vortrag sah ich mir Von 0 auf 100 in nur einer Stunde von Michael Jerger an. In dem Vortrag ging es darum, die Anlaufzeit bei Beginn eines Projekts extrem zu verkürzen, und mit wenigen Clicks ein lauffähiges System zu erhalten, das neben dem Betriebssystem gleich die Netzwerk, Emaileinstellungen , Tools und IDE enthält. Es wurde eine Historie des Konfigurationsmanagement gezeigt, sowie auf die drei Tools CFEngine, Puppet und Chef eingegangen. Um die Unterschiede zwischen den Tools zu sehen, wurde die Wikipedia Seite http://en.wikipedia.org/wiki/Comparison_of_open_source_configuration_management_software empfohlen. Das Projekt benutzt Puppet, und es wurde darauf eingegangen, wie man mit Puppet arbeitet. Besonders interessant, dass das Projekt mandaten-spezifisch ist, und man so generelle Einstellungen von Projektspezifischen (z.B. Benutzerdaten) abgrenzen kann. Es wurde dann gezeigt, wie in wenigen Minuten mit Hilfe des Projekts, Puppet und Virtual Box ein System lauffähig ist. Wer an dem Projekt interessiert ist, kann sich über Github https://github.com/jerger den Code herunterladen oder sogar eigene Sachen hinzufügen.

Als nächstes sah ich den Vortrag über Java Security Mythen von Dominik Schadow (@dschadow). In dem Vortrag wurden einige Mythen widerlegt, und gezeigt wie man mit Java sicher programmieren kann. Es wurde beispielsweise gezeigt, dass man auch das Login Formular über HTTPS schicken sollte, nicht nur den personalisierten Inhalt danach. Der Strict Transport Security Header hilft, damit der Browser sich immer nur mit HTTPS mit dem Server unterhält. Input Validierung wird von einigen Frameworks versprochen, doch es funktioniert nur manchmal. Man sollte sich nicht darauf verlassen, und selber testen und am besten Libraries zum Escapen benutzen, wie z.B. Enterprise Security API (https://code.google.com/p/owasp-esapi-java/). Forms immer als POST versenden hilft gegen XSRF (Cross-site Request Forgery), aber nicht wenn man Ajax benutzt. Dazu sollte man auf der Seite immer ein Access Token hinzufügen, dass nach dem Login dem Benutzer zugewiesen wird. Diese und andere Tipps kann man unter http://www.dominikschadow.de/files/event_jfs2013.pdf runterladen und den Beispielcode in https://github.com/dschadow/JavaSecurityMyths ansehen.

Im Vortrag Visuelle Codeanalyse von Thomas Haug (@tshaug) konnte man sehen, wie man mit Hilfe von Tools wie MOOSE und CodeCity den Code einlesen und grafisch ausgeben kann. MOOSE zeigt den Code als 2D Grafik an, während CodeCity ein 3D-Modell einer Stadt benutzt. Dabei werden zum Beispiel die größten Klassen als große Flächen oder hohe Gebäude angezeigt. Diese Werkzeuge benutzen als Grundlage Squarified Treemaps. Man kann verschiedene vorgegebene Grafiken anzeigen. Zum Beispiel kann man sehen wer von wem aufgerufen wird, und dabei werden Linien zwischen den Gebäuden angezeigt. Man kann auch direkt nach Code Smells suchen. Es wurde Wert darauf gelegt, dass die Visualisierung eine gute Hilfe ist, wo man schnell den Überblick sehen kann, sie sollte aber nicht alleinige Entscheidungsgrundlage benutzt werden. Es ist möglich, zwei verschiedene Systeme zu importieren und grafisch zu vergleichen. Systeme, die man nicht importieren kann, z.B. .NET, können von Sonar exportiert werden und dann von dem Tool über das Sonar Datei angezeigt werden. Als Buchempfehlung wurde „Object Oriented Metrics in Practice“ von Lanza und Marinescu (http://www.amazon.com/Object-Oriented-Metrics-Practice-Software-Characterize/dp/3540244298) gegeben. Die Folien können unter http://www.java-forum-stuttgart.de/_data/2013_A5-_Thomas_Haug-1.pdf runtergeladen werden.

Im nächsten Vortrag von Oliver Gierke (@olivergierke) Huch, wo ist meine Architektur hin? ging es darum, wie man die Architektur auf Mikroebene verbessern kann. Der Vortragende legte besonders Wert darauf, wie man die Abhängigkeiten organisiert und wie man den Code nicht nach Layers organisiert, sondern nach fachlichen Abhängigkeiten. Es ist wichtig, dass die Abhängigkeiten zwischen Packages unidirektional sind, sprich dass es zu einem klaren hierarchischen System kommt, wo die „höheren“ Packages nur von den niedrigeren (z.B util) Packages abhängig sind. In diesem Zusammenhang wurde betont, dass man Klassen auch Package Zugriff geben kann, und nur ein paar Klassen als Public deklariert werden sollten, die dann aus anderen Packages aufgerufen werden können. Die Architektur des Systems wurde mit dem Tool Sonargraph (http://www.hello2morrow.com/products/sonargraph) aufgezeigt. Den Code des Vortrags kann man in Github https://github.com/olivergierke/Whoops-Architecture, ein Blogbeitrag des Autors in http://www.olivergierke.de/2013/01/whoops-where-did-my-architecture-go sowie die Folien sind unter http://de.slideshare.net/olivergierke/whoops-where-did-my-architecture-go-11678054 zu finden.

Als letzten Vortrag des Tages hab ich Continuous Delivery in Action von Christian Faigle und Christian Baranowski (http://tux2323.blogspot.de) angesehen. Im dem Vortrag ging es darum, welche Probleme Continous Delivery löst, und es wurde gezeigt, wie man es implementieren kann. Der Build durchlief verschiedene Phasen, in dem auf unterschiedliche Systeme deployed worden ist.  Die verschiedenen Phasen wurden vom Build Pipeline Plugin (https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin) administriert. Zum Automatisieren wurde Gradle mit Buildscripts eingesetzt. Es wurde empfohlen, das gleiche Skript für alle Umgebungen einzusetzen, und die umgebungsspezifischen Einstellungen über Konfiguration zu regeln. Die Umgebungen wurden mit Vagrant und Puppet aufgesetzt und administriert. Falls man mehr über das Thema erfahren will, haben die Vortragenden das Buch „Continuous Delivery“ von Jezz Humble und David Farley (http://www.amazon.de/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912) empfohlen. Die Folien des Vortrags können unter http://prezi.com/n_ciqv21dryi/continuous-delivery-in-action angesehen werden.

Falls man sich auch noch für andere Vorträge interessiert, kann man die Folien von fast allen Vorträgen unter http://www.java-forum-stuttgart.de/de/Programm.html runterladen.

Zurück

© 2006-2024 exensio GmbH
Einstellungen gespeichert

Datenschutzeinstellungen

Wir nutzen Cookies auf unserer Website. Einige von ihnen sind essenziell, während andere uns helfen, diese Website und Ihre Erfahrung zu verbessern.

Sie können Ihre Einwilligung jederzeit ändern oder widerrufen, indem Sie auf den Link in der Datenschutzerklärung klicken.

Zu den gesetzlichen Rechenschaftspflichten gehört die Einwilligung (Opt-In) zu protokollieren und archivieren. Aus diesem Grund wird Ihre Opt-In Entscheidung in eine LOG-Datei geschrieben. In dieser Datei werden folgende Daten gespeichert:

 

  • IP-Adresse des Besuchers
  • Vom Besucher gewählte Datenschutzeinstellung (Privacy Level)
  • Datum und Zeit des Speicherns
  • Domain
You are using an outdated browser. The website may not be displayed correctly. Close