Nun ja, genauer gesagt, das Problem trat auf einem (Test-) Windows Server 2008 mit IE9 auf. Aha..?

Nach einem schnellen Aufschalten auf den Testserver und dem Aufruf der Debugging-Tools offenbarte, dass der IE9 an genau einer Stelle auf Nase flog: aAudio=”Audio”in window?new Audio(“”):{} Im Prinzip ein ganz normale Art und Weise, eine Feature Detection durchzuführen. Für diejenigen, die nicht in JavaScript firm sind: Die Variable aAudio wird, falls im Objekt window eine Eigenschaft Audio vorhanden ist, mit einer neuen Instanz eben dieser Audio-Klasse belegt, andernfalls mit einem leeren Objekt (hilfreich ist hierbei zu wissen, dass window der Standardscope ist).

Das heißt also, nur wenn der Browser die HTML5-API “Audio” kann, wird auch eine Instanz davon erstellt. Weiter später wird im Script auf eine spezielle Eigenschaft/Methode dieser Variable geprüft: Damit lässt sich dann feststellen, ob HTMl5-Audio implementiert wird (hier: canPlay). Das gesamte Problem gilt natürlich auch analog für die HTML5-API des Tags video.

Eine Exception “Not implemented”, die nicht aus der Anwendung kam, nicht aus dem Framework und auch nicht aus dem Plugin, welches im Endeffekt diese Zeile beinhaltet, wurde geschmissen und stoppte die gesamte Anwendung bzw. das verursachende Script. Und genau diese Zeile war die Feature Detection für HTML5-Audio in einer Sammlung von Flash/Video/Audio-Funktionalitäten.

Lange Rede, kurzer Sinn: Der Internet Explorer 9 hat u.a. die HTML5-APIs für Audio und Video implementiert — eigentlich. Nicht jedoch auf einem Windows Server 2008, denn dort wird dafür ein optional zu installierendes Feature — so called Desktop Experience Feature — des Betriebssystems benötigt. Und damit das ganze auch richtig gegen die Wand fahren kann und muss, tut man (der Browser) erstmal so, als würde er HTML5-Audio anbieten können (API window.Audio gibt es!), schmeißt dann aber eine Exception, wenn man das Objekt tatsächlich nutzt.

Tatsächlich ist die einzige Lösung, dies mit einem billigen try-catch zu lösen. Eine Post-Recherche ergab, die Macher von Feature-Detection-Framework Modernizr haben das genauso gemacht.

Es hat sich in den Jahren nicht viel geändert: Sonderwürste für den IE stehen weiterhin an.

Hintergrund – oder: Die Sache selbst

Eine granulare Feature Detection ist heutzutage bei modernen Webanwendungen oder besser -frameworks quasi Pflicht. Hat man früher noch eine grobe Browser Detection (Browserhersteller und -version) vorgenommen, um daraus herzuleiten, ob Feature X unterstützt wird, so prüft man heute besser auf dieses Feature direkt. Erstens sind die Features unzählig mehr geworden, zum anderen benötigt das das “Wissen”, welcher Browser welches Feature kann. Außerdem ist es mit den modernen Workingdraft/Livingstandard-Trends quasi unmöglich geworden, Features zu bestimmten Browsern zuzuordnen. Chrome und Firefox aktualisieren sich mittlerweile  mehr oder weniger selbstständig; und überhaupt ist die Geschwindigkeit der Browserentwicklungen so schnell geworden, dass eine Browser-basierte Herleitung von Feature-Verfügbarkeiten schwierig wird. Ein ganz gutes Beispiel ist HTML5 — denn HTML5 ist als Standard weder komplett fertig, noch in einem/jedem Browser gleichwertig implementiert.

In der Regel läuft eine Feature-Detection wie folgt ab: Man prüft, ob die Voraussetzungen bspw. für einen Tag oder eine DOM-API-Funktion vorhanden ist und ermittelt gegebenenfalls noch weitere Ausprägungen.

Beispiele

• navigator.geolocation ist nicht undefined, wenn der Browser die Geolocation-API kann.
• document.createElement(‘canvas’).getContext ist nicht undefined, wenn der Browser Canvas-Tags unterstützt und damit Canvas zeichnen kann.
• document.createElement(‘audio’).canPlay ist nicht undefined, wenn der Browser HTML5-Audio-Tags unterstützt und demnach HTML5-Audio abspielen kann.

Weitere Links

• Mozilla Browser Feature Detection
• Detect HTML5 Features Before You Use Them
• GitHub/Modernizr: #224 IE 9 Running on Windows Server SKU can cause an exception to be thrown
• Release Notes for Internet Explorer 9: Known Issues

In diesem Artikel geht es um die Installation und Konfiguration von Atlassians JIRA, FIshEye und Confluence in einer ursprünglich rein Trac-basierten Umgebung.

Ich gehe davon aus, dass die Hersteller-Guides bereits bekannt sind oder bei Fragen zu Rate gezogen werden. Es werden nicht alle Funktionen und Features der Produkte im einzelnen vorgestellt oder erklärt (etwa: Was ist ein Crowd-Server? oder Wie stelle ich den Benutzer-Signup aus?).

• http://confluence.atlassian.com/display/JIRA/JIRA+Documentation
• http://confluence.atlassian.com/display/FISHEYE/FishEye+Documentation+Home
• http://confluence.atlassian.com/display/DOC/Confluence+Documentation+Home

Installationen

Für eine saubere Installation empfiehlt es sich, die Anwendungen von einander getrennt zu installieren.

Alle drei Produkte lassen sich als Standalone oder als WAR herunterladen und installieren. Während die WAR -Variante nur in einen vorhandenen Tomcat deployt wird, ist die Standalone-Variante eine fertig konfigurierte Einheit, die auch entsprechend korrekt konfiguriert ist. Aus mehreren Gründen ist die Standalone-Variante vorzuziehen: Service-Able, besseres Tuning im Performance-Problemfall.

Leider ist die Qualität der Standalone-Versionen nicht überall gleich; JIRA ist dabei am Besten und quasi vollständig.

Für diesen Beitrag installieren wir die Produkte jeweils in die drei Verzeichnisse /opt/confluence, /opt/fisheye und /opt/jira. Und natürlich unter Linux.

JIRA

Praktischerweise wird JIRA in einem selbstausführenden Installer zur Verfügung gestellt. Also sudo gestartet, sollte man hier den empfohlenen Weg nehmen und JIRA als Service mit eigenem Benutzer installieren. Da der Installer selbstständig einen Benutzer jira anlegen wird, sollte dieser nicht vorher schon existieren. Ist bereits einer vorhanden, legt der Installer jira1 an, inkl. einem gleichlautenden Service.

Danach ist JIRA installiert und muss via Web konfiguriert werden. Für die produktive Installation bedeutet dies beispielsweise eine externe Datenbankanbindung.

Hinweis: Sofern der Administratorzugang mit einem Benutzer aus dem späteren Trac-Import matchen soll, sollte der Benutzername gleich heißen.

Hinweis: Sollen mehrere Tomcats auf einer Maschine laufen, müssen die Ports entsprechend verändert werden. Die JIRA-Tomcat-Konfiguration ist unter conf/server.xml zu finden. Dort findet sich auch ein auskommentierter Connector für AJP.

Es empfiehlt sich, den Remote- und API-Zugriff sofort zu aktivieren, da dieser in der Regel immer gebraucht wird (etwa für Eclipse Mylyn).

Falls die Benutzerkonten zwischen JIRA, Confluence und FishEye synchronisiert werden sollen (und das ist sicher zu empfehlen): Das Feature heißt bei Atlassian Crowd und ist in allen Produkten implementiert. Hierbei spielt JIRA dann den Crowd-Server, d.h. es stellt die Konten und Passwörter zur Verfügung. Confluence und FishEye werden später nur passiv gespiegelt.

FishEye

FishEye wird im Gegensatz zu JIRA nicht mit einem Installer ausgeliefert. Das Archiv entpackt hinterlässt nur die Applikation. Da der Standardport von FishEye 8060 ist und sich damit selten mit anderen Diensten überschneidet, kann man dies so stehen lassen.

Da FishEye von sich aus kein Service-Script mitliefert, muss man das selber beisteuern. Außerdem muss man sich auch selber um einen Benutzer (etwa sinnigerweise fisheye) kümmern.

FishEye wird per Default in eine HSQLDB installiert. Im Gegensatz zu JIRA kann man nicht bereits zu Beginn eine alternative Datenbank auswählen. Dafür kann Fisheye jedoch on the fly via Administration/Database in eine externe Datenbank migriert werden.

Falls die Crowd-Funktionalität von JIRA verwendet werden soll, muss in der Administration der JIRA-Server als “Application-Link” angelegt werden. Anschließend kann man die Benutzer synchronisieren (etwa automatisch jede Stunde) und das lokale Registrieren abschalten.

Hinweis: Mit dem FishEye-Administrator-Passwort kommt man immer in die Admin-Backend zurück. Dennoch empfehle ich, einen Login in einem separaten Browser (oder einfach im Inkognito-Modus) auszuprobieren. Per Default werden Benutzer, die in der Gruppe jira-administrators sind, auch automatisch FishEye-Administratoren.

Erst nach Abschluss dieser Feinheiten lohnt sich das Anlegen von Repositories.

Hinweis: Lässt man die alte Trac-Installation noch weiter laufen, so kann man in den Eigenschaften eines FishEye-Repositories einen Linker definieren, damit in Commits erscheinenden Ticket-Referenzen (#123) auf Trac verweisen können (reguläres Muster: #(\d+)). Prinzipiell kann man auch einen Link auf FishEye selber erzeugen, das funktioniert natürlich nur, wenn keine Tickets aufgrund von Projekt-Splittung verschoben wurden.

Nach erfolgtem Anlegen und Indizieren des Repositorys (oder der Repositories) sollte der Übersichtlichkeit wegen Projekte anlegen — idealerweise in der gleichen Struktur wie unter JIRA. Anschließend kann man mit den Application-Links dafür sorgen, dass erstens FishEye weißt, dass ein ein bestimmtes Projekt einer JIRA-Installation in den Changeset-Kommentaren verlinkbar ist und zweitens der entsprechenden JIRA-Installation eine Backreferenz auf diese FishEye-Quelle geben.

Mit dieser Konfiguration werden Commits mit einem Verweis auf ein Ticket (“… PROJECTKEY-123…”) automatisch auf JIRA verlinkt und gleichzeitig im JIRA-Vorgang als Aktivität aufgelistet.

Confluence

Wie FishEye bietet auch Confluence nur ein entpacktes Verzeichnis an. Auch hier muss man sich um ein Service-Script und einen Benutzer selber kümmern.

Auch hier sollte man nach erfolgter Installation die Authentifizerung auf JIRA umstellen. Dafür muss man eine Referenz auf JIRA anlegen. Eventuell ist es auch nötig, eine zusätzliche Referenz seitens JIRA auf Confluence (erlaubte Abfrage der Konten) anzulegen.

Wichtiger Hinweis: Es ist dringendst zu empfehlen, vor dem Switch auf den JIRA-Crowd-Server dem eigenen Konto (in JIRA) die neu zu erstellenden Benutzergruppe confluence-administrators hinzuzufügen — ansonsten sperrt man sich sofort aus. Hat man den Abgleichtimer auf eine Stunde gestellt und will – für Confluence – nicht von vorne anfangen, ist man eine Stunde merkbefreit.

Von Trac nach JIRA

Upgrade auf Trac 0.12

Das Importwerkzeug von JIRA ist nur mit Trac-Export-Daten kompatibel, die aus einer 0.12-Installation heraus erstellt wurden.

Die vorhandene Trac-Installation lief leider noch in der Vorgängerversion 0.11. Das macht sich unter anderem daran bemerkbar, das zwar der Import prinzipiell funktioniert, aber beispielsweise alle Zeiten/Zeitstempel falsch sind (01. Januar 1970). Dieser Umstand wird durch eine Änderung der internen Speicherung von Timestamps in Trac geschuldet (0.11 speichert in Sekunden, 0.12 jedoch in Mikrosekunden).

Daher war es zunächst erforderlich, die vorhandene Trac-Installation mittels Upgrade auf 0.12 zu aktualisieren. Je nach Installation ist ein Upgrade einfach oder umständlich.

Hinweis: Es kann durchaus sinnvoll sein, dass man seine bisherige Trac-Installation unverändert lassen will. Dies ist relativ einfach zu bewerkstelligen. Auf einer separaten Maschine (dafür eignet sich auch ein schnell aufgezogenes Debian in der VM) wird Trac 0.12 etwa via apt-get installiert. Danach wird ein Trac-Repository konfiguriert und anschließend das existierende Repository 1:1 herüberkopiert. Die anschließenden Befehle trac-admin upgrade und trac-admin wiki upgrade hiefen sowohl die Trac-Datenbank als auch die Wikiseiten auf die neue Version – fertig!

Export von Trac

Die Trac-Daten werden wie folgt exportiert: Die Tickets liegen alle in einer Datenbank im Repository, die Attachments liegen als Dateistruktur ebenfalls im Repository. Man wechselt in das Verzeichnis vom Trac-Repository und packt alles zusammen in ein Zip-Archiv.

Import in JIRA

Im Import-Assistenten wählt man Trac und danach das zuvor erstellte Zip-Archiv. Je nach Größe kann es erforderlich sein, dass man in der JIRA-Administration das Upload-Limit für Dateien (kurzfristig) erhöhen muss. Der Assistent entpackt das Archiv und analysiert die Strukturen. Sofern man keine Besonderheiten hat, kann man die Schritte alle absegnen. Eventuelle CustomFields sollten ebenfalls als solche auch in JIRA eingefügt werden.

Das “No-Priority”-Issue

Beim Import der Ticket-Daten wurde das Feld Priority nicht korrekt übernommen. Das hat die Auswirkung, dass beim Editieren eines Tickets automatisch die erstbeste Priorität seitens JIRA verwendet wird. Und das ist 1 => Blocker. Etwas unschön.

Prinzipiell ist so etwas aber kein großer Aufwand, da JIRA ein sehr ausgeklügeltes und vor allem funktionierendes Mehrfachbearbeitungsmanagement mitliefert. Über “Vorgänge / Suchen / Erweitert” kann man mittes JQL eine sehr spezifische Abfrage nach Vorgängen machen. Über jede getätigte Abfrage lässt sich über den Button “Tools” in der rechten, oberen Ecke eine Mehrfachbearbeitung starten.

Hinweis: Da der Name des Trac-Felds “Priority” mit dem JIRA-Feld “Priority” konkurriert, hat der Importer ein generisches Feld (cf-xxxx) anlegt.

Über die Abfrage “status = Reopened and priority is empty and cf[xxxxx] = Blocker” lassen sich beispielsweise alle “prioritätslosen” Tickets abfragen, die aus Trac mit Blocker-Priorität kommen”. Über die Mehrfachbearbeitung setzt man dann die Priorität auf “Blocker”. Das gleiche für alle anderen Prioritäten.

Das “Reopened Issues”-Issue

Beim Import der Ticket-Daten wurden alle bereits geschlossenen und “resolved” Tickets mit dem Status “Reopened” eingeladen. Auch hierfür eignet sich die Mehrfachbearbeitung.

Hinweis: Der Workflow erfordert beim Schließen eines Vorgangs die Angabe einer Resolution. Daher ist es wie bei “No-Priority” empfehlenswert, die Abfrage gruppiert nach eine Trac-Resolution zu machen. Ansonsten verliert man die originale Resolution.

Von Trac nach Confluence

Export von Trac

Die Daten der Wiki-Seiten liegen als Dateistruktur im Trac-Repository. Da der Export bereits unter “Von Trac nach JIRA” erfolgt ist, hat man die Wiki-Daten bereits vorliegen.

Import in Confluence

Für den Import der Daten steht ein universelles Java-Programm zur Verfügung (ist in der Confluence-Administration unter Import zu finden). Damit lassen sich die Trac-Daten (aber auch noch eine ganze Reihe anderer Formate/Anwendungen) in das Confluence-Schema importieren. Das Programm ist etwas unglücklich designed und die Steuerung ist an einigen Punkten etwas unsauber implementiert — sofern man jedoch einiges beachtet, funktioniert alles einwandfrei.

Zunächst wählt man in der Liste “trac” aus. Danach wählt man den Ordner der Attachments aus, was voraussetzt, das man das Trac-Repository auf dem Rechner zur Verfügung stehen hat, auf welchem der Importer ausgeführt wird. Anschließend wählt man die Wiki-Seiten aus. Hierbei ist anzumerken, dass der Importer den kompletten, absoluten Pfad der Dateien übernimmt! Das ist äußerst unschön, weil man zwar in Confluence später zwar einzelne, aber nicht mehrere Seiten gleichzeitig verschieben kann. Unter Umständen kann es sinnvoll sein, die Wiki-Seiten für diesen Import kurzfristig auf einem /-Level anzulegen. Ein Unding ohnegleichens.

Nach der Angabe der Confluence-Server-Angaben werden die Daten importiert. Hinweis: Die externe API muss in Confluence selbstverständlich aktiviert sein.

Bonus

Hudson/Jenkins-Integration

Zwar bietet Atlassian natürlich eine perfekte Integration in und mit ihrem eigenen Buildserver Bamboo an, dies ist aber nicht zwingend erforderlich. In der Regel reicht es aus, wenn man im Ticket automatisch/sofort erkennen kann, mit welchem Build ein Ticket bzw. ein entsprechender Changeset aufgenommen wurde. Dafür gibt es das Jenkins JIRA-Plugin.

Zuallererst muss in der globalen Konfiguration von Jenkins die JIRA-Installation konfiguriert werden. In den meisten Fällen muss dafür ein Benutzer angegeben werden: Will man es schön und sauber, dann legt man unter JIRA einen eigenen Buildserver-Benutzer an (etwa mit schönem Avatar?) und trägt dessen Zugangsdaten (generisches, langes Passwort?) in der Jenkins-Konfiguration ein.

Danach kann man im entsprechenden Jenkins-Job das JIRA-Plugin aktivieren und weiteres Tuning machen.

Mit dieser Konfiguration wird ein Build als weitere Aktivität in einem JIRA-Vorgang auftauchen.

Aber der Reihe nach.

SASS

So schön CSS ist, so alt und stupide ist der Spielraum zum entwickeln und konzipieren. CSS kann keine Vererbung, keine Strukturierungen, keine Kapselungen bzw. Mixins. Das einzige, was CSS kann: eine Aneinanderreihung von Tags, bspw. #element ul > li

Mit SASS ist das alles möglich. Es sind hierarchische Strukturen möglich, man kann Mixins (Kurzanweisungen für ein Set von Funktionen/Attributen, Stichwort: Browser-Cross-Features) oder endlich Variablen im CSS nutzen. Der Code-Syntax ist dabei eine Erweiterung von CSS3* (d.h. CSS selber ist weiterhin möglich) und wird üblicherweise in .scss-Dateien abgelegt. Jedes öffentlich zugängliche Stylesheet muss dann in ein “normales” CSS umgeschrieben werden, das erledigt SASS wahlweise auf Knopfdruck oder mit einem Watchdog (Befehl watch). Mit letzterem geschieht die Generierung on-the-fly, d.h. man kann zwischen SCSS und Browser genauso wechseln wie beim guten alten CSS.

* So lange man natürlich kein CSS3 nutzt, ist man auch CSS2 kompatibel.

Compass

Als Erweiterung für SASS gedacht, erweitert Compass das Funktionsspektrum um einige hilfreiche CSS(3)-Features. Die Referenz zeigt stets den aktuellen Stand und auf GitHub sind die Sourcen offen zugänglich. Um beispielsweise die mittlerweile zahlreichen (6!) vendor-spezifischen Anweisungen eines linearen Gradienten (hier: weiß zu schwarz) zu erzeugen, reicht das simple Mixin linear-gradient(color-stops(white, black)).

Nett: Als Pull bekam das Projekt auch schließlich einen experimentellen Hack, damit Gradienten out-of-the-box im IE6-8 funktionieren. So funktioniert Open Source.

PIE

CSS3PIE ist eine winzige Library, die in Form einer HTC (so genannte HTML Components, eine microsoft-spezifische JavaScript-Datei) weitestgehend die CSS3-Features border-radius, box-shadow und linear-gradient bereitstellt.

In Compass ist PIE optional verfügbar. Mit der Ergänzung einer Zeile SCSS-Code ist damit ein runder, schattierter Button real.

Beispiele

Da war noch was…

CSS3PIE wurde dieses Jahr ein Teil von Sencha. Da ist es nicht verwunderlich, dass Sencha selber für ihren Theme-Generator (Bestandteil der Sencha SDK Tools)  für ExtJS/SenchaTouch auf Compass, PhantomJS u.a. setzt.

Error: Failed to install db46

Problemlösung hier gefunden: einfach das aktuelle Java Developer Update installieren (Hintergrund: db64 scheint beim Installieren eine bestimmte Datei zu erwarten, die eben nur noch im Developerpaket vorhanden ist).

Unter dem Titel “Suche in Chrome per type=search anmelden” fand ich die Tage einen netten Hinweis von Markus. Es geht darum, dass der Chrome automatisch Suchmaschinen hinzufügt. Auch ich dachte bisher, dass Google einfach nur eine gute Liste eingepflegt hat (bspw. mit amazon.de), aber mitnichten: Die Amazon.de-Suchmaschine ist bei mir nur deswegen drin, weil ich die Amazonseite besucht habe und Chrome dort eine Suchmaschine “gefunden” hat. Aber warum gerade Amazon.de? Warum dict.cc?

Markus erster Hinweis war, dass es mit dem neuen HTML-Inputfeld-Typ “search” zusammenhängt. Ein anderer Kommentator brachte noch OpenSearch ins Spiel.. und als meine ersten Tests überhaupt nicht fruchteten, setzte ich mich mal genauer an das Thema heran. Den Großteil des Ergebnisses habe ich bereits in Markus’ Beitrag als Kommentar geschrieben.

OpenSearch

Beginnen wir mit OpenSearch: Dies ist ein — noch nicht standardisierter — Entwurf für ein Dokument, welches die Metainformationen einer Suchmaschine beschreibt: Name, Beschreibung, URL-Pattern, Sprache, usw.

Ein solches OSDD (OpenSearch Description Document) sieht dabei vereinfacht und exemplarisch so aus:

<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
<ShortName>Example</ShortName>
<Description>My example search engine</Description>
<InputEncoding>UTF-8</InputEncoding>
<Image height="16" width="16" type="image/x-icon">http://example.org/favicon.ico</Image>
<Url type="text/html" template="http://example.org/index.html#search={searchTerms}"/>
</OpenSearchDescription>

Damit ein Browser die OSDD auch finden kann, muss sie innerhalb des HTML-Heads als Metainformation eingefügt werden:

<link title="Example" type="application/opensearchdescription+xml" rel="search" href="http://example.org/opensearch.xml">

Voilá! Ein Firefox findet damit bereits die Suchmaschine und bietet, wenn man auf den kleinen Pfeil unter dem aktuellen Suchmaschinen-Icon klickt, das Hinzufügen der neuen an. Das gilt im Übrigen auch für den Internet Explorer 8. Ab FF 2 und IE7 kann zudem explizit auf eine solche OSDD per JavaScript verwiesen werden:

window.external.AddSearchProvider("http://example.org/opensearch.xml");

Autodiscovery Mode in Chrome

Google Chrome erkennt auch diese OSDD, stellt aber zur Zeit keine geeignete UI wie etwa Firefox oder Internet Explorer zur Verfügung. Vielmehr werden hier die Suchmaschinen automatisch erkannt, eingetragen und über die kombinierte Adress- und Suchleiste zur Verfügung gestellt.

Der Trigger für den Autodiscovery Mode ist dabei zwar ein INPUT-Field mit dem Typ “search” oder wahlweise mit dem Typ “text” und dem Namen “s”. Der eigentliche Clou Witz an der Sache ist jedoch, dass Chrome dieses HTML-Element explizit auf der Startseite der Domain erwartet. Es muss also auf der example.org/index.html oder example.org/startseite.jsp auftauchen. Funktioniert die OSDD prinzipiell von allen Seiten aus, so funktioniert der Autodiscovery Mode in keinem (virtuellen) Unterverzeichnis.

Interessanterweise spielt es aber keine Rolle, wie lange die Seite angezeigt wird. Liegt also bspw. eine example.org/index.html vor, die einen Meta-Refresh nach 0 Sekunden (sprich: sofort) macht, dann funktioniert der Autodiscovery Mode dennoch. Zusätzlich kann man das Formular auch unsichtbar machen, dies hat keine Auswirkungen.

Im Grunde reicht also dieses Schnippselchen, sofern man keine adäquate oder sinnvolle Startseite hat:

<form style="display: none;"><input type="search" name="s" /></form>

Die eigentliche Konfiguration holt sich Chrome wiederum aus der OSDD.

Drawbacks

• Apple Safari scheint bis dato keinerlei native Unterstützung für OSDD oder vergleichbares zu haben. Am nächsten kommt das Plugin Inquisitor.
• Internet Explorer 9 scheint auf den ersten Blick keine Unterstützung für OSDD zu haben. Evtl. habe ich es aber auch noch nicht gefunden?
• Opera hat auch keine Unterstützung.

• Spezialfall: Im Verbund mit einem Suchparameter via Hash (Ajax/RIAs) wird bei Firefox nur der location.hash ausgetauscht (die Applikation bleibt). Google hingegen veranlasst einen kompletten neuen Request auf location.href, womit die gesamte Applikation neu geladen wird.

tl;dr: in a nutshell und lost facts

• Die opensearch.xml stellt Metainformationen für eine Suchmaschine bereit und muss auf der HTML-Seite verlinkt werden.
• Für den Autodiscovery Mode von Chrome muss auf einer Seite im Domain-Root ein INPUT-Feld “type=search” oder “name=s” vorhanden sein.
• Das Formular respektive Feld muss weder für den Benutzer sichtbar sein (CSS), noch lange angezeigt werden (Redirect nach 0 Sekunden).
• Manuelles Hinzufügen über eine API in nahezu allen aktuellen Browsern möglich.
• Es können mehrere Suchmaschinen je Seite verwaltet werden (betrifft OSDD).

Links

• OpenSearch Supported Clients
• OpenSearch Developer Best Practices

Update: Martin Thoma hat einen englischen Artikel (http://martin-thoma.com/search-engine-autodiscovery/) geschrieben, der auf diesem basiert. Ergänzende Informationen sind zum Beispiel die aktualisierten Kompatibilitäten (IE7).

Click here to view the video on YouTube.

Manche haben scheinbar nichts Besseres zu tun, als mit einer HD-Cam da rumzulaufen. Die Hälfte des Films piepsen die Geigerzähler..

via fefe

Nein, hatte er nicht. Sowohl die Subversion-Timeline als auch das eigentliche Repository zeigten alles korrekt an — Puh! Das bedeutetet jedoch, das aus irgendeinem Grunde die Synchronisation mit Git in die Hose gegangen war. Leider brachte auch das Re-Syncen nichts.

Erst das nähere Betrachten in einem visuellen Darstellung mit Hilfe von GitX brachte eine Erkenntnis: Aus irgendeinem Grunde war an einem bestimmten Tag X zwischen zwei Commits ein Merge des Release-Branches in den Hauptzweig “master/trunk” geschehen. Da ich mich an eine solche Aktivität nicht erinnern konnte (abgesehen der Tatsache, dass mir das mit git-svn auch als Kunststück vorkam), ergab das ein großes Fragezeichen… bis ich dann sah, was die besagten Commits in der SVN-Timeline waren.

Aus historischen und situationsabhängigen Gründen wurde damals ein unkonventionelle Weg eingeschlagen werden: Aus /trunk wurde Release 1.0; /trunk wurde verschoben (bzw. gelöscht, außerhalb des Standard-SVN-Schema) und schließlich /branches/new-release nach /trunk verschoben. An dieser Stelle verschluckt sich die Git-SVN-Bridge, und alle drei Branches verschmelzen zu einem gleichen Tree (nämlich den Master/Trunk).

Und die Lösung des Problems? Einmal abgesehen davon, dass natürlich die Aktion im SVN-Repository nicht gerade brilliant war, lässt sich dies über die .git/config lösen. (Hinweis: Ein einfaches git remote rm löst das Problem nicht, weil es git-svn remotes sind.)

[svn-remote "1.1-RELEASE"]
    url = svn+ssh://your-server/home/svn/project-name/branches/1.1-RELEASE

fetch = :refs/remotes/1.1-RELEASE
oder auch

[svn-remote "1.1-RELEASE"]
    url = svn+ssh://your-server/home/svn
    fetch = project-name/branches/1.1-RELEASE:refs/remotes/1.1-RELEASE

Als jedoch auch die eigens dafür organisierte Kabelmaus auch sprang, musste der Fehler woanders liegen. Ich habe die üblichen Maßnahmen abgeklappert: PRAM-Reset, Caches löschen, Neustarten, Rechte prüfen. Alles Dinge, die zwar sowieso ‘mal sinnvoll sind, nur mir irgendwie nicht weiterhalfen.

Über Google findet man zwar einiges zum Thema, aber wenig davon hilft (und teilweise sind USB-Probleme, die irgendjemand mal mit einer Festplatte hatte, schon uralt oder zu situationsspezifisch). Schließlich aber brachte mich DIESER GENIALE BEITRAG auf eine kuriose, aber schlussendlich einfach brilliante Idee: Displayportstecker ab!

Damit wäre zwar die Frage noch offen, was da Probleme macht (Spannung am Stecker?!).. aber zumindest ist USB wieder nutzbar.

Ich schließe den Tag mit einem.. WTF?!

Update: Andreas (Kommentar #1) gab mir den sehr wertvollen Tipp, dass es an dem, zwar Original Apple, passiven DisplayPort-zu-DVI-Adapter liegt. Ein aktiver Adapter kostet heute auch nicht mehr viel mehr als ein sein passives Pendant. Im Internet geistern (alte) Preise von bis zu 100$, das ist also längst Geschichte. Über Amazon gibt es den Adapter von XFZ für knapp 20 €.

In der englischsprachigen (wo sonst!) Wikipedia liest man, dass das was mit Dual-DVI zu tun hat. Und mein externer 24″-Monitor braucht die…

Oder anders ausgedrückt, in Stichworten:

• Problemlösung iPhone reagiert nicht mehr
• Problemlösung iPhone iOS 4.3 Fehler 10

Chronik

Die Installation von Xcode 4 GM selber war wie immer einfach — er schaufelt insgesamt einige Gigabytes von Daten für Compiler, Doku und Xcode selber auf die Platte. Ein Neustart wird nicht empfohlen/vorausgesetzt, aber… es wird kein iPhone mehr erkannt. Nicht einmal die Akku-Ladefunktion funktionierte, geschweige denn eine iTunes-Synchronization (Symptom: iPhone wird als Gerät überhaupt nicht vom System erkannt. Allerdings konnte ich sehen, dass der USB-Hub ein Gerät “erkennt”, d.h. eine physikalische Verbindung bestand.) Ein Reboot löste das Problem — zunächst jedenfalls. Abgesehen davon ließ sich Xcode aber nicht vernünftig starten (immer 2 Fehlermeldungen, keine Reaktion bei “New Project”), was mir dann erstmal egal war.

Daraufhin wollte ich auch gleich die neue iOS 4.3 GM ausprobieren. (Ich denke, das Problem wäre auch mit jeder anderen Firmware passiert, siehe dazu später.) Ungefähr in der Mitte des Prozesses schlug das Aufspielen der Firmware fehl und das iPhone verblieb im Wiederherstellungsmodus (mit dem iTunes-Symbol und dem Kabel auf dem Display). Das Wiederherstellen per Backup brachte überhaupt nichts bzw. es resultierte mit dem gleichen Fehler. Der Fehler war immer eine Kombination verschiedener Meldungen, u.a. auch der o.g. “Fehler 10″ während der Wiederherstellung.

Der Ansatz, einfach Xcode 3.x wieder drüberzubügeln, fruchtete zunächst nicht. Auch nach einem Reboot veränderte sich das fehlerhafte Verhalten nicht. Sh..! Die hilfreichende Lösung war dann, iTunes 10.2 einfach *nochmal* zu installieren. Ich brauchte noch nichtmal das System neu zu starten, die Wiederherstellung funktionierte sofort.

Da besteht Verbesserungsbedarf, wenn iTunes und Xcode solche zentralen Abhängigkeiten untereinander haben.

Fazit

Eine Goldmaster ist wohl heute auch nicht mehr das, was es eigentlich mal bedeutete.

IE9 has none of them, nor does it have any validation, or ranges or the new types… and worst of all for my Uploader widget, still, after all these years, does not support multiple file uploads. So the 99% isn’t 99% of all HTML5 features — it’s 99% of the tests that IE implemented. This is like writing your own test and bragging that you passed it.

Ein (weiterer) schöner Artikel über den Bullshit Microsofts. Obwohl der IE9 grundlegende und zahlreiche neue Features von HTML5 implementiert, fehlen im Vergleich zu den anderen Browsern noch etliche.. abgesehen davon, das auch diese noch nicht alles implementiert haben.

Insofern ist die Aussage einer 99% HTML5 (Test)-Abdeckung genauso viel aussagekräftig, wie das Entwickeln und Nutzen von 99 Testfällen bei Hunderten Fallunterscheidungen.

Wetten, dass demnächst etliche Zeitungen, Magazine oder gar Blogs von der überragenden HTML5-Kompatibilität der IE9 berichten werden?