Wir unterstützen...

Elterninitiative Kinderkrebsklinik e.V

Kinderkrebsklinik e.V

Sponsoren

Wir danken unseren Sponsoren:

Permanente Sponsoren

Uni Düsseldorf
(Raum und Beamer)


(Preise)


(Preise)


(Preise)


(Preise)

Mitgliedschaften



java.net Member

Events

Nachlese: AngularJS | Print |
Written by Philip Höfges   
Friday, 19 December 2014 11:05

>> Slides

>> Video

Bald ist Weihnachten und das darf auch bei der Rheinjug nicht fehlen. Bei diesem letzten Vortrag des Jahres 2014 werden neben den üblichen Subs auch weihnachtliche Plätzchen gereicht. Schon im Vorfeld wird klar, dass die weihnachtliche Stimmung auch auf den Vortrag übergehen wird. Wieder finden sich etwa 90 Zuschauer im Hörsaal ein. Dieses mal wird ein Vortrag von zwei Rednern gehalten. Philipp Tarasiewicz und Robin Böhm sind Softwareentwickler und Coaches, die mit ihrer eigenen Firma sich vor allem mit dem heutigen Thema beschäftigen: AngularJS.

Zunächst erzählen die beiden Redner ein wenig über sich und werben nebenbei für ein Buch zum Thema, welches sie selbst mit verfasst haben. Der erste Teil des Vortrags wird von Philipp Tarasiewicz gehalten. Er stellt mit einer Einleitung AngularJS dar. Natürlich beginnt er mit der Nennung der Haupteigenschaften des Frameworks für JavaScript: Mit dem Two-Way Data Binding schafft es AngularJS, die Web-Applikation ständig zu aktualisieren, sofern es nötig ist, also tatsächlich nur dann, wenn wichtige Änderungen durchgeführt worden sind. Um dies zu veranschaulichen, zeigt Philipp ein kleines Beispiel. Daran kann sehr schön abgelesen werden, dass sich Two-Way Binding lohnt. Damit ist AngularJS sowohl MVVM (kurz für Modelview View Model), als auch MVW (kurz für Modelview Whatever). Es kann also in vielerlei Hinsicht dargestellt werden und ist somit sehr flexibel. Weiterhin stellt der Redner fest, dass die Lesbarkeit sehr hoch ist. Dies will er in einer Live-Coding-Session am Ende seines Abschnitts zeigen. Ein weitere wichtiger Punkt sind die Direktiven. Man hat damit die Möglichkeit, DOM-Manipulation tatsächlich nur in diesen Direktiven auszuführen und läuft nicht Gefahr, dass solche Manipulationen von anderer Stelle das Programm beeinflussen. Zudem kann man mit AngularJS mehr aus seinem HTML Tags und Attributen machen, wie Philipp am Ende zeigen will. Zuletzt ist noch Dependency Injection ein wichtiges Thema. Es ist schwierig, die Abhängigkeiten gut darzustellen, obwohl sie wichtig für das Konzept von AngularJS sind. Alles muss in einem Modul deklariert werden, was natürlich Abhängigkeiten hervorruft.

Am Ende zeigt Philip noch ein ausführliches Beispiel in einer Live-Coding-Session. Er zeigt, wie man einen ColorPicker in sehr kurzer Zeit, sehr effizient entwickeln kann. Zunächst wird eine direkte Verbindung von einem Textfeld zu einer Überschrift hergestellt. Und das Ganze live. Es muss nichts kompiliert werden, der Text erscheint sofort in der Überschrift. Schöne Sache. Mit diesem einfachen Trick können auch Schieberegler direkten Einfluss auf die App nehmen. Was am Ende dabei heraus kommt ist ein Feld, welches live die Farbe ändern kann. Und das mit diesem einen, einfachen Trick. Schöne Sache. Zuletzt zeigt Philipp noch, wie man aus diesem Code eine Direktive erzeugt und damit mehrere ColorPicker gleichzeitig anzeigen lassen kann, ohne den Code duplizieren zu müssen. Auch hier: Schöne Sache.

Danach darf auch Robin Böhm endlich zu Wort kommen. In seinem Abschnitt des Vortrags geht es um TDD (Test Driven Development). TDD stellt eines der wesentlichen Features von AngularJS dar. Hier kann man sich nach Herzenslust austoben. Es gibt ein Framework für E2E (End-To-End) Testing, Unit Testing mit Hilfe von Jasmine und Test Runner wie Karma. Nun behauptet Robin, dass jede Komponente unit-testbar sei und beweist dies, in dem er auf seinen Folien einige Beispiele zeigt. Da inzwischen das manuelle Kontrollieren des Codes mehr als veraltet ist, wird TDD immer wichtiger in der Softwareentwicklung. Außerdem können Tests als Gedächtnisstütze eingesetzt werden. Wenn man montags morgens ins Büro kommt, kann man anhand der Tests sehr schnell nachvollziehen, was man eigentlich in der letzten Woche so alles getrieben hat. Als nächstes erklärt Robin das Tool Jasmine. Die Methoden und Funktionen, die Jasmine bietet, liefern eine hervorragende Basis für Tests. Es werden Ausgaben mit erwarteten Ergebnissen verglichen. Vergleiche sind hierbei unter Anderem Gleichheit und Identität. Somit kann ein Testvorgang mit Jasmine leicht nachvollzogen werden. Im nächsten Schritt zeigt der Redner, wie man HTML-Templates leicht mit Direktiven ausstatten kann und damit auch Fehler in Browsern finden kann, die nicht von einem selbst stammen.

Abschließend zeigt Robin ebenfalls Live-Coding. Er erzeugt einen Würfel, der in alle drei Dimensionen drehbar ist. Schöne Sache. Jedes Element des Würfels, also Kanten und Flächen, sind nichts weiter als div-Elemente. Da jedes Element auch für sich selbst steht, kann man sie einzeln testen. Vom Grundaufbau her sieht der Code dem vom vorherigen Beispiel mit dem ColorPicker sehr ähnlich. Was natürlich mehr interessiert in diesem Kapitel sind die Tests. Diese sind schlicht einfache Vergleich nach Gleichheit etc. bei Jasmine. Damit zeigt Robin, dass man testgetriebene Entwicklung mit AngularJS sehr gut umsetzen kann.

Zum Schluss verlosen die beiden noch einige Exemplare ihres Buches, indem sie dem Publikum fragen zu ihrem Vortrag stellen. Eine gute Methode, die Aufmerksamkeit zu überprüfen. Bleibt am Ende nur zu sagen: Frohes Fest und einen guten Rutsch!

 
Nachlese: Spannende Erweiterungen der Java EE Plattform durch Innovationstechnologien von Oracle | Print |
Written by Philip Höfges   
Monday, 01 December 2014 10:51

>> Slides Peter Doschkinow (1. Vortrag)

>> Slides Michael Bräuer (2. Vortrag)

Auch zu diesem Vortrag fanden sich wieder über 75 Personen im Hörsaal ein. Wie üblich wurde das Gewinnspiel der Rheinjug durchgeführt. Dabei kam es zu einem Novum. Alle drei Gewinner wurden auf Anhieb gezogen. Das gab es noch nie! Ein guter Start für diesmal zwei Vorträge.

Der erste Vortrag wird von Peter Doschkinow gehalten. Er ist Senior Java Architekt bei Oracle und erzählt den Zuhörern interessante Dinge zur serverseitigem JavaScript in der Java Virtual Maschine. Peter stellt zunächst fest, dass es inzwischen sehr viele verschiedene Technologien für die JVM gibt. Diese sind sogar für die Server-Seite interessant. Früher hatte der Client im Vergleich zum Server sehr viel weniger Arbeit. Heutzutage stehen dem Benutzer aber auch dort einige Optionen zur Verfügung. Dies erzeugt aber natürlich auch Arbeit auf der Server-Seite. Dabei gewinnt JavaScript immer mehr an Bedeutung. Der Redner zeigt anhand einer Timeline anschaulich, wie sich JavaScript in der letzten Zeit entwickelt hat. Java und JavaScript sind inzwischen sehr beliebte Programmiersprachen. Auf der neuen Anwendungsplattform Java EE 7 wird der Fokus darauf gelegt, sowie auf HTML5. Für diese Plattform gibt es auch eine Anbindung an ein anderes Tool: Node.js.

Node.js arbeitet eher datenlastiger. Dabei wird allerdings der Umgang mit Nebenläufigkeit nicht mehr trivial. Es gibt tatsächlich keinen Standard für die Schnittstelle für Datenbanken. Als Beispiel zu dieser Behauptung, führt Peter Doschkinow einen Vergleich zwischen synchroner und asynchroner I/O an. Hier kann man sehr schön sehen, wie die Nebenläufigkeit die Laufzeit beeinflusst. Dadurch wird auch deutlich, dass Node.js nicht optimal ist. Die Lösung: Node.js in die Java SE/EE einbauen. Dazu wurde Projekt Nashorn eröffnet. Peter erklärt anschaulich, wie es sich aus Projekt Rhino entwickelt hat. Und es geht noch weiter. Auf diesem Projekt Nashorn aufbauend, wurde Avatar.js entwickelt, eine Plattform für serverseitige JavaScript Applikationen. Dies ist sogar zu 95 Prozent Node.js kompatibel. Ein sehr guter Wert. In einem Beispiel zeigt Doschkinow den Unterschied zwischen Java und JavaScript: Eine Foto-Datenbank mit Node.js als Framework.

Man kann sehr gut sehen, dass die Abhängigkeiten im Vorhinein bekannt sind. Es ist insgesamt sehr wenig Code geschrieben worden und doch ist das Beispiel sehr umfangreich. Es gibt auch andere Programme wie Nodyn, die aber nur am Rand erwähnt werden. Danach geht Peter Doschkinow wieder in die Vollen und zeigt ein neues Projekt: ProjectAvatar. ProjectAvatar ist eine End-to-end-Plattform und bietet neben Multi-threading auch Out-of-the-box Support an. Dadurch wird paralleles Rechnen sehr viel einfacher. In einer letzten Demonstration zeigt der Redner, wie eine einfache Applikation, nämlich das parallele Zeichnen von Figuren, mit JavaScript und Nods.js einfach und schnell zu realisieren ist. Man kann sehr schön sehen, wie es funktioniert. Tolles Beispiel. Zusammenfassend stellt Peter Doschkinow noch den wesentlichen Punkt heraus: Avatar schließt die Brücke zwischen Java und Node.js.

In der darauf folgenden kurzen Pause wird bereits über die Inhalt diskutiert, eher Michael Bräuer ans Mikrofon tritt und mit seinem Vortrag startet. Mit dem Thema In-Memory Grid Computing baut er auf dem vorherigen Vortrag zunächst auf. Dabei macht er auf das Problem aufmerksam, dass bei der Zeichnen-Applikation nicht jeder Client mit einem anderen gemeinsam zeichnen kann, sobald er auf einem anderen Host läuft. Dies ist ein Ärgernis. Die Lösung liegt dafür im Cache. Über In-Memory Data Grid wird dies realisiert. Die Vorteile liegen auf der Hand: Geringe Antwortzeiten, hoher Durchsatz, vorhersehbare Skalierbarkeit, Verfügbarkeit und Zuverlässigkeit. Damit kann die Kapazität über einzelne System hinaus gehalten werden. Dies stellt Michael Bräuer ebenfalls anschaulich dar. Er zeigt, dass die Daten auf die verschiedenen Systeme verteilt werden. Weiterhin gibt es Backups, so dass die Daten in den Systemen immer vorhanden sind, auch wenn eines ausfallen sollte. Dies auch unbedingt erforderlich, um Datenverlust zu vermeiden. Das Netzwerk sei der Feind, behautet Michael mit einem Grinsen im Gesicht. Durch unter anderem Serialisierung wird die Bearbeitung parallelisiert. Sobald sich etwas verändert hat, wird diese Änderung in den Cache geladen. Damit werden alle Clients sofort über diese Änderung informiert und alles kann parallel laufen. Die Daten liegen dabei im Cluster. Abschließend stellt der Redner noch die Frage, was es zu beachten gilt: Aus Betriebssicht muss darauf geachtet werden, dass die Netzwerkkonfiguration und Netzwerkplanung, sowie eine gute Einschätzung der Kapazitäten durchgeführt wird. Aus Entwicklersicht sollten Standardserialisierungsmechanismen vermieden, sowie paralleles Rechnen eingesetzt werden. Der Code muss zu den Daten gebracht werden, nicht die Daten zum Code.

 
Nachlese: Neo4j und die wunderbare Welt der Graphen | Print |
Written by Philip Höfges   
Monday, 22 September 2014 07:34

>> Video

Auch bei diesem Rheinjug-Tag haben sich wieder zahlreiche Menschen in der Heinrich-Heine-Universität versammelt, um einem Vortrag zu lauschen. Das Thema diesmal ist die Welt der Graphen. Gehalten wird der Vortrag von Michael Hunger, einem renommierten Mitarbeiter bei Neo Technology.

Michael Hunger gibt zunächst eine Einleitung zum Thema Graphen. Was sind Graphen eigentlich? Die Antwort ist, dass alles ein Graph ist. In der heutigen Gesellschaft ist jeder Mensch mit anderen vernetzt. Soziale Netzwerke sind nicht mehr wegzudenken. Aber wie sollte man diese vielen, vielen Daten verarbeiten? Die ersten Graphen stammen aus Schweden. Man hat sich überlegt, wie man die Daten geschickt verarbeiten kann. Die Graphen sind geboren. Ein weiteres Beispiel dafür ist die Logistik. Wie kann man verschieden Menschen verschiedene Informationen zukommen lassen? Wo ist die Ware? Wer transportiert sie? All dies lässt sich mit Graphen schnell und effizient lösen. Wie kommen Menschen von A nach B? Heutzutage mit Navigationssystemen. Auch diese sind nichts anderes als Graphen. Es wäre viel zu aufwendig, dies mit Datenbanken lösen zu wollen. Graphen schaffen hier sehr gute Abhilfe.

Nach Erklärung weiterer Beispiele, erklärt Michael Hunger wie Vorüberlegungen schon in Form von Graphen durchgeführt werden. Man stellt sich bereits Fakten in Form von Knoten vor und überlegt sich, wie jede Information mit einer anderen verbunden ist. Dadurch entsteht eine übersichtliche Darstellung von Informationen. Diese Darstellung ist formfrei und kann von jedem Benutzer selbst gewählt werden. Jeder Knoten kann alles sein, jede Art von Zustand.

Wieder zurück zu den sozialen Netzwerken. Eine Person gilt als sportbegeistert. Jedoch speichert das Netzwerk Informationen, z.B. auf welchen Seiten sich bewegt wird. Man glaubt also einer „sportbegeisterten“ Person dies garnicht, wenn mitgeschnitten wird, dass diese Person sich nicht auf Sportseiten herumtreibt. Genau deswegen sind die Beziehungen gewichtet. Man kann zum Beispiel den Zustand von Gefühlen gewichten. Liebe ist zum Beispiel nicht notwendigerweise bidirektional. Das heißt, das die Liebe auf die eine oder andere Seite gewichtet ist. Außerdem kann jeder Knoten mit unendlich vielen anderen Knoten verbunden sein. Jeder Mensch kann Gefühle für beliebig viele andere Menschen haben. Auch die Selbstliebe ist in einem Graphen gestattet, da jeder Knoten mit sich selbst verbunden sein kann.

Anschließend leitet Michael Hunger zum Kern des Vortrags über. Es gibt verschiedene Arten von Informationsdarstellung. Eine dieser Arten sind die Graphen, insbesondere die Darstellung mit Hilfe von Neo4j. Was macht Graphen gegenüber relationalen Modellen aus? Während relationale Modell eine Join-Tabelle aufbauen, die zwischen Knoten vermittelt, liefern Graphen eine eigene Datenstruktur dazu mit. Dadurch fällt die aufwendige Berechnung von Schlüsseln schlicht weg. Außerdem ist die Laufzeit bei Graphen nicht quadratisch, sondern linear. Um dies zu verdeutlichen, zeigt Michael Hunger ein einfaches Beispiel: Über wie viele Ecken kennt man andere Menschen? Graphen lieferen eine sehr schnelle Antwort, die sich auch bei wesentlich mehr Datensätzen nicht ändert, während das relationale Modell immer bei mehr Daten langsamer wird. Aber warum ist das so? Weil Graphen sich auf die nähere Umgebung des Zielknotens beschränkt und nicht die gesamte Datenbank durchsuchen - das spart Zeit.

Wie sieht das Ganze in Neo4j aus? Neo4j ist skalierbar, schemafrei, deklarativ und perfekt bei für stark vernetzte Daten. Die entsprechende Anfragesprache ist leicht zu lesen und beispielsweise SQL sehr ähnlich. Anhand einer sehr guten Demonstration zeigt Michael Hunger, wie das ganze durchgeführt wird. Der wesentliche Unterschied zu relationalen Modell ist die schnelle Abfrage von benachbarten Knoten. Durch simples Anklicken des Knotens kann dem Umkreis eingesehen werden.

Am Ende der Demonstration fasst Michael Hunger die geschilderten Resultate nochmals sehr übersichtlich zusammen: Alles kann ein als Knoten dargestellt werden, jeder Knoten kann mit unendlich vielen anderen Knoten verbunden sein und jedes Programm kann als Baum und somit als Graph dargestellt werden. Damit beendet Michael Hunger und dem Applaus der Zuhörer seinen Vortrag.

 
Nachlese: Der perfekte Match: Mit Docker Java Microservices produzieren | Print |
Written by Philip Höfges   
Friday, 31 October 2014 13:12

>> Folien auf Speakerdeck

>> Video

Mit einer Zuschauerzahl von über 100 Personen konnten wir an diesem Abend Peter Roßbach begrüßen. Das zentrale Thema dieses Abends ist Docker. Wie man an Peter Roßbachs T-Shirt sehen kann, geht es scheinbar um Wale, die Container transportieren. Dem ist auch fast so. Der Redner stellt vor, dass Administration und Entwicklung gleichzeitig beherrscht werden sollten. Wer beides kann, habe einen klaren Startvorteil. Allerdings stimmen Anspruch und die Realität oft nicht überein. Die meisten sind nur eines von Beidem. Das erzeugt Organisationsprobleme: Es muss immer eine Absprache zwischen beiden Parteien geben. Dieses Problem lässt sich auch auf den Arbeitsalltag übertragen: In der Regel gewinnt ja die Arbeit, die Freizeit kommt meistens zu kurz. Es ist der Traum eines jeden Arbeiters, die perfekte Balance zwischen Beidem zu finden. Hier kommt Docker ins Spiel, welches eine Möglichkeit ist, sich das Leben zu vereinfachen.

„Build, Ship and Run, any app, anywhere!“. So lautet das Mantra von Docker. Und das nicht ohne Grund. Jeder ist in der Lage mit einfachen Handgriffen bei Docker mitzumachen und es zu nutzen. Docker funktioniert ähnlich wie z.B. Github: Man kann Daten teilen. Der wesentliche Unterschied besteht aber darin, dass man auch lauffähige Programme teilen kann. Wie der erste Teil des Mantras sagt, kann sich etwas zusammenbauen, es teilen und sofort starten.

Doch wie funktioniert Docker eigentlich? Peter Roßbach zeigt, dass ein visualisierter Kernel benutzt wird. Solange also dieser Kernel unterstützt wird, solange läuft Docker auf auf jeder Linux-Distribution. Tolle Sache! Docker selbst ist ein Modul, welches über ein Bridge eine Netzwerkverbindung aufbaut. Sogar als VM unter dem Namen Boot2Docker ist es verfügbar. Es kann leicht mit ein bisschen Shell-Magie installiert und eingerichtet werden. Sobald die Vorbereitungen abgeschlossen sind, kann Docker gestartet werden. In einer Übersicht als Graph, stellt Peter Roßbach die wichtigsten Befehle für den Umgang mit Docker dar. Er sagt, diese seien wichtig und müssten zwingend gelernt werden. Weiterhin formuliert er einige Grundregeln für die Arbeit mit Docker: Diese können auch als Grundregeln der Programmierung benutzt werden. Wer mit Docker arbeitet, verbessert auch durchgehend sein Wissen. Es werden immer wieder Grundkenntnisse im Umgang benötigt und auch weiterführendes Wissen wird ständig vermittelt.

Im zweiten Teil des Vortrags stellt Peter Roßbach Microservice vor. Was ist Microservice? Microservice sagt, dass die Entwicklung möglichst einfach sein soll. Dabei hilft Docker, denn Docker vereinfacht die Built-Prozesse sehr, so dass jeder in der Lage ist, mit Docker Microservices selbst zu erstellen. Davon lebt Docker. Vom Teilen von Software. Es ist wie ein eigenes Ökosystem, welches ständig im Wachstum ist. Inzwischen existiert sogar ein eigenes Betriebssystem auf der Basis von Docker: CoreOS. Auch in zukünftigen Windows-Versionen soll Docker als Freeware bereits integriert sein. Zudem gibt es bereits einige sehr prominente Kunden, die Docker benutzen: Spotify, Netflix, Zalando und Ebay, um nur ein paar zu nennen.

Peter Roßbach stellt Bilder seines eigenen Schiffs vor, welches er aus LEGO-Steinen gebaut hat. Auf diesem Schiff liegen einige Container. Anhand dessen kann man sehen, dass lernen niemals aufhört. Entwickler müssen ständig bereit sein, etwas neues zu lernen. Dazu fällt ein weiterer, zentraler Satz: „Perfekt ist die Symbiose aus effektiv und effizient.“ Dem gibt es wohl nichts hinzuzufügen. Zum Schluss gibt Peter Roßbach noch die Möglichkeit, seine verwendeten Folien herunterzuladen. Getreu dem Motto: „Build, Ship and Run, any app, anywhere!“

 
Nachlese: Sagt mein Profiler die Wahrheit? | Print |
Written by Philip Höfges   
Friday, 22 August 2014 09:22

>> Folien auf Speakerdeck

>> Video

Trotz der langen Sommerpause fanden sich über 80 interessierte Zuhörer im Hörsaal 5B ein, um dem Vortrag von Fabian Lange zum Thema „Profiling“ zu lauschen. Der Web- und Performance-Spezialist von codecentric gewinnt, trotz leichter technischer Schwierigkeiten mit dem Mikrofon, mit einem Beispielprogramm, welches Zeichenketten erzeugen soll. Bei zwei verschiedenen Durchläufen bricht das Programm aber an zwei unterschiedlichen Stellen ab. Wie kommt so etwas zustande? Und wie findet der Kopf vor dem Bildschirm dies heraus? Genaue dafür wurde Profiler entwickelt.

In Java gibt es einige Werkzeuge, wie Mission Control, die die JVM nutzen und Profiling betreiben. Fabian Lange stellt diese in einer kurzen Historie vor und nutzt ein Zitat von Heisenberg, um zu verdeutlichen, dass jede Messung den Code beeinflusst. Zur Veranschaulichung dieser These beschreibt er einige Fehlerquellen beim Profiling:

Der so genannte „Overhead“ ist nicht präzise angegeben. Man kann nicht genau sagen, dass ein Analyseprogramm beispielsweise einen Overhead von zehn Prozent hat, ohne zu wissen, wie lange das zu analysierende Programm eigentlich braucht. Oftmals ist sogar der Speicher sehr knapp, was dazu führt, dass die Daten, die bei der Analyse gesammelt wurden, nicht gespeichert und somit ausgewertet werden können. Ein weiteres Problem stellt die Genauigkeit dar. Wie kann sagen, etwas sei genau? Es gibt Werte, die man nicht mit dem Begriff der Genauigkeit angeben kann, da sie nicht messbar sind. Beispielsweise kann man sich zwar die Zeit am Telefon ansagen lassen, die Zeit, welche man braucht, um einen Knopf an der Mikrowelle nach Beenden des Gesprächs zu drücken ist dabei nicht messbar. Weiterhin nennt Fabian Lange das Problem der Zeitangabe. Man muss zwischen CPU-Zeit und realer Zeit differenzieren. Realzeit lässt sich zwar sehr präzise messen, z.B. mit einer Uhr an der Wand, aber die Zeit, die eine CPU für eine Instruktion braucht, ist nur zwar genau feststellbar. Und was macht man mit großen Datenmengen? Fabian Lange vertritt die Ansicht, dass es wesentlich sinnvoller ist, sich auf kleine Daten, welche schneller auswertbar sind, zu verlassen, als in einem riesigen Paket von Daten zu suchen.

Im Profiling gibt es zwei klassiche Herangehensweisen: Das Sampling und die Instrumentierung. Während beim Sampling in regelmäßigen Abständen der Zustand des Programms eingefangen wird, verändert der Benutzer bei der Instrumentierung den zu messenden Code zu Einfügen von Zusatzcode, um an genau diesen Stellen das Programm zu messen. Zur Veranschaulichung hat Fabian Lange selbstgeschriebene Beispiele vorbereitet. Anhand derer kann man sehr deutlich sehen, dass Sampling zwar die Laufzeit des Programms nicht erhöht, jedoch nicht so viele Daten liefert wie die Instrumentierung.

Anhand einer Demonstration mit dem Tool „Hprof“ stellt Fabian Lange anschließend die Unterschiede zwischen den verschieden Version von Java heraus. Trotz eines identischen Programms liefern die Versionen 6, 7 und 8 von Java bei der Auswertung der Profiling-Daten unterschiedliche Ergebnisse.

In einer Zusammenfassung zeigt Fabian Lange, was für den Zuschauer hängen bleiben sollte. Die zentrale Aussage ist, dass Profiling keine Garantie bietet. Der Profiler kann nicht immer genau festhalten, an welcher Stelle des Programms der Fehler auftritt. Die letztendliche Verbesserung muss vom Anwender kommen. Zusammenfassend ist die Frage, ob ein Profiler die Wahrheit sagt, mit „Nein“ zu beantwortet.

Im Anschluss an den Vortrag wurde bei Freibier sehr angeregt über das Thema diskutiert.

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

Page 4 of 13