Foto vom Cebit-Vortrag 2010. Quelle: http://twitpic.com/16jcvg

Wir bedanken uns für den regen Zulauf zu unserer heutigen Präsentation und bieten allen Zuhörern im Folgenden die Linksammlung zu den erwähnten Tools an. Wer die Veranstaltung versäumt hat, findet darüber hinaus unsere Folien zum Download.

Sollten Sie weitergehendes Interesse am Thema haben, sprechen Sie uns gerne an. Wir freuen uns, Sie bei der Verbesserung Ihrer Entwicklungsabläufe unterstützen zu können. Außerdem stehen wir Ihnen natürlich auch für Projektarbeiten zur Verfügung.

Links zu im Vortrag genannten Tools

• Sonar (Code-Qualitäts-Server)
• FindBugs (Code-Qualitätsmessung für Sonar und Eclipse)
• Hudson (Continous Integration Server
• Mylyn (Eclipse-Plugin)
• Trac (Ticket-System u.a.)
• Trac-Burndown-Plugin (Scrum-Support für Trac)
• Selenium (Testsystem für Webapplikationen)

Abschließend die Vortragsfolien als PDF-Download.

In der März-Ausgabe der iX haben Thomas Mühlichen und ich einen Artikel zum Thema veröffentlicht, der die technischen Hintergründe und die lange Geschichte dieser “Technik” darstellen. Wir stellen auch dar, dass es längst Empfehlungen gibt, die betreffende CSS-Eigenschaft durch die Browser (nicht durch Webanbieter wie soziale Netze) anders handhaben zu lassen – Empfehlungen, die kein Browser bisher umgesetzt hat.

Das Plugin erzeugt bei einem Release drei Maven-Artefakte (POM, Sources, Javadoc), die dann alle in unserem Maven-Release-Repository (mit Apache Archiva) landen. Eines unserer Projekte beinhaltet aber selbst überhaupt keinen Code, sondern dient nur als Aggregations-Projekt um mit Hilfe des maven-assembly-plugins ein Distributions-Paket zu bauen. Dazu lässt sich das passende Goal des Plugins an die package-Phase binden:

<plugin>
 <artifactId>maven-assembly-plugin</artifactId>
 <version>2.2-beta-4</version>
 <configuration>
  <descriptors>
   <descriptor>src/main/assembly/distribution.xml</descriptor>
  </descriptors>
  <finalName>${pom.artifactId}-${pom.version}</finalName>
  <appendAssemblyId>false</appendAssemblyId>
  <tarLongFileMode>warn</tarLongFileMode>
 </configuration>
 <executions>
  <execution>
   <id>dist-assembly</id>
   <phase>package</phase>
   <goals>
    <goal>assembly</goal>
   </goals>
  </execution>
 </executions>
</plugin>

Wenn dann in Hudson

mvn release:prepare release:perform release:clean

ausgeführt wird, wird das angestrebte tar.gz auch anstandslos erzeugt, genauso anstadlos wird es aber in der deploy-Phase ignoriert und landet somit nicht, wie beabsichtigt, in unserem Release-Repository.

Wie kann man also dem Release-Plugin beibringen, das per Assembly erzeugte Paket ebenfalls zu deployen ? Recherche bezüglich des Plugins führt in Leere, bzw. man lernt recht schnell, dass das Plugin nichts anderes tut als die Standard-Goals (Test, Package, Deploy, …) auszuführen. Der nächste Schritt führt einen also zum maven-deploy-plugin und in der Tat kann der bastelfreudige Entwickler mit Hilfe des deploy-file-Goals einzelne Datei mittels eigener Executions in Remote-Repositories transferieren.

Noch während des Kampfes mit der passenden Konfiguration stiess ich dann auf das build-helper-maven-plugin. Damit kann man per attach-artifact Files zur Liste der Artefakte hinzufügen die dann während der install- und deploy-Phase verarbeitet werden:

<plugin>
 <groupId>org.codehaus.mojo</groupId>
 <artifactId>build-helper-maven-plugin</artifactId>
 <version>1.3</version>
 <executions>
  <execution>
   <id>attach-distribution</id>
   <phase>package</phase>
   <goals>
    <goal>attach-artifact</goal>
   </goals>
   <configuration>
    <artifacts>
     <artifact>
      <file>target/${pom.artifactId}-${pom.version}.tar.gz</file>
      <type>tar.gz</type>
     </artifact>
    </artifacts>
   </configuration>
  </execution>
 </executions>
</plugin>

Vorerst gklücklich über die gefundene und vor allem funktionierende Lösung stellte sich kurz darauf die blanke Ernüchterung ein. Dank Anders Hammar, der auf eine entsprechende Frage in der maven-user-Mailingliste antwortete weiss ich nun dass ich der besten und elegantesten Lösung am Anfang schon am nächsten war und mich letzlich ständig weiter von ihr enfernte … Nur das Ziel bei der Verwendung des assembly-plugins stimmte nicht, denn dort ist für genau diesen Use-Case das single-Goal vorgesehen:

  <execution>
   <id>dist-assembly</id>
   <phase>package</phase>
   <goals>
    <goal>single</goal>
   </goals>
  </execution>

Letzlich zählt aber die Tatsache dass wir jetzt mit der einfachsten und elegantesten Lösung am Start sind, und man kann eigentlich nur mit zwei klassischen Gemeinplätzen schliessen:

Man lernt nie aus, und oft sind es die kleinen Dinge im Leben.

In diesem Fall satte 8 Characters

In der Entwicklung unserer Produkte und Kundenprojekte setzen wir Open-Source-Tools zur Messung und Steigerung der Softwarequalität ein. Eine zentrale Rolle spielen dabei Hudson, Sonar und Trac.

Mit Trac führen wir unser Bug Tracking durch. Es gibt eine nahtlose Integration in Eclipse, so dass jeder Entwickler in Eclipse die ihm
zugewiesenen Tickets sehen kann. Darüber hinaus benutzen wir Trac zur Sprint-Planung (Scrum). Trac zeichnet uns im laufenden Sprint den Burndown-Graphen, so dass wir ohne Mehraufwand (nur durch die Bearbeitung der Tickets) eine kontinuierliche Statusanzeige über unseren Sprint haben.

Hudson ist unser Continous Integration Server. Mit ihm sehen wir auf einen Blick, bei welchen Projekten bzw. Modulen es klemmt. Im Stil eines Wetterberichts sehen wir den groben Status eines Moduls (Sonne, Wolken,
Regen, Gewitter).

Mit Sonar messen wir die Code-Güte und die Einhaltung von Sourcecoderegeln. Sonar zeigt uns die Codeabdeckung unserer Unit Tests und welche Verstöße gegen guten Programmierstil an welchen Stellen im
Code vorliegen. Im Hintergrund arbeiten z.T. Tools, für die es auch ein Plugin für Eclipse gibt, so dass wir in Eclipse und in der zentralen Übersicht übereinstimmende Anzeigen bekommen.

Im Rahmen des Vortrags auf der CeBIT werden wir über unsere Erfahrungen mit Open-Source-Werkzeugen zur Qualitätssteigerung unserer Software berichten. Im Anschluss stehen wir gerne zu einem persönlichen Gedankenaustausch zur Verfügung. Bitte vereinbaren Sie vorab einen Termin.

Wir bedanken uns bei der iX für die Einladung zum Vortrag. Linkwerk ist bekannt für herausragendes Know-how im Bereich Softwareentwicklung mit Java und XSLT, marktführende Kompetenzen bei der Verarbeitung von XML-Daten und -Dokumenten, Entwicklung zuverlässiger Web- und innovativer Semantic Web-Anwendungen. Der Vortrag auf der CeBIT gibt uns die Gelegenheit, Ihnen die qualitätssichernden und -schaffenden Maßnahmen vorzustellen, mit deren Hilfe für das Linkwerk-Niveau erreichen.

Der Vortrag ist für den 4. März um 12:30 Uhr geplant. Bitte informieren Sie sich im Vorfeld über etwaige Terminänderungen auf den Seiten des iX-CeBIT-Forums. Wir freuen uns über Ihre Anwesenheit!

Die BITV ist naturgemäß stellenweise abstrakt, ähnlich wie die verwandten englischen Texte des W3C. Um die Verständlichkeit zu erhöhen, haben wir eine mit Links zu HTML und CSS angereicherte Fassung der BITV erstellt und im Rahmen des Projekts <edition W3.de> veröffentlicht.

Vier Themenbereiche stehen für die iX ganz oben (und auf der Titelseite):

• Die Zukunft der Tools, von Visual Studio und Eclipse bis zu DSLs,
• IT-Hypes, wie Cloud Computing,
• Projektmanagement und
• die Trends bei den Programmiersprachen.

Wir freuen uns, dass wir den Beitrag für die wichtigsten Sprache für Rich Internet Applications schreiben durften: Javascript. Wie immer gilt auch hier: Wir schreiben nur über Dinge, die wir in unseren Projekten täglich einsetzen. Deshalb sprechen wir von Know-how aus Erfahrung.

Mit dem IE6 hat Microsoft die Unterscheidung in “Quirks Mode” und “Standard Mode” eingeführt. Ersterer sorgt dafür, dass der Browser die bis dato implementierte Standardkonformität vergisst und Seiten auf “althergebrachte” Weise darstellt. Im Standard Mode wird eine Seite angezeigt, wenn sie eine Doctype-Deklaration besitzt. So weit, so gut.

Microsofts Wunsch (oder Notwendigkeit) nach Abwärtskompatibilität hat aber mit dem IE7 zu Problemen geführt, so dass sie mit dem IE8 nun ein neues Konzept eingeführt haben: Document Compatibility. Der IE8 kann sich nun (fast wahlweise) verhalten wie ein

• IE8 (wow)
• IE7 (mhhh)
• IE5 (oh nooo!)

Dazu reicht nicht mehr der Doctype in der Seite aus, weil der Doctype ja ursprünglich zwischen IE6-Standard und IE6-Quirk (=IE5) unterschieden hat. Da sich aber der IE7-Standard-Mode völlig anders verhält als der IE6-Standard-Mode, ganz zu schweigen vom ….. Du weißt, wie das weiter geht.

Nun gibt’s also neue Features. Wer seine Seite im IE8 behandelt wissen möchte, wie im IE7 muss nichts weiter tun, als folgendes in die Seiten einbauen:

<!-- Mimic Internet Explorer 7 -->
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" >

Moment mal? “http-equiv”? Das ist doch ein Äquivalent für einen HTTP-Header! – Richtig. Wer es nicht in seine Seiten einbauen möchte, kann seinen Webserver auch dazu bewegen, den entsprechenden Header zu schicken. Auf den Microsoft-Seiten ist eine Anleitung für IIS und Apache zu finden.

Neben IE7-Kompatibilität, was bedeutet, dass der Browser in den IE7-Standard-Mode oder -Quirks-Mode gehen kann, lässt sich auch ein Modus direkt wählen. Die Schlüsselworte lauten “IE5″, “IE7″ und “IE8″, oder man wählt gleich “edge”, dann ist man immer vorne mit dabei (Details siehe oben verlinkte MS-Seite).

Schon verwirrt oder geht noch mehr?

Ok, wer bis hier gelesen hat, verträgt mehr. Es geht nämlich noch weiter. Unter der Überschrift “Understanding Content Attribute Values” heißt es:

Das content-Attribut ist so flexibel, dass es andere als die zuvor beschriebenen Werte akzeptiert. Das erlaubt Dir, feiner zu steuern, wie der Internet Explorer Deine Seiten darstellt. Zum Beispiel kannst Du das content-Attribut auf IE=7.5 setzen. Wenn Du das machst, versucht der Internet Explorer den Wert in einen Versionsvektor zu wandeln und wählt den Modus, der am nächsten am Ergebnis liegt. In diesem Fall würde der Internet Explorer den IE7-Modus wählen. Die folgenden Beispiele zeigen den jeweils gewählten Modus für weitere Werte, vorausgesetzt es liegen keine weiteren [beeinflussenden] Faktoren vor:

<!-- IE5 mode -->
<meta http-equiv="X-UA-Compatible" content="IE=4">

<!-- IE7 mode -->
<meta http-equiv="X-UA-Compatible" content="IE=7.5" > 

<!-- IE8 mode -->
<meta http-equiv="X-UA-Compatible" content="IE=100" > 

<!-- IE5 mode -->
<meta http-equiv="X-UA-Compatible" content="IE=a" >

Was passiert nun im IE8, wenn es keine Hinweise des Webadmins oder Seitenverfassers gibt? Die Antwort von MS ist einfach: Mit Doctype-Deklaration erfolgt die Anzeige im IE8-Mode, sonst im guten alten Quirks Mode. Wenn da nicht die Ausnahmen wären. Zitat:

Wenn die Doctype-Direktive einen standardbasierten Dokumenttyp anzeigt, zeigt der Internet Explorer 8 die Seite im IE8-Modus, außer in den folgenden Fällen:

• Kompatbilitätsansicht ist für die Seite eingeschaltet.
• Die Seite wurde in der Intranetzone geladen und der Internet Explorer 8 ist so konfiguriert, dass Seiten in der Intranetzone in der Kompatbilitätsansicht dargestellt werden.
• Der Internet Explorer 8 ist konfiguriert, alle Webseiten in der Kompatbilitätsansicht darzustellen.
• Der Internet Explorer 8 ist konfiguriert die Kompatbilitätsansichtsliste zu verwenden, die eine Liste von Websites angibt, die immer in der Kompatbilitätsansicht dargestellt werden.
• Die Entwicklerwerkzeuge überschreiben die Angaben in der Webseite.
• In der Webseite tritt ein Seitendarstellungsfehler auf und der Internet Explorer 8 ist so konfiguriert, dass er solche Fehler automatisch behebt, indem er die Seite erneut in der Kompatbilitätsansicht öffnet.

Where’s the beef?

Und was soll das ganze nun? Letzlich kann die Angelegenheit jedem egal sein, der seine Seiten im Griff hat. Man kann sich noch über den Aufwand wundern. Wer braucht IE5-Kompatibilität? Warum gibt’s keinen Schalter für IE6?

Meine Haltung ist: Webseiten, die für den IE5 “designed” wurden, sehen sowieso sch…licht aus. Da macht’s nicht viel, wenn das Design nicht mehr ganz passt. Auf der anderen Seite tut der Kompatbilitätskram auch niemandem weh.

Oder doch?

Doch. Mir. Wir entwickeln eine Javascript-Bibliothek, die natürlich nicht nur auf unseren Seiten funktionieren soll. Dank der in der Tat verbesserten Situation im IE8 wird das Entwicklerleben wirklich einfacher. Wir kommen gut voran und freuen uns über geringeren Aufwand. Doch, zu früh gefreut.

Bindet man die Bibliothek in Seiten ein, die keine Doctype-Deklaration haben, läuft vieles nicht mehr so, wie gewünscht. Das gilt für Javascript-Anweisungen, die Änderungen am DOM durchführen und dabei Einfluss auf die Darstellung nehmen. Bei Seiten, die wir selbst im Griff haben, kein Problem. Auch nicht bei Kunden, die mit uns in Kontakt stehen. Gibt man aber eine solche JS-Biblothek zum Download frei, hat man keine Kontrolle mehr, in welcher Umgebung die Software zum Einsatz kommt.

Und was bietet Microsoft dafür an? Das documentMode-Property. Nun darf ich also in Javascript, sorry Jscript, mittels document.documentMode abfragen, in welchem Darstellungsmodus die Seite angezeigt wird. Dumm nur, dass mir das Wissen nichts nützt. Letzlich muss ich auch in IE8-Zeiten Vorkehrungen für IE5 treffen. Im Gegensatz zu früheren Versionen, die sich entweder wie der IE5 oder wie sie selbst verhalten konnten, kann der IE8 nun aber an multipeler Persönlichkeitsstörung leiden.

ECMAScript ist die standardisierte Form von Javascript und damit ein wichtiger Baustein für die Weiterentwicklung des Web. Über die wichtigsten neuen Features von ECMAScript 5 und andere Neuerungen in Javascript berichten wir in der nächsten Ausgabe der iX. Dazu zählen die in Firefox, Chrome und Safari bereits implementierten Web Workers, ein Thread-Mechanismus für Javascript.

Darüber hinaus sagen unsere Kunden: “Der Workshop ist ein idealer Einstieg in XPath und XSLT. Er ist sehr praxisorientiert und das Erlernte wird umgehend durch Übungen vertieft. Die Inhalte werden optimal auf die Bedürfnisse und Wünsche der Teilnehmer abgestimmt.”

Und abschließend: “Dieser Workshop macht Appetit auf mehr…!”

Wir bedanken uns für soviel positive Rückmeldung.

Einige Hintergrundinformationen zu unseren Schulungen: Wir bieten ausschließlich solche Themen an, die zu unserem täglichen Projektgeschäft gehören. Unsere Kunden bekommen Know-how aus Erfahrung. Unsere Workshops führen wir bereits seit vielen Jahren durch. Trotz dieser langen Erfahrung bitten wir auch heute noch um Feedback der Schulungsteilnehmer. Um möglichst objektives Feedback zu bekommen, arbeiten wir mit Bewertungsbögen, die uns die Teilnehmer optional im Nachhinein anonym zukommen lassen können. Die Bewertungen und Anregungen der Kunden bilden die Grundlage für eine weitere Verbesserung unseres Angebots. Das Feedback der Schulung in der vergangenen Woche bestätigt unser Vorgehen und unser Bemühen, uns stetig zu verbessern. Die Schulungsunterlagen erstellen bei Linkwerk übrigens die jeweiligen Fachleute; deshalb ist ein solcher Erfolg immer ein Erfolg unseres Teams.

• Wikipedia: ECMAScript
• Allen Wirfs-Brock: Steps Toward Creating Compatible ECMAScript 5 Implementations
• Allen Wirfs-Brock: ECMAScript 5 Conformance Suite
• Microsoft: Document Object Model Prototypes, Part 2: Accessor (getter/setter) Support
• Mozilla Foundation: ECMAScript 5 support in Mozilla
• Mozilla Foundation: Using native JSON
• Douglas Crockford: JSON in JavaScript
• Prototype Core Team: bind
• John Resig: ECMAScript 5 Strict Mode, JSON, and More
• John Resig: ECMAScript 5 Objects and Properties
• Mark Miller, Waldemar Horwat, and Mike Samuel: Changes to JavaScript, Part 1: EcmaScript 5
• Ecma: Ecma International finalises major revision of ECMAScript
• Ecma: ECMAScript Language Specification, Final Draft
• Ecma: ECMAScript