Mann, Pro Sieben hats echt drauf. Die schaffen es, aus rein gar nichts drei Stunden Show zu erzeugen. Gestern Abend lief “Uri Geller live - Ufos & Aliens: Das unglaubliche TV-Experiment”. Unglaublich war daran zumindest mal, mit welcher Gewissenlosigkeit Pro Sieben hier Deppenfernsehen par excellence fabriziert hat.

Uri Geller ist auch einer meiner absoluten Lieblinge! Ich beschäftige mich hobbymäßig auch mit Zauberkunststücken wie Karten- oder Münztricks. In Magierkreisen ist Uri Geller stark umstritten, weil er den Leuten glauben macht, er könnte “wirklich” per Geisteskraft Löffel verbiegen. Magier sehen sich aber eher als “Künstler” im Kontext von Jongleuren oder Artisten: dem Publikum ist es immer klar, dass es sich um Tricks handelt und der Zauberkünstler einfach “nur” eine hohe Geschicklichkeit anwendet, um einen Effekt zu erzielen. Mit Esoterik, Wundern oder Aliens hat das rein gar nichts zu tun. Das würde im Gegenteil den Effekt deutlich schmälern.

Dass Uri Geller von sich glauben machen will, er könnte wirklich Uhren in der ganzen Republik per Gedankenkraft wieder ans Laufen bekommen ist absurd. Ich sage es mal so: das Löffelverbiegen ist in Profikreisen ein alter Hut und überhaupt nichts Besonderes mehr. Dafür gibts mittlerweile Lern-DVDs.

Das wird dann aber wieder durch breite Masse kompensiert. Wenn man einen TV-Aufruf startet, dass man bitte anrufen soll, wenn eine Uhr wieder läuft, dann kommen natürlich Anrufe, dass es wirklich klappt! Würde man den Leuten sagen, dass sie anrufen sollen, falls bei ihnen ein lila Nilpferd aus dem Fernseher hüpft und auf dem Wohnzimmertisch Rumba tanzt - auch dann würden Anrufe kommen! Solange die Samplemenge groß genug ist, gibt es immer ein paar Leute mit derben Aussetzern darunter.

Womit wir wieder bei der Show von gestern Abend wären. Nina Hagen wird auch immer seltsamer, bei ihr hat man ständig das Gefühl, dass irgendwann mal ein LSD-Trip schiefgelaufen ist. Die beste Aussage von ihr war noch “ich denke gar nichts”, was der Wahrheit wohl ziemlich nahe kommt. Lustig war dann auch der geflüsterte Einwuf von Johanna Klum an den Moderator: “Ich glaube jetzt denkt sie grade wieder nichts”, als Nina Hagen ohne Inhalt vor sich hin blubberte.

Toll war auch der Auftritt von “Vincent Raven”, der auch einfach nichts tat, außer da zu sein. Es klingt unglaublich, aber er hat wirklich rein gar keinen Content beigetragen - von einigen grausamen Stammeleien (auf zugegebenermaßen völlig abstruse Fragen) abgesehen.

Die Schaltungen in die Ukraine waren dann nur noch das Sahnehäubchen. In übel gestellten Szenen, unterlegt mit künstlichen “Störgeräuschen” wurde von “unerklärlichen Problemen beim Versenden der E-Mails” gesprochen. Lag wohl daran, dass die Ukrainer ihre Anlagen nicht gut genug warten, weil zu wenig Geld mit schwachsinnigen TV-Shows hereinkommt.

Hat man bei “Popstars”, “DSDS” und den ganzen unsäglichen Talkshows immer einige kurze Momente des Fremdschämens, so ist das hier über drei Stunden konstant aufrecht erhalten worden. Falls es wirklich da draußen Aliens gibt, die Leute entführen: BITTE das nächste mal Uri Geller und das Pro Sieben-Management abholen! Und auf keinen Fall mehr wieder bringen!

Dabei ist es nicht schlimm, dass so ein Müll produziert wird, schlimm ist aber, dass mit solchen “pseuo-ernstgemeinten” Machwerken eine vernünftige Auseinandersetzung mit diesen Themen völlig durch den Kakao gezogen wird und eine richtige Diskussion gar nicht mehr möglich ist. Jeder Zauber-Artist da draußen sollte sich von Leuten wie Uri Geller beleidigt fühlen und jeder ernsthafte SETI-Forscher sollte sich von Pro Sieben beleidigt fühlen.

Für diejenigen, die sich wirklich mit Mentalismus (Tricks!) auseinandersetzen möchten, empfehle ich aber den Klassiker Practical Mental Magic. SETI-Interessierte sollten sich einmal mit dem sehr guten Buch Beyond Contact beschäftigen, das die wissenschaftlichen Grundlagen des SETI-Programms beschreibt und eine populärwissenschaftliche Einführung in die unterliegende Signaltheorie enthält.

Alle anderen: viel Spaß mit der Alu-Pyramide auf dem Kopf.

Wir freuen uns, Ihnen mitteilen zu können, dass die gewünschten Artikel jetzt bei Amazon.de bestellt werden können!

Guns ‘n Roses: Chinese Democracy

Verfügbarkeit: Dieser Artikel wird am 21. November 2008 erscheinen. Bestellen Sie jetzt!

Ok, morgen werde ich mal vorsichtig die Konsistenz des Universums checken. Mal sehen. Auf jeden Fall wirds teuer für Dr. Pepper.

So we finally have a complete LinuxTag color scheme along with the scales of blue and yellow:

We’re now working on the basic visuals for ads, posters and flyers.

One key momentum that we thought about was “what are the motivations that brings people to LinuxTag?”. What does the common visitor expect when attending the show? We isolated three main points on this:

1. Networking
   A lot of people attend LinuxTag to see all those guys from the FOSS world that they see frequently at events like this. To get in touch, to work together in person is an important aspect of LinuxTag. Each year, we have requests for rooms from development teams where they can gather to discuss topics they can’t properly address by e-mail. It is not uncommon that these people meet up for the first time in real life on LinuxTag.
   On the other side, many people come to the show to improve their business network. I do not exaggerate by arguing that LinuxTag is the European Open Source business event. If you want to do business in the FOSS field, you have to be there.
2. Knowledge
   We know from our yearly surveys that many people come to LinuxTag to hear conference talks. There was a time we underestimated the marketing value of the conference, but this was plain wrong: the conference is the main attraction of LinuxTag. All other parts are there only to support the conference, plain and simple. We want to provide world class know-how presented by world class speakers each and every year. This is the key point of the whole LinuxTag endeavour.
3. Lifestyle
   LinuxTag is part of the FOSS community. The geekdom is becoming more and more sexy and more and more people want to be part of it. LinuxTag brings this unique feeling that no other conference has. Try to get that fine sense of completeness, of technology insight paired with the deep friendlyness of the Open Source principle on your common IBM marketing sell-me-your-stuff event. And there is more: be part of it! Nowhere else it is so easy to talk to the FOSS people and contributing to the pool of ideas, concepts and - finally - software. Be there and be part of it!
   And, if you’re out on your business, there is no place like LinuxTag to find excellent staff for your technology venture because these people are attracted by the unique lifestyle LinuxTag has to offer. If you really want to find the knowers, be at LinuxTag.

So we have these three key spots of motivation that drives LinuxTag. We now have to package them into a concise marketing message, transform it to a nice presentation and there we go..

Marko hatte mich vor einiger Zeit schonmal auf Elisa aufmerksam gemacht. Sieht sehr vielversprechend aus und könnte eine echte Alternative zum doch recht spröden MMS sein. Das wird mein nächstes Wochenendprojekt…prinzipiell sollte aber auf der S100 auch XBMC laufen, schließlich hat die XBox 1 auch nur 64 MB RAM. Dazu müsste aber auf der S100 zunächst mal zwingend OpenGL funktionieren - und zwar über den TV-Out…und da bin ich im Moment etwas skeptisch.

Achso: mein Artikel “10 Gebote für erfolgreiches BPM” aus der Computerwoche gibts jetzt auch als offizielles PDF zum herunterladen.

Maven mit Eclipse für JEE-Projekte zusammenzubringen ist nicht so ganz einfach. Deswegen hier eine kleine How-To.

Seltsamerweise existieren im Netz keine wirklich verwendbaren
“Kochrezepte” dafür, obwohl es sich aus meiner Sicht um ein
“Standardproblem” handelt.

Ziel ist es, die Vorzüge von Eclipse bei der Entwicklung von JEE-Modulen
zu nutzen (Hotdeployment, Servermanagement, Debugging usw.) und
gleichzeitig die volle Buildfähigkeit über Maven zu erhalten.

Dazu muss man grundlegend einen anderen Weg gehen, als das bei
JSE-Projekten der Fall ist: statt ein Projekt zunächst auf der
Maven-Ebene aufzubauen und dann von Maven die Eclipse-Settings über “mvn
eclipse:eclipse” erzeugen zu lassen, muss ein JEE-Projekt von Eclipse
her aufgebaut werden. Maven ist deutlich flexibler anpassbar als die
JEE-Eclipse-Plugins.

Schritt 1: Eclipse JEE-Projekte anlegen

Über die ganz normalen Wizards wird ein JEE-Projekt mit allen
Untermodulen angelegt. Für das Beispiel gehe ich von folgenden einzelnen
Eclipse-Projekten aus:

• DemoEJB
  Projekt, das die EJBs enthält. Hier werden (abweichend vom Eclipse-Standard) später auch die Domain-Klassen und die Remote-Stubs der EJB abgelegt. Maven erzeugt beim Releasebuild automatisch ein abgespecktes Client-JAR, dass nur die vom Client benötigten Klassen enthält. Während des Eclipse-Workflows werden die Klassen dieses Moduls vollständig mit dem Client deployt, liegen also zweimal physikalisch auf dem Server, falls der Client eine JEE-Serveranwendung wie z.B. ein WAR ist. (einmal beim EJB, einmal beim Client). Das ist verschmerzbar, stört nicht und ist durch die Eclipse-Governance auch sicher konsistent.
• DemoServlet
  Der Client für die EJBs in Form einer JEE-Weblayer-Anwendung. Hier sind Standard-Servlets und/oder JSPs enthalten, die über JNDI auf die EJBs zugreifen. Externe Clients sind ebenfalls möglich, aber der JEE-Client ist der in diesem Fall komplexere Fall, weil das WAR ebenfalls deployt werden muss.
• DemoEAR
  Das umgebende EAR-Projekt, dass aus dem EJB und dem WAR des Clients ein deploybares EAR-Archiv erzeugt. Da Maven kein gemeinsames Artefakt- und POM-Multiprojekt erlaubt, ist das EAR-Projekt ebenfalls ein Maven-Subprojekt.

Beim Erstellen der Projekte muss auf die Projektabhängigkeit geachtet
und ggf. angepasst werden. Eclipse geht im Standardfall davon aus, dass
Domainklassen und Stub-Interfaces im Client angesiedelt sind. Maven
erwartet diese Klassen aber im Serverprojekt und generiert lieber daraus
ein getrenntes Client-JAR für den Client mit diesen Klassen. Aus meiner
Sicht sauberer und Eclipse auch einfach beibringbar ist der Maven-Weg.
Dazu müssen die Abhängigkeiten folgendermaßen eingestellt sein:

   DemoEAR     --hat Abhängigkeit--> (DemoEJB, DemoServlet).

   DemoServlet --hat Abhängigkeit--> (DemoEJB).

   DemoEJB hat keine definierten Abhängigkeiten.

Sind die Abhängigkeiten eingestellt müssen nun die Pfade “Maven-like”
angepasst werden. Dazu müssen die Java-Sources von den restlichen
Resources getrennt und im üblichen Verzeichnisschema angeordnet werden.
Dies ist über die Projekt-Properties unter “Java Build Path -> Source”
zu erledigen.

Mit der jetzt vorliegenden Einstellung kann dann ein Deployment-Server
definiert werden und das Projekt über Eclipse normal genutzt werden.
Hot-Deployment und Debugging funktioniert direkt aus Eclipse heraus.

Als nächstes müssen die Maven-Einstellungen hinzugefügt werden, damit
das Gesamtprojekt per Maven bau- und deploybar wird.

Schritt 2: Maven-Konfiguration

Die Verzeichnisstruktur in Eclipse sieht im Moment folgendermaßen aus:

    - workspace
      + DemoEAR
      + DemoEJB
      + DemoServlet

Für die Maven-Konfiguration legen wir ein Hüllprojekt um die drei
Einzelprojekte. Dieses Hüllprojekt ist für Eclipse nicht notwendig und
nur für die “Projektklammer” des Multi-Projekts für Maven nötig. Aus
diesem Grund wird dieses Hüllprojekt am besten von Hand angelegt und
über die Kommandozeilentools ins SVN eingecheckt.

Für die Entwicklung bedeutet das, dass das Arbeiten und Bauen mit Maven
und Eclipse leicht unterschiedlich erfolgt. Die Zielverzeichnis bzw.
Projektstruktur sieht so aus:

    - DemoJEE
      + DemoEAR
      + DemoEJB
      + DemoServlet
      pom.xml

In Eclipse wird dann nicht das Hüllprojekt ausgecheckt und genutzt,
sondern nur die drei Subprojekte. Die Einstellungen des Hüllprojekts
sind nur für einen Maven-Build nötig. In diesem Fall wird das
Gesamtprojekt ausgecheckt und per “mvn package” das resultierende
EAR-Archiv im Subprojekt “DemoEAR” gebaut.

POM des Hüllprojekts

Die POM des Hüllprojekts ist recht simpel. Sie besteht aus einem
einfachen Multi-POM mit zusätzlichen Repository-Einstellungen:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>de.tarent</groupId>
  <version>1.0-SNAPSHOT</version>
  <artifactId>DemoJEE</artifactId>
  <packaging>pom</packaging>
  <name>project</name>
  <modules>
    <module>DemoEJB</module>
    <module>DemoServlet</module>
    <module>DemoEAR</module>
  </modules>
  <repositories>
    <repository>
      <id>jboss-repository</id>
      <name>jboss repository</name>
      <url>http://repository.jboss.com/maven2/</url>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
    </repository>
  </repositories>
</project>

Das JBoss-Repository ist für die Abhängigkeiten zu den JEE-Bibliotheken
nötig, die in den Subprojekten definiert sind. Das Projekt wird damit
gegen die JEE-JBoss-Implementierung gebaut. Das bedeutet explizit nicht,
dass die resultierenden JEE-Module nicht in anderen Appservern laufen,
die Bibliotheken werden als “provided” dort vorausgesetzt und nicht mit
gepackaged. JBoss bietet eine zertifizierte JEE 1.5-Implementierung.
Trotzdem sollten wir uns dafür im nicht-JBoss-Fall noch ein paar
Gedanken zur QS machen, das nur am Rande.

POM von DemoEJB

Das DemoEJB-Projekt ist ein einfaches Maven-Projekt, dass das EJB-Plugin
verwendet, um ein EJB-Jar zu erstellen.

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>de.tarent.DemoJEE</groupId>
  <artifactId>DemoEJB</artifactId>
  <packaging>ejb</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>enterprise java bean</name>
  <parent>
    <groupId>de.tarent</groupId>
    <artifactId>DemoJEE</artifactId>
    <version>1.0-SNAPSHOT</version>
  </parent>
  <build>
    <sourceDirectory>src/main/java</sourceDirectory>
    <plugins>
      <plugin>
        <artifactId>maven-ejb-plugin</artifactId>
        <configuration>
          <archive>
            <manifest>
              <addClasspath>true</addClasspath>
            </manifest>
          </archive>
          <ejbVersion>3.0</ejbVersion>
          <generateClient>true</generateClient>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.6</source>
          <target>1.6</target>
        </configuration>
      </plugin>
    </plugins>
  </build>
  <dependencies>
    <dependency>
      <groupId>javax.persistence</groupId>
      <artifactId>persistence-api</artifactId>
      <version>1.0</version>
      <scope>provided</scope>
    </dependency>
   <dependency>
      <groupId>javax.ejb</groupId>
      <artifactId>ejb-api</artifactId>
      <version>3.0</version>
      <scope>provided</scope>
    </dependency>
  </dependencies>
</project>

Falls weitere JEE-Abhängigkeiten benötigt werden, können diese hier
hinzugefügt werden. Als Parent wird das Hüllprojekt angegeben. Die
JBoss-Repository-Definitionen werden von dort geerbt.

Die “generateClient”-Einstellung sorgt dafür, dass ein zusätzliches
“virtuelle” Artefakt erstellt und dem virtuellen Repository hinzugefügt
wird. Auf dieses referenzieren wir dann später in den Abhängigkeiten des
Clients. Dieses spezielle Client-JAR enthält nur die Entities und die
Stubs. In der Konfiguration kann über weitere Parameter noch genauer
angegeben werden, welche Bestandteile des EJB-Codes in den Client
gepackaged werden. Genauere Infos dazu sind in der Plugin-Dokumentation
zu finden.

POM des Clients

Das Client-Projekt “DemoServlet” ist ein Standard-WAR-Projekt, dass aber
zusätzlich eine Abhängigkeit zur zuvor erstellen “virtuellen”
Client-Bibliothek enthält:

    ...
    <dependency>
      <groupId>de.tarent.DemoJEE</groupId>
      <artifactId>DemoEJB</artifactId>
      <version>1.0-SNAPSHOT</version>
      <type>ejb-client</type>
    </dependency>
    ...

Statt “ejb” wird “ejb-client” als Typ angegeben. Würde “ejb” angegeben,
so würde der gesamte Code des EJB-Projektes im resultierenden WAR
mitgepackaged werden.

POM des EAR-Projekts

Das EAR-Projekt baut aus den vorhandenen Artefakten das EAR zusammen und
deployt es optional auch direkt in einem JBoss-Server. Das EAR-Projekt
enthält selbst keinen Quellcode dafür aber die EAR-Deployment-Deskriptoren.

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>de.tarent.DemoJEE</groupId>
  <artifactId>DemoEAR</artifactId>
  <packaging>ear</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>ear assembly</name>
  <dependencies>
    <dependency>
      <groupId>de.tarent.DemoJEE</groupId>
      <artifactId>DemoEJB</artifactId>
      <type>ejb</type>
      <version>1.0-SNAPSHOT</version>
    </dependency>
    <dependency>
      <groupId>de.tarent.DemoJEE</groupId>
      <artifactId>DemoServlet</artifactId>
      <type>war</type>
      <version>1.0-SNAPSHOT</version>
    </dependency>
  </dependencies>
  <build>
<plugins>
      <plugin>
        <artifactId>maven-ear-plugin</artifactId>
        <configuration>
<applicationXml>${artifactId}/EarContent/META-INF/application.xml</applicationXml>
          <defaultLibBundleDir>lib</defaultLibBundleDir>
          <archive>
            <manifest>
              <addClasspath>true</addClasspath>
            </manifest>
          </archive>
          <modules>
            <ejbModule>
              <groupId>de.tarent.JEEDemo</groupId>
              <artifactId>DemoEJB</artifactId>
              <bundleFileName>DemoEJB.jar</bundleFileName>
            </ejbModule>
            <webModule>
              <groupId>de.tarent.JEEDemo</groupId>
              <artifactId>DemoServlet</artifactId>
              <contextRoot>/DemoServlet</contextRoot>
              <bundleFileName>DemoServlet.war</bundleFileName>
            </webModule>
	  </modules>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>jboss-maven-plugin</artifactId>
        <configuration>
        <jbossHome>/home/kleinhenz/Bibliothek/jboss-4.2.3.GA</jbossHome>
          <port>8080</port>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

Problematisch ist die Einstellung des JBoss-Homedirs. Diese Einstellung
ist im Moment leider nicht extern einstellbar. Allerdings ist die
Nutzung des JBoss-Plugins nur nötig, wenn direkt aus Maven heraus
deployt werden soll.

Bauen und Deployen

Damit ist die Konfiguration insgesamt fertig. Unter Eclipse lassen sich
die Projekte normal mit den Eclipse-Bordmitteln nutzen. Will man einen
Maven-Build vornehmen, so wird das Hüllprojekt ausgecheckt und mit “mvn
package” das Projekt gebaut. Nach dem Vorgang liegt im EAR-Projekt das
fertige EAR-Archiv.

Miss Jolie nimmt man dabei auch die harte Schlägerbraut nicht so richtig ab. Was in Tomb Raider noch ganz gut geklappt hat ist hier teilweise schon an der Grenze zur Lächerlichkeit. Angelina Jolie ist dermaßen dürr und sieht krank aus, dass man ihr am liebsten die ganze Zeit einen Schokoriegel reichen würde.