Nach dem Anlegen der Production-Datenbank wollte ich mittels “RAILS_ENV=production rake db:migrate” das DB-Schema einrichten. rake brach jedoch mit einem Fehler ab: “no such file to load — CSV”. Auf dem Mac konnte ich das Kommando absetzen. Und die Development-Version lief auch problemlos. Die in dem Projekt verwendete CSV-Klasse lag auch am Linux-Server unter /usr/lib/ruby/1.8/csv.rb.

Es hat mich ewig gekostet, die Ursache zu finden. Warum trat der Fehler bei einem rake-Aufruf in der Production-Version, aber nicht in der Development-Version auf? Der Grund: rails lädt im Production-Environment alle Klassen im Voraus. Daher tritt das Problem bereits beim Initialisieren auf.

Und was ist nun mit dem Fehler? In einer Datei stand require ‘CSV’, das ich per copy’n'paste aus dem Beispiel von einer Website kopiert hatte. Auf dem Mac ist das offenbar kein Problem. Unter Linux schon. Nachdem ich es in require ‘csv’ geändert hatte, lief rake anstandslos durch.

Damit mir — und Euch — das nicht noch einmal passiert, habe ich es hier aufgeschrieben.

• http://www.rubytips.org/2008/04/07/10-unique-ruby-language-features/
• http://www.cs.auckland.ac.nz/references/ruby/doc_bundle/Newcomers/ruby.html
• http://neworder.box.sk/news/18210
• http://www.linux-mag.com/id/1154
• http://www.linux-mag.com/id/1024
• http://www.linuxdevcenter.com/pub/a/linux/2001/10/25/ruby.html

Schon alleine dieser Trick ist Gold wert:

email = "Fred Bloggs "
email.match(/< (.*?)>/)[1]            # => "fred@bloggs.com"
email[/< (.*?)>/, 1]                  # => "fred@bloggs.com"
email.match(/(x)/)[1]                # => NoMethodError [:(]
email[/(x)/, 1]                      # => nil
email[/([bcd]).*?([fgh])/, 2]        # => "g"

•  Auf Railscasts.com gibt es über 100 Video-Casts zu speziellen RoR-Themen.
• Auf rorsecurity.info findet man eine Reihe von Beiträgen zu Sicherheitsthemen.
• Mit bundle_fu kann man automatisch mehrere eingebundene Stylesheets/JS-Files zusammenfassen, was die Aufbauzeiten stark reduziert.
• calendar_date_select ist ein Rails-Plugin, das einen schönen Date-Picker bereitstellt.
• Auf lindsaar.net gibt es einige lesenswerte Rails-Tips, z.B. ein Hinweis auf die Bang-Bang-Notation (!!) in Ruby und transactional migrations.
• Leider sind transaction migrations bei MySQL nicht möglich, da die DDL-Kommandos (CREATE TABLE etc.) nicht von Transaktionen erfasst sind. Bei PostgreSQL ist das hingegen kein Problem.

PostgresSQL

• Also habe ich mir endlich einmal PostgreSQL angeschaut — das wollte ich sowieso schon lange machen. Es gibt verschiedene Möglichkeiten, Postgres unter Mac OS X zu installieren, z.B. mit einem Installer.
• Nach einigen Recherchen habe ich mich aber dazu entschieden, die Installation doch lieber mit MacPorts durchzuführen. Interessant war der Beitrag auf Robby on Rails.
• Die PostgresSQL-Installation erledigt folgender Aufruf: sudo port install postgresql83 postgresql83-server
• Nach der Installation muss man zunächst einmal eine neue Datenbankinstanz anlegen — schon hier wird deutlich, dass sich Postgres viel mehr an Business-DBMS wie dem MS SQL Server oder Oracle anlehnt als an den Kollegen MySQL. Wie in vielen Howtos beschrieben erfolgt die Einrichtung der Instanz wie folgt:
  sudo mkdir -p /opt/local/var/db/postgresql83/defaultdb;
  sudo chown postgres:postgres /opt/local/var/db/postgresql83/defaultdb;
  sudo su postgres -c ‘/opt/local/lib/postgresql83/bin/initdb -D /opt/local/var/db/postgresql83/defaultdb’
• Allerdings gab es bei mir ein Problem: Der letzte Befehl brachte eine Fehlermeldung hervor (su: /dev/null: Permission denied). Ursache: Der postgres-Benutzer hat als Shell /dev/null eingetragen. Daher kann su keine Kommandos in dessen Kontext ausführen.
• Kein Problem, dann ändern wir halt schnell die Shell in /etc/passwd. Denkste! In der Datei existiert der postgres-Benutzer gar nicht. Das liegt daran, dass OS X die sog. NetInfo-Datenbank zum Speichern der Benutzer verwendet. /etc/passwd wird nur im Single-User-Mode, der im Notfall verwendet werden kann, ausgewertet.
• Wie ändert man Einträge in der NetInfo-DB? Mit dscl! Aufruf: dscl localhost. Das ist eine Art Shell für die Datenbank. Die Datenbank ist hierarchisch aufgebaut wie ein Dateisystem und man kann nach dem Starten mit cd und ls hindurchnavigieren
• Der Aufruf zum Ändern der Shell lautet: dscl . -create /Users/postgres UserShell /bin/bash
• Danach wird die Instanz eingerichtet (was überraschend lange dauert — was macht der denn alles?) und man kann den Server mit dem Kommando sudo su postgres -c ‘/opt/local/lib/postgresql83/bin/postgres -D /opt/local/var/db/postgresql83/defaultdb’ starten. Puh!
• Dann habe ich mir pgAdmin3, eine offenbar weitverbreitete Client-GUI für verschiedene Plattformen besorgt, um mich zum ersten Mal mit dem Server zu verbinden. Mit phpPgAdmin gibt es auch ein mit phpMyAdmin vergleichbares Web-basiertes Tool.
• Beim Ausprobieren von pgAdmin3 wird mir schnell klar, dass das komplexer wird als gedacht — da ist von Table Spaces und Login Rollen die Rede — Konzepte, die einem MySQL-Benutzer gar nichts sagen. Klingt aber spannend. Weiter bin ich noch nicht gekommen, insbesondere der Ruby-Datenbank-Treiber wird noch spannend. Angeblich kann man ihn einfach mit gem install postgres installieren.

Puh, das reicht fürs Erste. Ich bin ja gespannt, ob ich mich mit Postgres anfreunden kann. Achja, übrigens: Ich habe mir heute endlich das legendäre Pickaxe-Buch gekauft.

Ein bemerkenswerter Satz ist der folgende:

PHP wird oft als Einsteigersprache bezeichnet. Dabei wird aber meist nur bedacht, dass es im Vergleich zu manch älterer Sprache wie Perl oder C etwas einfacher zu erlernen ist, ein wichtiges Kriterium wird oft vergessen: In einer Einsteigersprache sollte es nicht zu einfach sein, sich Sicherheitslücken in eine Anwendung zu reißen. In diesem Punkt leistet sich PHP leider große Patzer.

Ruby vs. PHP