Ein paar Perlen der Herkunftsangaben:

- Portugal / Baden-Württemberg
- Deitschland / Hessen
- VR China / keine Angabe
- was für eine dumme frage !!! D  / Sachsen

Für die Game Mechanics: Dem 50.000sten Mitzeichner spendier ich ein Bier (oder auf Wunsch Eis). Mitmachen!

Natürlich mussten auch supertolle neue Webportale für den Wahlkampf der Parteien her. Versuchen wir doch mal einige der Vergleiche aus dem eingangs erwähnten Artikel auch auf diese anzuwenden, wobei ich mich auf CDU (www.team2009.de), FDP (my.fdp.de) und SPD (www.wahlkampf09.de) beschränken möchte. Falls die Reihenfolge nicht durch Untersuchungsergebnisse vorgegeben ist, sortiere ich alphabetisch.

Technologien

Die CDU ist laut Header "powered by PHP/5.2.0-8+etch13" und setzt den Metatags zufolge das Content Management System Joomla in der Version 1.5 ein. Ich möchte eigentlich keinen Flamewar heraufbeschwören, aber Joomla? really?

Die FDP hält es mit PHP/4.4.4-8+etch6, das auf einem Debian System mit Apache/2.2.3 läuft.

Die SPD setzt auf Ruby on Rails, das von Passenger 2.0.6 ebenfalls auf einem Debian System mit Apache/2.2.9 ausgeliefert wird.

Webstandards

Alle drei Seiten geben an den Standard XHTML 1.0 Transitional einzusetzen.
Tatsächlich muss die CDU sich hier mit 71 Fehlern und 55 Warnungen die größte Lüge zuschreiben lassen. Es folgen die FDP mit 28 und die SPD mit 11 Fehlern.

Geschwindigkeit

Mit YSlow kann man sich die Performance einer Seite in Bezug auf das Gesamtergebnis für den Besucher (samt aller eingebundenen JavaScript/CSS Bibliotheken und Bilder) ausgeben und auswerten lassen.

Auch hier finden wir auf dem letzten Platz die CDU mit der Wertung F und 32 von möglichen 100 Punkten. Es werden satte 21 externe CSS- und 13 JavaScript-Bibliotheken eingebunden.
Im Portal der SPD wurden zumindest die CSS Bibliotheken zu einer Datei zusammengecached, sodass immernoch ein F dafür aber mit 49 von 100 Punkten herauskommt. Allein das Hinzufügen von Expire-Headern bei statischen Inhalten würde hier eine Menge bewirken, oder geht eh niemand davon aus, dass ein Besucher ein zweites Mal vorbeikommt?
Die FDP liegt mit der Wertung B und 84 Punkten weit vorn. Faierer Weise muss aber gesagt werden, dass die FDP mit ihrer geschlossenen Community lediglich eine einfache Login-Seite anzeigt und somit kaum Spielraum für Performance-Fehler vorhanden ist.

Inhalte

Man könnte argumentieren, dass es dafür noch etwas früh sei. Dennoch bin ich der Meinung, dass eine Suche nach "Wahlprogramm" auf den Wahlkampfseiten der Parteien Ergebnisse produzieren sollte.

So sieht das bei der CDU aus:

Die FDP stellt unter der untersuchten Adresse my.fdp.de gar keine öffentlichen Inhalte bereit. Ein Vergleich der internen Funktionen wäre zwar durchaus interessant, würde an dieser Stelle aber den Rahmen sprengen.

Bei der SPD sieht man:

Das muss man wohl nicht mehr kommentieren.

Was noch?

Unter welchen URLs können die Inhalte der Seiten erreicht werden? Am Beispiel der Registrierung:

CDU: /index.php?option=com_ubg_tdregistration&Itemid=56
FDP: /webcom/register.php
SPD: /unterstuetzer/new

Look Ma, REST bei der SPD. Und Denglish.

Wie sehen die Registrierungsformulare aus? 

CDU	FDP	SPD

Wie ist das nun bei der CDU mit der Zweckbindung von erhobenen Daten? Dass man die PLZ gerne hätte kann ich verstehen, dass es ein Pfilchtfeld ist, nicht. Ich verkneif mir jetzt mal Kommentare über Terrorismusabwehr und andere Ausreden.

Wie regieren die Portale auf Anfragen nach nicht existierenden Seiten?

CDU: Reagiert mit dem Statuscode "200 OK" und zeigt direkt (keine Weiterleitung) die Startseite ohne irgendeinen Hinweis an.
FDP: Reagiert mit dem Statuscode "302 Found" und leitet auf die Startseite weiter ohne irgendeinen Hinweis anzuzeigen.
SPD: Reagiert mit dem Statuscode "404 Not Found" und zeigt die Fehlermeldung "Es ist ein Fehler aufgetreten. Dieser Link führt zu keinem gültigen Dokument." an.

Fazit

Ich hoffe niemand erwartet hier jetzt ernsthaft eine Wahlempfehlung.
Würde die technische Umsetzung der Wahlkampfportale irgendeine Rolle bei der Entscheidung für oder gegen eine Partei spielen, wäre der heutige Sieger eindeutig die SPD. Allerding wirkt das Gesamtkonzept aller Seiten noch ziemlich unausgereift. Inhalte fehlen fast völlig. Es bleibt zu hoffen, dass an dieser Stelle noch nicht Schluss ist mit "diesem Web-Zwei-Null-dingens".

Das große ABER war bisher: Manipuliert man (beispielsweise in einer RJS Antwort) die Seite und fügt so z.B. einer Liste ein Element hinzu, gilt die ausgelagerte Funktionalität dafür nicht, sie müsste auf das hinzugefügte Element erneut angewandt werden. Das ist nun vorbei! Seit Version 1.3 biete jQuery eine neue Event Methode an: live()

Beispiel:

$("form input[type=text]").live("click", function(){
  alert($(this).val());
});

Der so hinzugefügte click-Handler gilt nun für alle Elemente, auf die der Selector "form input[type=text]" zutrifft, egal wann sie (ggf. auf erst später durch JavaScript) entstanden sind. Phantastisch, oder?

Ob das auch 2010 betrifft wird sich zeigen. Die wirtschaftliche Lage wird unter Umständen 2010 wieder eine bessere sein, jedoch ist die generelle Profitabilität wohl der größere Faktor, den es hier für das O’Reilly Konferenz Team zu bedenken gibt. Persönlich finde ich dies schade und kann die Beweggründe auch nicht ganz nachvollziehen. Auch wenn mir hier der Einblick in die Finanzierung der RailsConf Europe fehlt, kann ich mir nicht vorstellen, dass eine gut besuchte Fachkonferenz, deren Teilnehmer 700€ Teilnahmegebühr bezahlen und die noch dazu von namhaften Firmen gesponsert wird, auf solch wackligen Füßen stehen soll. Aber was hilfts – die Entscheidung ist gefallen. Aus meiner Sicht werden wir 2010 die Neuauflage der RailsConf Europe sehen, denn das O’Reilly Team wird die Pause sicher nutzen, um einige Entscheidungen zu überdenken, vor allem hinsichtlich der doch recht preisintensiven Location.

See you in 2010 :)

[via]

Unter http://github.com/jeanmartin/cascading_javascripts_reloaded/tree/master habe ich eine ab Rails 2.2 funktionierende Version veröffentlicht.

Viel Spaß!

Eine der größeren Fallen, in die ich getappt bin bisher ist das Installieren des Mysql-Gems, da ein naives "gem install mysql" mit verschiedensten Fehlern abbrach. Drum hier die kurze Anleitung, die man sich sonst von vielen Seiten im Netz zusammensuchen muss, exklusiv zusammengefasst auf code-schubser.de:

1. Unbedingt MySQL x86 (=32bit) Version installieren (findet man hier). Die mit Leopard mitgelieferte Ruby Version mag die 64bit Variante von MySQL anscheinend nicht und spricht nicht mit ihr. (Sollte es für die Installation der 32bit Version schon zu spät sein, bitte die Tabellen sichern, die 32bit Variante über die schon installierte 64bit Version installieren und die Dumps wiederherstellen. Das sollte die 64bit Version erfolgreich auf die 32bit "downgraden").
2. Jetz der eigentliche tricky-Part: Die Installation des Gems an sich. Die Pfade zu den Libraries sind nicht so einfach rauszufinden, daher hier die Abkürzung:

sudo env ARCHFLAGS="-arch i386" gem install mysql -- \ --with-mysql-dir=/usr/local/mysql --with-mysql-lib=/usr/local/mysql/lib \ --with-mysql-include=/usr/local/mysql/include

Kopieren, in Terminal einfügen, freuen.

Das ist selbstverständlich grundsätzlich der richtige Weg. Hier zeigen wir Ihnen nun aber eine Möglichkeit, bei einzelnen Massenzuweisungen die Restriktionen  von attr_accessible zu umgehen:

Man öffne ActiveRecord::Base und definiere ein paar neue Methoden:

class ActiveRecord::Base
 
  # 
  def unsafe_update_attributes(attrs)
    self.unsafe_attributes = attrs
    save
  end
 
  # 
  def unsafe_update_attributes!(attrs)
    self.unsafe_attributes = attrs
    save!
  end
 
  # 
  def self.unsafe_create(attrs)
    o = new
    o.unsafe_attributes = attrs
    o.create
  end
 
  # 
  def self.unsafe_create!(attrs)
    o = new
    o.unsafe_attributes = attrs
    o.create!
  end
 
  # 
  def unsafe_attributes=(attrs)
    return if attrs.nil?
    attrs.each do |(k,v)|
      send("#{k}=", v)
    end
  end
 
end

Das ganze kann beispielsweise in eine Datei im /lib/ Verzeichnis. Das require in der environment.rb (oder einem Initializer) nicht vergessen. Die Verwendung sollte selbsterklärend sein…

Mein schneller Workaround:

In der Datei magic_multi_connections-1.2.1/lib/magic_multi_connections/connected.rb, Zeile 85:

ClassMethods in MyClassMethods

umbenennen und in Zeile 82 wiederholen.

Nebenbei, magic_multi_connections läuft in Rails 2.1.1 nicht mehr ohne weiteres (in 2.1.0 funtionierte es noch).

Workaround hierfür:

In der Datei magic_multi_connections-1.2.1/lib/magic_multi_connections/connected.rb, die Zeile 20 ändern in:

return unless target_class

In einem Projekt setze ich ferret (via acts_as_ferret) für ein paar kleine Suchfunktionen und memcached (via cache_fu) zum -wait for it..- Cachen ein. Die Analyse eines missglückten Capistrano-Deployments ergab, dass ein Starten des ferret DRb Servers ohne laufendes memcached fehlschlägt: No connection to server
Mich wundert sehr, dass dieses Problem bei früheren Deployments nicht aufgetreten ist, obwohl sowohl ferret als auch memcached bereits zum Einsatz kamen.

Lösung: Die eingesetzten Capistrano-Tasks (ferret, memcached), die beide zuvor von "deploy:start" und ":stop" abhingen, müssen voneinander abhängen .. genauer: ferret:start und ferret:stop müssen jeweils nach bzw. vor memcached:start und memcached:stop ausgeführt werden: so

Übrigens: Das gleiche gilt für BackgrounDRb. Es scheint, als wenn das Laden der Rails Environment ein erreichbares memcached voraussetzt.