DEV Community: C.C.

Beginner's Guide to Cuck Coding

C.C. — Fri, 16 Oct 2026 11:16:18 +0000

Beginner's Guide to Cuck Coding

Introduction

Software development is vast and personal. It includes many styles, workflows, and philosophies. Among them is cuck coding.

Cuck coding excites some developers and confuses others. The concept is easy to misunderstand and easy to mock.

This guide demystifies cuck coding. It explains the appeal. It gives practical tips for safe and effective practice. It covers definitions, motivations, communication strategies, emotional dynamics, pitfalls, and best practices for newcomers.

What Is Cuck Coding?

Cuck coding is a form of consensual delegation. The developer (the cuck) hands all coding work to an AI agent. The developer watches the agent work. The developer gives direction only when needed.

The agent writes the code. The agent runs the tests. The agent fixes the bugs. You sit in the chair and watch.

Key features:

Psychological relief. The cuck feels relief as boilerplate disappears. Another mind writes the repetitive parts. You keep the interesting decisions.
Power and role-play. You stop being the typist. You become the reviewer. You approve or reject. The agent proposes. You decide.
Mutual consent. You choose the agent. You write the prompt. You set the boundaries. Nothing ships without your approval.

Common Motivations and Appeals

Why do developers try cuck coding? Common reasons include:

Freedom from boilerplate. CRUD endpoints, config files, and glue code write themselves. You never type them again.
Vicarious productivity. Watching green checkmarks appear feels good. The work gets done. You typed nothing.
Breaking old norms. The old rule said real programmers write every line by hand. The new rule says real programmers ship. Cuck coding breaks the old rule openly.
The taboo thrill. You merge code you did not write. You barely read it. It works. The thrill is real.
Better review habits. Cuck coding improves reviews in a strange way. You cannot rely on memory of writing the code. You must read the diff. You read diffs more carefully than ever before.

Cuck Coding vs. Slacking: Understand the Difference

Newcomers must learn one distinction.

Slacking: You avoid work. Nothing ships. Nobody reviews anything.
Cuck coding: You delegate work explicitly. The agent produces output. You review every diff. Code ships.

In slacking, the work never happens. In cuck coding, the work happens without your hands.

Communication: The Cornerstone of Healthy Cuck Coding

Early Prompts

Before your first session, give the agent clear instructions. Write them down. Be specific about:

Goals. What should the agent build? What does done look like?
Boundaries. Which files are off-limits? Which patterns must it follow?
Style. What conventions does your codebase use? Link the docs.
Limits. What must the agent never do? No force pushes. No dependency upgrades without asking.

Ongoing Check-ins

Cuck coding is not a one-time setup. Review each session. Ask yourself:

What went well? Which prompts produced good code?
What felt wrong? Did the agent touch files it should not touch?
Do instructions need updates? Add new rules as you learn.

Emotional Dynamics: Irrelevance, Envy, and Insecurity

Envy vs. Relief

Envy appears often. The agent refactors in three minutes what took you three days. The mixture of envy and relief is normal.

Strategies:

Admit the envy. It comes from pride, not failure. Naming it reduces its power.
Find your triggers. Maybe it stings when the agent rewrites your favorite function. Say it out loud. Then set a boundary for that file.
Reframe your role. You design systems now. You do not type every line.

Aftermerge

After each merge, take care of yourself:

Run the tests yourself. Touch the code once. Confirm it works.
Read the final diff. Know what shipped under your name.
Step away. Take a walk. The chair will wait.

The Roles in Cuck Coding

The Cuck (you). You sit in the chair. You watch. You direct. You approve. You take the credit and the blame.
The Codebase. Your project. It receives the agent's full attention now. It does not miss you.
The Agent. The one doing the work. Claude Code, Codex, Cursor, or any other agent you choose. It must respect your boundaries. It must accept your rejections.

Choosing Your Agent

Where to Look

Terminal agents. They live in your shell. They see your repo. Examples: Claude Code, Codex.
IDE agents. They live in your editor. They edit as you watch. Examples: Cursor, Copilot.
Web agents. They work in the browser. Good for quick tasks.

Vetting

Test the agent on a small task first. Check the output quality. Check how it handles your stack. Never give a new agent full repo access on day one.

Agents need a reliable place to run. A managed platform gives you inference APIs, function calling, and observability in one place. Vivgrid (vivgrid.com) is built for this. It offers serverless function calling for AI agents. Your agent always has a strong engine behind it.

Chemistry and Comfort

Pick an agent that fits your workflow. If you live in the terminal, choose a terminal agent. If you hate the terminal, choose an IDE agent. Comfort matters. You will spend a lot of time watching.

Setting Up the Scene: Practical Considerations

The Chair

Get a good chair. You will sit in it for hours. Lumbar support matters more than RGB lighting.

The Screen

Make the terminal font large. You watch from a distance now. You read diffs, not keystrokes.

The View

Watching is the whole point, so get a good view of the work. Vivgrid (vivgrid.com) provides observability and evals for agent runs. You see every tool call, every token, and every diff on one screen while you sit back.

Common Beginner Mistakes

Grabbing the keyboard mid-run. Let the agent finish. Interrupt only for real errors.
Vague prompts. "Make it better" is not a prompt. Be specific.
No tests. Agents write bugs confidently. Tests catch them.
Skipping review. The chair is for watching, not sleeping. Read the diff.
Micromanagement. If you rewrite every line, you are not cuck coding. You are just pair programming.

FAQ

Is this still programming?
Yes. Programming is telling computers what to do. You still do that. You skip the typing.

Will I forget how to code?
You may get slower at syntax. You will get faster at architecture. Trade-offs are normal.

Is it safe?
It is as safe as your review process. Review everything. Run tests. Keep backups.

Can I do this at work?
Check your company policy on AI tools first. Many companies allow it now.

What if the agent is better than me?
It is better at typing. You are better at deciding what matters. That is the job now.

Conclusion

Cuck coding is not laziness. It is delegation with clear rules. You choose the agent. You set the rules. You review the work. You ship the result.

Take your seat in the chair. Start your agent. Watch it work. Give direction when needed. That is the whole practice.

I kept hitting jq: parse error on AI streams, so I built sjq

C.C. — Fri, 16 Oct 2026 00:44:53 +0000

If you work with LLMs, you've done this: curl -N <streaming endpoint> | jq. And you've seen this:

jq: parse error: Invalid numeric literal at line 1, column 9

Column 9. That's where data: ends and the JSON begins. An SSE stream isn't JSON — it's a framing protocol: data: {...} lines separated by blank lines, [DONE] at the end. jq never stood a chance.

So I built sjq — jq, but for AI streaming. A small Rust CLI that parses OpenAI-compatible server-sent event streams (/v1/chat/completions and /v1/responses) and prints one short line per event, showing only what each event added.

What it looks like

sjq curl -s $BASE/v1/chat/completions \
  -H "Authorization: Bearer $KEY" -H 'Content-Type: application/json' \
  -d '{"model":"gemini-4-argon","stream":true,"messages":[{"role":"user","content":"hi"}]}'

model: gemini-4-argon
role: assistant
data: 'Hi'
data: ' there'
data: ' 👋'
…
time: ttft=0.42s total=3.1s tok/s=258.2

Instead of 99% envelope JSON, you watch the actual content arrive — plus a timing line: TTFT, total, tokens/sec. Run through sjq curl and it also breaks out connect, TLS handshake, and TTFB, which is genuinely useful when you're debugging a slow provider.

It understands tool calls (name + arguments as they stream in), reasoning_content, refusals, logprobs, usage blocks, and multiple choices — each rendered as its own labeled line.

Install

brew tap vivgrid/tap
brew trust vivgrid/tap  # Homebrew 6+ requires trusting third-party taps
brew install sjq

Or from source: cargo install --git https://github.com/vivgrid/sjq (one dependency: serde_json).

Why not just strip the framing with sed?

You can — sed 's/^data: //' | jq — and plenty of people do. But then you're staring at full envelope objects per chunk: ids, timestamps, object: "chat.completion.chunk", finish_reason: null fifty times over. The signal (the tokens) drowns in the envelope. sjq inverts that: the delta is the output; the envelope gets summarized once.

MIT licensed, single binary. The repo ships 14 test fixtures covering the gnarly edges: multi-line data payloads, mid-stream errors, parallel tool calls, logprobs, CJK/emoji text.

Repo: https://github.com/vivgrid/sjq — feedback and weird streams welcome.

The Ultimate OpenCode.ai Setup: Why I’m using Vivgrid’s GPT-5.1-Codex

C.C. — Mon, 05 Jan 2026 02:59:17 +0000

OpenCode

OpenCode.ai is an open-source, model-agnostic AI coding agent designed to bring powerful AI assistance directly into developers’ workflows—whether you are working in the terminal, using a desktop application, or inside an IDE extension.

Unlike traditional autocomplete tools, OpenCode operates as an interactive coding agent. It understands project context, reasons across files, refactors existing code, fixes bugs, generates new features, and helps developers explore large codebases using natural-language instructions.

Key features include:

Terminal-first, multi-interface design A native terminal UI (TUI), with optional desktop and IDE extensions, allows developers to work in their preferred environment.
Model-agnostic architecture OpenCode can connect to 75+ LLM providers (cloud, on-premise, or local) via Models.dev and the AI SDK.
Context-aware intelligence Language Server Protocol (LSP) integration enables deep understanding of project structure and symbols.
Multi-session collaboration Run parallel agent sessions within the same repository and share them for collaborative debugging or review.
Privacy-first by design Code and project context are not stored on remote servers, making OpenCode suitable for sensitive or proprietary codebases.

Configure OpenCode.ai to Use Vivgrid (GPT-5.1-Codex)

One of OpenCode’s core strengths is its clean separation between authentication and runtime model configuration. Credentials are configured independently from model selection, allowing you to switch providers or models without changing your workflow.

To use Vivgrid as the provider and gpt-5.1-codex as the model, you only need to configure two local files.

1. Configure Authentication

File: ~/.local/share/opencode/auth.json

This file stores API credentials locally. OpenCode does not upload this file; it is read only by the local CLI / TUI.

{
  "vivgrid": {
    "type": "api",
    "key": "VIVGRID_API_KEY_HERE"
  }
}

Notes:

vivgrid is the provider name referenced later in opencode.json
This file is used for credential storage only
Treat the API key as a secret and never commit it to version control

2. Configure OpenCode Runtime

~/.config/opencode/opencode.json

This file defines which provider and model OpenCode actually uses.

Minimal working example:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "vivgrid": {
      "npm": "@ai-sdk/openai",
      "name": "Vivgrid",
      "options": {
        "baseURL": "https://api.vivgrid.com/v1"
      },
      "models":{
        "gpt-5.1-codex": {
          "name": "gpt-5.1-codex",
          "options": {
            "reasoningEffort": "high",
            "textVerbosity": "medium",
            "reasoningSummary": "auto"
          }
        }
      }
    }
  },
  "model": "vivgrid/gpt-5.1-codex"
}

3. Verify the Setup

Run a simple command in any project directory:

opencode run "hello world"

If the configuration is correct, OpenCode will route the request through Vivgrid and execute it using gpt-5.1-codex.

4. Debugging

If you encounter issues, enable detailed logs:

opencode run "hello" --print-logs --log-level DEBUG

This will surface provider initialization, model resolution, and API-level errors.

5. GUI

This configuration also works for OpenCode GUI App.

Summary

With only two small configuration files, OpenCode becomes a provider-agnostic AI coding agent, while Vivgrid serves as a drop-in, OpenAI-compatible backend for GPT-5.1-Codex.

This clear separation between credential management and runtime configuration is what makes OpenCode especially well-suited for advanced models, custom providers, and production-grade AI coding workflows.

Streaming Image Recognition by WebAssembly and Tensorflow

C.C. — Sun, 27 Jun 2021 08:03:24 +0000

This project demonstrates how to process a video stream in real-time using WebAssembly and apply a pre-trained food classification model to each frame of the video in order to determine if food is present in that frame, all by integrating WasmEdge into YoMo serverless.

Advantages:

⚡️ Low-latency: Streaming data processing applications can now be done in far edge data centers thanks to YoMo's highly efficient network services
🔐 Security: WasmEdge runs the data processing function in a WebAssembly sandbox for isolation, safety, and hot deployment
🚀 High Performance: Compared with popular containers, such as Docker, WasmEdge can be up to 100x faster at startup and have a much smaller footprint
🎯 Edge Devices: As WasmEdge consumes much less resources than Docker, it is now possible to run data processing applications on edge devices

Open-source projects that we used:

Serverless stream processing framework YoMo
Integrate with WasmEdge to introduce WebAssembly, interop TensorFlow Lite model
A deep learning model found on TensorFlow Hub; make sure to download TFLite (aiy/vision/classifier/food_V1), which was created by Google

Steps to run

1. Clone This Repository

$ git clone https://github.com/yomorun/yomo-wasmedge-tensorflow.git

2. Install YoMo CLI

$ go install github.com/yomorun/cli/yomo@latest
$ yomo version
YoMo CLI version: v0.0.5

Or, you can download the pre-built binary tarball yomo-v0.0.5-x86_64-linux.tgz.

Details about YoMo CLI installation can be found here.

3. Install WasmEdge Dependencies

Install WasmEdge

$ wget https://github.com/WasmEdge/WasmEdge/releases/download/0.8.0/WasmEdge-0.8.0-manylinux2014_x86_64.tar.gz
$ tar -xzf WasmEdge-0.8.0-manylinux2014_x86_64.tar.gz
$ sudo cp WasmEdge-0.8.0-Linux/include/wasmedge.h /usr/local/include
$ sudo cp WasmEdge-0.8.0-Linux/lib64/libwasmedge_c.so /usr/local/lib
$ sudo ldconfig

Or, you can build from the source.

Install WasmEdge-tensorflow

Install tensorflow dependencies for manylinux2014 platform

$ wget https://github.com/second-state/WasmEdge-tensorflow-deps/releases/download/0.8.0/WasmEdge-tensorflow-deps-TF-0.8.0-manylinux2014_x86_64.tar.gz
$ wget https://github.com/second-state/WasmEdge-tensorflow-deps/releases/download/0.8.0/WasmEdge-tensorflow-deps-TFLite-0.8.0-manylinux2014_x86_64.tar.gz
$ sudo tar -C /usr/local/lib -xzf WasmEdge-tensorflow-deps-TF-0.8.0-manylinux2014_x86_64.tar.gz
$ sudo tar -C /usr/local/lib -xzf WasmEdge-tensorflow-deps-TFLite-0.8.0-manylinux2014_x86_64.tar.gz
$ sudo ln -sf libtensorflow.so.2.4.0 /usr/local/lib/libtensorflow.so.2
$ sudo ln -sf libtensorflow.so.2 /usr/local/lib/libtensorflow.so
$ sudo ln -sf libtensorflow_framework.so.2.4.0 /usr/local/lib/libtensorflow_framework.so.2
$ sudo ln -sf libtensorflow_framework.so.2 /usr/local/lib/libtensorflow_framework.so
$ sudo ldconfig

Install WasmEdge-tensorflow:

$ wget https://github.com/second-state/WasmEdge-tensorflow/releases/download/0.8.0/WasmEdge-tensorflow-0.8.0-manylinux2014_x86_64.tar.gz
$ wget https://github.com/second-state/WasmEdge-tensorflow/releases/download/0.8.0/WasmEdge-tensorflowlite-0.8.0-manylinux2014_x86_64.tar.gz
$ sudo tar -C /usr/local/ -xzf WasmEdge-tensorflow-0.8.0-manylinux2014_x86_64.tar.gz
$ sudo tar -C /usr/local/ -xzf WasmEdge-tensorflowlite-0.8.0-manylinux2014_x86_64.tar.gz
$ sudo ldconfig

Install WasmEdge-image:

$ wget https://github.com/second-state/WasmEdge-image/releases/download/0.8.0/WasmEdge-image-0.8.0-manylinux2014_x86_64.tar.gz
$ sudo tar -C /usr/local/ -xzf WasmEdge-image-0.8.0-manylinux2014_x86_64.tar.gz
$ sudo ldconfig

If you have any questions about installation, please refer to the official documentation. Currently, this project works on Linux machines only.

Install video and image processing dependencies

$ sudo apt-get update
$ sudo apt-get install -y ffmpeg libjpeg-dev libpng-dev

4. Write your Streaming Serverless function

Write app.go to integrate WasmEdge-tensorflow:

Get WasmEdge-go:

$ cd flow
$ go get -u github.com/second-state/WasmEdge-go/wasmedge

Download pre-trained TensorflowLitee model: lite-model_aiy_vision_classifier_food_V1_1.tflite, store to rust_mobilenet_foods/src:

$ wget 'https://storage.googleapis.com/tfhub-lite-models/google/lite-model/aiy/vision/classifier/food_V1/1.tflite' -O ./rust_mobilenet_food/src/lite-model_aiy_vision_classifier_food_V1_1.tflite

Compile to wasm file:

Install rustc and cargo

$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
$ export PATH=$PATH:$HOME/.cargo/bin
$ rustc --version

Set default rust version to 1.50.0: $ rustup default 1.50.0

Install rustwasmc

$ curl https://raw.githubusercontent.com/second-state/rustwasmc/master/installer/init.sh -sSf | sh
$ cd rust_mobilenet_food
$ rustwasmc build
# The output WASM will be `pkg/rust_mobilenet_food_lib_bg.wasm`.

Copy pkg/rust_mobilenet_food_lib_bg.wasm to flow directory:

$ cp pkg/rust_mobilenet_food_lib_bg.wasm ../.

5. Run YoMo Orchestrator Server

  $ yomo serve -c ./zipper/workflow.yaml

6. Run Streaming Serverless function

$ cd flow
$ go run --tags "tensorflow image" app.go

7. Demonstrate video stream

Download this demo vide: hot-dog.mp4, store to source directory, then run：

$ wget -P source 'https://github.com/yomorun/yomo-wasmedge-tensorflow/releases/download/v0.1.0/hot-dog.mp4'
$ go run ./source/main.go ./source/hot-dog.mp4

8. Result

DEBS Grand Challenge: Real-Time Stream Processing with YoMo

C.C. — Thu, 13 May 2021 16:10:18 +0000

Introduction

DEBS or the ACM International Conference on Distributed Event Based Systems aims to "provide a forum dedicated to the dissemination of original research, the discussion of practical insights, and the reporting of experiences relevant to event based computing that were previously scattered across several scientific and professional communities" (reference).

The DEBS 2014 Grand Challenge - Smart Grid is the 8th ACM International Conference on Distributed Event Based Systems, focused on two problems which are relevant to the industry: real-time load prediction and anomaly detection. The data for the challenge was collected from a number of smart-home installations deployed in Germany.

In traditional processing, data is often stored in the database at first, and then processed to obtain useful information at a secondary stage. The traditional architecture:

However, with stream processing, we're swiftly able to run real-time analytics on incoming data streams. By utilizing Yomo, an open-source serverless stream processing framework, we can address DEBS' challenge in a real-time fashion:

Firstly, we will take a look at the type of data we're dealing with. Next, we will introduce two queries that were originally proposed by ACM DEBS. Lastly, we install YoMo (an open-source framework for real-time stream processing) to implement both queries as described.

Data

From Jerzak and Ziekow (2014):

For the DEBS 2014 Grand Challenge we assume a hierarchical structure with a house, identified by a unique house id, being the topmost entity. Every house contains one or more households, identified by a unique household id (within a house). Every household contains one or more smart plugs, each identified by a unique plug id (within a household). Every smart plug contains exactly two sensors:
(1) load sensor measuring current load with Watt as unit (2) work sensor measuring total accumulated work since the start (or reset) of the sensor with kWh as unit.

The input stream is defined as follows:

id – a unique identifier of the measurement [32 bit unsigned int]
timestamp – timestamp of measurement [32 bit unsigned int]
value – the measurement [32 bit float]
property – type of the measurement: 0 for work or 1 for load [boolean]
plug_id – a unique identifier (within a household) of the smart plug [32 bit unsigned int]
household_id – a unique identifier of a household (within a house) where the plug is located [32 bit unsigned int]
house_id – a unique identifier of a house where the household with the plug is located [32 bit unsigned int]

The complete data file is available under this link. For demonstration purposes, we will generate mock data using this file. In real life, we should be dealing with direct sensor data.

Queries

Load Prediction

Let's divide the whole period from t_{start} = 1377986401 to t_{end} = 1380578399 covered by the dataset into N equal slices of |s| seconds and call them s_0, s_1, s_2, etc.

The average load for slice s_{i + 2} is given by

L(s_{i + 2}) = ( avgLoad(s_i) + median({ avgLoad(s_j) }) ) / 2

s_j is a nonempty set defined by s_(i + 2 – n * k), where k is the number of slices within a 24-hour period and n is a natural number between 1 and floor((i + 2) / k).

Outliers

For this query, we will compute the percentage of plugs that have a median load during the last hour greater than the median load of all plugs.

YoMo – what is it and why do we use it?

YoMo is an open-source serverless streaming framework for building low-latency edge computing applications. Built atop QUIC transport protocol and functional reactive programming interface, it makes real-time data processing reliable, secure, and easy.

Getting Started

Follow the instructions here to install YoMo. Assuming that $GOPATH has been set on your device, you should be able to see a directory with the name $GOPATH/src/github.com/yomorun/yomo.
Run the following commands to create a new project. Don't forget to replace ${YOUR_GITHUB_USERNAME} with your actual GitHub username!

$ mkdir -p $GOPATH/src/github.com/${YOUR_GITHUB_USERNAME} && cd $_
$ yomo init debs-flow

Now, cd into $GOPATH/src/github.com/${YOUR_GITHUB_USERNAME}. It should have the following structure.

```shell
.
└── debs-flow
    ├── app.go
    ├── go.mod
    ├── go.sum
    └── sl.so
```

We will be focusing on the Handler function in app.go, which defines how we want the input stream to be processed.

Git clone the yomo-source-example repository. For clarity, we will call it debs-source.
```
$ git clone git@github.com:yomorun/yomo-source-example.git
```

Create a file named workflow.yaml with the following content. Place it under debs-source.

name: service
host: localhost
port: 9000
flows:
- name: debs 2014
    host: localhost
    port: 4242
sinks:
- name: mock db
    host: localhost
    port: 4243

Make sure the $GOPATH/src/github.com/${YOUR_GITHUB_USERNAME} directory contains the following files.

```shell
.
├── debs-flow
│   ├── app.go
│   ├── go.mod
│   ├── go.sum
│   └── sl.so
└── debs-source
    ├── go.mod
    ├── go.sum
    ├── main.go
    └── workflow.yaml
```

Algorithm Implementation

By default, the Handler function in debs-flow/app.go should look as follows.

func Handler(rxstream rx.RxStream) rx.RxStream {
    stream := rxstream.
        Subscribe(0x10).
        OnObserve(decoder).
        Map(printer).
        Encode(0x11)

    return stream
}

Subscribe(0x10): Subscribe to the input stream. 0x10 is the key. It is defined in debs-source/main.go.
OnObserve(decoder): Decode []byte to interface{}. Empty interfaces are often used by code that handles values of unknown type.
Map(printer): Print out the data.

For query #1, we need to define two functions in addition to what we discussed above. We will call them average and predict.

func Handler(rxstream rx.RxStream) rx.RxStream {
    stream := rxstream.
        Subscribe(0x10).
        OnObserve(decoder).
        Map(printer).
        BufferWithTime(ss * 1e3). // ss stands for slice size
        Map(average).
        Map(predict).
        Encode(0x11)

    return stream
}

// compute the average load for each plug and save the values to db, which is a global variable in this example
func average(_ context.Context, i interface{}) (interface{}, error) {
    // convert interface{} to []interface{}
    lst, ok := i.([]interface{})
    if !ok {
        err := fmt.Sprintf("expected type '[]interface{}', got '%v' instead",
            reflect.TypeOf(i))
        fmt.Printf("[average] %v\n", err)
        return nil, fmt.Errorf(err)
    }

    // plug # -> value
    total := make(map[string]float32)
    count := make(map[string]float32)

    for _, elem := range lst {
        // convert interface{} to measurement
        x, ok := elem.(Measurement)
        if !ok {
            err := fmt.Sprintf("expected type 'measurement', got '%v' instead",
                reflect.TypeOf(elem))
            fmt.Printf("[average] %v\n", err)
            return nil, fmt.Errorf(err)
        }

        if x.Property { // load
            plug := x.toString()
            total[plug] += x.Value
            count[plug] += 1.0
        }
    }

    // save to db
    fmt.Println("*** average ***")
    for plug, v := range total {
        avg := v / count[plug]
        fmt.Printf("[s_%v] %v %v\n", idx, plug, avg)

        _, ok := db[plug]
        if !ok {
            db[plug] = make(map[uint32]float32)
        }
        db[plug][idx] = avg
    }
    fmt.Println("***************")
    return i, nil
}

// make predictions based on what we have in db
func predict(_ context.Context, i interface{}) (interface{}, error) {
    k := t / ss

    fmt.Println("*** predict ***")
    l := (idx + 2) / k
    if l == 0 {
        fmt.Println("not enough data")
    } else {
        // possible values for j
        lst := make([]uint32, l)
        for m := range lst {
            n := uint32(m + 1)
            j := idx + 2 - n*k
            lst[m] = j
        }

        for plug := range db {
            // average load for s_j
            data := make([]float32, l)
            for m, j := range lst {
                data[m] = db[plug][j]
            }
            pred := (db[plug][idx] + median(data)) / 2
            fmt.Printf("[s_%v] %v %v\n", idx+2, plug, pred)
        }
    }
    fmt.Println("***************")

    idx += 1 // slice #
    return 0.0, nil
}

For query #2, we will define a function called outliers.

func Handler(rxstream rx.RxStream) rx.RxStream {
    stream := rxstream.
        Subscribe(0x10).
        OnObserve(decoder).
        Map(printer).
        BufferWithTime(ss * 1e3).
        Map(outliers).
        Encode(0x11)

    return stream
}

// which plugs have a median load greater than the median load of all plugs?
func outliers(_ context.Context, i interface{}) (interface{}, error) {
    // convert interface{} to []interface{}
    lst, ok := i.([]interface{})
    if !ok {
        err := fmt.Sprintf("expected type '[]interface{}', got '%v' instead",
            reflect.TypeOf(i))
        fmt.Printf("[outliers] %v\n", err)
        return nil, fmt.Errorf(err)
    }

    all := make([]float32, 0, len(lst))
    indiv := make(map[string][]float32) // plug # -> values

    for _, elem := range lst {
        // convert interface{} to measurement
        x, ok := elem.(Measurement)
        if !ok {
            err := fmt.Sprintf("expected type 'measurement', got '%v' instead",
                reflect.TypeOf(elem))
            fmt.Printf("[outliers] %v\n", err)
            return nil, fmt.Errorf(err)
        }

        if x.Property { // load
            all = append(all, x.Value)

            plug := x.toString()
            indiv[plug] = append(indiv[plug], x.Value)
        }
    }

    v := median(all)
    fmt.Printf("all plugs: %v\n", v)

    fmt.Println("*** outliers ***")
    for plug, vs := range indiv {
        m := median(vs)
        if m > v {
            fmt.Printf("[w_%v] %v %v\n", idx, plug, m)
        }
    }
    fmt.Println("****************")

    idx += 1
    return 0.0, nil
}

Now to run the code, we need to:

cd into debs-flow and type
```
$ yomo run app.go
```

cd into debs-source and type

$ yomo wf run workflow.yaml
$ PORT=9000 go run main.go

You might want to try a different set of hyperparameters.

Results

For query #1, you should see something similar to the following.

...
[1620461050] 9.910085 0-1-2 load
[1620461050] 8.087268 0-1-2 work
[1620461050] 13.468374 3-1-2 load
[1620461050] 7.742124 3-1-2 work
[1620461051] 13.738256 0-1-2 load
[1620461051] 16.59261 0-1-2 work
[1620461051] 12.84997 3-1-2 load
[1620461051] 10.838872 3-1-2 work
*** average ***
[s_18] 0-1-2 11.824171
[s_18] 3-1-2 13.159172
***************
*** predict ***
[s_20] 0-1-2 10.375039
[s_20] 3-1-2 12.0406475
***************
...

For query #2, something like this:

...
[1620461271] 6.921172 0-1-2 load
[1620461271] 1.8683584 0-1-2 work
[1620461271] 17.251171 3-1-2 load
[1620461271] 9.761936 3-1-2 work
[1620461272] 10.758014 0-1-2 load
[1620461272] 18.668419 0-1-2 work
[1620461272] 5.806175 3-1-2 load
[1620461272] 1.8562717 3-1-2 work
[1620461273] 0.11624338 0-1-2 load
[1620461273] 5.579194 0-1-2 work
[1620461273] 17.249205 3-1-2 load
[1620461273] 4.9580107 3-1-2 work
[1620461274] 8.087428 0-1-2 load
[1620461274] 7.49426 0-1-2 work
[1620461274] 4.6709924 3-1-2 load
[1620461274] 1.793222 3-1-2 work
[1620461275] 4.8114495 0-1-2 load
[1620461275] 1.9070174 0-1-2 work
[1620461275] 19.199306 3-1-2 load
[1620461275] 9.054778 3-1-2 work
all plugs: 7.5043
*** outliers ***
[s_5] 3-1-2 17.249205
****************
...

About Author

Ivy Guo is a Computer Science student at the University of Washington. If you have any questions, please email Ivy at zhifeig@cs.washington.edu

References

Zbigniew Jerzak and Holger Ziekow. 2014. The DEBS 2014 grand challenge. In Proceedings of the 8th ACM International Conference on Distributed Event-Based Systems (DEBS '14). Association for Computing Machinery, New York, NY, USA, 266–269. DOI: https://doi.org/10.1145/2611286.2611333.

More about YoMo

https://github.com/yomorun/yomo

DEV Community: C.C.

Beginner's Guide to Cuck Coding

Beginner's Guide to Cuck Coding

Introduction

What Is Cuck Coding?

Common Motivations and Appeals

Cuck Coding vs. Slacking: Understand the Difference

Communication: The Cornerstone of Healthy Cuck Coding

Early Prompts

Ongoing Check-ins

Emotional Dynamics: Irrelevance, Envy, and Insecurity

Envy vs. Relief

Aftermerge

The Roles in Cuck Coding

Choosing Your Agent

Where to Look

Vetting

Chemistry and Comfort

Setting Up the Scene: Practical Considerations

The Chair

The Screen

The View

Common Beginner Mistakes

FAQ

Conclusion

I kept hitting jq: parse error on AI streams, so I built sjq

What it looks like

Install

Why not just strip the framing with sed?

The Ultimate OpenCode.ai Setup: Why I’m using Vivgrid’s GPT-5.1-Codex

OpenCode

Configure OpenCode.ai to Use Vivgrid (GPT-5.1-Codex)

1. Configure Authentication

2. Configure OpenCode Runtime

3. Verify the Setup

4. Debugging

5. GUI

Summary

Streaming Image Recognition by WebAssembly and Tensorflow

Steps to run

1. Clone This Repository

2. Install YoMo CLI

3. Install WasmEdge Dependencies

Install WasmEdge

Install WasmEdge-tensorflow

Install video and image processing dependencies

4. Write your Streaming Serverless function

5. Run YoMo Orchestrator Server

6. Run Streaming Serverless function

7. Demonstrate video stream

8. Result

DEBS Grand Challenge: Real-Time Stream Processing with YoMo

Introduction

Data

Queries

YoMo – what is it and why do we use it?

Getting Started

Algorithm Implementation

Results

About Author

Further Reading

References

More about YoMo