Model

/ˈfaɪnɪt steɪt məˌʃiːn/

noun … “Model of computation with a limited number of states.”

Finite-State Machine (FSM) is an abstract computational model used to design sequential circuits or software systems. It consists of a finite set of states, a set of inputs that trigger transitions between states, and a set of outputs determined by its current state (and sometimes input). FSMs are widely used for modeling control logic, communication protocols, parsers, and embedded systems.

Key characteristics of Finite-State Machine include:

• Finite number of states: the system can only be in one state at a time.
• State transitions: movement between states triggered by input events.
• Deterministic or nondeterministic: deterministic FSMs have exactly one next state per input, while nondeterministic FSMs can have multiple possibilities.
• Outputs: determined either solely by state (Moore machine) or by state and input (Mealy machine).
• Applications: control systems, protocol design, sequence detection, UI navigation, and parser design.

Workflow example: Simple traffic light controller:

states = ["Green", "Yellow", "Red"]
current_state = "Green"

def transition(input_event):
    if current_state == "Green" && input_event == "timer":
        return "Yellow"
    elif current_state == "Yellow" && input_event == "timer":
        return "Red"
    elif current_state == "Red" && input_event == "timer":
        return "Green"
    return current_state

current_state = transition("timer")

Here, the traffic light cycles through a fixed set of states based on input events, illustrating a deterministic FSM.

Conceptually, a Finite-State Machine is like a board game with defined spaces: the player moves from one state to another according to the rules triggered by dice rolls or cards.

See Sequential Circuit, Flip-Flop, Digital, Control Logic, State Transition.

/dɪˈzaɪn ˈpætərnz/

noun … “Proven templates for solving common software problems.”

Design Patterns are reusable solutions to recurring problems in software architecture and object-oriented design. They provide templates for structuring code to improve maintainability, scalability, and readability, without prescribing exact implementations. Patterns encapsulate best practices and lessons learned from experienced developers, allowing teams to communicate ideas efficiently using standardized terminology.

Key characteristics of Design Patterns include:

• Reusability: patterns can be adapted across projects and languages while preserving their core intent.
• Abstraction: they provide high-level templates rather than concrete code.
• Communication: developers share complex solutions quickly by naming patterns, e.g., Singleton, Observer, or Factory.
• Scalability: patterns often facilitate extensible and modular designs, enabling easier adaptation to changing requirements.

Categories of Design Patterns commonly used in OOP include:

• Creational: manage object creation, e.g., Singleton, Factory, Builder.
• Structural: organize relationships between objects, e.g., Adapter, Composite, Decorator.
• Behavioral: define interactions and responsibilities, e.g., Observer, Strategy, Command.

Workflow example: A developer implementing a notification system can use the Observer pattern. The Subject maintains a list of subscribers (observers). When an event occurs, the subject notifies all observers, decoupling event generation from response handling. This approach allows adding new notification channels without modifying existing logic.

trait Observer {
  def update(message: String): Unit
}

class ConcreteObserver(name: String) extends Observer {
  def update(message: String): Unit =>
    println(name + " received " + message)
}

class Subject {
  private var observers: List[Observer] = List()
  def addObserver(o: Observer) => observers = observers :+ o
  def notifyObservers(msg: String) => observers.foreach(_.update(msg))
}

val subject = new Subject
val obs1 = new ConcreteObserver("Observer1")
val obs2 = new ConcreteObserver("Observer2")
subject.addObserver(obs1)
subject.addObserver(obs2)
subject.notifyObservers("Update available")

Conceptually, Design Patterns are like pre-made blueprints for a building: they guide construction, reduce errors, and ensure that multiple builders can understand and modify the structure consistently. Patterns give a shared vocabulary and strategy for solving recurring problems without reinventing solutions.

See OOP, Scala, Java, Actor Model.

/ˈæktər ˈmɑːdəl/

noun … “Concurrency through isolated, communicating actors.”

Actor Model is a conceptual model for designing concurrent and distributed systems in which independent computational entities, called actors, communicate exclusively through asynchronous message passing. Each actor encapsulates its own state and behavior, processes incoming messages sequentially, and can create new actors, send messages, or modify its internal state. This model eliminates shared mutable state, reducing the complexity and risks of traditional multithreaded Concurrency.

Key characteristics of the Actor Model include:

• Isolation: actors do not share memory, preventing race conditions and synchronization issues.
• Asynchronous messaging: actors interact via message queues, allowing non-blocking communication.
• Scalability: the model naturally supports distributed and parallel computation across multiple CPUs or nodes.
• Dynamic behavior: actors can change behavior at runtime and spawn other actors to handle tasks concurrently.

Workflow example: In a system built with Scala and the Akka framework, actors can perform internal computations without network operations, demonstrating the principles of isolation and asynchronous messaging safely on the same host.

import akka.actor._

class CounterActor extends Actor {
  var count = 0
  def receive = {
    case "increment" => count += 1
    case "get" => sender() ! count
  }
}

val system = ActorSystem("LocalSystem")
val counter = system.actorOf(Props[CounterActor], "counter")
counter ! "increment"
counter ! "increment"
counter ! "get"

Conceptually, the Actor Model is like a network of isolated mailboxes. Each mailbox (actor) processes incoming letters (messages) in order, decides actions independently, and can send new letters to other mailboxes. This structure allows the system to scale and respond efficiently without conflicts from shared resources.

See Concurrency, Scala, Threading, Akka.

/ˈfʌŋkʃənl ˈproʊɡræmɪŋ/

noun … “Writing code as evaluations of pure functions.”

Functional Programming is a programming paradigm where computation is expressed through the evaluation of functions, emphasizing immutability, first-class functions, and declarative code. Unlike OOP, which centers on objects and state, Functional Programming avoids shared mutable state and side effects, making reasoning about code, testing, and concurrency more predictable and robust.

Key characteristics of Functional Programming include:

• Pure functions: Functions that always produce the same output given the same input and have no side effects.
• Immutability: Data structures are not modified; operations produce new versions instead of altering originals.
• First-class and higher-order functions: Functions can be passed as arguments, returned from other functions, and stored in variables.
• Declarative style: Focus on what to compute rather than how to compute it, often using recursion or functional combinators instead of loops.
• Composability: Small functions can be combined to form complex operations, enhancing modularity and reuse.

Workflow example: In Scala or Haskell, a developer may process a list of numbers by mapping a pure function to transform each element and then filtering results based on a predicate, without mutating the original list. This approach allows parallel execution and easier debugging since functions do not rely on external state.

val numbers = List(1, 2, 3, 4, 5)
val squaredEven = numbers.map(n => n * n).filter(_ % 2 == 0)
println(squaredEven) // Output: List(4, 16)

Conceptually, Functional Programming is like a series of conveyor belts in a factory. Each function is a station that transforms items without altering the original input. The final product emerges predictably, and individual stations can be modified or optimized independently without disrupting the overall flow.

See Scala, Haskell, OOP, Immutability, Higher-Order Function.

/ˌoʊˌoʊˈpiː/

noun … “Organizing code around objects and their interactions.”

OOP, short for Object-Oriented Programming, is a programming paradigm that structures software design around objects, which encapsulate data (attributes) and behavior (methods). Each object represents a real-world or conceptual entity and interacts with other objects through well-defined interfaces. OOP emphasizes modularity, code reuse, and abstraction, making complex systems easier to design, maintain, and extend.

Key principles of OOP include:

• Encapsulation: Bundling data and methods together, controlling access to an object’s internal state.
• Inheritance: Creating new classes based on existing ones to reuse or extend behavior.
• Polymorphism: Allowing objects of different classes to be treated uniformly via shared interfaces or method overrides.
• Abstraction: Hiding complex implementation details behind simple interfaces.

In practice, OOP is used in languages such as Java, Scala, and C++. A developer might define a base class Vehicle with methods like start() and stop(), then create subclasses Car and Bike that inherit and customize behavior. This allows polymorphic handling, such as processing a list of Vehicle objects without knowing each specific type in advance.

class Vehicle:
    def start(self):
        print("Starting vehicle")

class Car(Vehicle):
    def start(self):
        print("Starting car")

vehicles = [Vehicle(), Car()]
for v in vehicles:
    v.start()

This outputs:

Starting vehicle
Starting car

Conceptually, OOP is like a workshop of interchangeable machines. Each machine (object) performs its own tasks, but all adhere to standardized controls (interfaces). This modular design allows new machines to be added or replaced without disrupting the overall workflow.

See Scala, Java, Design Patterns, Functional Programming.

/bɜːrt/

n. "Test instrument measuring bit error ratios in high-speed serial links using known PRBS patterns."

BERT, short for Bit Error Rate Tester, comprises pattern generator and error detector validating digital communication systems by transmitting known sequences through DUT (Device Under Test) and comparing received bits against expected, quantifying performance as BER = errors/total_bits (target 1e-12 for SerDes). Essential for characterizing CTLE, DFE, and CDR under stressed PRBS-31 patterns with added sinusoidal jitter/SJ.

Key characteristics of BERT include: Pattern Generator produces PRBS7/15/23/31 via LFSR or user-defined CDR-lock patterns; Error Counter accumulates bit mismatches over test time (hours for 1e-15 BER); Jitter Injection adds TJ/SJ/RJ stressing receiver tolerance; Loopback Mode single-unit testing via DUT TX→RX shorting; Bathtub Analysis sweeps voltage/jitter revealing BER contours.

Conceptual example of BERT usage:

# BERT automation script (Keysight M8040A API example)
import pyvisa

rm = pyvisa.ResourceManager()
bert = rm.open_resource('TCPIP::BERT_IP::inst0::INSTR')

# Configure PRBS-31 + 0.5UI SJ @ 20% depth
bert.write(':PAT:TYPE PRBS31')
bert.write(':JITT:TYPE SINU; FREQ 2e9; AMPL 0.1')  # 2GHz SJ, 0.1UI

# Run 1e12 bit test targeting 1e-12 BER
bert.write(':TEST:START')
bert.write(':TEST:BITS 1e12')
bert.query(':TEST:BER?')  # Returns '1.23e-13'

# Bathtub sweep: Vth vs RJ
bert.write(':SWEEp:VTH 0.4,0.8,16')  # 16 voltage steps
bert.write(':SWEEp:RUN')
bathtub_data = bert.query(':TRACe:DATA?')  # BER contours

Conceptually, BERT functions as truth arbiter for USB4/DisplayPort PHYs—injects PRBS through stressed channel, counts symbol errors post-CTLE/DFE while plotting Q-factor bathtub curves. Keysight M8040A/MSO70000 validates 224G Ethernet hitting 1e-6 BER pre-FEC, correlating eye height to LFSR error floors; single-unit loopback mode transforms FPGA SerDes into self-tester, indispensable for PCIe5 compliance unlike protocol analyzers measuring logical errors.

/lʊk-ɛm-ɛl/

n. “The language that teaches Looker how to see your data.”

LookML is a modeling language used in Looker to define relationships, metrics, and data transformations within a data warehouse. It allows analysts and developers to create reusable, structured definitions of datasets so that business users can explore data safely and consistently without writing raw SQL queries.

Unlike traditional SQL, LookML is declarative rather than procedural. You describe the structure and relationships of your data — tables, joins, dimensions, measures, and derived fields — and Looker generates the necessary queries behind the scenes. This separation ensures consistency, reduces duplication, and enforces business logic centrally.

Key concepts in LookML include:

• Views: Define a single table or dataset and its fields (dimensions and measures).
• Explores: Configure how users navigate and join data from multiple views.
• Dimensions: Attributes or columns users can query, such as “customer_name” or “order_date.”
• Measures: Aggregations like COUNT, SUM, or AVG, defined once and reused throughout analyses.

Here’s a simple LookML snippet defining a view with a measure and a dimension:

view: users {
  sql_table_name: public.users ;;

dimension: username {
sql: ${TABLE}.username ;;
}

measure: total_users {
type: count
sql: ${TABLE}.id ;;
}
}

In this example, the view users represents the database table public.users. It defines a dimension called username and a measure called total_users, which counts the number of user records. Analysts can now explore and visualize these fields without writing SQL manually.

LookML promotes centralized governance, reducing errors and inconsistencies in reporting. By abstracting SQL into reusable models, organizations can ensure that all users are working with the same definitions of metrics and dimensions, which is critical for reliable business intelligence.

In essence, LookML is a bridge between raw data and meaningful insights — it teaches Looker how to understand, organize, and present data so teams can focus on analysis rather than query mechanics.

/ˌeɪˈaɪ/

n. “Machines pretending to think… sometimes convincingly.”

AI, short for Artificial Intelligence, is a broad field of computer science focused on building systems that perform tasks normally associated with human intelligence. These tasks include learning from experience, recognizing patterns, understanding language, making decisions, and adapting to new information. Despite the name, AI is not artificial consciousness, artificial emotion, or artificial intent. It is artificial behavior — behavior that appears intelligent when observed from the outside.

At its core, AI is about models. A model is a mathematical structure that maps inputs to outputs. The model does not “understand” in the human sense. It calculates. What makes AI interesting is that these calculations can approximate reasoning, perception, and prediction well enough to be useful — and occasionally unsettling.

Modern AI is dominated by machine learning, a subfield where systems improve performance by analyzing data rather than following rigid, hand-written rules. Instead of telling a program exactly how to recognize a face or translate a sentence, engineers feed it large datasets and let the model infer patterns statistically. Learning, in this context, means adjusting parameters to reduce error, not gaining insight or awareness.

Within machine learning sits deep learning, which uses multi-layered neural networks inspired loosely by biological neurons. These networks excel at handling unstructured data such as images, audio, and natural language. The “deep” part refers to the number of layers, not depth of thought. A deep model can be powerful and still profoundly wrong.

AI systems are often categorized by capability. Narrow AI performs a specific task — recommending videos, detecting fraud, generating text, or playing chess. This is the only kind of AI that exists today. General AI, a hypothetical system capable of understanding and learning any intellectual task a human can, remains speculative. It is a concept, not a product.

In practical systems, AI is embedded everywhere. Search engines rank results using learned relevance signals. Voice assistants convert sound waves into meaning. Recommendation engines predict what you might want next. Security tools flag anomalies. These systems rely on pipelines involving data collection, preprocessing, training, evaluation, and deployment — often supported by ETL processes and cloud infrastructure such as Cloud Storage.

A critical property of AI is probabilistic behavior. Outputs are based on likelihoods, not certainties. This makes AI flexible but also brittle. Small changes in input data can produce surprising results. Bias in training data can become bias in decisions. Confidence scores can be mistaken for truth.

Another defining feature is opacity. Many advanced AI models function as black boxes. They produce answers without easily explainable reasoning paths. This creates tension between performance and interpretability, especially in high-stakes domains like medicine, finance, and law.

It is important to separate AI from myth. AI does not “want.” It does not “believe.” It does not possess intent, values, or self-preservation. Any appearance of personality or agency is a projection layered on top by interface design or human psychology. The system executes optimization objectives defined by humans, sometimes poorly.

Used well, AI amplifies human capability. It accelerates analysis, reduces repetitive labor, and uncovers patterns too large or subtle for manual inspection. Used carelessly, it automates mistakes, scales bias, and obscures accountability behind math.

AI is not magic. It is applied statistics, software engineering, and compute power arranged cleverly. Its power lies not in thinking like a human, but in doing certain things humans cannot do fast enough, consistently enough, or at sufficient scale.

In the end, AI is best understood not as an artificial mind, but as a mirror — reflecting the data, goals, and assumptions we feed into it, sometimes with uncomfortable clarity.