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

Nachlese: Java und SQL | Print |
Written by Marc Buengener   
Saturday, 25 January 2014 12:06

Das Video ist online!

Der heutige Abend startete mit unserer traditionellen Verlosung und der Vorstellung unseres neuen Silber-Sponsoren X;O.

Mehr als 100 interessierte Besucher begrüßten Lukas Eder zu seinem Vortrag über jOOQ. Seine Mission ist es, SQL sexy zu machen.

Als Motivation stellte Lukas die Entstehung der Zusammenarbeit von Java und SQL dar.

  • Die Mühsamkeit und Fehleranfälligkeit der Nutzung von JDBC zeigte die Suche nach 6 Bugs in einem vorbereiteten verzwickten Quelltext.
  • EJB 2.0 Entity Beans ermöglichen zwar die Abstraktion von SQL, sodaß kein SQL-Code mehr erforderlich ist, doch die Konfiguration ist umständlich. Copy und Paste komplexer Konfigurationsdateien begünstigen zusätzliche Fehler.
  • Lukas lobte Hibernate für die gute Idee, Daten nur über Getter und Setter - ohne SQL - zu manipulieren. Doch er führt an, dass es drei Wahrheiten über die Geschäftsdaten gibt. Die wahren Daten in der Datenbank, die wahren Daten in den Java-Objekten und die Wahrheit des Mappings in Hibernate. Die Herausforderung liegt in der Synchronisierung dieser Wahrheiten.
  • Auf weniger Verständnis stieß die Annotatiomania von JPA und EJB 3.0 zu dem der eigentliche Standard ausufert.
Das deklarative Programmieren einer an sich schon deklarativen Sprache, nämlich SQL, stört. Eigentlich möchten wir einfach nur SQL schreiben. Nach dem Trend NoSQL möchte Lukas den Trend No, SQL! fördern. Prominente Vertreter dieser Bewegung sind Google und Apache hadoop.

Lukas hielt seinen weiteren Vortrag in Form einer Codingsession von jOOQ. In einer bestehenden Filmdatenbank-Anwendung implementierten wir weitere SQL-Anfragen. Fragen aus der täglichen Praxis der anwesenden Besucher machten seinen Vortrag interaktiv und sehr lebendig.

Zur Verdeutlichung, dass überraschend viel mit einfachem SQL möglich ist, stellte Lukas die SQL-Fensterfunktion vor. Durch sie werden subqueries vermieden. Die Fensterfunktion war den meisten der Anwesenden unbekannt, obwohl sie Teil des 2003er-Standards ist. Als ebenfalls kaum bekanntes SQL-Feature wurden row-value expressions gezeigt. Weitere Fragen ließen uns alle viel über SQL lernen und machten Lust auf noch mehr. jOOQ bietet uns die Möglichkeit mehr SQL in Java zu verwenden.

jOOQ ist eine domänenspezifische Sprache, implementiert in Java. Sie wirkt als Adapter zwischen Java und SQL. Mit jOOQ kann direkt auf die Datenbank zugegriffen werden. Komfortabler ist jedoch die Nutzung von Java-Klassen für die Datenbanktabellen, die durch einen Codegenerator erstellt werden können. Diese Klassen beinhalten neben den Attributen und Typinformationen auch die Metadaten des Data-Dictionary der Datenbank.

Bei der Formulierung der SQL-statements sind auch die Metadaten nutzbar und werden mittels Autocomplete angeboten. Bereits zur Entwicklungszeit werden die statements auf Typsicherheit geprüft.

Eine Änderung der Datenbankstruktur erfordert lediglich das erneute Starten des Codegenerators. Die Möglichkeiten der Data Definition Language werden zur Zeit von jOOQ nicht abgebildet. Temporäre Tabellen können erstellt werden.

Die Grundidee von jOOQ ist die Verwirklichung einer Database-First-Architektur. Die Daten sind das Fundament, auf dem die Applikation aufbaut. Diesem Ansatz liegt die Erfahrung zugrunde, dass sich die Applikation häufiger ändert, als die durch sie verwalteten Daten. jOOQ verfolgt also einen datenbankorientierten Ansatz und orientiert sich dabei an SQL-Standards. So kann jOOQ auch SQL-Features emulieren, die durch die Datenbank nicht unterstützt werden. Als Beispiel nannte Lukas hier den Zugriff auf die Spaltennamen und deren gleichzeitige Umbenennung während der Verwendung eines Cursors auf einer Oracle-Datenbank.

Cursor werden durch ein lazy fetching in jOOQ ermöglicht, denn grundsätzlich übernimmt jOOQ alle durch die Datenbank gelieferten Daten in den Speicher.

Neben den java-Klassen für Datenbanktabellen werden durch den jOOQ-Codegenerator auch Records mit Gettern und Settern erstellt. Durch sie können Datensätze auf dem Record geändert werden und in der Datenbank gespeichert werden.

Die Vortragszeit verging, wie im Fluge. Weitere Fragen wurden in der persönlichen Runde beim Bier geklärt.

jOOQ ist OpenSource für OpenSource-Datenbanken. Für die Anbindung an kommerzielle Datenbanken ist auch jOOQ kommerziell. jooq.org/download

Wir bedanken uns bei Lukas für seinen interessanten und wieder Freude an SQL weckenden Vortrag.

 
Nachlese Eclipse Abend 2 | Print |
Written by Michael Jastram   
Thursday, 14 November 2013 19:16

Die rheinjug hatte es an diesem Abend gar nicht so leicht, da dieser Termin leider zeitgleich mit der Devoxx lag - da haben wir leider nicht aufgepasst. Trotzdem fanden sich ca 60 Besucher ein, die wissen wollten, was sich in der Eclipse-Welt so tut. Michael Jastram stellte zunächst die Rolle der Uni Düsseldorf im Eclipse-Umfeld vor. Seit ca. zwei Jahren ist die Universität akademisches Mitglied der Eclipse-Foundation, und stellt den Ursprung des Requirements Modeling Frameworks dar. Auch wenn Eclipse schon betagt ist, stellt es doch ein enormes Ökosystem dar, welches es ermöglicht, viele Probleme schnell und effizient zu lösen.

Alexander Nyßen begann die Vortragsreihe mit GEF, das inzwischen der Standard für grafische Editoren und Ansichten in Eclipse ist und letztes Jahr zehnjähriges Bestehen feiern durfte. Zest kam dann in 2007 als Visualisierungs-Toolkit dazu. Zehn Jahre ist eine lange Zeit, und um einige der über 400 Bugs zu lösen, müsste ein Bruch stattfinden, vor dem sich aus Legacy-Gründen die Community bisher gesträubt hat. Ein Mittelweg, der bei Zest gegangen wurde, ist eine Neuentwicklung (Zest 2), die aber nicht die alte Version ablöst, sondern unabhängig davon existiert. Das selbe ist der Fall mit GEF4, welches seit 2011 in Arbeit ist. Und um Redundanzen zu beseitigen, wurden die beiden Projekte unter dem Namen GEF4 vereint. Auch wichtig für viele Nutzer: GEF4 ist unabhängig von Eclipse. Insbesondere durch die Aktivitäten von Oracle im Bereich JavaFX, hat GEF4 die JavaFX-API unter dem Namen SwtFX "nachgebaut", um eine eventuelle zukünftige Migration zu erleichtern.

Thomas Schütz beschäftigt sich mit einem ganz anderen Thema, nämlich mit Realtime Object Oriented Modeling, einem Formalismus, der vom Eclipse etrice-Projekt realisiert wurde. Eine der Stärken von ROOM ist die Einfachheit des Metamodels - im Vergleich zu UML2, zum Beispiel, um eine Größenordnung kleiner. Mit ROOM können strukturelle Modelle und Verhaltensmodelle definiert werden, von denen performanter code generiert wird, der dann auf eingebetteten System betrieben wird. Der Kreis schließt sich mit modellbasiertem Debugging, von auf dem Controller ausgeführten Code. Die wichtigesten Elemente sind hierarchische Komponenten (Actors), die über Ports miteinander verbunden sind. Weiterhin gibt es Statemachines für das dynamische verhalten. Ganz wichtig: Alle grafischen Elemente haben eine textuelle Repräsentation. Im Gegensatz zu traditionellem objektorientierten Ansatz, kapselt ROOM auch die Parallelität. Jeder Aktor hat einen logischen Thread, der natürlich in der Implementierung nicht als eigener Thread realisiert werden muss. Wie das in der Praxis aussieht, zeigte Thomas mit Beispielen aus dem Automotive- und Finanzbereich

Marcel Bruch entwickelt seit Version 2.1 mit und für Eclipse. Zunächst zog er uns den Zahn, dass Eclipse 4 (E4) für die IDE etwas ändert, nämlich zunächst gar nichts. Denn auf E4 sitzt ein Kompatibilitäts-Layer, und darauf sitzt der ganze 3.x Legacy-Code. Dann stellte Marcel einige provokante Fragen: Was stört Euch an Eclipse? Ist es noch zeitgemäß? DAss es auch anders geht, zeigte Marcel mit einem kurzen Video von Bling (?), die eine openGL-basierte Implementierung gegen die SWT-API implementiert hatten. Die wabbelnden Fenster brachten haben die Besucher definitiv beeindruckt. Eine ähnliche Initiative ist mit JavaFX in Arbeit. Aber solche Ansätze ändern die GUI ja nicht grundsätzlich - ein komplett anderer IDE-Ansatz wurde bspw. mit Code-Bubbles realisiert. Auch zum Thema Debugging zeigt Marcell ganz neue Ansätze, die überhaupt nichts mit den heute bekannten Konzepten zu tun haben. Wie ist es denn mit Eclipse im Browser? Richtig cool fand das keiner, wobei schon der eine oder andere das als Nützlich bezeichnen würde. Dazu hat das Orion-Projekt beachtliches geleistet.

Aber wo ist die Zukunft von Eclipse? Die gute Nachricht: Das Problem ist erkannt, und es wird nach Lösungen gesucht. Durch kurzes Handzeichen stellte Marcel fest, dass doch einige im Publikum €30 für Eclipse zahlen würde, aber wenige Arbeitgeber würden das tun. Zuletzt stellte Marcel noch ein Konzept vor, bei dem nicht Geld, sondern implizite Mitarbeit gespendet wird, für einen erheblichen Gegenwert: Codetrails und Snipmatch sind Ansätze zum Crowdsourcing von Programmierwissen, das nicht nur auf Java beschränkt ist. Probiert es mal aus!

Wie üblich folgte hinterher bei einem Bier - mit oder ohne Alkohol - ein reger Gedankenaustausch.

 
Nachlese JavaFX | Print |
Written by Peter Stoffels   
Friday, 12 July 2013 12:31
Nachdem vier Wochen vergangen sind hat die Rheinjug auch schon wieder ein neues Thema für die wissenshungrigen Informatiker unter uns gefunden. Diese Mal wurde uns das GUI Framework JavaFX vorgestellt. Wie der Titel vom Plakat schon verriet war Swing gestern und die beiden Präsentatoren Michael Thiele und Alexander Cascall haben dies eindrucksvoll mit Live-Demonstrationen vor ca. 100 Besuchern bewiesen. Übrigens sind die Folien und Demo-Code bei gitHub zu finden.

Also was ist JavaFX? JavaFX soll wie gesagt Swing ablösen und ist ein GUI-Framework, das mehr und mehr Einzug erhält, gerade in der Webwelt. Dies soll ferner auch für mobile Geräte mit Betriebssystemen wie iOs oder Android interessant werden, da mit JavaFX 2.0 auch Gestensteuerung möglich ist.

Womöglich jeder Java-Entwickler hat schon mal mit Swing gearbeitet und an einigen Stellen festgestellt, wie aufwendig es ist, einfache Dinge darzustellen. Dies wurde zum Beispiel anhand des Ladens eines Bildes demonstriert. Direkt im Vergleich dazu wurde ein Codeauszug von JavaFx gezeigt, der sich nur auf einige wenige Zeilen Code beschränkte. Schnell wurde klar, das Thema wird interessant. Generell hat sich viel bei JavaFX getan: Es unterstützt wie eben schon bereits Gesten (Multitouch), rendert sehr gut und schnell Animationen (durch GPU-Hardwarebeschleunigung), enthält sehr ahnsehnliche Chart-Diagramme und unterstützt u.a. auch das Abspielen von HD-Videos durch die Media Engine. Generell bietet das Framework viele ansehnliche Effekte und Tools und kann durch CSS oder FXML beschrieben werden.

Das ist gerade mit das interessante an JavaFX, dass die grafischen Oberflächen losgelöst sind von der Logik und durch XML oder CSS beschrieben werden können. Das bedeutet auch, dass grafische Oberflächen von Designern entwickelt können und Backendlogik von Software-Entwicklern. Generell verwendet JavaFX auch ein Architektur Pattern, das MVVM Pattern, welches dem Model-View-Controller Pattern ähnelt. Es definiert ein View welches via Databinding an das ViewModel gebunden ist und dieses ist wiederum an ein oder mehrere Models gebunden. Ein simples Beispiel hierfür ist ein Model Vorname und ein Model Nachname. Das ViewModel würde dann z.B. eine Komposition dartstellen: Gesamtname, welches aus den beiden Models besteht. Die Komposition oder das ViewModel dient dann als Datencontainer für ein Label z.B. welches sich im View befindet. Der Clou bei der ganzen Sache ist, dass das ganze Framework überwiegend auf Properties und Bindings aufbaut. Ändert sich also der Name im Label, ändern sich auch die Models auf der untersten Ebene und umgekehrt (Bi-Direktional).

Damit die eben genannten Beispiele auch bildlich hängen bleiben, haben die beiden live am Beamer programmiert. Dafür diente „Farmville“ als Demonstrationsvorlage. In diesem Spiel geht es darum, Gemüse vom Feld zu ernten. Problem dabei ist, dass das Gemüse einen Lebenszyklus durchläuft. Schritt für Schritt haben uns die beiden dann präsentiert, wie man solch ein Spiel in JavaFX programmieren kann.

JavaFX ist mittlerweile fester Bestandteil von JavaSDK7 und wird auch von vielen IDE’s unterstützt. Den besten Support bietet wohl Netbeans in dieser Hinsicht.

Alles in Allem war dies wieder ein klasse Vortrag. Dieses Mal von Michael Thiele und Alexander Cascall, die wirklich Freude und Spaß beim Entwickeln mit grafischen Oberflächen mit dem JavaFX Framework vermittelt haben. Bei dem einen oder anderen Zuschauer hat es mit Sicherheit die Neugierde geweckt, selbst einmal ein paar Gehversuche mit JavaFX zu starten.

 
Nachlese: Agile Entwicklungspraktiken in verteilter Entwicklung | Print |
Written by Michael Jastram   
Thursday, 10 October 2013 18:25
Gut 100 Besucher kamen an diesem Abend zur rheinjug, um Jutta Eckstein zu hören, die als Buchautorin und Keynote-Sprecherin inzwischen einen weiten Bekanntheitsgrad erreicht hat. Auch diesen Abend wurde wieder für die Kinderkrebsklinik gesammelt. Letzte Mal wurde ja speziell für Nicola gesammelt, für die die rheinjug die Spenden verdoppelt und großzügig auf €500 aufgerundet hat. Wir freuen uns, dass genug Spenden für Nicolas Krebstherapie zusammengekommen sind.

Jutta Eckstein begann, den Rahmen des Themas abzustecken. Denn "verteilte Teams" kann zweierlei bedeuteten: es können wirklich verteilte teams (distributed), oder verstreute (dispersed) Teams sein. Danach wurde dann auf die typischen Praktiken hingewiesen, wie Pair Programming, Testing, usw., sowie auf deren Mißverständnisse. Zum Beispiel ist Pair Programming nicht dafür gedacht, neue Mitarbeiter einzuarbeiten, sondern um Entwickler auf der selben Augenhöhe zusammenzubringen, um eine geimensame Kultur in der Entwicklung aufzubauen. Diese Praktiken wurden dann im Licht der verstreuten Entwicklung neu beleuchtet. Denn wenn sich die Mitglieder eines Teams nur selten sehen, dann sind diese Praktiken umso wichtiger.

Einen großen Unterschied in verstreuten Teams ist die Bedeutung von Akzeptanztests, denn diese eignen sich auch, um das System mit zu dokumentieren, da diese Tests konkrete Beispiele liefern. Dazu gab Jutta das Beispiel der Entwicklung eines Pay-TV-Systems in Indien, für einen Kunden in New York. Das Problem war, das zu dem Zeitpunkt, in Indien das Konzept des Pay-TVs sich überhaupt nichts vorstellen konnten. Das machte die Kommunikation schwierig. Die Inder haben Ihr Verständnis in der Form von ausführbaren Akzeptanztests dokumentiert, was es dem Kunden ermöglichte, das Verständnis der Entwickler zu kommentieren und zu korrigieren.

Collective Ownership ist auch schwieriger zu realisieren, wenn die Teams verteilt sind. Üblich in großen Teams ist eine exklusive Ownership für jedes Team, aber eine gemeinsame Ownership innerhalb eines Teams. Als Beispiel nannte Jutta hier wieder Indien, wo die Fluktuation von Mitarbeitern wesentlich größer ist als bswp. in Deutschland. Da kann es auch passieren, dass plötzlich das ganze Team weg ist, und das darf natürlich nicht passieren.

Refactoring sind auch kritisch, wenn sie globale Auswirkungen haben. Das kann dazu führen, dass größere Arbeiten denn am Wochenende oder sogar an Feiertagen durchgeführt werden müssen.

Zum Abschluss präsentierte Jutta noch die "Golden Rule", von einem Projekt von Joseph Pelrine: "At the end of a workday: all code is checked in; all tests run green; the build works; build time is < 10 minutes -- or you throw it all away". Sicherlich wahr für jedes agile Projekt, aber ganz besonders für verteilte.

Am Ende des Vortrags wurde Jutta Eckstein mit vielen Fragen bombardiert, und die Diskussionen gingen bei einem Bier noch eine ganze Weile weiter.

 
Nachlese Web Development: You're Doing it Wrong | Print |
Written by Michael Jastram   
Monday, 17 June 2013 14:01
Absagen gehören zur Realität eines Veranstalters, aber die Erkrankung unseres Dozenten Bernhard Löwenstein einen Tag vor der Veranstaltung brachte uns doch ganz schön ins Schwitzen. Zum Glück erklärte sich Stefan Tilkov bereit, mit dem Thema "Web Development: You're Doing it Wrong" einzuspringen, und so fanden sich auch ca. 100 Besucher ein (von denen lediglich einer den Vortrag "Java in der Ausbildung" erwartete).

Vielen unserer Besucher kennen Stefan als einen der Treiber von REST, also der Idee, die Webprotokolle so einzusetzen, wie sie konzipiert wurden. Nur das es diesmal darum ging, vernünftige Webanwendungen zu schreiben. Bei dem Vortrag handelte es sich um einen Rant: Warum darf man bei manchen Webanwendungen die Vor- und Zurückknöpfe nicht benutzen? Warum muss ein Refresh zurück zur Homepage führen? Wieso ist bei abgeschaltetem JavaScript nichts zu sehen?

Die Ideen von diesem Vortrag fürt Stefan unter dem Namen ROCA (Resource-oriented Client Architecture) zusammen. Es handelt sich dabei um eine Sammlung von Best Practices, die nicht neu sind, aber leider allzu oft vergessen und/oder ignoriert werden - sowohl von Menschen als auch - noch schlimmer - von den Entwicklern von Web-Frameworks.

Exemplarisch wurden viele Stellen gezeigt, wie man mit relativ wenig Aufwand neue und bestehende Webanwendungen drastisch verbessern kann. Zum Beispiel sollte JavaScript nur eingesetzt werden, um bestehende Präsentationen zu verschönern, aber nicht um Kernfunktionalität zu implementieren. Die Trennung von Inhalt (HTML) und Präsentation (CSS) versteht sich sowieso von selbst.

Der Vortrag warf viele Fragen auf, die zum Teil im Anschluss des Vortrags und zum Teil bei einem Bier noch weiter diskutiert wurden. Wir freuen uns, dass der Ersatzvortrag auf so viel Interesse stieß.

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

Page 6 of 14