The Levenshtein distance is a measure of the difference between two strings. It indicates how many single-character operations are needed to transform one string into the other. The allowed operations are:

1. Insertion of a character

2. Deletion of a character

3. Substitution of one character with another

Example:

The Levenshtein distance between "house" and "mouse" is 1, since only one letter (h → m) needs to be changed.

Applications:

Levenshtein distance is used in many areas, such as:

• Spell checking (suggesting similar words)

• DNA sequence comparison

• Plagiarism detection

• Fuzzy searching in databases or search engines

Formula (recursive, simplified):

For two strings a and b of lengths i and j:

lev(a, b) = min(
  lev(a-1, b) + 1,        // deletion
  lev(a, b-1) + 1,        // insertion
  lev(a-1, b-1) + cost    // substitution (cost = 0 if characters are equal; else 1)
)

There are also more efficient dynamic programming algorithms to compute it.

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

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)!")
}

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.

An INNER JOIN is a term used in SQL (Structured Query Language) to combine rows from two (or more) tables based on a related column between them.

Example:

You have two tables:

Table: Customers

Table: Orders

Now you want to know which customers have placed orders. You only want the customers who exist in both tables.

SQL with INNER JOIN:

SELECT Customers.Name, Orders.Product
FROM Customers
INNER JOIN Orders ON Customers.CustomerID = Orders.CustomerID;

Result:

Explanation:

• Clara didn’t place any orders → not included.

• The order with CustomerID 4 doesn’t match any customer → also excluded.

In short:

An INNER JOIN returns only the rows with matching values in both tables.

An explicit join is a clear and direct way to define a join in an SQL query, where the type of join (such as INNER JOIN, LEFT JOIN, RIGHT JOIN, or FULL OUTER JOIN) is explicitly stated.

Example of an explicit join:

SELECT *
FROM customers
INNER JOIN orders
ON customers.customer_id = orders.customer_id;

This makes it clear:

• Which tables are being joined (customers, orders)

• What kind of join is used (INNER JOIN)

• What the join condition is (ON customers.customer_id = orders.customer_id)

In contrast: Implicit join

An implicit join is the older style, using a comma in the FROM clause, and putting the join condition in the WHERE clause:

SELECT *
FROM customers, orders
WHERE customers.customer_id = orders.customer_id;

This works the same, but it's less clear and not ideal for complex queries.

Benefits of explicit joins:

• More readable and structured, especially with multiple tables

• Clear separation of join conditions (ON) and filter conditions (WHERE)

• Recommended in modern SQL development

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

An implicit join is a way of joining tables in SQL without using the JOIN keyword explicitly. Instead, the join is expressed using the WHERE clause.

Example of an implicit join:

SELECT *
FROM customers, orders
WHERE customers.customer_id = orders.customer_id;

In this example, the tables customers and orders are joined using a condition in the WHERE clause.

In contrast, an explicit join looks like this:

SELECT *
FROM customers
JOIN orders ON customers.customer_id = orders.customer_id;

Differences:

When is an implicit join used?

It was common in older SQL code, but explicit joins are recommended today, as they are clearer, easier to maintain, and less error-prone, especially in complex queries involving multiple tables.