Mai 2004 Archive

Drei Sachen machen Weblogs (resp. Blogs) für Suchmaschinen speziell: 1) Eine intensive und langlebige Verlinkung mit stabilen Links (Permalinks) und Trackbacks, 2) die Bereitstellung des Inhalts in XML (via RSS) und 3) die aktive Benachrichtigung von http://www.weblogs.com/ und http://blo.gs/ bei Änderungen.

Generell gilt für Blogs, dass sie sehr gut mit Suchmaschinen funktionierten. Spezialisiert haben sich beispielsweise Technorati oder Feedster: Beide gut um aktuelle Informationen der Weblog Community zu finden.

Ein bisschen spannender ist Daypop, welche nicht nur Blogs durchsucht aber Top Themen feststellt. Ein bisschen wie Google Zeitgeist aber in Echtzeit und auf Stufe Post. Ganz ähnlich auch blogdex.

Interessant ist auch Blogtree, die für angemeldete Blogs deren Zusamenhänge resp. den Familienbaum zeigt. Dies inkl. Geburtstage...

Und hier noch eine lange Liste von Suchmaschinen für Weblogs.

Die Site tel.search.ch ist zweifellos gut und zwar in allen Dimensionen. Ein paar Sachen sind einfach sehr gut und funktionieren bei der Konkurrenz nicht...

Suche ich mich selbst in St. Gallen so funktioniert dies auch ohne Leerschlag zwischen St. und Gallen. Eine Suche nur mit Gallen bringt richtigerweise das selbe Resultat.

Dank der Verbindung zur Websuche vergleicht die Suche Adressbestandteile von Webseiten mit dem Telefonbucheintrag und schlägt Websites vor (unter dem Adresseintrag). Für namics klappts grad nicht so toll, besser z.B. für Veloblitz.

So richtig gut finde ich, wenn ich nach einer Nummer suche, für die es keinen einzelnen Eintrag gibt beispielsweise 01 228 67 01.... Die Suche schlägt den nächstliegenden Nummernkreis vor und findet so namics Zürich.

Gut finde ich auch, dass bei Null Treffern die Erweiterung der Region vorgeschlagen wird. So suchte ich letzthin ein Restaurant in Teufen und fand es am Ende in Niederteufen.

Eine schönes Hotel finde ich sowohl in Biel wie auch in Bienne. Eigentlich logisch aber bei anderen klemmts.

Technisch keine Datenbank aber ein invertierter Index mit Hash-Tabellen (so wie bei der Suchmaschine). Rasend schnell, effizient auf ein paar Linux-Büchsen und vor allem an den Benutzer gedacht! Gratulation.

"Jürg, schau Dir die Site doch rasch an...". Natürlich gibt es fiese Tools um Sachen rauszufinden. Der folgende Beitrag zeigt die harmlosen und alles solche ohne Installation.

Zuerst schau ich mir an, auf was die Sache läuft: http-Server, Betriebssystem: Netcraft (links oben).

Dann auf was das Ding läuft und wie die Anbindung resp. das Peering ist. Die Route mit den Whois und dem RIPE Eintrag auf der BBox (clientseitiges Java benötigt) -- Messung immer ab Bern. Für Peering ab verschiedenen Standroten bietet sich www.traceroute.org an.

Was mir als nächtes meist einfällt sind ein paar Eckwerte des Clientcodes bei Webmasterplan: Der Ladezeitcheck.

Und eigentlich fast zeitgleich die generelle Suchmaschinentauglichkeit.

Und nun werden wir seriös und schauen und die Validität des Clientcodes an, die Validität des CSS und die Links.

Was natürlich nicht fehlen sollte (wenn auch die Aussagekraft von Quellcodeanalyse sehr bescheiden ist), ist WAI. Bei Bobby oder bei Cythia. Besser in der Aussage aber mehr Arbeit ist der Barrierefinder.

Sodeli und so hätten wir mal schon viel zu erzählen....

Qualitativ richtig gut und wertvoll sind Test mit Systformance über Verfügbarkeit und Performance. Das braucht aber mehr Zeit und Kopfarbeit. Link und UID/PW in know.namics.

Die Idee ist so einfach: Um an eine Datei zu kommen, so ist es besser nicht nur "runter" zu laden aber gleichzeitig die "andere" Richtung der IP-Verbindung zu nutzen. Realisiert im Filesharing von BitTorrent (eine tolle Sache).

Grundzüge der Funktion (vor der Verteilung):

- Die zu verteilende Datei wird in einem Metafile beschrieben: Dateierweiterung .torrent. Darin wir diese u.a. in Stücke (pieces) aufgeteilt und letztere mit SHA1 überprüfbar gemacht (Beispiel: BitTorrent für Fedora).

- Auch beschrieben in der Metadatei ist ein zentraler Server, der die Adressliste der verteilenden Clients verwaltet: Der Tracker.

- Und nun noch der Client genannt Downloader. Ein Downloader der die gesamte zu verteilenden Datei hat wird Seeder genannt. Zu Beginn ist dies ein Einziger.

Grundzüge der Funktion (die Verteilung):

- Der erste Kunde für den Download gibt seinem BitTorrent-Client die .torrent Metadatei, zugänglich über http.

- Aufgrund des Inhaltes kontaktiert der Client den Tracker und der gibt ihm eine Liste von Downloadern -- die sogenannten Peers (Gleichgesinnte).

- Von da an ist der Downloader vollständig autonom und kontaktiert seine Peers mit der Bitte für einen Download. Die Summe aller kommunizierenden Downloaders heisst Swarm.

- Und nun kommt das Wichtigste (und der zentrale Unterschied zu anderen P2P-Protokollen). Als "Belohnung" für einen laufenden Download startet der Downloader gleich einen Upload zu seinem Peer mit einem Dateifragment, welches dieser noch nicht hat. Der Erfinder Cohen nennt dies tit-for-tat (so wie in der Spieltheorie resp. bei Kindern "wie du mir, so ich dir").

Das Resultat ist die effizienteste Bandbreiten-Nutzung aller Downloadprotokolle nahe an den Eigenheiten von TCP/IP. Vorausgesetzt die Dowloader bleiben lange am Netz und alle spielen fair mit (dem ist meist nicht so). Verglichen wird diese gegenseitige Optimierung mit dem Optimierungstheorie des Wirtschaftswissenschafters Vilfredo Pareto.

Für den, der die Referenzimpletierung in Phyton nicht mag, gibt es zahlreiche graphische Clients. Der bekannteste (mit schönen Screenies) ist Azureus.

Hier knackig von Bram Cohen beschrieben: [pdf, 80 KB] Incentives Build Robsutness in BitTorrent und ein gutes FAQ.