OpenID Connect (OIDC) ist ein Authentifizierungsprotokoll, das auf OAuth 2.0 basiert. Es ermöglicht es Clients (z. B. Web-Apps, Mobile-Apps), die Identität eines Benutzers sicher zu verifizieren, der sich bei einem externen Identitätsanbieter (IdP) anmeldet — zum Beispiel Google, Microsoft, Apple, etc.

🔐 Kurz gesagt:

OAuth 2.0 → regelt die Autorisierung (Zugriff auf Ressourcen)
OpenID Connect → regelt die Authentifizierung (Wer ist der Benutzer?)

🧱 Wie funktioniert OpenID Connect?

1. Benutzer klickt auf "Login mit Google"

2. Deine App leitet den Benutzer zum Google-Login weiter

3. Nach erfolgreichem Login leitet Google den Benutzer mit einem ID Token zurück

4. Deine App validiert dieses JWT-Token

5. Du weißt nun, wer der Benutzer ist – verifiziert von Google

🔑 Was enthält ein ID Token?

Das ID Token ist ein JSON Web Token (JWT) mit Informationen über den Benutzer, z. B.:

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "name": "John Doe",
  "email": "john@example.com",
  "iat": 1650000000,
  "exp": 1650003600
}

• iss = Issuer (z. B. Google)

• sub = Benutzer-ID

• email, name = Benutzerinformationen

• iat, exp = Zeitstempel

🧩 Typische Anwendungsfälle

• "Login mit Google/Microsoft/Apple"

• Single Sign-On (SSO) in Unternehmen

• Zentrale Identitätsverwaltung (Keycloak, Auth0, Azure AD)

• OAuth-basierte APIs mit Identitätsprüfung

🛠️ Komponenten bei OpenID Connect

PEST ist ein moderner Testing-Framework für PHP, das vor allem durch seine lesbare Syntax, Expressivität und enge Integration mit PHPUnit besticht.

📌 PEST = "PHP Testing for Humans"
Es richtet sich an Entwickler, die saubere, lesbare und schnelle Tests schreiben wollen – ohne viel Boilerplate.

🚀 Warum PEST statt PHPUnit?

PEST basiert auf PHPUnit, aber es:

• bietet eine minimalistische, expressive Syntax

• entfernt unnötigen Overhead

• unterstützt funktionalen, verhaltensbasierten Teststil

• lässt sich optional mit einer klassischen PHPUnit-Struktur kombinieren

🔍 Beispiel – PHPUnit vs. PEST

PHPUnit:

class UserTest extends TestCase
{
    public function test_user_has_name()
    {
        $user = new User('John');
        $this->assertEquals('John', $user->name);
    }
}

PEST:

it('has a name', function () {
    $user = new User('John');
    expect($user->name)->toBe('John');
});

👉 Deutlich kürzer, besser lesbar – besonders bei vielen Tests.

🧩 Features von PEST

• ✅ Elegante Syntax (ähnlich wie Jest oder Mocha in JavaScript)

• 🧪 Unterstützt unit, feature, API, browser-based Tests

• 🧱 Datengetriebene Tests (with([...]))

• 🧬 Test-Hooks wie beforeEach() / afterEach()

• 🎨 Erweiterbar über Plugins & eigene Expectations

• 🔄 Kompatibel mit PHPUnit (du kannst PHPUnit-Tests weiter nutzen)

🛠️ Installation

In einem Laravel- oder Composer-Projekt:

composer require pestphp/pest --dev
php artisan pest:install  # (für Laravel-Projekte)

Dann kannst du direkt loslegen:

./vendor/bin/pest

🧠 Fazit

PEST ist ideal, wenn du:

• Tests schreiben willst, die Spaß machen

• sauberen, modernen Code bevorzugst

• bereits PHPUnit nutzt, aber Lust auf mehr Expressivität hast

💡 Viele moderne Laravel-Entwickler steigen auf PEST um, weil es sich perfekt in Laravel-Apps integriert und das Testen „menschlich“ macht – wie der Slogan schon sagt.

Deployer ist ein Open-Source-Deployment-Tool für PHP-Projekte – speziell entwickelt, um Anwendungen wie Laravel, Symfony, Magento, WordPress oder auch generische PHP-Apps automatisiert, wiederholbar und sicher auf Server zu bringen.

🚀 Was macht Deployer besonders?

• Es ist ein CLI-Tool, geschrieben in PHP.

• Du definierst dein Deployment in einer deploy.php-Datei mit klaren Aufgaben (Tasks).

• Es setzt auf das Prinzip Zero Downtime Deployment, z. B. durch Symlinks.

• Unterstützt mehrstufige Umgebungen (z. B. staging, production).

🛠️ Typischer Workflow mit Deployer

Du installierst Deployer über Composer:

composer require deployer/deployer --dev

Du generierst ein Template:

vendor/bin/dep init

Du konfigurierst deploy.php, z. B. für Laravel:

host('mein-server.com')
    ->set('deploy_path', '/var/www/meinprojekt')
    ->set('branch', 'main');

task('deploy', [
    'deploy:prepare',
    'deploy:vendors',
    'artisan:migrate',
    'deploy:publish',
]);

Du startest das Deployment:

vendor/bin/dep deploy production

🔁 Was passiert im Hintergrund?

Deployer:

• Verbindet sich via SSH mit dem Zielserver

• Klont das Git-Repository in ein neues Release-Verzeichnis

• Installiert Composer-Abhängigkeiten

• Führt Tasks aus (z. B. php artisan migrate)

• Verlinkt das neue Release mit dem Live-Verzeichnis (current)

• Löscht alte Releases nach Bedarf

📦 Vorteile von Deployer

Datenbank-Trigger (kurz: Trigger) sind spezielle automatische Aktionen in einer Datenbank, die ausgelöst werden, wenn bestimmte Ereignisse auf einer Tabelle oder Sicht (View) passieren.

🔧 Was macht ein Trigger?

Ein Trigger ist ein vordefinierter Code, der bei INSERT, UPDATE oder DELETE auf einer Tabelle automatisch ausgeführt wird – ohne dass der Benutzer ihn direkt aufruft.

🧠 Beispiel:

Stell dir vor, du hast eine Tabelle Bestellungen, und du willst, dass immer, wenn eine Bestellung gelöscht wird, diese Info in einer Tabelle Log gespeichert wird.

Dann schreibst du einen DELETE-Trigger für die Tabelle Bestellungen, der automatisch beim Löschen etwas in Log schreibt.

🔄 Arten von Triggern:

CREATE TRIGGER log_delete
AFTER DELETE ON Bestellungen
FOR EACH ROW
BEGIN
  INSERT INTO Log (aktion, zeitpunkt)
  VALUES ('Bestellung gelöscht', NOW());
END;

✅ Wofür werden Trigger verwendet?

• Validierung von Daten

• Automatisches Logging

• Business-Logik abbilden

• Referentielle Integrität erweitern

⚠️ Nachteile:

• Schwer zu debuggen

• Können unbemerkt viele Aktionen auslösen

• Beeinflussen Performance, wenn komplex

GitHub Actions ist ein Feature von GitHub, mit dem du automatisierte Workflows für deine Softwareprojekte erstellen kannst – direkt im GitHub-Repository.

🛠️ Was kann man mit GitHub Actions machen?

Du kannst CI/CD-Pipelines (Continuous Integration / Continuous Deployment) aufbauen, z. B.:

• ✅ Code automatisch testen (z. B. mit PHPUnit, Jest, Pytest)

• 🛠️ Code bei jedem Push oder Pull Request builden

• 🚀 Software automatisch deployen (z. B. auf einen Webserver, in die Cloud, zu DockerHub)

• 📦 Releases erstellen (z. B. ZIP-Dateien, Versionstags)

• 🔄 Cronjobs oder geplante Tasks laufen lassen

🧱 Wie funktioniert es?

GitHub Actions basiert auf sogenannten Workflows, die du in einer Datei definierst:

• Die Datei heißt z. B. .github/workflows/ci.yml

• Sie ist im YAML-Format

• Du definierst Events (z. B. push, pull_request) und Jobs (z. B. build, test)

• Jobs bestehen aus Steps, die Befehle oder Aktionen ausführen

Beispiel: Einfacher CI-Workflow für Node.js

name: CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '20'
      - run: npm install
      - run: npm test

🧩 Was sind "Actions"?

Eine Action ist ein einzelner Schritt, den man in einem Workflow ausführt. Es gibt:

• Vorgefertigte Actions (z. B. actions/checkout, setup-node, upload-artifact)

• Eigene Actions (z. B. Shell-Skripte oder Docker-Container)

Du kannst Actions im GitHub Marketplace finden und nutzen.

💡 Warum ist das nützlich?

• Spart manuelle Arbeit

• Verbessert Codequalität (durch automatisierte Tests)

• Macht Deployments reproduzierbar

• Alles direkt in GitHub – kein externer CI-Dienst nötig (wie Jenkins oder Travis CI)

Storyblok ist ein benutzerfreundliches, headless Content-Management-System (CMS), das Entwicklern und Marketing-Teams hilft, Inhalte schnell und effizient zu erstellen, zu verwalten und zu veröffentlichen. Es bietet eine visuelle Bearbeitungsoberfläche, die es ermöglicht, Inhalte in Echtzeit zu gestalten, und ist flexibel mit verschiedenen Frameworks und Plattformen kompatibel. Durch seine API-first-Architektur können Inhalte auf jeder digitalen Plattform ausgespielt werden, was es ideal für moderne Web- und App-Entwicklung macht.

Ein Prepared Statement (auch vorbereitetes Statement genannt) ist eine Technik in der Programmierung, insbesondere bei der Arbeit mit Datenbanken, um SQL-Abfragen sicherer und effizienter auszuführen.

1. Was passiert bei einem Prepared Statement?

Ein Prepared Statement besteht aus zwei Schritten:

1. Vorbereitung der SQL-Abfrage mit Platzhaltern
   Beispiel in SQL:

SELECT * FROM users WHERE username = ? AND password = ?

• (In manchen Sprachen nutzt man auch :username oder andere Platzhalter)

• Bindung der Parameter und Ausführung
  Die echten Werte werden später „gebunden“, z. B.:

$stmt->bind_param("ss", $username, $password);
$stmt->execute();

2. Vorteile

✅ Sicherer vor SQL-Injection:
Benutzereingaben werden nicht direkt in die SQL eingebaut, sondern separat behandelt.

✅ Schneller bei Wiederholungen:
Die SQL-Abfrage wird vom Datenbankserver einmal geparst und kann mehrfach effizient ausgeführt werden (z. B. bei Schleifen).

$conn = new mysqli("localhost", "user", "pass", "database");
$stmt = $conn->prepare("SELECT * FROM users WHERE email = ?");
$stmt->bind_param("s", $email); // "s" für string
$email = "beispiel@example.com";
$stmt->execute();
$result = $stmt->get_result();

Kurz gesagt:

Ein Prepared Statement trennt SQL-Logik von Benutzereingaben und schützt so vor Sicherheitslücken wie SQL-Injection. Es ist eine Best Practice beim Umgang mit Datenbanken.

Ein Outer Join ist ein Begriff aus der Datenbankabfrage (meist in SQL) und bezeichnet eine spezielle Art, zwei Tabellen miteinander zu verknüpfen – auch dann, wenn keine passenden Datensätze in einer der Tabellen vorhanden sind.

Arten von Outer Joins:

1. LEFT OUTER JOIN (oder einfach: LEFT JOIN):
   → Gibt alle Datensätze aus der linken Tabelle zurück, auch wenn es keine passenden Datensätze in der rechten Tabelle gibt.
   → Nicht passende Werte aus der rechten Tabelle werden mit NULL aufgefüllt.

2. RIGHT OUTER JOIN (oder: RIGHT JOIN):
   → Gibt alle Datensätze aus der rechten Tabelle zurück, auch wenn es keine passenden in der linken gibt.
   → Nicht passende Werte aus der linken Tabelle werden mit NULL ergänzt.

3. FULL OUTER JOIN:
   → Gibt alle Datensätze aus beiden Tabellen zurück.
   → Wo keine Übereinstimmung vorliegt, wird mit NULL ergänzt.

Beispiel:

Angenommen, du hast zwei Tabellen:

• Kunden

  Kundennr	Name
  1	Anna
  2	Bernd
  3	Clara

• Bestellungen

  Bestellnr	Kundennr	Produkt
  101	2	Buch
  102	4	Lampe

LEFT JOIN (Kunden LEFT JOIN Bestellungen ON Kunden.Kundennr = Bestellungen.Kundennr)

Transaction Control Language (TCL) ist ein Teil der SQL-Sprache, der verwendet wird, um die Kontrolle über Transaktionen in einer Datenbank zu ermöglichen. Eine Transaktion ist eine logische Einheit von Arbeit, die eine oder mehrere SQL-Anweisungen umfasst – oft Insert-, Update- oder Delete-Befehle –, die zusammen ausgeführt werden sollen.

TCL stellt Befehle bereit, um sicherzustellen, dass Transaktionen korrekt abgeschlossen oder im Fehlerfall rückgängig gemacht werden.

Die wichtigsten TCL-Befehle:

BEGIN;

UPDATE konto SET saldo = saldo - 100 WHERE konto_id = 1;
UPDATE konto SET saldo = saldo + 100 WHERE konto_id = 2;

COMMIT;

→ Beide Updates werden gemeinsam abgeschlossen. Wenn ein Fehler auftritt, könnte man ROLLBACK ausführen, um beide Änderungen zu verwerfen.

Wichtig:

TCL-Befehle wirken nur bei Datenbank-Systemen, die Transaktionen unterstützen (z. B. PostgreSQL, Oracle, MySQL mit InnoDB).

Die Data Manipulation Language (DML) ist ein Teilbereich der SQL (Structured Query Language), der für das Bearbeiten von Daten in einer Datenbank verwendet wird. Mit DML können Benutzer Daten einfügen, abfragen, ändern und löschen – also genau das, was man im Alltag mit Daten in einer Datenbank machen möchte.

Zu den wichtigsten DML-Befehlen gehören:

Beispiel:

-- Einfügen
INSERT INTO kunden (name, stadt) VALUES ('Müller', 'Berlin');

-- Abfragen
SELECT * FROM kunden WHERE stadt = 'Berlin';

-- Aktualisieren
UPDATE kunden SET stadt = 'Hamburg' WHERE name = 'Müller';

-- Löschen
DELETE FROM kunden WHERE name = 'Müller';

Wichtig:

• DML arbeitet mit den Daten innerhalb der Tabellen, nicht mit der Struktur der Tabellen selbst (dafür gibt es die Data Definition Language, DDL).

• DML-Befehle können oft rückgängig gemacht werden (z. B. durch ROLLBACK), sofern Transaktionen unterstützt werden.

Kurz gesagt: DML ist das Werkzeug, mit dem du Daten in einer Datenbank lebendig hältst – also ständig anpasst, liest und veränderst.