Seit einigen Tagen beschäftige ich mich auf Nutzerseite mit openID. Ich finde den Gedanken sehr praktisch, überall den gleichen Loginnamen zu verwenden und mir nicht hunderte von Passwörtern merken zu müssen.
Kurzer Seitenhieb: Eigentlich wollte ich hier im Blog und bei Fresssäckchenwahnsinn das Blog openID-fähig machen. Leider scheint es Probleme mit meinem Provider zu geben, so dass entsprechende Funktionalitäten noch warten müssen.
Ein bischen stört mich, dass ich beim Kommentieren in Blogs mit openID zwar einfach und schnell kommentieren kann, aber anschließend als Link mein openID-URI erscheint.
Mir war zwar dank des Beitrages bei agenturblog.de klar, wie das prinzipiell funktioniert, aber die korrekten Angaben für den Server von xlogon.net wusste ich nicht.
Erst in einem Kommentar im Artikel “Endlich Single-Sign-On mit openID?” bekam ich die entscheidenden Daten:
<link rel="openid.server" href="https://my.xlogon.net/server" />
<link rel="openid.delegate" href="http://xlogon.net/kbessner" />
Dies in den Header der Startseite eingetragen und man kann sich für Kommentare in Blogs etc. mit diesem URI identifizieren.
Gerade eben fiel mir sehr positiv auf, dass der RSS-Feed-Reader NetNewsWire 3.1 auch Mikroformate unterstützt.
Hinter dem unten in rot aufleuchtenden “CAL”-Symbol verbirgt sich die kurz darüber angezeigte Veranstaltung. Ein Klick auf das Symbol öffnet ein Menü mit den im Artikel eingebetteten Mikroformaten. Die entsprechende Auswahl wird dann der eingestellten Kalenderapplikation hinzugefügt.
P.S. Bei jedem Schreiben von “Mikroformate” schreibe ich beim ersten Ansetzen immer “Mirkoformate”. Dabei kenne ich nicht einmal einen Mirko.
MySQL ist toll! Es bietet all das, wofür man bei kommerziellen Unternehmen viel Geld bezahlen muss. Aber ich will nicht verschweigen, dass einige Funktionen einfach nicht vorhanden oder nur schlecht implementiert sind.
Dazu gehört unter anderem eine weitreichend verfügbare Volltextsuche. Die Volltextsuche für myISAM-Tabellen ist absolut brauchbar, unterliegt aber einer zentralen Einschränkung: Sie ist ausschließlich für myISAM-Tabellen verfügbar.
Gallery2, eine Bilddatenbank, die wir für wissenschaftlich auszuwertende Röntgenbilder in der Klinik nutzen, legt InnoDB-Tabellen an. Bei enorm großen Datenmengen für Bilder ist das durchaus sinnvoll. Leider fehlt so völlig die Funktionalität der Volltextsuche auf mySQL-Basis und das Suchmodul von Gallery2 ist mehr als schlecht. Das Modul behandelt nämlich jede Eingabe als eine komplette Phrase.
Statt die Eingabe ‘dysplasie koxarthrose’ als zwei Suchworte -nämlich ‘Koxarthrose’ und ‘Dysplasie’- zu behandeln und miteinander zu verknüpfen, sucht das Modul genau nach dem eingegebenen String und liefert entsprechend relevante, aber zu wenige Treffer zurück.
Das Projekt Sphinx nimmt sich nun dieser Problematik an und hat eine gut gereifte Suchmaschine entwickelt.
Sphinx ist darauf spezialisiert, in einem von ihr angelegten Index Suchoperationen durchzuführen. Die reine Datenhaltung übernimmt weiterhin die Datenbank. Alles, was Sphinx braucht, sind Angaben für eine Verbindung zur Datenbank, eine Abfrage, die die zu durchsuchenden Datensätze enthält und Angaben, wie der Index angelegt werden soll.
Inzwischen experimentiere ich ein paar Tage mit Sphinx. Was leider länger Kopfzerbrechen bereitete, war die Suche nach Wörtern mit deutschen Umlauten.
Fälschlicherweise nahm ich an, dass es reichen würde, in meinem Index den Zeichensatz mittels charset_type = utf-8 und der Standardeinstellung dazu (charset_table = 0..9, A..Z->a..z, _, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F) auf UTF-8 zu setzen, aber eine einfache Suche nach “Hüfte” brachte keine Ergebnisse, jedoch die Suche nach “Knie”. Klar, dass wohl der Umlaut dafür verantwortlich sein musste.
Also habe ich erst einmal einige Dinge kontrolliert: Sind die zugrunde liegenden Tabellen auch mit UTF-8 kodiert, das Terminal auf UTF-8 ausgelegt? Alles positiv.
Eine Suche über den MySQL Query Browser nach “Hüfte” brachte entsprechende Ergebnisse. Im Terminal sah das nun wieder anders aus. Die gleiche Abfrage über den mysql-Client im Terminal gab keine Ergebnisse zurück.
Bis ich dann auf die Idee kam, einmal den zur Kommunikation mit dem mySQL-Server verwendeten Zeichensatz umzustellen: SET NAMES uft8;. Und siehe da: Im Terminal bekam ich mit dem mysql-Client auch Datensätze mit der Suche nach “Hüfte” zurück.
Also habe ich für Sphinx in der Definition für die Datenquelle ein vorauseilendes SQL-Statement eingefügt: sql_query_pre = SET NAMES utf8.
Das brachte allerdings auch nach Reindexierung keine Treffer für “Hüfte”.
Ein bisschen Suchen in der Dokumentation von Sphinx machte mich beim zweiten Lesen auf den Punkt “3.5. Charsets, case folding, and translation tables” aufmerksam. Dort steht, dass der Parameter charset_table all die Zeichen enthält, die zu Wörtern gehören. Bisher enthielt die Tabelle lediglich die lateinischen Buchstaben, den Unterstrich, Ziffern und ein paar komische russische Zeichen. Mit der Hilfe von http://www.utf8-zeichentabelle.de habe ich mir folgende UTF-8-Zeichen für ä = U+00E4; Ä = U+00C4; ü = U+00FC; Ü = U+00DC; ö = U+00F6; Ö = U+00D6; ß = U+00DF herausgesucht und nach Vorbild der Standardzeichentabelle die führenden Nullen weggelassen: charset_table = charset_table = 0..9, A..Z->a..z, _, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F, U+E4, U+C4, U+FC, U+DC, U+F6, U+D6!
Das war der Erfolg!
Leider hatte das ganze einen kleinen Nachteil. Suchanfragen wie “primäre Koxarthrose” funktionierten problemlos. Allerdings wurde bei genau diesen Zeichen eine Unterscheidung der Groß- und Kleinschreibung vorgenommen. Die Suche nach “primÄre Koxarthrose” bringt nämlich keine Ergebnisse.
Also noch die Groß- Buchstaben in Kleinbuchstaben umwandeln lassen, was zu folgender Charsettable führt: charset_table = 0..9, A..Z->a..z, _, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F, U+DC->U+FC, U+C4->U+E4, U+D6->U+F6, U+DF, U+E4, U+F6, U+FC.
Nach Reindexieren funktioniert die Suche mit Sphinx nun genau so wie erwartet.
Ich habe das unschätzbare Glück in der Klinik, in der ich arbeite, ebenfalls mit einem G5 iMac unter Mac OS X 10.5 Leopard arbeiten zu können.
Allerdings benötige ich häufig das Microsoft SQL Server Management Studio Express. Dazu greife ich bisher über den VNC-Client “Chicken of the VNC” auf einen leistungsstarken Rechner in der Abteilung zu, der unter vmware ein virtuelles Windows XP beherbergt. Leider spielt “Chicken of the VNC” nicht so gut mit. Abgesehen von den zahlreichen unpassenden Tastenbelegungen ist die Darstellungsgeschwindigkeit selbst über kabelgebundenes Netzwerk ziemlich lahm. Ich vermute, dass der VNC-Client und vmware sich nicht auf einen besseren Komprimierungsalgorithmus einigen können.
Heute bin ich auf Qemu aufmerksam geworden: eine virtuelle Maschine, die auf einem PowerPC-Prozessor einen x86-Prozessor emulieren kann und somit die Installation von Windows XP ermöglicht.
Erste Installationsversuche nach der Anleitung auf der Qemu-Webseite schlugen fehl, weil immer wieder die CD nicht gelesen werden konnte. Mit einem Image der CD hätte ich abhelfen können. Aber wie zieht man nun ein Image von einer CD, das man Qemu als CD-ROM unterjubeln kann?
Folgende Lösung bietet sich -eine originale Windows XP-CD vorausgesetzt- an:
- Windows XP-CD einlegen
- Festplattendienstprogramm starten
- in der linken Leiste die Windows XP-CD anklicken
- auf die Schaltfläche “neues Image” klicken
- folgende Einstellungen wählen: “Image-Format: nur lesen” und “Verschlüsselung: ohne”
- Noch einen Namen für das Image und den Speicherort wählen und auf “sichern” klicken
In der Folge entsteht ein via Qemu bootbares CD-Image für Mac OS X, das in den Einstellungen der entsprechenden virtuellen Maschine in Qemu eingespannt werden kann.
Und nun installiert Windows XP schon seit 10:00 Uhr morgens:
Im Übrigen habe ich dann festgestellt, dass die Emulation von Qemu derart langsam ist, dass an ein sinnvolles Arbeiten mit dem MS SQL Management Studio Express nicht möglich ist. Zum Glück hat mich dieser Versuch nur eine halbe Stunde für die Imageerstellung und das Warten auf die fertige Installation gekostet.
Ich werde versuchen, den Remote Desktop Client von Microsoft zu nutzen, um auf den virtuellen Windows XP-Rechner unter vmware zu kommen. Soeben habe ich eine Verbindung via Remote Desktop Client auf den Studienserver versucht und erfreut festgestellt, dass die Darstellungsperformance hier wesentlich besser ist.
