ePetition gegen Zensur im Internet

Zum Thema selbst möchte ich lediglich auf einige, die sich damit auskennen verweisen. 50.000 Mitzeicher werden benötigt, um zumindest angehört zu werden.  22.000 sind es aktuell (05.05. – 17:30 Uhr). Und weil wir doch alle Statistiken lieben:

Land Mitzeichner Einwohner (Mio.)
Deutschland / Berlin 1754 3,416 513,47
Deutschland / Hamburg 633 1,771 357,43
Deutschland / Bremen 206 0,663 310,71
Deutschland / Baden-Württemberg 2918 10,75 271,44
Deutschland / Bayern 3054 12,52 243,93
Deutschland / Sachsen 946 4,22 224,17
Deutschland / Hessen 1346 6,073 221,64
Deutschland / Nordrhein-Westfalen 3793 17,997 210,76
Deutschland / Niedersachsen 1602 7,972 200,95
Deutschland / Rheinland-Pfalz 703 4,046 173,75
Deutschland / Schleswig-Holstein 492 2,837 173,42
Deutschland / Saarland 172 1,037 165,86
Deutschland / Brandenburg 370 2,536 145,90
Deutschland / Thüringen 327 2,289 142,86
Deutschland / Mecklenburg-Vorpommern 208 1,68 123,81
Deutschland / Sachsen-Anhalt 298 2,412 123,55

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!

Wer ist hier RESTful?

Vielleicht erinnert sich der ein oder andere ja noch den Artikel Obama is RESTful aus den letztjährigen Wahlkampftagen in den USA. Seit nun auch hierzulande Politiker auf zum Teil peinlichste Art und Weise versuchen Obamas Wahlkampftaktiken zu imitieren findet man sie im Web ü-ber-all, wirklich, ohne Ausnahme.

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.

weiterlesen…

jQuery geht live()!

jQuery ist ja so schon toll. In Rails Projekten dank jRails sehr einfach verwendbar, da auch Funktionen wie "link_to_remote" weiter wie gewohnt genutzt werden können. Um unobtrusive zu sein, sollte man dabei aber auf genau diese verzichten und möglichst jedwede JavaScript Funktionalität auslagern, was mit jQuery meist auch Spaß macht.

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?

RailsConf Europe 2009 fällt aus

Obwohl der subjektive Eindruck volle Hallen und gut besetzte Seminarräume vermittelte, hat O’Reilly angekündigt, dass die RailsConf Europe 2008 nicht profitabel genug war. Zusammen mit der aktuellen Wirtschaftslage ist dies eine ungesunde Mischung und so zieht O’Reilly dieses Jahr den Stecker aus der RailsConf Europe und hat angekündigt, dass es 2009 keine Wiederholung der Konferenz geben wird.

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 :)

 

Das Internet

The Internet

[via]

Cascading Javascripts reloaded

Wer das plugin cascading_javascripts von RedHill Consulting nutzt und das auch unter Rails 2.2 vorhatte, wird enttäuscht feststellen, dass es nicht mehr funktioniert. Kein Grund zu verzweifeln, die Lösung naht:

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

Viel Spaß!

Mysql Gem unter MacOSX Leopard installieren

Um auch endgültig in den Entwicklerkreisen in Berlin/Mitte anerkannt zu werden, bin ich vor einigen Wochen auf ein MacBook umgestiegen. Die Einrichtung einer gewohnten Rails-Entwicklungsumgebung (nicht IDE, nur die tägliche Arbeitsumgebung), erfordert das Umgehen von einigen Hindernissen, da anscheinend unter MaxOS, speziell Leopard, alles nochmal ganz anders ist als es schon unter Windows anders war.

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.

attr_accessible umgehen

Kennen Sie das auch? Beim Testen oder in den Controllern der Administration der neuen Anwendung sollen per Massenzuweisung die Attribute eines Models gesetzt werden, aber im Model sind mal wieder einige Attribute wegen attr_accessible nicht massenzuweisbar…

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:

weiterlesen…

acts_as_ferret/lib/class_methods.rb to define ClassMethods

Wieder mal ein Problem beim Zusammenspiel zweier Plugins: acts_as_ferret & magic_multi_connections. Macht sich bemerkbar etwa beim Serverstart durch den o.g. Fehler.

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

 

capistrano, memcached, ferret und “No connection to server”

Darauf bin ich gestern gestoßen. Noch bin ich nicht ganz sicher, ob es nicht eine bessere Lösung gibt oder das Verhalten fälschlicherweise irgendwie von mir herbeigeführt wurde:

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.

←Older