Denn ein AI-Agent mit Shell-Zugriff kann im Prinzip alles, was du auch kannst. Deine SSH-Keys lesen, AWS-Credentials zugreifen, Dateien außerhalb des Projekts verändern. Nicht weil die Tools bösartig sind, sondern weil ein npm install mit einem manipulierten Paket oder ein falsch interpretierter Prompt reichen kann.

Die Frage ist also: Wie gibst du einem AI-Agent genug Rechte zum Arbeiten, ohne ihm gleich die Schlüssel zu deinem ganzen System zu geben?

sandbox-shell (sx): macOS Seatbelt für Entwickler

macOS hat mit Seatbelt ein mächtiges Sandboxing-System eingebaut. Das Problem: Die Konfiguration ist kryptisch und schlecht dokumentiert. Genau hier setzt sx an. Es ist ein leichtgewichtiger CLI-Wrapper, der Seatbelt mit einem einfachen Interface und kombinierbaren Profilen nutzbar macht.

Das Prinzip ist Deny-by-Default:

• Dateisystem: Nur das Projektverzeichnis + /tmp sind beschreibbar
• Netzwerk: Standardmäßig komplett blockiert
• Sensible Pfade: ~/.ssh, ~/.aws, ~/Documents usw. sind gesperrt

Installation

brew tap agentic-dev3o/sx
brew install sx

Optional: Shell-Integration für Prompt-Indikatoren und Aliases:

# In ~/.zshrc einfügen
source $(brew --prefix)/share/sx/sx.zsh

Damit bekommt ihr im Terminal einen Indikator, ob ihr gerade in einer Sandbox arbeitet ([sx:offline], [sx:localhost], [sx:online]), und praktische Aliases wie sxo (online) und sxl (localhost).

Globale Konfiguration

In ~/.config/sx/config.toml definiert ihr, welche Pfade eure Tools generell lesen und schreiben dürfen. Das hängt davon ab, welchen Ruby-Version-Manager ihr nutzt. Hier ein Beispiel für mise:

[filesystem]
allow_read = [
    "~/.gitconfig",
    "~/.config/git/",
    "~/.bundle/",
    "~/.gem/",
    "~/.local/share/mise/",
    "~/.config/mise/",
]

allow_write = [
    "~/.bundle/",
    "~/.gem/",
    "~/.cache/",
]

Nutzt ihr rbenv, ersetzt die mise-Pfade durch ~/.rbenv/. Bei asdf entsprechend ~/.asdf/.

Projekt-Konfiguration

Im Projektverzeichnis könnt ihr mit sx --init eine .sandbox.toml anlegen:

cd mein-projekt
sx --init

Für ein typisches Rails-Projekt mit MySQL, Redis und Memcache in Docker sieht die Konfiguration so aus:

[sandbox]
inherit_global = true

# Localhost für Datenbankzugriff über Docker
network = "localhost"

[shell]
pass_env = ["RUBY_DEBUG_ENABLE"]

Die pass_env-Einstellung ist wichtig: Der Ruby-Debugger (rdbg) versucht beim Start automatisch einen Unix-Socket zu öffnen, was Seatbelt im Localhost-Modus blockiert. Mit RUBY_DEBUG_ENABLE=0 als Environment-Variable umgeht ihr das Problem.

Was blockiert die Sandbox konkret?

Ein sx --explain zeigt euch genau, was erlaubt und was gesperrt ist:

=== Sandbox Configuration ===

Network Mode: Localhost

Working Directory (full access):
  /Users/mathias/Workspace/mein-projekt

Denied Read Paths:
  - ~/.ssh
  - ~/.aws
  - ~/.docker/config.json
  - ~/Documents
  - ~/Desktop
  - ~/Downloads

Und das könnt ihr leicht verifizieren:

# Funktioniert – Projektdateien sind lesbar
sx -- cat README.md

# Blockiert – SSH-Keys sind geschützt
sx -- cat ~/.ssh/id_rsa
# => No such file or directory

# Blockiert – kein Schreibzugriff außerhalb des Projekts
sx -- touch ~/Desktop/test
# => Operation not permitted

Seatbelt macht die gesperrten Dateien quasi unsichtbar. Ein Prozess in der Sandbox weiß nicht einmal, dass ~/.ssh/id_rsa existiert.

Netzwerk-Modi

sx bietet drei Netzwerk-Modi, die ihr je nach Aufgabe kombiniert:

In der Praxis heißt das:

# Linting braucht kein Netzwerk
sx -- bundle exec rubocop

# Tests brauchen die lokale Datenbank
RUBY_DEBUG_ENABLE=0 sx localhost -- bundle exec rspec

# Gems installieren braucht Internet
sx online -- bundle install

Einsatz mit AI Coding-Agents

Jetzt zum eigentlichen Punkt: Warum das Ganze besonders relevant für AI-Tools ist.

Claude Code

Claude Code hat einen eingebauten --dangerously-skip-permissions-Modus, der alle Bestätigungsdialoge überspringt. Praktisch, aber riskant. Mit sx könnt ihr diesen Modus nutzen und trotzdem sicher bleiben:

sx claude -- claude --dangerously-skip-permissions

Das claude-Profil gibt Claude Zugriff auf ~/.claude, während alles andere gesperrt bleibt. Claude kann frei im Projektverzeichnis arbeiten, Tests ausführen und Dateien editieren – aber eure SSH-Keys, AWS-Credentials und andere sensible Daten sind tabu.

OpenAI Codex

Für Codex gilt das gleiche Prinzip:

sx localhost -- codex

Warum nicht einfach Docker?

Docker ist natürlich auch eine Option, aber sx hat ein paar Vorteile für den täglichen Einsatz:

• Kein Overhead: Kein Container-Build, kein Volume-Mounting, keine Port-Forwards
• Native Performance: Läuft direkt auf dem Host, keine Virtualisierung
• Einfache Integration: Ein Prefix vor dem Befehl, fertig
• Zugriff auf lokale Tools: Eure installierte Ruby-Version, eure Shell-Config – alles da

Mein Alltags-Setup

So sieht mein typischer Workflow aus:

Fazit

AI Coding-Agents sind gekommen, um zu bleiben. Die Produktivitätsgewinne sind real. Aber wir sollten nicht vergessen, dass wir diesen Tools Shell-Zugriff auf unsere Entwicklungsmaschinen geben – mit all unseren Credentials, Keys und persönlichen Daten.

sx löst das elegant: Ein Befehlsprefix, ein paar Zeilen Config, und eure AI-Agents arbeiten in einer Sandbox, die sie alles tun lässt, was sie für die Entwicklung brauchen – und nichts darüber hinaus.

Viel Spaß beim Ausprobieren!

Links:

• sandbox-shell auf GitHub
• Claude Code
• macOS Seatbelt Dokumentation

Warum das Ganze? Klassische Ansätze wie Single Table Inheritance (STI) oder „nackte“ polymorphe Assoziationen stoßen schnell an Grenzen: STI bläht Tabellen auf, polymorphes CRUD bleibt oft mühsam zu paginieren. Das Recordable Pattern nutzt Rails’ Delegated Types, um eine dünne, performante „Superklasse“-Tabelle (Recording) mit schlanken „Subklasse“-Tabellen (Recordables wie Message, Document, Comment) zu kombinieren.

Das Grundprinzip

• Eine zentrale Tabelle „recordings“ hält alle gemeinsamen Metadaten (z. B. Bucket, Creator, Timestamps) und verweist polymorph auf den „konkreten Inhalt“ (recordable).
• Jede konkrete Recordable (Message, Document, Comment) hat eine eigene Tabelle mit genau ihren Feldern.
• Abfragen, Pagination und gemeinsame Logik passieren über Recording; konkretes Verhalten (z. B. export_html) lebt bei den Recordables.

So bleibst du:

• flexibel (neue Typen ohne Recording-Migration),
• performant (einheitliche Timeline auf der dünnen Recording-Tabelle),
• sauber getrennt (Metadaten vs. Inhalte).

Minimales Datenmodell

Migration (gekürzt auf das Wesentliche):

create_table :recordings do |t|
  t.references :bucket,  null: false, foreign_key: true
  t.references :creator, null: false, foreign_key: { to_table: :users }
  t.string  :recordable_type, null: false
  t.bigint  :recordable_id,   null: false
  t.index [:recordable_type, :recordable_id]
  t.bigint :parent_id # optional: Recording-Baum (Unterelemente)
  t.index :parent_id
  t.timestamps
end
add_foreign_key :recordings, :recordings, column: :parent_id

create_table :messages do |t|
  t.string :title,   null: false
  t.text   :content, null: false
  t.timestamps
end

create_table :documents do |t|
  t.string :title, null: false
  t.text   :body
  t.string :external_url
  t.timestamps
end

create_table :comments do |t|
  t.text :body, null: false
  t.timestamps
end

Models und Concerns

Recording: die „Superklasse“ mit Delegation

class Recording < ApplicationRecord
  belongs_to :bucket
  belongs_to :creator, class_name: "User"

  delegated_type :recordable, types: %w[Message Document Comment], dependent: :destroy

  # optional: Baumstruktur
  belongs_to :parent, class_name: "Recording", optional: true
  has_many   :children, class_name: "Recording", foreign_key: :parent_id, dependent: :nullify

  # Bequeme Filter-Scopes kommen mit delegated_type:
  # Recording.messages, Recording.documents, Recording.comments
end

Recordable-Concern: gemeinsame API für Inhalte

module Recordable
  extend ActiveSupport::Concern

  included do
    has_many :recordings, as: :recordable, inverse_of: :recordable
  end

  def display_title
    respond_to?(:title) ? title : self.class.name
  end

  def export_html
    "#{display_title}"
  end
end

Konkrete Typen:

class Message < ApplicationRecord
  include Recordable
  validates :title, :content, presence: true

  def export_html
    "#{title}#{content}"
  end
end

class Document < ApplicationRecord
  include Recordable
  validates :title, presence: true

  def export_html
    if external_url.present?
      "#{title}External: #{external_url}"
    else
      "#{title}#{body}"
    end
  end
end

class Comment < ApplicationRecord
  include Recordable
  validates :body, presence: true

  def display_title
    body.truncate(40)
  end

  def export_html
    "#{body}"
  end
end

Erstellen und Paginieren einer Timeline

Bucket kapselt die Aufnahme neuer Inhalte („record“) und die Timeline. Bucket ist hier eher abstrakt und könnte genausogut auch ein Projekt sein, oder ein Kunde:

class Bucket < ApplicationRecord
  has_many :recordings, dependent: :destroy

  def timeline(limit: 50)
    recordings.order(created_at: :desc).limit(limit).includes(:recordable)
  end

  def record(recordable, creator:, parent: nil, color: nil)
    recordings.create!(recordable: recordable, creator: creator, parent: parent, color: color)
  end
end

Typische Abfragen:

bucket = Bucket.find(1)

# Gesamte Timeline effizient paginieren
bucket.timeline(limit: 50).each do |rec|
  puts "[#{rec.recordable_type}] #{rec.recordable.display_title}"
end

# Nur bestimmte Typen (Scopes via delegated_type)
Recording.messages.where(bucket: bucket).limit(20)
Recording.documents.where(bucket: bucket).order(created_at: :desc)

Versionierung per Repointing (immutable Recordables)

Statt Inhalte zu „updaten“, erzeugst du neue Recordables und verweist die Recording-Zeile auf die neue Version. Das hält Historie sauber und macht Kopieren effizient.

class Recording < ApplicationRecord
  # ...

  def repoint_to!(new_recordable)
    update!(recordable: new_recordable)
  end
end

# Beispiel: Message ? neue Document-Version
msg_rec = bucket.record(Message.create!(title: "Kickoff", content: "Welcome!"), creator: user)
new_doc = Document.create!(title: "Specs v2", body: "Updated requirements")
msg_rec.repoint_to!(new_doc) # Recording zeigt nun auf Document

Wenn du eine echte Ereignis-Historie brauchst, ergänze ein Event-Model und schreibe beim record/repoint_to! Einträge (z. B. „created“, „repointed“, inkl. vorher/nachher recordable_type/_id). Das hält Audit-Trails und erlaubt Timeline-Features (siehe Video/37signals-Artikel).

Copy & Move: Subtrees kopieren

Ein Vorteil des Patterns: Kopieren und Verschieben ganzer Teilbäume wird planbar und schnell, weil Recordings leichtgewichtig sind und Recordables immutable dupliziert werden. Eine einfache Kopier-Serviceklasse:

class Copier
  def self.copy!(source_recording:, destination_bucket:, creator:)
    new(source_recording, destination_bucket, creator).copy!
  end

  def initialize(source_recording, destination_bucket, creator)
    @source_recording   = source_recording
    @destination_bucket = destination_bucket
    @creator            = creator
  end

  def copy!
    ActiveRecord::Base.transaction do
      copied_root = copy_recording(@source_recording, parent: nil)
      @source_recording.children.each { |child| copy_branch(child, parent: copied_root) }
      copied_root
    end
  end

  private

  def copy_branch(node, parent:)
    copied = copy_recording(node, parent: parent)
    node.children.each { |child| copy_branch(child, parent: copied) }
    copied
  end

  def copy_recording(original, parent:)
    new_recordable = duplicate_recordable(original.recordable)
    @destination_bucket.record(new_recordable, creator: @creator, parent: parent, color: original.color)
  end

  def duplicate_recordable(recordable)
    case recordable
    when Message
      Message.create!(title: recordable.title, content: recordable.content)
    when Document
      Document.create!(title: recordable.title, body: recordable.body, external_url: recordable.external_url)
    when Comment
      Comment.create!(body: recordable.body)
    else
      raise ArgumentError, "Unsupported recordable: #{recordable.class.name}"
    end
  end
end

Vergleich mit STI und „plain“ Polymorphismus

• STI: Einfache Fälle ok. Bei divergenten Typen entsteht Tabellen-Bloat, viele NULL-Spalten, Migrationen werden groß, Erweiterbarkeit leidet.
• Polymorphismus ohne delegated_type: Funktioniert, aber es fehlen bequeme Scopes/Convenience-Methoden; unified Pagination ist oft hakelig.
• Recordables + delegated_type: Einheitliche Timeline über eine dünne Tabelle, klare Trennung von Meta vs. Inhalt, leichte Erweiterbarkeit (neuen Typ hinzufügen statt zentrale Tabelle migrieren), gute Performance bei Abfragen.

Wann solltest du das Pattern nutzen?

• Du brauchst eine gemischte, paginierbare Timeline (z. B. Aktivitätsfeed über Messages, Documents, Comments).
• Deine Typen unterscheiden sich stark in ihren Attributen.
• Du willst Polymorphismus am Parent (Recording) und saubere Delegation an die Inhalte.

Wann eher nicht?

• Deine Subtypen sind fast identisch (STI könnte reichen).
• Du hast keine gemeinsamen Abfragen über Typgrenzen hinweg.

Best Practices

• Halte Recording schlank: nur Metadaten und die polymorphe Referenz. Keine großen Textfelder.
• Packe typenübergreifende Logik in Recording (oder Concerns), typenspezifische Logik in die Recordables.
• Nutze delegate am Recording für gemeinsame Schnittstellen, z. B. delegate :export_html, to: :recordable.
• Wenn Auditing/History wichtig ist, ergänze Events und schreibe Änderungen mit.
• Autorisierung: Recording bündelt viele Aktionen – prüfe Berechtigungen konsequent.

Fazit

Das Recordable Pattern mit delegated_type ist eine elegante, praxiserprobte Lösung für polymorphe Inhalte in Rails. Es bringt dir:

• eine einheitliche, performante Timeline,
• klare Verantwortlichkeiten zwischen Metadaten und Inhaltsobjekten,
• einfache Erweiterbarkeit ohne große Migrationen,
• saubere APIs durch Delegation.

Wenn du Feed-ähnliche Strukturen, Versionierung und Kopier-Features brauchst, wirst du mit Recordings/Recordables sehr schnell produktiv.

Viel Spaß beim Ausprobieren – und schreib mir gern, wenn du Fragen hast oder Beispiele aus deinem Projekt teilen willst!

— Mathias (webmatze.de)

Ich freue mich, euch heute mein neuestes Ruby Gem vorzustellen: icanhazdadjoke. Wie der Name schon verrät, ermöglicht dieses Gem euch, auf einfache Weise zufällige "Dad Jokes" aus der icanhazdadjoke API abzurufen. Wer liebt nicht einen guten, alten, schlechten Witz?

Was ist ein "Dad Joke"?

"Dad Jokes" sind einfache, oft vorhersehbare und klischeehafte Witze, die typischerweise von Vätern erzählt werden. Sie zeichnen sich durch ihre Wortspiele und ihren harmlosen Humor aus. Beispiele gefällig? Hier sind ein paar Klassiker:

• Warum können Geister so schlecht lügen? Weil man sie durchschauen kann!
• Wie nennt man einen Bumerang, der nicht zurückkommt? Einen Stock!

Ha! Ich weiß.

Funktionen des Gems

Mit icanhazdadjoke könnt ihr ganz einfach zufällige Witze abrufen und in euren Ruby-Anwendungen verwenden oder direkt im Terminal aufrufen. Das Gem ist leicht zu installieren und noch einfacher zu benutzen. Hier sind einige der Hauptfunktionen:

• Zufällige Witze abrufen: Holt euch einen zufälligen Witz mit einer einzigen Zeile Code.
• Leicht erweiterbar: Das Gem ist so konzipiert, dass es leicht erweitert und in bestehende Projekte integriert werden kann.

Installation

Die Installation des Gems ist einfach und dauert nur einen Moment. Führt einfach folgenden Befehl in eurem Terminal aus:

gem install icanhazdadjoke

Nutzung

Nachdem ihr das Gem installiert habt, könnt ihr es in eurem Projekt verwenden. Hier ist ein kurzes Beispiel, wie ihr einen zufälligen Witz abrufen könnt:

require 'icanhazdadjoke'

joke = ICanHazDadJoke.fetch_joke
puts joke

So einfach ist das! Ihr könnt den abgerufenen Witz dann überall in eurem Code verwenden, wo ihr ihn braucht.

Beispielprojekt

Hier ist ein kleines Beispielprojekt, das zeigt, wie man das Gem in einer einfachen Ruby-Anwendung verwenden kann:

require 'sinatra'
require 'icanhazdadjoke'

get '/' do
  joke = ICanHazDadJoke.fetch_joke
  "<h1>Dad Joke</h1><p>#{joke}</p>"
end

Dieses einfache Sinatra-Projekt erstellt einen kleinen Webserver, der bei jedem Aufruf der Startseite einen neuen Witz anzeigt.

Fazit

Ich hoffe, euch gefällt mein neues Gem icanhazdadjoke. Es war ein lustiges Projekt und ich freue mich darauf zu sehen, wie ihr es in euren eigenen Projekten verwendet. Wenn ihr Fragen oder Anregungen habt, lasst es mich gerne wissen. Den Code und weitere Informationen findet ihr auf GitHub.

Viel Spaß beim Programmieren und vergesst nicht, hin und wieder einen guten "Dad Joke" zu erzählen!

Ruby on Rails hingegen ist derzeit eines der populärsten und produktivsten OpenSource Frameworks, mit dem sich sehr schnell umfangreiche Webanwendungen erstellen lassen. Wer schon damit gearbeitet hat, weiß wieviel Spaß es machen kann.

Ruby selbst ist eine Scriptsprache, wie z.B. auch PHP eine Scriptsprache ist. Ruby wurde jedoch von Grund auf mit dem Ziel entwickelt, leicht verständlich zu sein und eine schnelle Entwicklung damit zu ermöglichen.

Ubuntu für Rails vorbereiten

Damit wir das Rails Framework unter Ubuntu 11.10 verwenden können, müssen wir zuerst Ruby installieren. Von Haus aus ist Ubuntu noch nicht mit Ruby ausgestattet, jedoch läßt sich dieses (und auch andere Programmiersprachen) sehr leicht nachträglich installieren.

Hierzu muss man wissen, dass es verschiedene Versionen von Ruby gibt. Ältere Versionen von Ruby on Rails haben hauptsächlich auf die Ruby Version 1.8.7 gesetzt. Die neusten Ruby on Rails Versionen ab 3.0 verwenden jedoch bevorzugt Ruby Version 1.9.2. Um unser System also für die Zukunft vorzubereiten, werden wir auf den Ruby Versions Manager (RVM) setzen, mit dem es möglich ist jede beliebige Ruby Version zu installieren und auch bequem zwischen diesen zu wechseln.

Damit wir RVM installieren können, müssen wir zuerst ein paar Abhängigkeiten installieren:

sudo apt-get install git
sudo apt-get install curl

Git benötigen wir, weil die meisten Ruby on Rails Projekte und Erweiterungen ihre Sourcen mit Git verwalten. Und curl brauchen wir, um mit dem folgenden Befehl RVM zu installieren:

bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)

Nachdem dies ausgeführt wurde, bekommen wir noch ein paar Hinweise vom RVM Entwickler, wie wir damit umgehen können. Unter anderem wird auch noch darauf hingewiesen, dass folgende Abhängigkeiten installiert werden sollten, bevor man damit beginnen kann, ein oder mehrere Ruby Versionen zu installieren:

sudo apt-get install build-essential openssl libreadline6 libreadline6-dev curl git-core zlib1g zlib1g-dev libssl-dev libyaml-dev libsqlite3-0 libsqlite3-dev sqlite3 libxml2-dev libxslt-dev autoconf libc6-dev ncurses-dev automake libtool bison subversion

Nun sollte man das Terminal einmal schließen und wieder ein neues Terminal öffnen und mit folgenden Befehl überprüfen, ob RVM richtig installiert wurde:

type rvm | head -1

Wird hier jetzt 'rvm is a function' zurückgegeben, ist alles in Ordnung und wir können damit beginnen, unsere benötigte Ruby Version zu installieren.

Ruby 1.9.2 auf Ubuntu installieren

Abhängig davon, welche Ruby on Rails Version wir nutzen wollen, können wir nun die entsprechende Ruby Version installieren. Dies ist mit dem RVM Befehlt mehr als einfach. Gehen wir davon aus, dass wir Ruby on Rails 3.1 (also die aktuelle Version) installieren wollen, können wir so Ruby 1.9.2 installieren:

rvm install 1.9.2

Nach ein paar Minuten ist dann Ruby installieret. Beachten sollte man hierbei jedoch unbedingt, dass alles was man mit RVM macht ohne den sudo Befehlt ausgefürt werden muss! Warum dies so ist und weitere wichtige Nutzungshinweise erhaltet ihr in der RVM Dokumentation.

Um nun die installierte Ruby Version nutzen zu können, muss man sie mit dem folgenden Befehl aktivieren:

rvm use 1.9.2

Jetzt kann man überprüfen, welche Ruby Version installiert ist:

ruby -v

Ruby on Rails auf Ubuntu installieren

Nachdem nun alle notwendigen Vorbereitungen abgeschlossen sind, können wir damit beginnen die aktuelle Rails Version zu installieren. Rails und andere benötigte Packete werden mit dem RubyGems Package Manager installiert. Dieser wurde zum Glück auch schon automatisch von RVM mit installiert. Wir brauchen also nur noch folgendes auszuführen:

gem install rails

und schon wurde Ruby on Rails erfolgreich installiert. Auch hier ist wieder zu beachten, dass alle RubyGems ohne den sudo Befehl installiert werden.

JavaScript Runtime installieren

In der aktuellen Rails Version 3.1.1 gibt es noch eine weitere Abhängigkeit, welche man beachten muss. Rails benötigt hier nämlich eine im System installierte JavaScript Runtime um bestimmte Funktionen ausführen zu können. Am einfachsten und problemlosesten konnte ich dieses Problem bei mir beheben, indem ich Node.js installiert habe:

sudo apt-get install nodejs

Ruby on Rails testen

Jetzt wo alles installiert ist, können wir schnell noch ein Testprojekt mit Rails erstellen:

rails new test_app
cd test_app
rails server

und uns dies im Browser aufrufen:

http://localhost:3000

Fertig ist unsere Ruby on Rails installation auf Ubuntu.

Die hier genannten Installationsschritte mögen sich mit denen auf anderen Ubuntu Versionen oder anderen Linux System unterscheiden.

Leider hat sich Microsoft nicht dazu hinreißen lassen, seine neusten Browser auch für Mac OS X zu veröffentlichen, so dass man auf andere Wege und Mittel zurückgreifen muss.

Dual Boot mit BootCamp oder Virtual Machine?

Sicher, Apple bietet uns über BootCamp an, ein anderes Betriebsystem wie Windows XP auf einer zweiten Partition zu installieren. Hat man dies getan, kann man natürlich auch den Internet Explorer unter Windows verwenden.

Allerdings haben wir dadurch auch einige Nachteile, die natürlich nicht verschwiegen werden können. Zum einen müssen wir extra Festplattenplatz für die zweite Partition bereitstellen - Windows ist hier natürlich nicht besonders sparsam -, zum anderen können wir so immer nur ein Betriebssystem gleichzeitig laufen lassen. Was natürlich unpraktisch ist, wenn unsere Entwicklungsumgebung auf Mac OS X läuft.

Bleibt als weitere Möglichkeit noch, Windows in einer virtuellen Maschine zu installieren. Mit Parallels oder VMWare Fusion gibt es hier sehr gute Programme, die es uns sehr leicht machen, ein oder mehrere Betriebssysteme zu installieren und gleichzeitig mit Mac OS X laufen zu lassen.

Doch auch diese Möglichkeit fällt ins Wasser, wenn wir gar keine eigene (offizielle) Installations CD von Windows besitzen und uns auch nicht extra eine zulegen wollen, nur um etwas im Internet Explorer zu testen. Doch was bleibt uns nun noch übrig?

ies4osx - Der Internet Explorer für OS X

Ich weiß, ich weiß. Warum bin habe ich nicht gleich am Anfang erwähnt, das es doch einen Internet Explorer für Mac OS X gibt? Aber ich liebe es, ein wenig Spannung aufzubauen - und seien wir doch mal ehrlich, die Ungeduldigen unter euch haben die vorhergehenden Abschnitte sowieso übersprungen. (Was? Das stimmt wirklich? Dann schnell zurück und noch einmal von vorne lesen!)

Mike Kronenberg schien sich mal die gleichen Fragen gestellt zu haben. Warum kann ich keine Windows Anwendungen unter OS X laufen lassen? Also hat er sich hingesetzt und das Linux Wine Projekt - mit dem viele Windows Anwendungen unter Linux laufen können - auf Mac OS X portiert und als Darwine zur Verfügung gestellt. Dann ist er anscheinend auf das ies4linux Projekt gestoßen, mit dem es möglich war den Internet Explorer 6 mit Hilfe von Wine auf Linux zum Laufen zu bekommen. Dies hat er ebenfalls portiert und herausgekommen ist ies4osx! <tröte>TATAAA!</tröte>

Die Installation von ies4osx ist wirklich sehr einfach. Zuerst die aktuellen Versionen von Darwine und ies4osx herunterladen, Darwine in den Applications Ordner von OS X verschieben, den Installer von ies4osx ausführen und fertig. Der Installer lädt sich die benötigten Dateien herunter und legt eine lauffähige Version vom "Internet Explorer 6" auf dem Desktop ab.

Es ist sogar möglich, Flash, Java und den Mediaplayer 6.4 von Microsoft auf diesem IE 6 zu installieren.

Mein Fazit

Seit ich vom ies4osx Projekt erfahren habe, habe ich immer einen Internet Explorer bei mir auf meinem MacBook laufen und kann so jederzeit meine Seiten auch dort überprüfen. Sicherlich, der Internet Explorer für Mac OS X reagiert oft etwas träge und vor allem wenn Flash im Spiel ist, wird es richtig langsam, aber für den Zweck, meine Seiten im IE 6 zu testen, ist dies vollkommen ausreichend.

Leider gibt es momentan noch keine Version vom IE 7 oder IE 8 für Mac OS X, aber schauen wir mal, was die Zukunft so bringt.

Wie läuft es bei euch? Entwickelt ihr auch unter Mac OS X? Wenn ja, welche Lösungen habt ihr gefunden, um eure Seiten auch auf dem Internet Explorer zu testen?

In den Tagen des Social Webs gehört es unter anderem zu den häufigen Aufgaben eines Entwicklers, XML Dokumente zu generieren, oder APIs auf Basis von XML bereitzustellen. News wollen in Form von RSS oder Atom abonniert werden, Inhalte aus anderen Webangeboten über XML in die eigenen Seiten integriert werden.

XML ist also ziemlich wichtig und daher sollte das Erstellen und die Verarbeitung von XML mit einem Framework wie Ruby on Rails auch so einfach und unkompliziert wie möglich erfolgen.

Was ist Google Sitemaps?

Wie dies funktioniert und welche Schritte dafür notwendig sind, werde ich am Beispiel einer Google Sitemap für ein Blog zeigen. Google stellt mit Google Sitemaps eine Methode zur Verfügung, um neue Inhalte aus dynamischen Webseiten noch schneller in den Google Suchindex aufnehmen zu lassen. Dazu können Webseiten eine sitemap.xml Datei zur Verfügung stellen, welche in Form von XML Daten wie URL, Erstell- bzw. Updatedatum und eine Indizierungspriorität zu allen verfügbaren Seiten - in unserem Fall sind dies die Blogeinträge - enthalten kann.

Rails Generator hilft uns

Bei großen dynamischen Seiten ist es natürlich aufwendig, diese XML Datei immer von Hand zu pflegen, darum wollen wir diese mit den Mitteln von Ruby on Rails automatisch generieren lassen.
Überlegen wir doch erstmal, was wir alles für die geforderte Aufgabe benötigen. Wir brauchen einen Sitemap Controller mit einer index Action, welche wir aufrufen können und die dann schließlich das XML generiert. Also sollten wir zuerst diesen neuen Controller generieren lassen. Dies ist in Ruby on Rails mehr als einfach:

ruby script/generate controller Sitemap index

Dieser Komandozeilenaufruf nimmt uns diese Aufgabe ab. Der Rails Generator legt daraufhin mehrere Dateien an. Unter anderem den Controller sitemap_controller.rb mit der Action index und den View index.html.erb.

     exists  app/controllers/
exists  app/helpers/
create  app/views/sitemap
exists  test/functional/
create  app/controllers/sitemap_controller.rb
create  test/functional/sitemap_controller_test.rb
create  app/helpers/sitemap_helper.rb
create  app/views/sitemap/index.html.erb

Der Controller

Im nächsten Schritt holen wir uns in der bereits für uns angelegten index Action eine Liste mit allen vorhandenen Blogeinträgen und sagen Rails, dass das Ergebnis als XML gerendert werden soll.

class SitemapController < ApplicationController

def index
@articles = BlogArticle.find(:all, :order => 'created_on DESC, updated_on DESC')
respond_to do |format|
format.xml { }
end
end

end

Wie man sehen kann, sortieren wir die gefundenen Blogeinträge absteigend nach Erstellungs- und Bearbeitungsdatum. So ist sichergestellt, dass die aktuellsten Einträge in der XML Datei später immer am Anfang stehen.

Mit Rails XMLBuilder ist XML so einfach wie noch nie

Wie im ersten Schritt zu sehen, hat Rails für uns mit der index.hmtl.erb auch schon die Viewdatei für die index Action erstellt. Da wir jedoch kein HTML sondern XML ausgeben wollen, benennen wir diese Datei in index.xml.builder um.

Diese Umbenennung hat zwei Effekte. Rails wird auf diese Datei automatisch zurückgreifen, wenn XML gerendert werden soll und die Endung .builder teilt Rails mit, dass der Inhalt dieser Datei Anweisungen für den Rails eigenen XML Builder enthält. Mit diesem Builder lassen sich schnell komplexe XML Dateien erstellen, wie wir am folgenden Beispiel sehen werden.

xml.instruct!

xml.urlset "xmlns" => "http://www.google.com/schemas/sitemap/0.84" do
xml.url do
xml.loc         "http://www.name-der-seite.de/"
xml.lastmod     w3c_date(Time.now)
xml.changefreq  "always"
end

@articles.each do |article|
xml.url do
xml.loc         url_for(:only_path => false, :controller => 'blog', :action => 'show', :id => article)
xml.lastmod     w3c_date(article.created_on)
xml.changefreq  "weekly"
xml.priority    0.8
end
end

end

Dieser Code ist so ziemlich selbsterklärend. Es wird über verschiedene xml Anweisungen die Struktur der sitemap.xml erzeugt und über alle BlogArticles iteriert.

Eine Hilfe für das Datumsformat

Zur Ausgabe des Datums im richtigen Format haben wir die Methode w3c_date() im sitemap_helper.rb definiert.

module SitemapHelper

def w3c_date(date)
date.utc.strftime("%Y-%m-%dT%H:%M:%S+00:00")
end

end

Fast fertig

Damit wir diese Action nun auch über die URL http://www.name-der-seite.de/sitemap.xml aufrufen können, werden wir in der Datei routes.rb noch ein entsprechendes Mapping anlegen.

map.connect "sitemap.xml", :controller => "sitemap", :action => "index"

Nun steht dem Aufruf durch Google und der anschließenden erfolgreichen Indizierung unserer gesamten Blogbeiträge nichts mehr im Weg.

Abschließend kann man sagen, dass XML mit Ruby on Rails wirklich nicht schwer ist. Wenn man den gesamten Aufwand betrachtet, so konnten wir die geforderte Funktionalität in 5 bis 10 Minuten umsetzen. Wenn das nicht effektiv ist, was denn dann? :o)