acts_as_blog - :home

Mephisto per Capistrano deployen

2008-06-24T13:24:00Z

Nach dem Ausfall des Servers letzte Woche, mußte ich dieses Blog auf einem neuen Server aufsetzen. Ein passender Augenblick, das ganze sauber mit Capistrano zu machen. Dies ist eine kurze Zusammenfassung, wie auch du Mephisto auf einem Server mit openSuSE 10.2 und Plesk 8.4 (wie sie bei 1&1 angeboten werden) deployen kannst. Die Beispiele haben “acts-as-blog.net” als Beispieldomain. Du solltest entsprechend die Daten deinen Anforderungen anpassen.

Als allererstes solltest du eine Domain inklusive Webspace über Plesk anlegen. Plesk erzeugt daraufhin in /srv/www/vhosts/$DOMAIN unter anderem ein httpdocs- sowie ein conf-Verzeichnis. Die übrigen Verzeichnisse sind für das Deployment selbst uninteressant. Natürlich darf auch Ruby und die Rubygems auf dem Server nicht fehlen. Auch ein passendes Gem für deine Datenbank (MySQL, PostgreSQL) solltest du installieren. Dies kannst du über yast erledigen. Ich hatte ursprünglich auch Rails 2.1 installiert, doch wie sich später herausstellte, läuft Mephisto derzeit nur mit Rails 2.0.x, so daß ich Mephisto mit Rails 2.0.2 im Vendor-Verzeichnis deployen mußte. Das tzinfo-gem kannst du auch entweder direkt auf dem Server installieren oder im Vendor-Verzeichnis mitliefern. Zu guter Letzt habe ich auch noch den Mongrel mitinstalliert. Dies ist kein Muß, vermutlich würde es mit Webrick genauso funktionieren.

Der Apache (Version 2.2) muß natürlich als Proxy arbeiten. Dazu müssen die entsprechenden Proxy-Module geladen werden. Ich fand keinen Menüpunkt in Plesk, um diese Einstellung vorzunehmen, also habe ich in der /etc/sysconfig/apache2-Datei die Zeile, die mit APACHE_MODULES anfängt um ”proxy proxy_http proxy_balancer” erweitert. Spätestens jetzt sollte auch dir klargeworden sein, daß du ohne sudo nicht auskommen wirst. Einen sudo-losen Weg habe ich bislang nicht weiter ausprobiert.

Da Capistrano das Projekt unbedingt aus einem SCM-Repository deployen möchte, kannst du entweder das Vanilla-Mephisto von GitHub damit deployen, Mephisto auf GitHub forken oder ein komplettes eigenes Repository auf einer eigenen Maschine einrichten. Letztenendes ist es egal, für welchen Weg du dich entscheidest, solange du die korrekte URL für das Repository in der config/deploy.rb angibst.

Mephisto benötigt eine Datenbank, um deine Artikel zu speichern. Lege eine Datenbank und einen Benutzer für diese Datenbank mit Plesk an. Die Zugangsdaten für diese Datenbank solltest auch in den Production-Abschnitt der database.yml-Datei eintragen. Damit wäre die Datenbankverbindung konfiguriert.

Das Skript, was zuständig für das Starten des Mongrel ist, heißt script/spin. Bei mir sieht dieses Skript so aus:

#!/bin/sh
script/process/spawner -a 127.0.0.1 -p 8010 -i 3

Damit werden 3 Mongrels auf Port 8010-8012 gestartet. Wie viele Mongrels tatsächlich benötigt werden, ist abhängig davon, wie stark besucht die Webseite ist. Da ein Mongrel mit ca. 64MB Speicherverbrauch zu buche schlägt, sollte man auch nicht zu viele Mongrels auf einmal starten. Vergiß nicht, dieses Skript ausführbar (chmod +x script/spin) zu machen und es wieder einzuchecken!

Der Apache muß noch als Proxy für den Mongrel konfiguriert werden. Hierzu bietet Plesk an, daß man die Konfiguration der einzelnen virtuellen Hosts um eigene Konfigurationseinstellungen erweitern kann. Diese Einstellungen gehören in die /srv/www/vhosts/$DOMAIN/conf/vhost.conf-Datei. Ich habe eine entsprechende vhost.conf-Datei vorbereitet, die beim Deployment mithochgeladen und aktiviert wird. Hierzu habe ich in meinem Verzeichnis mit der Working-Copy von Mephisto die Datei config/vhost.conf mit folgendem Inhalt erstellt:

# Mongrel cluster configuration
<Proxy balancer://actsasblog_mongrel>
        BalancerMember http://127.0.0.1:8010
        BalancerMember http://127.0.0.1:8011
        BalancerMember http://127.0.0.1:8012
        Order deny,allow
        Allow from all
</Proxy>

RewriteEngine On

# Check for maintenance file and redirect all requests
RewriteCond %{DOCUMENT_ROOT}/current/system/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ /current/system/maintenance.html [L]

# Rewrite index to check for static
RewriteRule ^/$ /current/index.html [QSA]

# Rewrite to check for Rails cached page
RewriteRule ^([^.]+)$ $1.html [QSA]

# Redirect all non-static requests to cluster
RewriteCond %{DOCUMENT_ROOT}/current/%{REQUEST_FILENAME} !-f
RewriteRule ^/(.*)$ balancer://actsasblog_mongrel%{REQUEST_URI} [P,QSA,L]

Damit wäre alles bereit, mit Capistrano auf den Server hochgeschossen zu werden. Hierzu mußt du deine working copy capifien. Gib im Hauptverzeichnis deiner Working-Copy einfach capify . ein und Capistrano erzeugt zwei neue Dateien in deiner Working-Copy. (Capfile und config/deploy.rb) Es ist eine Glaubensfrage, ob du diese Dateien ins Repository einchecken solltest. Letztere ist bei Mephisto sogar explizit in der .gitignore aufgeführt.

Die config/deploy.rb-Datei solltest du nun an deine Anforderungen anpassen. Als Vorlage kannst du meine Datei benutzen:

set :application, "acts_as_blog"
set :repository, "git://meinrepository/acts_as_blog.git"

role :web, "acts-as-blog.net"
role :app, "acts-as-blog.net"
role :db,  "acts-as-blog.net", :primary => true

default_run_options[:pty] = true
set :deploy_to, "/srv/www/vhosts/acts-as-blog.net/httpdocs"
set :user, "actsasbloguser"
set :scm, :git
set :ssh_options, { :forward_agent => true }
set :use_sudo, false

set :common_dirs, ['public/assets']

namespace :deploy do
  desc "upload database configuration"
  task :upload_database_configuration, :roles => :app do
    run "mkdir -p #{shared_path}/config"
    config = File.read(File.join(File.dirname(__FILE__), "database.yml"))
    put config, "#{shared_path}/config/database.yml"
    run "ln -nfs #{shared_path}/config/database.yml #{latest_release}/config/database.yml"
  end

  desc "update virtual host configuration"
  task :update_vhost_conf, :roles => :web do
    run "mkdir -p #{shared_path}/config"
    config = File.read(File.join(File.dirname(__FILE__), "vhost.conf"))
    put config, "#{shared_path}/config/vhost.conf"
    sudo "ln -nfs #{shared_path}/config/vhost.conf #{deploy_to}/../conf/vhost.conf"
    sudo "/usr/local/psa/admin/bin/websrvmng --vhost-name=acts-as-blog.net"    # update plesk
    sudo "/usr/sbin/rcapache2 configtest"   # test apache configuration
    sudo "/usr/sbin/rcapache2 reload"      # reload apache configuration
  end

  desc "symlink common directories on server"
  task :symlink_common_dirs, :roles => :web do
    unless fetch(:common_dirs, []).empty?
      fetch(:common_dirs).each do |dir|
        run "rm -rf #{release_path}/#{dir} &&\
              ln -nfs #{shared_path}/#{dir} #{release_path}/#{dir}"
      end
    end
  end

  desc "set up common directories on server"
  task :setup_common_dirs, :roles => :web do
    unless fetch(:common_dirs, []).empty?
      dirs = fetch(:common_dirs).map { |d| File.join(shared_path, d)}
      run "umask 002 && mkdir -p #{dirs.join(' ')}"
    end
  end

  after "deploy:finalize_update", "deploy:symlink_common_dirs"
  after "deploy:setup", "deploy:setup_common_dirs"

  after "deploy:finalize_update", "deploy:upload_database_configuration"
  after "deploy:upload_database_configuration", "deploy:update_vhost_conf"
end

Da ich sowohl die config/database.yml als auch die config/vhost.conf explizit von der Revisionsverwaltung ausgeklammert habe, muß ich diese separat auf dem Server ablegen. Das erledigen die upload_database_configuration- und update_vhost_conf-Tasks. Die setup_common_dirs- und symlink_common_dirs-Tasks hatte ich bereits schon mal hier vorgestellt.

Damit wäre alles zum Deployment vorbereitet. Das eigentliche Deployment läuft dann so ab:


cap deploy:setup  # Verzeichnisse vorbereiten
cap deploy:check  # Prüfen, ob alle Schreibrechte ausreichen
cap deploy:cold   # Hoch damit!

Beim letzten Befehl sollte ein Haufen Zeilen vorbeiscrollen. Dies ist normal und kein Grund zur Besorgnis. Irgendwann wird sudo nach dem Paßwort fragen, um die vhost.conf einzubinden. Danach wird der Apache reloaded und die Mongrels gestartet. Damit sollte nun ein frisches Mephisto auf dem Server laufen. Sollten Probleme auftreten, so solltest du dir die Ausgaben von cap deploy:cold genau anschauen. Oft ist in den Meldungen das Problem klar zu erkennen.

Spätere Updates von Mephisto kannst du mit cap deploy durchführen. Alles weitere findest du in der Dokumentation auf der Capistrano-Website.

Building PostgreSQL on Mac OS X Leopard

2008-03-27T12:55:00Z

Some time ago I wrote a german article on how to install PostgreSQL on Leopard. It seems I struck a chord with many people. So I decided to make this article accessible to a wider audience by translating it to English. I modified and updated parts of it where appropriate. So here it is without further ado.

In the course of this article I will install PostgreSQL from source. While I tried to describe all the steps along the way, you should have at least some basic experience with the terminal. Be also aware that you will be required to make changes to vital system settings. Mistakes can render your system unusable if not completely dead. Don’t say I didn’t warn you! Having said that let me reassure you that most readers of the original article have succeeded in installing PostgreSQL.

To build PostgreSQL on your system you will need a C compiler. If you haven’t already done so please install the Xcode tools that came on your Leopard install DVD or grab a fresh copy from Apple’s Developer Connection. I will be installing PostgreSQL 8.3.1 which is the latest version at the moment but these instructions should work with later versions, too.

Grab the latest sources from http://www.postgresql.org/ftp/latest/. The file you will need is usually named postgresql-8.x.x.tar.gz or postgresql-8.x.x.tar.bz2. Extract the contents of that archive to some place convenient. Open the terminal and change into the directory containing the extracted sources. From there start the build process with this command.

./configure --prefix=/Library/PostgreSQL --enable-thread-safety \
--with-krb5 --with-bonjour --with-openssl --with-gssapi \
&& make && sudo make install

NB Even though Leopard and PostgreSQL now support DTrace you currently will not be able to build PostgreSQL with DTrace support as this only works on Solaris right now. Later versions of PostgreSQL might get fixed but no luck so far.

PostgreSQL usually runs with privileges of a special user. I chose user and group id 183 since it was unused on my system. To make sure this user/group id not already taken on your system use the following two commands to list all users/groups on your system and pick some other unused ids between 100 and 500 if neccesary.

dscl . -list /Users UniqueID
dscl . -list /Groups PrimaryGroupID

Unlike other Unix systems Leopard uses Open Directory to store user accounts. I’m going to be using dscl to create a user and group for PostgreSQL. (Adjust user and group ids if neccesary)

sudo dscl . -create /Groups/_postgres 
sudo dscl . -create /Groups/_postgres RealName 'PostgreSQL Server'
sudo dscl . -create /Groups/_postgres PrimaryGroupID 183          
sudo dscl . -create /Groups/_postgres UserShell /usr/bin/false
sudo dscl . -create /Groups/_postgres Password '*'
sudo dscl . -create /Groups/_postgres NFSHomeDirectory /var/empty

sudo dscl . -create /Users/_postgres   
sudo dscl . -create /Users/_postgres Password '*'
sudo dscl . -create /Users/_postgres RealName 'PostgreSQL Server'
sudo dscl . -create /Users/_postgres PrimaryGroupID 183
sudo dscl . -create /Users/_postgres UniqueID 183      
sudo dscl . -create /Users/_postgres UserShell /usr/bin/false
sudo dscl . -create /Users/_postgres NFSHomeDirectory /Users/Shared/PostgreSQL

If no errors occurred you should be able to test that newly created user by typing id _postgres. The response should look like this:

uid=183(_postgres) gid=183(_postgres) groups=183(_postgres)

Since I installed everything into /Library/PostgreSQL there’s some extra work needed to have all command line tools conveniently available. Either add /Library/PostgreSQL/bin to the shell’s $PATH or symlink all those tools to a directory that is already in the $PATH. I opted for the latter. Since Leopard comes with a pristine /usr/local directory it might be neccessary to create some directories first. Something like sudo mkdir -p /usr/local/{bin,man/man1,man/man7} should do the trick. To create all those symlinks you can use this little script.

#!/bin/sh

POSTGRES_DIR=/Library/PostgreSQL
DEST_DIR=/usr/local
SYMLINK_DIRS="bin man/man1 man/man7"

for CUR_DIR in $SYMLINK_DIRS; do
  for CUR_FILE in $POSTGRES_DIR/$CUR_DIR/*; do
    sudo ln -nfs $CUR_FILE $DEST_DIR/$CUR_DIR${CUR_FILE#$POSTGRES_DIR/$CUR_DIR}
  done
done

A quick check with <q>which psql</q> should reveal if everything went smoothly. Zsh users might need to rehash.

I decided to store the database in /Users/Shared/PostgreSQL. As this directory usually does not exist it must be created first.

sudo mkdir -p /Users/Shared/PostgreSQL
sudo chown _postgres:_postgres /Users/Shared/PostgreSQL

Now the database can be initialized. During the initialization process you will be asked to enter a password for the database superuser. Pick any password just don’t forget it. To initialize the database use this command.

sudo -u _postgres initdb -U postgres -A md5 -W -E UTF8 \
-D /Users/Shared/PostgreSQL/data

A successful initialization looks similar to this:

The files belonging to this database system will be owned by user "_postgres".
This user must also own the server process.

The database cluster will be initialized with locale de_DE.UTF-8.
The default text search configuration will be set to "german".

creating directory /Users/Shared/PostgreSQL/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 20
selecting default shared_buffers/max_fsm_pages ... 2400kB/20000
creating configuration files ... ok
creating template1 database in /Users/Shared/PostgreSQL/data/base/1 ... ok
initializing pg_authid ... ok
Enter new superuser password: 
Enter it again: 
setting password ... ok
initializing dependencies ... ok
creating system views ... ok
loading system objects' descriptions ... ok
creating conversions ... ok
creating dictionaries ... ok
setting privileges on built-in objects ... ok
creating information schema ... ok
vacuuming database template1 ... ok
copying template1 to template0 ... ok
copying template1 to postgres ... ok

Success. You can now start the database server using:

    postgres -D /Users/Shared/PostgreSQL/data
or
    pg_ctl -D /Users/Shared/PostgreSQL/data -l logfile start

I intend to use PostgreSQL on my machine for development with Ruby on Rails so I prefer logging all commands sent to the database. In a production environment that might impact performance negatively so be careful how much logging you really need.

Create in /var/log a directory for the log files.

sudo mkdir /var/log/postgres

I want PostgreSQL to send all log messages to the syslog daemon which in turn will write them to disk. Add to /etc/syslog.conf this line:

local3.*                                /var/log/postgres/postgres.log

To prevent the log file from growing until it fills up your whole disk add this to /etc/newsyslog.conf:

/var/log/postgres/postgres.log          644  5     *    @T00  J

Now create an empty log file and restart the syslog daemon.

sudo touch /var/log/postgres/postgres.log
sudo kill -HUP $(cat /var/run/syslog.pid)

Of course PostgreSQL must be told to use syslog. These two lines in /Users/Shared/PostgreSQL/data/postgresql.conf will take care of that:

log_destination = 'syslog'
syslog_facility = 'LOCAL3'

While you are editing this file you should tell PostgreSQL what to log. As I mentioned before, I want it all. (see PostgreSQL documentation: Error Reporting and Logging)

log_line_prefix = '%u@%h:/%d '
log_statement = 'all'

PostgreSQL is now ready to be launched. But it would be tedious to always start it by hand. I created a launchd script to have PostgreSQL start automatically at boot time.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>org.postgresql.postmaster</string>
    <key>UserName</key>
    <string>_postgres</string>
    <key>OnDemand</key>
    <false/>
    <key>ProgramArguments</key>
    <array>
        <string>/Library/PostgreSQL/bin/postmaster</string>
        <string>-D</string>
        <string>/Users/Shared/PostgreSQL/data</string>
        <string>-c</string>
        <string>log_connections=YES</string>
    </array>
    <key>ServiceDescription</key>
    <string>PostgreSQL Server</string>
</dict>
</plist>

Save this script as org.postgresql.postmaster.plist in /Library/LaunchDaemons and have it read by launchd using sudo launchctl load /Library/LaunchDaemons/org.postgresql.postmaster.plist. This is the moment of truth. Now you finally get to know if you screwed up somewhere along the way. This is what you should get. (Or at least something resembling that)

Venus:~ fastjack$ ps ax | grep postmaster
 5315   ??  Ss     0:00.31 /Library/PostgreSQL/bin/postmaster -D /Users/Shared/PostgreSQL/data -c log_connections=YES

The database should accept connections:

Venus:~ fastjack$ psql -U postgres template1
Password for user postgres: 
Welcome to psql 8.3, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help with psql commands
       \g or terminate with semicolon to execute query
       \q to quit

template1=#

As you might have guessed from the name, this is a blog about Ruby on Rails. This article would not be complete without describing how to install the Postgres gem so you can actually use the database to do something useful. Since I installed PostgreSQL in an unconventional location the Postgres gem will not be able to find it automatically. This command should take care of that:

sudo gem install postgres -- --with-pgsql-lib-dir=/Library/PostgreSQL/lib \
--with-pgsql-include-dir=/Library/PostgreSQL/include

If you have an Intel mac you will probably have to change that line to:

sudo env ARCHFLAGS='-arch i386' gem install postgres -- \
--with-pgsql-lib-dir=/Library/PostgreSQL/lib \
--with-pgsql-include-dir=/Library/PostgreSQL/include

That’s it. Now you’re ready to start hacking with Ruby on Rails

Plugin der Woche: active_record_defaults

2008-02-28T12:47:00Z

Ein Plugin, was mir heute ein wenig Arbeit erspart hat ist active_record_defaults. Damit kann man in ActiveRecord-Modellen Defaultwerte für einzelne Attribute festlegen, ohne sie im Schema zu verankern. Das Plugin findet sich unter http://svn.viney.net.nz/things/rails/plugins/active_record_defaults/. Die Benutzung ist denkbar einfach:

class Person < ActiveRecord::Base
  defaults :age => 16
end

Schon ist jede Person 16 Jahre alt, sofern nichts anderes angegeben wurde.

Rails 2.0

2007-12-07T15:51:00Z

Holt es euch, solange es heiß ist!

Eine recht ausführliche Liste aller Neuerungen gibt es hier.

Ich werde mal gleich eine kleine Testanwendung versuchen. Mal schauen, wie es sich anfühlt.

Update: 2.0.1 ist bereits raus. Ist wohl beim Release etwas schiefgelaufen.

PostgreSQL auf Mac OS X 10.5

2007-11-04T00:04:00Z

Vor einer Weile habe ich in meinem Blog geschrieben, wie man PostgreSQL auf Mac OS X 10.4 (aka Tiger) installiert. Seitdem ist eine Weile ins Land gegangen. PostgreSQL ist inzwischen bei 8.2.5 angekommen und es existiert eine 8.3 beta 2. Nicht ganz unerwähnt bleiben sollte auch die Tatsache, daß vor kurzem Mac OS X 10.5 (aka Leopard) erschien. Änderungen in Mac OS X 10.5 machen haben dazu geführt, daß meine alte Anleitung als überholt angesehen werden kann. Deshalb folgt hier die aktualisierte Version.

Für die Installation brauchst du Xcode 3.0. Es befindet sich auf der Installations-DVD von Leopard bzw. du kannst von von Apples Developer Connection herunterladen. Ist Xcode installiert, kannst du mit der eigentlichen Installation von PostgreSQL loslegen. Ich werde im Laufe dieser Anleitung PostgreSQL 8.3 beta 2 bei mir installieren, doch die einzelnen Installationsschritte sollten auch mit 8.2 und 8.1 ohne Änderungen funktionieren.

Warnung: Einige der folgenden Schritte (wie z.B. das Anlegen der Gruppe/User) führen Änderungen an wichtigen Systemeinstellungen durch. Unbedachte Änderungen und Fehler können hier schnell dazu führen, daß das System unbenutzbar wird. Sagt nicht, ich hätte euch nicht gewarnt! Ich habe anhand dieser Schritte PostgreSQL auf 2 Rechnern bereits erfolgreich eingerichtet. Statistisch gesehen, macht das eine Erfolgsquote von 100% (*auf die Schulter klopf*), doch ich kann nicht garantieren, daß es überall ohne Probleme abläuft. Solltest du Probleme haben oder gar Fehler in der Anleitung entdeckt haben, so kannst du mich gerne per Email kontaktieren (s. Impressum) oder einen Kommentar unter diesem Artikel hinterlassen.

Lade dir zuerst den Quelltext von PostgreSQL herunter. Unter http://www.postgresql.org/ftp/latest/ findest du stehts die aktuelle stabile Release. Die richtige Datei heißt in der Regel postgresql-8.x.x.tar.gz bzw. postgresql-8.x.x.tar.bz2. Extrahiere das Archiv an einer geeigneten Stelle und begib dich mit dem Terminal in dieses Verzeichnis. Von da aus, kannst du PostgreSQL mit folgender Zeile kompilieren und installieren:

./configure --prefix=/Library/PostgreSQL --enable-thread-safety \
--with-krb5 --with-bonjour --with-openssl --with-gssapi \
&& make && sudo make install

An dieser Stelle möchte ich anmerken, daß Mac OS X 10.5 DTrace mit an Bord hat und PostgreSQL 8.3 auch mit DTrace-Support kompiliert werden kann. Leider kennen die Makefiles von PostgreSQL 8.3 in der aktuellen Beta nur die Solaris-Version von DTrace und brechen auf Mac OS X mit einer Fehlermeldung beim kompilieren ab. Ich hoffe, daß dieses Problem bis zur Release von PostgreSQL 8.3 behoben wird. Sollten spätere Versionen von PostgreSQL in dieser Hinsicht korrigiert werden, so reicht es aus, die obige Configure-Zeile um --enable-dtrace zu erweitern.

Damit PostgreSQL auch laufen kann, benötigt es einen Systemuser. In meiner früheren Anleitung für Tiger hatte ich mich für die User-ID 73 entschieden, da diese frei war. Unter Leopard sind fast alle freien User-IDs unter 100 belegt. Ich habe mich also für die User-ID 183 entschieden.

Eine weitere Änderung gegenüber Tiger, ist der Wegfall des Netinfo Managers sowie der NetInfo-Kommandozeilentools wie niutil. Ab Leopard gibt es nur noch das Open Directory und das Kommandozeilentool dscl. Die benötigte Gruppe und den User legst du mit folgenden Befehlen an:

sudo dscl . -create /Groups/_postgres 
sudo dscl . -create /Groups/_postgres RealName 'PostgreSQL Server'
sudo dscl . -create /Groups/_postgres PrimaryGroupID 183          
sudo dscl . -create /Groups/_postgres UserShell /usr/bin/false
sudo dscl . -create /Groups/_postgres Password '*'
sudo dscl . -create /Groups/_postgres NFSHomeDirectory /var/empty

sudo dscl . -create /Users/_postgres   
sudo dscl . -create /Users/_postgres Password '*'
sudo dscl . -create /Users/_postgres RealName 'PostgreSQL Server'
sudo dscl . -create /Users/_postgres PrimaryGroupID 183
sudo dscl . -create /Users/_postgres UniqueID 183      
sudo dscl . -create /Users/_postgres UserShell /usr/bin/false
sudo dscl . -create /Users/_postgres NFSHomeDirectory /Users/Shared/PostgreSQL

Den Erfolg dieser Zeilen kannst du überprüfen, indem du id _postgres eingibst. Dies sollte folgende Zeile zurückliefern:

uid=183(_postgres) gid=183(_postgres) groups=183(_postgres)

Durch die Installation in /Library/PostgreSQL befinden sich die Kommandozeilentools von PostgreSQL an einem etwas mühsam erreichbaren Ort. Um dir das Leben zu erleichtern kannst du entweder /Library/PostgreSQL/bin zu deinem $PATH hinzufügen, oder Symlinks zu den Tools in einem Verzeichnis erstellen, welches sich im $PATH befindet. Ich habe mich für letzteres entschieden und einen Haufen Symlinks in /usr/local angelegt. Da Leopard ein geradezu jungfräuliches /usr/local-Verzeichnis mitliefert, war es bei mir nötig, die leeren Verzeichnisse für die Tools und ihre Man-Pages zuerst mit sudo mkdir -p /usr/local/{bin,man/man1,man/man7} anzulegen. Das symlinken erledigt dieses kleine Skript.

#!/bin/sh

POSTGRES_DIR=/Library/PostgreSQL
DEST_DIR=/usr/local
SYMLINK_DIRS="bin man/man1 man/man7"

for CUR_DIR in $SYMLINK_DIRS; do
  for CUR_FILE in $POSTGRES_DIR/$CUR_DIR/*; do
    sudo ln -nfs $CUR_FILE $DEST_DIR/$CUR_DIR${CUR_FILE#$POSTGRES_DIR/$CUR_DIR}
  done
done

Teste nun mit <q>which psql</q>, ob die PostgreSQL-Kommandozeilentools auch wirklich erreichbar sind. (In der Zsh könnte es nötig werden, vorher noch rehash auszuführen, damit neue Programme im $PATH erkannt werden)

Ich habe mich entschieden, die Datenbank unter /Users/Shared/PostgreSQL abzulegen (siehe auch NFSHomeDirectory des Users _postgres). Da dieses Verzeichnis normalerweise nicht existiert, mußt du es zuerst anlegen:

sudo mkdir -p /Users/Shared/PostgreSQL
sudo chown _postgres:_postgres /Users/Shared/PostgreSQL

Als nächstes muß die Datenbank initialisiert werden. Während der Initialisierung wirst du nach dem Passwort für den Datenbank-Superuser (in meinem Fall postgres genannt) gefragt. Da du diesen Datenbank-Superuser brauchst, um weitere User und Datenbanken anzulegen, wäre es äußerst ungeschickt, seine Logindaten zu verlieren. Die Datenbank initialisierst du mit diesem Befehl:

sudo -u _postgres initdb -U postgres -A md5 -W -E UTF8 \
-D /Users/Shared/PostgreSQL/data

Sollte die Initialisierung mit folgenden Ausgaben fehlschlagen, so begib dich zuerst mit <q>cd ~</q> in dein Heimatverzeichnis und führe dann die Initialisierung erneut aus.

could not identify current directory: Permission denied
could not identify current directory: Permission denied
could not identify current directory: Permission denied
The program "postgres" is needed by initdb but was not found in the
same directory as "initdb".
Check your installation.

Eine erfolgreiche Initialisierung dagegen sollte ungefähr so aussehen:

The files belonging to this database system will be owned by user "_postgres".
This user must also own the server process.

The database cluster will be initialized with locale de_DE.UTF-8.
The default text search configuration will be set to "german".

creating directory /Users/Shared/PostgreSQL/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 20
selecting default shared_buffers/max_fsm_pages ... 2400kB/20000
creating configuration files ... ok
creating template1 database in /Users/Shared/PostgreSQL/data/base/1 ... ok
initializing pg_authid ... ok
Enter new superuser password: 
Enter it again: 
setting password ... ok
initializing dependencies ... ok
creating system views ... ok
loading system objects' descriptions ... ok
creating conversions ... ok
creating dictionaries ... ok
setting privileges on built-in objects ... ok
creating information schema ... ok
vacuuming database template1 ... ok
copying template1 to template0 ... ok
copying template1 to postgres ... ok

Success. You can now start the database server using:

    postgres -D /Users/Shared/PostgreSQL/data
or
    pg_ctl -D /Users/Shared/PostgreSQL/data -l logfile start

Da ich PostgreSQL für die Entwicklung mit Rails benutze, möchte ich gerne wissen, welche Befehle an die Datebank gesendet werden. Solltest du die Datenbank in einer Produktivumgebung einsetzen wollen, so würde ich Logging auf die wirklich wichtigen Meldungen beschränken, da es sonst die Datenbank unnötig ausbremsen könnte.

Lege in /var/log ein Verzeichnis für die PostgreSQL-Logfiles an.

sudo mkdir /var/log/postgres

In der früheren Anleitung habe ich PostgreSQL die Logfiles direkt schreiben lassen. Leider hat PostgreSQL die unangenehme Eigenheit, an den Namen eines jeden Logfiles eine Zufallszahl anzuhängen, was es etwas mühsam machte, das aktuelle Logfile zu finden. Deshalb werde ich diesmal über den Syslog loggen lassen. Füge dazu in der /etc/syslog.conf folgende Zeile hinzu:

local3.*                                /var/log/postgres/postgres.log

Dieses Logfile soll auch jeden Tag um Mitternacht gegen ein neues ausgetauscht werden, damit es nicht zu sehr anwächst. Dies erledigt folgende Zeile in der /etc/newsyslog.conf:

/var/log/postgres/postgres.log          644  5     *    @T00  J

Lege nun ein leeres Logfile an und starte den Syslog-Daemon mit diesen Befehlen:

sudo touch /var/log/postgres/postgres.log
sudo kill -HUP $(cat /var/run/syslog.pid)

Jetzt muß noch PostgreSQL wissen, daß es auch den Syslog benutzen soll. Dies geschieht mit folgenden Zeilen in der /Users/Shared/PostgreSQL/data/postgresql.conf:

log_destination = 'syslog'
syslog_facility = 'LOCAL3'

Wo wir noch in der Konfigurationsdatei von PostgreSQL drin sind, sollten wir auch noch festlegen, was PostgreSQL loggen soll. Ich empfehle für den Anfang folgendes: (s. PostgreSQL Doku: Error Reporting and Logging)

log_line_prefix = '%u@%h:/%d '
log_statement = 'all'

Damit ist PostgreSQL nun endlich bereit zum Start. Es wäre jedoch auf die Dauer etwas mühselig, PostgreSQL immer von Hand zu starten. Ich habe deshalb ein Launchd-Skript erstellt, was PostgreSQL automatisch beim Booten startet. Das Skript sieht folgendermaßen aus:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>org.postgresql.postmaster</string>
    <key>UserName</key>
    <string>_postgres</string>
    <key>OnDemand</key>
    <false/>
    <key>ProgramArguments</key>
    <array>
        <string>/Library/PostgreSQL/bin/postmaster</string>
        <string>-D</string>
        <string>/Users/Shared/PostgreSQL/data</string>
        <string>-c</string>
        <string>log_connections=YES</string>
    </array>
    <key>ServiceDescription</key>
    <string>PostgreSQL Server</string>
</dict>
</plist>

Speichere dieses Skript unter dem Namen org.postgresql.postmaster.plist im Verzeichnis /Library/LaunchDaemons und lade es in den Launchd mit sudo launchctl load /Library/LaunchDaemons/org.postgresql.postmaster.plist. Wenn alles gutgegangen ist, solle PostgreSQL nun laufen. Bei mir sieht dies so aus:

Venus:~ fastjack$ ps ax | grep postmaster
 5315   ??  Ss     0:00.31 /Library/PostgreSQL/bin/postmaster -D /Users/Shared/PostgreSQL/data -c log_connections=YES

Und die Datenbank akzeptiert auch Verbindungen zu ihr:

Venus:~ fastjack$ psql -U postgres template1
Password for user postgres: 
Welcome to psql 8.3beta2, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help with psql commands
       \g or terminate with semicolon to execute query
       \q to quit

template1=#

Da dies ein Blog über Ruby on Rails ist, wäre diese Anleitung nicht vollständig, ohne zu erwähnen, wie das passende Postgres-Gem installiert wird. Da sich PostgreSQL an einer für andere Unix-Systeme ungewöhnliches Stelle befindet, fällt die normale Installation erstmal auf die Nase, weil es PostgreSQL nicht findet. Du mußt also dem Gem mitteilen, wo es die PostgreSQL-Libraries und -Includes findet. Der vollständige Befehl sieht so aus:

sudo gem install postgres -- --with-pgsql-lib-dir=/Library/PostgreSQL/lib \
--with-pgsql-include-dir=/Library/PostgreSQL/include

Das war’s. Es ist geschafft. PostgreSQL läuft und mit dem Postgres-Gem kannst du auf die Datenbank aus deinen Rails-Anwendungen zugreifen.

simply_helpful in Rails Edge

2007-10-19T20:42:00Z

Und noch eine Arbeitserleichterung in Rails Edge (und damit auch im kommenden Rails 2.0). Simply Helpful war bislang als Plugin für Rails 1.2.x verfügbar. In Verbindung mit REST sind Formulare jetzt noch einfacher zu schreiben. In Rails 1.2.x muß man noch folgendes schreiben, um ein Edit-Formular zu bekommen:

form_for :foo, @foo, :url => foo_path(@foo), :html => {:method => :put} do |f|
  ...
end

Das geht nun deutlich kürzer:

form_for @foo do |f|
  ...
end

Jepp, das ist alles. Simply Helpful erkennt automatisch, ob es sich bei @foo um ein neues ActiveRecord-Objekt handelt und baut automagisch einen Link zur create- bzw. update-Action.

Partials jetzt noch einfacher

2007-10-18T07:28:00Z

Und wo ich gerade bei Änderungen in Rails Edge bin. Eine weitere fingerschonene Änderung hat es in Rails geschafft. Mußte man bislang noch folgendes schreiben:

render :partial => "projects", :collection => @projects

genügt demnächst schon:

render :partial => @projects

FormHelper#label in Rails Edge

2007-10-18T07:07:00Z

Seit Changeset 7541 hat Rails Edge (und damit höchstwahrscheinlich auch das kommende Rails 2.0) einen neuen Helper, um Labels für Formularfelder zu erzeugen. Hier ist ein kleines Beispiel, um zu sehen, wie der Helper benutzt werden kann.

<% form_for(:foo, @foo, :url => foo_path(@foo)) do |f| -%>
  <%= f.label :bar, 'Bar' %>
  <%= f.text_field :bar %>
<% end -%>

Läßt man den zweiten Parameter hinter label weg, so wird die Beschriftung aus dem Attributnamen mit humanize abgeleitet.

Rails-Plugins mit Piston

2007-10-16T10:12:00Z

Ein Rails-Projekt ohne Plugins ist nahezu undenkbar. Plugins wie attachment_fu, restful_authentication und will_paginate sind fast immer Pflicht. Mit script/plugin, was bei jedem Rails-Projekt beiliegt, können diese Plugins installiert werden.

Das script/plugin-Skript funktioniert recht gut, hat jedoch ein paar Schönheitsfehler. Standardmäßig kopiert es einfach alle Dateien in ein Verzeichnis in vendor/plugins/mein_plugin. Ein update des Plugins ist so jedoch unmöglich. Es kann nur erneut installiert werden. Dabei werden etwaige eigene Änderungen am Plugin gnadenlos überschrieben.

Um diesem Problem entgegenzuwirken, kann script/plugin mit der Option -x aufgerufen werden. Das Plugin wird dann mit Subversion als <q>External</q> ausgecheckt. Dies löst das Problem mit den Updates. Sollte jedoch das externe Repository nicht erreichbar sein, so wird Subversion Fehlermeldungen beim update und commit ausspucken. Grafische Frontends für Subversion kommen mit diesen Fehlermeldungen selten klar. Auch wer von der Kommandozeile arbeitet, wird auf die Dauer von diesen Fehlermeldungen genervt sein.

An dieser Stelle kommt Piston ins Spiel. Es checkt die Plugins aus ohne externals, vermerkt jedoch für sich, woher das Plugin stammt. Damit ist ein Update jederzeit möglich. Und da sich Subversion nicht um externals kümmern muß, ist es auch kein Problem, wenn das externe Repository nicht erreichbar ist.

Piston wird wie jedes andere Gem einfach mit gem install piston -y installiert. Damit ist es nun einsatzbereit. Benötige ich nun will_paginate in meinem Projekt, so installiere ich es einfach mit folgendem Befehl:

piston import svn://errtheblog.com/svn/plugins/will_paginate \
   vendor/plugins/will_paginate

Um dieses Plugin auf den neuesten Stand zu bringen benutze ich dann diesen Befehl:

piston update vendor/plugins/will_paginate

Weitere Optionen finden sich auf der Piston-Website.

Deployment mit Capistrano

2007-09-28T06:37:00Z

Ein Rails-Projekt mit Capistrano zu deployen ist eigentlich gar nicht so schwer. Es kann jedoch leicht passieren, daß man einen Schritt vergißt und dann erstmal dumm aus der Wäsche schaut. Deshalb habe ich mal kurze Anleitung hier geschrieben, wie der grundsätzliche Ablauf aussieht. Ich setze Capistrano 2.0 ein. Wer noch die Vorgängerversion (1.4.x) einsetzt sollte sein Gem updaten, um dieser Anleitung zu folgen.

Projekt capistranisieren

Um ein Rails-Projekt mit Capistrano zu deployen, brauchst du zu allererst das Capistrano-Gem. Dies kannst du mit <q>gem install capistrano -y</q> installieren. Auf dem Zielserver (auf den das Projekt deployed werden soll) benötigst du außerdem noch Subversion. Ich muß hoffentlich nicht extra erwähnen, daß ein Zugriff per ssh auf den Zielserver Pflicht ist? Damit sollte alles installiert sein, was du benötigte. Capistranisiere dein Projekt mit capify. In meinem Beispiel sieht dies so aus:

[~] capify /Users/fastjack/Sites/DrawBridge
[add] writing `./Capfile’
[add] writing `./config/deploy.rb’
[done] capified!

Auf die Plätze

In der config/deploy.rb mußt du Capistrano mitteilen, wohin es dein Projekt beim Deployment befördern soll. Die Konfiguration sieht bei mir in etwa so aus:

set :application, "DrawBridge"
set :repository,  "http://svn.meinserver.irgendwo/DrawBridge/trunk"

role :app, "192.168.1.182"
role :web, "192.168.1.182"
role :db,  "192.168.1.182", :primary => true

set :deploy_to, "/usr/local/www/frigg/#{application}"
set :use_sudo, false

namespace :deploy do
  desc "upload database configuration"
  task :add_database_configuration, :roles => :web do
    run "mkdir -p #{shared_path}/config"
    config = File.read(File.join(File.dirname(__FILE__), "database.yml"))
    put config, "#{shared_path}/config/database.yml"
    run "ln -s #{shared_path}/config/database.yml \
          #{latest_release}/config/database.yml"
  end

  after "deploy:finalize_update", "deploy:add_database_configuration"
end

Mit dieser Konfiguration wird Capistrano mein Projekt auf den Server mit der IP-Adresse 192.168.1.182 unter /usr/local/www/frigg/DrawBridge befördern. Capistrano wird hierzu einen Checkout mit Subversion durchführen. Der Subversion-Server sollte also vom Zielserver erreichbar sein. Zu guter Letzt wird noch die Datenbankkonfiguration von meinem Rechner auf den Zielserver kopiert (weil ich die Datenbankkonfiguration nicht in das Repository einchecke). Damit sollte auch klar sein, daß die config/database.yml einen Abschnitt für die production-Umgebung besitzen muß, der auf dem Zielserver funktioniert.

Damit Capistrano nach dem Deployment auch den Mongrel starten kann, brauchst du noch ein spin-Skript im scripts-Verzeichnis. Dieses sollte ausführbar sein und auch als ausführbar in Subversion (svn propset svn:executable on script/spin) markiert sein. Mein script/spin sieht so aus:

#!/bin/sh
script/process/spawner -a 127.0.0.1 -p 15000 -i 3

Damit werden 3 Mongrel-Server auf den Ports 15000-15002 gestartet, die nur auf Anfragen vom Localhost reagieren. Die Mongrels werden bei mir hinter einem Apache, der als Proxy fungiert, laufen, deshalb sind sie auch nur an den Localhost gebunden.

Fertig

Damit ist hoffentlich alles bereit, um das Projekt zu deployen. Mit cap deploy:check kannst du noch schnell prüfen, ob es irgendwelche schwerwiegenden Probleme gibt, die das Deployment behindern könnten. Warnmeldungen über ein Fehlendes releases-Verzeichnis kannst du dabei ignorieren, dies wird im nächsten Schritt angelegt. Nun ist es an der Zeit, das Deployment vorzubereiten. Mit cap deploy:setup läßt du Capistrano die noch fehlenden releases- sowie shared-Verzeichnisse anlegen. Überprüfe noch schnell, ob du auch wirklich alle lokalen Änderungen wieder ins Repository eingecheckt habst, sonst werden sie nicht auf den Zielserver gelangen.

Los!

Jetzt kann es losgehen. Mit cap deploy:cold startest du nun den Deploymentprozess. Dies dauert ein paar Minuten und endet hoffentlich damit, daß am Ende folgende Zeilen stehen:

[192.168.1.182] executing command
** [out :: 192.168.1.182] appending output to nohup.out
   command finished

Nun laufen 3 Instanzen des Mongrels und warten auf Anfragen vom Apache.

Herzlichen Glückwunsch. Dein Projekt wurde erfolgreich deployed. Lehn dich zurück und genieße ein erfrischendes (alkoholisches) Getränk.

Resourcen im Singular

2007-09-24T08:21:00Z

Wer sich in Rails über die etwas unverständliche Fehlermeldung wie diese wundert <q>session_url failed to generate from {:controller=>"session", :action=>"show"} - you may have ambiguous routes, or you may need to supply additional parameters for this route. content_url has the following required parameters: ["session", :id] - are they all satisfied?</q>, der hat mit Sicherheit in seiner routes.rb folgendes stehen:

map.resources :session

Das Problem dabei ist, daß die Resource <q>session</q> im Singular ist, während die map.resources-Anweisung eine Resource im Plural erwartet. Schreibt man stattdessen:

map.resource :session

so klappt es auch wieder mit dem Routing. (Ja, es ist nur das Plural-s verschwunden).

Autotest, Growl und RSpec

2007-09-18T18:44:00Z

Ich hatte einen ähnlichen Artikel bereits in meinem anderen Blog darüber geschrieben. Doch hier ist es nochmal, damit alles an einem Ort zu finden ist, und weil ich in der Zwischenzeit auch einiges daran geändert habe.

Angenfangen hat es, als ich ein paar Wochen über diesen Artikel von John Nunemaker in meinem Feed-Reader gestolpert bin. Das war gleich doppelt interessant. Ich fand die Idee mit Growl supergeil. Und von autotest hatte ich bis dahin auch noch nie gehört. Autotest ist Teil des ZenTest-Gems und kann ganz einfach mit gem install ZenTest -y installiert werden. (Die meisten werden noch ein sudo davor schreiben müssen)

Nachdem ich meine erste ~/.autotest-Datei erstellt habe, ging das eigentliche Experimentieren erst richtig los. Ich war nicht der einzige, der über diesen Artikel gestolpert war, denn kurze Zeit später präsentierte Jamie Hill etwas ansehnlichere Icons. Das sah schon richtig gut aus. Zu guter Letzt machte mein Wechsel auf RSpec einige Änderungen notwendig. Meine derzeitige ~/.autotest-Datei sieht also so aus. (download)

require 'autotest/timestamp'

module Autotest::Growl

  IMAGE_ROOT = "~/Library/Autotest/Images" 

  def self.growl title, msg, img, pri=0, sticky="" 
    system "growlnotify -n autotest --image #{img} -p #{pri} -m '#{msg}' '#{title}' #{sticky}" 
  end

  def self.find_test_summary(test_results)
    test_summary = test_results.find {|result| result.include? "example"}.chomp
  end

  def self.display_test_summary(summary)
    examples, failures, pending = summary.split(', ')
    if failures.to_i > 0
      growl "Tests fehlgeschlagen", summary, "#{IMAGE_ROOT}/fail.png", 2
    elsif pending.to_i > 0
      growl "Tests stehen aus", summary, "#{IMAGE_ROOT}/pending.png", 1
    else
      growl "Tests bestanden", summary, "#{IMAGE_ROOT}/pass.png", 0
    end
  end

  Autotest.add_hook :ran_command do |at|
    unless at.results.empty?
      summary = find_test_summary(at.results)
      display_test_summary(summary)
    else # Irgendwas ging ganz furchtbar schief
      growl "Panik!", "Die Tests lieferten keine Ergebnisse!", "#{IMAGE_ROOT}/panic.png", 3
    end
  end
end

Ich habe die Smileys um einen vierten Panic-Smiley ergänzt, falls etwas ganz fürchterlich schief gehen sollte. Da ich autotest immer in Netbeans starte und die Netbeans-Konsole keine Farbcodes beherrscht, entferne ich in meinen Projekten in $PROJEKT/spec/spec.opts immer die Zeile mit --colour. Folglich habe ich es auch nicht für nötig befunden, diese Farbcodes in meiner ~/.autotest-Datei herauszufiltern. Wem die Growl-Nachrichten nicht bunt genug sind, und auch farbige Meldungen in der Konsole haben möchte, muß sich einen entsprechenden Filter selbst in seine ~/.autotest-Datei einbauen.

Validations und virtuelle Attribute

2007-09-11T08:55:00Z

Manchmal möchte ich (virtuelle) Attribute im Model haben, die sich nicht 1:1 auf Spalten in einer Tabelle abbilden lassen. Ein gutes Beispiel dafür ist mein Machine-Model. In dem Model möchte ich unter anderem das Baujahr der Maschine festhalten. Dies könnte ich zwar auch einfach als ein Integer in der Datenbank speichern, doch für diverse Datumsberechnungen habe ich mich dazu entschlossen, das Baujahr als Datum (jeweils als den 1. Januar des Jahres) zu speichern. Das Baujahr habe ich zu einem virtuellen Attribut es Models gemacht. Das ganze sieht dann so aus.

class Machine < ActiveRecord::Base
  def build_year
    read_attribute(:built_on).year if read_attribute(:built_on)
  end

  def build_year=(year)
    write_attribute(:built_on, Date.new(year.to_i, 1, 1)) unless year.empty?
  end
end

Damit läßt sich nun build_year wie jedes andere Attribut des Models in Views verwenden. Wie wäre es noch mit Validations? Hierzu habe ich folgende validate-Methode gebaut.

def validate
  errors.add(:build_year, "can't be blank") unless build_year.is_a?(Fixnum) 
  errors.add(:build_year, "must be after 1944") if build_year && build_year<1945
  errors.add(:build_year, "can't be in the future") if build_year && build_year>Date.today.year
end

Damit wird mein virtuelles Attribut nun auch entsprechend im View hervorgehoben, wenn die Validation fehlschlägt.

content_for und Defaultwerte

2007-09-01T21:19:00Z

Mit content_for lassen sich mehrere Bereiche im Layout mit Inhalten füllen. Typischerweise sieht das im View so aus.

<% content_for :page_title do -%>
  Niemand erwartet die Spanische Inquisition
<% end -%>

Im Layout kann ich nun das ganze mit yield :page_title wieder ausgeben. Was ist aber wenn ich gar keinen Inhalt für den :page_title angebe? Dann kommt die Seite mit einem leeren Titel daher. Daher ist es sinnvoll, hier einen Defaultwert anzugeben. Das könnte im Layout etwa so aussehen.

<%= (yield :page_title) || "Du hast den Titel vergessen, du Dummy!" %>

Alternativ könnte ich auch einen Partial hier einbinden, aber das hängt ganz von den Anforderungen ab.

Doppelt hält besser

2007-09-01T08:23:00Z

Ich benutze oft einen recht nützlichen Rubyismus, den ich <q>bang-bang</q> nenne. In meinem fiktiven User-Modell habe ich folgende Methode.

def married?
  !! spouse
end

Die Methode spouse würde hier einfach nur eine Instanz des User-Models mit dem Ehepartner zurückgeben. Aber was sollen die beiden Ausrufezeichen (in Unix-Kreisen als <q>bang</q> bezeichnet) da? Ein Ausrufezeichen in Ruby ist normalerweise eine logische Negation. Zwei Ausrufezeichen sind also eine doppelte Negation.

Wer in der Schule aufgepasst hat, wird nun einwerfen, daß eine doppelte Negation sich selbst wieder aufhebt. Das ist auch korrekt, doch in Ruby gelten etwas andere Regeln. Alles was nicht false oder nil ist, gilt als wahr. Liefert also die Methode spouse einen Ehepartner zurück, so gibt die Methode married? das Ergebnis true zurück.