🛠️ What is GitHub Actions?

GitHub Actions is a feature of GitHub that lets you create automated workflows for your software projects—right inside your GitHub repository.

📌 What can you do with GitHub Actions?

You can build CI/CD pipelines (Continuous Integration / Continuous Deployment), such as:

• ✅ Automatically test code (e.g. with PHPUnit, Jest, Pytest)

• 🛠️ 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)

🧱 How does it work?

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

Example: Simple CI Workflow for 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

🧩 What are "Actions"?

An 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.

💡 Why use GitHub Actions?

• 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

Docker Compose is a tool that lets you define and run multi-container Docker applications using a single configuration file. Instead of starting each container manually via the Docker CLI, you can describe all your services (like a web app, database, cache, etc.) in a docker-compose.yml file and run everything with a single command.

In short:

Docker Compose = Project config + Multiple containers + One command to run it all

Example: docker-compose.yml

version: '3.9'
services:
  web:
    build: .
    ports:
      - "5000:5000"
    volumes:
      - .:/code
  redis:
    image: "redis:alpine"

This file:

• Builds and runs a local web app container

• Starts a Redis container from the official image

• Automatically networks the two containers

Common Commands:

docker-compose up        # Start all services in the foreground
docker-compose up -d     # Start in detached (background) mode
docker-compose down      # Stop and remove containers, networks, etc.

Benefits of Docker Compose:

✅ Easy setup for multi-service applications
✅ Version-controlled config (great for Git)
✅ Reproducible development environments
✅ Simple startup/shutdown of entire stacks

Typical Use Cases:

• Local development with multiple services (e.g., web app + DB)

• Integration testing with full stack

• Simple deployment workflows (e.g., via CI/CD)

A Headless CMS (Content Management System) is a system where the backend (content management) is completely separated from the frontend (content presentation).

In detail:

Traditional CMS (e.g., WordPress):

• Backend and frontend are tightly coupled.

• You create content in the system and it's rendered directly using built-in themes and templates with HTML.

• Pros: All-in-one solution, quick to get started.

• Cons: Limited flexibility, harder to deliver content across multiple platforms (e.g., website + mobile app).

Headless CMS:

• Backend only.

• Content is accessed via an API (usually REST or GraphQL).

• The frontend (e.g., a React site, native app, or digital signage) fetches the content dynamically.

• Pros: Very flexible, ideal for multi-channel content delivery.

• Cons: Frontend must be built separately (requires more development effort).

Common use cases:

• Websites built with modern JavaScript frameworks (like React, Next.js, Vue)

• Mobile apps that use the same content as the website

• Omnichannel strategies: website, app, smart devices, etc.

Examples of Headless CMS platforms:

• Contentful

• Strapi

• Sanity

• Directus

• Prismic

• Storyblok (a hybrid with visual editing capabilities)

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.

Shopware is a modular e-commerce system from Germany that allows you to create and manage online stores. It’s designed for both small retailers and large enterprises, known for its flexibility, scalability, and modern technology.

🔹 General Information:

• Developer: Shopware AG (founded in 2000 in Germany)

• Technology: PHP, Symfony framework, API-first approach

• Current Version: Shopware 6 (since 2019)

• Open Source: Yes, with paid extensions available

• Headless Ready: Yes, supports headless commerce via APIs

🔹 Key Features:

• Product Management: Variants, tier pricing, media, SEO tools

• Sales Channels: Web shop, POS, social media, marketplaces

• Content Management: Built-in CMS ("Shopping Experiences")

• Payments & Shipping: Many integrations (e.g. PayPal, Klarna)

• Multilingual & Multi-Currency Support

• B2B & B2C capabilities

• App System & API for custom extensions

🔹 Who is Shopware for?

• Startups (free Community Edition available)

• SMEs and mid-sized businesses

• Enterprise clients with complex needs

• Very popular in the DACH region (Germany, Austria, Switzerland)

🔹 Advantages:

• Made in Germany → GDPR-compliant

• Highly customizable

• Active ecosystem & community

• Scalable for growing businesses

Design by Contract (DbC) is a concept in software development introduced by Bertrand Meyer. It describes a method to ensure the correctness and reliability of software by defining clear "contracts" between different components (e.g., methods, classes).

Core Principles of Design by Contract

In DbC, every software component is treated as a contract party with certain obligations and guarantees:

1. Preconditions
   Conditions that must be true before a method or function can execute correctly.
   → Responsibility of the caller.

2. Postconditions
   Conditions that must be true after the execution of a method or function.
   → Responsibility of the method/function.

3. Invariant (Class Invariant)
   Conditions that must always remain true throughout the lifetime of an object.
   → Responsibility of both the method and the caller.

Goal of Design by Contract

• Clear specification of responsibilities.

• More robust and testable software.

• Errors are detected early (e.g., through contract violations).

Example in Pseudocode

class BankAccount {
    private double balance;

    // Invariant: balance >= 0

    void withdraw(double amount) {
        // Precondition: amount > 0 && amount <= balance
        if (amount <= 0 || amount > balance) throw new IllegalArgumentException();

        balance -= amount;

        // Postcondition: balance has been reduced by amount
    }
}

Benefits

• Clear contracts reduce misunderstandings.

• Easier debugging, as violations are detected immediately.

• Supports defensive programming.

Drawbacks

• Requires extra effort to define contracts.

• Not directly supported by all programming languages (e.g., Java and C++ via assertions, Python with decorators; Eiffel supports DbC natively).

Perl Compatible Regular Expressions (PCRE) are a type of regular expression syntax and engine that follows the powerful and flexible style of the Perl programming language. They offer advanced features that go beyond the basic regular expressions found in many older systems.

Why "Perl Compatible"?

Perl was one of the first languages to introduce highly expressive regular expressions. The PCRE library was created to bring those capabilities to other programming languages and tools, including:

• PHP

• Python (similar via the re module)

• JavaScript (with slight differences)

• pcregrep (a grep version supporting PCRE)

• Editors like VS Code, Sublime Text, etc.

Key Features of PCRE:

✅ Lookahead & Lookbehind:

• (?=...) – positive lookahead

• (?!...) – negative lookahead

• (?<=...) – positive lookbehind

• (?<!...) – negative lookbehind

✅ Non-greedy quantifiers:

• *?, +?, ??, {m,n}?

✅ Named capturing groups:

• (?P<name>...) or (?<name>...)

✅ Unicode support:

• \p{L} matches any kind of letter in any language

✅ Assertions and anchors:

• \b, \B, \A, \Z, \z

✅ Inline modifiers:

• (?i) for case-insensitive

• (?m) for multiline matching, etc.

(?<=\buser\s)\w+

This expression matches any word that follows "user " using a lookbehind assertion.

Summary:

PCRE are like the "advanced edition" of regular expressions — highly powerful, widely used, and very flexible. If you're working in an environment that supports PCRE, you can take advantage of rich pattern matching features inspired by Perl.

“Link Juice” is a term from Search Engine Optimization (SEO) that refers to the value or authority passed from one webpage to another through hyperlinks. This "juice" helps influence how well a page ranks in search engine results (especially Google).

In simple terms:

When website A links to website B, it passes on some of its credibility or authority — that’s the "link juice." The more trusted and relevant site A is, the more juice it passes.

Key factors that influence link juice:

• Authority of the linking site (e.g., a major news site vs. a small blog)

• Number of outgoing links: The more links on a page, the less juice each one gets.

• Follow vs. Nofollow: Only dofollow links typically pass link juice. Nofollow links (with rel="nofollow") usually don’t.

• Link placement: A link within the main content has more value than one in the footer or sidebar.

• Relevance: A link from a site with related content carries more weight.

Example:

A backlink from Wikipedia to your site gives you a ton of link juice — Google sees it as a sign of trust. A link from an unknown or spammy site, on the other hand, might do little or even harm your rankings.

SVG stands for Scalable Vector Graphics. It's an XML-based file format used to describe 2D graphics. SVG allows for the display of vector images that can be scaled to any size without losing quality. It's widely used in web design because it offers high resolution at any size and integrates easily into web pages.

Here are some key features of SVG:

• Vector-based: SVG graphics are made up of lines, curves, and shapes defined mathematically, unlike raster images (like JPEG or PNG), which are made of pixels.

• Scalability: Since SVG is vector-based, it can be resized to any dimension without losing image quality, making it ideal for responsive designs.

• Interactivity and Animation: SVG supports interactivity (e.g., via JavaScript) and animation (e.g., via CSS or SMIL).

• Search engine friendly: SVG content is text-based and can be indexed by search engines, offering SEO benefits.

• Compatibility: SVG files are supported by most modern web browsers and are great for logos, icons, charts, and other graphics.

The "Happy Path" (also known as the "Happy Flow") refers to the ideal scenario in software development or testing where everything works as expected, no errors occur, and all inputs are valid.

Example:

Let’s say you’re developing a user registration form. The Happy Path would look like this:

1. The user enters all required information correctly (e.g., a valid email and secure password).

2. They click “Register.”

3. The system successfully creates an account.

4. The user is redirected to a welcome page.

➡️ No validation errors, no server issues, and no unexpected behavior.

What is the purpose of the Happy Path?

• Initial testing focus: Developers and testers often check the Happy Path first to make sure the core functionality works.

• Basis for use cases: In documentation or requirements, the Happy Path is typically the main scenario before covering edge cases.

• Contrasts with edge cases / error paths: Anything that deviates from the Happy Path (e.g., missing password, server error) is considered an "unhappy path" or "alternate flow."