Nachlese: Fun mit Java(FX) auf embedded Hardware | Print |
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 | Print |
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 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: 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: 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.

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

Page 6 of 14