In Japan habe ich mit einigen Leuten, vor allem Deutschen und US-Amerikanern, über Reiskocher diskutiert. Die generelle Meinung war, dass man so etwas “zu hause” nicht erhält. Ich war gegenteiliger Ansicht und sollte recht behalten. Bei der Boutique Sumlai in St. Gallen habe ich mir für ca. 120 Franken einen schicken Kocher gekauft. Gestern habe ich in einem Heftchen des Interdiscount eine Werbung für Reiskocher gesehen. Preis: ca. 20 Franken, heruntergesetzt von etwa 80. Wahrscheinlich war da jemand in der Einkaufsabteilung überzeugt vom durchschlagenden Erfolg dieser Kocher und muss nun merken, dass die in der Schweiz nicht so häufig gebraucht werden. Jedenfalls hatten meine lieben Freunde in Japan definitiv unrecht. Die Teile kriegt man bei uns. ...

Roger hat mich auf einen Artikel der heutigen NZZ am Sonntag hingewiesen. Dieser fasst ganz kurz die aktuelle Forschung im Bereich Kaffee zusammen. Das Resultat ist für mich sehr überraschend. Nicht nur, dass dem Kaffee praktisch keine schlechten Wirkungen nachgewiesen werden können, sondern der Konsum von Kaffee wirkt sich gar positiv aus. Zum Beispiel: Und mindestens sechs unabhängige Studien führten zu dem ermutigenden Schluss, dass regelmässige Kaffeetrinker mit 60 bis 80 Prozent geringerer Wahrscheinlichkeit an Parkinson erkranken. Der Artikel ist leider nicht online erhätlich. Ich selber bezeiche mich als ehemaliger Koffeinsüchtiger. Beim Entzug litt ich über eine Woche an starken Kopfschmerzen. Nur harmlos scheint die Sache meiner Meinung nach also doch nicht zu sein.

Chong Hyang Gyun, wurde vom obersten Gericht Japans eine Beförderung verweigert. Die südkoreanische Frau, Tochter eines Südkoreaners und einer Japanierin, wollte eine Weiterbildung besuchen und so eine höhere Stelle in der Verwaltung einnehmen. Die Verwaltung verweigerte ihr jedoch dieses Recht, mit der Begründung, sie sei keine Japanerin, und so wandte sie sich an die Gerichte. 1997 entschied das Gericht von Tokyo (“Tokyo High Court”), dass sie tatsächlich das Recht hat, befördert zu werden und sprach ihr auch eine Entschädigung zu. Die Verwaltung, ihr Arbeitgeber, legte Rekurs ein und bekam jetzt vor dem obersten Gericht recht. ...

Ruby arbeitet sehr stark mit Exceptions, was die Fehlerbehandlung relativ einfach macht. Auch das Rails Framework arbeitet mit Exceptions. So wirft zum Beispiel der Code Project.find(@params["id"]) den Fehler ActiveRecord::RecordNotFound. Doch nachdem ich bei Rails sowieso so wenig Code schreiben muss, finde ich es irgendwie nicht sehr elegant für die Fehlerbehandlung noch viel zu schreiben. So sah mein erster Anlauf aus: begin @project = Project.find(@params["id"]) @page_title = "Project: " + @project.title rescue ActiveRecord::RecordNotFound @page_title = "Project not found" render "layouts/error", 404 end Und das ganze für jede Methode in dem Controller. Ich bin dann über Blöcke in Ruby gestolpert. Siehe den Link für eine Erklärung, was das ist. Damit habe ich im ApplicationController die Methode handle404 implementiert: def handle404(pagetitle) begin yield rescue ActiveRecord::RecordNotFound @page_title = pagetitle render "layouts/error", 404 end end So sieht der Code von vorher nun wie folgt aus: handle404("Project not found") { @project = Project.find(@params["id"]) @page_title = "Project: " + @project.title } Das bewirkt, dass im RecordNotFound-Fall ein 404 Fehler mit dem Titel "Project not found" generiert wird. So finde ich das schon recht elegant gelöst. Da ich aber erst seit sehr kurzer Zeit mit Ruby arbeite, weiss ich aber noch nicht, ob das so wirklich okay ist.

Ich hatte mich vor kurzem mal gefragt, wie koffeinfreier Kaffee eigentlich hergestellt wird, bin dann aber nicht auf die Frage zurück gekommen. Jetzt hat sich Urs Gehrig dafür interessiert und ein wenig recherchiert.

Auf Ruby on Rails aufmerksam geworden bin ich durch einen Artikel in Linux Magazin oder ähnlich. Wenn ich da schon gewusst hätte, dass Rails momentan so gehyped wird, ich hätte wahrscheinlich nicht damit begonnen. Das hat damit zu tun, dass ich eine extreme Abgenigung gegen jede Art von Hypes habe, ganz speziell wenn es um Programmiersprachen etc. geht. Aber ich bin froh, habe ich mich dieses mal nicht von diesen Gedanken leiten lassen. Nun, wieso Hype? Rails wurde gestern mit einem Slashdot Artikel ausgezeichnet. Dieser verweist auf einen sehr guten Artikel bei ONLamp namens Rolling with Ruby on Rails. Dieser erklärt kurz, was Ruby und Rails sind, zeigt die Installation unter Windows und führt dann mit einem Tutorial in Rails ein. ...

Seit kurzem ist das neue Projekt Wikinews online, welches als eine Fusion zwischen einer Zeitung und Wikipedia gedacht ist. Da musste sich auch die NZZ dazu melden und hat dies mit dem mehr schlechten als rechten Artikel Selbstverwaltung des Wissens gelöst. Michael schreibt dazu: Und freilich wird man auch nicht müde, immer wieder die gleiche Kritik anzubringen. Kann man sich auf Texte verlassen, die von “Amateuren” verfasst wurden? So geschehen in einem Beitrag in der Neuen Zürcher Zeitung. Witzigerweise widerlegt sich Stefan Krempl, der Verfasser, im selben Artikel gleich selbst. Dass es um die Wikinews geht, muss man erraten, denn das Wort kommt im Text gar nicht vor. Stattdessen verwechselt Krempl Wikimedia mit den Wikinews. Sein Fazit: Es ist wohl kaum denkbar, dass ein derart gravierender Fehler in einem Wiki unbemerkt geblieben wäre. Dagegen kann man davon ausgehen, dass der Beitrag in der Neuen Zürcher Zeitung auch in den nächsten 225 Jahren nicht verbessert wird. Wo er recht hat, hat er recht. Ich selber bin nicht unbedingt Fan von Wikinews aber aus anderen Gründen als von der NZZ angeführt. Bei Wikipedia werden Artikel oft über längere Zeit gut. Bei News-Artikeln fehlt aber diese Zeit, da es schnell gehen muss. Das Projekt werde ich trotzdem aufmerksam verfolgen. (Via Stefan Bucher)

Nach einer kurzen Diskussion in der deutschen Wikipedia scheint kaum jemand zu befürworten, dass dieses neue Anti-Spam-Attribut dort aktiv bleibt (Siehe meine Artikel Kommentar-Spam wird unattraktiver und Nachtrag zu rel=nofollow) Momentan wird auf Meta-Wikipedia darüber diskutiert, was weiter zu unternehmen ist.

Gerade habe ich noch über SQL Injection bei Rails geschrieben und nun habe ich mich auch schon dem Thema Cross-Site Scripting zugewendet. Wieder beziehe ich mich auf das Dokument Securing your Rails, dieses mal auf das Kapitel 2. Bei Rails ist die Verteidigung gegen Cross-Site Scripting so simpel, dass es keine Ausrede mehr gibt, das nicht zu tun. Bei PHP rege ich mich jeweils ein wenig über den sehr langen Funktionsnamen htmlspecialchars auf. Bei Rails lautet die Funktion einfach h. Und das ist auch richtig so, wird doch diese Funktion extrem oft benötigt. In der Praxis sieht das dann so aus: ...

Sicherheit von Web-Applikationen ist eines meiner Lieblingsthemen. So habe ich vor einigen Jahren ein Papier zum Thema SQL Injection und Cross-Site Scripting geschrieben. Dieses diente damals einem Firmen-internen Vortrag bei meiner Lehrfirma. Der Schwerpunkt dieses Papiers lag auf der Verhinderung der Angriffe mit Active Server Pages. Das Thema ist nach wie vor aktuell, und nach wie vor gibt es da viel zu tun. Bei der Evaluation von Ruby on Rails ist es für mich auch wichtig, wie ich da SQL Injection und Cross-Site Scripting verhindern kann. Das Manual Securing your Rails ist prominent auf der Startseite des Bereiches Dokumentation verlinkt und gibt Auskunft. Erstmal kümmert sich Rails um sehr viele Dinge selber. So werden ja viele Funktionen für den Datenbank-Zugriff der Daten automatisch generiert und diese sind gegen SQL Injection Probleme geschützt. Um bei einer eigenen Query (find_all heisst die Funktion dazu) keine Probleme damit zu erhalten, müssen die Benutzer-Eingaben bereinigt werden. Dazu kann man eine Methode verwenden, welche der Möglichkeit von “Prepared Statements” in anderen Frameworks nicht unähnlich ist. Ein Beispiel: ...