bg_image
header

Google Apps Script

🔧 What is Google Apps Script?

Google Apps Script is a cloud-based scripting language developed by Google, based on JavaScript. It allows you to automate tasks, extend functionality, and connect various Google Workspace apps like Google Sheets, Docs, Gmail, Calendar, and more.


📌 What can you do with it?

  • Automatically format, filter, or sync data in Google Sheets.

  • Send, organize, or analyze emails in Gmail.

  • Automatically process responses from Google Forms.

  • Create and manage events in Google Calendar.

  • Build custom menus, dialogs, and sidebars in Google apps.

  • Develop web apps or custom APIs that integrate with Google services.


✅ Benefits

  • Free to use (with a Google account).

  • Runs entirely in the cloud—no setup or hosting required.

  • Seamless integration with Google Workspace.

  • Well-documented with many examples and tutorials.


🧪 Example (Auto-fill cells in Google Sheets)

function fillColumn() {
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet();
  const range = sheet.getRange("A1:A10");
  for (let i = 1; i <= 10; i++) {
    range.getCell(i, 1).setValue("Row " + i);
  }
}

GitHub Actions

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


Contentful

Contentful is a headless content management system (headless CMS). It allows businesses to manage content centrally and deliver it flexibly to various channels—such as websites, apps, or digital displays—via APIs.


What does “Headless” mean?

Traditional CMS platforms (like WordPress) handle both content management and content presentation (e.g., rendering on a website). A headless CMS separates the content backend from the presentation frontend—hence the term “headless,” as the “head” (the frontend) is removed.


Key features of Contentful:

  • API-first: Content is accessed via REST or GraphQL APIs.

  • Flexible content modeling: You can define your own content types (e.g., blog posts, products, testimonials) with customizable fields.

  • Multi-language support: Well-suited for managing multilingual content.

  • Cloud-based: No server maintenance needed.

  • Integration-friendly: Works well with tools like React, Vue, Next.js, Shopify, SAP, etc.


Who is Contentful for?

  • Companies with multiple delivery channels (websites, apps, smartwatches, etc.)

  • Teams that want to develop frontend and backend separately

  • Large brands with global content needs

  • Developer teams seeking a scalable and flexible CMS

 


Headless CMS

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

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

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

 


Entity Manager

💡 What is an Entity Manager?

An Entity Manager is a core component of ORM (Object-Relational Mapping) frameworks, especially in Java (JPA – Java Persistence API), but also in other languages like PHP (Doctrine ORM).


📦 Responsibilities of an Entity Manager:

  1. Persisting:

  2. Finding/Loading:

    • Retrieves an object by its ID or other criteria.

    • Example: $entityManager->find(User::class, 1);

  3. Updating:

    • Tracks changes to objects and writes them to the database (usually via flush()).

  4. Removing:

    • Deletes an object from the database.

    • Example: $entityManager->remove($user);

  5. Managing Transactions:

    • Begins, commits, or rolls back transactions.

  6. Handling Queries:


🔁 Entity Lifecycle:

The Entity Manager tracks the state of entities:

  • managed (being tracked),

  • detached (no longer tracked),

  • removed (marked for deletion),

  • new (not yet persisted).


🛠 Example with Doctrine (PHP):

$user = new User();
$user->setName('Max Mustermann');

$entityManager->persist($user); // Mark for saving
$entityManager->flush();        // Write to DB

✅ Summary:

The Entity Manager is the central component for working with database objects — creating, reading, updating, deleting. It abstracts SQL and provides a clean, object-oriented way to interact with your data layer.


Join Point

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.


Aspect Oriented Programming - AOP

Aspect-Oriented Programming (AOP) is a programming paradigm focused on modularizing cross-cutting concerns—aspects of a program that affect multiple parts of the codebase and don't fit neatly into object-oriented or functional structures.


💡 Goal:

Typical cross-cutting concerns include logging, security checks, error handling, transaction management, or performance monitoring. These concerns often appear in many classes and methods. AOP allows you to write such logic once and have it automatically applied where needed.


🔧 Key Concepts:

  • Aspect: A module that encapsulates a cross-cutting concern.

  • Advice: The actual code to be executed (e.g., before, after, or around a method call).

  • Join Point: A point in the program flow where an aspect can be applied (e.g., method execution).

  • Pointcut: A rule that defines which join points are affected (e.g., "all methods in class X").

  • Weaving: The process of combining aspects with the main program code—at compile-time, load-time, or runtime.


🛠 Example (Java with Spring AOP):

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

This code automatically logs a message before any method in the com.example.service package is executed.


✅ Benefits:

  • Improved modularity

  • Reduced code duplication

  • Clear separation of business logic and system-level concerns


❌ Drawbacks:

  • Can reduce readability (the flow isn't always obvious)

  • Debugging can become more complex

  • Often depends on specific frameworks (e.g., Spring, AspectJ)


Assertion

Assertions are programming constructs used to check assumptions about the state of a program. An assertion tests whether a specific condition is true—if it isn't, an error is typically raised and the program stops.

x = 10
assert x > 0   # passes
assert x < 5   # raises AssertionError, since x is not less than 5

Purpose of Assertions:

  • They help with debugging: you can verify that certain conditions in code hold true during development.

  • They document implicit assumptions, e.g., “At this point, the list must have at least one item.”

  • They are mainly used during development—assertions are often disabled in production code.

Key Difference from Regular Error Handling:

Assertions are meant to catch programmer errors, not user input or external failures. For example:

  • assert age > 0 → inappropriate if age comes from user input.

  • Instead, use: if age <= 0: raise ValueError("Age must be positive.")