Ich habe mal wieder in der Kiste gekramt und ein paar neue Photos hochgeladen. Das Highlight dieser Serie ist aus Sicht der Erinnerung der Besuch bei Jackson Pollocks Haus auf Long Island. Auch wenn es zu der Zeit nicht zur Besichtigung geöffnet war, war es doch eine tolle Atmosphäre.

Ihr gelangt zu mehr Photos, wenn ihr auf das obige clickt.

Jede Tag-Seite auf Taggling.de/.com (z.B. taggling.de/tag/auto) ist ab sofort mit einem speziellen RDF-Code versehen. Damit können Blogsysteme, die Trackback Autodiscovery unterstützen, Tags in ihren Beiträgen einfach per Trackback an Taggling übermitteln. (Dieser Beitrag wurde somit automatisch mit dem Tag „Auto“ versehen und steht nun auch tatsächlich in der Datenbank.)

Die Trackback-URL eines jeden Tag lautet www.taggling.com/tb/<tagname>, also z.B. www.taggling.com/tb/auto.

Das ganze befindet sich zur Zeit noch in einer Testphase, die so generierten Einträge werden bisher nur in der Datenbank zwischengespeichert. Ich hoffe, dass ein paar Test-Einträge generiert werden. Auf Anfrage kann ich dann auch eine URL ausgeben, die den Inhalt der internen Liste ausgibt. So können externe Entwickler testen, ob der Trackback richtig funktioniert hat.

Es ist so natürlich auch möglich, neue Tags zu erzeugen. Beim Testen ist es so also noch einfacher, „seinen“ Eintrag aus obiger Liste herauszufinden.

In einem weiteren Schritt möchte ich das Trackbacken von Links, Farben und Photos ermöglichen. Dazu würde dem Trackback halt ein entsprechender Parameter übergeben. In dem Zusammenhang möchte ich das dann in Freetag einbringen.

Mal sehen, wohin die Reise führt :-)

Wie Mac Essentials so schön schreibt: I ward narrisch!

Es geistern ja nun die unterschiedlichsten Gerüchte aus den unterschiedlichsten Kanälen durch die Web-Welt zum Thema Apple und Intel. Dabei gehen die meisten Berichte davon aus, dass MacOS X auf x86 kompatiblen Prozessoren (ich zähle die 64 Bit Variante von Intel/AMD einfach mal mit dazu) portiert werden soll. Einige berichteten sogar davon, dass vorerst nur der Mac mini und dann Schritt für Schritt andere Rechner aus Apples Portfolio mit Intel Prozessoren bestückt werden sollten.

Der Grund dafür wäre, dass der Umstieg auf eine neue Hardwareplattform nicht zu hundert Prozent sofort erfolgen müsste und gerade Firmen aus dem professionellen Softwarebereich mehr Zeit hätten, ihre Programme umzuschreiben. Denn einfach nur den Prozessor austauschen ist nicht möglich. Das wäre so, als wenn man einen Raketenmotor in ein Auto einbauen wollte – ohne hier jetzt eine Aussage zur Geschwindigkeit machen zu wollen! Das sind einfach zwei grundsätzlich unterschiedliche Antriebskonzepte.

Es sind aber auch noch andere Szenarien denkbar. So hat Apple mit IBM angeblich eine Art Vertragsstrafe festgelegt, die Apple nun in die Situation gebracht hat, dass die umfangreiche Spezifikation der PowerPC-Architektur rechtlich an Apple übergeht und sie somit die Möglichkeit hätten, Intel mit der Entwicklung eines PowerPC zu beauftragen. Das wäre für Intel vielleicht auch deshalb interessant, weil ja auch z.B. die nächste Generation der Spielekonsole XBox aus dem Hause Microsoft mit PowerPC arbeitet.
Andererseits kann ich mir aber nur schwer vorstellen, wie Intel es schaffen soll, innerhalb kürzester Zeit die PowerPCs fehlerfrei zu produzieren und dann auch noch so weiterzuentwickeln, dass Apple noch leistungsfähigere einsetzen kann und auch im mobilen Bereich (iBook, Powerbook) schnellere Prozessoren anbieten kann. Immerhin kennt sich Intel auf dem Bereich der PowerPC nicht aus.

Die dritte Alternative, neben einem Totalumstieg auf x86 und der Verlagerung der Produktion von PowerPC zu Intel, wurde von Apple schon einmal gewählt. Damals wurde von der 6800er Prozessorfamilie (68k) auf PowerPC umgeschwenkt und in das neue Betriebssystem ein Emulator für 68k eingebaut. Das würde dann ja nur Sinn machen, wenn ein zukünftiges MacOS X auf x86 basiert. Ich glaube allerdings nicht, dass die Geschwindigkeit der neuen Plattform dazu ausreichen würde, einen G5 auch nur annährend zu emulieren. Dafür schneidet dieser in Tests einfach viel zu gut ab.

Wir werden also abwarten müssen, bis Steve Jobs heute Abend in der Keynote die Gerüchte entweder bestätigt oder Lügen straft. Vielleicht kommt der Tablet Mac ja doch, mit Intel Prozessor und sorgt so dafür, dass sich die Entwickler gerne mit der neuen Plattform auseinandersetzen… Immerhin hat es Apple aber wieder einmal geschafft, vor einer WWDC die gesammelte Aufmerksamkeit der IT-Branche auf sich zu vereinen. Respekt!

Ich habe am 18. Mai mal den Zähler von Blogcounter.de auf diesem Blog eingebaut. In erster Linie, weil ich neugierig war, wie die Darstellung sein würde. Denn schon seit einiger Zeit beschäftige ich mich gedanklich mit einem Statistik-/Auswertetool speziell für Blogs.

Parallel zu Blogcounter habe ich dann die Webalizer-Ausgaben des Hosters dieses Blogs (domainfactory.de) angeschaut und mir ein paar Tageslogfiles von olbertz.de runtergeladen.

In den Apache-Logfiles steht natürlich elendig viel Müll drin, der in erster Linie von (im Mai) insgesamt mehr als 20.000 Zugriffen auf Kommentar- und Trackbackskripte herrührt! Captcha und ein paar andere Tricks helfen aber dabei, dieses Blog frei von Spam zu halten.

Durch die technischen Gegebenheiten von Blogcounter fallen diese Zugriffe also schonmal weg, was aber auch ganz in meinem Interesse liegt: Da Blogcounter nur als HTML-Code in Seiten eingebettet wird, kann er Zugriffe auf nicht-existierende Seiten, oder auf Seiten, die den HTML-Code nicht eingebaut haben, nicht zählen.

Das ärgerliche ist aber, dass der Blogcounter auch ganz andere Sachen nicht zählt. Im Logfile und in Webalizer habe ich jezt für die ersten 30 Stunden im Juni Suchanfragen über Google & Co. (30 Stück), wohingegen Blogcounter nur 5 aufführt.

Die Zeilen im Apache-Logfile weisen nichts besonderes auf, so dass ich nicht davon ausgehe, dass Blogcounter einen Anlaß hatte, diese Besucher zu ignorieren. Natürlich habe ich die Zielseiten auch überprüft und den Code des Zählers dort gefunden.

Um es deutlich zu machen: ich glaube nicht, dass Blogcounter irgendwas manipuliert, die Serverlast, die durch die dauernden Zählcode-Aufrufe verursacht wird, scheint Blogcounter aber zu überfordern. Wenn man sich den Code von Blogcounter anschaut, stellt man fest, das ganz klassisch entweder über das Image selbst (http://track.blogcounter.de/log.php?id=dirk) oder über JS-Code, den Referer und andere Statistikdaten ausliest und dann das Image aufruft: http://www.blogcounter.de/bc/log.php?id=dirk&referer=&r=1280×1024&c=32&showme=y&st=img&title=The%20blog%20that%20never%20sleeps%20-%20&style=4&url=http://www.olbertz.de/&b=589

Auch wenn die URLs unterschiedlich aufgebaut sind und die Rückgabe von http://track.blogcounter.de/log.php?id=dirk total unsinnig ist und nichts mit einem Bild zu tun hat, scheint Blogcounter diese Anfragen korrekt zu zählen und auch darzustellen.

Ich kenne jetzt die Architektur hinter Blogcounter nicht und kann so nur zwei Vermutungen aufführen: entweder wird jeweils in dem PHP-Skript direkt in die Datenbank gezählt, oder die Aufrufe dieser Zeilen wird regelmäßig aus den Logfiles gescannt und dann in die Datenbank geschrieben. Der zweite Fall wäre sinnvoller, weil dann auch zu Peakzeiten keine Verzögerung beim Aufruf des Skriptes durch das Warten auf die Datenbank auftreten sollte. In beiden Fällen verschluckt Blogcounter aber relevante Informationen.

Wenn ich mich nämlich mit solchen Tools beschäftige, dann aus dem Grund, um herauszufinden, wo Besucher landen, die über Suchmaschinen oder andere Links reinkommen und was ich an den entsprechenden Artikeln vielleicht noch ergänzen und/oder verbessern kann. Ich habe den Counter inzwischen wieder ausgebaut und werde mich wohl doch an dem eigenen Tool zu schaffen machen müssen.