Damit der Rocket Rentals Server richtig auf den Request reagieren kann, muss im Admin Frontend ebenfalls eine Subdmain angelegt werden. Dazu logged man sich unter beim Hosting ein. Im oberen Menü wählt man “Sites”. Aus dem linken Menü wählt man dann “Subdomain” aus. Das Host Feld beinhaltet den Namen der Subdomain. Der Redirect Type ist “No flag”. Der Redirect Path ist “/<subdomain>_<domain>_<tld>”. Beispiel: “/staging_wheelmap_org”. Nach dem Speichern dauert es höchstens 15 Minuten, bis die Änderungen aktiv sind. In der Zwischenzeit können wir aber schon eine neue Datenbank anlegen. Das ist besonders wichtig, da wir nicht die Produktivdatenbank versehentlich verändern wollen, wenn die Auftraggeber die neue Version ausprobieren und dabei Daten manipulieren. Auch das kann auf der Admin Seite des Rocket Rentals Frontend geschehen. Usernamen und Passwort für die Datenbank nicht vergessen!

Dann muss auf dem Rechner, der das deployment durchführt eine Capistrano Erweiterung installiert werden:

sudo gem install capistrano-ext

Danach muss die deploy.rb Datei etwas angepasst werden. Füge folgende Zeilen an den Anfang der Datei:

# config/deploy.rb

set :stages,        ['staging', 'production']
set :default_stage, 'staging'
require 'capistrano/ext/multistage'

Jetzt werden für jede Umgebung im Rails Projekt unter config/deploy/ eine eigene Datei mit dem Umgebungsnamen angelegt:

mkdir -p config/deploy
touch config/deploy/staging.rb
touch config/deploy/production.rb

Aus der bisherigen deploy.rb Datei müssen folgende Zeilen in die config/deploy/production.rb kopiert werden:

# config/deploy/production.rb

set :application, 'domain_tld' # Beispiel: wheelmap_org
set :db_names, :production => 'prod_db_name'
set :db_user, 'prod_db_username'
set :db_password, 'prod_db_password'
set :rails_env,   'production'

Anschließend müssen diese Zeilen in der config/deploy.rb auskommentiert oder gelöscht werden.

In der config/deploy/staging.rb Datei müssen jetzt die Angaben für die Staging Umgebung gemacht werden:

# config/deploy/staging.rb

set :application, 'subdomain_domain_tld' #Beispiel: staging_wheelmap_org
set :db_names, :production => 'staging_db_name'
set :db_user, 'staging_db_username'
set :db_password, 'staging_db_password'
set :rails_env,   'staging'

Nun sind alle Vorbereitungen getroffen und wir können die Staging Umgebung einrichten:

cap staging deploy:setup

Danach kann die Anwendung deployed werden:

cap staging deploy:cold

Will man die Live Version deployen führt man folgenden Befehl aus:

cap production deploy

Bei Problemen oder Fragen einfach einen Kommentar hinterlassen.

Ich habe das Vergnügen für meinen aktuellen Kunden DaWanda ein Gadget für StudiVZ zu entwickeln. Ein Gadget besteht aus einer XML Datei, die definiert, um welche Anwendung es sich handelt, wer der Author ist usw. Dazu gehören wahlweise mehrere CSS und Javascript Dateien. Nachdem man alles in eine Zip Datei, die den gleichen namen wie die XML Datei trägt, gepackt hat, kann man die Anwendung in die Sandbox hochladen und ausprobieren. Eine Beispiel Datei könnte so aussehen:

<?xml version="1.0" encoding="UTF-8"?>
<Module>
  <ModulePrefs
    title="Example StudiVZ Gadget"
    title_url="http://www.christophbuente.de"
    author="Christoph Bünte"
    author_email="info@christophbuente.de"
    description="Example description"
    screenshot="http://www.christophbuente.de/images/screenshot.jpg"
    thumbnail="http://www.christophbuente.de/images/thumbnail.jpg">
    <Require feature="opensocial-0.8" />
    <Require feature="views" />
  </ModulePrefs>
  <Content type="html" >
    <![CDATA[
      <script>
        function init() {
          // Put initialization code here
        }
        gadgets.util.registerOnLoadHandler(init);
      </script>
    <div id='container'></div>
    ]]>
  </Content>
</Module>

Jede Interaktion des Benutzers mit der Anwendung wird mit Hilfe weiterer Javascript Funktionen behandelt. Dazu stehen eine Reihe eingebauter Funktionen aus dem Opensocial Container bereit. Darüber hinaus haben die Entwickler von StudiVZ eine API Beschreibung der zusätzlichen Funktionen bereit gestellt. Was aber, wenn man nun nicht mit Javascript entwickeln möchte bzw. kann? Es besteht die Möglichkeit Flash Content einzubinden. Man kann aber auch ein beliebiges Backend einbinden. Dieses Backend muss nur 2 Bedingungen erfüllen:

• Es muss auf HTTP Requests reagieren können und beliebiges HTML,CSS und JavaScript zurück liefern
• Es muss im Namen des Applikationsbenutzers einen OAuth signierten Request an die StudiVZ REST API schicken können.

Wie im Schema zu sehen, sendet der User einen Request, um die Applikation zu benutzen. Der Container liest darauf hin den Inhalt der XML Datei aus. Dort ist neben einem DIV Container lediglich ein externes Javascript referenziert. In dem Javascript sind einfache Methoden zum Navigieren und Interagieren definiert. Das rendern des HTML übernimmt ein Ruby Backend. Das braucht zum Render unter Umständen noch zusätzliche Informationen wie zum Beispiel Name und Foto des Benuter usw. Diese Informationen holt es sich mit einem OAuth signierten Request von der abgebildeten REST API. Das vom Ruby Backend erzeugte HTML rendert der Opensocial Container in einem IFrame im Browser des Benutzers. Für eine bessere Übersicht definieren wir im XML einzelne Views, die jeweils einen eigenen Endpunkt im Backend haben. Eine einfache gadget.xml mit 2 definierten Views für Profil und Vollansicht mit Backend Anbindung:

<?xml version="1.0" encoding="UTF-8"?>
<Module>
  <ModulePrefs
    title="Spitzenmässiges StudiVZ Gadget mit Backendanbindung"
    title_url="http://www.christophbuente.de"
    author="Christoph Bünte"
    author_email="info@christophbuente.de">
    <Require feature="opensocial-0.8" />
    <Require feature="views" />
  </ModulePrefs>
  <Content type="html" view="profile" >
    <![CDATA[
      <script type="text/javascript" src="http://www.yourbackend.com/profile.js" ></script>
      <div id='profile'></div>
    ]]>
  </Content>
  <Content type="html" view="canvas" >
    <![CDATA[
      <script type="text/javascript" src="http://www.yourbackend.com/canvas.js" ></script>
      <div id='canvas'></div>
    ]]>
  </Content>
</Module>

Das referenzierte Javascript ist ebenfalls sehr schlank. Darin wird lediglich eine Backend URL aufgerufen und deren Response Body in das profile bzw. canvas div geschrieben.

function init{
  var url = 'http://www.yourbackend.com/profile/'
  var params = {};
  params[gadgets.io.RequestParameters.AUTHORIZATION]=gadgets.io.AuthorizationType.SIGNED;
  gadgets.io.makeRequest(url, requestCallback, params);

}

function requestCallback(obj) {
	document.getElementById('profile').innerHTML = obj.data;
}

Damit die REST API benutzt werden kann, muss man sich an ihr Authentifizieren. Da das Backend aber dumm ist, hat es keine Userdaten, um sich dort anzumelden. Glücklicherweise ist der Request aus dem Javascript mit dem verschlüsselten Authentifierungsdaten des angemeldeten Anwendungsbenutzers signiert. Mit deren Hilfe können wir einen neuen, signierten Request erzeugen, den die API akzeptieren wird. Doch zuerst muss die Glültigkeit der Signatur überprüft werden:

sudo gem install oauth --source http://gemcutter.org

require 'oauth'
require 'oauth/consumer'
require 'oauth/request_proxy/action_controller_request'
require 'oauth/signature/rsa/sha1'
require 'oauth/signature/hmac/sha1'

class ApplicationController < ActionController::Base

  before_filter  auth_required

  def oauth_required
    cert_file = File.join(RAILS_ROOT, 'public', 'public.cer')
    cert_str = File.read(cert_file)
    consumer = OAuth::Consumer.new(ConsumerToken, cert_str)

    begin
      pass = OAuth::Signature.build(request, :consumer => consumer).verify
      logger.info "Signature verification returned: #{pass}"
    rescue OAuth::Signature::UnknownSignatureMethod => e
      logger.error "ERROR "+ e.message
    end

    render :text => "OAuth access denied", :status => :unauthorized  unless pass
  end

Die URL für das öffentliche Zertifikat wird mit jedem Request mit geschickt. Einmal runterladen sollte reichen. Ich denke, man muss es nicht bei jedem Request erneut vom StudiVZ Server laden. Den Consumer Token findet ihr in der OAuth Section eurer Gadget Sandbox (http://www.meinvz.net/GadgetDeveloper/GadgetOAuth/xxx). xxx ist deine Gadget ID.

Sollte der before_filter nicht abbrechen war die Signatur korrekt und der Request kann bearbeitet werden. Aus einem mir nicht bekannten Grund ist der Request des Containers an das Backend mit der RSA-SHA1 Methode signiert. Dafür wird das Zertifikat benötigt. Für den Request an die API muss die HMAC-SHA1 Methode verwendet werden. Dafür wird ein neuer Consumer benötigt:

def get_owner
  consumer = OAuth::Consumer.new(ConsumerToken, ConsumerSecret,
      :signature_method => 'HMAC-SHA1',
      :site => "http://sandbox.gadgets.apivz.net",
      :scheme => :query_string,
      :http_method => :get)
  requestor_param = {:xoauth_requestor_id => params[:opensocial_owner_id]}.to_param
  access_token = OAuth::AccessToken.new(consumer)
  response = access_token.get("/social/rest/people/#{params[:opensocial_owner_id]}/@self?#{requestor_param}")
  owner_attributes = JSON.parse(response.body)['entry']
end

Feedback, Fragen und Kritik sind immer gerne willkommen.

Die verschiedenen Test Frameworks haben ihre Vor- und Nachteile. Test::Unit ist relativ einfach und schnell. test/spec und RSpec hingegen deutlich lesbarer, jedoch auch langsamer. Sie eigenen sich deshalb besser, um die Tests als Dokumentation zu verwenden. Test::Unit und test/spec verwenden für Viewtests den Umweg über die Controller, was sie im Vergleich zu RSpec deutlich langsamer macht. In Rspec testet man jede Schicht des MVC Musters separat. Das Verhalten der jeweils anderen Schichten wird mit Mocks und Stubs simuliert. Integration Tests mit Cucumber testen dann das Zusammenspiel aller Schichten.

Carlos Dandos und José Valims Remarkable ist das mit Abstand großartigste Plugin für Ruby on Rails, was mir seit langem über den Weg gelaufen ist, denn es reduziert Tests auf das nötigste! Man schreibt in unglaublich expressiver Form, was das erwartete Verhalten ist. Das auf RSpec basierende Remarkable testet mit einer Vielzahl von Custom Matchers die Erwartung ab.

Ein Beispiel für ein Model Validation Test in Test::Unit

class UserTest < Test::Unit
  def test_user_not_valid_if_name_is_blank
    user = User.create
    assert user.invalid?
    assert_equal :blank, :user.errors[:name]
  end
end

Ein Beispiel für ein Model Validation Test in test/spec

context 'User validations' do
  specify 'user should not be valid if name is blank' do
    user = User.create
    user.should.not.be.valid
    user.errors[:name].should == :name
  end
end

Ein Beispiel für ein Model Validation Test in RSpec

describe User do
  it 'should not be valid if name is blank' do
    user = User.create
    user.should_not_be_valid
    user.errors[:name].should == :blank
  end
end

Und jetzt der gleiche Test mit Remarkable:

describe User do
  it { should validate_presence_of(:name) } # RSpec syntax
  should_validate_presence_of :name # Remarkable macro syntax
end

Ok, was musst du tun, um Remarkable verwenden zu können? Falls noch nicht geschen, solltest du das Gem Verzeichnis von Github als Quelle für weitere Gems lokal registrieren:

sudo gem sources -a http://gems.github.com

Danach müssen die benötigten Gems installiert werden:

sudo gem install rspec -v 1.2.6
sudo gem install rspec-rails -v 1.2.6
sudo gem install remarkable_rails

Für alle, die noch eine Rails Version < 2.2 verwenden müssen zusätzlich den I18n Backport von Sven Fuchs installieren:

sudo gem install svenfuchs-i18n

Abschließend müssen im Rootverzeichnis des entsprechenden Rails Projektes noch einige helper scripte generiert werden:

ruby script/generate rspec

Welche Matcher bringt Remarkable mit?

• Matcher für alle Validierungen mit allen Optionen
• Matcher für alle Assoziationen mit fast allen Optionen
• Named Scopes und Massenzuweisungsmatchern
• Datenbank Matcher für Indexes usw.

Ein typischer Unit Test mit Remarkable könnte so aussehen:

require File.expand_path(File.dirname(__FILE__) + '/../spec_helper')

describe User, 'validations' do
  should_validate_presence_of   :username, :email, :password
  should_validate_length_of     :username, :minimum => 6
  should_validate_acceptance_of :agreement
end

describe User, 'associations' do
  should_have_many :images
  should_have_many :posts
  should_have_one  :profile
end

describe User, 'database' do
  should_have_column :activated, :type => :boolean
  should_have_index  :username
end

describe User, 'named scopes' do
  should_have_scope :with_image, :joins => :images
  should_have_scope :activated,  :conditions => { :activated => true }
end

Und von nun an möchte ich nicht mehr hören, dass testen zu schwer sei. Alles Ausreden!

In diesem Sinne, Test frei.

Um mit Rails auf dem Mac zu beginnen, gibt es zwei Möglichkeiten:

1. Kompilieren und installieren aller benötigten Komponenten
2. Benutzen einer Applikation, die schon alles mitbringt.

Getreu dem Motto dieses Artikels, empfehle ich den schnellen, einfachen Weg Ryan Rauum stellt auf seiner Website eine Cocoa Anwendung zur Verfügung, die bereits alle Komponenten – bis auf die Datenbank – in einer Anwendung bündelt. Die Installation ist so einfach, wie bei jeder anderen Anwendung.

• Herunterladen
• DMG Datei doppelt anklicken
• Locomotive Symbol in das Programmverzeichnis ziehen

Als Datenbank empfehle ich für die ersten Schritte MySQL. Über den Produktiveinsatz von MySQL mag man streiten, aber um einfach mal anzufangen reicht MySQL völlig aus. Die Dateien für sehr viele Betriebsysteme stehen auf der download Seite bereit. Die Installation besteht eigentlich nur noch aus dem entpacken des tar.gz Archivs und starten der darin enthaltenen .pkg Datei. Eine Anleitung hat MySQL auch online gestellt.

Nachdem die Datenbank nun läuft ist es Zeit Locomotive zu starten. In der Applikation kann nun ein beliebiges Projekt erstellt werden (Apfel + N). Dazu gibt man den Namen und Pfad an, in dem das neue Projekt erstellt werden soll. Wer glücklicher Besitzer einer Textmate Lizens ist, klickt rechts auf das erstellt Projekt im Locomotive Fenster und wählt: “Edit in Textmate”. Es geht aber auch jeder andere Editor, um die wenigen Schritte zum laufenden Projekt zu gehen.

Die Datei config/database.yml im Projektverzeichnis enthält die Angaben, um Rails mit der Datenbank kommunizieren zu lassen. Hier sind in der bei der Verwendung von MySQL lediglich die Datenbanknamen für development, test und production anzugeben. Bei Bedarf kann hier auch der Benutzer, Passwort und Host bzw. Socket angepasst werden. Der schnellste Weg zu den drei Datenbanken ist mit Hilfe des Terminals:

mysql -uUser -pPasswort

In der geöffneten mysql shell sind die drei create Anweisungen nötig

create database projektname_development;
create database projektname_test;
create database projektname_production;

So, das war es eigentlich schon. Nachdem mit Hilfe von Locomotive der Server für das Projekt gestartet wurde, sollte man im Browser unter der Adresse: http://localhost:3000 eine Erfolgsmeldung sehen:

Welcome aboard. You’re riding the Rails!

“Wer rastet, der rostet.” – So geht es auch Software-Entwicklern. Wer sich nicht ständig nach neuem umschaut und den imaginären Werkzeugkasten mit neuen Tools füllt, wird irgendwann selbst zum alten Eisen gehören. Deswegen habe ich schon vor einiger Zeit angefangen, Ruby on Rails in meine Repertoire aufzunehmen. Diese Woche habe ich in einem 4 Tage Workshop mein Wissen über Ruby und Rails weiter ausbauen können.

[ad#vert-banner]

David A. Black, Autor des Buches “Ruby for Rails” ist für diesen Workshop aus New Jersey, USA angereist. Neben einem ganzen Tag für ActiveRecord und REST, wurden auch Themen wie “routing, testing, caching, deploy, plugins, rjs und javascript behandelt. Das Ganze war gespickt mit hunderten von ad hoc Beispielen, die David in seiner ganz eigenen Art in die Konsole oder den irb hackt.

Derartig tiefgreifende Kenntnis über eine bestimmte Thematik ist mir bisher noch nicht begegnet. Klar, arbeit man hier und da mit Leuten zusammen, die deutlich fitter sind als man selbst. Doch David “lebt” Ruby seit Jahren.

Um hier nicht nur meine Freude für Ruby und Rails zum Ausdruck zu bringen, sondern vielleicht auch ein nützliches Detail zu liefern, möchte ich das Test Framework Selenium erwähnen. Damit ist es möglich über die hoffentlich bereits geschriebenen Unit-, Functional- und Integrationtests hinaus, die Anwendung in einem echten Browser zu testen. Damit kann der Kunde sehr schnell sehen, was geht und was nicht. Und was noch viel wichtiger ist: wie es aussieht in verschiedenen Browsern aussieht.

Die Installation ist schnell und einfach. Im Hauptverzeichnis des Rails Projektes installiert wird das Plugin mit Hilfe des folgenden Kommandozeilen Befehls installiert:

 ruby script/plugin install selenium

Anschließend generiert man eine Testdatei im Ordner test/selenium mit folgendem Befehl:

 ruby script/generate selenium login.rse

Der generierte Testfall muss nun noch editiert werden, um die Applikation sinnvoll zu testen. Dabei können sämtliche Benutzerinteraktionen in lesbarer Form geskriptet werden. Die Kommandoreferenz findet man hier. Sollte die Anwendung bisher noch nicht im Testmodus verwendet worden sein, ist es nötig, die Testdatenbank auf den neuesten Stand zu bringen:

 rake db:migrate RAILS_ENV=test

Damit die Tests auch durchführbar sind, muss der Server im Testmodus gestartet werden:

 ruby script/server -e test

Ruft man jetzt die Rails Anwendung in einem beliebigen Browser auf (http://localhost:3000/selenium) sieht man das Admininterface von Selenium. Hier lässt sich einstellen, welche Tests laufen sollen. Darüber hinaus lassen sich noch die Geschwindigkeit und Highlighting variieren. Ein Klick auf den “Play-Button” im oberen rechten Fenster lässt die Show beginnen. Eine ausführliche Anleitung zur Benutzung des Interface findet man ebenfalls auf der selenium Webseite. Nach belieben können weitere Tests generiert werden und erscheinen dann automatisch im linken Fenster neben dem bereits erstellen login test.

Abschließend möchte ich Benjamin und Mathias danken, dass sie David nach Berlin gebracht haben. Es war spitze!

[ad#vert-banner]

Für mich als eingefleischten Java Entwickler ist die Syntax sicher die größte Umstellung beim erlernen einer neuen Programmiersprache. Doch Ruby und damit auch Rails macht es dem Entwickler durch gut lesbaren code sehr leicht, die Semantic des Codes zu verstehen. Dazu kommt, daß Rails dem Entwickler durch sorgfältig durchdachte Konventionen bereits viele Entscheidungen abnimmt. Wo kommt der Code für die Controller, die Tests hin, wo lege ich Bilder und statischen Inhalt ab, wie benenne ich Dateien und Datenbank Tabellen? All diese Fragen führen im Projektalltag durch Permutation zu einer riesigen Anzahl von Möglichkeiten, die ständig Entscheidungen verlangen. Und wo mehrere Entwickler zusammen arbeiten, fallen die Entscheidungen nicht immer gleich aus, was letztlich zur Entropie des Projektes beiträgt.

In dem genannten Buch werden anhand eines ca. 150 seitigen Tutorials alle Facetten des Rails Frameworks zumindest gestreift, und in mehreren anschließenden Kapiteln amüsant vertieft. In dem Tutorial wird das Leben eines Webentwicklers am Beispiel eines Webshops beschrieben. Kurze Iterationen und frühes Feedback vom Kunden unterstützen den agilen Entwicklungsprozess ebenso, wie kurzer, gut lesbarer Code, der sich schnell ändern und testen läßt. Von Langeweile, wie bei den üblichen Hello Word Tutorien ist hier keine Spur!

Besonders beeindruckend fand ich neben den bereits implementierten xml und string output Methoden die dynamisch erzeugbaren Finder methoden, um Objekte in der Datenbank anhand bestimmter Attribute zu finden. Kombiniert mit deklarierbaren Objekt Assoziationen ergeben sich daraus mächtige Werkzeuge, die in Java Projekten regelmäßig eine Diskussion und Implementierungsorgie auslösen. Das folgende Beispiel enthält eine zur Laufzeit dynamisch erzeugte Methode, die einfach zu lesen ist und keines Kommentares bedarf.

users = User.find_all_by_firstname_and_lastname ("Dave", "Thomas")

Mit diesen ersten Eindrücken hinterlasse ich den geneigten Leser und möchte jeden animieren, sich dieses wertvolle Buch zu kaufen. Ruby on Rails bringt wieder Spaß in die Webentwicklung.

Neulich wollte ich in einer kleinen Rails Web-Applikation (siehe aktuelle Literatur) eine Ansicht einer 1:n Beziehung zweier Objekte in Listenform erstellen. Die Anforderung war allerdings, die Liste nach der Anzahl der Kinder zu sortieren und dabei die Objekte zuerst anzuzeigen, die keine Kinder haben.

[ad#vert-banner]

Damit die Ergebnismenge des SELECT Statements auch die Eltern Objekte enthält, die keine Kinder besitzen, muss ein LEFT JOIN verwendet werden. Grundsätzlich ist das zwar etwas mehr Aufwand für die Datenbank, aber dennoch schaffbar, ohne eine Ewigkeit warten zu müssen. Mit Hilfe von Indizierungen lässt sich die ganze Sache auch hinreichend beschleunigen. Das folgende SQL Statement erfüllt diese erste Anforderung:

SELECT p.name, c.name
FROM parents AS p
LEFT JOIN children AS c
ON p.id=c.parent_id

Allerdings fehlt hier die Sortierung. Das zweite Problem ist, dass das Feld c.name für alle kinderlosen Eltern NULL ist, und somit nicht gezählt werden kann. Folgendes Statement behebt zwar das Problem, aber die Ausführung braucht bei großen Tabellen Jahre.

SELECT IF(c.id IS NULL,0,COUNT(*)) AS kids, p.name
FROM parents AS p
LEFT JOIN children AS c ON p.id=c.parent_id
ORDER BY kids
GROUP BY p.id

Die lange Ausführungsdauer hat vor allem einen Grund: Die Sortierung geschieht auf einer Spalte, die effektiv nicht existiert, sondern erst zur Laufzeit mit Hilfe der Count Funktion erzeugt wird. Das heißt es muss erst ein kompletter Join über beide Tabellen durchgeführt werden, ehe eine Sortierung stattfinden kann. Auch eine Limitierung der Ergebnisliste mit Hilfe von LIMIT ändert daran nichts, denn die würde erst nach der Sortierung durchgeführt.

Um diese lange Wartezeiten zu vermeiden, habe ich mir folgendes überlegt: Man baut in die Tabelle der Elternklasse eine Spalte ein, die die Anzahl der Kinder speichert. Nun muss “nur noch” beim hinzufügen und löschen eines Kindes diese Spalte gepflegt werden. Das heißt, meine Applikation ist für die Datenintegrität zuständig.

Zurück zu Rails, denn da ist dieses Funktionalität bereits an Board. Getreu dem Motto “Konvention über Konfiguration”, erzeugt man lediglich die Spalte in der Tabelle der Elternklasse. Diese trägt den sprechenden Namen <kindertabelle>_count also in diesem falls children_count. In der Kinderklasse wird nun noch deklariert, dass der Zähler automatisch aktualisiert wird.

class Child < ActiveRecord::Base
  belongs_to :parent, :counter_cache => true
end

Und siehe da, nun lässt sich eine normaler Finder verwenden, um den View aufzubauen. Komplett ohne JOIN!

@parents = Parent.find(
  :all,
  :limit => 20,
   ffset => @parent_pages.current.to_sql[1],
   rder => "children_count ASC, parent ASC")

Da jetzt nur noch real existierende Spalten für die Sortierung verwendet werden und eine effektive Limitierung der Ergebnismenge möglich ist, dauert die Anfrage nur noch wenige ms.

Thx Rails!