Valider RSS-Feed mit Ruby on Rails

Im Netz habe ich einige Anleitungen gefunden, wie man Feeds mit Ruby on Rails erzeugt, die Ergebnisse fand ich aber entweder unzureichend oder sie waren nicht valide laut W3C. Deshalb hier der Code für den RSS-Feed, den man bei BookReporter.de findet.

Code im Controller:

def rss
@nachrichten = Nachricht.find(:all, :conditions => ["aktiv = 1"], :order=>"created_at DESC", :limit => 20)
render_without_layout
end

Und hier die View (rss.rxml):

xml.instruct!

xml.rss "version" => "2.0", "xmlns:atom" => "http://www.w3.org/2005/Atom" do
xml.channel do

xml.title       "BookReporter.de Nachrichten und Termine"
xml.link        url_for :only_path => false, :controller => 'nachrichten'
xml.description "BookReporter.de: Letzte 20 Nachrichten und Termine."
xml.language('de-de')
xml.tag!("atom:link", "href" => url_for(:only_path => false, :controller => 'nachrichten', :action => 'rss'), "rel" => "self", "type" => "application/rss+xml")
xml.pubDate      @nachrichten.first.created_at.rfc2822

@nachrichten.each do |n|
xml.item do
xml.title       n.titel
xml.link        url_for :only_path => false, :controller => 'nachrichten', :action => 'show', :id => n
xml.description truncate(textilize(n.hauptteil), length = 255, truncate_string = link_to("...",:only_path => false, :controller => 'nachrichten', :action => 'show', :id => n))
xml.guid        url_for :only_path => false, :controller => 'nachrichten', :action => 'show', :id => n
xml.pubDate     n.created_at.rfc2822
end
end

end
end

Jetzt muss noch folgender Code ins Layout und fertig ist der Feed:

<%= auto_discovery_link_tag(:rss, {:action => "rss", :controller=>"nachrichten"}, {:title =>"BookReporter.de Nachrichten und Termine"}) %>

BookReporter mit ersten Kritiken online

Gerade das Buch Tannöd ist eine der ersten Kritiken auf BookReporter: ein Buch welches es bis an die Spitze der Buchcharts geschafft hat. Während die einen sich mit dem Buch befassen, fragen sich andere ob die diversen Preise, wie Krimi des Jahres (hier negativer) gerechtfertigt sind. Außerdem hängt schon eine Klage wegen Urheberrechtsverletzung an. Wer übrigens lieber hören als lesen möchte, dem empfehle ich einen der vielen Podcasts zum Thema wie z.B. der hier verlinkte.

Mal sehen wie es mit Tannöd in den Charts weitergeht und ob es eine gute Idee von BookReporter war ausgerechtnet dieses Buch zu rezensieren.

Das Projekt selbst ist übrigens wieder in Ruby on Rails programmiert und auf dem Moviereporter-Server gehostet.

Wiki zum Thema Web 2.0

wikiIm Rahmen einer Fallstudienarbeit innerhalb meines Studium habe ich zusammen mit Mike und Dirk ein Wiki zum Thema Web 2.0 erstellt. Die Installation könnt ihr hier auf dieser Seite in der Kategorie Wiki nachlesen.

Inzwischen haben wir die Arbeit präsentiert und das Wiki ist öffentlich unter wiki.technixblog.de zu erreichen.

Weiteres zur Fallstudie könnt ihr im Blog von Prof. Kern nachlesen.

Unsere Präsentation könnt ihr hier herunterladen: wiki.ppt (PowerPoint, ca. 1 MB)

MediaWiki installieren

Vorgehen nach http://www.mediawiki.org/wiki/Installation.

Nach dem Download der aktuellen Version (1.8.1 vom 11.10.2006) wurde das Archiv auf dem lokalen Rechner entpackt und per FTP auf den Webserver hochgeladen.

Damit PHP 5 per CGI funktioniert mussten alle php-Dateien auf CHMOD 755 gesetzt werden.
Dann wurde die Seite im Browser aufgerufen und den Anweisungen gefolgt, sowie alle Angaben für die Umgebund und den Datenbankserver eingegeben.

Meilenstein: Wiki installiert.

Weiterlesen

Zugriffsschutz aktivieren

Damit noch niemand im unfertigen Wiki rumpfuscht wird das gesamte Verzeichnis per .htaccess geschützt.

Die Datei .htaccess erweitert und sieht nun so aus.

AuthType Basic
AuthName „Interner Bereich“
AuthUserFile (Pfad gelöscht *fg*)
Require valid-user
Order deny,allow
Deny from All
Satisfy any
AddHandler cgi-script .php

Zusätzlich muss die Datei .htusers angelegt werden. Diese enthält die einzelnen Nutzer und wird aus verständlichen Gründen nicht veröffentlicht.

Auswahl des Wikis und Abhängigkeiten

So, das Thema ist festgelegt.

Erstellung eines Wikis zum Thema „Web 2.0“

Beschränkung: PHP & MySQL.

Bevor es logeht lege ich eine passende Kategorie hier auf technixblog an, um alle Schritte zu dokumentieren. Damit auch meine beiden Mitschreiber ihre Tätigkeiten hier kurz dokumentieren können, richte ich zwei Nutzer für sie ein. Login ist jeweils der Name (Anfangsbuchstabe großgeschrieben). Als Initialpasswort habe ich den Namen einer uns allen bekannten, fußballverrückten Kommilitonin gewählt, wobei die Vokale großgeschrieben (alles andere klein) sind. Das Passwort kann (sollte) nach dem ersten Login geändert werden.

Auswahl der Plattform

Nach kurzer Überlegung kommt nur MediaWiki in Frage. Für den Server bietet sich technixblog.de an. Platz ist noch vorhanden, PHP- und MySQL-Üntersützung ebenfalls. Um das Wiki gut erreichbar zu machen, wird die Subdomain wiki eingerichtet. Das Wiki wird also unter wiki.technixblog.de erreichbar sein.

Einrichten von PHP5

Die aktuelle Version 1.8.1 benötigt PHP5. Da auf dem Webserver PHP4 als Standardumgebung gesetzt ist und PHP5 zusätzlich installiert ist, muss eine Richtlinie gesetzt werden, dass .php-Dateien mit PHP5 geparsed werden.

Dies geschieht mit ein .htaccess-Datei die in das Stammverzeichnis des Wikis kopiert wird.

.htaccess

AddHandler cgi-script .php

Da PHP5 als CGI eingebunden ist, müssen .php-Dateien ausführbar gesetzt werden (CHMOD 755).

Ein Test mit der Datei phpinfo.php funktioniert!

phpinfo.php

Die weiteren Anforderungen sind auf dem Webserver ebenfalls erfüllt. MySQL muss mindestens 4.x sein.

Abzählen von Sudoku-Gittern mit dem Dancing-Links-Algorithmus

Sudoku LogoDas in Java entwickelte Programm zum Abzählen von 3×3 Sudoku-Gittern mit dem Dancing-Links-Algorithmus ist nun samt Dokumentation fertig. Später wird noch ein Sudoku-Benchmark erscheinen, mit dem man die Leistung der Java Virtual Machine (JVM) für diesen speziellen Fall testen kann. Hier die Dateien zum runterladen:

dlx_sudoku.jar inkl. Quellen

dokumentation.pdf

java -jar dlx_sudoku.jar threads – Startet das Programm mit 10 Threads (Mehrprozessorfähig)
java -jar dlx_sudoku.jar – Startet das Programm ohne Threads

WordPress: Der Dateityp entspricht nicht den Sicherheitsrichtlinien

Beim Uploaden von einigen Dateitypen ziegt WordPress die Meldung Der Dateityp entspricht nicht den Sicherheitsrichtlinien an. WordPress prüft beim Hochladen den Dateityp und gibt bei unbekannten Typen diese Fehlermeldung aus.

Damit WordPress 2.0.4 zusätzliche Dateitypen kennt, müssen diese in die Datei /wp-includes/functions-post.php ab Zeile 970 eingetragen werden.

function wp_check_filetype($filename, $mimes = null) {
// Accepted MIME types are set here as PCRE unless provided.
$mimes = is_array($mimes) ? $mimes : apply_filters(‚upload_mimes‘, array (
‚jpg|jpeg|jpe‘ => ‚image/jpeg‘,
‚gif‘ => ‚image/gif‘,
‚png‘ => ‚image/png‘,
[…]
‚class‘ => ‚application/java‘,
‚tar‘ => ‚application/x-tar‘,
‚zip|jar‚ => ‚application/zip‘,
‚gz|gzip‘ => ‚application/x-gzip‘,
‚exe‘ => ‚application/x-msdownload‘
));
[…]

In meinem Fall habe ich die gewünschte Endung .jar einfach hinter die vorhandenen Endungen zip geschrieben und mit ‚|‘ abgetrennt.

Hybrid Landmark Routing

In meiner Seminararbeit über Topologiebewusstes, proaktives Ad-Hoc-Routing habe ich mich intensiv mit dem Optimized Link State Routing (OLSR) und dem Hybrid Landmark Routing (Hybrid LANMAR) beschäftigt. Da OLSR ohnehin recht gut dokumentiert und Hybrid LANMAR noch relativ neu ist, stelle ich den Teil zu Hybrid LANMAR online.

Wie der Name bereits andeutet, handelt es sich dabei um ein hybrides Protokoll, es vereint proaktives und reaktives Routing. Genau wie OLSR baut das Hybrid Landmark Routing auf ein bereits existierendes Verfahren auf. Hybrid LANMAR ist eine Optimierung des LANMAR Protokolls. Beide Protokolle nutzen die Annahme, dass es meistens Bewegungen ganzer Gruppen in MANETs gibt. Die eigentliche Optimierung bei Hybrid LANMAR liegt in einer verbesserten Behandlung des Falls, wenn sich einzelne Knoten nicht in einer Gruppe bewegen.

Hybrid Landmark Routing
Beispieltopologie Hybrid LANMAR

Wie in der Abbildung dargestellt kann man sich ein MANET mit bewegenden Gruppen (graue Ellipsen) vorstellen. Blaue Punkte sind die Knoten, die sich individuell bewegen und die ich externe Knoten nennen werde. Die grünen Linien sind die Verbindungen zwischen den Knoten. Ein schwarzes Dreieck stellt einen Gruppenführer dar. Es ist aber nicht ausgeschlossen, dass sich Gruppen mit der Zeit ändern und neue Mitglieder gewinnen oder verlieren.

Das Routingverfahren

Die Autoren von Hybrid LANMAR unterteilen das Routing in drei Bereiche: lokale Wegfindung, Finden von Gruppen und Auffinden einzelner Knoten, die nicht in einer Gruppe sind.

Lokale Wegfindung

Für das lokale Routing innerhalb eines bestimmten Bereichs wird das Fisheye Protokoll genutzt. Es begrenzt die Entfernung (Hops) auf einen relativ kleinen festgelegten Wert und ist ein proaktives Verfahren.

Finden von Gruppen

Damit auch außerhalb des lokalen Bereichs Wege gefunden werden können, wird das Verfahren um einen Gruppenführer (=GF) erweitert. Er ist Repräsentant seiner Gruppe und für die Vernetzung mit weiteren Gruppen zuständig. Sobald ein GF bestimmt wurde, fängt dieser an das gesamte Netzwerk über sein Dasein zu informieren. Doch wie wird ein GF bestimmt? Als GF wird der Knoten gewählt, der die meisten benachbarten Knoten in seiner Gruppe besitzt, üblicherweise sollte dies in der Mitte der Gruppe und nicht am Rand der Fall sein.

Finden externer Knoten

Beim klassischen LANMAR Protokoll ist jeder externe Knoten als seine eigene Gruppe definiert. Je mehr externe Knoten es gibt, desto mehr Gruppen existieren. Folglich sinkt die Skalierbarkeit. Hier setzt Hybrid LANMAR an und nutzt dafür ein reaktives Routingverfahren, das nicht ständigen, schlecht skalierbaren, proaktiven Aktualisierungen unterliegt, da es von der Gruppenstruktur getrennt arbeitet.

Ablauf der Wegefindung

Ein jeder Knoten speichert die drei Routingtabellen für lokales Routing, Routing innerhalb der Gruppen (engl.: Landmark Routing Table), Routing für externe Knoten und einen Zwischenspeicher über die Gruppenzugehörigkeit der Zielknoten lokal ab. Der Ablauf der Wegefindung sieht dann wie folgt aus:

  1. Existiert das Ziel bereits in der Tabelle für lokales Routing, wird nach dieser an den nächsten Knoten Weitergeleitet.
  2. Wenn das Ziel nicht in der Tabelle für lokales Routing steht, wird nach der Gruppenzugehörigkeit gefragt. Wie das genau passiert erkläre ich später.
  3. Konnte das Ziel einer Gruppe zugeordnet werden, wird das Paket in Richtung des GF dieser Gruppe weitergeleitet. Ist das Paket in der Zielgruppe angekommen, wird nach der Tabelle für lokales Routing verfahren.
  4. Wenn das Ziel keiner Gruppe zugeordnet werden konnte, handelt es sich um einen externen Knoten und es wird mit einem reaktiven Verfahren die Wegewahl bestimmt.

Wie wird die Gruppenzugehörigkeit bestimmt? Dazu muss man wissen, dass bei Hybrid LANMAR eine IP-Adresse in zwei Hälften aufgeteilt wird. Die erste Hälfte enthält die (variable) Nummer der zugehörigen Gruppe eines Knotens und die zweite Hälfte dessen eindeutige Kennung/Adresse. Als Gruppennummer wird einfach die Kennung des GF genutzt. Ist ein Knoten nicht Mitglied einer Gruppe, wird seine Gruppennummer auf null gesetzt. Um die Gruppenzugehörigkeit festzustellen wird ein verteiltes System zur Namensauflösung (DNS) mit der Kennung des Zielknotens befragt und als Antwort erhält man eine IP-Adresse mitsamt Gruppennummer und Knotenkennung.
Meiner Meinung nach liegen hier einige Schwachstellen in der Erklärung seitens der Erfinder von Hybrid LANMAR. Wie soll dieses verteilte DNS-System aussehen? Muss jeder x-te Knoten solche Informationen bereitstellen oder wie sieht dies in der Realität aus? Erzeugt ein solches System nicht zusätzliche Bandbreite?
Auch beim Routing zur nächsten Gruppe bleiben noch Fragen offen. Ist ein Paket von einer Gruppe bei der nächsten Gruppe angekommen, so soll nach dem Willen der Autoren nach der Tabelle für lokales Routing die Wegewahl bestimmt werden. Aber was ist wenn es eine große Gruppe ist und die Anzahl der möglichen Hops zu klein gewählt wurde? Hier hätte eine Grafik zur Erklärung vielleicht behilflich sein können.

Anwendungen in der Praxis

Der Entwurf zu Hybrid LANMAR ist vom September 2005 und damit noch sehr neu. Anwendungen in der Praxis wird man schwerlich finden, weshalb ich mich kurz auf die Resultate der Tests aus dem Entwurf beziehen werde.
Glaubt man den Statistiken, ist Hybrid LANMAR eine erfolgreiche Verbesserung des ursprünglichen LANMAR Protokolls. Es sind nur wenige Nachteile zu erkennen. Hybrid LANMAR benötigt etwas mehr Verwaltungsaufwand zur Wegebestimmung. Durch das reaktive Routing steigt außerdem die Verzögerung bis ein Paket übertragen wurde. Die Vorteile überwiegen, denn bei gleichem Durchsatz weist Hybrid LANMAR eine wesentlich höhere Anzahl erfolgreich zugestellter Pakete auf, je mehr externe Knoten es gibt. Das Ziel der Entwickler scheint erfüllt.

Kritik

Ursprünglich hatte ich in meiner Seminararbeit am Ende OLSR und Hybrid LANMAR verglichen. Da hier nur der Teil über Hybrid LANMAR zu finden ist und ich nicht alles neu schreiben wollte, habe ich einen passenden Abschnitt kopiert. Dieser befasst sich mit möglichen Problemen:
Bei Hybrid LANMAR wird es sich negativ auswirken, wenn eine Gruppe ihren GF verliert und dadurch bei allen Knoten der Eintrag aktualisiert werden muss. Während bei OLSR keine Änderungen an den IP-Adressen notwendig waren, baut Hybrid LANMAR auf eine Kombination von Knoten- und Gruppenkennung auf. Bei nicht angepassten Anwendungen kann dies zu Problemen führen, da sich die Adresse durch eine neue Gruppenzuordnung ändert. Auch die Rückgewinnung der Gruppenzugehörigkeit über das verteilte DNS-System lässt noch offene Fragen, die erst noch geklärt werden müssen.

Mehr Infos