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

A Join Point is a concept from Aspect-Oriented Programming (AOP).

Definition:

A Join Point is a specific point during the execution of program code where additional behavior (called an aspect) can be inserted.

Typical examples of Join Points:

• Method calls

• Method executions

• Field access (read/write)

• Exception handling

Context:

In AOP, cross-cutting concerns (like logging, security, or transaction management) are separated from the main business logic. These concerns are applied at defined points in the program flow — the Join Points.

Related terms:

• Pointcut: A way to specify which Join Points should be affected (e.g., "all methods starting with save").

• Advice: The actual code that runs at a Join Point (e.g., "log this method call").

• Aspect: A combination of Pointcut(s) and Advice(s) — the full module that implements a cross-cutting concern.

Example (in Spring AOP):

@Before("execution(* com.example.service.*.*(..))")
public void logBeforeMethod(JoinPoint joinPoint) {
    System.out.println("Calling method: " + joinPoint.getSignature().getName());
}

→ This logs a message before every method call in a specific package. The joinPoint.getSignature() call provides details about the actual Join Point.

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.

SLD (Styled Layer Descriptor) is an XML-based standard developed by the Open Geospatial Consortium (OGC). It is used to define the styling of geospatial data in web mapping services like WMS (Web Map Service).

What does SLD do?

SLD describes how certain geospatial features should be rendered on a map — meaning it defines colors, lines, symbols, labels, and more. With SLD, you can specify things like:

• Roads should appear red.

• Water bodies in blue, with a certain transparency.

• Points should have symbols that vary depending on attribute values (e.g., population).

• Text labels over features.

Technically:

• SLD is an XML file with a defined structure.

• It can be read by WMS servers like GeoServer or MapServer.

• The file includes Rules, Filters, and Symbolizers like LineSymbolizer, PolygonSymbolizer, or TextSymbolizer.

Example of a simple SLD snippet:

<Rule>
  <Name>Water Bodies</Name>
  <PolygonSymbolizer>
    <Fill>
      <CssParameter name="fill">#0000FF</CssParameter>
    </Fill>
  </PolygonSymbolizer>
</Rule>

Why is it useful?

• To create custom-styled maps (e.g., thematic maps).

• To define styling server-side, so the map is rendered correctly regardless of the client.

• For interactive web GIS applications that react to attribute values.

If you're working with geospatial data — for example in QGIS or GeoServer — you'll likely come across SLD when you need fine-grained control over how your maps look.

The SLD (Second-Level Domain) is the part of a domain name that appears directly to the left of the Top-Level Domain (TLD).

Example:

In the domain
👉 example.com

• .com is the TLD (Top-Level Domain)

• example is the SLD (Second-Level Domain)

Domain Structure (from right to left):

More Examples:

Why it matters:

The SLD is usually the custom, chosen part of the domain—often representing a company name, brand, or project. It's the most recognizable and memorable part of a domain name.

A hyperscaler is a company that provides cloud services on a massive scale — offering IT infrastructure such as computing power, storage, and networking that is flexible, highly available, and globally scalable. Common examples of hyperscalers include:

• Amazon Web Services (AWS)

• Microsoft Azure

• Google Cloud Platform (GCP)

• Alibaba Cloud

• IBM Cloud (on a somewhat smaller scale)

Key characteristics of hyperscalers:

1. Massive scalability
   They can scale their services virtually without limits, depending on the customer's needs.

2. Global infrastructure
   Their data centers are distributed worldwide, enabling high availability, low latency, and redundancy.

3. Automation & standardization
   Many operations are automated (e.g., provisioning, monitoring, billing), making services more efficient and cost-effective.

4. Self-service & pay-as-you-go
   Customers usually access services via web portals or APIs and pay only for what they actually use.

5. Innovation platform
   Hyperscalers offer not only infrastructure (IaaS), but also platform services (PaaS), as well as tools for AI, big data, or IoT.

What are hyperscalers used for?

• Hosting websites or web applications

• Data storage (e.g., backups, archives)

• Big data analytics

• Machine learning / AI

• Streaming services

• Corporate IT infrastructure