Im Informatikstudium bekommt man Abstraktion beigebracht. Man lernt, große Dinge in seine Bestandteile aufzulösen und dann einzeln anzugehen. Das beginnt mit Trivialem wie Quicksort und endet bei der Model Driven Architecture. Und das ist auch gut so. Die Abstraktion ist ganz klar eines der wichtigsten Werkzeuge der modernen Informatik und der modernen Systementwicklung. Was einem allerdings nicht beigebracht wird, ist Maß damit zu halten.

Im Seminarraum meiner damaligen Arbeitsgruppe hing ein handgeschriebenes und ausgeblichenes Schild. Auf dem Stand “Fünf Stunden Perl programmieren ersetzt eine Stunde Nachdenken”. Was zunächst wie die scherzhafte Kritik an einer Programmiersprache aussieht ist bei genauerem Hinsehen viel mehr: es ist die Kritik an einer Verselbstständigung der Abstraktion. Und genau da liegt eine große Schwäche bei vielen Leuten, die eine systematische Ausbildung der Informatik hinter sich haben: die Technologie verkommt zum Selbstzweck. Wer hat nicht schon einmal Quellcode gesehen, der sich in endlosen Klassenhierarchien vererbt oder Datenmodelle, die jedes ach so kleine Datenpäckchen noch externalisieren und ein an sich einfache fachliche Probleme zu Datenmodellen mit dutzenden Entitäten aufblähen?

Fragt man dann nach, warum die Modelle denn so sind wie sie sind, bekommt man meistens “Erweiterbarkeit” an den Kopf geworfen. Oder “Änderbarkeit”. Oder “Vereinfachung”. Spätestens hier wird dann aber auch schon durch das reine Nachfragen selbst dem abstraktesten Architekten klar, dass etwas schief läuft. Diese “Verkomplizierung im Namen der Vereinfachung” oder auch “spekulative Verallgemeinerung” ist eine sehr verbreitete Krankheit in vielen vielen Softwaresystemen. Sie führt zu sehr schwer zu wartenden Quellcodes und deutlichen Mehrkosten bei jeder Art von Veränderung und Erweiterung. Damit erreicht sie dann genau das Gegenteil von dem, was eigentlich beabsichtigt war – und das ist das Tragische daran.

Allerdings befällt dieses Problem nicht nur Software an sich, sondern auch IT-Standards oder auch Entwicklungsprozesse. Dieses “Overengineering” kann man beispielsweise sehr gut bei den WS-*-Standards wie SOAP, WSDL oder auch BPEL beobachten. WSDL ist da ein sehr gutes Beispiel: prinzipiell lässt sich damit jede Art von Schnittstelle auf Basis jeder Art von Technologie beschreiben. Aber wird das auch eingesetzt? Mir ist es nicht gelungen auch nur einen einzigen Fall zu finden, in dem WSDL nicht zur Beschreibung von SOAP-Web-Services auf Basis von HTTP oder SMTP zum Einsatz kam. Die beim Design von WSDL berücksichtigte Unabhängigkeit von jeder Art von Dritttechnologie wird überhaupt nicht genutzt! Allerdings hat sie WSDL sehr viel komplexer gemacht und damit schwerer einzusetzen und damit im Endeffekt teuerer. Dass man bei einer so innovativen Technologie wie Web-Services damit quasi das gesamte Konzept auf die Kippe stellt nur weil man die “ultimativ allgemeine” Lösung finden möchte ist ein Nebeneffekt. Und dass dieser tatsächlich zuschlagen und einen gesamten Standard ins Abseits katapultieren kann, ist am Besipiel von UDDI sehr schön zu beobachten.

Aus meiner Sicht ist ein guter Entwickler und ein guter Architekt nicht nur jemand, der Abstrahieren kann, sondern auch jemand, der die Grenzen der Abstraktion erkennt. Er muss in der Lage sein, fachliche Bedürfnisse gegenüber technischen Möglichkeiten abzuwägen und die “richtige” Lösung zu finden – nicht die technisch perfekteste, sondern die technisch und fachlich eleganteste. Einfach die Lösung, die KISS ist.

Mal abwarten ob noch ein paar bessere Emulatoren dafür erscheinen.

A Kiss Before Dying movie download Looking for Comedy in the Muslim World movie

• Blow trailer

News from the gadget department: just got my PayPal/eBay Security token. It is a nice little device just the right size for a keychain. The token is made by Verisign and can be used to protect your PayPal and eBay accounts. Once activated, you have to log in to these accounts using the number displayed on the token. Every number is valid for 30 seconds. The idea is that you can only log in to your account when in physical possession of the piece of hardware.

You can order the token worldwide for around 5 Euros here.The device itself is a Vasco Digipass Go 3, which can also be ordered from Verisign directly (which costs $30). Verisign announces the Go 3 OTP device as a device usable with Verisign’s OpenID

Memoirs of an Invisible Man film www порно ru

service. So, I was giving it a try and registered my token at Verisign’s OpenID site

• Tourist Trap movie download

…and it works Secret Passage movie download

!

When registered with the service, you can use the PayPal token to log in into all OpenID enabled sites like Sourceforge or use it for your own applications. The access to the Quendor.org adminstration interface is now accessible thru OpenID authentication and I can use my keychain token to log in. Nice.

This is, in short, a nightmare scenario for long-time iPod fans: are we entering a world in which Apple controls and taxes literally every piece of the iPod purchase from headphones to chargers, jacking up their prices, forcing customers to re-purchase things they already own, while making only marginal improvements in their functionality? It’s a shame, and one that consumers should feel empowered to fight.

Einfach nur krank und ein weiterer Grund, keine Apple-Produkte zu kaufen. Defective by Design eben. Fireproof video

Jay. In diesem Frühjahr erscheint tatsächlich “Giana Sisters 2″ für den NDS. Damit wird eines aus meiner Sicht besten Computerspiele aller Zeiten fortgesetzt. Mehr Infos beim Publisher, Spellbound Entertainment. Auf dem NDS gibts sowieso viel zu wenige 2D-Jump-and-Runs.

Der erste Teil war eigentlich ein böser Mario Rip-Off, aber damals wars egal, nur Noobs

• The Legend of Lucy Keyes dvd

hatten ein NES, echte Kerle hackten auf dem C64. Nintendo fand das damals allerdings nicht so witzig, das Spiel wurde wegen einer Klage ziemlich schnell wieder zurückgezogen. War aber auch schon ziemlich dreist, vor allem, weil auf Seiten Rainbow Arts eine gewisse Doppelmoral vorhanden war.

Jaja, die gute alte Zeit.. The Dudesons Movie movies

• Blow dvdrip

So, heute mal wieder ein Artikel aus dem tiefen Tal der lustigen Softwarefrickeleien. Ich habe mich am Wochenende mal intensiv mit JEE, Eclipse und Maven und dem Zusammenspiel dieser Dinge auseinandergesetzt. Die nächste Version des LinuxTag eTicket-Systems soll voll auf JEE setzen.

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
  buy Yat goh hiu yan

  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).

buy Blue Steel


   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.

Cory Doctorow hat einen rantigen Artikel buy Meet Dave The House Bunny dvd zum Thema DRM geschrieben:

So go on buying your Audible books, your iTunes DRM songs, your Zune media, your EA games… None of these companies will ever disappear, nor will the third-party DRM suppliers they use. They are as solid and permanent as Commodore, Atari, the Soviet Union, the American credit system and the Roman Empire.

Hintergrund ist die Abschaltung der DRM-Server von Wal*Mart. Diese Teile sterben diese Teile wie die Fliegen im Moment. Manchmal treffen Prophezeihungen halt auch ein..

North Country movie full

am Fraunhofer-Institut sein.

Oh, God! You Devil video

kleinhenz@mklein-nb:~$ host x.blubb.blubb
x.blubb.blubb has address 172.16.4.2
x.blubb.blubb has address 172.16.4.1
x.blubb.blubb has address 172.16.4.3

Applications usually use the first entry, resulting in a per-query association of host and ip address. If the actual DNS query is not cached, it works as a continuing distribution of querys over the listed ips.

Turning off the DNS caching in Java is easy: set the “networkaddress.cache.ttl” property to “0″ disables it. But here comes the problem: if you have mixed IPv4 and IPv6 hosts in your DNS, Java will prefer the v6 hosts, listing them on top on the v4 addresses. This results in a bizarre behaviour: the list of ips in the returned list are mixed up – but in two groups: the mixed IPv6 host group appears on top of the mixed IPv6 group!

The solution is rather simple: just add “java.net.preferIPv4Stack=true” to the properties environment and the round robin works as espected.

• Wayne’s World video

oder wollte davon jemals irgendwas gehört haben. Selbst darauf angesprochen, dass auf der iRiver H300-Serie Rockbox deutlich mehr bietet als die Original-Firmware, waren die Koreaner überrascht.
Bei den Appliances ist es aus meiner Sicht immer das Gleiche: man baut einigermaßen gute Hardware, vernachlässigt aber die Software mehr oder weniger vollständig. Bestes Beispiel ist der Sansa View, mein aktueller MP3-Player: tolle Hardware aber die Firmware wird von Version zu Version immer schlechter. Im offiziellen Sandisk-Forum

gibt es eine riesige Schlammschlacht zu diesem Thema und ich frage mich beispielsweise auch, wie es sein kann, dass sich mit einem Firmwareupdate die Batterielaufzeit halbiert!?
Warum kommt keiner dieser Vollspackos mal auf die Idee den Rockbox-Kernel als Basis für eine Firmware zu verwenden und einfach eine neue Oberfläche aufzusetzen (denn die ist, sorry Rockbox, nicht wirklich “commercial-grade”). Davon würde Rockbox (endlich eine vernünftige UI) und der Hardware-Hersteller (endlich eine vernünftige Software) profitieren.
Ok, ich weiß schon, das Gegenargument ist, dass die Hardware-Typen kein Interesse daran haben, dass ihre Software auch vom Konkurrenten genutzt werden kann. Aber seien wir mal ehrlich: im Moment verkaufen die sowieso nur über die Hardware, die Software kann Five Across the Eyes in dem üblich-schrottigen Zustand so oder so kein Kaufargument sein. Oder hat man schonmal jemand gesehen, der beim Kauf die Funktionen wichtiger als “Aussehen”, “Gigabytes” oder “gesamter Coolheitsfaktor” bewertet? Wenn es das gäbe, würde nur Apple im Moment MP3-Player verkaufen…