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)

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!

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.

Heute möchte ich euch einen nützlichen Tipp für eure Git-Konfiguration zeigen: das Einrichten einer globalen .gitignore-Datei. Diese Methode ist super praktisch, wenn ihr bestimmte Dateien oder Dateitypen habt, die ihr in all euren Projekten ignorieren möchtet, ohne die lokale .gitignore-Datei in jedem Repository manuell anzupassen.
Das ist bei mir zum Beispiel dann der Fall, wenn ich lokale Tools nutze, die ihre Konfigurationsdateien im Repository-Verzeichnis ablegen, die ich aber nie einchecken möchte.

Warum eine globale .gitignore-Datei?

Eine globale .gitignore-Datei ermöglicht es euch, Ignore-Muster zu definieren, die in allen euren Git-Repositories gelten. Das ist besonders nützlich, wenn ihr häufig mit Dateien arbeitet, die ihr in jedem Projekt ignorieren möchtet, wie z.B. Log-Dateien oder temporäre Dateien.

Schritt-für-Schritt-Anleitung

1. Erstelle die globale .gitignore-Datei

Zuerst müsst ihr eine globale .gitignore-Datei erstellen. Diese Datei kann irgendwo auf eurem System liegen, aber ein üblicher Ort ist das Home-Verzeichnis. Ihr könnt sie beispielsweise .gitignore_global nennen.

touch ~/.gitignore_global

2. Füge Muster zur globalen .gitignore-Datei hinzu

Jetzt könnt ihr die ~/.gitignore_global-Datei bearbeiten und die Muster hinzufügen, die ihr global ignorieren möchtet. Dafür könnt ihr jeden beliebigen Texteditor verwenden. Hier ein Beispiel:

# Beispielhafte globale .gitignore-Datei
*.log
*.tmp

3. Konfiguriere Git, um die globale .gitignore-Datei zu verwenden

Als nächstes müsst ihr Git mitteilen, dass es diese globale .gitignore-Datei verwenden soll. Dazu verwendet ihr den git config Befehl:

git config --global core.excludesfile ~/.gitignore_global

4. Überprüfe die Konfiguration

Um sicherzustellen, dass Git eure globale .gitignore-Datei verwendet, könnt ihr die Konfiguration überprüfen:

git config --get core.excludesfile

Dieser Befehl sollte den Pfad zu eurer globalen .gitignore-Datei ausgeben (z.B. /home/euerbenutzername/.gitignore_global).

Wie funktioniert das?

• Die globale .gitignore-Datei ergänzt die Ignore-Muster, die in der lokalen .gitignore-Datei eures Repositories definiert sind.
• Muster, die in der globalen .gitignore-Datei definiert sind, werden in allen euren Git-Repositories ignoriert.
• Die lokale .gitignore-Datei in einem spezifischen Repository hat Vorrang vor der globalen Datei. Das bedeutet, dass bei einem Konflikt die Regeln der lokalen .gitignore-Datei angewendet werden.

Mit diesen Schritten könnt ihr sowohl globale als auch lokale Ignore-Regeln effektiv in eurem Git-Workflow verwalten.

Ich hoffe, dieser Tipp hilft euch dabei, eure Git-Konfiguration ein bisschen effizienter zu gestalten. Viel Spaß beim Codieren!

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!

Als Jugentlicher wollte ich unbedingt Turbo Pascal lernen und habe mir als Projekt ein einfaches Sokoban Spiel genommen und es umgesetzt. Im Laufe der Umsetzung habe ich vieles über Turbo Pascal gelernt und auch dessen Grenzen entdeckt. So musste ich z.B. einige der Grafikroutinen dann doch mit Assembler umsetzen.

Da mich das Programmieren von grafischen Spielereien (Demos) oder eben auch gleich richtigen Spielen schon immer faziniert hat, habe ich mich auch gleich für das DragonRuby Game Toolkit interessiert. Dieses erlaubt es euch, mit Hilfe der Ruby Programmiersprache 2D oder auch 3D Spiele zu programmieren.

Und da ich wieder nach einer Idee für ein Spiel suchte, dachte ich mir: "Hey, warum versucht du nicht einfach das gleiche Spiel wie damals umzusetzen?".

Gesagt – getan.

Also habe ich angefangen und entstanden ist dabei DragonRuby Sokoban.

Den Code findet ihr wie immer auf meinen GitHub Account.

Und wer es nicht erwarten kann, kann das Spiel auch gleich hier ausprobieren:

Viel Spaß!

Host Alias

Wollen wir nicht immer den vollen Hostnamen eingeben müssen, um uns per SSH mit einem Server zu verbinden, lohnt es sich eine SSH Konfiguration ~/.ssh/config zu erstellen.

Dort definieren wir dann einen Alias Namen für den Ziel Host. In unserem Fall „myserver“ und legen mit HostName fest, welcher Host sich dahinter verbergen soll. Außerdem können wir uns sparen, immer einen User angeben zu müssen, indem wir diesen per User Eintrag festlegen.

Host myserver
	HostName remote.server.com
	User ouruser

Nun können wir uns ganz einfach verbinden:

$ ssh myserver

Über einen Jump Host mit einem anderen Host verbinden

Manchmal kann man sich nur über einen dritten Server (Jump Host) mit einem anderen Server verbinden. Die SSH Syntax dafür ist jedoch nicht einfach zu merken. Nehmen wir an wir wollen uns über den Jump Host jump.host.com mit unserem Ziel Host remote.server.com verbinden, dann müssen wir normalerweise folgendes eingeben:

$ ssh -J ouruser@jump.host.com:22 remote.server.com

Es ist jedoch deutlich einfacher, dies alles ebenfalls in der SSH Konfiguration ~/.ssh/configzu definieren.

In unserem Fall können wir ProxyJump verwenden, um den Jump Host zu definieren, über den wir uns mit dem Ziel Host verbinden wollen.

Den Jump Host selber definieren wir ebenfalls über einen Host Eintrag:

Host jumphost
	HostName jump.host.com
	User ouruser
	ProxyCommand none

Host myserver
	HostName remote.server.com
	User ouruser
	ProxyJump jumphost

Nun können wir uns mit dem Ziel Host verbinden und werden automatisch über den Jump Host geschickt:

$ ssh myserver

In der SSH Konfiguration läßt sich allerdings noch viel mehr konfigurieren. Eine ausführlichere Anleitung findet sich hier ssh_config(5) - OpenBSD manual pages

Von Hause aus ist ein Chromebook nicht mehr als ein Chrome Browser mit ein paar erweiterten Funktionen. Jedoch eignet es sich kaum für entwicklungstechnische Aufgaben. Es ist zwar nicht unmöglich, auf einem Chromebook zu programmieren, aber man stößt schnell an die Grenzen.

Auch ich habe mir dazu längere Zeit Gedanken gemacht und einiges ausprobiert. So habe ich zum Beispiel den (jetzt leider eingestellten) Service von Nitrous.io genutzt, um auf einer externen Virtuellen Maschine und mit einem Editor in einem Browser zu arbeiten. Aber man ist von den externen Anbietern abhängig, es kommen regelmäßige Kosten auf einen zu und wenn man Pech hat, wird der Service irgendwann einfach eingestellt - wie in diesem Fall geschehen.

Es musste also eine bessere Möglichkeit gefunden werden. Zum Glück ist es mittlerweile relativ einfach möglich, Linux parallel zu Chrome OS laufen lassen. Und unter Linux kann man dann leicht eine Entwicklungsumgebung einrichten und nutzen.

Hier stelle ich euch vor, welche Schritte man durchführen muss und auf welche Schwierigkeiten man stoßen kann.

Chromebook in den Developer Modus schalten

Damit man Linux auf einem Chromebook nutzen kann, muss dieses zuerst in den Developer Modus geschaltet werden. Wie dies geschieht, kann von Chromebook zu Chromebook unterschiedlich sein.

Auf chromium.org gibt es hierfür für die meisten Modelle eine entsprechende Anleitung.

Ich selber verwende das Acer C740 welches sich durch Drücken der Tasten Escape und Refresh und dann auf Power in den Developer Mode versetzten lässt. (Achtung! Nur Refresh und Power setzt das Chromebook in den Werkszustand zurück!) Bitte beachtet auch, dass dieser Vorgang alle Daten auf eurem Chromebook löscht und das System komplett neu einrichtet!

Crouton herunterladen

Im nächsten Schritt müssen wir Crouton herunterladen. Hierbei handelt es sich um ein Programm, mit dem sich verschiedene Linux Chroot Umgebungen installieren lassen. Es ist somit also auch möglich, mehrere verschiedene Linux Systeme nebeneinander betreiben zu können.

Dazu einfach die Datei herunterladen oder auf der Seite von Crouton den entsprechenden Link suchen.

Ubuntu Trusty mit XFCE Windowmanager installieren

Nun müssen wir mit der Tastenkombination Strg + Alt + T ein Terminal öffnen. In diesem Terminal wird die Chrome OS Developer Shell (crosh) ausgeführt. Hier geben wir dann folgenden Befehl ein:

crosh> shell
chronos@localhost / $

Nun können wir Crouton aus dem Downloads Ordner heraus ausführen und Ubuntu Trusty mit dem Window Manager XFCE installieren:

sudo sh ~/Downloads/crouton -r trusty -t xfce

Dieser Vorgang dauert etwas länger. Es werden alle benötigten Linux Bibliotheken heruntergeladen und installiert. Wenn alles fertig ist, können wir die Chroot Umgebung starten.

Ubuntu starten

Mit folgendem Befehl starten wir Ubuntu:

sudo enter-chroot

Damit kommen wir in die Shell von Ubuntu. Auch wenn XFCE ein netter Window Manager ist, möchte ich doch lieber einen einfach zu bedienenden und performanten Tiling Window Manager wie i3 nutzen. Diesen können wir direkt gleich installieren:

sudo apt-get install i3

XFCE starten und i3 einrichten

Wir können an dieser Stelle die Shell mit Strg + D wieder schließen und XFCE starten:

sudo startxfce4

Wir rufen dann im Menü 'Session and Startup' die Einstellungen 'Application Autostart' auf und fügen mit '+ Add' einen neues Kommando mit folgenden Werten hinzu:

• Name: i3
• Description: i3
• Command: /usr/bin/i3

Dann gehen wir zu 'Session and Startup > Session' wählen alle Einträge die xfce enthalten aus und schließen diese indem wir auf 'Quit program' klicken. Danach speichern wir die Session und starten die Chroot Umgebung neu.

i3 sollte jetzt automatisch starten und funktionsfähig sein.

Warum ein Window Manager wie i3?

Warum nutzen wir nicht einfach die normale Shell von Ubuntu, sondern installieren einen Window Manager? Aber der Vorteil liegt klar auf der Hand. Mit i3 können sehr leicht mehrere Shells geöffnet und positioniert werden, auch in verschiedenen Workspaces. Außerdem können grafische Programme wie Firefox oder auch der Atom Editor geöffnet werden. Gerade dies ist wichtig, wenn wir komfortabel unseren Code eingeben und bearbeiten wollen.

Das System lässt sich einfach individuell anpassen und erweitern. Ihr wollte ein anderes Hintergrundbild? Oder Ruby, Node oder ähnliche Dinge installieren? Die Möglichkeiten sind praktisch unendlich.

Hier findet ihr drei sehr gute Einführungsvideos zu i3.

Ich hoffe ich konnte euch zeigen, welche Möglichkeiten in eurem Chromebook stecken. Wenn Ihr Fragen habt, stellt diese einfach in den Kommentaren.