Newsletter

Email:


Name (optional):


Archiv (ab 2010)

Nächste Veranstaltung

Thu, 22. May 2014
Software ändern - aber richtig (Gernot Starke)

18:30 - Türen auf
19:00 - Vortrag

Anmeldung

Anmeldung mit Xing

Anmeldung ohne Xing

Alle Veranstaltungen kostenlos

Verlosung nur an angemeldete Gäste

Silber-Sponsoren

Don't get lost in data, get information

ABIT GmbH - Beratung - Software -  Seminare - Veranstaltungen - NewsCreating digital success. | ecx.io

Oracle University - Offizieller Anbieter von Schulungen und Zertifizierungen zu Oracle Technologie

Veranstaltungen

Thu, 22. May 2014
Software ändern - aber richtig (Gernot Starke)

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)


(Organisation und Marketing)


(Preise)


(Preise)

Mitgliedschaften

java.net Member

Nächster Vortrag: Software ändern - aber richtig (22.05.)
Written by Lukas Ladenberger   
Wednesday, 12 March 2014 08:31

Ich bringe Ihnen nahe, worauf es bei Evolution, Wartung und Änderung von Software wirklich ankommt. Den größten Teil unseres Informatikerlebens verbringen wir mit Anpassungen bestehender Systeme - und genau dieser Teil kommt in der klassischen Ausbildung praktisch nicht vor. Zuerst fasse ich für Sie die wesentlichen Gründe für Änderungen zusammen. Anschliessend erkläre ich in Form von Mustern und methodischen Bausteinen wesentliche Lösungsansätze:

Sinnvolles Verhalten, wenn Sie mehr Probleme als Budget haben
So finden Sie die schlimmsten Probleme
So überzeugen Sie Ihr Management von Umbaumaßnahmen
So gehen Sie mit technischen Schulden um

Dozent: Dr. Gernot Starke, innoQ Fellow, Mitgründer von arc42, Mitgründer des iSAQB e.V., Gründer von aim42.org, Autor u.a. von „Effektive Softwarearchitekturen“, dem „Knigge für Softwarearchitekten“.

 
Nachlese: Fun mit Java(FX) auf embedded Hardware
Written by Marc Buengener   
Monday, 07 April 2014 15:58

>> Zum Video

Heute Abend begrüßten wir in überschaubarer Runde Gerrit, um mit ihm Spaß mit Java, insbesondere mit JavaFX auf embedded Hardware zu haben. JavaFX auf embedded Hardware ist eine Teilmenge von JavaFX. Man muss also einige Einschränkungen in Kauf nehmen, profitiert aber von den Java-Vorteilen, z.B. einer aktiven Community. Wilde Grafikeffekte sind mit JavaFX allerdings nicht möglich. Das JDK für embedded Hardware ist aktuell noch 32 MB groß. Das Ziel ist es jedoch, den Footprint auf 16 MB zu verkleinern.

Unser Ziel ist es also, kleine Anwendungen zu schreiben, für die ein Desktoprechner überdimensioniert wäre. Als typische Anwendungsfelder nannte Gerrit
die Automatisierung der eigenen vier Wände,
Home Entertainment,
Anzeigen beliebiger Art, wie z.B. Displays für medizinische Messwerte,
sogenannte Information Kiosks, wie z.B. Bus- oder Zugfahrpläne und
den Bildungsbereich - einfach, um zu Lernen.

Auch die Hardware beschränkt die Möglichkeiten.
Empfehlenswert sind hier das
BeagleBoard xM,
das populäre Raspberry Pi und
neuere Hardware mit ARM-Architektur.

Neben dem eigentlichen Rechner sind noch
ein Netzteil,
eine Class 10 SD Memory Karte als schnelle Festplatte,
ein WiFi-Stick und
ein Touch-Display anzuschaffen.

Das Display ist die mit Abstand teuerste Komponente. Als allgemeinen Tipp empfahl Geritt einen powered USB-Hub zu verwenden, um seltsame Fehler, wie spontane Bildschirmausfälle, zu vermeiden.
Man muss also wieder tricksen, um Hardware-schonend zu programmieren.

Typische Anforderungen für die Entwicklung auf embedded Hardware ist beispielsweise die Verwendung einer berührungssensitive Benutzerschnittstelle. Maus- und Tastatureingaben wären für eine Fahrstuhlsteuerung ungewöhnlich. Auch die Steuerelemente entsprechen nicht denen einer Desktopanwendung und der Bildschirm ist oft viel kleiner, wie beispielsweise auf einer Smartwatch.

Der von Sun gepredigte Grundsatz "write once, run anywhere" trifft auf die Programmierung auf embedded Hardware nur mit erheblichen Einschränkungen zu.

Für das Rendering gilt das Scene-Graph-Konzept. Die Steuerelemente und deren Bestandteile sind in einer Baumstruktur hierarchisch gegliedert. Alle angewendeten Effekte und Bewegungen, gelten auch immer für die zugehörigen Kind-Knoten. Die Bildschirminhalte werden automatisch gerendert, der Entwickler hat darauf nur mittelbaren Einfluss. JavaFX ist nicht für die Spieleentwicklung gemacht.

Für die aktuellen Geräte sind ca. 1.000 Elemente (Nodes) verwaltbar. Wenn man mehr Bildschirmelemente nutzen möchte, reicht es nicht, diese unsichtbar zu machen. Sie würden im Speicher bleiben. Man muss ihre setManaged-Eigenschaft negieren.

Auch wenn Visualisierungen Gerrits Steckenpferd sind, auf embedded Hardware gilt der von Microsoft mit Windows 8 vorgemachte Grundsatz "content over chrome". Eine einfache Gestaltung einer Progressbar erfordert beispielsweise 3 Nodes im Scene-Graph. Den Fortschrittsbalken selbst, ein Zeiger-Element und vielleicht noch eine Textbox. Eine aufwendige Gestaltung mit gleichem Informationsgehalt kann schon mal 245 Nodes erfordern. Besonders, wenn viele Schattierungen und geschachtelte Elemente verwendet werden. Man sollte bei der Gestaltung der Benutzeroberfläche auf die Anzahl der Bildelemente achten. Animationen und aufwendige Effekte, wie dynamische Schattenwürfe und Verläufe sollte man vermeiden. Übereinander gezeichnete Elemente haben den besonderen Nachteil, dass sie sich gegenseitig beeinflussen.

Zum Abschluss erlebten wir eine Premiere in der rheinjug, eine interaktive Demo, zu der alle Zuhörer nach vorne gebeten wurden. Dort ergab sich die Party vor der Party und wir konnten die von Gerrit mitgebrachten Implementierungen auf Hardware wie Tablets, Smartphones und seiner Smartwatch wirklich begreifen.

 
Nachlese: Gründung einer Cloud Company
Written by Michael Jastram   
Friday, 21 February 2014 09:16

Im Rahmen des heutigen Abends wurden auch einige interne Änderungen angekündigt. Michael Jastram, Gründer der rheinjug, hat seine Rolle als 1. Vorsitzenden des gemeinnützien Vereins nach sieben Jahren an Lukas Ladenberger abgegeben. Nach einem kurzen Rückblick über die Jahre, einschließlich des Konsums von Subs (5000), Cookies (2000) und Bier (1200 l), ging es dann auch zum nächsten Thema über.

Igor outete sich zunächst als Ex-Java-Programmierer und versuchte dann, ein paar Vororteile bezüglich Claud-Firmen aus dem Weg zu räumen. Zum Beispiel, dass die Sicherheit von Servern kleiner Unternehmen eher fragwürdig ist, wie er mit einem entsprechenden Foto dokumentierte. Und da ging es nur um die Hardware - Herausforderungen wie eine entsprechende Administration kommen dann noch dazu kurz: Keine kleine Firma kann auch nur annähernd die Infrastruktur-Qualität erreichen, die Firmen wie Amazon oder Google ermöglichen.

Nun stellte Igor einen typischen Cloud-Stack vor, der aus IaaS (Infastructure), PaaS (Platform) oder SaaS (Software) bestehen kann. Der wichtigste Punkt ist eben, dass gemietet wird, und nicht investiert werden muss. Aber es gibt noch eine reihe weitere Vorteile, abgesehen davon, dass der Markt wesentlich größer ist: Typische Cloud-Dienste wachsen mit ihren Kunden. Das wiederum bedeutet, dass viele kleine Firmen sich Cloud-Produkte leisten können, was bei traditioneller Software nicht der Fall gewesen wäre.

Nachdem damit die Grundlagen vermittelt und Missverständnisse aus dem Weg geräumt waren, stellte Igor das Arbeiten in seiner Firma elastic.io vor, die keinen eigenen Server betreibt: Der Code lebt bei gitHub, die Software läuft auf heroku, als Framework wird node.js eingesetzt. An diesem Punkt brach eine kleine Diskussion aus, denn viele Besucher drückten Sorgen über Daten-Klau aus. Igor konterte jedoch damit, dass es keinen Grund gibt, dem eigenen Admin mehr zu vertrauen als dem von Amazon. Abgesehen davon dass bspw. der Sourcecode allein, ohne das dazugehörige Team, nur wenig wert ist - wie man an vielen Open Source-Projekten sieht, denen der Hauptentwickler verlorengegangen ist.

Soweit, so gut: Cloud Software bietet viele Vorteile, doch wie setzt man sie am besten ein, insbesondere, um skalieren zu können? Igor stellte ein paar einfache Regeln auf: Design for Failure; Decoupling; Elasticity; Asynchrony; Avoid Distributed Tansactions; Auf jeden dieser Punkte ging er mit konkreten Beispielen ein und auch diese Themen lösten wieder angeregte Diskussionen aus.

Obwohl viele Fragen schon während des Vortrags gestellt und beantwortet wurden, kamen noch viele weitere Diskussionen in der anschließenden Fragerunde zustande, die sich - wie so oft - noch in einer gemütlichen Runde mit Bier fortsetzte.

 
Nachlese: Java und SQL
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.

 
More Articles...