Aber im Laufe der Zeit sind diese Abenteuer immer weniger geworden. Nicht, weil mich das Thema nicht mehr interessiert – ich arbeite tatsächlich jeden Tag als "Webentwickler" in meinem Beruf - aber ich habe langsam das Gefühl, das die Zeit der technischen Blogs sich seinem Ende nähert.

In Zeiten von AI ist der erste Reflex, wenn man sich mit einem Thema beschäftigt, nicht mehr die Suche nach interessanten Blog-Beiträgen anderer Entwickler. Stattdessen fragt man einfach die KI nach Details und bekommt immer häufiger auch die ausreichenden Antworten. Selbst auf Google klickt man nicht mehr auf die Suchergebnisse, sondern bekommt die Antwort direkt an erster Stelle angezeigt.

Wer liest dann überhaupt noch meinen Blog?

Ich habe das Gefühl – nur noch die KI selbst – wenn überhaupt.

Ich bin daher zu der Erkenntnis gekommen, dass ich vorranging nicht mehr für andere Entwickler oder Gleichgesinnte schreiben möchte (schon gar nicht nur für die KI), sondern ich möchte für mich schreiben.

Denn eigentlich ist es doch das Schreiben an sich, dass mir Spaß macht. Technische Artikel kann die KI hundertmal besser schreiben als ich. Aber die eigenen Gedanken und Gefühle aufs Papier zu bringen (oder in diesem Fall ins Blog), dass kann einem die KI nicht abnehmen.

Und das ist auch der Grund, warum ich die Ausrichtung dieses Blogs überdenke und den Fokus in Zukunft weniger auf technische Beiträge, sondern auf das Schreiben selber lenken möchte.

Um das zu unterstreichen, habe ich sogar das komplette Design der Seiten so angepasst, dass es das Geschriebene hervorhebt. Das Handwerkliche. Keine kalten, glatten Beiträge, keine Perfektion, sondern authentische Gefühle, unfertige Gedanken.

Ich habe mich in der letzten Zeit sehr intensiv mit dem Thema Schreiben auseinandergesetzt. Ja ich habe sogar zwei kleinere Bücher geschrieben. Und ich bin dabei an Software zu arbeiten, die mich (und andere) beim Schreiben unterstützen soll. Doch mehr dazu später.

Das Schreiben besitzt also gerade einen ziemlich großen Fokus in meinem Leben und vielleicht führt das ja auch dazu, dass ich wieder mehr Spaß an meinem eigenen Blog finden werde.

Wer auch immer bis hierhin gelesen hat... Schön das du da bist!

Wenn es dann im Frontend interaktiv werden musste, zum Beispiel bei einem Modaldialog für eine Bestätigung oder ein Einstellungsfenster, griff ich fast schon reflexartig zu schwerem Besteck: Bootstrap-Klassen, Tailwind UI-Komponenten oder custom Stimulus-Controllern, die mühsam das Ein- und Ausblenden regeln.

Vor Kurzem habe ich mich jedoch gefragt: Gibt es da mittlerweile nicht etwas Moderneres direkt im Browser?

Die Antwort lautet: Ja, und es ist genial! Das native HTML-Element <dialog> löst eines der nervigsten Frontend-Probleme komplett ohne externe JavaScript-Bibliotheken. In diesem Artikel zeige ich dir, wie du als Backend- oder Fullstack-Entwickler mit minimalem Aufwand moderne, barrierefreie Modals erstellst.

Was ist das <dialog>-Element?

Das <dialog>-Element ist ein standardisiertes HTML5-Element zur Darstellung von Dialogboxen, Modals oder Popups. Obwohl es schon länger in den Web-Spezifikationen existiert, hat es in den letzten Jahren einen exzellenten Browser-Support erreicht und ist im modernen Web-Development nicht mehr wegzudenken.

Das Besondere daran: Der Browser übernimmt für uns die gesamte logische Schwerstarbeit, die man früher mühsam mit JavaScript programmieren musste.

Warum ist das ein absoluter Game-Changer?

Wenn du früher ein Modal selbst gebaut hast, musstest du an unglaublich viele Dinge denken:

1. Focus Trapping: Der Tastatur-Fokus (Tabulatortaste) darf das Modal nicht verlassen, solange es offen ist.
2. Schließen per ESC-Taste: Der Benutzer erwartet, dass sich das Modal mit Esc schließt.
3. Barrierefreiheit (Accessibility): Screenreader müssen erkennen, dass ein Modal aktiv ist, und den Hintergrund temporär ignorieren.
4. Hintergrund-Sperre: Scrollen auf der restlichen Seite sollte verhindert werden.

Das native <dialog>-Element macht all das automatisch out-of-the-box. Kein langes Herumprobieren, keine zusätzlichen Accessibility-Bugs.

Praktisches Beispiel: Unser erstes natives Modal

Lass uns ein einfaches, aber voll funktionsfähiges Modal bauen. Wir benötigen dazu ein wenig HTML, minimales CSS für das Styling des Hintergrunds und nur drei Zeilen native JavaScript-API (ganz ohne Libraries).

1. Das HTML-Markup

<!-- Ein einfacher Button, der den Dialog öffnet -->
<button id="open-modal-btn" class="btn-primary">Profil bearbeiten</button>

<!-- Das native Dialog-Element -->
<dialog id="profile-dialog">
  <div class="dialog-content">
    <h2>Profil bearbeiten</h2>
    <p>Hier kannst du deinen Benutzernamen aktualisieren.</p>

    <!-- form[method="dialog"] schließt das Modal automatisch beim Absenden -->
    <form method="dialog">
      <div class="form-group">
        <label for="username">Benutzername:</label>
        <input type="text" id="username" name="username" placeholder="webmatze" required>
      </div>

      <div class="dialog-actions">
        <!-- Ein Button mit type="submit" schließt das Modal und gibt den Wert zurück -->
        <button type="submit" value="cancel" class="btn-secondary">Abbrechen</button>
        <button type="submit" value="save" class="btn-success">Speichern</button>
      </div>
    </form>
  </div>
</dialog>

2. Das JavaScript (Die native Browser-API)

Obwohl wir keine Bibliotheken brauchen, müssen wir dem Browser sagen, wann er das Modal öffnen soll. Das geht über die native JavaScript-Schnittstelle des Elements:

// DOM-Elemente selektieren
const dialog = document.getElementById('profile-dialog');
const openButton = document.getElementById('open-modal-btn');

// Dialog als echtes Modal öffnen
openButton.addEventListener('click', () => {
  dialog.showModal(); 
});

// Optional: Event-Listener, um auf das Schließen zu reagieren
dialog.addEventListener('close', () => {
  console.log(`Dialog geschlossen mit dem Wert: ${dialog.returnValue}`);
});

3. Das Styling mit modernem CSS

Mit dem CSS-Pseudo-Element ::backdrop können wir den Hintergrund hinter dem geöffneten Dialog kinderleicht abdunkeln oder weichzeichnen – ein Feature, für das man früher oft extra Wrapper-Klassen brauchte.

/* Styling für das Dialog-Fenster selbst */
dialog {
  border: none;
  border-radius: 12px;
  box-shadow: 0 10px 30px rgba(0, 0, 0, 0.2);
  padding: 0;
  width: 90%;
  max-width: 500px;
}

/* Der abgedunkelte Hintergrund hinter dem Modal */
dialog::backdrop {
  background-color: rgba(15, 23, 42, 0.6); /* Edles Schiefergrau mit Transparenz */
  backdrop-filter: blur(4px); /* Schöner Weichzeichner-Effekt */
}

/* Einfache Einblend-Animation */
dialog[open] {
  animation: fadeIn 0.3s ease-out forwards;
}

@keyframes fadeIn {
  from {
    opacity: 0;
    transform: scale(0.95);
  }
  to {
    opacity: 1;
    transform: scale(1);
  }
}

Schritt-für-Schritt-Erklärung: Wie funktioniert das?

showModal() vs. show()

Im JavaScript verwenden wir dialog.showModal(). Das ist wichtig! Es gibt auch eine Methode namens dialog.show(), aber diese öffnet den Dialog nur als "normales" Element auf der Seite (ohne Fokus-Sperre und ohne abgedunkelten Hintergrund). Nur showModal() macht daraus ein echtes, barrierefreies Modalfenster, das über allen anderen Elementen liegt.

Das magische form[method="dialog"]

Wenn du innerhalb des Dialogs ein Formular mit method="dialog" verwendest, passiert etwas Magisches: Sobald einer der Submit-Buttons geklickt wird, schließt der Browser den Dialog automatisch.

• Der Wert des Attributs value des geklickten Buttons wird im Dialog-Objekt als dialog.returnValue gespeichert. So kannst du im JavaScript ganz einfach auslesen, ob der User auf "Speichern" oder "Abbrechen" geklickt hat.

Der Rails-Kontext: Perfekt für Hotwire & Turbo!

Da ich viel mit Ruby on Rails und Hotwire arbeite, war mir wichtig zu sehen, wie gut sich das <dialog>-Element dort integrieren lässt. Die Antwort ist: Es harmoniert perfekt!

Wenn du ein Modal dynamisch per Server-Side-Rendering nachladen möchtest, kannst du das <dialog>-Element einfach in ein turbo-frame packen. Sobald der Frame vom Server geladen wird, öffnet ein minimaler Stimulus-Controller das Modal:

# app/views/profiles/edit.html.erb
<%= turbo_frame_tag "modal" do %>
  <dialog data-controller="modal" data-action="close->modal#cleanup">
    <h2>Profil bearbeiten</h2>
    <%= form_with model: @profile, method: :put do |f| %>
      <!-- Formularfelder -->
      <%= f.submit "Speichern" %>
    <% end %>
  </dialog>
<% end %>

Der dazugehörige Stimulus-Controller benötigt lediglich eine einzige Methode zum automatischen Starten:

// app/javascript/controllers/modal_controller.js
import { Controller } from "@hotwire/stimulus"

export default class extends Controller {
  connect() {
    this.element.showModal()
  }

  cleanup() {
    // Entfernt das Modal aus dem DOM nach dem Schließen, falls gewünscht
    this.element.remove()
  }
}

Das ist extrem sauberer Code. Keine komplizierten CSS-Klassen-Toggles, kein Z-Index-Chaos in Tailwind. Der Browser regelt das einfach nativ.

Browser-Kompatibilität

Du fragst dich vielleicht, ob du das Element schon produktiv einsetzen kannst. Die Antwort ist ein klares Ja!

Seit März 2022 wird das <dialog>-Element von allen großen Browser-Engines (Chromium, WebKit, Gecko) vollständig unterstützt. Das bedeutet uneingeschränkten Support in Google Chrome, Apple Safari, Mozilla Firefox und Microsoft Edge – sowohl auf dem Desktop als auch auf dem Smartphone.

Zusammenfassung & Key Takeaways

Als Entwickler, der sich gerne auf das Backend konzentriert, hat mich das <dialog>-Element absolut begeistert. Es nimmt uns die lästige Detailarbeit bei der UI-Programmierung ab und sorgt gleichzeitig für barrierefreie Webanwendungen.

• Kein JavaScript-Overhead: Modale Dialoge lassen sich mit minimalem nativem JavaScript öffnen.
• Automatische Barrierefreiheit: Fokus-Sperre (Focus Trapping) und die Tastatursteuerung über die Esc-Taste funktionieren sofort.
• Styling leicht gemacht: Mit dem ::backdrop-Selektor lässt sich der Hintergrund edel stylen (inklusive Weichzeichner).
• Perfektes Teamspiel: Integriert sich nahtlos in moderne Backend-Frameworks wie Ruby on Rails mit Hotwire/Turbo.

Wenn du also das nächste Mal ein modales Fenster bauen musst, spar dir den Griff zur nächsten JavaScript-Library. Probier stattdessen das native <dialog>-Element aus – dein Code (und deine User) werden es dir danken!

Weiterführende Ressourcen

• MDN Web Docs: The Dialog Element
• Can I Use: HTML
  element

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

Die Lösung: .git/info/exclude

Was ist .git/info/exclude?

Diese Datei funktioniert genau wie .gitignore, wird aber nicht ins Repository committed und bleibt lokal auf deinem Rechner. Jedes Git-Repository hat diese Datei bereits – du musst sie nur mit Einträgen füllen.

Praktische Git-Aliases für den Alltag

Um die Arbeit mit lokalen Excludes zu vereinfachen, habe ich mir einige Git-Aliases erstellt, die ich hier teilen möchte.

1. Dateien zum Exclude hinzufügen

git config --global alias.exclude '!f() { echo "$1" >> .git/info/exclude; }; f'

Verwendung:

git exclude "meine-lokale-datei.txt"
git exclude "tmp/"
git exclude "*.local"

2. Alle Exclude-Einträge anzeigen

git config --global alias.excluded '!grep -v "^#" .git/info/exclude | grep -v "^$"'

Verwendung:

git excluded

Dieser Befehl zeigt alle Einträge aus .git/info/exclude an und filtert dabei Kommentare und Leerzeilen heraus.

3. Betroffene Dateien auflisten

git config --global alias.excluded-files '!git ls-files -o --ignored --exclude-from=.git/info/exclude'

Verwendung:

git excluded-files

Zeigt alle ungetrackten Dateien, die durch .git/info/exclude ignoriert werden.

4. Bonus: Alle ignorierten Dateien anzeigen

Falls du alle ignorierten Dateien sehen willst – aus .gitignore, .git/info/exclude und der globalen Ignore-Datei kombiniert:

git config --global alias.ignored '!git ls-files -o --ignored --exclude-standard'

Verwendung:

git ignored

Hinweis zu Git-Aliases mit Argumenten

Bei der Erstellung des exclude-Aliases bin ich auf eine Besonderheit gestoßen: Git hängt Argumente automatisch ans Ende eines Aliases an. Verwendet man zusätzlich $1, erscheint das Argument doppelt.

Die Lösung ist das Wrapping in eine Shell-Funktion:

# Falsch – Argument erscheint doppelt:
git config --global alias.exclude '!echo "$1" >> .git/info/exclude'

# Richtig – Funktion verhindert das Problem:
git config --global alias.exclude '!f() { echo "$1" >> .git/info/exclude; }; f'

Fazit

Mit diesen einfachen Aliases wird die Arbeit mit lokalen Git-Excludes zum Kinderspiel. Du kannst Dateien schnell ausschließen, dir einen Überblick verschaffen und behältst die Kontrolle darüber, was in deinem Repository getrackt wird – ohne die .gitignore für alle anderen zu verändern.

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)

Wir alle wissen aber auch, dass es nicht leicht ist, als kreativer Kopf Aufmerksamkeit zu bekommen, geschweige denn davon leben zu können.

Und nun gibt es auch noch Konkurrenz aus einer ganz anderen Ecke für alle Kreativen. Die KI ist auf dem Weg, uns Menschen in kreativer Hinsicht den Rang abzulaufen.

Bilder erstellen? Für die KI kein Problem. Oder vielleicht gleich ganze Videos? Schafft die KI auch. Aber was ist mit Musik? Die kann doch nicht einfach generiert werden, oder?

Ich habe die letzen Tage einige Tools ausprobiert, die es uns erlauben mittels KI ganze Songs zu generieren. Vor allem SUNO hat mich überzeugt.

Es benötigt nur einen einfachen, kurzen Prompt, und schon wird ein kompletter Song innerhalb weniger Sekunden erzeugt. Und das Erschreckende ist, diese künstlich erzeugten Songs sind nicht einmal schlecht.

Seit Version 4 von SUNO kann man sie praktisch kaum noch von 'echten' Liedern unterscheiden.

Hier sind ein paar Beispiele, die ich zusammen mit meinen Kindern erstellt habe. Sie haben mir die Grundidee des Songs genannt, ich habe den Prompt geschrieben, und SUNO macht den Rest.

Ich schwebe:

Nacht der Schatten:

Mein Leben ist schön:

Oder auch auf englisch:

Was haltet ihr von KI-Song-Generatoren? Könnt ihr euch vorstellen, solche Musik zu hören? Würdet ihr überhaupt merken, dass ein Song künstlich erzeugt wurde?

Heute möchte ich euch ein cooles Tool vorstellen, das mir und meinem Team das Leben deutlich einfacher macht: Das Git Dashboard!

Was ist das Git Dashboard?

Stellt euch vor, ihr kommt morgens ins Büro und wollt schnell wissen:

• Was habt ihr gestern alles committed?
• Was haben eure Teammitglieder gemacht?
• Wer war besonders aktiv?

Genau dafür haben wir das Git Dashboard entwickelt! Mit einem einzigen Befehl bekommt ihr einen übersichtlichen Report über alle Aktivitäten in eurem Repository.

Wie funktioniert's?

Super einfach! Nach der Installation könnt ihr zum Beispiel eingeben:

git dashboard              # Zeigt den Report von gestern
git dashboard -d today     # Zeigt den heutigen Report
git dashboard --date 2024-12-18  # Zeigt den Report für ein bestimmtes Datum

Was macht es so besonders?

• Zeigt eure persönlichen Commits übersichtlich an
• Listet die Commits eurer Teammitglieder auf
• Erstellt eine Rangliste mit Commit-Zahlen und geänderten Zeilen
• Berücksichtigt alle Branches
• Flexibel im Datum - heute, gestern oder jedes andere Datum

Perfekt für Daily Standups!

Keine Panik mehr vor der Frage "Was hast du gestern gemacht?". Ein schnelles git dashboard und ihr habt alle Infos parat!

Probiert es aus!

Das Tool ist Open Source und super einfach zu installieren. Schaut euch das Projekt auf GitHub an und gebt ihm einen Stern, wenn es euch gefällt!

Installation in zwei Schritten:

git clone https://github.com/webmatze/git-dashboard.git
./install.sh

Viel Spaß beim Ausprobieren!

P.S.: Feedback und Contributions sind immer willkommen!

Die folgende Funktion erweitert den klassischen 'cat' Befehl so, dass er sowohl mit lokalen Dateien als auch mit URLs umgehen kann:

Die Funktion prüft mittels eines regulären Ausdrucks, ob das übergebene Argument eine URL ist. Falls ja, wird curl verwendet, um den Inhalt herunterzuladen und anzuzeigen. Bei normalen Dateien wird der Standard-cat-Befehl verwendet.

Beispiele für die Verwendung:

• cat datei.txt -> Zeigt den Inhalt einer lokalen Datei
• cat https://github.com/beispiel -> Zeigt den HTML-Inhalt der Website

Die Funktion könnt ihr einfach in eure ~/.zshrc einfügen und nach dem Neuladen der Shell sofort nutzen.

Ein kleiner, aber feiner Hack, der den Workflow beim Arbeiten mit Dateien und Webinhalten vereinfacht. Das ist Unix-Philosophie at its best: Bestehende Werkzeuge erweitern, ohne ihre ursprüngliche Funktionalität zu beeinträchtigen.

Die Meta Ray-Ban Smart Glasses sind eine spannende Kombination aus Sonnenbrille und innovativer Technologie. Ausgestattet mit Mikrofonen, Lautsprechern und Kameras, bieten sie die Möglichkeit, unterwegs Anrufe zu tätigen, Musik zu hören, Fotos und Videos aufzunehmen und natürlich auch die digitalen Assistenten von Meta zu nutzen. Besonders hervorzuheben ist die nahtlose Integration der Meta AI Features, die durch Sprachsteuerung das smarte Erlebnis erweitern. Doch leider stehen diese AI-Funktionen aktuell in der EU nicht zur Verfügung.

Warum? Regulierungshindernisse. In der EU gibt es strenge Datenschutzrichtlinien, die sicherstellen sollen, dass die Nutzerdaten gut geschützt werden. Meta ist aufgrund dieser Vorschriften derzeit nicht in der Lage, das Meta AI Feature für Nutzer innerhalb der EU freizugeben. Das bedeutet, dass alle, die die brillanten AI-gestützten Funktionen der Brille nutzen möchten, in Europa vorerst leer ausgehen.

Doch zum Glück gibt es eine Lösung für alle, die sich nicht damit zufriedengeben möchten. Mit einem VPN kann man die AI Features trotzdem aktivieren und vollständig nutzen.

Anleitung: Meta AI mit VPN aktivieren

Folge einfach diesen Schritten, um die Meta AI Features auch in Deutschland zu aktivieren:

1. Meta View App deinstallieren: Zuerst musst du die Meta View App von deinem Smartphone deinstallieren, da wir einen neuen Installationsprozess starten werden.
2. VPN aktivieren und Standort USA auswählen: Verbinde dich über eine VPN-App mit einem Server in den USA. Dadurch denkt Meta, dass du dich in den USA befindest.
3. Meta View App neu installieren: Lade die Meta View App erneut herunter und installiere sie auf deinem Smartphone.
4. Einrichtungsprozess durchlaufen: Starte die Meta View App und folge den normalen Einrichtungsschritten für deine Ray-Ban Smart Glasses. Im Laufe der Einrichtung wirst du nun die Möglichkeit haben, die Meta AI Features zu aktivieren.
5. VPN deaktivieren: Nachdem alles eingerichtet ist, kannst du das VPN wieder ausschalten. Die Meta AI Features sind weiterhin auf deiner Brille aktiv und voll nutzbar – auch ohne dauerhaftes VPN.

Fazit

Mit ein paar einfachen Schritten und der Hilfe eines VPN kannst du die vollen Meta AI Features deiner Ray-Ban Smart Glasses auch in Europa nutzen. Diese smarte Lösung ermöglicht es, das volle Potenzial der Brille auszuschöpfen und die innovativen Funktionen in den Alltag zu integrieren. Also, warum warten? Hol dir die smarte Zukunft schon jetzt nach Hause!

Der unmittelbare Reiz von KI-Werkzeugen in der Entwicklung liegt in ihrem Versprechen von Effizienz. Stellen wir uns eine Welt vor, in der die mühsame Arbeit des Programmierens von KI übernommen wird und Entwickler sich auf höherwertige Problemlösungen und kreatives Denken konzentrieren können. Dies ist kein Wunschtraum. KI-Werkzeuge können in Sekundenschnelle große Mengen an Code analysieren und Fehler entdecken, die menschliche Augen Stunden kosten könnten. Sie können Optimierungen vorschlagen, Code umstrukturieren und sogar routinemäßige Funktionen autonom schreiben. Die potenziellen Zeitersparnisse sind enorm und bieten einen Einblick in eine Zukunft, in der Entwicklungszyklen drastisch verkürzt und die Produktivität enorm gesteigert wird.

Diese Effizienz kommt jedoch mit einem Vorbehalt: dem Risiko der Überabhängigkeit. Wenn Entwickler beginnen, sich stärker auf KI für alltägliche Aufgaben zu verlassen, besteht die Gefahr, dass grundlegende Fähigkeiten verkümmern. Programmieren ist ebenso eine Kunst wie eine Wissenschaft und erfordert nicht nur ein Verständnis der Syntax, sondern auch eine tiefgehende Intuition für Problemlösungen. Eine Überabhängigkeit von KI könnte Entwickler zu Aufsehern statt zu Schöpfern machen und möglicherweise die Fähigkeiten abstumpfen, die ihre Expertise definieren.

Neben der Effizienz versprechen KI-Werkzeuge eine Demokratisierung der Entwicklung. Mit der Unterstützung von KI können auch Personen mit begrenzten Programmierkenntnissen funktionale Anwendungen erstellen, was die Eintrittsbarriere für technologische Unternehmungen und Innovationen senkt. Dies könnte zu einer Welle von Kreativität und Vielfalt in der Technologielandschaft führen, da mehr Stimmen die Mittel finden, ihre Ideen zum Leben zu erwecken. Doch diese Demokratisierung ist nicht ohne Schattenseiten. Da die Entwicklung zugänglicher wird, könnte der Markt mit Anwendungen unterschiedlicher Qualität übersättigt werden, was es schwieriger macht, wirklich innovative Ideen hervorzuheben. Zudem könnte die Leichtigkeit der Erstellung ethische Dilemmata aufwerfen, da böswillige Akteure diese Werkzeuge für schädliche Zwecke nutzen.

Die Integration von KI in die Entwicklung wirft auch Fragen zur Arbeitsplatzverdrängung auf. Während KI die Produktivität steigern kann, weckt sie auch Ängste vor der Automatisierung, die menschliche Arbeitsplätze ersetzen könnte. Diese Sorge ist nicht unbegründet; die Geschichte ist voller Beispiele, in denen Technologie bestimmte Fähigkeiten überflüssig gemacht hat. Es ist jedoch auch zu beachten, dass Technologie stets neue Möglichkeiten geschaffen hat, auch wenn sie andere schließt. Die Herausforderung besteht darin, sich an diese Veränderungen anzupassen und sicherzustellen, dass Entwickler die Fähigkeiten und das Wissen haben, um mit KI zu arbeiten, anstatt von ihr verdrängt zu werden.

Schließlich gibt es das Thema Kreativität. KI kann Code schreiben, aber kann sie auch innovieren? Entwicklung bedeutet nicht nur, Lösungen für bekannte Probleme zu finden; es geht darum, Möglichkeiten zu sehen, die noch niemand anderes gesehen hat. Das menschliche Element – unsere Fähigkeit zu träumen, außerhalb der Algorithmen zu denken – ist es, was wahre Innovation antreibt. Während KI-Werkzeuge den kreativen Prozess unterstützen können, können sie nicht den Funken menschlicher Genialität ersetzen.

Zusammenfassend lässt sich sagen, dass die Entwicklungslandschaft zweifellos durch KI-Werkzeuge transformiert wird. Sie bieten eine Welt der Effizienz, Zugänglichkeit und Möglichkeiten, die vor wenigen Jahrzehnten noch unvorstellbar war. Doch während wir diese Werkzeuge annehmen, müssen wir auch die Herausforderungen beachten, die sie mit sich bringen. Das Gleichgewicht zwischen Effizienz und Fähigkeitserwerb, Demokratisierung und Qualitätskontrolle sowie Automatisierung und Arbeitsplatzschaffung wird der Schlüssel sein, um diese neue Ära zu navigieren. Vor allem müssen wir uns daran erinnern, dass KI ein Werkzeug zur Verbesserung der menschlichen Kreativität ist, nicht zu deren Ersatz. Die Zukunft der Entwicklung liegt nicht in der Wahl zwischen Mensch oder Maschine, sondern in der Nutzung der Stärken beider.