Fast hätte ich's vergessen: Nach meiner ersten kulinarischen Erfahrung (s. Curryworsten) habe ich ja versprochen, mich noch einer anderen belgischen Spezialität zu widmen: Schokolade.
Ich selber bin kein Fan von Pralinen, obwohl genau diese Naschvariante es ist, für die Belgien berühmt sein soll. Also habe ich mich auf Schokolade in der Tafelform beschränkt.
Bei Wein gilt ja die Aussage: Ein Wein ist immer dann ein guter Wein, wenn er einem schmeckt.
Wenn das auch für Schokolade gilt, dann machen die hier sehr gute Schokolade. Aber deswegen nach Belgien fahren? Vielleicht nicht, aber die Vielfalt in den Schaufensterauslagen der zahlreichen Schokolaterien zu sehen, lässt einem doch schon mal das Wasser im Munde zusammenlaufen.
Für "richtige" Nahrung empfehle ich hier aber entweder Pommes oder die internationale Küche Italiens und Argentiniens. Niemals eine Currywurst!! Die sollte man nur im Land der Dichter und Denker zu sich nehmen, und da ist das ein echter Genuss. ;-)
Freitag, 19. November 2010
Das war's: Ein kleines Fazit von Jörn
Fünf Tage Devoxx sind zu Ende. Ohne Frage fünf teilweise sehr interessante aber auch anstrengende Tage.
Wir haben erstmals die Teinahme an einer derartigen Veranstaltung mit einem Blog dokumentiert und somit allen "Daheimgebliebenen" mehr oder weniger live Bericht erstattet. Dieser Blog war für uns eine Hilfe, das Gesehene und Gehörte noch mal zu verarbeiten und für alle Leser hoffentlich eine interessante Nachrichtenquelle.
Natürlich gab es (wie immer und überall) positives und negatives festzustellen.
Positiv war definitiv die zumeist hohe Qualität der Vorträge. Dies galt sowohl für das inhaltliche als auch für das rethorische Niveau. Hinzu kam die Besonderheit des Veranstaltungsortes: Wann hat man schon mal die Gelegenheit Vorträge vor einer großen Kinoleinwand präsentiert zu bekommen?
Negativ fällt mal wieder das Essen auf. Wie schon von Teilnehmern vergangener Jahre berichtet, fallen Frühstück und Mittagessen recht mager aus. Abends gibt es eh nichts. Die Räumlichkeiten waren ab Tag 3 an ihre Kapazitätsgrenzen gestoßen (sitzen auf den Treppen war teilweise notwendig). Das wurde zusätzlich bei Raumwechseln zwischen den Vorträgen deutlich (die einen wollen rein, die anderen raus. Gedränge und lange Schlangen; ein Raumwechsel dauerte eine gefühlte Ewigkeit). Aufgrund der zahlreichen Vorträge hatte man nur wenig Zeit, sich mit anderen Teilnehmern zu unterhalten oder die parallel stattfindende Messe mit Ausstellern unterschiedlichster IT-Unternehmen zu besuchen. Die Abstände zwischen den Vorträgen waren manchmal recht eng. Hinzu kam unsere "Selbstverpflichtung" zu bloggen, wofür die sowieso knappen Pausen meist vollständig draufgingen (aber daran sind wir selber "schuld").
Fazit: Grundsätzlich ließe sich diese Veranstaltung uneingeschränkt weiterempfehlen und eine Teilnahme im nächsten Jahr fest einplanen (dann mit zwei anderen Kollegen), wenn ... ja, wenn es nicht eine sehr günstige Alternative gäbe: parleys.com! Gegen einen vergleichsweise geringen Unkostenbeitrag von 79€/Jahr erhält man in einer sehr guten Flash-Oberfläche Zugang zu sämtlichen Devoxx-Beiträgen des aktuellen Jahres. Viele der älteren Beiträge sind meines Wissen sogar gratis.
Man spart Reisekosten, die Mitarbeiter fallen für's Tagesschäft nicht aus, es ist billiger und alle haben etwas davon. Nur auf einen Blog wie diesen müsste man verzichten. ;-)
Vielleicht wird's ja was.
Wir haben erstmals die Teinahme an einer derartigen Veranstaltung mit einem Blog dokumentiert und somit allen "Daheimgebliebenen" mehr oder weniger live Bericht erstattet. Dieser Blog war für uns eine Hilfe, das Gesehene und Gehörte noch mal zu verarbeiten und für alle Leser hoffentlich eine interessante Nachrichtenquelle.
Natürlich gab es (wie immer und überall) positives und negatives festzustellen.
Positiv war definitiv die zumeist hohe Qualität der Vorträge. Dies galt sowohl für das inhaltliche als auch für das rethorische Niveau. Hinzu kam die Besonderheit des Veranstaltungsortes: Wann hat man schon mal die Gelegenheit Vorträge vor einer großen Kinoleinwand präsentiert zu bekommen?
Negativ fällt mal wieder das Essen auf. Wie schon von Teilnehmern vergangener Jahre berichtet, fallen Frühstück und Mittagessen recht mager aus. Abends gibt es eh nichts. Die Räumlichkeiten waren ab Tag 3 an ihre Kapazitätsgrenzen gestoßen (sitzen auf den Treppen war teilweise notwendig). Das wurde zusätzlich bei Raumwechseln zwischen den Vorträgen deutlich (die einen wollen rein, die anderen raus. Gedränge und lange Schlangen; ein Raumwechsel dauerte eine gefühlte Ewigkeit). Aufgrund der zahlreichen Vorträge hatte man nur wenig Zeit, sich mit anderen Teilnehmern zu unterhalten oder die parallel stattfindende Messe mit Ausstellern unterschiedlichster IT-Unternehmen zu besuchen. Die Abstände zwischen den Vorträgen waren manchmal recht eng. Hinzu kam unsere "Selbstverpflichtung" zu bloggen, wofür die sowieso knappen Pausen meist vollständig draufgingen (aber daran sind wir selber "schuld").
Fazit: Grundsätzlich ließe sich diese Veranstaltung uneingeschränkt weiterempfehlen und eine Teilnahme im nächsten Jahr fest einplanen (dann mit zwei anderen Kollegen), wenn ... ja, wenn es nicht eine sehr günstige Alternative gäbe: parleys.com! Gegen einen vergleichsweise geringen Unkostenbeitrag von 79€/Jahr erhält man in einer sehr guten Flash-Oberfläche Zugang zu sämtlichen Devoxx-Beiträgen des aktuellen Jahres. Viele der älteren Beiträge sind meines Wissen sogar gratis.
Man spart Reisekosten, die Mitarbeiter fallen für's Tagesschäft nicht aus, es ist billiger und alle haben etwas davon. Nur auf einen Blog wie diesen müsste man verzichten. ;-)
Vielleicht wird's ja was.
Tag 5: 11:50 - 12:50 : The roots of Java EE 6: JSR-299 (CDI) and Weld extensions
Contexts and Dependency Injection (CDI) ist eines der zentralen Themen in JEE 6. Dieser Vortrag widmete sich der Referenz-Implementierung Weld.
Sämtliche Eigenschaften von Weld aufzuzählen, ginge an dieser Stelle zu weit; hierzu sei auf die Homepage von Weld verwiesen (s. o.).
Wichtig ist, dass CDI im Allgemeinen das Thema Dependency Injection standardisiert und Weld im Speziellen diesen Standard sowohl für "ausgewachsene" Applikationsserver als auch für Servlet Engines implementiert.
Ergänzt wird Weld durch "Seam Solder", welche als portable lib nützliche Tools bereitstellt, um CDI zu erweitern.
Aus meiner Sicht sollten wir Weld im Auge behalten, auch wenn zurzeit kein konkretes Einsatzgebiet dafür zu existieren mag.
Sämtliche Eigenschaften von Weld aufzuzählen, ginge an dieser Stelle zu weit; hierzu sei auf die Homepage von Weld verwiesen (s. o.).
Wichtig ist, dass CDI im Allgemeinen das Thema Dependency Injection standardisiert und Weld im Speziellen diesen Standard sowohl für "ausgewachsene" Applikationsserver als auch für Servlet Engines implementiert.
Ergänzt wird Weld durch "Seam Solder", welche als portable lib nützliche Tools bereitstellt, um CDI zu erweitern.
Aus meiner Sicht sollten wir Weld im Auge behalten, auch wenn zurzeit kein konkretes Einsatzgebiet dafür zu existieren mag.
Tag 5: 10:45 - 11:45 - WebSockets meet JavaServer Faces
Von Matthias Wessendorf
Dieser Vortrag schloss die Lücke, die nach dem Vortrag der Kaazing-Leute klaffte. Die offene Frage war: "Was ist auf der Serverseite notwendig?"
Serverside WebSocket Support:
Richtig interessant wurde es, als die Verwendung von Websockets im Zusammenspiel mit JSF2.0 und Atmosphere gezeigt wurde.
Er versprach mir die Codebeispiele noch zu veröffentlichen.
Wertung:
Dieser Vortrag schloss die Lücke, die nach dem Vortrag der Kaazing-Leute klaffte. Die offene Frage war: "Was ist auf der Serverseite notwendig?"
Serverside WebSocket Support:
- Node.js
- Kaazing Gateway
- Jetty 7 and 8
- Glassfish 3.1
- Resin
Richtig interessant wurde es, als die Verwendung von Websockets im Zusammenspiel mit JSF2.0 und Atmosphere gezeigt wurde.
Er versprach mir die Codebeispiele noch zu veröffentlichen.
Wertung:
Tag 5: 10:45 - 11:45 : Apache Camel, a powerful open source integration framework
Wenn Apache Camel nur halbwegs das hält, was Titel und Inhalt dieser Veranstaltung versprachen, dann ist dieses Framework definitiv ein "must have"!
Camel ist ein frei verfügbares Business Integration Framework. Es bedient also die Notwendigkeit in vielen Unternehmensanwendungen, andere Komponenten oder Systeme ansteuern und integrieren zu müssen.
Die Muster, nach denen dies geschieht und die nichtfunktionalen Anforderungen, denen man sich bei der Integration konfrontiert sieht, sind über viele Unternehmensanwendungen betrachtet vergleichbar. Und so tritt Camel an, einem diese "Grundlast" auf vereinheitlichte Weise zu nehmen.
Die theoretische Grundlage bilden die sogenannten Enterprise Integration Patterns, wie sie in der einschlägigen Literatur beschrieben sind (das Standardwerk zu diesem Thema findet man hier). Im wesentlichen werden hierbei zur Beschreibung Symbole mit einer bestimmten Semantik eingesetzt und auf diese Weise Rezepte zur Lösung bestimmer (Standard-)Probleme formuliert. Camel bietet die Verwendung dieser Patterns auf unterschiedliche Weise an:
Camel erhebt den Anspruch, auf vielen Gebieten "einfach oder "leicht" zu sein:
Camel ist ein frei verfügbares Business Integration Framework. Es bedient also die Notwendigkeit in vielen Unternehmensanwendungen, andere Komponenten oder Systeme ansteuern und integrieren zu müssen.
Die Muster, nach denen dies geschieht und die nichtfunktionalen Anforderungen, denen man sich bei der Integration konfrontiert sieht, sind über viele Unternehmensanwendungen betrachtet vergleichbar. Und so tritt Camel an, einem diese "Grundlast" auf vereinheitlichte Weise zu nehmen.
Die theoretische Grundlage bilden die sogenannten Enterprise Integration Patterns, wie sie in der einschlägigen Literatur beschrieben sind (das Standardwerk zu diesem Thema findet man hier). Im wesentlichen werden hierbei zur Beschreibung Symbole mit einer bestimmten Semantik eingesetzt und auf diese Weise Rezepte zur Lösung bestimmer (Standard-)Probleme formuliert. Camel bietet die Verwendung dieser Patterns auf unterschiedliche Weise an:
- Als DSL, programmierbar in XML, Java, Groovy und Scala
- Über eine GUI, welche diese Symbole zur "Programmierung" anbietet
Camel erhebt den Anspruch, auf vielen Gebieten "einfach oder "leicht" zu sein:
- Im Wesentlichen wird die Laufzeitumgebung durch eine handvoll JARs definiert. Es ist kein Laufzeit-Container notwendig, wenngleich möglich.
- Es gibt eine große Zahl an Komponenten, die eine Reihe von Anwendungsfällen, Zielsystemen und Konvertern abbilden, welche aber auch durch eigene Lösungen erweitert werden können.
- Die Konfiguration ist einfach (s. o.).
- Die transportierten Daten basieren nativ auf Java POJOs. Konvertierungen in ein anderes Datenformat muss nur im Bedarfsfall erfolgen.
- Camel arbeitet gut mit Spring zusammen.
Tag 5: 11:50 - 12:50 - ElasticSearch - You Know, for Search
Von Shay Banon
Der Letzte Talk auf der Devoxx zum Thema ElasticSearch die Suchmaschine für die Cloud.
So nebenbei ... Die Cloud ... hat die irgendwer mal gesehen? Ist das SkyNet? ;-)
Der Vortragende hat einen Vortag im Style einer Consolenausgabe abgeliefert und erklärte die Basics am Beispiel eines Online-Bookstore der Bücher und CDs anbietet.
Das Ganze sah nach einer mächtigen Software aus die mit extrem großen und kaum vorstellbaren Datenmengen (Bereich: terra- bis petabyte) operiert.
Zwei Dinge noch:
Wertung:
Der Letzte Talk auf der Devoxx zum Thema ElasticSearch die Suchmaschine für die Cloud.
So nebenbei ... Die Cloud ... hat die irgendwer mal gesehen? Ist das SkyNet? ;-)
Der Vortragende hat einen Vortag im Style einer Consolenausgabe abgeliefert und erklärte die Basics am Beispiel eines Online-Bookstore der Bücher und CDs anbietet.
Das Ganze sah nach einer mächtigen Software aus die mit extrem großen und kaum vorstellbaren Datenmengen (Bereich: terra- bis petabyte) operiert.
Zwei Dinge noch:
- exposes lucene searches via json
- version 0.13 BETA - wird jedoch produktiv eingesetzt
Wertung:
Tag 4: 16:40 - 17:40 : Implementing Emergent Design
Übersetzt man emergent und überträgt dies auf das Thema dieses Vortrages, dann könnte der Votrag auch wie folgt überschrieben sein: "Wie man in der Softwreentwicklung ein Design entstehen und wachsen lässt."
Ein Problem in der Softwareentwicklung - vielleicht sogar das Hauptproblem - liegt darin, dass wir zu Beginn eines Softwareprojektes nahezu nichts über die Anwendungsdomäne wissen und sich das notwendige Wissen erst mit der Zeit entwickelt. Idealerweise warten wir also sehr lange (unendlich lange), bis wir genug für die Umsetzung wissen. Dieses Vorgehen ist leider nur bedingt akzeptabel.
Um dieses Thema greifbarer zu machen, zitiert der Vortragende den ehemaligen Chef-Philosophen der US-Regierung Donald Rumsfeld:
"Es gibt bekanntes Wissen. Das sind Sachen, von denen wir wissen, daß wir sie wissen. Es gibt bekanntes Unwissen. Das bedeutet, es gibt Sachen, von denen wir wissen, daß wir sie nicht wissen. Aber es gibt auch unbekanntes Nichtwissen. Das sind Sachen, von denen wir nicht wissen, daß wir sie nicht wissen."
Diese Unwissenheit macht es in der Softwareentwicklung schwer, ein von Anfang an tragfähiges Design zu entwickeln, geschweige denn ein Design, welches sich leicht an den Wissenszuwachs während der Projektlaufzeit anpassen lässt.
Daher zwei weitere seiner Kernaussagen:
In dem Vortrag wurde zwischen essential complexity (also der Anwendungsdomäne natürlicherweise innewohnenden Komplexität) und accidential complexity (also der durch fehlerhafte Designentscheidungen hinzugefügten Komplexität) unterschieden. Beispiele fur letzteres sind
Die Vorschläge hierzu sind so brilliant wie einfach:
Ein Problem in der Softwareentwicklung - vielleicht sogar das Hauptproblem - liegt darin, dass wir zu Beginn eines Softwareprojektes nahezu nichts über die Anwendungsdomäne wissen und sich das notwendige Wissen erst mit der Zeit entwickelt. Idealerweise warten wir also sehr lange (unendlich lange), bis wir genug für die Umsetzung wissen. Dieses Vorgehen ist leider nur bedingt akzeptabel.
Um dieses Thema greifbarer zu machen, zitiert der Vortragende den ehemaligen Chef-Philosophen der US-Regierung Donald Rumsfeld:
"Es gibt bekanntes Wissen. Das sind Sachen, von denen wir wissen, daß wir sie wissen. Es gibt bekanntes Unwissen. Das bedeutet, es gibt Sachen, von denen wir wissen, daß wir sie nicht wissen. Aber es gibt auch unbekanntes Nichtwissen. Das sind Sachen, von denen wir nicht wissen, daß wir sie nicht wissen."
Diese Unwissenheit macht es in der Softwareentwicklung schwer, ein von Anfang an tragfähiges Design zu entwickeln, geschweige denn ein Design, welches sich leicht an den Wissenszuwachs während der Projektlaufzeit anpassen lässt.
Daher zwei weitere seiner Kernaussagen:
- Design ist das Zeug, welches man später nur schwer verändern kann.
- Architektur ist, sowenig wie möglich von diesem schwer veränderbaren Zeug zu verwenden.
In dem Vortrag wurde zwischen essential complexity (also der Anwendungsdomäne natürlicherweise innewohnenden Komplexität) und accidential complexity (also der durch fehlerhafte Designentscheidungen hinzugefügten Komplexität) unterschieden. Beispiele fur letzteres sind
- Zuviele Anwendungsschichten
- Zuviel Delegating oder Proxying
Die Vorschläge hierzu sind so brilliant wie einfach:
- Test driven design: Hier geht es mehr um das Design als um das Testen. Durch den Aufbau von Unit Tests verschafft man sich erstmal ein besseres Verständnis von dem, was der eigentliche Code leisten soll. Man bricht fast automatisch die Zielklassen in kleinere Einheiten herunter und erreicht dadurch eine bessere Abstraktion. Konsequenz: Weniger accidential complexity. Dieses Vorgehen sollte besonders bei neuem Code angewendet werden.
- Refactoring: Es gilt das Prinzip von der collective code ownership, d. h. jeder darf den Code des anderen ändern. Durch Refactoring sollten in bestehendem Code frühzeitig veraltete Abstraktionen und grundsätzlich schlechter Code so schnell wie möglich korrigiert werden (Zitat: "fix broken windows whenever you see them"). Andernfalls dienen solche Codebestandteile früher oder später als vermeidlich brauchbare Vorlage für neuen Code (z. B. in heißen Phasen).
- APIs und DSLs: APIs Beschreiben die Schnittstellen zu Teilkomponenten, Alleine sich darüber Gedanken machen zu müssen kann schon dazu führen, dass die Fassade eine Teilkomponente für den Aufrufer leichter und eingängiger bedienbar wird und sich die Komponente nur auf das beschränkt,wofür sie gedacht sein soll. Das Ergebnis kann in eine DSL münden, welche die Verwendung der Komponente ausdrucksstärker und (typ-)sicherer macht. Dies geht einher mit Punkt 1.
Tag 4: 15:10 - 16:10 : Hadoop, HBase, and Hive in Production
Früher war der "Feind" Microsoft. Dann hat Google diese Position eingenommen. In letzter Zeit bemüht sich Facebook intensiv im diesen Titel. Mit Erfolg, wie die regelmäßigen Pressemitteilungen über dieses Unternehmen verdeutlichen. ;-)
Diese Session ist von Facebook. Ich bin also für eine Stunde in der Höhle des Löwen und höre mir an, wie die Datenkrake hinter der "Gefällt mir"-Fassade funktioniert.
500 Millionen aktive Nutzer monatlich wollen technisch verwaltet werden. Die damit verbundene Datenmenge übersteigen ein wenig jenes Datenvolumen, mit dem wir in unseren Projekten arbeiten müssen.
Andere Anforderungen an das Mengengerüst verlangen nach anderen Lösungen für den Umgang damit. Klassische Datenbanken mit klassischen Abfragesprachen helfen hier nach Aussage des Vortragenden wenig.
Massive Parallelisierung gepaart mit einem modifizierten Datenspeicherung und entsprechender Datenabfrage-"Sprache" beschreiben abstrakt den gewählten Lösungsansatz. Konkret setzt Facebook dabei auf folgende Werkzeuge:
Diese Session ist von Facebook. Ich bin also für eine Stunde in der Höhle des Löwen und höre mir an, wie die Datenkrake hinter der "Gefällt mir"-Fassade funktioniert.
500 Millionen aktive Nutzer monatlich wollen technisch verwaltet werden. Die damit verbundene Datenmenge übersteigen ein wenig jenes Datenvolumen, mit dem wir in unseren Projekten arbeiten müssen.
Andere Anforderungen an das Mengengerüst verlangen nach anderen Lösungen für den Umgang damit. Klassische Datenbanken mit klassischen Abfragesprachen helfen hier nach Aussage des Vortragenden wenig.
Massive Parallelisierung gepaart mit einem modifizierten Datenspeicherung und entsprechender Datenabfrage-"Sprache" beschreiben abstrakt den gewählten Lösungsansatz. Konkret setzt Facebook dabei auf folgende Werkzeuge:
- Aggregation von RDBMS-Knoten über Scribe
- Verteilte Datenspeicherung über Apache Hadoop
- Verteilte Dateiverwaltung über das Hadoop Distributed File System HDFS
- Datensuche und -verarbeitung über Hadoop MapReduce
- DataWarehousing auf Basis von Apache Hive
Tag 2: 09:30 - 12:30 - Dive into Android
Der Vortrag wurde von Romain Guy und Chet Haase vorgetragen, wobei Romain „Layouts“ und Chet „Graphics“ vorgetragen hat. Der Vortragstil war eine Mischung aus Präsentations-Slides und Live-Coding-Demos.
Layouts-Facts
Layout und bzw. die View-Beschreibung erfolgt bei Android in XML.
Feste Masseinheiten: dip,px etc.
Wichtig:
Die sogenannte Layout-Geometry bzw. das Box-Layout kam mir bekannt vor. Ähnlich wie beim CSS gibt es margin und padding. Die „gravity“, die Position innerhalb der Box, war mir neu.
Romain meinte, das das Liniear Layout das meist genutzte Layout ist. Außerdem solle man nicht zu viele Layouts schachteln.
RelativeLayout
Table Layout
Tools
Hierarchieviewer als Debug-Tool
Stellt die Hierarchie des Layouts dar.
Part 2 : Graphics and Animations
Custom Views and Containers für Coole Effekte (Spiegel etc.)
Allgemeines:
How = Paint
What = Canvas
Where = Bitmap, Surface
Paint
Canvas
Verbunden mit dem Destination
Bitmaps
Tip: „reuse objects for performance“
Graphical effects
Animation Effects
Help user understand whats happening
Optimize Techs
mobile not desktop
opt: bitmaps
others
Tools
Romain: http://www.curious-creature.org/category/android/
Chet: http://graphics-geek.blogspot.com/
android-developer site: http://developer.android.com
Layouts-Facts
Layout und bzw. die View-Beschreibung erfolgt bei Android in XML.
- Layouts sind wichtig aufgrund der verschiedenen Displaysgrößen
- Layouts sind nicht pluggable
- Layout extends ViewGroup
- Parameter sind Kindelement des Layouts (im XML)
Feste Masseinheiten: dip,px etc.
Wichtig:
- match the parent's size
- Parameter: MATCH_PARENT bedeutet „big as parent“
- best fit: WRAP_CONTENT
- FrameLayout
- LinearLayout
- RelativeLayout
- TableLayout
Die sogenannte Layout-Geometry bzw. das Box-Layout kam mir bekannt vor. Ähnlich wie beim CSS gibt es margin und padding. Die „gravity“, die Position innerhalb der Box, war mir neu.
Romain meinte, das das Liniear Layout das meist genutzte Layout ist. Außerdem solle man nicht zu viele Layouts schachteln.
RelativeLayout
- care at Version 1.5
Table Layout
- no Table-Widget just layout
Tools
Hierarchieviewer als Debug-Tool
Stellt die Hierarchie des Layouts dar.
- nicht in Eclipse integriert
- Funktioniert nicht für Enduser-Phones
- Feature: Export als Photoshop-File => COOOL
Part 2 : Graphics and Animations
Custom Views and Containers für Coole Effekte (Spiegel etc.)
Allgemeines:
How = Paint
What = Canvas
Where = Bitmap, Surface
Paint
- Stroke props- width,color
- Fill props- gradient
- Quality - anti-aliasing, dithering, bitmap scaling
Canvas
Verbunden mit dem Destination
Bitmaps
- images
- rendering buffer
- creation
- drawing to
- drawing from
Tip: „reuse objects for performance“
Graphical effects
- rich background
- alpha ramps
- 3d light effeccts
- Gradiend effect
Animation Effects
Help user understand whats happening
- transition between states
- indicate actions and consecuences
- indicates changes in state
Optimize Techs
mobile not desktop
- slow cpu's
- less memomory
opt: bitmaps
- pre-scale
- cache complex rendering
- create bitmaps in device depth
others
- avoid garbage
- make background view opague
- avoid re-creating objects
- dont over-invalidate
- avoid costly operations on the UI thread -> AsyncTask is your friend
- reduce layout nesting
- avoid costly rendering during animatgionans -> do it fast, max. half sec.
Tools
- traceview for profiling
- hierarchyviewert container visualization
- layoutopt - static analysis on xml-files as extra tool
Romain: http://www.curious-creature.org/category/android/
Chet: http://graphics-geek.blogspot.com/
android-developer site: http://developer.android.com
Donnerstag, 18. November 2010
Tag 3: 15:10 - 16:10 - Testing RESTful Web Services
Von Jan Algermissen
Von diesem Vortrag habe ich mir erhofft mehr zum Thema testen von REST-Services zu erfahren. Die Slides sahen nett aus, aber inhaltlich kam leider nichts praktisches bzw. verwertbares heraus.
Herr Algermissen, der seinen Firmensitz übrigens auch in Hamburg hat, versprach seine Slides, als auch seinen theoretischen Ansatz/Test-Algorithmus, über SlideShare zu veröffentlichen.
Leider konnte ich bisher noch nichts finden.
Blog des Vortragenden: www.nordsc.com/blog
Wertung:
Tag 4: 13:15 - 13:30 : loadUI : A uniquely cool approach to Interactive Distributed Load Testing
loadUI ist ein Performance-Testing-Tool. Technisch basiert es auf JavaFX und ermöglicht es, über eine interaktive GUI per Drag'n'Drop Last-Tests zu erzeugen und auszuführen.
Die GUI macht einen sehr guten Eindruck: Diverse Komponenten zur Lastteststeuerung (u. a. Anzahl Requests, Latenzzeiten) lassen sich beliebig zusammenstöpseln und deren Ergebnisse protokollieren. Ein loadUI agent erlaubt die Steuerung verteilter Lasttests. Weitere Komponenten lassen sich auf einfache Weise über eine Groovy-DSL ergänzen. Im Unterbau ist soapUI nutzbar
Und all das in Echtzeit, während der Lasttest läuft.
Fazit: Must have!
Die GUI macht einen sehr guten Eindruck: Diverse Komponenten zur Lastteststeuerung (u. a. Anzahl Requests, Latenzzeiten) lassen sich beliebig zusammenstöpseln und deren Ergebnisse protokollieren. Ein loadUI agent erlaubt die Steuerung verteilter Lasttests. Weitere Komponenten lassen sich auf einfache Weise über eine Groovy-DSL ergänzen. Im Unterbau ist soapUI nutzbar
Und all das in Echtzeit, während der Lasttest läuft.
Fazit: Must have!
Tag 4: 12:00 - 13:00 - Android UI Development: Tips, Tricks, and Techniques
Von Chet Haase und Romain Guy
Mein zweiter Vortag zum Thema Android. In diesem Talk ging es eher um "do's and dont's". Es wurden die Themen "Garbage prevention", Tools
Wieder ein paar Zitaten aus dem Talk:
- "avoid object creation"
- "recycle bitmaps"
- "instead of myBitmap=null use myBitmap.recycle()"
- "dont wait for the finalizer"
- "be aggressive on deallocating objects"
Tools zum Thema Speichermanagement/-monitoring
- Tools Allocation Tracking
- Debug.startAllocationCounting()
- Heap-Analysis mit "hat" (vom Java Oracle SDK) mit hprof-converter
- MAT Memory-Analysis-Tool for Eclipse
Tools für Layouting
- HierarchieViewer
- LayoutOpt
Verhindern von "Memory Leaks"
- "careful with context"
- "care with static fields"
- "avoid non-stsatic inner classes"
- "use weak references"
- Single-threaded UI
- Dont block the UI-thread
- ANR* after 5 sec - dump on sd-card
- Handler posts messages in event-queues
- Use AsyncTask - they are WorkerThread with callbacks
* Application not responding
Wertung:
Tag 4: 12:00 - 13:00 : Grails 1.3 Update
Grails ist eines von vielen Web-Frameworks, die hier auf der Veranstaltung vorgestellt werden. Es basiert auf der Sprache Groovy, welche wiederum auf der JavaVM aufsetzt.
Der Vortrag stellte die Neuerungen vor, die in Version 1.3.x in Grails eingeflossen sind. Eine Zusammenfassung findet man hier.
Der Vortrag stellte die Neuerungen vor, die in Version 1.3.x in Grails eingeflossen sind. Eine Zusammenfassung findet man hier.
Tag 4: 16:40 - 17:40 - Defective Java: Mistakes that matter
Von William Pugh
William Pugh ist Professor an der Uni von Maryland und ist bekannt als ein JavaPuzzler. Ein Puzzler-Talk hat er nach dem Talk zusammen mit Joshua Bloch in einem anderen Saal veranstaltet.
William Pugh zeichnet sich als Verantwortlicher für das FindBugs-Projekt. Er erzählte von seiner Arbeit, der Unterstützung bei Google, mit seinem Tool FindBugs und lieferte in diesem Zusammenhang interesannte Zahlen....
An dieser Stelle zähle ich das gesagte Stichwortartig auf:
- statisic analysis can't find all bugs
- statisic analysis is limited
- @Google: 4000 bugs in google-server-code rang 1-12
- @Google: 8000 reviews by 800 engineers
- @Google: more than 1000 nullpointer bugs found
- @Google: presubmit check with find-bugs
- @Google: when you want to commit a change you need a code review
- 5-10% find software quality mistakes
- 80% coverage is a good number
- find dead code
- "Google has alot of dead code!"
Die Aussage von William war:
- "Your code is imperfect!"
- "It will never be perfect"
- "fix it when it bites"
- "a fix is good for you before they bit you"
Ich bin seit langem von FindBugs überzeugt, der Talk heute hat gezeugt, dass viele aus der Java-Szene FindBugs einsetzen und eine breite Akzeptanz vorhanden ist.
Von unserem heutigen Standpunkt aus, sind wir auf dem richtigen Weg. Wir machen Code-Reviews und in den Code-Reviews werden wir zukünftig auch FindBugs einsetzen.
Wertung:
Tag 4: 17:50 - 18:50 - Encryption Boot Camp on the JVM
Von Matthew McCullough
Der Talk handelte, wie der Titel vermuten lässt, von Verschlüsselung mit Java.
Der Stil des Vortragenden war erfrischend und die Slides grafisch ansprechend.
Die Folien kann hier anschauen.
Wertung:
Der Talk handelte, wie der Titel vermuten lässt, von Verschlüsselung mit Java.
Der Stil des Vortragenden war erfrischend und die Slides grafisch ansprechend.
Die Folien kann hier anschauen.
Wertung:
Tag 4: 10:50 - 11:50: Comparing JVM Web Frameworks
Ein Vortragsthema, wie gemacht, um bei allen Zuschauern in Fettnäpfchen zu treten. Denn am Ende erwartet doch jeder die Antwort auf die Frage: "Wer ist das schönste im ganzen Land?"
Wie aber zu erwarten war: Eine eindeutige Antwort darauf gibt es nicht. Der Vortragende gab aber ein klares Statement ab, welches Framework NICHT zu benutzen ist:
Wie aber zu erwarten war: Eine eindeutige Antwort darauf gibt es nicht. Der Vortragende gab aber ein klares Statement ab, welches Framework NICHT zu benutzen ist:
"Don't use Struts!"
Das Problem ist aber nicht das einzelne Framework ansich: Es ist die Vielzahl an unterschiedlichsten Web-Frameworks, die eine fundierte Entscheidung zugunsten einer Lösung so schwer macht.
Konsequenz: Es ist ein Leitfaden notwendig, welcher zum einen das Vorgehen und zum anderen die Kriterien zur Auswahl eines Frameworks definieren.
Das vorgeschlagene Vorgehen sollte dabei wie folgt aussehen:
- Führe eine grobe Vorauswahl von zu untersuchenden Frameworks durch (Bauchentscheidung)
- Erzeuge auf Basis einer definierten Fachlichkeit je Framework einen Prototypen
- Dokumentiere die Ergebnisse gemäß Kriterienkatalog (s. u.)
- Präsentiere die Ergebnisse (anderen Entwicklern, Stakeholdern)
- Stelle Dokumentation und Präsentation (anderen Entwicklern, Stakeholdern) zur Verfügung und spreche eine Empfehlung aus
- Entwickler-Produktivität
- Entwickler-Wahrnehmung
- Lernkurve
- "Project health"
- Verfügbarkeit von Entwicklern für die jeweilige Technologie
- Job Trends (!)
- Templating
- Komponenten-Struktur
- Ajax-Support
- Plugins / Addons
- Skalierbarkeit
- Testing Support
- i18n, l10n
- Validation support (Client und Server!)
- Multi-language support (im Sinne von zusätzlich einsetzbaren (Skript-)Sprachen)
- Qualität der Dokumentation und der Tutorials
- Verfügbare Bücher
- REST Support (Client und Server!)
- Mobile Support
- Grad des Risikos für einen Einsatz beim Kunden
- Handelt es sich um eine kunden-zentrierte Anwendung?
- Muss die Anwendung Desktop-like Funktionalität bieten?
- Handelt es sich um Multimedia-Anwendungen?
- Handelt es sich um eine Internet-Anwendung mit hohen Zugriffs- und Benutzerzahlen? Wähle ein Request-basiertes Framework.
- Handelt es sich um eine Internet-Anwendung hinter einer Firewall mit geringen Zugriffszahlen? Wähle ein Komponenten-basiertes Framework.
- Handelt es sich um eine Web-Anwendung mit langer Lebensdauer (5-10 Jahre)? Wähle ein Framework mit großer Community und großem Hersteller-Support.
- GWT
- Vorteile: Java-basiert, Javascript wird automatisch optimiert, einfach zu lernen, große Community
- Nachteile: Langsames Kompilieren, schwer zu testen
- Grails
- Vorteile: Von Java-Entwicklern leicht zu lernen, Groovy als Basis, viele Plugins
- Nachteile: Grauenvolle Stacktraces, Zugrundeliegendes Framework zu sehr weggekapselt
- Wicket
- Vorteile: Klasse für Java-Developer, gutes Binding zwischen Seiten und Views, Aktive Community
- Nachteile: Stateful by default, Keine saubere Trennung zwischen HTML-Templates und Java-Code
Tag 4: 15:10 - 16:10 - JavaPosse Live
JavaPosse Live von Dick Wall, Carl Quinn und Joe Nuxoll
"How the f**k is the JavaPosse?"
Die Java-Posse sind vier Autoren die regelmäßig einen Podcast mit Nachrichten, Diskussionen und Interviews rund um das Java-Ecosystem veröffentlichen. Die Autoren, Tor Norbye (Sun Microsystems), Carl Quinn (Google), Dick Wall (Google) und Joe Nuxoll (Apple Inc.) sind durch ihren Podcast zu echten Stars in der Community geworden. Ihr Erkennungszeichen sind bunte übergroße Cowboy-Hüte. Der Saal war in Kürze überfüllt, die eigentliche Veranstaltung war eine Mischung aus Quatsch-sagen und machen. Wirklich Sinnvoll war der Besuch nicht, immerhin hab ich es jetzt mal live gesehen.
Wertung:
"How the f**k is the JavaPosse?"
Die Java-Posse sind vier Autoren die regelmäßig einen Podcast mit Nachrichten, Diskussionen und Interviews rund um das Java-Ecosystem veröffentlichen. Die Autoren, Tor Norbye (Sun Microsystems), Carl Quinn (Google), Dick Wall (Google) und Joe Nuxoll (Apple Inc.) sind durch ihren Podcast zu echten Stars in der Community geworden. Ihr Erkennungszeichen sind bunte übergroße Cowboy-Hüte. Der Saal war in Kürze überfüllt, die eigentliche Veranstaltung war eine Mischung aus Quatsch-sagen und machen. Wirklich Sinnvoll war der Besuch nicht, immerhin hab ich es jetzt mal live gesehen.
Wertung:
Tag 4: Zwischenruf: Überall Macs
Es ist kaum zu glauben: MacBook und iPhone sind dieNummer-1-Gadgets der Teilnehmer und Vortragenden. Den Härtefall aber sah ich aber gestern: Ein Besitzer eines Dell-Notebooks wollte sich wohl unbedingt zu den Mac-Jüngern zählen und hat kurzerhand das Dell-Logo mit einem Apple-Sticker überklebt.
Soweit sind Christian und ich allerdings nicht: Wir stehen zu unseren EeePC-Netbooks für 300€. Sind doch auch schön ... heul.
Soweit sind Christian und ich allerdings nicht: Wir stehen zu unseren EeePC-Netbooks für 300€. Sind doch auch schön ... heul.
Tag 4: 9:30 - 10:40: The Future Roadmap of Java EE
Auch Tag 4 beginnt mit einer Keynote. Heute geht es um die zukünftigen Themen in Java EE.
Ein zentrales Thema auf der Devoxx 2010 ist Cloud Computing. Dem kann sich JEE nicht verschließen. Dabei sind die vom Java-Ökosystem mitgebrachten Randbedingungen garnicht so schlecht: Es gibt Container, Services, Security-Mechanismen, CLuster-Unterstützung, u. s. w.
Für das "Anwendungsleben in der Wolke" sind aber laut Vortragendem noch einige Herausforderungen zu meistern:
Auch die Paketierung der Anwendung muss verbessert werden, denn:
Hier noch ein Update zum Thema "Modularität der Javaplattform": Das Konzept dahinter wird nicht vor Java 8 verfügbar sein. Interessant wa in diesem Zusammenhang ein Hinweis, wie man sich bei Sun - äh Oracle - die Lösung des Packaging und Dependency Management vorstellt.
Wenn eine Anwendung Abhängigkeiten zu einer API in der Version 1.1 hat und diese API vom Laufzeit-Container implementiert wird, dann wird die Implementierung des Laufzei-Containers genommen. Wenn nicht, dann wird die von der Anwendung mitgelieferte Implementierung herangezogen. Ist das neu? Nein. Neu daran ist, dass das vordergründig wohl nicht mehr über
den Classpath geregelt wird, sondern auf Basis einer Konfigurationsdatei, die mit der Awnedung deployt wird. Hoffentlich lässt sich dort dann auf einheitliche Weise dieses Defaultverhalten auch wieder übersteuern (heute hat jeder AppServer hier seine eigene Logik).
Natürlich gab es auch einen Ausblick auf JSF 2.2 , welcher natürlich die umfassende Unterstützung von HTML 5 im Fokus hatte.
Und nachdem JMS seine Randnotiz bekam (Specs und API werden aufgeräumt), ging es erneut um JPA, diesmal mit einem Ausblick auf Version 2.1. Neue Möglichkeiten beim Mapping und rund um das Laden von Daten, API-Erweiterungen sowie verbesserte Querying-Möglichkeiten weden als Teil von JEE 7 sowie Standalone zur Verfügung stehen. Erste Pläne für ein JSR wird es im Januar 2011 geben.
Zum wiederholten Male wurde das Thema JAX-RS vorgestellt. Ich möchte an dieser Stelle lediglich die genannten Implementierungen und Frameworks erwähnen, die bei der Entwicklung JAX-RS-fähiger Anwendungen unterstützen.
Implementierungen, u. a.
Ein zentrales Thema auf der Devoxx 2010 ist Cloud Computing. Dem kann sich JEE nicht verschließen. Dabei sind die vom Java-Ökosystem mitgebrachten Randbedingungen garnicht so schlecht: Es gibt Container, Services, Security-Mechanismen, CLuster-Unterstützung, u. s. w.
Für das "Anwendungsleben in der Wolke" sind aber laut Vortragendem noch einige Herausforderungen zu meistern:
- Strenge Anforderungen an Resource- und State-Management
- Bessere Isolation zwischen Applikationen
- Bereitstellung einer Standard-API für NoSQL-RDBMS, caching, ...
- Allgemeines Monitoring
Auch die Paketierung der Anwendung muss verbessert werden, denn:
- Applikationen sind versioniert
- Mehrere Versionen eine Anwendung können zeitgleich nebeneinander existieren
Hier noch ein Update zum Thema "Modularität der Javaplattform": Das Konzept dahinter wird nicht vor Java 8 verfügbar sein. Interessant wa in diesem Zusammenhang ein Hinweis, wie man sich bei Sun - äh Oracle - die Lösung des Packaging und Dependency Management vorstellt.
Wenn eine Anwendung Abhängigkeiten zu einer API in der Version 1.1 hat und diese API vom Laufzeit-Container implementiert wird, dann wird die Implementierung des Laufzei-Containers genommen. Wenn nicht, dann wird die von der Anwendung mitgelieferte Implementierung herangezogen. Ist das neu? Nein. Neu daran ist, dass das vordergründig wohl nicht mehr über
den Classpath geregelt wird, sondern auf Basis einer Konfigurationsdatei, die mit der Awnedung deployt wird. Hoffentlich lässt sich dort dann auf einheitliche Weise dieses Defaultverhalten auch wieder übersteuern (heute hat jeder AppServer hier seine eigene Logik).
Natürlich gab es auch einen Ausblick auf JSF 2.2 , welcher natürlich die umfassende Unterstützung von HTML 5 im Fokus hatte.
Und nachdem JMS seine Randnotiz bekam (Specs und API werden aufgeräumt), ging es erneut um JPA, diesmal mit einem Ausblick auf Version 2.1. Neue Möglichkeiten beim Mapping und rund um das Laden von Daten, API-Erweiterungen sowie verbesserte Querying-Möglichkeiten weden als Teil von JEE 7 sowie Standalone zur Verfügung stehen. Erste Pläne für ein JSR wird es im Januar 2011 geben.
Zum wiederholten Male wurde das Thema JAX-RS vorgestellt. Ich möchte an dieser Stelle lediglich die genannten Implementierungen und Frameworks erwähnen, die bei der Entwicklung JAX-RS-fähiger Anwendungen unterstützen.
Implementierungen, u. a.
- Apache CXF
- Apache Wink
- eXo
- Jersey
- RESTEasy
- ...
- Play
- SiteBricks
- Scalate
- Spring
- VRaptor
- ...
Mittwoch, 17. November 2010
Tag 3: 17:50 - 18:50: HTML5 Websockets: A New World of Limitless, Live, and Wickedly Cool Web Applications
Die Firma Kaazing hatte mal wieder einen Auftritt zum Thema HTML5, genauer HTML5 WebSockets.
Grundidee: HTML bassiert auf HTTP. HTTP auf TCP. Während TCP eine Full-Duplex-Kommunikation erlaubt, gibt es bei HTTP lediglich einen Request, gefolgt von einer Resonse. Das ist bidirektional, aber nicht full duplex.
Manch moderne Web-Anwendungen benötigen für den Datenaustausch das Konzept einer Standleitung, über die Daten quasi in Echtzeit übertragen werden können. Das betrifft zum einen die Datenlieferung vom Client zum Server (mit dem Client als aktiven Part) ABER auch die Datenlieferung vom Server zum Client (mit dem Server als aktivem Part).
Letzteres ist nicht neu: Konzepte, wie "Long poll" haben zumindest den Eindruck einer server-initiierten Datenlieferung vermittelt. Mit allen damit verbundenen Nachteilen, denn es ist nach wie vor HTTP mit dem damit verbundenen Overhead.
WebSocket ist ein Ansatz das Problem zu lösen. Grundidee:
Grundidee: HTML bassiert auf HTTP. HTTP auf TCP. Während TCP eine Full-Duplex-Kommunikation erlaubt, gibt es bei HTTP lediglich einen Request, gefolgt von einer Resonse. Das ist bidirektional, aber nicht full duplex.
Manch moderne Web-Anwendungen benötigen für den Datenaustausch das Konzept einer Standleitung, über die Daten quasi in Echtzeit übertragen werden können. Das betrifft zum einen die Datenlieferung vom Client zum Server (mit dem Client als aktiven Part) ABER auch die Datenlieferung vom Server zum Client (mit dem Server als aktivem Part).
Letzteres ist nicht neu: Konzepte, wie "Long poll" haben zumindest den Eindruck einer server-initiierten Datenlieferung vermittelt. Mit allen damit verbundenen Nachteilen, denn es ist nach wie vor HTTP mit dem damit verbundenen Overhead.
WebSocket ist ein Ansatz das Problem zu lösen. Grundidee:
- Ein Client schickt einen HTTP-Request mit einer Upgrade-Anforderung auf WebRequest
- Der Server schickt den Return-Code 101 mir dem unterstützten WebSocket-Schema
- Client und Server kommunizieren ab dann rein über TCP
- Der Browser muss HTML5 WebSocket unterstützen: Chrome 4.0+, Safari 5.0 & iOS4, Firefox 4 Beta, Opera 11 Alpha leisten dies. (Auf Nachfrage: IE9, eventuell) Auf http://websocket.org kann man den eigenen Browser testen.
- Die Webseite im Browser benötigt Javascript-WebSocket-APIs, wie z. B. Stomp, XMPP, AMQP
- Auf Serverseite blieben die Vortragenden eine Antwort schuldig. Schade.
Tag 3: 16:40 - 17:40: Spring 3.1: Themes and Trends
Jürgen Hoeller stellte auf bewährte Weise bekanntes und neues rund um Spring 3 dem zahlreich erschienenen Publikum vor.
Er begann mit einem "Rückblick" auf Spring 3.0 (aus unserer Sicht ist das sowas wie Zurück in die Zukunft). Der große Schwerpunkt: Annotations für alles und nichts.
Dann kam er Blick nach vorne, auch wenn das meiste noch in Arbeit sei.
Und gleich mit dem ersten Punkt sprach mir Jürgen aus dem Herzen: Environment profiles for beans. Hierhinter verbirgt sich die Möglichkeit Bean-Definitionen zu grupperien und einem bestimmten Profil zuordnen zu können. Mögliche Profile sind
Mit @Connfiguration wird Javas-basierte Konfiguration unterstützt. Typische Einsatzgebiete sind
Das Session-Management wird ebenfalls renoviert. Hier sollen Lifecycle und Speicheroptionen flexibilisiert werden (Stichwort: Conversation)
Früher oder später werden wir die Version 3.1 auch verwenden. Bis dahin müssen wir uins in Geduld üben, zumal das Datum der Veröffentlichung noch nicht klar scheint.
Er begann mit einem "Rückblick" auf Spring 3.0 (aus unserer Sicht ist das sowas wie Zurück in die Zukunft). Der große Schwerpunkt: Annotations für alles und nichts.
- @Value("#{aBean.aProperty}") als Fallback, wenn für annotierte Methode keine externe Konfiguration vorliegt.
- Standard-Annotations: @ManagedBean, @Inject, @TransactionAttribute
- REST-Support: @RequestMapping, @PathVariable
- Portlet 2.0 Support: @Controller, @RequestMapping, @ActionMapping, @EventMapping
- Declarative model validation (JSR-303): @NotNull, @Past (bei Date!), @Valid
- Annotation-driven number/date formatting and parsing
- Scheduling: @Scheduled(cron="0 0 12 * * ?") auf Methode (!), @Async
Dann kam er Blick nach vorne, auch wenn das meiste noch in Arbeit sei.
Und gleich mit dem ersten Punkt sprach mir Jürgen aus dem Herzen: Environment profiles for beans. Hierhinter verbirgt sich die Möglichkeit Bean-Definitionen zu grupperien und einem bestimmten Profil zuordnen zu können. Mögliche Profile sind
- Development, Testing, Produktion
- Unterschiedliche Deployment-Umgebungen
Mit @Connfiguration wird Javas-basierte Konfiguration unterstützt. Typische Einsatzgebiete sind
- AOP-Konfiguration
- Transaktionen
- Scheduling
Das Session-Management wird ebenfalls renoviert. Hier sollen Lifecycle und Speicheroptionen flexibilisiert werden (Stichwort: Conversation)
Früher oder später werden wir die Version 3.1 auch verwenden. Bis dahin müssen wir uins in Geduld üben, zumal das Datum der Veröffentlichung noch nicht klar scheint.
Tag 3: 15:10 - 16:10: Vaadin - Rich Web Applications in Java without Plug-ins or JavaScript
Vaadin ist yet yet yet another Web framework, welches ein einfaches rein serverseitiges Programmiermodell unter Verwendung von GWT anbietet. Die wesentliche Eigenschaft von Vaadin ist, dass sämtliche Technologien, die den Client oder die Kommunikation zwischen Client und Server betreffen (GWT, JSON, Ajax, ...) durch Vaadin vor dem Entwickler verborgen werden.
Vaadin bietet eine große Palette von fertig vorkonfektionierten Kompopnenten an, die hinsichtlich ihres Layoutings, aber auch hinsichtlich ihres Verhaltens (z. B. Lazy Loading, Paging) modernen Ansprüchen in der Web-Entwiclung genügen.
Die Entwicklung kann in Eclipse vorgenommen werden. Das Vaadin-Plugin stellt die gängigen Wizards zur Projekt- und Code-Erzeugung bereit. Beeindruckend ist der Visual Editor, obwohl er noch im Experimentierstadium ist.
Als Zieltechnologien werden
Als guter Startpunkt dient vaadin.com. Im Wiki befinden sich auch Informationen zur Verwendung von Spring in Vaadin.
Vaadin ist definitely worth a try. ;-)
Vaadin bietet eine große Palette von fertig vorkonfektionierten Kompopnenten an, die hinsichtlich ihres Layoutings, aber auch hinsichtlich ihres Verhaltens (z. B. Lazy Loading, Paging) modernen Ansprüchen in der Web-Entwiclung genügen.
Die Entwicklung kann in Eclipse vorgenommen werden. Das Vaadin-Plugin stellt die gängigen Wizards zur Projekt- und Code-Erzeugung bereit. Beeindruckend ist der Visual Editor, obwohl er noch im Experimentierstadium ist.
Als Zieltechnologien werden
- Servlet Engines
- Portlet Engines (1.0 und 2.0)
- Google App Engine
Als guter Startpunkt dient vaadin.com. Im Wiki befinden sich auch Informationen zur Verwendung von Spring in Vaadin.
Vaadin ist definitely worth a try. ;-)
Tag 3: 12:00 - 13:00: Java Persistence 2.0
Die Java Persistence API in der Version 2.0 ist Teil von JEE 6, aber auch Standalone einsetzbar. Sie ist Bestandteil von GlassFish v3. Als Referenzimplementierung dient EclipseLink.
Der Vortrag beschreibt die wesentlichen Neuerungen von JPA 2.0. Hier einige Ausszüge.
In Collections der Art Collection<AClass> kann AClass eine Klasse, aber auch ein Elementartyp sein. Durch die Verwendung von @ElementCollection plus @Embeddable wird in der Datenbank zusätzlich eine Mappingtabelle angelegt, welche neben der Id entweder eine Spalte für den Elemntartyp oder Spalten für sämtliche Attribute von AClass enthält. Das genaue Verhalten ist durch weitere Annotations konfigurierbar.
Die Annotation @OrderColumn erzeugt extra Spalte, über die sich eine Sortierung abbilden lässt. Eine Laufzeitsortierung erlaubt @OrderBy.
Die Java Persistence Query Language (JPQL) wird sprachlich erweitert um
Zum Locking lässt sich folgendes zusammenfassen.
Parametrierung:
Und last but not least wurde auch der 2nd Level Cache modernisiert:
Der Vortrag beschreibt die wesentlichen Neuerungen von JPA 2.0. Hier einige Ausszüge.
In Collections der Art Collection<AClass> kann AClass eine Klasse, aber auch ein Elementartyp sein. Durch die Verwendung von @ElementCollection plus @Embeddable wird in der Datenbank zusätzlich eine Mappingtabelle angelegt, welche neben der Id entweder eine Spalte für den Elemntartyp oder Spalten für sämtliche Attribute von AClass enthält. Das genaue Verhalten ist durch weitere Annotations konfigurierbar.
Die Annotation @OrderColumn erzeugt extra Spalte, über die sich eine Sortierung abbilden lässt. Eine Laufzeitsortierung erlaubt @OrderBy.
Die Java Persistence Query Language (JPQL) wird sprachlich erweitert um
- KEY, VALUE
- CASE
- "Restricted polimorphism"
- "Collection valued input parameter"
- CriteriaQuery
- CriteriaBuilder
- Root
- Join, ListJoin, MapJoin
- Path
- Subquery
- Parameter
- TypedQuery
- Tuple
- TupleElement
Zum Locking lässt sich folgendes zusammenfassen.
Parametrierung:
- Optimistic locking erfolgt auf Basis von @Version
- Insgesamt wurde die Parametrierung des Lockings von der Namensgebung her vereinheitlicht: OPTIMISTIC(READ), OPTIMISTIC_FORCE_INCREMENT(WRITE), PESSIMISTIC_READ, PESSIMISTIC_WRITE, PESSIMISTIC_FORCE_INCREMENT
- EntityManager: lock, find, refresh
- Query methods: setLockMode, setHint
- NamedQuery Annotation: lockMode element
- PessimisticLockException
- LockTimeoutException
Und last but not least wurde auch der 2nd Level Cache modernisiert:
- APIs und Kontroll-Optionen wurden hinzugefügt/erweitert (aus Portabilitätsgründen)
- In der API tauchen nun Methoden auf wie evict, evictAll, contains
- Annotation @Cacheable (ALL, NONE, ENABLE_SELECTIVE, DISABLE_SELECTIVE)
Tag 3: 10:50 - 11:40: The State of the Web
Diese Session lieferte einen globalen Überblick über vermeidliche Trends der Vergangenheit und über aktuelle Trends, mit denen sich die Web-Zukunft gestalten lässt.
Immer wieder wurde vom Potential von HTML 5 geredet, was dieser Standard selber liefert und welche Technologien mit zu deren Ökosystem gehören. Nahrhafte Details kamen aber nicht zum Vorschein.
Was hängen blieb, waren lediglich Informationen zum Nachschlagen:
Immer wieder wurde vom Potential von HTML 5 geredet, was dieser Standard selber liefert und welche Technologien mit zu deren Ökosystem gehören. Nahrhafte Details kamen aber nicht zum Vorschein.
Was hängen blieb, waren lediglich Informationen zum Nachschlagen:
Tag 3: 10:00 - 10:50: Java SE: The road ahead
So. Und jetzt Butter bei die Fische! Wo will Oracle mit Java hin?
Unter den Zynikern war vorher klar, dass Oralce solange an Java festhält, wie sie aus dem Rechtsstreit mit Google Geld ziehen können. :-)
Die Botschaft dieser Keynote war aber eine deutlich andere: Oracle hält in jedem Fall an Java fest. Aussagen in der REihenfolge der Gewichtung:
Unter den Zynikern war vorher klar, dass Oralce solange an Java festhält, wie sie aus dem Rechtsstreit mit Google Geld ziehen können. :-)
Die Botschaft dieser Keynote war aber eine deutlich andere: Oracle hält in jedem Fall an Java fest. Aussagen in der REihenfolge der Gewichtung:
- Für Oracle ist Java die Nummer-1-Technologie. Man arbeite selber sehr viel mit Java und hat eine große Zahl an Entwickler-Know-how im eigenen Hause, welches man durch eine Abkehr von Java nicht verlieren (bzw. vernichten) möchte.
- Man hofft durch Java-basierte Plattformen und Frameworks indirekt Profit daraus zu erzeugen.
- Man hofft durch Beratungsleistungen direkt Profit aus aktuellen und zukünftigen Entwicklungen rund um Java zu erzielen.
- Reduzierung der Entwicklungskosten (siehe auch 1.).
- JCP
- openJDK
- Partner für openJDK (u. a. IBM, Apple)
- Neue Sprach-Features zur Verbesserung der Produktivität (Code-Vereinfachungen) und Performance (Unterstützung von Mehrkern-Prozessoren). Hier ist besonders das Lambda-Projekt zu nennen, welches u. a. Closures in die Java-Welt bringt.
- Immutable Ojects sollen zukünfirg mittels "value class ..." deklariert werden können.
- Aprospos Sprache: Typ-Informationen aus Java Generics werden aktuell via Type erasure auf Bytecode-Ebene gelöscht. Oracle will dies ändern! Mit einer Technik namens "Type reification" sollen diese Typinformationen zukünfitg erhalten bleiben! Das wird ein tiefer Eingriff in die VM.
- Die Java-Plattform soll modularer werden. Java-Anwendungen sollen leichter in unterschiedliche Zielsysteme integrierbar sein. Hier spielt das Jigsaw-Projekt eine wichtige Rolle.
- Zur besseren Integration von Nicht-Java-Sprachen auf der JVM wird das DaVinci Machine-Projekt voran getrieben.
- Oracle und Sun sind nun eine Firma mit zwei JVMs. Diese JVMs sollen zukünftig zu einer gemeinsame VM namens Hotspot zusammenwachsen.
Tag 3: 9:30 - 10:00: Welcome and Intro
Nach den ersten beiden University Days beginnt heute die eigentliche Konferenz.
Die Begrüßung beginnt mit Statistiken und Selbstbeweihräucherung:
Wirklich wichtig: Parleys.com, das Portal, worüber die Sessions als Videos abgerufen werden können, ist in Version 4 erschienen. Zu einem Unkostenbeitrag von 79€ im Jahr erhält man Zugriff auf sämtliche Beiträge von diesem Jahr. Die Sessions der vorherigen Jahre sind inzwischen frei verfügbar.
Auch hier stehen mehrere Clients zur Verfügung (gratis), u. a. für Android aus dem Android Market (Suchbegriff: "Parleys"). Hab's ausprobiert: Cool!
Anregung: In Zukunft die Gebühr für Parleys abdrücken und Kosten für Reise und Teilnahme sparen.
Die Begrüßung beginnt mit Statistiken und Selbstbeweihräucherung:
- 3000 Teilnehmer
- aus 40 Ländern (u. a. sei jedes europäische Land mit mindestens einem Teilnehmer vertreten; wichtig zu wissen)
- bekommen 127 Tracks
- von 110 Vortragenden geboten.
Wirklich wichtig: Parleys.com, das Portal, worüber die Sessions als Videos abgerufen werden können, ist in Version 4 erschienen. Zu einem Unkostenbeitrag von 79€ im Jahr erhält man Zugriff auf sämtliche Beiträge von diesem Jahr. Die Sessions der vorherigen Jahre sind inzwischen frei verfügbar.
Auch hier stehen mehrere Clients zur Verfügung (gratis), u. a. für Android aus dem Android Market (Suchbegriff: "Parleys"). Hab's ausprobiert: Cool!
Anregung: In Zukunft die Gebühr für Parleys abdrücken und Kosten für Reise und Teilnahme sparen.
Dienstag, 16. November 2010
Tag 1: 17:25 - 17:55 - VisualVM - multiplatform versatile monitoring solution von Jaroslav Bachorik
Der Talk dauerte nur eine halbe Stunde und sollte zeigen wie einfach man das im JDK enthaltene Tool mittles Plugin erweitern kann. Leider ist dem Sprecher, in der Kürze der Zeit, nicht gelungen das Vortragsziel zu vermitteln.
Schade ;-(
Die einzigen Notizen die ich mir zum Vortrag gemacht habe:
Schade ;-(
Die einzigen Notizen die ich mir zum Vortrag gemacht habe:
- Visual VM
- NetBeans 6.9.1
- Plugin für VisualVM
Tag 1: 16:45 - 17:15 - Beautiful Java EE: URL-rewriting for the next generation web-user von Lincoln Baxter III
Schnell stellte sich heraus das es um PrettyFaces geht, das uns in der Entwicklung schon begegnet ist. Das einzige Neue für mich war, dass PrettyFaces auch ohne JSF sinnvoll eingesetzt werden kann.
Der Talk war kurz und leider ist der Funke nicht über gesprungen.
Wertung:
Der Talk war kurz und leider ist der Funke nicht über gesprungen.
Wertung:
Tag 1: 09:30 - 12:30 - Productive Programmer von Neal Ford
Neal Ford ist Software Architekt bei ThoughtWorks. ThoughtWorks ist u.a. auch bekannt für die OpenSource-Produkte wie CruiseControl und Selenium. Neal ist Author von sechs IT-Büchern u.a. passend zum heutigen Talk das Buch "The Productive Programmer".
Der Vortrag war in verschiedene Themenschwerpunkt unterteilt:
accelerate
Hier ging es um die Produktivitätssteigerung durch Erweiterung eingesetzter Software durch Plugins bzw. Addons. Neal meinte sobald ein Entwickler gezwungen wird die Hände von den Tasten zu nehmen (um z.B. die Maus zu benutzen), würde seine Produktivität erheblich sinken.
Das Mantra war: "use short-cuts"
Er empfahl sogar ein Eclipse-Plugin namens Mousefeed, das sich meldet wenn der Entwickler in einem Menü etwas mit der Maus auswählt anstatt es mit einem Short-Cut zu aktivieren. Das Plugin soll den Entwickler "zwingen" die Short-Cuts zu lernen.
Getreu dem DRY-Prinzip empfahl er dem Entwickler "Every time you type things 3 times, do a template". Auch für Emails die sich häufig wiederholen, aber nur wenig Änderungen beinhalten, wie z.B. unsere "Testsystem XX wird in kürze heruntergefahren *EOM*"-Emails sollten "Templatisiert" werden.
Ich habe mir vorgenommen zumindest das Plugin Mousefeed zu installieren, um zu sehen welche Short-Cuts noch nicht angekommen sind. Denn das Short-Cuts erheblich schneller sind, steht für mich außer Frage. Es soll jedoch Kollegen(-innen) geben die sogar ein Copy-To-Clipboard mir der Maus ausführen.
Die o.g. Info-Emails sind dank Olaf auch mit einem Klick erzeugt - danke.
focus
Bei diesem Themenschwerpunkt ging es um den Arbeitsplatz als solches.
Beispiele:
canonicality
Baue kleine Tools für wiederkehrende Aufgaben des Alltags. Suche Tools die dir die Arbeit abnehmen können. Oder wie Du Dein Leben einfacher machen kannst indem du die QS schulst wie Selenium-Tests zur Fehler-Beschreibung einer Webanwendung geschrieben werden können. So das auf beiden Seiten Zeit gespart werden kann.
Manta an dieser Stelle: "Automate what is to automate"
Gern würde ich alles erläutern, daß würde aber den Rahmen dieses Blogs sprengen.
Die andere Themen waren:
Ich war von dem Vortrag begeistert und habe beschlossen allen Vorträgen meine subjektive Bewertung zu geben.
Diese Vortrag erhält von mir glatte fünf Sterne (höchst Zahl) und legt die Messlatte für die anderen kommenden Vorträge recht hoch.
Glückwunsch an Neal Ford für den gelungenen Vortrag.
Der Vortrag war in verschiedene Themenschwerpunkt unterteilt:
accelerate
Hier ging es um die Produktivitätssteigerung durch Erweiterung eingesetzter Software durch Plugins bzw. Addons. Neal meinte sobald ein Entwickler gezwungen wird die Hände von den Tasten zu nehmen (um z.B. die Maus zu benutzen), würde seine Produktivität erheblich sinken.
Das Mantra war: "use short-cuts"
Er empfahl sogar ein Eclipse-Plugin namens Mousefeed, das sich meldet wenn der Entwickler in einem Menü etwas mit der Maus auswählt anstatt es mit einem Short-Cut zu aktivieren. Das Plugin soll den Entwickler "zwingen" die Short-Cuts zu lernen.
Getreu dem DRY-Prinzip empfahl er dem Entwickler "Every time you type things 3 times, do a template". Auch für Emails die sich häufig wiederholen, aber nur wenig Änderungen beinhalten, wie z.B. unsere "Testsystem XX wird in kürze heruntergefahren *EOM*"-Emails sollten "Templatisiert" werden.
Ich habe mir vorgenommen zumindest das Plugin Mousefeed zu installieren, um zu sehen welche Short-Cuts noch nicht angekommen sind. Denn das Short-Cuts erheblich schneller sind, steht für mich außer Frage. Es soll jedoch Kollegen(-innen) geben die sogar ein Copy-To-Clipboard mir der Maus ausführen.
Die o.g. Info-Emails sind dank Olaf auch mit einem Klick erzeugt - danke.
focus
Bei diesem Themenschwerpunkt ging es um den Arbeitsplatz als solches.
Beispiele:
- Bequememen/Ergonomischen Stuhl
- Zwei Bildschirme (sollen die Produktivität erhöhen)
- Ergonomisches Keyboard
canonicality
Baue kleine Tools für wiederkehrende Aufgaben des Alltags. Suche Tools die dir die Arbeit abnehmen können. Oder wie Du Dein Leben einfacher machen kannst indem du die QS schulst wie Selenium-Tests zur Fehler-Beschreibung einer Webanwendung geschrieben werden können. So das auf beiden Seiten Zeit gespart werden kann.
Manta an dieser Stelle: "Automate what is to automate"
Gern würde ich alles erläutern, daß würde aber den Rahmen dieses Blogs sprengen.
Die andere Themen waren:
- dont shave yaks!
- composed-method
- test-driven-development
- top-10-code-smells
- question authority
- slap
- polyglott programming
- every nuance
Ich war von dem Vortrag begeistert und habe beschlossen allen Vorträgen meine subjektive Bewertung zu geben.
Diese Vortrag erhält von mir glatte fünf Sterne (höchst Zahl) und legt die Messlatte für die anderen kommenden Vorträge recht hoch.
Glückwunsch an Neal Ford für den gelungenen Vortrag.
More to come...
Der erste Tag stellte sich als sehr anstrengend heraus, sodass ich noch keine Zeit gefunden habe etwas zu den Vorträgen zu schreiben.
Jörn gibt ein Blog-Tempo vor, das es mir schwer macht mit zu halten. Da ich gestern todmüde ins Bett gefallen bin, hab ich mir vorgenommen wenigstens heute etwas zu berichten (und sei es nur vom Vortag).
Tag 2: 19:00 - 22:00: BoFs (eigentlich)
Grundsätzlich ging es auch heute wieder um interessante Themen:
Daher werde ich an den folgenden Tagen mit hoher Wahrscheinlichkeit an den BoFs nicht mehr teilnehmen. Stattdessen werde ich lieber die Zeit nutzen, das bis dahin in den "normalen" Sessions vermittelte Wissen noch mal aufzubereiten und die Ergebnisse an dieser Stelle zu präsentieren. Ich glaube, davon haben alle mehr. Ich zum Beispiel habe mehr Schlaf. ;-)
- Scala
- Scalable data structures for Java
- Dealing with Asynchronicity in Java™ Technology-Based Web Services
Daher werde ich an den folgenden Tagen mit hoher Wahrscheinlichkeit an den BoFs nicht mehr teilnehmen. Stattdessen werde ich lieber die Zeit nutzen, das bis dahin in den "normalen" Sessions vermittelte Wissen noch mal aufzubereiten und die Ergebnisse an dieser Stelle zu präsentieren. Ich glaube, davon haben alle mehr. Ich zum Beispiel habe mehr Schlaf. ;-)
Tag 2: 17:25 - 17:55: Scalable and RESTful web applications: at the crossroads of Kauri and Lily
Am Ende der Session habe ich mich gefragt: Musste ich Kauri und Lily vorher kennen? Dann habe ich mich gefragt, ob ich es in Zukunft kennen muss. Ich habe mich bei beiden Fragen für "nein" entschieden.
Damit die Infos trotzdem nicht verloren gehen, hier die Links zu den Produkten
Wer mehr wissen möchte, kann dort nachlesen.
Damit die Infos trotzdem nicht verloren gehen, hier die Links zu den Produkten
Wer mehr wissen möchte, kann dort nachlesen.
Tag 2: 16:45 - 17:15: Groovy/Grails Development in Eclipse
Ich bin erleuchtet! Bisher nahm ich an, dass IntelliJ IDEA und Netbeans diejenigen IDEs sind, welche die beste Unterstützung für die Entwicklung von GRoovy-/Grails-Applikationen sind. SpringSource hält dagegen und baut deren Tool Suite (STS), welche unter Eclipse läuft massiv aus.
Die zahlreichen Demos zeigten eindrucksvoll das aktuelle Feature Set, welches als Groovy/Grails Extensions über das STS Dashboard in die Eclipse-Umgebung geholt wird. Dabei wurde sehr großer Wert darauf gelegt, dass sich die Groovy-Entwicklung genauso anfühlt, wie die Java-Entwicklung. Aus der IDE heraus scheint nun folgendes "seamless" möglich zu sein:
Aktuell wird Groovy in den Version 1.6 und 1.7 unterstützt. Aus der Ferne war die Unterstützung für Grails 1.3.5 erkennbar.
Jetzt habe ich eine Sorge weniger, wenn es darum geht, Groovy/Grails intensiver in unseren Projekten einzusetzen (intensiver Test vorausgesetzt), denn: Ein Wechsel der IDE scheint nicht mehr notwendig zu sein.
Die zahlreichen Demos zeigten eindrucksvoll das aktuelle Feature Set, welches als Groovy/Grails Extensions über das STS Dashboard in die Eclipse-Umgebung geholt wird. Dabei wurde sehr großer Wert darauf gelegt, dass sich die Groovy-Entwicklung genauso anfühlt, wie die Java-Entwicklung. Aus der IDE heraus scheint nun folgendes "seamless" möglich zu sein:
- Projekt-Wizard für Groovy/Grails
- Syntax Highlighting
- Refactoring
- Compile, Run, Test und ... Debugging (!) mit guter Anzeige der Variablen-Inhalte
- Script Shell
- Auto-Deployment auf Springs eigenen tc Server
- Hot-Deployment
- Nahtlose Integration in Java-Code
Aktuell wird Groovy in den Version 1.6 und 1.7 unterstützt. Aus der Ferne war die Unterstützung für Grails 1.3.5 erkennbar.
Jetzt habe ich eine Sorge weniger, wenn es darum geht, Groovy/Grails intensiver in unseren Projekten einzusetzen (intensiver Test vorausgesetzt), denn: Ein Wechsel der IDE scheint nicht mehr notwendig zu sein.
Tag 2: 13:30 - 16:30: What's new in Hibernate
Direkt nach dem Mittagessen kam die dreistündige Hibernate-Druckbetankung. Viel Material zu alten Bekannten und neuen Projekten im Hibernate-Ökosystem.
Das objekt-relationale Mapping (ORM) wird um interessante Eigenschaften erweitert. Beim Mapping von Ids (besonders bei der Abbildung vvon Objektbeziehungen) gibt es jetzt Unterstützung über die Annotation @MapsId. Bei zusammengesetzten Schlüsseln können die Ids der daran beteiligten Attribute auf unterschiedliche Weise generiert werden (partial generation). BEim lesenden und schreibenden Zugriff auf Klassenattribute (Tabellenspalten) kann über die Annotation @ColumnTransformer der Wert verändert werden. Das Thema "Lazy Loading" kann nun zusätzlich mit sogenannten Fetch profiles feingranularer konfiguriert werden.
Die Criteria API versucht seit jeher einen objektorientierten, typsicheren und DB-neutralen Zugriff auf die Datenbasis zu ermöglichen. Hier wurde anhand von Codebeispielen der Umgang mit
Ergänzt wurde dies mit Hinweisen zu Änderungen in Hibernate 3.6, u. a.:
Ein kleiner Ausflug war Hibernate Spacial. Dieses Projekt hat sich zum Ziel gesetzt, eine auf einfache Weise nutzbare Geo-Suche in Java zu ermöglichen. Auch hier kommt wieder die Criteria-API zum Einsatz.
Mit Hibernate Envers wurde ein Projekt vorgestellt, das sich der Hidstorisierung von Daten widmet. Grundidee: Bestehende Tabellen werden nicht verändert. Je Tabelle wird eine Audit-Tabelle ergänzt, welche die historisierten Daten enthält. Jeder historisierte Datensatz wird dort komplett abgelegt und bekommt eine DB-global eindeutige Versionsnummer (wie in SVN). Damit das funktiuoniert muss Hibernate Envers natürlich in den Classpath, Event Listener müssen ergänzt und die zu versionierenden Entity-Klassen mit @Audited annotiert werden.
Aber wie kommt man an historisierte Daten wieder heran? Heirzu wurden drei Varianten vorgestellt:
Mit der Vorstellung von Hibernate Validator ging's weiter. Dies ist die Bean-Validation-Referenz-Implementierung. Ziel: Definition EINER Stelle, an der für sämtliche Anwendungsteile (GUI, BLog) die Validierung von Domain-Objekten erfolgt. Der Fokus des Vortrages lag hier bei den Neuerungen, als da wären:
Das war Druckbetankung pur, gab einem aber einen umfassenden Einblick in das, was das Hibernate Ökosystem leistet. In Teilen verwenden wir einzelne Projekte davon ja bereits. Interessant ist Hibernate Envers: Dies könnte den Eigenbau in unseren Produkten ersetzen...
Das objekt-relationale Mapping (ORM) wird um interessante Eigenschaften erweitert. Beim Mapping von Ids (besonders bei der Abbildung vvon Objektbeziehungen) gibt es jetzt Unterstützung über die Annotation @MapsId. Bei zusammengesetzten Schlüsseln können die Ids der daran beteiligten Attribute auf unterschiedliche Weise generiert werden (partial generation). BEim lesenden und schreibenden Zugriff auf Klassenattribute (Tabellenspalten) kann über die Annotation @ColumnTransformer der Wert verändert werden. Das Thema "Lazy Loading" kann nun zusätzlich mit sogenannten Fetch profiles feingranularer konfiguriert werden.
Die Criteria API versucht seit jeher einen objektorientierten, typsicheren und DB-neutralen Zugriff auf die Datenbasis zu ermöglichen. Hier wurde anhand von Codebeispielen der Umgang mit
- Lazy Loading (default, übersteuerbar mit fetch())
- Aliases
- Joins
- CriteriaBuilder.createTupleQuery()
- Subqueries und
- Views
Ergänzt wurde dies mit Hinweisen zu Änderungen in Hibernate 3.6, u. a.:
- 2nd Level Cache und die Verwendung von Infinispan
- CGLIB ist deprecated (stattdessen Verwendung von Javassist)
- Das Packaging (die Modularisierung) wurde angepasst
- Kein Support mehr für Java 1.4
Ein kleiner Ausflug war Hibernate Spacial. Dieses Projekt hat sich zum Ziel gesetzt, eine auf einfache Weise nutzbare Geo-Suche in Java zu ermöglichen. Auch hier kommt wieder die Criteria-API zum Einsatz.
Mit Hibernate Envers wurde ein Projekt vorgestellt, das sich der Hidstorisierung von Daten widmet. Grundidee: Bestehende Tabellen werden nicht verändert. Je Tabelle wird eine Audit-Tabelle ergänzt, welche die historisierten Daten enthält. Jeder historisierte Datensatz wird dort komplett abgelegt und bekommt eine DB-global eindeutige Versionsnummer (wie in SVN). Damit das funktiuoniert muss Hibernate Envers natürlich in den Classpath, Event Listener müssen ergänzt und die zu versionierenden Entity-Klassen mit @Audited annotiert werden.
Aber wie kommt man an historisierte Daten wieder heran? Heirzu wurden drei Varianten vorgestellt:
- Gezieltes Finden über Revision number: Hier gibt es eine spezielle find-Methode mit Angabe der Entity-Klasse, seiner Id und der gesuchten Revision number.
- Query über Revision number: Hier gibt es eine spezielleforEntityAtRevision-Methode mit Angabe der Entity-Klasse und der gesuchten Revision number.
- Query über Entity history: Hier gibt es eineforRevisionOfEntity -Methode.
Mit der Vorstellung von Hibernate Validator ging's weiter. Dies ist die Bean-Validation-Referenz-Implementierung. Ziel: Definition EINER Stelle, an der für sämtliche Anwendungsteile (GUI, BLog) die Validierung von Domain-Objekten erfolgt. Der Fokus des Vortrages lag hier bei den Neuerungen, als da wären:
- Neue Annotation @ScriptAssert: Ermöglicht auf Klassenebene eine Datenvalidierung mit Hilfe von Skripten.
- Es gibt eine API, welche die direkte Programmierung der Constraints ermöglicht.
- Method level validation, im Sinne einer Prüfung von Pre- und Post-Conditions. So ein bisschen, wie AOP-Advices, nur eleganter.
Das war Druckbetankung pur, gab einem aber einen umfassenden Einblick in das, was das Hibernate Ökosystem leistet. In Teilen verwenden wir einzelne Projekte davon ja bereits. Interessant ist Hibernate Envers: Dies könnte den Eigenbau in unseren Produkten ersetzen...
Tag 2: 13:00 - 13:15: Programming in pain
In diesem 15 Minuten dauernden Quickie ging es nicht um eine neue Programmiersprache namens "pain". Vielmehr lautete der Untertitel sinngemäß: "Wie das Programmieren mit Scala meinen Blick auf die Programmierung mit Java veränderte".
Der Vortragende ging dabei auf folgende Scala-Features ein, welche den Umgang mit der Sprache sehr elegant machen:
Der Vortragende ging dabei auf folgende Scala-Features ein, welche den Umgang mit der Sprache sehr elegant machen:
- Named arguments: In Scala kann man einer Methode/einem Konstruktor Parameter unter Angabe des zugehörigen Parameternamens übergeben. Dies ist in Java nicht möglich. Baut man hingegen seine Java-Klassen in Form einer DSL, in der Methoden den Parameternamen entsprechen, kann man das Scala-Feature einigermaßen elegant nachbilden und einen deutlich sprechenderen und fehlerfreieren Code erhalten.
- Variables and Values: Scala kennt Variablen-Deklarationen mit "var" und "val", wobei letztere dem "final" in Java entsprechen. Der Vortragende rät dazu, wesentlich gezielter "final" einzusetzen.
- Normally immutable: In Scala sind defaultmäßig alle Objekte unveränderlich. In Java gilt dies nur zum geringen Teil (z. B. String) und besonders bei Collections garnicht. Daher der Rat für eigene Klassen (wo umsetzbar): Nach Möglichkeit auf setter verzichten (!) und in getter-Methoden Kopien der Objektdaten zurückgeben. Dies verhindert "programming by side-effect".
- Small classes: Scala gehört wohl zu denjenigen Sprachen mit der kompaktesten Möglichkeit Klassen zu beschreiben. Hier gibt es unter Java keinen Gegenentwurf.
- Collections: Scala hat Collections im Angebot, die leicht zu initialisieren und durch nette Hilfsmethoden einfach zu verarbeiten sind. Java kennt zur Initialisierung allenfalls Array.asList(...). Hier können die Bibliotheken von Google Guava hilfreich sein.
- Object composition: Zu Scalas Traits hat Java definitiv keinen Gegenentwurf.
- Advanced switches: Scala erlaubt in Switch-Case-Anweisungen den Vergleich mit beliebigen Objekt-Typen. In Java undenkbar. Der Vortragende hat aber eine interessante DSL vorgestellt, mit der man das nachbilden könnte.
Tag 2: 9:30 - 12:30: Introducing Wicket
Was für ein Tag 1! Die Müdigkeit noch nicht ganz aus den Augen gerieben geht es nach gutem Frühstück in die erste Session von Tag 2. Nach dem morgentlichen Blick auf den Teller schweift nun der Blick erneut über den Tellerrand hinaus und schaut sich mal an, was Apache Wicket so zu bieten hat.
Wicket ist "yet another web framework", welches alles, was in der Java-Welt aktuell modern ist, verspricht zu leisten.
Veröffentlicht unter der Apache Licence 2.0 liegt Wicket zurzeit in der Version 1.5-M3 vor.
Die zentralen Features im Überblick
Der Vortrag entwickelte sich aber recht interessant. Im Vergleich zu anderen Web Frameworks, welche zum Rendern des Clients auf JSP, JSF oder GSP (Grails) setzen und im gewissen Maße die Programmierung von Logik in der UI-Schicht erlauben, setzt Wicket rein auf HTML. Der Rest (Logik, Validierung, Navigation) findet ausschließlich auf der Java-Seite statt. Die Verbindung zwischen HTML-Seite und Java-Klasse erfolgt über "Tricks" und Namenskonventionen.
Der "Trick" dahinter besteht im Ausnutzen einer Eigenschaft von HTML (beziehungsweise der Browser, die HTML rendern): Alles, was ein HTML-Renderer nicht kennt, wird ignoriert. Dies gilt sowohl für Nicht-HTML-Tags als auch für Nicht-HTML-Attribute.
Und genau hier setzt Wicket an. Wicket definiert ein Attribut namens "wicket:id". Wenn sich eine Wicket-Komponente (s. u.) auf ein HTML-Tag beziehen soll, dann erweitert man dieses HTML-Tag um ein wicket:id-Attribut und gibt ihm einen Wert, den man wiederum in Java referenziert.
Dieses Vorgehen hat den Vorteil, dass ein UI-Designer direkt auf Ebene von HTML und CSS arbeiten und jederzeit das Ergebnis in unterschiedlichen Browsern sehen und testen kann, ohne durch Frameworks oder Servlet Container unterstützt werden zu müssen.
Auf UI-Seite geht es aber trotzdem nicht ganz ohne Wicket-Magie: HTML-Seiten haben das Problem, dass sie von Haus aus keine hinreichend gute Unterstützung für die Zerlegung einer Seite in Teilseiten haben. Externe Bilder, Javascript und CSS können über entsprechende Tags eingebunden werden. Eine HTML-Seite kann zwar in mehrere zerlegt und via <frame> oder <iframe> wieder zusammengebaut werden. Ein Templating (wie beispielsweise von Struts Tiles oder Sitemesh gewohnt) gibt es aber nicht. Diese Lücke versucht Wicket mit den Tags <wicket:child> und <wicket:extend> zu füllen.
Auf Java-Seite konzentriert sich der Entwickler auf die Programmierung der Seitenlogik und der Seitennavigation. Dabei wird die Zugehörigkeit einer Java-Klasse zu einer HTML-Seite über den gemeinsamen Klassen-/Dateinamen geregelt (Convention over configuration).
Die Seitenlogik folgt dem MVC-Pattern. Jede Seitenklasse (Page) und sämtliche Controls auf der Seite sind Wicket-Komponenten, die ineinander gestöpselt werden können und in Summe den Komponentenbaum einer Seite bilden.
Sämtliche Wicket-Komponenten sind wiederum Java-Klassen, die individuell erweitert werden können (durch Vererbung). Alternativ können neue Komponenten durch Implementierung entsprechender Interfaces geschaffen werden.
Sämtlicher Komponenten können Events verarbeiten (z. B. onClick). In den zahlreichen Demos wurde hierfür der Weg über anonymous inner classes verwendet, welche per "new" erzeugt und danach der Komponente bekannt gegeben wird.
Apropos "new": Wicket-Komponenten durchleben zwar ein Lifecycle; es bedarf aber keiner besonderen Factories um sie zu erzeugen oder bei einem "Lifecycle-Manager" anzumelden. Erzeugt werden sie einfech durch "new".
WIcket bietet von Haus aus eine Reihe von Komponenten an:
In den Demos wurde eine der klassischen Web-Hello-World-Anwendungen gebaut: Ein Shopping-Portal. Die Beispiel zeigte auf elegante Weise die Vorzüge bei der Entwicklung auf Basis von Wicket:
Fazit: Unbedingt anschauen!
Wicket ist "yet another web framework", welches alles, was in der Java-Welt aktuell modern ist, verspricht zu leisten.
Veröffentlicht unter der Apache Licence 2.0 liegt Wicket zurzeit in der Version 1.5-M3 vor.
Die zentralen Features im Überblick
- Java-basiert
- Code-zentriert
- Komponenten-orientiert
- Strikte Trennung zwischen Design und Code
Der Vortrag entwickelte sich aber recht interessant. Im Vergleich zu anderen Web Frameworks, welche zum Rendern des Clients auf JSP, JSF oder GSP (Grails) setzen und im gewissen Maße die Programmierung von Logik in der UI-Schicht erlauben, setzt Wicket rein auf HTML. Der Rest (Logik, Validierung, Navigation) findet ausschließlich auf der Java-Seite statt. Die Verbindung zwischen HTML-Seite und Java-Klasse erfolgt über "Tricks" und Namenskonventionen.
Der "Trick" dahinter besteht im Ausnutzen einer Eigenschaft von HTML (beziehungsweise der Browser, die HTML rendern): Alles, was ein HTML-Renderer nicht kennt, wird ignoriert. Dies gilt sowohl für Nicht-HTML-Tags als auch für Nicht-HTML-Attribute.
Und genau hier setzt Wicket an. Wicket definiert ein Attribut namens "wicket:id". Wenn sich eine Wicket-Komponente (s. u.) auf ein HTML-Tag beziehen soll, dann erweitert man dieses HTML-Tag um ein wicket:id-Attribut und gibt ihm einen Wert, den man wiederum in Java referenziert.
Dieses Vorgehen hat den Vorteil, dass ein UI-Designer direkt auf Ebene von HTML und CSS arbeiten und jederzeit das Ergebnis in unterschiedlichen Browsern sehen und testen kann, ohne durch Frameworks oder Servlet Container unterstützt werden zu müssen.
Auf UI-Seite geht es aber trotzdem nicht ganz ohne Wicket-Magie: HTML-Seiten haben das Problem, dass sie von Haus aus keine hinreichend gute Unterstützung für die Zerlegung einer Seite in Teilseiten haben. Externe Bilder, Javascript und CSS können über entsprechende Tags eingebunden werden. Eine HTML-Seite kann zwar in mehrere zerlegt und via <frame> oder <iframe> wieder zusammengebaut werden. Ein Templating (wie beispielsweise von Struts Tiles oder Sitemesh gewohnt) gibt es aber nicht. Diese Lücke versucht Wicket mit den Tags <wicket:child> und <wicket:extend> zu füllen.
Auf Java-Seite konzentriert sich der Entwickler auf die Programmierung der Seitenlogik und der Seitennavigation. Dabei wird die Zugehörigkeit einer Java-Klasse zu einer HTML-Seite über den gemeinsamen Klassen-/Dateinamen geregelt (Convention over configuration).
Die Seitenlogik folgt dem MVC-Pattern. Jede Seitenklasse (Page) und sämtliche Controls auf der Seite sind Wicket-Komponenten, die ineinander gestöpselt werden können und in Summe den Komponentenbaum einer Seite bilden.
Sämtliche Wicket-Komponenten sind wiederum Java-Klassen, die individuell erweitert werden können (durch Vererbung). Alternativ können neue Komponenten durch Implementierung entsprechender Interfaces geschaffen werden.
Sämtlicher Komponenten können Events verarbeiten (z. B. onClick). In den zahlreichen Demos wurde hierfür der Weg über anonymous inner classes verwendet, welche per "new" erzeugt und danach der Komponente bekannt gegeben wird.
Apropos "new": Wicket-Komponenten durchleben zwar ein Lifecycle; es bedarf aber keiner besonderen Factories um sie zu erzeugen oder bei einem "Lifecycle-Manager" anzumelden. Erzeugt werden sie einfech durch "new".
WIcket bietet von Haus aus eine Reihe von Komponenten an:
- Labels
- Links
- Repeaters
- Forms
- TextField
- DropdownChoice
- Panel
- DataView
- DataTable
- Aus Sicht der Page bilden sie ein Delegate zur eikgentlichen Datenquelle und erlauben es der Page über Änderungen in der DAtenquelle automatisch informiert zu werden.
- Datenzugriffe werden null-safe, besonders wenn man entlang eines Objektgraphen navigiert (z. B. "person.adresse[0].strasse")
In den Demos wurde eine der klassischen Web-Hello-World-Anwendungen gebaut: Ein Shopping-Portal. Die Beispiel zeigte auf elegante Weise die Vorzüge bei der Entwicklung auf Basis von Wicket:
- Erstmal eine HTML-Seite bauen.
- Dann eine Page programmieren.
- Die in der Page auftauchenden Controls (deren Namen) per wicket:id in der HTML-Seite dem jeweiligen HTML-Tag zuordnen.
- Page-Navigation (und gf. HTML-Zielseite) ergänzen.
- Fertig.
- Bookmarkable Links
- URL-Rewriting
- Strategien zur Vermeidung von Double submit out-of-the-box
- WicketTester für Komponenten-Test innerhalb von JUnit und ohne Container (!)
- Wicket Debugger
Fazit: Unbedingt anschauen!
Montag, 15. November 2010
Tag 1: 19:00 - 22:00: BOFs
Die BoF-Sessions sind primär ein Erfahrungsaustausch unter Gleichgesinnten. Dieses BOFs hatten sämtlich den Charakter einer Q&A Session, in denen Experten zu den jeweiligen Themen auf Fragen aus der Praxis und zur Zukunft einzelner Technologien Stellung bezogen. Die Themen waren:
- Groovy/Grails Get Together
- Spring BOF
- jpatterns.org - Annotations for Pointing out Patterns in Your Code
Tag 1: 17:25 - 17:55: Programatic UI - how to build UI and avoid acute chevronitis
Ok: Der erste Na-ja-geht-so-Vortrag. Die wesentlichen Aussagen:
1. die aktuelle Tool-Unterstützung für XML-basierte Konfiguration oder GUI-Beschreibung inzwischen sehr gut ist und das Fehlerpotential bei der Entwicklung stark minimiert,
2. ObjectForms bis auf eine Web-Präsenz noch nichts zu bieten hat und nominell auf Android und GWT beschränkt sein wird.
- String-Bezeichner sind die Ursache für sämtliche Probleme beim Programmieren.
- Es gibt neue Plattformen, welche massiv auf UI-Beschreibungen in XML setzen, z. B. Android.
- Um Java-Business-Logik mit der "XML"-GUI kommunizieren zu lassen, ist viel "überflüssiger" Glue Code notwendig.
- Das ist schlecht!
- Wenn Du in Java programmierst, nutze auf jeder Ebene den zentralen Vorzug, den Java bieten kann: Kontrolle durch den Compiler!
- Programmiere die GUI in Java!
- Nutze Reflection, um aus der BLog eine mögliche GUI "abzuleiten".
- Nutze zusätzlich ObjectForms-Annotations, um den Glue Code weiter zu minimieren.
1. die aktuelle Tool-Unterstützung für XML-basierte Konfiguration oder GUI-Beschreibung inzwischen sehr gut ist und das Fehlerpotential bei der Entwicklung stark minimiert,
2. ObjectForms bis auf eine Web-Präsenz noch nichts zu bieten hat und nominell auf Android und GWT beschränkt sein wird.
Tag 1: 16:45 - 17:15: Developer Tools to push productivity
In dieser Session steht das Spring-Ökosystem im Mittelpunkt. Neben Wiederholungen zu Roo und ein paar bekannten Dingen zu STS gab es folgende (für mich) neue Informationen:
Durch die FinCon-Brille betrachtet ist dies definitiv zu evaluieren!
Insgesamt wird ein Trend deutlich: Spring integriert in immer stärkerem Maße Google-Technologien, teilweise als "first choice", wenn es darum geht, für einzelne Aspekte Defaults zu definieren:
- Groovy/Grails-Support hat seinen Weg in STS gefunden. Details hierzu blieben aber offen.
- tc Server (Tomcat-Variante von Spring) mit verbesserter Unterstützung von Redeployment während der Entwicklung ohne Neustart des Servers
- Spring Insight (!)
Durch die FinCon-Brille betrachtet ist dies definitiv zu evaluieren!
Insgesamt wird ein Trend deutlich: Spring integriert in immer stärkerem Maße Google-Technologien, teilweise als "first choice", wenn es darum geht, für einzelne Aspekte Defaults zu definieren:
- GWT als Client-Technologie
- Google Source als Plattform zur Veröffenntlichung von Roo-Add-ons
- Google App Engine für die Wolke (ok: VMWare-Unterstützung ist für Spring natürlich Pflicht)
- Google SpeedTracker für Profiling von Spring-Web-Anwendungen
Tag 1: 13:30 - 16:30: Spring Roo
Das wohl ewige Mantra in der IT lautet: Software-Entwicklung muss einfacher werden und sich ausschließlich auf das Business konzentrieren können.
Ein schöner Gedanke, und manche Frameworks/Konzepte sind ihn in ebensolcher Schönheit gestorben.
Spring Roo versucht anders zu sein. Aber der Reihe nach.
Spring Roo ist ein Rapid Application Development Tool (RAD) und liegt aktuell in der Version 1.1.0 vor. Es versucht den für eine Web-Anwendung zu schreibenden Code sowie die zugehörige Konfiguration auf ein Minimum zu reduzieren, ohne dabei an Funktionalität einzubüßen. Das kennt man im Grunde von Rails oder Grails.
Das Fundament von Roo besteht im wesentlichen aus
Wenn man aktuell Spring-basierte Web-Anwendungen bauen will, dann sind diverse Dinge zu programmieren, die man eigentlich geschenkt bekommen möchte, da sie sich eh immer wieder wiederholen, z. B.:
Durch die Verwendung von Roo-Kommandos bleibt einem auch der wesentliche Teil der Spring-Konfiguration erspart.
Zusätzliche Add-ons (die man auch selber schreiben kann) erleichtern massiv den Umgang mit Technologien/Bibliotheken, wie z. B.:
Sehr elegant: Änderungen im Code werden automatisch in die laufgende Anwendung übernommen. Darüber hinaus werden DB-Änderungen nach Aufruf eines Roo-Shell-Kommandos EBENFALLS übernommen. Dies betrifft sämtliche Schichten von der Domainklasse bis hin zur GUI!
Durch die FinCon-Brille betrachtet ist Spring Roo hochinteressant:
Aus meiner Sicht gibt es aber folgendes zu bedenken: Als Client-Technologie kommen out-of-the-box JSP (!) plus Roo-eigene Taglibs zum Einsatz. Einzige genannte Alternative: GWT. Dies entspricht NICHT unserem Tool Stack, welcher sich bei aktuellen (Neu-)Entwicklungen auf JSF konzentriert.
Diese "Kröte" könnte man aber schlucken:
Ein schöner Gedanke, und manche Frameworks/Konzepte sind ihn in ebensolcher Schönheit gestorben.
Spring Roo versucht anders zu sein. Aber der Reihe nach.
Spring Roo ist ein Rapid Application Development Tool (RAD) und liegt aktuell in der Version 1.1.0 vor. Es versucht den für eine Web-Anwendung zu schreibenden Code sowie die zugehörige Konfiguration auf ein Minimum zu reduzieren, ohne dabei an Funktionalität einzubüßen. Das kennt man im Grunde von Rails oder Grails.
Das Fundament von Roo besteht im wesentlichen aus
- dem Spring-Ökosystem (Framework, Security, Annotations, tc Server, etc.)
- Hibernate plus weiterer OR-Mapper und entsprechend unterstützter Datenbanken
- einer Roo Shell (wichtig!)
- AspectJ (noch wichtiger!)
- Roo Add-ons und Annotations
- Integration in Spring STS
Wenn man aktuell Spring-basierte Web-Anwendungen bauen will, dann sind diverse Dinge zu programmieren, die man eigentlich geschenkt bekommen möchte, da sie sich eh immer wieder wiederholen, z. B.:
- get-/set-Methoden für Properties
- DAOs mit Standard-CRUD- und Finder-Operationen
- GUIs mit Standard CRUD-Benutzerelementen (z. B. Listen mit Paginierung)
Durch die Verwendung von Roo-Kommandos bleibt einem auch der wesentliche Teil der Spring-Konfiguration erspart.
Zusätzliche Add-ons (die man auch selber schreiben kann) erleichtern massiv den Umgang mit Technologien/Bibliotheken, wie z. B.:
- REST
- JSON
- AJAX (Dojo ist Default)
- Spring Web Flow
- Spring Security
- i18n
Sehr elegant: Änderungen im Code werden automatisch in die laufgende Anwendung übernommen. Darüber hinaus werden DB-Änderungen nach Aufruf eines Roo-Shell-Kommandos EBENFALLS übernommen. Dies betrifft sämtliche Schichten von der Domainklasse bis hin zur GUI!
Durch die FinCon-Brille betrachtet ist Spring Roo hochinteressant:
- Die Tools scheinen ausgereift
- Der Tool Stack unter Roo ist uns (fast) komplett bekannt
- In einzelnen Bereichen reduziert sich der Programmieraufwand erheblich
- Sinnvolle gefüllte Testklassen werden automatisch mitgeneriert
- Der Build-Redeploy-Roundtrip sollte sich erheblich verkürzen
Aus meiner Sicht gibt es aber folgendes zu bedenken: Als Client-Technologie kommen out-of-the-box JSP (!) plus Roo-eigene Taglibs zum Einsatz. Einzige genannte Alternative: GWT. Dies entspricht NICHT unserem Tool Stack, welcher sich bei aktuellen (Neu-)Entwicklungen auf JSF konzentriert.
Diese "Kröte" könnte man aber schlucken:
- JSPs sind bei vielen unserer Entwickler bekannt.
- Im Fokus steht das Entwickeln von JEE-konformen Web-Anwendungen. Wenn Schnelligkeit in der Entwicklung eine deutlich höhere Priorität gegenüber den verwendeten Bibliotheken hat, dann ist besonders bei neuen Anwendungen die Wahl der (UI-)Waffe egal.
Tag 1: 09:30 - 12:30: Hadoop Fundamentals
Meine erste Session widme ich dem Blick über den Tellerrand. Die Session beleuchtet Systeme für den Umgang mit sehr großen Datenmengen. "Sehr groß" bedeutet: Terabyte.
Hadoop ist ein solches System. Es basiert auf dem Hadoop Distributed File System und einer Algorithmik namens MapReduce. Beides sind gesonderte Subprojekte dieses Apache-Projektes.
Große Datenmengen wollen schnell verarbeitet werden können. Hierzu implementiert Hadoop das zentrale Konzept der Lastverteilung auf unterschiedliche Rechner-Knoten in einem Rechnernetzwerk. Ergänzt wird dieses Konzept durch
MapReduce ist eine besondere Art, gesuchte Information zu finden und weiter zu verarbeiten. Hierfür kommen
Ein Driver ist das Hauptprogramm, welches den gesamten Suchprozess steuert und den zentralen Zugriff auf die Datenbasis ermöglicht. Ein Mapper verarbeitet Daten als Key-Value-Paare. Dabei bildet ein enzelnes Key-Value-Paar die Eingabe und eine Liste von Key-Value-Paaren das Ergebnis. Dieses geht schließlich an den Reducer (es können auch mehrere sein), welcher die Daten aufbereitet (z. B. aggregiert oder modifiziert) und als Ergebnis bereitstellt (z. B. als Endergebnis oder für weitere Mapper).
Man kann sich den Unterschied zwischen Mapper und Reducer vielleicht stark vereinfacht so vorstellen:
Für die Programmierung von Hadoop (API) stehen zwei Programmiersprachen zur Verfügung:
Trotzdem kann es schwierig sein, seine gesamte Abfragelogik über MapReduce-Skripte abzubilden. Alternativ stehen einem Datenbank-ähnliche Projekte zur Verfügung, welche das Abstraktions-Level auf die Verwendung von SQL- oder SQL-ähnliche Sprachen hebt. Zwei solcher Projekte sind Hive und Pig.
Hive kennt als Abstraktionslevel Tabellen, Zeilen und Spalten und speichert diese Informationen in einem Metastore. Hiver erlaubt einen auf SQL basierenden Datenzugriff (plus einer Reihe von Zusatzfunktionen) und ist somit aus Java heraus via JDBC ansprechbar. Der Unterbau von Hadoop bleibt verborgen, wenn man denn will.
Pig kennt keinen Metastore. Die Strukturinformationen werden zur Ausführungszeit der Skripte bekannt gegeben. Die Skriptsprache heisst Pig latin, deren Skripte über einen sogenannten Pig Server (Java-API) angesprochen werden können. Die Sprache erlaubt diverse Zugriffs- und Aggregtionsmöglichkeiten und kapselt Hadoop vollständig.
Durch die FinCon-Brille betrachtet ist das Hadoop Ökosystem eine sehr interessante Alternative zu "herkömmlichen" Datenhaltungssystemen, wenn
Eine Evaluierung wäre natürlich Voraussetzung. Hierbei müsste u. a. geprüft werden, inwieweit ein System wie Hive sich daten- und prozesstechnisch in eine eigene Anwendungsladschaft integrieren ließe. Hinzu kommt die Beantwortung der Frage nach der Bereitschaft unserer Kunden eine geeignete Infrastruktur bereit zu stellen.
Hadoop ist ein solches System. Es basiert auf dem Hadoop Distributed File System und einer Algorithmik namens MapReduce. Beides sind gesonderte Subprojekte dieses Apache-Projektes.
Große Datenmengen wollen schnell verarbeitet werden können. Hierzu implementiert Hadoop das zentrale Konzept der Lastverteilung auf unterschiedliche Rechner-Knoten in einem Rechnernetzwerk. Ergänzt wird dieses Konzept durch
- Zerlegung von großen Daten in Blöcke definierter Größe (z. B. 64 oder 128 MB)
- Verteilung dieser Daten auf die Knoten
- Verteilung der Datenverarbeitung auf unterschiedliche Knoten
- Vermeidung von Netzwerkzugriffen, wo immer möglich
MapReduce ist eine besondere Art, gesuchte Information zu finden und weiter zu verarbeiten. Hierfür kommen
- Driver
- Mapper und
- Reducer
Ein Driver ist das Hauptprogramm, welches den gesamten Suchprozess steuert und den zentralen Zugriff auf die Datenbasis ermöglicht. Ein Mapper verarbeitet Daten als Key-Value-Paare. Dabei bildet ein enzelnes Key-Value-Paar die Eingabe und eine Liste von Key-Value-Paaren das Ergebnis. Dieses geht schließlich an den Reducer (es können auch mehrere sein), welcher die Daten aufbereitet (z. B. aggregiert oder modifiziert) und als Ergebnis bereitstellt (z. B. als Endergebnis oder für weitere Mapper).
Man kann sich den Unterschied zwischen Mapper und Reducer vielleicht stark vereinfacht so vorstellen:
- Mapper sind so etwas wie Filter
- Reducer sind Transformatoren
Für die Programmierung von Hadoop (API) stehen zwei Programmiersprachen zur Verfügung:
- Java
- Hadoop Streaming
Trotzdem kann es schwierig sein, seine gesamte Abfragelogik über MapReduce-Skripte abzubilden. Alternativ stehen einem Datenbank-ähnliche Projekte zur Verfügung, welche das Abstraktions-Level auf die Verwendung von SQL- oder SQL-ähnliche Sprachen hebt. Zwei solcher Projekte sind Hive und Pig.
Hive kennt als Abstraktionslevel Tabellen, Zeilen und Spalten und speichert diese Informationen in einem Metastore. Hiver erlaubt einen auf SQL basierenden Datenzugriff (plus einer Reihe von Zusatzfunktionen) und ist somit aus Java heraus via JDBC ansprechbar. Der Unterbau von Hadoop bleibt verborgen, wenn man denn will.
Pig kennt keinen Metastore. Die Strukturinformationen werden zur Ausführungszeit der Skripte bekannt gegeben. Die Skriptsprache heisst Pig latin, deren Skripte über einen sogenannten Pig Server (Java-API) angesprochen werden können. Die Sprache erlaubt diverse Zugriffs- und Aggregtionsmöglichkeiten und kapselt Hadoop vollständig.
Durch die FinCon-Brille betrachtet ist das Hadoop Ökosystem eine sehr interessante Alternative zu "herkömmlichen" Datenhaltungssystemen, wenn
- man mit wirklich großen Datenmengen hantieren muss,
- man mit einer hohen Anzahl parallel zu verarbeitender User-Anfragen umgehen können muss und schnelle Antwortzeiten garantieren möchte,
- es sich ausschließlich um lesenden Zugriff handelt.
Eine Evaluierung wäre natürlich Voraussetzung. Hierbei müsste u. a. geprüft werden, inwieweit ein System wie Hive sich daten- und prozesstechnisch in eine eigene Anwendungsladschaft integrieren ließe. Hinzu kommt die Beantwortung der Frage nach der Bereitschaft unserer Kunden eine geeignete Infrastruktur bereit zu stellen.
Sonntag, 14. November 2010
Tag 0: Registrierung
Heute ist für eine Stunde der Registration Desk im Metropolis Kino (dort findet in den nächsten Tagen auch die Veranstaltung statt) geöffnet.
Unser Hotel liegt im Zentrum, das Kino eher etwas außerhalb im Norden Antwerpens. Es ist also Bahnfahren angesagt. Mit der Tram. Kein Problem mit der richtigen Fahrkarte: Für 8€ gibt es eine Lijnkaart. Für sämtliche Fahrten innerhalb einer Zone und einer Stunde werden einmalig 80 Cent von der Karte abgebucht. Vereinfacht gesagt reicht eine Karte dann für fünf Hin- und Rückfahrten zwischen Hotel und Kino. Das ist ziemlich günstig.
Unsere Tramstation heisst Diamant. Hier fahren mehrere Linien ab, u. a. "unsere" Linie 6. Nach kurzer Wartezeit fährt vorher aber eine noch eine andere Linie in den Bahnhof ein: Ein hochmodern wirkender Zug mit drei verbundenen Waggons, aerodynamische Linie, sportliche Farbgebung, tiefergelegt, klimatisiert schwebt leise in den Bahnhof ein und genauso leise weder heraus. Was für ein Komfort für 80 Cent, denke ich mir.
Und dann kommt die Linie 6...
Die dürftige Leuchtanzeige am Zug erfordert meine ganze Konzentration und offenbart erst sehr spät, dass das, was ich dann zu sehen bekomme, tatsächlich das Gefährt sein wird, welchem ich die kommende Viertelstunde mein Leben anvertraue: Ein altersschwacher, klappriger, rostiger Waggon mit defekten Fenstern und Türen erreicht in alle Richtungen schwankend den Banhsteig.
Diese Tram schwebt nicht, sie kämpft sich in den Bahnhof und so über die gesamte Strecke.
Nur, um ein Gefühl dafür zu entwickeln: Ich möchte diesen Zug in einer Reihe mit der Bahn auf Mallorca zwischen Soller und Port de Soller (Siemens & Halske 1922) sowie der berühmten historischen Linie 28 in Lissabon nennen, ohne zu wissen, ob die Antwerpener Variante deren unmittelbarer Nachfolger oder gar Vorgänger ist.
Das Ding gehört optisch ins Museum, bringt mich aber dennoch sicher zum Registration Desk (und wieder zurück).
Dort angekommen bleibt mir der befürchtete Andrang erspart. Das Konferenz-Material ist schnell ausgehändigt. Eintrittskarte. Rucksack mit Unterlagen, Werbung und einem Devoxx-Shirt ... in Größe L. Will's jemand haben? ;-)
Der Zeitplan steht; jetzt kann's losgehen.
Unser Hotel liegt im Zentrum, das Kino eher etwas außerhalb im Norden Antwerpens. Es ist also Bahnfahren angesagt. Mit der Tram. Kein Problem mit der richtigen Fahrkarte: Für 8€ gibt es eine Lijnkaart. Für sämtliche Fahrten innerhalb einer Zone und einer Stunde werden einmalig 80 Cent von der Karte abgebucht. Vereinfacht gesagt reicht eine Karte dann für fünf Hin- und Rückfahrten zwischen Hotel und Kino. Das ist ziemlich günstig.
Unsere Tramstation heisst Diamant. Hier fahren mehrere Linien ab, u. a. "unsere" Linie 6. Nach kurzer Wartezeit fährt vorher aber eine noch eine andere Linie in den Bahnhof ein: Ein hochmodern wirkender Zug mit drei verbundenen Waggons, aerodynamische Linie, sportliche Farbgebung, tiefergelegt, klimatisiert schwebt leise in den Bahnhof ein und genauso leise weder heraus. Was für ein Komfort für 80 Cent, denke ich mir.
Und dann kommt die Linie 6...
Die dürftige Leuchtanzeige am Zug erfordert meine ganze Konzentration und offenbart erst sehr spät, dass das, was ich dann zu sehen bekomme, tatsächlich das Gefährt sein wird, welchem ich die kommende Viertelstunde mein Leben anvertraue: Ein altersschwacher, klappriger, rostiger Waggon mit defekten Fenstern und Türen erreicht in alle Richtungen schwankend den Banhsteig.
Diese Tram schwebt nicht, sie kämpft sich in den Bahnhof und so über die gesamte Strecke.
Nur, um ein Gefühl dafür zu entwickeln: Ich möchte diesen Zug in einer Reihe mit der Bahn auf Mallorca zwischen Soller und Port de Soller (Siemens & Halske 1922) sowie der berühmten historischen Linie 28 in Lissabon nennen, ohne zu wissen, ob die Antwerpener Variante deren unmittelbarer Nachfolger oder gar Vorgänger ist.
Das Ding gehört optisch ins Museum, bringt mich aber dennoch sicher zum Registration Desk (und wieder zurück).
Dort angekommen bleibt mir der befürchtete Andrang erspart. Das Konferenz-Material ist schnell ausgehändigt. Eintrittskarte. Rucksack mit Unterlagen, Werbung und einem Devoxx-Shirt ... in Größe L. Will's jemand haben? ;-)
Der Zeitplan steht; jetzt kann's losgehen.
Entspannte Anreise
Ich bin heute etwas entspanter als Jörn in den Tag gestartet.
Morgen geht der Spaß los...
- "Ausgeschlafen" bis 7:30h (für einen Familienvater)
- Online Checkin
- Frühstück mit der Familie
- Koffer packen
- Park&Ride zum Flughafen wg. Schienenersatzverkehr
- Kofferabgabe in Terminal 2 (Brussels Airlines)
- Mit meiner Familie das Familienfest "Phantastische Welten" am Flughafen anschauen
- 14:20h Abschied
- Ankunft in Brüssel ~16:30h - mit Java am Flughafen
- Weiter mit der Bahn ca. 1h15 (Umsteigen in Brüssel-Nord)
- Ankunft Anveers-Centraal
Die Reiserouten von Jörn und Christian
Interessant finde ich, daß Jörn und ich jeweils eine andere Route gewählt haben...
Morgen geht der Spaß los...
Curryworsten
Auch wenn der Name es nicht vermuten lässt: Frietkots gehören zu den Lieblingsspeisen in Belgien. Anders als bei uns, wo sich die Speise Pommes Frites nennt und eher als Beilage taugt, steht sie beim Belgier im Mittelpunkt des Essgenusses.
Hier mutieren andere Nahrungsmittel zur Beilage, gar zur wenig beachteten Nebensache ... und schmecken leider auch entsprechend.
Dies gilt besonders für die Curryworsten, die noch schlimmer schmecken, als der hiesige Bezeichner der Currywurst vermuten lässt.
Als Andreas mich gewarnt hat, "Ess dort keine Currywurst", dachte ich, mit "dort" meint er das Einzugsgebiet des Veranstaltungszentrums. Jetzt weiss ich: Er meint ganz Antwerpen, wenn nicht sogar ganz Belgien! Diese sogenannte Wurst hat keinen Biss, schmeckt fade und mehlig, riecht befremdlich und sieht eher aus, wie das metabolische Ergebnis nach Verzehr einer richtigen Currywurst. Zum perfekten Gesamtbild fehlen eigentlich nur noch Knorpel...
Deutlich leckerer sehen die Schaufensterauslagen der zahlreichen Schokolaterien aus. Probiert habe ich noch nichts; aber es sind ja noch ein paar Tage Zeit...
Hier mutieren andere Nahrungsmittel zur Beilage, gar zur wenig beachteten Nebensache ... und schmecken leider auch entsprechend.
Dies gilt besonders für die Curryworsten, die noch schlimmer schmecken, als der hiesige Bezeichner der Currywurst vermuten lässt.
Als Andreas mich gewarnt hat, "Ess dort keine Currywurst", dachte ich, mit "dort" meint er das Einzugsgebiet des Veranstaltungszentrums. Jetzt weiss ich: Er meint ganz Antwerpen, wenn nicht sogar ganz Belgien! Diese sogenannte Wurst hat keinen Biss, schmeckt fade und mehlig, riecht befremdlich und sieht eher aus, wie das metabolische Ergebnis nach Verzehr einer richtigen Currywurst. Zum perfekten Gesamtbild fehlen eigentlich nur noch Knorpel...
Deutlich leckerer sehen die Schaufensterauslagen der zahlreichen Schokolaterien aus. Probiert habe ich noch nichts; aber es sind ja noch ein paar Tage Zeit...
Ankunft in Antwerpen
Nun scheint klar, wer das schlechte Wetter aus Hamburg über Amsterdam nach Antwerpen gebracht haben könnte: Ich! Sei's drum. Der Zug ist pünktlich. Das Hotel macht einen guten Eindruck. Internet access free of charge. Wenn jetzt das Frühstück auch noch gut ist...
SEHR gut ist die Info von der Dame an der Rezeption, dass heute in Antwerpen ein verkaufsoffener Sonntag ist! Das eröffnet für den Rest des Tages ganz neue Perspektiven. ;-)
Damit ist der Tagesablauf vorbestimmt: Mittagessen, Bummeln gehen und um 18:00 Uhr auf zum Registration Desk der Devoxx. Damit sollten man die möglichen Wartezeiten am Montag umgehen können. Immerhin haben sich 3000 Teilnehmer angemeldet...
SEHR gut ist die Info von der Dame an der Rezeption, dass heute in Antwerpen ein verkaufsoffener Sonntag ist! Das eröffnet für den Rest des Tages ganz neue Perspektiven. ;-)
Damit ist der Tagesablauf vorbestimmt: Mittagessen, Bummeln gehen und um 18:00 Uhr auf zum Registration Desk der Devoxx. Damit sollten man die möglichen Wartezeiten am Montag umgehen können. Immerhin haben sich 3000 Teilnehmer angemeldet...
Amsterdam: Mal wieder Regen
Und dass die Frisur noch sitzt, ist ein kleines Wunder. KLM bringt mich überpunklich zu meinem Zwischenstopp in Amsterdam.
Aber irgend jemand hat das Hamburger Wetter im Gepäck mitgebracht und die Fluglotsen von Schiphol lassen uns auf besondere Weise daran teilhaben: Sie spendieren uns eine Aussenposition und krönen dies zum Verlassen des Flugzeuges mit einer nicht überdachten Gangway. Das mit der Gangway kann aus meiner Sicht zwei Gründe haben:
Und siehe da: Der selbsternannte "König des Frikadellenbrötchens" hält eine Auswahl von Frühstücks-Menüs für mich parat. Einen Wrap, Pan Cakes und einen Toastie. Dazu Kaffee. Auf den Bildern hinterm Tresen sieht alles ziemlich lecker aus. Wenn man dann aber das sieht, was vor einem auf dem Tablett als sogenanntes Toastie landet, dann tagträumt man sich in die Rolle eines Michael Douglas, der in "Falling down", diesen "winzigen" Unterschied zwischen Werbung und Realität auf seine Weise anprangerte (für alle, die den Film nicht kennen: Er hat einen schlechten Tag, einen sehr schlechten, kommt mit seiner Frühstücksbestellung im Fastfood-Imbiss seiner Wahl zwei Minuten zu spät und beschwert sich danach über die Qualität des ihm servierten Burgers; ach ja: Er trägt eine Sporttasche bei sich, voller Waffen...)
Bis zur Weiterfahrt sind noch über zwei Stunden Zeit. Dann geht's mit Thalys nach Antwerpen.
Aber irgend jemand hat das Hamburger Wetter im Gepäck mitgebracht und die Fluglotsen von Schiphol lassen uns auf besondere Weise daran teilhaben: Sie spendieren uns eine Aussenposition und krönen dies zum Verlassen des Flugzeuges mit einer nicht überdachten Gangway. Das mit der Gangway kann aus meiner Sicht zwei Gründe haben:
- Diese Wetterbedingungen scheinen hier derart ungewöhnlich zu sein, dass der Flughafen keine besitzt.
- Der Flieger kommt aus Deutschland: Rache für 1974!
Und siehe da: Der selbsternannte "König des Frikadellenbrötchens" hält eine Auswahl von Frühstücks-Menüs für mich parat. Einen Wrap, Pan Cakes und einen Toastie. Dazu Kaffee. Auf den Bildern hinterm Tresen sieht alles ziemlich lecker aus. Wenn man dann aber das sieht, was vor einem auf dem Tablett als sogenanntes Toastie landet, dann tagträumt man sich in die Rolle eines Michael Douglas, der in "Falling down", diesen "winzigen" Unterschied zwischen Werbung und Realität auf seine Weise anprangerte (für alle, die den Film nicht kennen: Er hat einen schlechten Tag, einen sehr schlechten, kommt mit seiner Frühstücksbestellung im Fastfood-Imbiss seiner Wahl zwei Minuten zu spät und beschwert sich danach über die Qualität des ihm servierten Burgers; ach ja: Er trägt eine Sporttasche bei sich, voller Waffen...)
Bis zur Weiterfahrt sind noch über zwei Stunden Zeit. Dann geht's mit Thalys nach Antwerpen.
Der frühe Vogel...
...ist total fertig vom frühen Aufstehen. 3:45 Uhr! Am Sonntag!!! Aber wenn man neben der Konferenz noch was von Antwerpen sehen möchte, dann muss man rechtzeitig aus den Federn. Der Zeitplan am Montag erzwingt eh eine Anreise am Vortag.
Ohne Frühstück geht's aus dem Haus (zu so früher Stunde ist an Essen sowieso nicht zu denken...).
Die Fahrtzeiten des öffentlichen Nahverkehrs in Hamburg zum Flughafen erzwingen fast den Ruf nach einem Taxi. Ich glaub', dem Taxifahrer geht's genau wie mir. Er bleibt stumm. Genau wie ich. Gut so. Das einzige, was einem um diese Uhrzeit aufmuntert, ist das Regenwetter in Hamburg, dem ich in Kürze entfliehe.
Ohne Frühstück geht's aus dem Haus (zu so früher Stunde ist an Essen sowieso nicht zu denken...).
Die Fahrtzeiten des öffentlichen Nahverkehrs in Hamburg zum Flughafen erzwingen fast den Ruf nach einem Taxi. Ich glaub', dem Taxifahrer geht's genau wie mir. Er bleibt stumm. Genau wie ich. Gut so. Das einzige, was einem um diese Uhrzeit aufmuntert, ist das Regenwetter in Hamburg, dem ich in Kürze entfliehe.
Samstag, 13. November 2010
Zeitplan (Christian)
Da ich kein Smart-Phone habe, konnte ich immerhin mit dem Chrome-Browser (HTML5-Client) meinen vorläufigen Schedule erstellen...
Freitag, 12. November 2010
Zeitplan (Jörn)
Der erste Zeitplan steht. Die Auswahl fiel manchmal nicht leicht und einige Entscheidungen stehen wegen Terminüberschneidungen noch aus. Meinen aktuellen Stand findet Ihr hier.
Mittwoch, 10. November 2010
Willkommen
Willkommen zum Devoxx2010-Blog der C1 FinCon GmbH! Hier wird während der Devoxx 2010 in Antwerpen regelmäßig von Christian und Jörn über die Inhalte der Vorträge berichtet.
Stay tuned ;-)
Stay tuned ;-)
Abonnieren
Posts (Atom)