visualMind

OSGi-Bundles bauen mit Tycho

2010-06-25T06:26:00.006+01:00

Hallo,

ich habe mit Hilfe des Tutorials von Mattias Holmqvist (Teil 1, Teil 2 und Teil 3) unser Projekt vom Headless PDE-Build bzw. BND-Build umgestellt auf Tycho.

Zunächst einmal: Es geht erstaunlich einfach. Das Tutorial ist unglaublich präzise. Und tycho funktioniert schon in der Version 0.8 sehr gut, die gerade die aktuelle ist (0.10-SNAPSHOT wollte ich nicht nehmen).

Aber natürlich gab es auch noch ein paar Probleme, die kein noch so gutes Tutorial aus der Welt schaffen kann. Ich liste die einfach mal hier auf, damit andere bei ähnlichen Problemen eine Hilfe bekommen:

Source- und Target-Versionen für den Code

Wir verwenden für unseren Source Java Version 6-Features, insbesondere @Override-Annotationen auch für Methoden, die Interface-Methoden überschreiben. Das resultiert dann in einem Fehler "must override a superclass method".

Das wollte ich zunächst mit einer Plugin-Konfiguration in der parent-pom lösen, hier hat aber Tycho in der Version 0.8 noch ein Problem.

Aber das osgi-compile-Plugin verwendet aber die gleichen Properties zur Konfiguration wie das "normale" compile-Plugin, ich konnte also einfach die Properties maven.compiler.source=6 und maven.compiler.target=6 in der Parent-POM setzen.

In zukünftigen Versionen wird Tycho diese Information aus dem Manifest ziehen.

eclipse-application

Wir hatten bisher die .product-Datei in einem ganz normalen Bundle zusammen mit ein paar Java-Klassen, den entsprechenden Ressourcen etc. Tycho baut ein eclipse-application-Bundle aber nicht als Bundle, so dass es ich einfach genau so gemacht habe, wie Mattias Holmqvist es als sein Standard-Vorgehen beschreibt: Ich habe ein eigenes Plugin in der Eclipse IDE angelegt, das nur die foo.bar.product-Datei enthält. Dieses muss noch nicht einmal als PDE-Projekt angelegt sein. Noch schnell eine POM für dieses Projekt geschrieben (wie beschrieben in Teil 2) und in die Parent-POM eingetragen.

Verschachtelte Projekte

Tycho arbeitet im Moment nur mit P2-Repositories, nicht aber mit dem Maven-Repository. Es ist also nicht möglich, die verschiedenen Layer einer Applikation aufeinander aufbauend in separaten Builds zu bauen. Also muss die Parent-POM wirklich alle Module auf einmal bauen.

Soweit dazu, aber selbst mit diesen kleinen Problemchen hatte ich mit tycho meine Eclipse-Applikation schneller gebaut als mit dem PDE-Build oder mit dem BND-Plugin.

OSGi-Bundles bauen mit Eclipse und Maven

2009-07-13T07:42:00.011+01:00

Neu: Ich habe jetzt mal Tycho ausprobiert, damit ist alles besser :)

Allerdings mache ich dafür kein neues Tutorial, das von Mattias Holmqvist (Teil 1, Teil 2 und Teil 3) ist schon ziemlich perfekt. Meine Erfahrungen damit habe ich unter OSGi-Bundles bauen mit Tycho beschrieben.

---
Alter Post (Vorsicht, mir hat's Groß- und Kleinschreibung zerlegt und das Aufräumen lohnt aus oben beschreibenem Grund nicht mehr) :

OSGi-Bundles und Eclipse Plugins zu bauen war bisher immer sehr umständlich und fehleranfällig. Das bringt mich ja zu der Haltung, dass ich OSGi eher vermeiden würde. Insbesondere bringt es ja in der Regel auch keinen Business-Value. Anderes Thema, ich bin nun mal durch das Umfeld gezwungen, Plugins für die Eclipse Rich Client Platform zu bauen.

Meine Randbedingungen sind Folgende: Ich möchte in Eclipse entwickeln und dort auch alle Möglichkeiten der PDE nutzen. Andererseits ist es für mich keine Option, fertige Bundles durch einen Entwickler aus seiner IDE exportieren zu lassen. Ich nutze nämlich sowieso ein automatisches Build-System (schließlich bin ich nicht alleine auf der Welt, sondern kooperiere mit anderen, zum Teil verteilt sitzenden Kollegen), um Continuous Builds und Nightly Builds zu machen (siehe mein letzter Post). Dort möchte ich die Bundles über Maven bauen. Bisher haben wir das hier in der Firma über den automatisierten PDE-Build gemacht, der Prozess ist aber höchst umständlich und fehleranfällig.

Mit dem bnd-Tool und dem maven-bundle-plugin aus dem Apache Felix-Projekt gibt es jetzt aber eine spannende und benutzbare Option. Spannend deswegen, weil bnd einen völlig neuen Weg geht - es basiert nämlich nicht (nur) auf Deklarationen, sondern analysiert den compilierten Code, um Abhängigkeiten zu entdecken und in die MANIFEST.MF einzutragen.

Jetzt zur Lösung: Da ich nicht nur ein Bundle verwende, habe ich eine "common-pom.xml" als gemeinsame Parent-POM meiner Bundle-Projekte.

Dort verwende ich folgenden Eintrag unter Plugins:

<plugin>
  <groupid>org.apache.felix</groupid>
  <artifactid>maven-bundle-plugin</artifactid>
  <extensions>true</extensions>
  <configuration>
    <manifestlocation>META-INF</manifestlocation>
    <instructions>
      <bundle-symbolicname>${pom.groupId}.${pom.artifactId};singleton:=true</bundle-symbolicname>
      <bundle-activator>${bundle.activator}</bundle-activator>
      <embed-dependency>*;scope=compile|runtime;type=!pom,inline=false</embed-dependency>
      <embed-transitive>true</embed-transitive>
      <embed-directory>lib</embed-directory>
      <import-package>${bundle.import-packages}*;resolution:=optional</import-package>
    </instructions>
  </configuration>
</plugin>

Die notwendigen Properties habe ich in der Parent-POM wie folgt definiert:

<properties>
<bundle.activator>${pom.groupId}.${pom.artifactId}.internal.Activator</bundle.activator>
<bundle.import-packages></bundle.import-packages>
</properties>

Für das Zusammenspiel mit Eclipse als IDE sorgen dabei einige Einträge: Zunächst verwende ich als manifestLocation natürlich den "default"-Pfad von Eclipse (META-INF) und nicht den maven-default unter target.

Zum anderen verwende ich ein "Embed-Directory" (lib), in das ich per maven-dependency-plugin alle notwendigen Abhängigkeiten (d.h. 3rd-Party-Libraries, die ich nicht zu OSGi-Bundles konvertiere) kopiere. Der entsprechende Abschnitt der Parent-POM sieht wie folgt aus:

<profiles>
  <profile>
    <id>eclipse</id>
    <build>
      <plugins>
        <plugin>
          <artifactid>maven-clean-plugin</artifactid>
          <executions>
            <execution>
              <id>clean-dependencies-eclipse</id>
              <phase>process-resources</phase>
              <goals>
                <goal>clean</goal>
              </goals>
              <configuration>
                <filesets>
                  <fileset>
                    <directory>${basedir}/lib</directory>
                    <includes>
                      <include>**/*</include>
                    </includes>
                  </fileset>
                </filesets>
              </configuration>
            </execution>
          </executions>
        </plugin>
        <plugin>
          <artifactid>maven-dependency-plugin</artifactid>
            <executions>
              <execution>
                <id>copy-dependencies-eclipse</id>
                <phase>process-resources</phase>
                <goals>
                  <goal>copy-dependencies</goal>
                </goals>
                <configuration>
                <outputdirectory>${basedir}/lib</outputdirectory>
                <includescope>compile</includescope>
                <includescope>runtime</includescope>
                <excludetypes>pom</excludetypes>
              </configuration>
            </execution>
          </executions>
        </plugin>
      </plugins>
    </build>
  </profile>
  ...
</profiles>

Für ein konkretes Bundle sind jetzt "nur noch" relativ wenige Schritte notwendig:

Natürlich muss das Projekt die Parent-POM entsprechend referenzieren (ich mache das bei mir per relative-path wie folgt):

<parent>
  <groupid>de.vizmind</groupid>
  <artifactid>common</artifactid>
  <version>0.0.1-SNAPSHOT</version>
  <relativepath>../de.vizmind.common/pom.xml
</parent>

Als Packaging muss man bundle verwenden:

<packaging>bundle</packaging>

Jetzt kann man ganz wie gewohnt seine Dependencies eintragen, wobei die Compile und Runtime-Dependencies wie oben gesagt in den lib-Ordner kopiert werden und so für den PDE-Mechanismus von Eclipse verwendbar sind - dieser hat nämlich so seine Probleme mit den "Maven Dependencies" des m2eclipse-Plugins.

Abhängigkeiten zu anderen Bundles markiert man einfach mit dem Scope "provided", diese werden dann herangezogen, um die "import-packages" zu bestimmen, aber nicht mit in das Bundle kopiert.

Jetzt muss man gegebenenfalls noch die Properties aus der Parent-POM "überdefinieren", z.B. wenn man keinen Activator definiert hat (der default wird unter ${pom.groupId}.${pom.artifactId}.internal.Activator erwartet).

Wenn man Abhängigkeiten definieren muss, die sich nicht aus den class-Dateien ergeben, so ist das manuell über das Property "bundle.import-packages" zu tun. Da dieses Property einfach vor die automatisch bestimmten gehängt wird, muss man es (noch) mit einem Komma beenden, sofern es nicht leer ist. (Ein weiterer Punkt für Verbesserungen). In unserem Beispiel hier verwenden wir in einem Bundle spring und referenzieren in der context.xml einen PropertyPlaceholderConfigurer. Der Import für diese Klasse kann natürlich nicht automatisch aus .class-Dateien bestimmt werden, also muss er manuell hinzugefügt werden. (Ein weiterer Punkt für Verbesserungen - Automatische Analyse von Spring-Dateien).

Zusammen sieht das dann wie folgt aus:

<properties>
  <bundle.activator></bundle.activator>
  <bundle.import-packages>org.springframework.beans.factory.config,</bundle.import-packages>
  
</properties>

Jetzt ist mein Projekt fertig. Die Verwendung eines Profils (in der Parent-POM, siehe oben) sorgt dafür, dass ich mit folgendem Maven-Kommando ein Eclipse-Projekt anlegen kann, ohne dem eigentlichen Build später in die Quere zu kommen.

mvn eclipse:clean eclipse:m2eclipse process-resources compiler:compile bundle:manifest -Declipse.pde=true -Peclipse

Das Kommando ist noch etwas umständlich, evtl. mache ich später hier noch etwas "Feinarbeit". Für jetzt funktioniert es erst mal.

Das Projekt kann nun in Eclipse importiert werden. Einziger Wermutstropfen: Aktuell wird die .classpath-Datei noch nicht so aufgebaut, dass die embedded 3rd-Party-Libraries auch referenziert werden. Die muss man noch einmal "von Hand" in den Build-Path aufnehmen.

Damit ist der Weg frei, das Bundle in der Eclipse IDE zu verwenden und zu entwickeln.

Mit

mvn package

kann man nun das Bundle auch bauen, so dass auch dem automatisierten Build nichts mehr im Wege steht.

Ciao

Chris

Video vom Vortrag

2009-05-11T19:13:00.002Z

Den Hudson-Vortrag hab ich gleich nochmal gehalten - beim Arbeitskreis Objekttechnologie Norddeutschland.

Diesmal gibt's auch ein Video davon.

Vortrag bei der JUGHH: Continous Integration mit Hudson

2009-03-18T23:16:00.004Z

Hallo!

Gestern habe ich einen Vortrag bei der Java User Group Hamburg über Continuous Integration mit Hudson gehalten. Die Folien dazu gibt's unten.

Wie üblich haben sich neben und nach dem Vortrag interessante Diskussionen ergeben, die im wesentlichen in zwei Richtungen gehen:

Zum einen ist der Build von Eclipse-Applikationen ein echter Schwachpunkt, für den jeder Lösungen sucht bzw. ähnliche Workarounds findet. Ein wirklich schwerwiegendes Problem dabei ist, dass man kaum verwertbare Dokumentation dazu findet. Ich werde versuchen, das in einem meiner nächsten Posts zu beheben und unseren Eclipse-PDE-Build-Prozess zu beschreiben. Die Einbindung in Hudson ist dabei Gott sei Dank nicht das Problem.

Zum anderen stellte sich einmal mehr heraus, dass auch das Bauen von Software immer wieder neue und interessante Facetten hat. Hudson kann ja mit mehreren Build-Prozessoren umgehen. Welche Build-Schritte kann man eigentlich parallelisieren? Welche müssen in jedem Fall erst nach einer Menge anderer Teil-Schritte bearbeitet werden. Wie synchronisiert man diese Builds. Wie testet man? Auch das sind Themen, auf die ich jetzt (noch) keine Antwort habe. Demnächst mehr.

Gute Nacht!

Continuous Integration mit Hudson

View more presentations from cb.betz.

Neues Jahr, neues Glück

2009-01-13T16:45:00.005Z

So - neuer Vorsatz... eigentlich hab ich's ja nicht so mit Vorsätzen, aber dieses Jahr ist gut dafür. Unser Nachwuchs kommt und ich hab mir überlegt, dass es endlich Zeit ist, web2.0ig zu werden. Also nicht passiv, sondern aktiv. Selbst bloggen, twittern, flickrn und so weiter, was das Zeug hält. Was Nachwuchs und Web 2.0 miteinander zu tun haben? Erst mal gar nix. Außer dass ich natürlich drüber nachdenke, was mir wichtig ist und was ich gern mache. Und das werde ich hier mit allen teilen, die's interessiert.

Also kurz über mich - ich bin ja eigentlich schon Web 2.0. Viel im Internet unterwegs und schon eher das, was sich so gemeinhin Early Adopter nennt. Immer eher technisch, aber auch mit einem starken Bezug zum Nutzen, zu User und Usage Experience bis hin zum Marketing. Den Fokus auf Benutzbarkeit habe ich schon in meiner Promotion gehabt. Da ging es darum, wie man eLearning-Systeme durch Fachexperten mit einer möglichst geringen Einstiegshürde erstellen kann und wie diese dann nach und nach so wachsen, dass sie "intelligent" auf die Lerner reagieren können. Ich habe schon Expertensysteme entwickelt, Musikportale im Internet gebaut und auch größere Web-Systeme für Banken. Nicht gerade Web 2.0 - aber für die konservative Branche schon recht fortschrittlich. Manches davon habe ich in meiner eigenen Firma gemacht, manches bei einem der größten deutschen Interactive-Dienstleister.

Seit etwas über einem Jahr bin ich jetzt in einer ganz anderen Branche. Ich baue Software zur Kommunikationsanalyse in einer alteingesessen Hamburger Firma. Zum Thema Visuelle Analyse werde ich hier sicher noch das ein oder andere schreiben.

session building

2008-10-18T08:07:00.001Z

hey, spannend. Es ist total egal, wie viele Leute sich für ein Thema interessieren. Die Themen werden immer in den Schedule gepinnt.

barcamp...

2008-10-18T07:58:00.002Z

make wine tasting visible, accessible places, tomocos, theatre 2.0,

Die Themen sind recht unterschiedlich und bei weitem nicht soooo technisch, wie die ursprünglich angekündigten Themen. Fragt sich, ob nur die Nerds ihre Themen schon vorher präsentieren?

Website Navigation

2008-10-14T12:04:00.002Z

Interessant, sollte man mal ausprobieren: Eine Website ohne eigene (hierarchische) Navigation, weil Benutzer die sowieso nicht benutzen. Stattdessen "teleportieren" sich die Benutzer mit Googles Hilfe von einer Website zur nächsten.

Das würde völlig neue Wege der Visualisierung erlauben. Raus mit diesem ganzen Overhead zur Navigation. Stattdessen würde vielleicht eine Customized Search Sinn machen.

Die richtige Frage

2008-10-14T11:41:00.005Z

Interessant: Hier, in der Session von Moritz Stefaner, werden Visualisierung nicht als Tool zur Überprüfung von Hypothesen, sondern als Tools zur Generierung von Hypothesen gesehen. Ich habe oft den Eindruck - gerade auch im Vergleich mit Manuel Lima - dass solche Fragestellungen auf dieser VizThink-Konferenz oft noch nicht beantwortet werden. Eigentlich noch nicht einmal gestellt werden. Ich erinnere nur an die Session gestern (und den Post dazu): Dabei kam aus dem Auditorium die Frage, wie man Visualisierungen für unterschiedliche Stakeholder produzieren kann und wie man vor allem entscheiden kann, welche Visualisierung für welche Stakeholder passend ist.

Marketing-Maschine

2008-10-14T11:36:00.002Z

Die Marketing-Maschine auf der VizThink schlägt voll zu - selten habe ich eine Veranstaltun erlebt, in der Sessions so unverholen zum Marketing missbraucht werden oder von den Teilnehmern als solches wahrgenommen werden.

Egal, ob es die Aufforderung ist, das "Was ist die visual thinking Industrie"-Poster zu vervollständigen oder die Pro-/Con-Liste für visuelle Kooperationssoftware (natürlich mit der visuellen Kooperationssoftware) zu erstellen - natürlich lernt man dabei was.

Visual Thinking or Visual Explaining

2008-10-13T14:31:00.003Z

Aus meiner ersten Session heute morgen habe ich ja die Frage mitgenommen, ob es einen Unterschied zwischen visual thinking und visual explaining gibt. Denn die Werkzeuge sind ja durchaus unterschiedliche - von Mind Mapping und ähnlichen brainstorming Techniken über mehrere Stufen hin zu dem Ergebnis, der Infographik, die den Kern der Nachricht transportiert. Dabei sind auch die Ziele durchaus unterschiedlich.

In den verschiedenen Sessions kommt es daher auch immer zu der Diskussion um Expertise-Modellen, d.h. die Schritte zwischen Daten und Wissen, Lernen und Lehren oder wie auch immer man die Skala aufspannt.

Auch für meine Arbeit - die Analyse und das Kommunizieren der Ergebnisse - ist diese Unterscheidung wichtig und sollte in der Software noch wesentlich stärker berücksichtigt werden.

Mini-Erkenntniss

2008-10-13T14:29:00.000Z

Beim Mittagessen hab ich erfahren, dass es Leute gibt, die davon leben, bei Workshops live die Diskussionen in Flipchart-Bilder zu fassen. Eigentlich kam ich darauf, weil eines der Flipcharts aus einem Workshop wirklich herausstechend besser aussah als die anderen.

InfoViz'08 in Berlin

2008-10-13T14:05:00.005Z

Moin,

heute bin ich auf der VizThink '08 Europe in Berlin. Worum geht's? "It's about spending lots of money on a poster a six-year old could draw". Nein, natürlich nicht - aber das ist das Vorurteil, mit dem diese noch relativ junge "Industrie" häufig konfrontiert wird.

Warum bin ich hier? Ganz einfach - Software ist meistens visuell. Das User Interface wird in der Regel visuell wahrgenommen, die Informationen visuell präsentiert und das sind meistens mehr als man nach der 5 +/- 2 - Regel im Arbeitsspeicher des Hirns halten kann.

Interessanterweise ist die Konferenz gar nicht so "visuell" wie man vielleicht vorher hätte vermuten können, sondern zum Teil auch sehr physisch aktiv: Es wird auch gerne Text auf Post-Its an die Wand geklebt. Aber eben Text. Ist das jetzt visuell? Weil's hinterher an der Wand klebt?

Die Mischung aus Designern, Software-Entwicklern, Consultants und zwischen den verschiedensten fachlichen Disziplinen hier ist ziemlich groß im Vergleich zu anderen Sachen, die man sonst so hört oder sieht. Deswegen ergeben sich auch in den kleinen Gesprächen am Rande der Konferenz sehr interessante Gespräche.

Dass visual thinking noch relativ jung ist und es eben nicht immer fest gefertigte Antworten gibt, sieht man auch daran, dass stärker als bei anderen Konferenzen die Fragen und Diskussionsbeiträge sehr interessante Einsichten bringen.

Ich bin gespannt, was noch an Einsichten kommt.

jax08: Advanced GlassFish

2008-04-22T15:00:00.002Z

So, das ist jetzt hoffentlich spannender und die ersten paar Minuten kann ich doch ganz bestimmt auf der CD-Rom noch checken. Auf jeden Fall habe ich gerade den Talk gewechselt und lass mich mal zum GlassFish informieren.

Ein interessanter Link ist VisualVM, ein Monitoring Tool aktuell in Beta 2.

GlassFish unterstützt Single Sign On (SSO) für alle Web Applikationen bzw. mit OpenSSO gibt es auch ein CrossServer bzw. CrossDomain SSO. Interessant ist, dass OpenSSO auch heterogene Umgebungen abdeckt, indem man Adapter in die jeweiligen Umgebungen deployt. Jetzt gibt's einige Beispiele dafür, wie man mit OpenSSO in verschiedenen Setups nutzt. Jetzt gerade gibt's hier das Beispiel für die Nutzung in WebServices. Da SSO ja ein immer wiederkehrendes Thema ist.

Weg vom SSO-Thema, hin zu einem neuen Hype: Scripting. Man merkt schon, Daniel Adelhardt hat so gewisse Vorbehalte: "muss man zugestehen" und "Quick, Dirty & Good Enough Architekturen" - ehrlich, das was hier offensichtlich als "Enterprise Architekturen" firmiert ist halt nicht pragmatisch. Nicht in dynamischen Sprachen und nicht in Java.

Immerhin, Sun hat das erkannt und setzt auf JRuby. Jython ist auch dazugekommen. Jetzt fehlt nur noch offizieller Support für Groovy. Und Daniel Adelhardt gibt das Statement, dass Groovy in Netbeans und in GlassFish unterstützt wird. Ich persönlich bin ja überzeugt davon, dass dynamische Sprachen - hier unterscheide ich für mich ja von "Skriptsprachen" - auch im Enterprise Umfeld wesentliche Benefits bringen können.

Dass es Sinn macht, AppServer und "Skriptsprachen" zu kombinieren, stellt auch Daniel Adelhardt dar, sei es aus Security Gründen, aus Gründen der Betriebs-Infrastruktur und des entsprechenden KnowHows.

Schön ist die Unterstützung von PHP über das Quercus Servlet. Das gefällt mir. Auch für JRuby gibt es Bundle, das sich direkt in den GlassFish 2 installieren lässt. Von GlassFish 3 gibt es eine Mini-Version (geht quasi zurück auf die Keynote), die dann auch quasi "nur" den Ruby-Server bereitstellt.

Was passiert mit Groovy bzw. Grails? Interessanterweise wird das in Deutschland gemacht und ist aktuell in Arbeit.

Nächstes Thema: Rich Application Clients: Load Balancing und Failover for IIOP(s). Man kann da den Client mit dem ear bundlen und der Glassfish generiert dann automatisch ein JNLP File. Scheint aber alles nicht so einfach zu sein. Das ganze gibt's zum Nachlesen auf den Slides. Und hah - für Firewall/Loadbalancing-Szenarien gibt's 'ne Lösung.

Comet ist eine Lösung, um einen Push vom Server auf den Client auszulösen. Muss man sich mal genauer ansehen. Auf jeden Fall unterstützt der GlassFish Comet und man muss einfach im http-listener das Property "cometSupport" auf "true" setzen. Im Server-Log sollte dann so was stehen wie "Enabling Grizzly ARP Comet support". Die Basis für Comet im GlassFish ist die NIO, die ein non-blocking handling erlaubt. Im Service einfach den CometHandler implementieren und den CometHandler beim Request anhängen. Der Code ging auf zwei Slides und der Mechanismus ist ziemlich interessant.

Mein Fazit zu dieser Session: Ja, das mit OpenSSO hat nicht wirklich zwingend was mit GlassFish zu tun, aber dennoch war der Talk sehr interessant, hat eine weite Thematik behandelt und war absolut empfehlenswert. Gut, das Thema Comet hatten wir so auch schon mal, ohne zu wissen, dass es Comet gibt.

jax08: Presenter First for RCP applications using Spring OSGi

2008-04-22T14:30:00.000Z

Wow, drei Buzzwords auf einmal im Titel, wenn ich dann auch noch testable dazunehme... also abwarten, ob das Buzzword-Bingo wird oder interessant. In diesem Zeitslot ist die Konkurrenz groß, ich habe auf Glassfish, Sprachtrends und Pragmatic Architecture verzichtet.

Natürlich wollen wir möglichst einfach, agil, testbar auch unseren Eclipse RCP UI-Code entwickeln. Also los. Kurze Einführung ins Beispiel, Test Cases für das Beispiel. Schade, da macht Heiko Seeberger schon zuerst die Tests, doch dann macht er (auf seinen Folien) wieder den "Fehler", sich nicht von den Tests leiten zu lassen. Er macht erst mal ein "so macht man's nicht"-Beispiel und hackt das Beispiel komplett in einem Composite. Naja, kein Wunder, dass sich das nicht testen lässt. Weiter. Nächster Punkt.

Ich denke, dass ich hier falsch bin - und mir den Vortrag lieber auf CD-Rom ansehe. Mal sehen, ich geh mal weiter in den nächsten Vortrag, wo es sich vielleicht nicht so leicht nachlesen lässt.

Grails - der Gral der Webentwicklung

2008-04-22T12:30:00.000Z

Mann, oh mann! Zweimal schon wollte ich mir diesen Talk in Hamburg schon anhören - in der XP-User Group und an der HAW. Hat beide Male nicht geklappt, also muss es hier endlich gehen. Ich komme ja aus der Ecke Web-Entwicklung und das Thema wird mich bestimmt auch nicht ganz loslassen, auch wenn ich im Moment eher Service-orientiert und Eclipse RCP-lastig unterwegs bin. Vielleicht gibt's ja auch neue Ideen für ein RCP-Grail, denn convention over configuration hat sich dort auch noch nicht durchgesetzt. Hinzu kommt, dass dies die meiner Meinung nach "schwächste" Session-Runde ist (hier hatte ich nur vier Talks zur Auswahl) und wir uns kollegentechnisch etwas aufgeteilt haben und wir so nichts relevantes verpassen. Hoffentlich.

Hey, cool. Endlich hat sich's mal gelohnt, dass mein Notebook so 'nen schwachen Akku hat: Dadurch wollte ich mir einen Platz mit Steckdose sichern, war früher da und muss jetzt wenigstens weder stehen noch am Boden sitzen. Grails ist ein Thema, das brennt.

Der Vortragsstil - zumindest der Einstieg - ist schon mal klasse. Ich persönlich stehe ja auf diese Art von Vorträgen. Anhand von "Praxisbeispielen" beleuchten die beiden Web-Frameworks: Es ist mehr eine Pannenshow in Bildern aus allen möglichen Bereichen, mit Übertragung auf die Web-Frameworks. Die Folien danach sind eher klassisch, aber gut, es soll ja auch nicht nur cool sein, sondern auch informativ.

Spring, Hibernate und Sitemesh sind die Grundlagen von Grails, Groovy ist nur der Zuckerguß auf diesen Grundlagen. Und da der Zuckerguß dünn ist, wird die Applikation auch nicht dick, soll heißen langsam durch die doch vergleichsweise geringe Performance. Neben diesen Grundlagen stecken in Grails noch andere Libraries für Ajax, Batch, Sicherheit und Tests. Eigentlich sind es die alten Bekannten aus der Welt der Webentwicklung.

Jetzt kommt ein Crash-Kurs Groovy, den gebe ich hier mal nicht weiter. Für Java-Entwickler ist der Einstieg ja suuper-leicht, aber wie immer dauert es natürlich eine Weile, bis man wirklich in der Denke der Sprache angekommen ist. Ich reite noch mal drauf rum - wer LISP kann, ... naja, lassen wir das. Worauf auch Stefan Roock nochmal hinweist: Groovy und Java integrieren sich nahtlos, man kann von Java-Klassen auf Groovy-Klassen zugreifen und umgekehrt.

Jetzt zu Grails: Zunächst mal die Persistenz: Domain-Objects werden automatisch gemappt. Ich muss also keine Hibernate-Konfiguration, keine JPA-Annotationen oder sonst etwas machen, es geht sofort los. Wobei man zugeben muss, dann man es hier halt nicht über Annotationen oder sonst etwas machen muss, sondern über die Konvention, dass es in einem Package domain liegt und dass man die Felder hasMany oder belongsTo benutzt, die jeweils eine Map bekommen. Constraints werden beispielsweise über eine Closure definiert, die eine DSL enthält. Spannendes Konzept. Stefan Roock weist noch darauf hin, dass man sich leichter tut, wenn man es erst mal so hinnimmt und nicht versucht, es erst mal zu verstehen und dann zu machen. Stimmt wohl, das Konzept ist einfach zu benutzen. Wie die Abbildung auf die Datenbank-Constraints passiert muss man eigentlich gar nicht wissen. Aber es zeigt schön die Groovy-Denke.

Der DynamicFinder ist total interessant, da er wundervoll die Dynamik der Sprache zeigt: Adresse.findAllByPostleitzahlAndGueltigBis(21502, null). Ein MOP (Metaobject Protocol) hat echte Vorteile! Die Zwischenfrage nach der IDE-Unterstützung ist natürlich interessant: IDEA hat die beste Unterstützung, Eclipse und Netbeans ziehen da nach.

GroovyServerPages setzen voll auf Sitemesh und entsprechende Taglibs. Das kann man in Java natürlich so auch selbst machen, aber Grails bringt das halt schon alles mit.

Wir haben Model und View, die Controller verbinden das. Dabei werden Controller in einem eigenen Package und über das Suffix Controller identifiziert. Interessanterweise werden die einzelnen Aktionen nicht als Methoden realisiert, sondern als Closures, die in Feldern gespeichert werden.

Jetzt geht's schon ins Eingemachte: AJAX ist eingebaut (Prototype / Script.acoluo.us, Yahoo! UI als Plugin, Dojo als Plugin). TagLibs lassen sich einfach selbst bauen: Wieder per Konvention in den Ordner taglib die eigene TagLib reinwerfen und schon ist die Taglib fertig. Stefan Roock weist darauf hin, dass man durch die Einfachheit in Grails-Projekten eigene Taglibs viel häufiger einsetzt als in Java-Projekten. Glaube ich sofort.

Testen ist in Grails direkt eingebunden. Es generiert Skelette für Domain-Klassen und Controller, integriert die Ausführung von Tests in die bereitgestellten Skripte etc. Noch ist das ziemlich langsam, weil die VM, das Framework und der Webserver immer mal wieder hoch- und runtergefahren wird.

Jetzt kommt Stefan Roock schon zu RESTful Services mit Grails, sehr interessant, aber doch durchaus vielleicht schon fast zu tief. Die Zuhörer schwitzen zum Teil schon.

Aber, es ist fast geschafft. Jetzt geht's (nach der unvermeidlichen Werbeeinblendung) zur Live-Demo. Also Console auf, TextMate auf und los geht's. Bernd Schiffer baut sich erst mal eine neue Grails-Applikation. Beziehungsweise er lässt sich eine neue Applikation bauen, und zwar vom entsprechenden Grails-Skript.
Die Domain-Klasse wird wieder per Skript erzeugt. Erst mal ist das nicht spannend, aber Plugins für Grails können sich hier einklinken und so wird beispielsweise zu der Domain-Klasse auch eine Test-Klasse erzeugt.

Jetzt kann man die Applikation starten (dazu fährt intern ein Jetty hoch). Noch passiert nicht viel - die Applikation fährt hoch, aber es ist nur die Grails-Standard-Seite zu sehen. Also - Server läuft weiter - macht Bernd Schiffer sich einen entsprechenden Controller. Den sieht man jetzt schon auf der Einstiegsseite. Fehlt noch ein View, aber die entsprechenden Ordner sind auch schon angelegt. Also flugs eine gsp-Seite angelegt.

Bisher alles ohne Server-Neustart zu sehen.

In der Klasse BootStrap gibt's eine init (und eine destroy)-Methode, dort kommt noch ein bisschen Init-Code hin (Domänen-Objekt erzeugen), Server stoppen und starten (sonst wird die BootStrap-init-Methode nicht ausgeführt). Und schon sieht man was.

Jetzt geht's weiter über das Einfügen von Links, mehr Code im Controller etc. Damit sind wir durch. Die Fragen gehen im Rauschen unter, über DataSources kann die zugrundeliegende Datenbank auswählen, Refactorings sind noch nicht wirklich gut unterstützt, es gibt verschiedene Möglichkeiten, (Java) Legacy-Code zu integrieren. Mit DB-Migrate kann man die Migration von Datenbank-Schemata durchführen.

Noch mein Fazit: Der Talk war eine gute Einführung mit einer schönen Mischung aus theoretischer Einsicht und einem praktischen Teil. Groovy ist auf jeden Fall einen Blick wert. Wann kommt jetzt das Buch?

Randnotiz Treffer

2008-04-22T09:24:00.003Z

Gerade auf der JAX-Website gelesen, dass es "Beste Gelegenheiten für Networking & Erfahrungsaustausch!" gibt. Stimmt, bin gerade kurz nach seinem Vortrag in Stefan Zörner reingelaufen. Mal sehen, was mein Kollege nachher über Zörners Talk erzählt.

Spring: Vom Framework zum Ökosystem

2008-04-22T08:11:00.002Z

Ich habe mich für die Session "Spring: Vom Framework zum Ökosystem entschieden". Damit hat Eberhard Wolff gewonnen vor Rod Johnson mit seiner Q&A-Session zur Keynote und ein paar anderen interessanten Sessions. Hoffentlich wird's so interessant wie ich mir das gerade erhoffe. Natürlich stellt sich gerade in dieser Session die Frage, ob Spring mit allem nicht mittlerweile zu groß wird und damit in die Falle tappt, in der Java EE jetzt schon steckt.

Wow, erst mal schmeißt Wolff viiiiele Blasen an die Wand: Die ganzen Spring-Teilprojekte. Eine der Blasen ist Spring Batch. Spring Batch ist die Unterstützung von Batch-Jobs für Java, und dass Batch Jobs in vielen Projekten wichtig sind. Typische Probleme von Batches (ich denke mal, die Unterstützung dafür kommt gleich) sind Wiederaufsetzen nach einem Fehler, Parallelisierung und die Optimierung von Datenbank-Operationen.

[...] (Anmerkung: Hier redet Eberhard Wolff ziemlich detailliert über Spring Batch) Und weiter, und mehr, und noch mehr Batch Details. Ja, ich weiß was ein Batch ist und wie man so was bauen würde. Die Details von Spring Batch kann ich mir anschauen, jetzt wo ich weiß, dass es das gibt. Ich fange gerade an, in meinen Unterlagen zu blättern und nach Alternativen zu suchen. Das ist nicht der Vortrag des Titels, sondern irgendwas anderes. Das ganze geht mir persönlich viel zu tief in Spring Batches, ein deutlich flacherer Überblick hätte mir hier definitiv gereicht. Mehr, unterschiedlicher. Was gibt es noch an Blasen.

Endlich geht's weiter zum nächsten Bubble: Spring Integration. Das löst typische EAI-Probleme, also Messages, Routing, Splitting, Transformation etc. Das Framework basiert auf einem Pipes & Filters Pattern und ist Event-driven. Das heißt, dass sich das Framework um das Message-Listening kümmert und dann die Service-Aufrufe regelt. Beispielsweise übernimmt das Spring Integration Framework das Thread-handling. Super, das ist jetzt mal auf dem korrekten Niveau. Jetzt nur nicht zu sehr abgleiten ins Detail. Wir gehen jetzt mal in den Code, es könnte schon zu detailliert werden. Jaaa, es wird zu detailliert. Gut, es interessiert mich auch, ich raschle nicht, aber es ist eigentlich zu detailliert. Ich tackere das jetzt nicht mit, sondern verweise einfach mal auf die entsprechenden Slides. Ich hoffe mal, dass ich die CD-ROM mit den Slides nachträglich bekomme. Kommt das Ding per Post oder muss man es holen? Worauf ich hier noch hinweisen möchte: Spring Integration hat eine klassische Java-API, man kann aber auch sehr gut und einfach mit Annotations arbeiten.

Spring Web Services ist das nächste Bubble, das Eberhard Wolff vorstellt. Interoperabilität ist das Ziel von Web Services und Contract First ist das Mittel zum Zweck. Wenn man schon mal WebServices hat, dann kann man mehr machen als nur request-response und man möchte ggf. auch direkt auf das XML durchgreifen können.

ContractFirst ist gesetzt, wie soll man sonst Interoperabilität gewährleisten. Eine WSDL von Hand schreiben macht keinen Spaß. Umgekehrt ist der Weg der Generierung der WSDL aus Java auch suboptimal - es ist contract last, die Java Klassen entsprechen nicht den WSDL/XSD-Möglichkeiten, man bindet sich ggf. an die einzelnen WebService-Stacks. Selbst schon erlebt - WebServices sind per se erst mal nicht wirklich interoperabel zwischen verschiedenen Stacks und Sprachen. Jetzt kommen wir wieder zu dem Punkt, dass die WSDL eigentlich nicht en bloc von Hand geschrieben werden sollte, sondern aus verschiedenen Artefakten zusammengeneriert werden sollte.

Spring verwendet ein XML Schema zur Definition der Datenbeschreibung und der Methoden. Die Komplexität des SOAP Stacks (Endpoints, Ports und so weiter und so fort) kann man dann an anderer Stelle machen.

Für das Mapping von Objekten auf XML und umgekehrt kann man die vorhandenen Techniken nehmen - JAXB 1 und 2, Castor, XMLBeans, JiBX, XStream oder was auch immer. Oder man mappt nicht, sondern geht direkt auf die XML-Struktur runter, beispielsweise mit JDOM oder SAX. Die dritte Alternative geht über Annotationen und XPath. Das sieht interessant aus.

In 1.5 ("was wir jetzt gerade shippen") gibt es neu auch JMS und Email Transport.

Weitere Bubbles werden noch nicht mal kurz vorgestellt, da es z.T. noch eigene Talks dafür gibt.

Spring Enterprise bundled verschiedene Dinge zusammen: Zum Beispiel das Advanced Pack for Oracle, die bestimmte Misfeatures des Oracle RAC "ausbügelt". Es gehört auch die SpringSource Tool Suite dazu und die SpringSource Application Management Suite.

Ok, wir haben gesehen, dass Spring mittlerweile auch ein ganzer Zoo von Frameworks ist, aber diese einzelnen Frameworks sind wesentlich loser aneinander gekoppelt als dies bei JEE der Fall ist.

Future of Java

2008-04-22T07:13:00.004Z

In der Keynote erzählt Rod Johnson was über die Zukunft von Enterprise Java. In seiner typisch amerikanischen Art führt er erst mal aus, dass Java nicht mehr sexy ist: "No one will date a Java developer". Ruby sei doch so viel sexier für Web development. Ist natürlich nicht so, sonst stände Johnson ja nicht hier, sondern würde Ruby machen. Also, noch viel amerikanischer: Wir ziehen erst mal Statistiken raus - indeed.com job trends gibt ja die nötigen Daten ohne große Arbeit. Also der Vergleich mit Ruby, mit dot.net, alles in bunten Bildern. Fazit: Damit Java-Entwickler weiter gedated werden, muss sich Java ändern. Mal schauen, was Johnson als six plus two predictions präsentiert.

Aber zuerst mal zu den Faktoren, die Änderungen notwendig machen: Zuerst mal ist da die "productivity challenge" - dass man mit Ruby on Rails schneller ist in der Entwicklung von bestimmten Web-Applikationen ist als mit Java hat sich nun schon rumgesprochen. Der Punkt daran ist, dass die Java community an den "low hanging fruits" vorbeispringt. Warum also immer Rakentenphysik, wenn's auch einfach geht. Si!

Der zweite Grund für notwendige Änderungen ist einfach das Alter von Java EE. Java ist einfach nicht mehr schlank, weil sich mittlerweile eine Menge "baggage" angesammelt hat. Gut, ich hätte zwar "garbage" genommen, aber der Effekt ist der gleiche: Man muss das System wieder aufräumen, den Frühjahrsputz machen. Johnson sieht in Java EE 6 genau den Versuch, die Java Plattform auf Vordermann zu bringen. Die beiden Idees hinter Java EE 6 sind Extensibility und Profiles (steht auch im JSR-316). Die Grundlage für die Extensibility ist die Erkenntnis, das man nicht alles in die Plattform stecken muss, sondern dass die Plattform wirklich, ja was, eine Plattform für andere Frameworks sein sollte. Immerhin, die Erkenntnis ist für die Java EE Plattform wirklich neu. Klingt aber gut, denn mir geht das, beispielsweise mit den Appservern als Ergebnis von Java EE, oft so, dass ich viele der angebotenen Dienste nicht brauche. Andere auch nicht, und das ist wohl der Grund, warum der Tomcat als "App-Server light" so beliebt ist. Sorry, ich bin abgeschweift.

Johnson ist mittlerweile schon bei den Profiles. Es wird erst mal drei davon geben und sie sind Ausprägungen der Plattform. Die einfachste Variante "Profile A" (ich denke mal, dass sich der Name noch ändern wird) ist im wesentlichen der Tomcat: Servlets, JSPs, EL und JSTL und solche Sachen. Wichtig sind dabei Änderungen in der Sichtweise: Die Extensibility schlägt wieder zu und so muss man z.B. nicht immer alles von Hand in die web.xml eintragen. Stattdessen wird es eine API dafür geben, so dass Frameworks einfacher auf der Java EE (light) Plattform aufsetzen können.

Profile B ist Profile A plus persistence und zwei Komponenten-Modelle (mit Fragezeichen). Eventuell wird es ein EJB 3.1 light geben, was auch immer das sein wird. Das zweite wird evtl. ein Web Beans Modell sein (JSR-299). Profile C wird ziemlich genau das sein, was wir jetzt schon als Java EE haben. Rod Johnson hat jetzt schon auf den Folien stehen, dass das volle Java EE wenig Relevanz hat.

Für Sun ist das natürlich eine gute Strategie: Mit dieser Strategie kann sich Java vielleicht noch ein paar Jahre unten gegen Ruby und oben gegen Dot.Net verteidigen. Ob es für Entwickler wirklich einen echten Effekt zeigt, wird sich noch zeigen: WebLogic, WebSphere und JBoss werden natürlich ihre Produktstrategie ein Stück weit unabhängig von Sun überdenken. Die Tendenzen dort gehen ja eher dahin, immer mehr in die Produkte zu packen - und sei es nur als Marketing Fake. Aber das ist ein anderes Thema. Rod Johnson kommt zu ähnlichen Schlüssen auf seiner nächsten Folie. Interessant, die nächste Statistik kommt auch (siehe oben) - Tomcat ist die am häufigsten eingesetzte Plattform für Enterprise Java. Was Sun hier also als Strategie fährt ist einfach ihre Anpassung an die Realität. An die Realität, die wir hier im Auditorium schon alle leben.

Jetzt zu den lange angekündigten Predictions:
"Real competition will return to the application server market", jaja, Tomcat kann sich dann auch den Java EE-Stempel aufkleben und damit hat man einen weiteren Marktteilnehmer. Und neben Tomcat noch viele andere. Damit gibt es eben eine niedriger Markteintrittsschwelle. Ok, im wesentlichen hatte ich den Punkt ja oben auch schon, denn der Punkt ist doch, dass die vollen Java EE Appserver Funktionalität realisieren, die nur die wenigsten nutzen. Geht mir im übrigen auch so - im letzten Projekt hatten wir einen WebLogic, benutzt davon haben wir die Servlet Engine für die WebServices und JMS. Das hätten wir auch mit dem Tomcat machen können.

Prediction 2: "Tomorrow's application server will be lightweight and modular". Die JBoss-Leute schreien jetzt "haben wir schon, haben wir schon". Richtig. Und alle anderen werden laut Johnson auf OSGi als technische Basis setzen.

Prediction 3: "Tommorow's application server will not merely implement JCP specifications". Komisch - das tun sie doch heute schon nicht. Und wenn, dann pushen sie ihre originären Sachen als neue Standard-Vorschläge. Aber Johnson führt das noch ein bisschen aus: Es wird nicht nur JCP standards geben, sondern z.B. auch die von der OSGi Allience. Viel interessanter ist der Umkehrschluss, in dem Rod Johnson ausführt, dass der JCP nicht immer das Rad neu erfinden muss. Wer braucht commons logging, wenn es schon log4j gibt. Wer braucht ein neues EJB-Konzept, wenn es Spring gibt. JSR 277, wenn es OSGi gibt. Ob sich diese Einstellung endlich durchsetzen kann? Ich bin kein Fan davon, dass es nur (Gedanken-) Monopole gibt und wer eine bessere Idee hat, der sollte sie auch in Code umsetzen. Aber oft ist es eben keine bessere Idee, manchmal noch nicht mal eine andere. Eben nur eine andere Organisation - das not invented here Phänonomen macht auch vor dem JCP nicht halt. Damit kommt auch die extended prediction: the JCP will run on open source.

Prediction 4: The market will address the gap between Tomcat and WebLogic/WebSphere. Das stimmt, denn das stimmt ja auch jetzt schon. Nur dass sich zum Teil jeder seine eigene Lösung strickt. Man kann auch einen Tomcat so produktiv einsetzen wie den WebLogic.

Prediction 5: The gap between application servers and ESBs will be bridget. Naja, das ist noch ein langer Weg. Es ist zum Beispiel immer noch ein weiter Weg dahin, dass meine Plattform entscheidet, ob es jetzt aus Lastgründen einen lokal deployten Service nutzt oder den gleichen Service auf einer anderen Maschine. Aber solche Features wären für mich ein echter Fortschritt auch für den SOA-Gedanken. Und auf den SOA-Gedanken kommt Rod Johnson auch gerade, klar, der liegt bei dem Thema ja nahe und das Buzzword trägt immer noch.

Prediction 6: The Black knight will be defeated. Oder anders ausgedrückt: EJB ist dying. Jaja, das ist keine Prediction, das ist eine Beobachtung. Wer macht schon EJB, wenn er stattdessen Spring machen kann. Interessante Statistik wieder - in den USA sieht man das mit EJB offensichtlich (noch) etwas anders. Aber - die erste witzige Statistik - die Kurven für die Entwicklung von Java EE und Cobol gleichen sich wie ein Ei dem anderen. Beides Legacy-Techniken.

In der Conclusion gesteht Johnson ein, dass Java EE 6 die Relevanz von Java EE erhöht, aber dass Java nicht mehr die Zukunft bestimmen wird.

Auf zur nächsten Session.

JAX Eröffnung

2008-04-22T06:55:00.003Z

Tag 1 der JAX 08. Gestern war ich ja schon auf Tag 0, dem Agile Day vor der JAX. Sebastien Meyen -Chefredakteur bei S&S Media, dem Host der JAX - sagt es gerade, es waren ca. 400 Leute da. Jetzt erzählt er erst mal was über den aktuellen Kontext - welche Themen sind interessant (Architekturen, Agilität, Techniken), in welchem Marktumfeld sind wir hier alle unterwegs: Java EE, EJB 3, Alternative Stacks, Vom Web 2.0 zum Enterprise 2.0 und dynamische Sprachen und Scripting.

Sebastian Meyen geht gerade bei den dynamischen Sprachen vor allem auf Groovy ein. Ich persönlich finde das ja sehr nett, denn ich halte - auf der Java Plattform, die ja sehr gelungen ist - Groovy für die bessere Wahl als beispielsweise JRuby. Gut, aber das ist vermutlich der nächste Glaubenskrieg. Zusammengesetzt sieht Meyen folgenden Stack: Unten Java EE & Co., darüber eine "dynamischer" Layer von dynamischen Sprachen oder Rule Engines und darüber noch eine weitere Schicht von domain-specific languages.

Für das Eclipse Forum gibt's noch den Hinweis auf die Opening Session, in der auch der Weg zu Eclipse 4.0 dargestellt wird. Vielleicht sollte ich da noch hingehen? Ich kann mich doch nicht zerreißen.

Hey, interessante Frage von der Bühne: Wer war eigentlich letztes Jahr schon auf der JAX? Ich würde mal schätzen, dass sich so ungefähr ein Fünftel meldet. Und wer war vor zwei Jahren schon da? Überraschung: Die gleichen Leute. Mal sehen, ob ich nächstes Jahr eine von den beiden Fragen mit ja beantworten kann...

Gäääähn, jetzt werden die ganzen "großen und wichtigen Namen" genannt. Lesen kann ich selbst, steht doch alles im Programm. Schade, bis gerade war die Eröffnung doch ganz nett gemacht. Naja, gehört halt dazu...

Agiles Projektmanagement bei Werkverträgen

2008-04-21T15:04:00.003Z

Ok, es hat etwas gedauert, bis Dirk Sohn in Fahrt kam. Erst hat er sich mühevoll auf einen Life of Brian Witz hingearbeitet ("Ein Schuh"), der Vortrag drohte schon zäh zu werden. Aber kaum hatte er den Schuh umständlich erklärt fiel alle Zurückhaltung von ihm ab und er drehte richtig auf. Dieser Vortrag war definitiv der Höhepunkt. Humoristisch, aber auch inhaltlich.

Das Destillat der Projekterfahrungen, ich sage nur "bottom-up controlling" oder "ein Wiki ist es nicht", war ebenso informativ wie Dirk Sohns Ansichten zur Iteration 0, die - ich habe das auch schon erlebt - mitunter dogmatisch diskutiert wird.

Schön, dass Dirk Sohn am Ende seines Vortrags sogar noch auf die zu Beginn versprochenen Werkverträge kam. Aber eigentlich war das nur die Abrundung des Vortrags.

Product Owner - eine Herausforderung

2008-04-21T14:55:00.003Z

Das ganze Plenum voller Leute geschätzte zwei bis dreihundert und auf die Frage, ob jemand schon Product Owner ist oder noch werden will meldet sich kein einziger. Vielleicht geht es ja allen so wie mir... die Rolle "in Reinform" wird so wohl wirklich selten gelebt.

Aber immerhin - der Talk ist ein echtes Highlight. Urban Ernst beleuchtet seine Erfahrungen als Product Owner eines 20-Entwickler-Projekts. (Zwischendurch ist mir der Saft ausgegangen - also genauer meinem Notebook - so dass es kein Live-Blogging gibt.)

Ganz nebenbei räumt Urban Ernst noch mit einigen Lebenslügen agiler Entwicklung und insbesondere von Scrum auf: Projektteams organisieren sich nicht einfach so von selbst. Jaja, schon klar - das hat so auch nie jemand gesagt. Aber es ist gut, wenn zur Abwechslung mal wieder jemand darauf hinweist, wieviel Arbeit das in der Realität ist.

Ein reichliches Learning war die Sprint Goal Presentation und die Story Abnahmen, in denen der Product Owner die aktive Rolle übernimmt. Und auch ganz wichtig: Der Prozess läuft wesentlich runder, wenn Product Owner und Scrum Master das gleiche Verständnis vom Prozess haben und so in die gleiche Richtung ziehen.

Ich setze noch einen drauf: Es ist essentiell, dass alle im Projekt den gleichen Prozess leben. Nicht mit der gleichen Intensität, klar. Aber über kurz oder lang macht es das Team mürbe, wenn es verschiedene Vorstellungen des Prozesses gibt. Also noch mal: Schon die Vorstellung des Prozesses. Denn sonst wird das nie ein Prozess.

Kollaboration in IT-Projekten

2008-04-21T09:52:00.005Z

Dr. Georg Molter und Torben Knerr reden jetzt über Team Kollaboration in Java Projekten, stellen Herausforderungen und Anforderungen vor und zeigen dann Kollaborationswerkzeuge auf drei Leveln: Level 1 als Zusammenstellung von Open Source Tools, Level 2 als spezielle Kollaborationstools und Level 3 als in die IDE integrierte Kollaborationsplattformen.

Die Probleme räumlich verteilter Kollaboration sind ja hinlänglich bekannt - nicht nur aus der Softwareentwicklung. Die drei "bedeutsamen" von Molter und Knerr lassen sich eigentlich zusammendampfen auf "schlechte Kommunikation". Das führt dann beispielsweise zu unterschiedlichen Auffassungen der Requirements, zu intransparenter Planung und schwierigem Monitoring. Weitere Implikationen sind die verfügbaren Kommunikationsmittel (Telefon, Chat, Filesharing, Video-Conferencing) etc. inklusive der Performance dieser Kommunikationsmittel.

Voraussetzungen für den Erfolg einer räumlich verteilten kollaborativen Entwicklung sind eine einheitliche Begriffswelt, Prozesse und Tools (z.B. zur Versionsverwaltung, Verwaltung der Testfälle, etc.), ein gemeinsames Verständnis von den Work Items und den Requirements und die Unterstützung durch geeignete Tools zur Kollaboration. Viele "Disziplinen" sind (durch Tools) zu erfüllen, um eine gute Kollaborationsumgebung zu bieten.

Molter und Knerr schnappen sich nun einige der Tools und checken einfach mal durch, in wie weit diese die Disziplinen erfüllen. Die beruhigende Aussage vorweg: In der Java-Welt sind wir gar nicht so schlecht unterwegs. Ich erwarte mal, dass die Tools auf den unterschiedlichen Levels unterschiedlich gut geeignet sind. Die einzelnen Tools möchte ich hier jetzt nicht weitergeben, das war vor allem eine Slide Show mit Screenshots.

Der Talk war leider genau das - eine Slide Show von Screenshots mit einigen Allgemeinplätzen über Kollaboration im Allgemeinen. Ich hoffe auf den Nachmittag.

Einführung von agilen Prozessen

2008-04-21T08:51:00.003Z

"Wie wird man agil?" ist die Frage, an der sich Jutta Eckstein in ihrem Talk entlanghangelt. Interessante Frage, weil die Einführung doch immer wieder ein schwieriger Prozess ist. Im übrigen: Veränderung ist immer ein schwieriger Prozess, warum sollte die Veränderung zu einem agilen Vorgehen also leichter gehen. Nach der "klassischen" Unterscheidung in bottom-up und top-down (heißt hier "guerilla tactics" und "command and control", aber die Begriffe sind mir persönlich zu kriegerisch) konstatiert Jutta Eckstein, dass idealerweise alle am gleichen Strang ziehen - Managment, Kunde, Entwickler... Naja, wann passiert das in der Realität schon? In meiner jedenfalls nicht. Aber genau darum geht es ja Jutta Eckstein. Wie führt man agiles Vorgehen trotzdem erfolgreich ein?

Folgende Punkte sind demnach wichtig:
In einer Reihe von Retrospektiven sammelt man zuerst mal die Erfahrungen vergangener Projekte oder des aktuellen Projekts. Das Statement von Jutta Eckstein ist, dass als Ergebnis dieser Reflexion über das eigene Vorgehen und das gewünschte Vorgehen in der Regel etwas agiles hervorgeht.

Readiness / Enabling Workshops schaffen - meistens mit den Entscheidern, weniger mit den Entwicklern - das Verständnis und legen den Grundstein für das weitere Vorgehen. Wichtige Fragen dabei sind "Was machen wir schon?", "Was ist einfach umzusetzen?", "Was ist wirklich schwierig?" und "Was ist unmöglich?". Klar, raus kommt die Entscheidung, ob man überhaupt agil vorgehen kann und was man gegebenfalls noch zu tun hat.

Wenn man die Entscheidung hat, dann kann man loslegen. Hier kommt der Consultant durch - verkaufen, verkaufen, verkaufen. Mindestens hier kann man Schulungen verkaufen. Was sollte man aber zum loslegen machen? Training und Coaching sollte hier einfach die ersten Schritte begleiten, also einfach mal die ersten Iterationen planen etc. Gleichzeitig braucht man einen, wie Jutta Eckstein das ausdrückt, "Passionate change agent", also jemand, der mit Leidenschaft für die Einführung der Agilität einsteht. Ich fühle mich angesprochen.

Leider geht Jutta Eckstein nicht (direkt) darauf ein, wie man das Team dazu bringt, im Verlauf des Prozesses immer mehr Verantwortung von sich aus zu übernehmen. Sie sagt nur, dass der Erfolg der Einführung von drei Rollen entscheident abhängt: Dem project lead, dem passionate change agent und dem technical leader.

Um dauerhaften Erfolg zu haben, muss man den Spagat zwischen "Anfängern" auf der einen Seite und "Agilen" auf der anderen Seite schaffen. Geht nur mit Rezept für die Anfänger, auch wenn das der Agilität eigentlich widerspricht. Natürlich sind immer wiederkehrende Retrospektiven hilfreich, um die eigenen Erfahrungen zur reflektieren und den Prozess an die eigenen Bedürfnisse anzupassen. Wirklich hilfreich ist es natürlich, wenn der Leidenschaftliche im Laufe des Projekts auf die anderen Teammitglieder abfärbt.

Damit sind wir durch den Talk durch. Wenn ich jetzt mal eine Retrospektive mache, dann hoffe ich mal, dass das nur die erste Iteration im Projekt "Agile Day" war, denn bisher kamen für mich keine brandneuen Erkenntnisse durch. An den wirklichen Knackpunkten hat sich Jutta Eckstein - natürlich auch durch die Kürze der Zeit gebremst - ausgeschwiegen. Für mich sind die Knackpunkte auf diesem Feld nämlich die Unterstützung des agilen Prozesses durch die Entwickler auf der einen Seite (der Veränderungsprozess ist in der Regel doch extrem von einzelnen Personen abhängig) und durch die übrigen an einem Projekt beteiligten andererseits. Insbesondere Vertrieb, Mitarbeiter-Plaung und Controlling sehe ich da als interessante Faktoren: Der Vertieb meint, agiles Vorgehen schlechter verkaufen zu können als ein Festpreisprojekt. Für die Mitarbeitereinsatzplaung ist es nötig, nicht nur genaue "Schätzungen" abzugeben - die natürlich keiner als Schätzungen anerkennt, aber das ist ein anderes Thema - die Mitarbeiter machen ja in der Regel nicht nur dieses eine (agile) Projekt, sondern auch noch andere Projekte, und so weiter und so fort.
Das Controlling kann naturgemäß mit Agilität nur sehr schwer umgehen - wie soll man beispielsweise den Fertigstellungsgrad bei etwas messen, das einfach per Definition nie fertig ist, sondern sich ständig in einem Prozess der Änderung befindet.

Ich hoffe, der Tag erhellt noch ein paar von diesen Fragen. Die Titel klingen ja interessant.

Neues von der JAX 08

2008-04-21T08:46:00.002Z

So, es gibt mal wieder was neues in meinem Blog: Ich bin gerade auf der JAX, genauer auf dem Agile Day. Auf der Zugfahrt habe ich gerade noch den Tonabnehmer von Frank Westphal zum Thema gehört und dabei auch einige interessante Aspekte zu dem mittlerweile doch relativ "alten" Thema Agilität gehört, die sich auch mit meinem Erfahrungshorizont decken: Eine interessante Frage ist beispielsweise, wie man Agilität in das gesamte Unternehmen trägt, wie man agile Software-Entwicklung beispielsweise mit einem bestehenden Controlling integriert. Agiles Controlling, gibt's das? Mal sehen, was zu solchen Themen auf der JAX passiert.

web 3.0 ... kurzer Gedenkenstrom

2007-09-30T17:39:00.000Z

Nach dem Web 1.0 (mehr oder weniger statische Internetseiten) und dem Web 2.0 ("das Mitmachnetz") wird es Zeit für das Web 3.0, zumindest für die ersten Vorboten. Ich stelle einfach mal zusammen, was sich da so an Ideen findet.

Zunächst ist da das räumliche Web (spatial web). Mit Google Earth, Maps, aber auch mit rein virtuellen Räumen wie Second Life, World of Warcraft finden sich hier schon einige Systeme, die einen Vorgeschmack darauf bieten, was die Zukunft im Web - und außerhalb des Webs - bieten wird: Die Vermengung virtueller und realer Räume. Wir leben im "First Life" und sind daran gebunden, dass bestimmte Dinge an bestimmten Orten stattfinden: Wohnen, Arbeiten, Urlaub. Gerade bei der Urlaubsplanung ist Google Earth für viele schon ein echtes Werkzeug geworden. Und dann taggt man einfach seiner Bilder mit Geodaten (aufgenommen mit dem GPS-Empfänger) und schon kann man nachverfolgen, was wo war. Genauso kann man auch alles andere geotaggen - damit finden sich auch schon neben Google weitere Firmen, die Karten mit Bildmaterial und Tags verheiraten wollen.

Second Life war sicher zuerst ein Hype und ist jetzt mehr oder weniger uninteressant geworden, die Idee wird aber das räumliche Web beeinflussen: In 2D im Netz zu surfen ist mehr oder weniger unbefriedigend: Wir leben in einer dreidimensionalen Welt. Online-Shops werden in Zukunft die Waren dreidimensional präsentieren (manche faken das ja schon mit Quicktime VR), auf der letzten CeBIT gabe es 3D-Fernseher zu sehen - zusammen mit IPTV und Overlay-Ads eine tolle Vermarktungsquelle: Einfach den laufenden Film an der Stelle anhalten, wo der Hauptdarsteller diese tollen Klamotten anhat, draufklicken und direkt in den Shop kommen. Dort die Klamotten auf das eigene 3D-Modell ziehen... naja, das ist dann vielleicht Web 5.0 - oder so.

Der zweite Kandidat für's Web 3.0 ist das mobile Web. Immer schon verkündet glaube ich daran, dass der mobilen Kommunikation und insbesondere dem mobilen Webzugang die Zukunft gehört. Gerade zusammen mit dem räumlichen Web kann man sich so toll wirklich nützliche Anwendungen überlegen: Wo ist das nächste gute Restaurant: natürlich nach Web 2.0-Maßstäben von Nutzern empfohlen. Das interessiert mich selten dann, wenn ich wirklich am Rechner sitze. Die Kneipen und Restaurants in meiner Nähe kenne ich. Nein, meistens interessiert mich das, wenn ich unterwegs bin. Also schnell auf meiner PSP per öffentlichem W-Lan auf qype.

Für mich als alten KIler (KI = Künstliche Intelligenz) ist die dritte Zukunftslinie natürlich die spannenste: das semantische Netz. Dabei werden Web-Inhalte nicht einfach nur "konsumierbar" für Menschen produziert, sondern so, dass der Rechner auch etwas damit anfangen kann. Genauer: Ein sogenannter Inferenzmechanismus. Ok, zu tief für hier und jetzt, ein Beispiel muss her. Freebase baut auf der Basis von Wikipedia-Artikeln ein semantisches Wiki auf: Zu Städten steht da nicht nur jeweils ein netter Artikel. Jeder Artikel ist potentiell auch mit einem oder mehreren Typen zugeordnet (die man natürlich frei anlegen darf). Städte sind beispielsweise von folgenden Typen: Location (klar, Städte liegen irgendwo auf der Welt, siehe oben), City (Städte haben ganz besondere Eigenschaften, z.B. eine Einwohnerzahl zu einem bestimmten Zeitpunkt), gegebenenfalls noch ein paar mehr.
Eine Stadt liegt in einem Staat - und jetzt wird es interessant. Wo bei Wikipedia die Links alle gleich sind, da sind die Links bei Freebase auch typisiert. Es gibt also einen Linktyp "is contained" (ist enthalten). Eine Stadt ist enthalten in einem Staat. Eine Staat wiederum ist über den gleichen Linktyp enthalten in einem Staatenbund. Und Linktypen können wieder Eigenschaften haben. Zum Beispiel können sie transitiv sein. Hamburg ist beispielsweise in Deutschland, Deutschland in der EU. Also (!) liegt Hamburg auch in der EU. Und genau das ist der Clou. Kein Mensch muss das in irgendeinem Artikel explizit angeben, trotzdem kann man die Information direkt aus Freebase herausbekommen. Mit einer Anfrage bekommt man so beispielsweise alle Millionenstädte in Europa.

Ganz so einfach ist es leider nicht - die Anfragesprache ist eine Wissenschaft für sich. Klar, es geht. Aber schön wäre doch, wenn man irgendwie eine natürlichsprachliche Anfrage in diese komische Syntax automatisch überführen könnte. Das ist jetzt aber wieder Web 4.0.

Google Developer Day (Hamburg) - mein Fazit

2007-05-31T18:36:00.000Z

So, der Tag ist rum, die Sessions sind gelaufen, ich habe die neuen Building Blocks (Schlagwort des Tages) gesehen. Es ist Zeit für mein Fazit - und das ist sehr positiv.

Die Location ist gut - ohne Zweifel. Dann die nächste positive Überraschung: Die Organisation ist fantastisch, das WiFi funktioniert einfach, es geht mit Essen los. Und auch das Essen ist sehr gut. Dann gleich die erste negative Überraschung. Die Übertragung der Keynotes aus London hätte man sich einfach sparen können: Die Qualität des Videostreams ist nun mal nicht erste Sahne, die Inhalte sind kaum besser. Hatte ich ja schon geschrieben.

Der Rest des Tages ist eitel Sonnenschein: Die Referenten sind gut, kompetent, witzig. Die Sessions und Workshops hätten, das habe ich mehrfach gehört, anspruchsvoller sein können. Aber ich weiß, dass es eeeecht schwierig ist, das richtige Niveau zu finden. Und ich glaube, dass es schon wirklich gut geklappt hat.

Über die einzelnen Sessions hatte ich schon gebloggt. Das möchte ich hier nicht noch mal tun. Insgesamt fand ich sie alle von Inhalt und Form sehr unterschiedlich und sehr gut.

Zum Ende noch mal - das Essen war gut (keine Ahnung, ob das Filet vom Mittag oder die Spieße vom Abend besser waren, aber für mich als Schleckermaul war die Creme brulee der Hit).

Also, auf ein Neues. Ich freue mich schon auf den nächsten Google Developer Day. Dann sehen wir uns hier wieder unter dem Tag GDD08.

Wrap up

2007-05-31T16:30:00.000Z

Beim Wrap-up hat Andreas Gebhard über Deepa Mehta geredet. Ok, Semantische Netze sind nicht neu, aber wenn er bei Google reden darf, dann muss es ja cool sein. Gedacht, getan: Gegoogelt nach DeepaMehta, gefunden (www.deepamehta.de), ausprobiert und angeschmiert: "The DeepaMehta server at www.deepamehta.de:7557 isn't running" :(

argh...

2007-05-31T16:18:00.000Z

Doch die falsche Session gewählt. Im Maps Workshop gab's - ich glaube für erfolgreiche Implementierungen - eine 3D Maus. 3D Maus ! Cool. Groovy. Und ich war nicht dabei.

Earth, KML und firstlife.com

2007-05-31T16:06:00.000Z

Gerade bei Joachim in der Earth- und KML-Session gewesen. War sehr interessant, allerdings war ich etwas zu spät und deswegen schon wieder steckdosenlos. Deswegen nicht live, sondern hinterher gebloggt: Was man mit KML, Maps und Earth so machen kann ist schon jetzt beeindruckend. Wenn man mal in die Zukunft blicken mag - Earth ist ja so alt noch nicht - gibt es schon noch einige Punkte. Network Links, also die Möglichkeit, Geodaten dynamisch nachzuladen, sind jetzt der Anfang. Meine Frage nach Dynamic-KML, also KML mit JavaScript, das im Browser (aka Earth) ausgeführt wird, führt naturgegebenermaßen nicht zu einer befriedigenden Antwort. Joachims veröffentlichte Meinung dazu ist, dass Earth eher schlanker werden soll und eher in den Browser integriert wird als dass es mit noch mehr Funktionalität angereichert wird.

So, jetzt werden hier um mich herum schon die Stuhlreihen abgebaut, damit die Party gleich steigen kann.

Peeks aus der GData Session

2007-05-31T14:25:00.000Z

Frank Mantek redet hier über GData - die Google API zum Zugriff auf diverse Services, z.B. Calendar, Blogger, Picasaweb etc. Nach dem Überblick über das optimistic locking per Versionierung und Authentication. Es gibt diverse Client Libraries - in Java mit Support von Google, in Ruby und - dadahh - LISP ist es eine contributed lib, also von irgendwem. Aber es gibt sie.

Ok, jetzt redet Frank gerade über die verschiedenen Zielsysteme. Kommt mir gerade eine Geschäftsidee? Hm, nein, nicht hier und nicht jetzt - und wenn, dann blogge ich das hier nicht ;) Ansonsten sind die Übersichten eher öde. Aber gut, was will man auch über eine API alleine sagen? Das hat Frank schon ganz am Anfang der Session gesagt.

Aus der Liste der Beispiele ragt der "Phixr Online Photo Editor" raus. Muss ich mal ausprobieren. Schön zu sehen, dass Google mit REST gute Erfahrung gemacht hat und dafür das Atom-Protokoll in der dort vorgesehenen Weise erweitert hat. Der klare Vorteil von REST ist - wer hät's gedacht - die Einfachheit. SOAP ist - gerade in der vollen Ausbaustufe - die ideale Möglichkeit, sich in den Fuß zu schießen. Kleiner Exkurs: Unser über https (Client Zertifikat, Server Zertifikat) und WebService Security gesicherter Service hat jedenfalls ordentlich weh getan. Spaß ist was anderes.

Schön zu sehen ist die Folie "Care for your Developers": Protocol Centric & Language Agnostic; Open your Code; Give Fair Warnings of Changes; Meet your Developers. Stimmt. Das letzte macht Google ja heute und das machen sie gut.

Von Maplets zu Gadgets

2007-05-31T13:12:00.001Z

Again... Nachdem ich gerade schon von Maplets gehört habe, höre ich mir jetzt Douwe Osinga an, der über Gadgets redet.

Erst mal: Was sind Gadgets - naja, kleine html/script-Snipplets, die man auf seiner eigenen Homepage, auf iGoogle, im Dashboard, in der Sidebar oder eben irgendwo laufen lassen kann. Sogar im IBM WebSphere Portal ;) Ob Stephan Uhrenbacher das Qype Gadget schon am Start hat? Ich sehe jedenfalls nur die Qype*Vibes hier.

Ein Gadget kann man mit User Preferences (auch hidden) konfigurieren. Dabei gibt es allerlei vorgefertigte Elemente (checkboxes, lists) etc. Dazu kommt dann noch der html- und script-Block im Content und mit beidem zusammen kann man auf dem Gadget Scratchpad in kürzester Zeit sein erstes Gadget bauen. Douwe geht schnell durch so ein paar Sachen durch, die man in seinem Gadget gerne haben möchte: Maps, Google Analytics, Remote Content (z.B. RSS/Atom feeds).

Das ganze ist nicht so hands-on wie die Google Maps API Session von Steffen Meschkat gerade eben, aber auch ganz interessant. Oder vielleicht zu hands-on: Wenn das scratchpad erst mal voll mit JavaScript-Code ist, dann ist das doch ein bisschen viel auf einmal. Aber immerhin: Douwe macht das launig.

Schön ist der Hinweis, dass es in Europa wohl nicht so wichtig ist, die Bedeutung von Internationalisierung zu betonen. Amerika, kannst Du uns hören? Hm, wohl nicht... ;) Auf jeden Fall: Es gibt message bundles, in denen man die Texte ablegen kann. Kennen wir ja aus Java. Hier ist es halt in XML.

Gadgets können auch states speichern. Dazu kann man ein Preference-Item als "hidden" markieren und darin den Zustand speichern. Gadgets können auch externe Ressourcen cachen - die werden dann einfach auf die Google-Server repliziert.

Die Punkte: "Add to Google Button", "Promote your Gadget" etc. überspringen wir mal. Top Gadget Authros findet man jedenfalls unter http://www.google.com/ig/authors. Der Preis für das beste Gadget (hier auf dem Developer Day) ausgelobt ist ein Mittagessen mit Douwe. Hm. Will ich das? Douwe selbst preist an, dass man es für sich selbst machen sollte, "because it's cool".

Mal sehen, wann ich mein erstes Gadget schreibe. Wenn, dann mach ich das wohl zuerst mal, weil ich's für mein Dashboard mag. Ups, gerade noch was nettes gesehen, als ich einen Link für diesen Eintrag gesucht habe: Der Google Mashup Editor. Muss ich nachher mal einen Blick drauf werfen oder sehen, wen ich dazu ausquetschen kann.

Google Maps API

2007-05-31T12:21:00.000Z

Jetzt bin ich in der Google Maps API Session. Steffen Meschkat erzählt uns hier was über die alten und neuen Features in Maps. Zu den neuen gehören u.a. AdSense für Maps.

Schick, die Slides sind in HTML (gut gemacht), dadurch kann Steffen direkt Maps-Element vorführen. Noch ist es einfach, er fängt mit einem "Hello World!" an, indem er in erst mal (gaaanz kurz) zeigt, wie er einen Text in eine Bubble steckt.

Schön: Er geht gleich auf essentielle Fragen ein, die sich direkt an diesem einfachen Beispiel stellen: Wie kann ich einen (von vielen) Markern nach vorne holen? Antwort: Gar nicht. Der Marker ist eigentlich nur ein Punkt. Der Marker steht eigentlich senkrecht auf der Karte, in der 2.5-D Darstellung werden nördlichere durch südlichere Marker überdeckt.

Schick auch die Folie mit dem integrierten Editor: Steffen hat sich eine kleine JavaScript-Konsole in die Map geklebt, mit der er hier direkt in der Session Beispiele laufen lassen kann.

Und wieder was gelernt: Es gibt "Implementierungs-Artefakte". Hier "draggable". Erst macht man einen Marker "draggable: true", danach muss man ihn noch mit "enableDragging()" wirklich drag&drop-bar machen.

Weiter zu ascynchronous continuation: hier gibt man bei einer Serveranfrage die Funktion mit, die die Antwort verarbeitet. Der Grund dafür: JavaScript läuft im Browser in einem einzigen Thread - warten auf die Antwort ist also nicht drin.

Hach, wie mag ich es, LISP zu können. Funktionen hin- und herzuschubsen ist doch das normalste der Welt ;)

Witziger Einwurf am Rande: KML ist von Computer-Grafikern. Klar, Koordinaten sind x, y. Maps ist von Geographen, in der API sind Koordinaten also latitude, longitude. Schön, dass beides irgendwie verständlich ist, zusammen aber irgendwie gemurkst wirkt.

Hach, nochmal. Ich mag LISP - jetzt erklärt Steffen hier erst mal Closures. Gähn ;)

Spannend: Jetzt erklärt Steffen gerade, wie die Maps Entwickler die Sicherheitsmechanismen von JavaScript "ausgehebelt" haben. Ich fass mal kurz zusammen: Es wird ein JSNOP script aufgerufen, das selbst ein callback enthält.

Auch spannend: Peformance. Erstens läuft die Browser UI und das javascript in einem einzigen Thread. Zweitens sind DOM Operationen langsam.

Aus Performance-Gründen werden über den GMarkerManager nur die Marker wirklich in den DOM-Tree eingefügt, die auch (in dem Ausschnitt, in dem Zoom-Level) zu sehen sind.
Man sollte außerdem lange Sequenzen in Blöcke unterteilen, weil ... ups, hier bricht die Erklärung einfach ab. Schade.

Über die DrivinDirectionsAPI kann man sich, beispielsweise in einer seperaten Pane innerhalb des Maps-divs, Routeninformationen anzeigen lassen.

Und weiter im Text. Maplets sind die Basis für weitere Mesh-ups. Zur Zeit liegt das auf http://maps.google.com/preview. Zusammengeworfen werden da die Google Gadgets API (iframe mit html und javascript, remote data Zugriff, Speicherung von Benutzer-Präfs) und Google Maps API (overlays, event-listener).

Jetzt läuft uns leider die Zeit davon, wir gehen trotzdem noch mal schnell in den Code, d.h. in das XML-File, in dem das Maplet definiert wird. In den Modul-Präfss gibt es in den Inhalt . Im steht dann der html und script-Content, der im Maplet-iframe landet. Sieht eigentlich einfach aus. Mal sehen, ob sich das in der realen Welt auch so darstellt. Interessant ist auch das Herstellen von Sicherheit einerseits (Verhinderung von Cross-Side-Scripting, XSS) und das Umgehen von Sicherheitsmechanismen andererseits (Kommunikation zwischen Script-Teilen von maps.google.com und gmodules.com).

Damit genug von hier, auf zur nächsten Session. Aber festzuhalten: Gute Session.

Wrap up der Keynote in 7 Minuten ;)

2007-05-31T11:52:00.000Z

Ha, nicht aufgepasst, stattdessen gebloggt etc. und - richtig gemacht: Joachim gibt gerade die
Zusammenfassung der Londoner Keynotes - verdichtet, besser, mit anderen Schwerpunkten, z.B. deutlich mehr Gears. Schön.

Nachricht von der Keynote

2007-05-31T11:29:00.000Z

Hier bin ich - beim Google Developer Day. Nach dem leckeren Essen ("Essen ist wichtig bei Google", Karl Krainer) hatte ich schon die ersten netten Kontakte - mit den Jungs von atoolo.com oder mit Patrick und Joachim von Google.

Jetzt sitze ich hier zwischen den beiden einzigen Frauen im Auditorium der Keynote (eine davon ist meine Frau :) ). Die deutsche Keynote war schon sehr nett und kann es fast mit dem Essen aufnehmen. Stephan Uhrenbacher stellt seine Company Qype vor - Early Adaptor von Maps. Die Vorstellung der Speaker von heute ist noch ganz kurzweilig, danach hat die Veranstaltung schon den ersten Tiefpunkt... Chris DiBona erzählt sehr langweilig in eher schlechter Videoübertragung öde Dinge über diverse Entwicklungen bei Google. Das ganze gleicht einem Rundumschlag durch den Buzzword-Dschungle mit diversen Plattitüden dazwischen.

Überhaupt ist die Übertragung aus London nicht soooo faszinierend. Vielleicht schnacke ich doch ein bisschen mit meinen Nachbarinnen und freue mich auf die Live-Sessions nachher.

Google Developer Day

2007-05-25T18:25:00.000Z

Moin, moin!

Nächste Woche ist Google Developer Day in Hamburg - und ich bin dabei. Man darf gespannt sein.

Meine persönlichen Favoriten sind ja die Gadget-Themen. Mal sehen, wann ich mein erstes eigenes Gadget schreibe. Bisher war ich ja auf mehr auf Web-Applikationen aus. Generell ist das glaube ich auch einfach eine gute Gelegenheit, neue (nette, interessante) Leute kennen zu lernen und auch alte Bekannte wieder zu sehen.

Noch bleiben viele Fragen offen: Wer hält die Talks? Kann man in der Kürze der Zeit wirklich tiefschürfendes erfahren? Gibt's Sofas für die Teepause? Wer hat gesagt, dass es immer Kaffepause heißen muss?

Lookin' forward :)

Chris