PKCE (pronounced "pixy")

RFC 7636: Proof Key for Code Exchange

www.rfc-editor.org/rfc/rfc7636

PKCE (RFC 7636) is an extension to the Authorization Code flow to prevent CSRF (cross-site request forgery) and authorization code injection attacks.

PKCE was originally designed to protect the authorization code flow in mobile apps, but its ability to prevent authorization code injection makes it useful for every type of OAuth client, even web apps that use client authentication.

source: https://oauth.net/2/pkce/

AI Overview

How It Works

PKCE replaces the need for a client secret with a cryptographic proof process:

1. Create the Verifier: The client app generates a cryptographically random, high-entropy string called the Code Verifier.
2. Create the Challenge: The app hashes this string (typically using SHA-256) to create the Code Challenge.
3. Send the Challenge: The app sends the Code Challenge to the authorization server alongside the initial login request.
4. Exchange and Verify: When the authorization server returns the authorization code, the app sends the code plus the original unhashed Code Verifier back to the server. The server hashes the provided verifier and confirms it matches the original challenge before issuing an access token.

poka-yoke, forcing function

Poka-yoke is a Japanese term that means "mistake-proofing" or "error prevention", and is also sometimes referred to as a forcing function or a behavior-shaping constraint.

Defects occur when the human mistakes are allowed to reach the customer. The aim of poka-yoke is to design the process so that mistakes can be detected and corrected immediately, eliminating defects at the source.

Poka-yoke was originally baka-yoke, which means "fool-proofing" (or "idiot-proofing").

source: https://en.wikipedia.org/wiki/Poka-yoke

Forcing functions are a super way to help make things foolproof, or better, errorproof — as all of us make mistakes with designed things without being fools. You may have used your own forcing function when, in an attempt to make sure you remember your passport or tickets before a flight, you put them directly in front of the door so you couldn’t open it without noticing them.

source: https://sketchplanations.com/forcing-function

RAG pipeline

A Retrieval-Augmented Generation (RAG) pipeline enhances Large Language Model (LLM) outputs by fetching relevant data from external sources, reducing hallucinations and improving accuracy. It involves indexing documents into a vector database, retrieving relevant chunks based on user queries, and augmenting the prompt with this context to generate grounded responses.

How a RAG Pipeline Works

The RAG pipeline operates through two main phases: ingestion (preparing knowledge) and retrieval (generating answers). 

1. Data Ingestion & Indexing: Documents (PDFs, websites, databases) are loaded, split into smaller chunks, converted into numerical embeddings via an AI model, and stored in a vector database.
2. Retrieval & Generation: A user query is converted into a vector and matched against the vector database to find the most relevant chunks. These chunks, along with the original question, are fed to the LLM to generate a precise answer. 

cit.: YouTube

Benefits of RAG Pipelines

• Reduced Hallucinations: Grounding answers in provided documents ensures higher factual accuracy.
• Up-to-Date Information: Enables models to access, for example, the latest internal documents without retraining.
• Data Privacy: Allows querying private or proprietary data sources securely. 

cit.: NVIDIA Developer

How to Build a RAG Pipeline

Building a RAG pipeline typically involves these steps:

1. Load Data: Use loaders for files, websites, or databases.
2. Chunking: Divide data into smaller, manageable text sections.
3. Embeddings & Storage: Use embedding models to vectorize text and store them in a vector store like Pinecone, ChromaDB, or Weaviate.
4. Retrieval Engine: Build a mechanism to perform semantic searches for relevant info.
5. LLM Generation: Send retrieved content to a model (like GPT-4) to generate the answer.
6. Frameworks: Utilize frameworks like LangChain or LlamaIndex to connect these components. 

cit.: YouTube

source: AI summary

reference: https://developer.nvidia.com/blog/rag-101-demystifying-retrieval-augmented-generation-pipelines/

Semantic Kernel

Semantic Kernel is a lightweight, open-source development kit that lets you easily build AI agents and integrate the latest AI models into your C#, Python, or Java codebase. It serves as an efficient middleware that enables rapid delivery of enterprise-grade solutions, backed with security enhancing capabilities like telemetry support.

Semantic Kernel combines prompts with existing APIs to perform actions. By describing your existing code to AI models, they’ll be called to address requests. When a request is made the model calls a function, and Semantic Kernel is the middleware translating the model's request to a function call and passes the results back to the model.

source: https://learn.microsoft.com/en-us/semantic-kernel/overview/

LDAP

LDAP, the Lightweight Directory Access Protocol, is a mechanism for interacting with directory servers. It’s often used for authentication and storing information about users, groups, and applications.

source: https://ldap.com/

The Lightweight Directory Access Protocol (LDAP) is a directory service protocol that runs on a layer above the TCP/IP stack. It provides a mechanism used to connect to, search, and modify Internet directories. The LDAP directory service is based on a client-server model. The function of LDAP is to enable access to an existing directory.

source: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ldap/lightweight-directory-access-protocol-ldap-api

SLI, SLO, SLA (service level indicator/objective/agreement)

Key Definitions & Differences

• SLI (Service Level Indicator): The actual measurement of a service's behavior, such as uptime or request success rate.
• SLO (Service Level Objective): A target value for the reliability of a service, defined by the SLI. These are usually internal goals.
• SLA (Service Level Agreement): A contract between a provider and customer that outlines expected service levels and consequences (like service credits) if targets are missed.

Practical Example

• SLI: The current success rate of user logins is 99.98%
• SLO: The goal is 99.95% success rate per month.
• SLA: If success falls below 99.90%, the company owes customers a refund. 

Key Takeaways

• SLOs should be stricter than SLAs to provide a buffer for error.
• SLIs (indicators) are used to measure SLOs (objectives).
• SLAs are typically legally binding and external, while SLOs are internal targets. 

Reference: https://www.atlassian.com/incident-management/kpis/sla-vs-slo-vs-sli

takt time

Takt time is a calculation of the available production time divided by customer demand.

For example, if a widget factory operates 480 minutes per day and customers demand 240 widgets per day, takt time is two minutes. Similarly, if customers want two new products per month, takt time is two weeks. The purpose is to precisely match production with demand.

Takt is German for a precise interval of time such as a musical meter.

source: https://www.lean.org/lexicon-terms/takt-time/

Gherkin Syntax

Gherkin Syntax: Structured format (Given/When/Then) for defining behavior.

Gherkin is a plain-text language with a simple structure. It is designed to be easy to learn by non-programmers, yet structured enough to allow concise description of test scenarios and examples to illustrate business rules in most real-world domains.

Here is a sample Gherkin document:

Feature: Account Holder withdraws cash

Scenario: Account has sufficient funds

    Given The account balance is $100

      And the card is valid

      And the machine contains enough money

     When the Account Holder requests $20

     Then the ATM should dispense $20

      And the account balance should be $80

      And the card should be returned

source: https://support.smartbear.com/cucumberstudio/docs/bdd/write-gherkin-scenarios.html

Reference: https://cucumber.io/docs/gherkin/reference/

ROAM (risk management)

ROAM

ROAM is a risk management framework used primarily in Agile and Scaled Agile Framework (SAFe) to categorize risks during PI planning.

Resolved

The risk has been addressed and is no longer a concern.

Owned

A person has taken responsibility for addressing the risk/concern.

Accepted

The risk is considered absorbable if the situation occurs.

Mitigated

Action has been taken that lessens the probability of the event happening or the consequence if it happens has been reduced to acceptable limits.

Sayre's Law

Sayre's law is an adage stating that "in any dispute the intensity of feeling is inversely proportional to the value of the stakes at issue." The principle underscores how conflicts over minor matters often generate outsized animosity due to the absence of significant material consequences.

Sayre, a professor of political science at Columbia University from 1952 until his death, drew from his experiences in university administration and faculty governance, where competition for prestige and minor perquisites often eclipsed substantive policy differences. The law underscores a pattern wherein low tangible risks permit unchecked escalation of ideological or interpersonal conflicts, unmitigated by external accountability or significant loss.

source: https://grokipedia.com/page/Sayre's_law

See also TWOTW: Bikeshedding