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)

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

A daemon (pronounced like "day-mon", not like the English word "demon") is a background process that runs on a computer system—typically without direct user interaction.

Key characteristics of a daemon:

• Starts automatically during system boot.

• Runs continuously in the background.

• Performs tasks without user input.

• Listens for requests from other programs or network connections.

Examples:

• cron daemon: Executes scheduled tasks (e.g., daily backups).

• sshd: Handles incoming SSH connections.

• httpd or nginx: Web server daemons.

• cupsd: Manages print jobs.

Technical background:

• On Unix/Linux systems, daemon process names often end in "d" (e.g., httpd, systemd).

• Daemons are typically launched at system startup by init systems like systemd or init.

Origin of the term:

The word comes from Greek mythology, where a “daimon” was a guiding spirit or invisible force—aptly describing software that works quietly behind the scenes.

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.

In software development, a guard (also known as a guard clause or guard statement) is a protective condition used at the beginning of a function or method to ensure that certain criteria are met before continuing execution.

In simple terms:

A guard is like a bouncer at a club—it only lets valid input or states through and exits early if something is off.

Typical example (in Python):

def divide(a, b):
    if b == 0:
        return "Division by zero is not allowed"  # Guard clause
    return a / b

This guard prevents the function from attempting to divide by zero.

Benefits of guard clauses:

• Early exit on invalid conditions

• Improved readability by avoiding deeply nested if-else structures

• Cleaner code flow, as the "happy path" (normal execution) isn’t cluttered by edge cases

Examples in other languages:

JavaScript:

function login(user) {
  if (!user) return; // Guard clause
  // Continue with login logic
}

Swift (even has a dedicated guard keyword):

func greet(person: String?) {
  guard let name = person else {
    print("No name provided")
    return
  }
  print("Hello, \(name)!")
}

An Early Exit is a programming technique where a function or algorithm terminates early when a specific condition is met. The goal is usually to make the code more efficient and easier to read.

Example in a function:

function getDiscount($age) {
    if ($age < 18) {
        return 10; // 10% discount for minors
    }
    if ($age > 65) {
        return 15; // 15% discount for seniors
    }
    return 0; // No discount for other age groups
}

Here, the Early Exit ensures that the function immediately returns a value as soon as a condition is met. This avoids unnecessary else blocks and makes the code more readable.

Comparison with a nested version:

function getDiscount($age) {
    $discount = 0;
    if ($age < 18) {
        $discount = 10;
    } else {
        if ($age > 65) {
            $discount = 15;
        }
    }
    return $discount;
}

This version introduces unnecessary nesting, reducing readability.

Other Use Cases:

• Input validation at the start of a function (return or throw for invalid input)

• Breaking out of loops early when the desired result is found (break or return)

An Early Exit improves readability, maintainability, and performance in code.

A Single Page Application (SPA) is a web application that runs entirely within a single HTML page. Instead of reloading the entire page for each interaction, it dynamically updates the content using JavaScript, providing a smooth, app-like user experience.

Key Features of an SPA:

• Dynamic Content Loading: New content is fetched via AJAX or the Fetch API without a full page reload.
• Client-Side Routing: Navigation is handled by JavaScript (e.g., React Router or Vue Router).
• State Management: SPAs often use libraries like Redux, Vuex, or Zustand to manage application state.
• Separation of Frontend & Backend: The backend typically serves as an API (e.g., REST or GraphQL).

Advantages:

✅ Faster interactions after the initial load
✅ Improved user experience (no full page reloads)
✅ Offline functionality possible via Service Workers

Disadvantages:

❌ Initial load time can be slow (large JavaScript bundle)
❌ SEO challenges (since content is often loaded dynamically)
❌ More complex implementation, especially for security and routing

Popular frameworks for SPAs include React, Angular, and Vue.js.

CSS Media Queries are a technique in CSS that allows a webpage layout to adapt to different screen sizes, resolutions, and device types. They are a core feature of Responsive Web Design.

Syntax:

@media (condition) {
    /* CSS rules that apply only under this condition */
}

Examples:

1. Adjusting for different screen widths:

/* For screens with a maximum width of 600px (e.g., smartphones) */
@media (max-width: 600px) {
    body {
        background-color: lightblue;
    }
}

2. Detecting landscape vs. portrait orientation:

@media (orientation: landscape) {
    body {
        background-color: lightgreen;
    }
}

3. Styling for print output:

@media print {
    body {
        font-size: 12pt;
        color: black;
        background: none;
    }
}

Common Use Cases:

✅ Mobile-first design: Optimizing websites for small screens first and then expanding for larger screens.
✅ Dark mode: Adjusting styles based on user preference (prefers-color-scheme).
✅ Retina displays: Using high-resolution images or specific styles for high pixel density screens (min-resolution: 2dppx).

What is Responsive Design?

Responsive Design is a web design approach that allows a website to automatically adjust to different screen sizes and devices. This ensures a seamless user experience across desktops, tablets, and smartphones without needing separate versions of the site.

How Does Responsive Design Work?

Responsive Design is achieved using the following techniques:

1. Flexible Layouts

• Websites use percentage-based widths instead of fixed pixel values so that elements adjust dynamically.

2. Media Queries (CSS)

• CSS Media Queries adapt the layout based on screen size. Example:

@media (max-width: 768px) {
    body {
        background-color: lightgray;
    }
}

• → This changes the background color for screens smaller than 768px.

• 3. Flexible Images and Media

  • Images and videos automatically resize with:

img {
    max-width: 100%;
    height: auto;
}

4. Mobile-First Approach

• The design starts with small screens first and then scales up for larger displays.

Benefits of Responsive Design

✅ Better user experience across all devices
✅ SEO advantages, as Google prioritizes mobile-friendly sites
✅ No need for separate mobile and desktop versions, reducing maintenance
✅ Higher conversion rates, since users can navigate the site easily

Conclusion

Responsive Design is now the standard in modern web development, ensuring optimal display and usability on all devices.

A Bearer Token is a type of access token used for authentication and authorization in web applications and APIs. The term "Bearer" means "holder," which implies that anyone in possession of the token can access protected resources—without additional verification.

Characteristics of a Bearer Token:

• Self-contained: It includes all necessary authentication information.
• No additional identity check: Whoever holds the token can use it.
• Sent in HTTP headers: Typically as Authorization: Bearer <token>.
• Often time-limited: Tokens have expiration times to reduce misuse.
• Commonly used with OAuth 2.0: For example, when authenticating with third-party services.

Example of an HTTP request with a Bearer Token:

GET /protected-data HTTP/1.1
Host: api.example.com
Authorization: Bearer abcdef123456

Risks:

• No protection if stolen: If someone intercepts the token, they can impersonate the user.
• Must be securely stored: Should not be exposed in client-side code or URLs.

💡 Tip: To enhance security, use short-lived tokens and transmit them only over HTTPS.