OpenID Connect (OIDC) is an authentication protocol built on top of OAuth 2.0. It allows clients (like web or mobile apps) to verify the identity of a user who logs in via an external identity provider (IdP) — such as Google, Microsoft, Apple, etc.
OAuth 2.0 → handles authorization (access to resources)
OpenID Connect → handles authentication (who is the user?)
User clicks "Login with Google"
Your app redirects the user to Google’s login page
After successful login, Google redirects back with an ID token
Your app validates this JWT token
You now know who the user is — verified by Google
The ID token is a JSON Web Token (JWT) containing user identity data, like:
{
"iss": "https://accounts.google.com",
"sub": "1234567890",
"name": "John Doe",
"email": "john@example.com",
"iat": 1650000000,
"exp": 1650003600
}iss = issuer (e.g. Google)
sub = user ID
email, name = user info
iat, exp = issued at / expiration
“Login with Google/Microsoft/Apple”
Single Sign-On (SSO) in organizations
Centralized user identity (Keycloak, Auth0, Azure AD)
OAuth APIs that require identity verification
| Component | Description |
|---|---|
| Relying Party | Your app (requests login) |
| Identity Provider | External login provider (e.g. Google) |
| ID Token | JWT containing the user’s identity |
| UserInfo Endpoint | (Optional) endpoint for additional user data |
PEST is a modern testing framework for PHP that focuses on clean syntax, readability, and developer experience. It builds on PHPUnit but provides a much more expressive and minimalistic interface.
📌 PEST = "PHP Testing for Humans"
It’s designed for developers who want to write fast, readable, and elegant tests — with less boilerplate.
PEST is built on top of PHPUnit, but it:
Provides a cleaner, simpler syntax
Removes unnecessary structure
Encourages a functional, behavior-driven style
Still supports traditional PHPUnit classes if needed
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');
});👉 Much shorter and easier to read — especially when writing many tests.
✅ Elegant, expressive syntax (inspired by Jest/Mocha)
🧪 Supports unit, feature, API, and browser-based testing
🧱 Data-driven testing via with([...])
🧬 Test hooks like beforeEach() / afterEach()
🎨 Fully extensible with plugins and custom expectations
🔄 Fully compatible with PHPUnit — you can run both side by side
In a Laravel or Composer project:
composer require pestphp/pest --dev
php artisan pest:install # for Laravel projectsThen run tests:
./vendor/bin/pestPEST is ideal if you:
Want to write tests that are fun and easy to maintain
Prefer clean, modern syntax
Already use PHPUnit but want a better experience
💡 Many Laravel developers are adopting PEST because it integrates seamlessly with Laravel and truly makes testing feel "human" — just like its slogan says.
Deployer is an open-source deployment tool for PHP projects — specifically designed to automate, standardize, and securely deploy applications like Laravel, Symfony, Magento, WordPress, or any custom PHP apps.
It’s a CLI tool, written in PHP.
You define your deployment process in a deploy.php configuration file with clearly defined tasks.
It supports zero-downtime deployment using symbolic links (symlinks).
It supports multi-environment deployments (e.g., staging, production).
Install Deployer via Composer:
composer require deployer/deployer --devGenerate a config template:
vendor/bin/dep initConfigure deploy.php, e.g., for Laravel:
host('my-server.com')
->set('deploy_path', '/var/www/myproject')
->set('branch', 'main');
task('deploy', [
'deploy:prepare',
'deploy:vendors',
'artisan:migrate',
'deploy:publish',
]);Deploy your app:
vendor/bin/dep deploy productionDeployer:
Connects to the server via SSH
Clones your Git repo into a new release directory
Installs Composer dependencies
Runs custom tasks (e.g., php artisan migrate)
Updates the symlink to point to the new release (current)
Removes old releases if configured
Database triggers are special automated procedures in a database that are automatically executed when certain events occur on a table or view.
Imagine you have a table called Orders, and you want to automatically log every time an order is deleted.
You can create a DELETE trigger on the Orders table that inserts a message into a Log table whenever a row is deleted.
| Type | Description |
|---|---|
| BEFORE | Executes before the triggering action |
| AFTER | Executes after the triggering action |
| INSTEAD OF | (for views) replaces the triggering action |
CREATE TRIGGER log_delete
AFTER DELETE ON Orders
FOR EACH ROW
BEGIN
INSERT INTO Log (action, timestamp)
VALUES ('Order deleted', NOW());
END;Data validation
Audit logging
Enforcing business rules
Extending referential integrity
Can be hard to debug
Might trigger other actions unexpectedly
Can impact performance if overly complex
GitHub Actions is a feature of GitHub that lets you create automated workflows for your software projects—right inside your GitHub repository.
You can build CI/CD pipelines (Continuous Integration / Continuous Deployment), such as:
🛠️ Build your app on every push or pull request
🚀 Automatically deploy (e.g. to a server, cloud platform, or DockerHub)
📦 Create releases (e.g. zip packages or version tags)
🔄 Run scheduled tasks (cronjobs)
GitHub Actions uses workflows, defined in a YAML file inside your repository:
Typically stored as .github/workflows/ci.yml
You define events (like push, pull_request) and jobs (like build, test)
Each job consists of steps, which are shell commands or prebuilt actions
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 testAn Action is a single reusable step in a workflow. You can use:
Prebuilt actions (e.g. actions/checkout, setup-node, upload-artifact)
Custom actions (e.g. shell scripts or Docker-based logic)
You can explore reusable actions in the GitHub Marketplace.
Saves time by automating repetitive tasks
Improves code quality through automated testing
Enables consistent, repeatable deployments
Integrated directly in GitHub—no need for external CI tools like Jenkins or Travis CI
Storyblok is a user-friendly, headless Content Management System (CMS) that helps developers and marketing teams create, manage, and publish content quickly and efficiently. It offers a visual editing interface for real-time content design and is flexible with various frameworks and platforms. Its API-first architecture allows content to be delivered to any digital platform, making it ideal for modern web and app development.
A Prepared Statement is a programming technique, especially used when working with databases, to make SQL queries more secure and efficient.
It consists of two steps:
Prepare the SQL query with placeholders
Example in SQL:
SELECT * FROM users WHERE username = ? AND password = ?
(Some languages use :username or other types of placeholders.)
Bind parameters and execute
The real values are bound later, for example:
$stmt->bind_param("ss", $username, $password);
$stmt->execute();✅ Protection against SQL injection:
User input is treated separately and safely, not directly inserted into the SQL string.
✅ Faster with repeated use:
The SQL query is parsed once by the database server and can be executed multiple times efficiently (e.g., in loops).
$conn = new mysqli("localhost", "user", "pass", "database");
$stmt = $conn->prepare("SELECT * FROM users WHERE email = ?");
$stmt->bind_param("s", $email); // "s" stands for string
$email = "example@example.com";
$stmt->execute();
$result = $stmt->get_result();A Prepared Statement separates SQL logic from user input, making it a secure (SQL Injection) and recommended practice when dealing with databases.
An Outer Join is a type of database join (commonly used in SQL) that returns records from one or both tables even if there’s no matching record in the other table.
LEFT OUTER JOIN (or simply: LEFT JOIN):
→ Returns all records from the left table, and the matching ones from the right table.
→ If there’s no match, the result is filled with NULL values from the right table.
RIGHT OUTER JOIN (or: RIGHT JOIN):
→ Returns all records from the right table, and the matching ones from the left table.
→ If there’s no match, NULL is used for the left side.
FULL OUTER JOIN:
→ Returns all records from both tables, with NULL where no match exists on either side.
Suppose you have two tables:
Customers
| CustomerID | Name |
| 1 | Anna |
| 2 | Bernd |
| 3 | Clara |
Orders
| OrderID | CustomerID | Product |
| 101 | 2 | Book |
| 102 | 4 | Lamp |
| CustomerID | Name | OrderID | Product |
|---|---|---|---|
| 1 | Anna | NULL | NULL |
| 2 | Bernd | 101 | Book |
| 3 | Clara | NULL | NULL |
Transaction Control Language (TCL) is a subset of SQL used to manage transactions in a database. A transaction is a logical unit of work that may consist of one or more SQL statements—typically INSERT, UPDATE, or DELETE—that should be executed together.
TCL provides commands to ensure that transactions are properly completed or rolled back in case of errors.
| Command | Description |
|---|---|
COMMIT |
Saves all changes made in the current transaction permanently to the database. |
ROLLBACK |
Undoes all changes made since the last COMMIT. |
SAVEPOINT |
Creates a named point within a transaction that you can roll back to later. |
ROLLBACK TO SAVEPOINT |
Reverts changes back to a specific savepoint. |
SET TRANSACTION |
Defines characteristics for the current transaction (e.g., isolation level). |
BEGIN;
UPDATE account SET balance = balance - 100 WHERE account_id = 1;
UPDATE account SET balance = balance + 100 WHERE account_id = 2;
COMMIT;→ Both updates are completed together. If an error occurs, you could use ROLLBACK to cancel both operations.
TCL commands only work in database systems that support transactions (e.g., PostgreSQL, Oracle, or MySQL with InnoDB).
Data Manipulation Language (DML) is a subset of SQL (Structured Query Language) used to manage and manipulate data within a database. With DML, users can insert, query, update, and delete data — essentially everything you'd typically do with data stored in a database.
| Command | Purpose |
|---|---|
SELECT |
Retrieve data from a table |
INSERT |
Add new data |
UPDATE |
Modify existing data |
DELETE |
Remove data |
-- Insert
INSERT INTO customers (name, city) VALUES ('Müller', 'Berlin');
-- Query
SELECT * FROM customers WHERE city = 'Berlin';
-- Update
UPDATE customers SET city = 'Hamburg' WHERE name = 'Müller';
-- Delete
DELETE FROM customers WHERE name = 'Müller';DML deals with the data inside tables, not with the structure of the tables themselves (that's handled by Data Definition Language, DDL).
DML operations can often be rolled back (undone), especially when transactions are supported.
In short: DML is the toolset you use to keep your database dynamic and interactive by constantly adding, reading, modifying, or deleting data.
Renovate
