Veranstaltungen

DDD Strategic Design im Kontext von Microservices (Michael Plöd)

Do, 13. Juli 2017

Event Sourcing (Marco Heimeshoff)

Do, 10. August 2017

Kalender als XML und iCal

Wir unterstützen...

Elterninitiative Kinderkrebsklinik e.V

Kinderkrebsklinik e.V

Sponsoren

Wir danken unseren Sponsoren:

Permanente Sponsoren

Uni Düsseldorf
(Raum und Beamer)


(Preise)


(Preise)


(Preise)


(Preise)

Mitgliedschaften



java.net Member

Events

gearconf 2012 am 25. und 26. Juni in Düsseldorf | Print |
Written by Heiko Sippel   
Monday, 28 May 2012 10:34

Unter dem Motto "Von der Versionskontrolle bis zu Continuous Delivery" findet die vierte gearconf in Düsseldorf statt. Sprecher wie Eberhard Wolff, Christian Binder und Stefan Scheidt informieren wieder über Tools und Methoden bei der Software-Entwicklung im Team. An zwei Tagen in zwei Tracks können Besucher sich in Vorträgen und Workshops über Werkezueg und Best Practices informieren. Subversion und git, Jenkins und maven, Spock und Unit-Tests sind nur einige der behandelten Themen. rheinjug-Besucher erhalten 20 % Rabatt auf den Eintrittspreis, und weitere Ermäßigungen sind auf Anfrage möglich. Alle Informationen unter www.gearconf.com.

 
Nachlese: Eclipse-Abend | Print |
Written by Michael Jastram   
Thursday, 26 April 2012 19:59

An diesem Abend hatten wir bei der rheinjug mal ein ein anderes Format: Statt einem langen Vortrag, der in die Tiefe geht, gab es vier Kurzvorträge, die unterschiedliche Themen rund um Eclipse beleuchteten. Die 120 Besucher an diesem Abend waren begeistert.

Ralph Müller machte eine lustige Rundfahrt durch die zehnjährige Lebensgeschichte der Eclipse Foundation: von den Anfängen bei IBM, über die Gründung der Eclipse Foundation, bis heute, wo mehr und mehr Firmen der Fundation beitreten, deren Geschäft weit über reine Software hinausgeht - Autos, Telefone, Flugzeuge und vieles mehr.

Nach diesem Überblick ging Lars Vogel in die Tiefe und zeigte, wie die Reise hingeht: Nämlich zu Eclipse 4, das es schon seit einiger Zeit gibt, aber bald Eclipse 3 komplett ablösen soll. In Eclipse 4 gibt es noch viele Bugs, da machte Lars auch keinen Hehl draus. Denn die Architektur wurde komplett neu aufgesetzt. Eclipse 4 ermöglicht vieles über Konfiguration zu realisieren, was bei Eclipse 3 Java-Code erforderte. Zum Beispiel lässt sich jetzt eine leere Anwendung ohne eine einzige Zeile Code konfigurieren. Eclipse 4 realisiert nun auch vieles über Dependency Injection. Eclipse 3.8 wird das letzte 3er Release sein, nach aktueller Plannung.

Die Anzahl der händischen Schritten zu reduzieren, zeitnah den Beteiligten im Entwicklungsprozess Feedback zu geben und alles Irrelevante auszublenden, darum ging es bei dem Vortrag von Steffen Pingel. Das Ergebnis ist Task-focussed Development. Dazu stellte er als erstes Mylyn das schon lange Teil von Eclipse ist, und das vielen rheinjug-Besuchern auch ein Begriff war. Dort demonstrierte er, wie Eclipse, Bugzilla, Jenkins und Git in enger Integration zusammenwirken. Als Bonus zeigte er dann noch, wie man Gerrit vor das Repository setzen kann, um Code Reviews durchzuführen - ebenfalls nahtlos in die Eclipse IDE eingebunden. Diese Werkzeuge leben alle unter dem Mylyn Toplevel-Projekt bei Eclipse.

Jan Köhnlein stellte zum Schluss noch XText vor, ein Framework zum Erstellen von Domänen-Spezifischen Sprachen (DSLs). Nach einer kurzen Einführung in die Architektur, ging es dann aber gleich ans Programmieren. Nach einer Schnelleinführung in Grammatiken, nahm er sich eine fertige vor und generierte mit ein paar Klicks eine Sprache daraus. Ohne weiteres Zutun entstand ein Eclipse-Editor, der Auto-Complete, Syntax-Highlighting und weitere fortschrittliche Features unterstützte - ohne weiteres zutun. Als nächstes nutzer er XTend, um eine enge Integration zwischen Java und der neuen DSL zu generieren.

Leider musste Lars uns direkt nach seinem Vortrag verlassen - aber die anderen Dozenten blieben noch eine Weile, um bei einem Bier die Themen des Abends zu vertiefen.

Wir hatten übrigens eine gute Mischung bei den Betriebssystemen: Ralph benutzte Mac, Lars Gnome, Steffen KDE und Jan war wieder ein Mac-Nutzer.

 
Nachlese: Spock | Print |
Written by Michael Jastram   
Thursday, 09 February 2012 20:21
Igor Drobiazko

Das Spock-Framework macht Testen einfacher - das Verspricht Igor Drobiazko in diesem Vortrag. Dieses Thema hat 65 Besucher an die Heinrich-Heine Universität gelockt.

Wieso brauchen wir überhaupt ein neues Test-Framework? Denn davon gibt es schließlich viele. Allerdings unterscheiden sich viele dieser Frameworks nicht sonderlich, was die Features betrifft. Und wirklich elegant sind sie alle nicht. Hinter Spock steckt die Philosophie, dass Groovy zum einen vieles, das zum Testen notwendig ist, schon von Haus aus zur Verfügung stellt (z.B. sind keine Asserts notwendig), zum anderen lässt sich vieles wesentlich eleganter als in Java ausdrücken.

Eine Test-Klasse in Spock nennt sich "Specification" und besteht aus mehreren Teilen die durch Labels wie "when", "then", und weiteren voneinander getrennt sind. Der Clou ist, dass in der "then"-Sektion das steht, was erwartet wird, und zwar als Ausdruck. Um die max()-Methode zu testen, würde da also z.B. Math.max(1,3) == 3 stehen. Wenn nun ein Fehler auftauchen würde, würde Spock den Ausdruck ausdrucken und mit Labeln versehen, die die vorgefundenen Werte zeigt.

Als nächstes lernten wir mehrere Features kennen, die das Schreiben von Testen einfach angenehmer machen: Von Groovy-Features wie besserem Auto-Boxing und Typerkennung, bis hin zu Eingabetabellen für Tests, die den selben Test übersichtlich mit unterschiedlichen Parametern ausführen.

Doch am beeindruckensten sind die Fähigkeiten von Spock beim Mocking. Mit wenigen Zeilen Code werden Mock-Objekte erzeugt. Die Auswertung der Mockobjekte erfolgt dann im "then" block. Dabei können Wildcards, und sogar Closures eingesetzt werden. Insbesondere Closures lösen wesentlich eleganter, was Frameworks wie Mockito mit Captchas lösen.

Das Fazit: Auch für Entwickler, die sich (noch) nicht mit Groovy auskennen, konnen schnell gut lesbare Tests produziert werden. Der einzige Wermutstropfen ist, dass zur Zeit die Unterstützng von Spock in Eclipse noch nicht so ausgereift ist wie die in IntelliJ.

Auch diesmal haben wir wieder Spenden für die Elterninitative Kinderkrebsklinik gesammelt. Zusammen mit der Sammlung vom Januar-Vortrag haben wir €59,83 bekommen, und wir werden den Betrag wie immer verdoppeln und €120 überweisen.

Wie immer wurde beim Bier hinterher noch das eine oder andere Thema lange weiter diskutiert.

 
Nachlese Adam Bien | Print |
Written by Michael Jastram   
Thursday, 22 March 2012 11:42

Obwohl die Anmeldezahlen auf Xing zeitweise die 200-Teilnehmer-Grenze überschritten hatten, waren letzten Endes doch "nur" 190 Teilnehmer in Hörsaal 5C - was immer noch eine beachtliche Leistung ist. Wir werden ab jetzt weiter die Hörsäle nutzen, die dichter am Eingang liegen.

Adam Bien wurde schon während den Ankündigungen herangezogen, um mit Quiz-Fragen die Gewinner der Verlosungen zu finden. Das war eine kleine Erinnerung an die Anfangszeiten der rheinjug, als wir das noch regelmäßig gemacht hatten - bis uns die Fragen ausgingen.

Viele Folien gab es bei Adam Bien nicht: Er erzählte einiges zum Java Community Prozess und versuchte uns klar zu machen, dass es sich hier nicht um einen Architekturelfenbein handelt, in dem praxis-ferne Architekturentscheidungen gefällt werden, sondern um erfahrene Entwickler und Architekten, die Dinge berücksichtigen müssen, die Otto-Normal-Programmier kaum erahnen könnte. Er hat allen nahe gelegt, die Diskussionen im JCP zu verfolgen, die alle offen und transparent stattfinden.

Aber dann ging es ans eingemachte: Adam startete NetBeans und fing an, drauflos zu hacken. Als Arbeitsbeispiel schlug er vor, eine neue, webbasierte Verlosungsanwendung für die rheinjug zu entwickeln. An diesem Beispiel hangelte er sich mit einer athemberaubenden Geschwindigkeit voran und stellte viele verschiedene Konzepte vor - zum Thema Schichten, Testen, Abstraktionen, und vielem mehr. Das ganze gestaltete er interaktiv, griff Fragen vom Publikum auf, diskutierte diese und setzte sie sofort um.

Auch wenn das Ergebnis (noch) nicht für die Verlosungen der rheinjug einsetzbar ist (um am Erscheinungsbild zu arbeiten war keine Zeit), so war es doch beeindruckend zu sehen, wie schnell man eine Webanwendung mit Java bauen kann, und wie viele praxisnahe Tipps es dabei gab. Die Fragen und der anschließende Applaus bestätigten, dass jeder etwas Hilfreiches mit nach Hause genommen hat.

 
Nachlese: Woher kommen Softwarefehler? | Print |
Written by Michael Jastram   
Thursday, 19 January 2012 19:50

Professor Zeller hat dem Lehrstuhl für Softwaretechnik und Programmiersprachen einen Besuch abgestattet, und die rheinjug hat ihn dann gleich für einen Vortrag rekrutiert. Das Thema kam gut an - es fanden sich 165 Besucher ein, die sich neue Einsichten rund ums Thema Softwarefehler erhofften.

Neue Einsichten hatte Prof. Zeller einige zu bieten. Ganz allgemein fokussierte er sich auf die drei Themen Diagnose, Erkennen, Vorbeugen.

Um die Problematik deutlich zu machen, wurden erst diverse Probleme vorgestellt - diese variierten vom Kampfjet bis zur einfachen Adressenanwendung. Dort wurde dann im Detail analysiert, wo die Fehlerursache war, und was die Geschichte hinter den einzelnen Problemen war. Damit wurde der Rahmen gesetzt.

Testen ist ein wichtiger Aspekt vom Debuggen. Viel Hilfe können einem Werkzeuge anbieten, die entweder Interaktionen mit der Software aufzeichnen, oder sogar automatisch Tests erzeugen. Ein Beispiel ist Exsyst, ein Werkzeug, dass vollautomatisch und ohne irgendwelche Anforderungen an den Nutzer, GUI-basierte Programme testet. Exsyst wird hoffentlich im Laufe dieses Jahres in der Open Source veröffentlicht. Das Programm soll es bald auch für Webanwendungen unter trywebmate.com geben. Sehr cool!

Nun zum Thema Vorbeugen: Wer macht mehr Fehler, junge oder alte Entwickler? Die Antwort ist alte, das liegt aber daran, dass die jüngeren gar nicht an den schwierigen Code drankommen. Wie nützlich sind Metriken, und welche Rolle spielen Programmiersprachen und Bibliotheken? Aufschlussreich war dabei, dass viele Fehler oft da auftauchen, wo schon viel unternommen wird: Zum Beispiel finden sich in gut getestetem Code mehr Fehler als in schlecht- oder gar nicht getesteten Code. Das liegt aber - wie bei dem Entwicklerbeispiel - oft daran, dass gerade dort, wo es schwierig ist, viel investiert wird. Die Investition lohnt sich (viel Testen == viele Bugs gefunden), aber ändert nichts daran, dass viele Bugs in dem komplizierten Code trotzdem unerkannt bleiben.

Die zahlreichen Fragen bestätigten, dass Prof. Zeller einen Nerv getroffen hast. Das Thema wurde beim anschließenden Bier noch lange weiter diskutiert, und viele Besucher gingen mit neuen Ideen nach Hause.

 
<< Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>

Page 9 of 14