Monthly Archives: August 2008

Mein PHP-Denken

Posted by on 2008.08.29 3 comments

Jetzt bin ich natürlich an PHP gewohnt. C-Syntax… sämtliche Parameter stehen in Klammern… wenig in-place-Funktionen… etc. Drei Sachen gibt es in python, die mir abgehen bzw. die ich nicht schön finde.

for i in liste:

Das was in PHP als “value” bezeichnet wird, ist in i enthalten, aber den “key” vermisse ich. Sozusagen: liste[key] = i. Einen eigenen Zähler dazuzuschreiben, ist ein bisschen unschön. Aber meist kann man es mit Funktionen wie map() umgehen oder funktional schreiben.

"Hello World".split(' ')

Etwas komisch, dass der erste Parameter mit einem Punkt vorher genannt wird und alle weiteren in den Klammern. Umgekehrt ist das nicht bei allen Funktionen so (zB list, int, str). Gibt es da ein Konzept dahinter?

abc = 'foo'
defghi = 'bar'

Diese Schreibweise ist laut PEP8 zu bevorzugen. Nach der Variable sollte genau nur ein Leerzeichen folgen. Ich habe in PHP aber immer die Gleichzeichen solange hinausgeschoben, dass sie auf einer Ebene mit den Gleichzeichen der nächsten Variable stehen.

Meine Scrubs-Hommage

Posted by on 2008.08.25 2 comments

Wer es nicht bemerkt hat: zwischen 05.07 (“Mein Schuljahr”) und 27.07 (“Mein Ferienalltag”) habe ich eine kleine Scrubs-Hommage gemacht. Alle Titel für Beiträge begannen mit “Mein/e”, wie es bei den Episoden von Scrubs ist. Insgesamt habe ich nur 9 Beiträge durchgehalten, aber es war faszinierend. Das beweist mir wirklich, dass ich vieles schreibe, was nur in einen privaten Blog gehört. Vieles lässt sich so leicht beschreiben. Wenn man es jedoch 9 Beiträge durchzieht und alle spontan schreibt, dann entstehen auch nicht ganz ideale Titel (“Mein ubuntu 8.04″). Auf jeden Fall schreibe ich gerne heute noch solche Titel (“Meine Maturafächer” und zahlreiche Entwürfe in der Warteschleife).

Naja… und letztendlich war es auch ein Auftakt zu meinen Sommerferien die ganzen uralten Filme zu schauen. In den letzten 5 Jahren hatte ich vielleicht 4 Filme geschaut. Von “Herr der Ringe” und “Mission Impossible” kannte ich nur den Titel. Und deshalb habe ich die Gelegenheit genutzt alle möglichen Filme nachzuschauen. Da lernte ich auch das alte Medium “Videokassette” kennen ;-)

Argumente gegen PHP

Posted by on 2008.08.22 No comments

PHP mögen viele nicht. Ich auch nicht. Die Argumente, die oftmals genannt werden, kann ich aber überhaupt nicht nachvollziehen. PHP wird mit Perl verglichen. PHP wird mit python verglichen. Natürlich gibt es grundlegende Unterschiede, aber man darf eine Programmiersprache nicht dafür verurteilen, dass sie ein anderes Konzept verfolgt. Ich erkläre einmal Argumente, mit denen ich nicht einverstanden bin, und ebenso meine Argumente gegen PHP:

  • PHP hat keine Namespaces. Natürlich sind sie bei riesigen Projekten vorteilhaft, wenn man jedoch die Namen für Funktionen, Module und Variablen gut wählt, dann halte ich sie nicht für notwendig. Ich habe sie zumindest noch nie unbedingt gebraucht. Sehr wichtig halte ich dafür den Geltungsbereich für Variablen in Funktionen (ach, wie schön das klingt ;-) ). Der muss dafür auf jeden Fall zur Verfügung stehen und das ist soweit ich weiß bei allen turing-vollständigen Programmiersprachen implementiert.
  • PHP hat kein Modulkonzept. In der Tat. Mit include() kann man sämtliche PHP-Dateien wie Module importieren und wenn der Programmierer eines Frameworks kein Noob ist, kommt es auch zu keinen Komplikationen. Viele wissen auch gar nicht, dass es für alles mögliche implementierte Funktionen gibt. BBCode, GnuPG, XML-Zeug, …
  • PHP verwendet sogenannte assoziative Arrays. Wie bereits oben erwähnt, darf man eine Programmiersprache nicht dafür verurteilen, dass sie ein anderes Konzept verfolgt. Das Konzept von PHP: Alles sollte in einem Container Platz haben. Es gibt keine weiteren Unterscheidungen (vergleich Perl und python). Für gewisse Bereiche halte ich den dynamischen Umgang mit Datentypen (in Arrays) für sehr vorteilhaft. Der Kritikpunkt ist nur, dass Arrays unsauber implementiert sind.
  • Stichwort Datentypen. PHP ist sehr großzügig mit Datentypen. (int)”12Foobar” ist 12 und (int)$_GET['sql_injection'] ist 0. Auch hier finde ich Vorteile, allerdings ist es für seine schlechte Implementierung zu verurteilen. Fehler wie diese führen dazu, dass Durchschnitts-Programmierer unsauberen Quelltext schreiben.
  • $var; das Dollarzeichen kennzeichnet die Variable. Halte ich für sehr praktisch, wobei es den Quelltext natürlich mit Dollarzeichen überhäuft. Aber in python oder VB gibt es dann keine Doppelreferenzierung wie $$var_von_var. Bei der Analyse (die zB für einen Online-Syntaxhighlighter gemacht werden muss) ist die Variable leichter zu erkennen. Außerdem gibt es keine Komplikationen zwischen Funktionsnamen und Variablen
  • PHP hat keine UTF-8-Unterstützung. Während PHP 6 Unicode unterstützen soll, machen dies schon lange die meisten anderen Sprachen (von python kann ich es bestätigen). Wie lange es jedoch dauert, bis alle PHP6 verwenden, möchte ich gar nicht wissen, nachdem manche Programmierer noch PHP4 unterstützen. Dann denkt man sich, man kann doch sicher irgendwie selbst was programmieren, damit man mysql_set_charset auch in alten Versionen verfügbar machen kann. Falsch… es stehen gar keine Basisfunktionen für den UTF-8-Support zur Verfügung.
  • PHP ist spezialisiert. python hat seinen “interaktiven Modus” auf der Kommandozeile und Perl kann man als Skript laufen lassen. Der “interaktive Modus” für PHP nennt sich SAPI, allerdings bietet er nicht die idente Funktionalität. Besonders bei zeitaufwändigen Arbeiten hat PHP hier Probleme. Über die max_execution_time lässt sich die Ausgabezeit regeln, aber für den Browser ist das auch nicht angenehm. Gerade in dem Moment läuft neben mir ein python-Skript mit einer Laufzeit > 23000 Sekunden (bisher ;-) ). In PHP würde ich sowas nicht machen. Aber ok… PHP ist spezialisiert auf Webanwendungen und dafür kann man es ja nicht verurteilen?!
  • Die PHP-Dokumentation ist minimalistisch. Kann ich nicht bestätigen. Von den Modulen (die andere als Zend entwickeln) und Kommentaren (der User) abgesehen. Natürlich kann PHP keine Veranwortung über die Korrektheit von Aussagen anderer über PHP übernehmen. Für relativ neue Funktionen muss man manchmal warten bis eine Doku vorhanden ist. Google macht sonst den Rest.
  • Der Umgang mit in-place-Funktionen. sort() ist das klassische Beispiel aus jeder Programmiersprache, die in-place arbeitet. Sie verändert die Eingabeliste direkt und gibt keine Rückgabeparameter zurück. Während es in python viele dieser Sorte gibt, so sind es in PHP nur ein paar in-place-Funktionen. Die passen eigentlich nicht in das restliche Konzept. Aber wenn es sauber dokumentiert ist, halte ich es für akzeptabel
  • Durch die Modularität der php.ini ist es schwer ein Framework für alle Versionen zu schreiben. Wenn der PHP-Entwickler seine Berechtigungen sehr streng einstellt, dann läuft das Framework unter allen Konfigurationen. Für die alten $HTTP_POST_VARS gibt es Hack, die auch ich immer einbaue.
  • PHP hat magic_quotes und register_globals. PHP gesteht sich diese Fehler ein und macht in der Dokumentation darauf aufmerksam (zB 1, 2)
  • Funktionsnamen sind nicht einheitlich. Keine einheitlichen Richtlinien für underscores (zB urlencode und base64_encode). Verb oder Objekt? (zB create_function und var_dump). “2″ oder “to”? (zB strtoupper und bin2hex). Als Referenz sei “PHP has inconsistent function naming” genannt. python und Perl haben überall klare Richtlinien
  • Datenbank-Unterstützung. … ist unter PHP wunderbar und für alle möglichen Datenbank stehen die Funktionen bereit. Auch persistente Verbindungen sind möglich. Ich gebe den Vorwürfen recht, dass viele nicht wissen flush-Funktionen umzugehen

Ich denke hier kommt man zu keinem Ergebnis. Wenn man es genau nimmt, kann man jeden Unterschied als Vor- sowieso Nachteil nennen. Das Einzige was wirklich nicht in Ordnung ist, wenn das Verhalten von Quelltext unvorherrsehbar ist (wenn die Erwartung auf Logik oder der Dokumentation basiert). Und hier hat PHP wirklich einige Defizite. Wie schon oft genug erwähnt, bin ich immer mehr mit python unterwegs, jedoch warten noch einige PHP-Skripte auf mich. Nichts destotrotz… ich glaube es ist alles reine Gewohnheitssache. Seit ich weiß, dass ein String (in einem Vergleich mit einem Integer) in einen Integer verwandelt wird, wird mir auch nicht mehr der Fehler passieren. Genauso haben ich schon alle Funktionsnamen intus. Jetzt wird man argumentieren “es soll nicht nur Gewohnheitssache sein, sondern für alle leicht erlernbar. Nicht nur fürjahrelang eingefleischte Geeks”. Das stimmt natürlich. Wenn wir von dem Standpunkt ausgehen, kann ich aber genauso gegen jede andere Programmiersprache argumentieren. PHP halte ich für Anfänger gut. Als ich diese Aussage in IRC tätigte, argumentierten zwar alle entgegen, aber mein Hauptargument ist, dass man sich keine Gedanken um Datentypen machen muss und große quelltextdesign-technische Freiheit hat. Der Umgang mit Parametern ist auch wesentlich leichter als in python. Natürlich kann ich trotzdem nicht PHP empfehlen. Schließlich bleibt man auf jeden erlernten Programmiersprache stecken. Und das soll nicht PHP sein…

Wer sich jetzt fragt, wieso ich den Post auch in “Philosophie” gegeben habe, darf sich mit der Frage befassen: Wann sind genug Argumente genannt, damit man “seine aktuelle” Programmiersprache wechselt und sich mit einer anderen befasst?

PageRank

Posted by on 2008.08.20 1 comment

Mit diesem PageRank-Rechner-Python-Skript ist es möglich den PageRank einer Webseite zu “decodieren”. Ich habe das nette Tool mal angeworfen und die Webseiten meiner Verwandten/Bekannten abgecheckt. Das Schlusslicht führen natürlich die Webseiten der Internetkonzerne an.

PR URL
0 lukas-prokop.at/blog/
0 project-jua.at
0 brg-viktring-board.at/lp
0 knol.google.com
1 brg-viktring-board.at
1 cprokop.org/blog
1 prokop82.at
2 lowk-spotting.at
2 petertheone.com
2 devnull.michael-prokop.at
4 michael-prokop.at
5 pocoo.org
5 grml.org
8 amazon.de
9 flickr.com
9 bloglines.com
9 wikipedia.org
10 google.com

:-) Wer sich wundert, wieso mein Blog und meine Pseudo-Homepage so niedrig gestuft sind: Ganz einfach. Der PageRank sollte jedem bekannt sein und basiert auf der Anzahl der Links auf eine Seite. Wenn eine PR-hohe Seite auf eine PR-niedrige verweist, wird die niedrige auch höher eingestuft. Soviel zu Theorie und in der Praxis habe ich so gut nirgends auf meine Projekte noch verwiesen. Außerdem ist die Domain sehr entscheidend. Eine funpic-Domain kann einfach nie hoch hinauskommen und brg-viktring-board.at/blog ist von brg-viktring-board.at stark beeinflusst. In der Realität zählt der PR aber nicht so viel. Wichtiger ist die Stichwortoptimierung. Zusätzlich hat Google in Updates am Algorithmus herumgeschraubt, um Google-Bomben wie diese nicht zuzulassen. Das soll sich mit lukas-prokop.at dann alles ändern. Man darf auf die Shutdown-Week gespannt sein (bzw. wird es ein bisschen länger dauern) :-)

PS: Außerdem verlinke ich viel zu gerne. Das ist sicher nicht gut für meinen PR :-/ :smile:

Meine Maturafächer – Teil I

Posted by on 2008.08.19 3 comments

Die Matura erwartet mich nächstes Schuljahr und jetzt stehe ich vor der schwierigen Frage: Was maturiere ich? Die Entscheidung fällt mir nicht leicht. Einerseits soll die Matura nicht zu schwer sein, weil ICH sie mir schwer machen möchte, es aber keine Probleme mit den Lehrern geben darf. Umgekehrt sollte die Matura als klarer Abschluss der Schule dienen und den Hinblick auf meine berufliche Zukunft setzen. Aber ich beginne ganz einfach. Ich poste einmal die Fächer, die zur Auswahl stehen:

D (WPF)E M FRZ GEO BIO H PHY CHEMIE ME INFO PUP

Gut… ich werde das ganze normale Maturamodell wählen: 3/4 mündl. und 3/4 schriftl (wenn ich bei dem einen 3 wähle, muss ich 4 beim anderen wählen). Da wir eine AHS mit musischem Schwerpunkt sind, ist schon einiges vorgegeben.

schriftl.: D E/FRZ M

Ich wähle auf jeden Fall Englisch. Es ist bekannt, dass ich nicht viel von Sprachen halte außer Englisch. Außerdem müssen wir als ME-Maturanten ME nehmen. Und in Hinblick auf berufliche Aussichten und mein Interesse wähle ich natürlich Informatik mündlich:

schriftl.: D E M (ME)
mündl.: WPF-Info (ME)

So… und das ist der kritische Moment. Was jetzt? Das bisherige ist klar, aber den Rest muss ich mir in den Sommerferien überlegen. Ich möchte auf jeden Fall bis Schulanfang eine Entscheidung haben und zu Weihnachten die ersten Arbeiten gemacht haben. Was fehlt? Die Entscheidung, ob ich mündlich oder schriftlich Musik antrete und 2 mündl. Fächer.

Ich werde jetzt ganz kommentarlos Fächer streichen. Vielleicht bin ich nicht für das Fach zu begeistern gewesen. Vielleicht mag ich nicht bei diesem Lehrer maturieren. Wer weiß…

D (WPF)E M FRZ GEO BIO H PHY CHEMIE ME PUP

Naja… ein paar Kommentare muss ich ja doch abgeben. WPF E darf ich nicht antreten, weil ich es dem Lehrer versprochen habe ^^ H (aka Geschichte) interessiert mich irrsinnig (gute Arbeit vom Lehrer ;-) ), aber es ist leider zu viel Stoff zu lernen. PHY sollte mein letzter Test entscheiden. Die resultierende Note war nicht ganz klar, aber sprach gegen einen Antritt. Jetzt bin ich eigentlich noch unentschlossen, aber eher nein.

Übrig bleiben 6 Fächer. In die enge Auswahl kommen D, M, Chemie und ME. Aber die endgültige Entscheidung muss ich noch fällen :-/

Ideen des Funky Caching

Posted by on 2008.08.18 1 comment

Bereits 2002 hat Rasmus Lerdorf in seinem Vortrag (Seite 25) auf der PHPCon die Ideen des Funky Cachings beschrieben.

Seine Idee: Du kommst zu einer Fehlerseite, weil sie nicht vorhanden ist. Du wirst umgeleitet auf generate.php. Du empfängst die ursprüngliche URL und schlägst in der Datenbank nach. Du generierst die Datei, die nachgefragt wurde. Du schreibst auf die Fehlerseite einen Hinweis, wo er die Datei jetzt finden kann. Die erweiterten Gedanken wären jetzt, dass du alle Dateien einmal im Monat von deinem Server löscht, weil wenn sie jemals noch gebraucht werden, werden sie eh neu generiert. Dann behält man immer den Überblick am Server. “Caching” ist in dem Sinne gemeint, dass die Dateien zwischengespeichert werden und evtl. auch wieder neu erzeugt werden. Das Ziel des Cachings (Zugriffsoptimierung) ist erreicht.

Die allgemeine Idee: Man generiert eine Seite und abgerufen wird das blanke HTML auf welches schneller zugegriffen werden kann. Idealerweise generiert man die Seite direkt an dem Erscheinen eines neuen Posts.

Wenn ich mir jetzt überlege… ich habe 85 Zugriffe an einem Tag (habe ich testweise 24 Stunden am 10.7.08 die Zugriffe aufgezeichnet – natürlich ohne IP-Adresse ;-) ) auf meinen Weblog. Der Weblog benötigt keine dynamischen Funktionalitäten wie ein Forum mit Usersystem. Viele rufen sowieso nur den RSS-Feed ab. 85 Zugriffe, dabei nur ~0.3 Posts pro Tag und jedes Mal muss die Datei neu erzeugt werden. Zahlt sich PHP-Caching dann nicht aus? (ich höre schon die Stimmen der WordPress-Nutzer: ja, es gibt ein WP-Plugin, welches solche Techniken nutzt, aber hin oder her: in WP muss immer der PHP-Parser gestartet werden und damit nutzt WP nicht die volle Funktionalität des PHP-Caching)

Damit ich jetzt wirklich möglichst repräsentative Zahlen habe, werde ich einmal überprüfen, welche Zugriffszeitdifferenz eine HTML-Seite von WordPress und die PHP-generierte Seite hat. Schauen wir einmal, ob es sich auszahlt und ich habe mir einmal ein paar Überlegungen gemacht, weil vielleicht wird es ein Teil vom CMS 1.0 :-)

Ein Beispiel, wieso ich RSS liebe…

Posted by on 2008.08.17 No comments

Der BRGblog wird täglich von rund 7-8 Spamkommentaren befallen. Phasenweise war es jetzt eine kurze Pause, aber jetzt bin ich wieder am regelmäßigen Löschen. Delete… Delete… Delete… Delete… Delete… *damn* 1 Kommentar zu viel gelöscht. Naja… Thunderbird geöffnet und das alte Kommentar per Copy&Paste kopiert. Voila! :-)

BlogActionDay 2008

Posted by on 2008.08.15 No comments

Fast schon wieder ein Jahr ist seit dem letzten vergangen. Aber es hat ja noch Zeit bis zum 15. Oktober. Dann startet wieder der BlogActionDay 2008 diesmal mit dem Thema “poverty”

Update 16.08.08: Heute hat mich auch der Newsletter zum nächsten BAD vom BAD-Team erreicht :-)

PHP-Sessions

Posted by on 2008.08.12 4 comments

Ich habe immer wieder miterlebt, dass Neulinge nicht verstehen, welche geniale Idee sich hinter PHP-Sessions versteckt. Sie verwenden $_SESSION und setzen session_start(), aber verstehen muss man es scheinbar nicht wirklich. Ich werde es einmal hier erklären und hoffe, dass der eine oder andere die Genialität erkennt.

Serverseitig
Serverseitige Speicherung von Daten ist kein Problem. Wir können in Datenbanken schreiben, in Textdateien oder die Daten bei jedem neuen Aufruf erzeugen. Die Daten können persistent gespeichert werden. Auf die Daten kann dann idealerweise nur das Skript selbst zugreifen und somit sind die Daten sicher vor Angreifern geschützt, die die Passwörter lesen möchten. Jedoch gibt es keine Variante den User zu einem Datensatz zuzuordnen. Das ist der große Nachteil. Die Useridentifikation ist ein grundlegendes “Problem” (wer für Anonymität im Internet ist, wird jetzt “Glück” sagen) von HTTP.

Das Useridentifikationsproblem
Das Grundproblem ist, dass HTTP verdammt stark an Amnesie leidet und nach Ablauf des Datentransfers alles wieder vergisst. Wir verlieren sämtliche Daten, die wir einfach in einer Variable ablegen.

Clientseitig
Abhilfe sollen dafür Cookies schaffen. Cookies sind kleine Textdateien, die temporär am Rechner des Clients abgelegt werden. Ob Cookies abgespeichert werden, ist natürlich nicht sicher. Der HTTP-Header kann nur “bitten” die Daten zu speichern. Ob sie angenommen werden, ist unklar. Es gibt auch keine effiziente Methode herauszufinden, ob der Client Cookies akzeptieren wird oder nicht. Wird es jedoch akzeptiert, hat man die Möglichkeit einen Namen einem Inhalt zuzuordnen. Somit hätten wir das Problem gelöst. Wir können die Daten auf dem Client speichern und damit funktioniert die Useridentifikation wunderbar. Und die Cookies bleiben auch erhalten (Daten sind persistent). Nach Ablauf des Datentransfers bleiben die Cookies gespeichert und bei der nächsten Anfrage an den Server werden die Cookies mitgesendet. Jedoch haben wir bei Cookies ein sicherheitstechnisches Problem: Wir können nicht Usernamen, Passwort oder andere heikle Daten auf dem Client speichern. Die kann der Client ganz leicht ändern und der Client erhält nun statt dem Usernamen “MeisterLuk” den Namen “admin”. Sämtliche Daten, die am Client gespeichert werden, sind unglaubwürdig!

Zusammenfassung
Ich fasse nochmals kurz zusammen:

  • Wir können serverseitig wunderbar sämtliche Daten speichern und sie sind sicher vor Hackern. Jedoch ist es schwer einem User einen Datensatz zuzuordnen.
  • Wir können clientseitig jedem Benutzer beliebig viele Cookies mitgeben und können dann jedem User einen Datensatz zuordnen. Jedoch sind Daten vom Client unglaubwürdig, weil er sie leicht ändern kann. Wir können somit keine sensiblen Daten speichern

Die Lösung des Problems ist eine Technik, die die Vorteile beider Techniken zusammenfasst:
PHP-Sessions
Die geniale Idee von PHP-Sessions ist es am Client eine Identifikationsnummer zu speichern. Dieser Identifikationsnummer wird am Server ein Datensatz zugeordnet. Sprich: Wir speichern am Client ein Cookie mit dem Namen (zB) “SID” (für “Session-Identification”) und speichern darin einen einzigartigen Wert, der den User identifiziert. Bei einer Anfrage (zB einer Webseite) wird diese SID an den Server geschickt. Dieser sucht den Datensatz mit der SID. Und diesem Datensatz befinden sich zB Username und Passwort. Da der Benutzer nie die serverseitig gespeicherten Daten zu Gesicht bekommt, sind die Daten sicher und glaubwürdig. Akzeptiert der User den Cookie mit der SID nicht, so bekommt er einfach keinen Zugang (zB zu einem Administratorenbereich). Jetzt könnte noch jemand auf die Idee kommen und sagen: was ist wenn ich so lange die (clientseitig gepsicherte) SID so umändere, bis ich die SID vom Administrator erhalte? Die Wahrscheinlichkeit, dass du im Lotto gewinnst ist größer als die Wahrscheinlichkeit die SID vom Administrator zu erfahren (ich weiß leider nicht mehr die genaue Zahl). Wenn du ein Sicherheitsfanatiker bist, kannst du auch eine zweite SID hinzufügen, weil sich die Wahrscheinlichkeit dann exponentiell vergrößert. Man kann SIDs auch an die URL anhängen und sie somit über GET mitsenden. Diese Variante ist jedoch eher unsicher, weil Leute gerne den vollen Link mitsenden und somit auch ihre SID. Man sollte die Cookies-Variante bevorzugen. Oder im Idealfall beides. Auf die PHP-SID kann mit session_id() zugegriffen werden. Somit wirken beide Nachteile der Techniken nicht mehr.

Wen es interessiert: Die Aufgabe einen Datensatz einer SID zuzuordnen übernimmt nicht der Programmierer. Sämtliche Daten werden einfach in $_SESSION gespeichert und sind beim nächsten Webseitenaufruf verfügbar. Es ist nur notwendig session_start() vor dem Ablauf des Skripts zu starten. PHP speichert die $_SESSION-Daten in einem temporären Verzeichnis. Bei einem XAMPP befinden sie sich in tmp/. Ein guter Webhoster erlaubt auch Zugriff auf dieses Verzeichnis. Hat der Server irgendwelche serverseitigen Probleme mit Sessions (kommt nur selten vor), löscht man alle Dateien des Verzeichnis’ und das Problem ist gelöst.

Die RSS-Auslese

Posted by on 2008.08.07 No comments

Insgesamt 3 Tage war ich mit dem ToDo-Punkt “RSS-Feeds sortieren” beschäftigt. Mein Ziel war es die RSS-Feeds so durchzuschauen, dass ich die nächsten 2 Jahre mich nicht darum ärgern muss. Die Durchführung ist genau vorgelegt: ich sammle alle möglichen interessanten Feeds und lösche dann einige heraus, die zu unwichtig für mich sind. Als Resultat erhalte ich die wirklich interessanten, die ich die nächsten 2 Jahre lesen werde.

Die Liste bestand ursprünglich aus über 200 Feeds. Einige davon sind jedoch veraltert (vor allem im Webdevelopment-Bereich findet man zahlreiche “tote” Feeds) oder entsprechen nicht meinen Aufnahmekriterien. Die resultierende Liste beinhaltet rund 110 RSS-Feeds zu Blogs, die meinem Interessenbereich entsprechen oder etwas besonderes im Web sind. Und wie schaut es mit dem Lesen aus? Ich war jetzt 2-3 Tage sage und schreibe 2 Stunden pro Tag mit dem Lesen beschäftigt. Das fängt an bei den aktuellen Entwicklungen von xhtml5 im WhatWG und endet bei einer 50-jährigen Frau, die seit 1999 mit Webdevelopment zu tun hat. Natürlich umfasst mein Interessengebiet auch Programmiersprachen, News und halt die Blogs meiner Kollegen/Bekannten/Verwandten. Das kann durchaus informativ sein. In Blogs, in denen 5-10 Beiträge pro Tag erscheinen, lasse ich auch durchaus ein paar Beiträge aus, aber Aktuelles aus Bereichen wie Hardware hört man nur in unbekannten Blogs, die niemand liest.

Eine Tatsache nervt mich unheimlich: Manche Themen werden nur in den Blogs angesprochen, die sich auf das jeweilige Thema spezialisieren. Umgekehrt schlug die Nachricht von Knol unheimlich ein. Mir tut mein Beitrag regelrecht leid. Meine Lösung für dieses Problem: Private Blogs sollten sich als diese kennzeichnen und klar zum Ausdruck bringen, dass sie um die Themen handeln, die die jeweilige Person beschäftigen. Andere Blogs sollten auf ein Thema konzentriert sein und nur zu diesem bloggen. Das hieße die Nachricht von Knol dürfe nur in Googles Blog, Webdevelopment-Blogs, SEO-Blogs, andere WebWeblogs und in privaten Blogs erwähnt werden. Die privaten Blogs abonniert man dann nur von Personen, die man persönlich kennt. Ich selbst werde einmal dieser Philosophie zu folgen versuchen. Es ist mir nach der Regel gestattet über Knol zu bloggen (da dies ein “privater Blog” ist), aber ich möchte es selbst nicht. Für solche Nachrichten gibt es sinnvollere Quellen.

Naja… und damit es nicht weiterhin bei 2 Stunden pro Tag bleibt, lösche ich jeden Tag 3-4 Feeds raus. Aktuell fällt es mir noch leicht. Vor allem Blogs, die man neu abonniert hat, löscht man gerne (wobei ich nicht dieser Philosophie folgen möchte ;-) ). Naja… Thomas A. Limoncelli hatte Recht: Das moderne Pendant zu Mailing-Listen sind RSS-Feeds. Wenn man unproduktiv sein will, liest man den ganzen Tag und glaubt damit produktiv zu sein :-)

PS: Wer Probleme beim Abonnieren von neuen-alten RSS-Feeds mit Thunderbird hat, sollte sich diesen kurzen Beitrag von pc-wissen-online.de durchlesen