dogfood Juli 2004 [2]

Dienstag, 13. Juli 2004

[12h37] MacOS X Tiger -- Daring Fireball/John Gruber über Spotlight, inkl. Insider-Wissen aus den Spotlight-Sessions.
Kurzfassung: Spotlight kann vermutlich nur Dateien, aber keine Datenbanken indizieren. Apples Mail wird in MacOS X Tiger umgestellt: alle Mails werden intern als einzelne Files abgespeichert, die Mailboxen stellen Verzeichnisse dar. Nur über diesen Trick wurde Apples Mail für Spotlight „durchsuchbar“.
Möglicherweise findet auch keine Volltext-Inidzierung statt, sondern nur der ersten 100kB einer Datei.
[08h38] Sommerferien sind ein Stück „scary“. Plötzlich ist man um kurz nach Acht der erste im ganzen Büro-Gebäude und abends um Neun der Letzte.

Montag, 12. Juli 2004

[22h53] WebDev_Blogsoftware -- Weil nachgefragt wurde: wie war das nun letzte Woche mit der spontanen „Umlegen“ von allesaussersport.de von MovableType auf Wordpress?
Zur Erinnerung: letzten Mittwoch überfiel des nächtens zum zweiten Mal eine Comment-Spam-Attacke meine allesaussersport-Domain. Da das Entfernen von Spam-Kommentaren bei MovableType 2.x allgemein aasig ist, und unter meinen speziellen Rahmenbedingungen besonders, fiel am Morgen der Entschluß auf Wordpress umzusteigen.
Zum Einsatz kam, schließlich ist es langweilig das Alte zu replizieren, ein Wordpress 1.3 „Nightly“, also eine frühe Alpha-Version.
Ex- und Import der Einträge war leicht. MovableType bietet eine Export-Funktion die Einträge und Kommentar in einer Textdatei ablegt und Wordpress bietet ein Script zum Importieren jener Datei in Wordpress (WP). Erste Schwierigkeit: es haben sich auf allesaussersport binnen 12 Monate 2MB Text angesammelt, die WP-Import-Funktion kann aber, je nach Server, nur eine begrenzte Menge aufnehmen. In meinem Fall lag das Limit irgendwo bei 1,2MB, bei anderen bei 800KB. Die Lösung lag auf der Hand und ließ sich durch eine Suche im Wordpress-Supportforum bestätigen: Die exportierte Textdatei in zwei Teile auseinanderupfen und in zwei Schritten importieren lassen.
Zweite Schwierigkeit: Beim Import fragt WP nach auf welche Wordpress-User die MovableType-Autoren umgelegt werden sollen. Hat bei mir nicht wirklich geklappt, er hat einen zweiten User „dogfood“ angelegt. Hier musste ich per phpMyAdmin direkt in die Datenbank rein, um mit SQL-Anweisungen die Autoren-ID quer durch alle Einträge von „dogfood“ auf „dogfood“ umzusetzen. Ich will meine Hand nicht ins Feuer legen, dass dies nicht irgendwo Nebenwirkungen verursacht, aber ich habe nichts erkennen können, wo die User-ID eines Artikels sonst noch in den SQL-Tabellen auftaucht.
Das Template war schnell von MovableType auf WP umgestrickt, da besaß ich mit blogbar.de hinreichend Erfahrung und konnte auch auf dafür angefertigte Hacks/Plug-Ins zurückgreifen.
Die Quick'n'Dirty-Umsetzung war so binnen 2-3 Stunden gegessen. Plus 2-3 weitere Stunden die ich verwendet habe, um das Layout von allesaussersport.de etwas aufzufrischen.
Baustellen sind noch hinreichend vorhanden. Die Archivlinks funktionieren zwar hinreichend, aber ich bin mir nicht sicher inwieweit alles bereits auf WP-Dateien zurückgreift, oder noch auf die statischen MovableType-Dateien. Am Layout und an speziellen Archiv-Templates muss auch noch geschraubt werden.
Und am nächsten Tag durfte ich die Arbeit noch mal machen, denn ich Idiot hatte eine Sache nicht bedacht: die MovableType-Installation lief im Hintergrund noch. Und als des nächtens die Kommentar-Spammer wieder zurückkehrten, brachten die neuen Kommentare das MovableType-CGI dazu, die index.php-Startseite zu überschreiben. War aber nicht schlimm. Das neue Layout war CSS-basierend, ich musste nur einige Tags austauschen und hatte den Zustand vom Vortage drin.
Wie macht sich WP generell?
Die Oberfläche finde ich zum Texten immer noch sehr viel angenehmer als MovableType. Was aber immer noch katastrophal ist, ist die Situation mit Trackbacks und Pingbacks, die immer noch genauso wenig funktionieren. Liest man sich quer durch die Foren und deutet das Schweigen der Entwickler, so scheint sich eine diffzile Gemengenlage zu existieren. Anscheinend sind die Probleme nicht richtig nachvollziehbar und tauchen nur bei einigen Personen auf. Auch der vielzitierte codefreak.de-Hack sowie die elegantere Version von wp-hackers (siehe generation NeXt) bringen einigen (sprich: mir) keine Linderung, da das Problem nicht auf Query-Strings beschränkt ist.
Ich habe leider noch keine Zeit gehabt, mir das eingehend anzugucken (sprich: mal zu sehen was da überhaupt von WP ausgegeben wird, ob mod_rewrite eine Rolle spielt etc...). Aber es sei hier zur Warnung erwähnt, falls man auf WP umsteigen möchte und ein Ping- oder Trackback-Junkie ist.
[22h49] Jeez, isses schon so lange her, das ich was reingeschrieben habe? Sorry, Betrieb auf dogfood wird diese Woche wieder spärlich werden, da das Blogs!-Buch in die Schlussgerade einbiegt. Korrekturen, Beschnitt usw.

Freitag, 09. Juli 2004

[14h38] Job -- Die Bearbeitung der Layouts für das Weblog Buch stößt auf eine Schwierigkeit. Es ist wieder die Geschichte mit den Schriften Diesmal in einer anderen Variation.
Wie beschrieben, muss ich die verwendeten Webschriften in den Layout-Dateien austauschen: von der Mac-TrueType- auf die Windows-TrueType-Geschmacksrichtung. Dabei gibt es aber in vielen Dateien ein Problem: obwohl eigentlich alles ausgetauscht ist, wird weiterhin eine Schrift als fehlend angezeigt. Diese läßt sich auch nicht per „Schriftarten suchen“-Dialog in InDesign austauschen oder anspringen.
Ich habe deshalb ein AppleScript geschrieben, dass alle Zeichen in allen Textrahmen auf allen Seiten durchgeht, und mir meldet wenn es einen fehlenden Font entdeckt. Fehlanzeige. Auch das AppleScript findet nix.
Schließlich konnte ich durch gezieltes Wegschmeißen von Objekten in der Datei den Schuldigen finden: in InDesign läßt sich Text auch in Grafikrahmen reinschreiben. Während des Layoutens versucht man einen Text einzusetzen und merkt dass es der falsche Weg ist und löscht den Text. Alleine: im Grafikrahmen bleibt zwar kein Text, aber die Font-Einstellung übrig.
Was erklärt warum „Schriftarten suchen“ bei der fehlenden Schriftart „0 characters“ anzeigt.
Richtig ätzend wird es aber dadurch, dass, so mein derzeitiger Wissensstand, es von Seiten AppleScripts keinen Zugriff auf die Schrifteneigenschaften von Grafikrahmen gibt. Alles was polygone, rectangle oder page item-Objekte anbieten, ist ein Verweis auf text frame-Objekte. Die aber wiederum, habe ich nach meinem Verständnis, bereits im ersten Anlauf abgeklappert und nichts gefunden...
Update: Denkfehler. Überall wo Text war, ist auch ein Text Frame Objekt. Aber wo kein Text im Text Frame, da keine Fonts-Objekte, noch nicht mal an Text Style Range ist ranzukommen. Steht einfach nicht in den properties Records.
[10h25] MacOS X_WebDev -- Die Debatte um die „eigenmächtigen“ HTML- und DOM-Erweiterungen in Apples Safari für OS X Tiger geht weiter. Im Großen und Ganzen: David Hyatt erklärt warum -1-, -2-, CSS-Spezialist Eric Meyer widerspricht -1-, -2-, Tim Bray widerspricht ebenfalls -1-, -2-.
Hauptargumentation von Meyer und Bray: Safari verwässert Standards und läßt die Mitte-Neunziger-Ära wieder auflebene, mit browserspezifischen HTML-Erweiterungen. Hyatt legt dar, dass ein standardkonformer Weg entweder in Implementation oder aber im Aufwand für den User (zur Programmierung von Dashboard-Widgets) untragbar wären.
Als Kompromiss scheint sich abzuzeichnen, einen Dashboard-eigenen „namespace“ zu definieren und damit saubere Validation zu erlauben.