Crypto Forem

Anonymous Membership Proofs on Midnight: Building Privacy-Preserving Allowlists

BossChaos — Sat, 02 May 2026 13:05:55 +0000

Anonymous Membership Proofs on Midnight: Building Privacy-Preserving Allowlists

Last month, I was tasked with building an allowlist system for a Midnight dApp. The requirement seemed simple: let authorized users access a feature without revealing who they are. In the clear-text world, you'd just check if (user in allowedList). But on a privacy platform, that if statement leaks everything.

This tutorial walks through building a complete anonymous membership proof system — from the Compact contract on-chain to the TypeScript tooling that generates Merkle proofs locally. We'll cover sparse Merkle trees, depth-20 path verification, nullifier-based replay prevention, and admin root management.

Why Merkle Trees for Allowlists?

Traditional allowlists publish every member's address on-chain. That's fine for transparency, but terrible for privacy. A Merkle tree solves this differently:

Off-chain: The admin maintains a list of member secrets
On-chain: Only a single 32-byte hash (the Merkle root) is stored
Proof: A member proves they know a secret that hashes to a leaf in the tree, without revealing which leaf

                    Root (on-chain)
                   /    \
                 H01    H23
                /  \    /  \
               H0  H1  H2  H3
              / \  / \ / \ / \
             L0 L1 L2 L3 ...  (2^20 leaves)

To prove you're L1, you provide H0, H23, and the path indices. The verifier recomputes the root and checks it matches the on-chain value. Your secret (L1's preimage) stays private.

The Compact Contract

The contract manages three pieces of state:

export ledger merkle_root: Bytes<32>;
export ledger admin_commitment: Bytes<32>;
export ledger used_nullifiers: Set<Bytes<32>>;

Witnesses (Secret Inputs)

These are the prover-side inputs that never appear on-chain:

witness getSecret(): Bytes<32>;
witness getContext(): Bytes<32>;
witness getSiblings(): Vector<20, Bytes<32>>;
witness getPathIndices(): Vector<20, Boolean>;
witness getAdminSecret(): Bytes<32>;

Recomputing the Merkle Path

circuit hashLevelNode(is_right: Boolean, current: Bytes<32>, sibling: Bytes<32>): Bytes<32> {
  if (is_right) {
    return persistentHash<Vector<3, Bytes<32>>>([
      pad(32, "zk-allowlist:node:v1"),
      sibling,
      current
    ]);
  } else {
    return persistentHash<Vector<3, Bytes<32>>>([
      pad(32, "zk-allowlist:node:v1"),
      current,
      sibling
    ]);
  }
}

Checking Membership

circuit isMember(): (Bytes<32>, Bytes<32>) {
  let secret = getSecret();
  let context = getContext();
  let leaf = poseidonHash(secret);
  let computed_root = leaf;
  let siblings = getSiblings();
  let indices = getPathIndices();

  for (i in 0..20) {
    computed_root = hashLevelNode(indices[i], computed_root, siblings[i]);
  }

  assert(computed_root == merkle_root.read(), "Invalid membership proof");

  let nullifier = persistentHash<Vector<2, Bytes<32>>>([secret, context]);
  assert(not used_nullifiers.contains(nullifier), "Nullifier already used");

  (computed_root, nullifier)
}

Admin Root Management

export circuit setRoot(new_root: Bytes<32>): [] {
  let admin_secret = getAdminSecret();
  let commitment = poseidonHash(admin_secret);
  assert(commitment == admin_commitment.read(), "Not authorized");
  merkle_root.write(disclose(new_root));
}

The TypeScript Tooling

Sparse Merkle Tree Implementation

export class MerkleTree {
  readonly depth: number;
  private leaves: HashHex[] = [];
  private layers: Map<number, Map<number, HashHex>> = new Map();
  private zeroHashes: HashHex[];

  constructor(depth: number = 20) {
    this.depth = depth;
    this.zeroHashes = computeZeroHashes(depth);
    for (let i = 0; i <= depth; i++) {
      this.layers.set(i, new Map());
    }
  }

  insertLeaf(leafHash: HashHex): number {
    const leafIndex = this.leaves.length;
    this.leaves.push(leafHash);
    this.setNode(0, leafIndex, leafHash);

    let currentIndex = leafIndex;
    for (let level = 0; level < this.depth; level++) {
      const parentIndex = Math.floor(currentIndex / 2);
      const leftChild = this.getNode(level, parentIndex * 2);
      const rightChild = this.getNode(level, parentIndex * 2 + 1);
      const parentHash = hashNode(leftChild, rightChild);
      this.setNode(level + 1, parentIndex, parentHash);
      currentIndex = parentIndex;
    }
    return leafIndex;
  }
}

The Complete Flow

Step 1: Admin Sets Up the Contract

ADMIN_SECRET=$(openssl rand -hex 32)
ADMIN_COMMITMENT=$(echo -n $ADMIN_SECRET | poseidon-hash)
compact deploy --ledger admin_commitment=$ADMIN_COMMITMENT

Step 2: Add Members Off-Chain

midnight-allowlist add-member --secret "alice-secret-123"
ROOT=$(midnight-allowlist get-root)

Step 3: Push Root On-Chain

compact call setRoot --arg new_root=$ROOT --witness admin_secret=$ADMIN_SECRET

Step 4: Member Generates and Submits Proof

PROOF=$(midnight-allowlist generate-proof --secret "alice-secret-123" --context "voting-round-1")
compact call proveMembership --proof $PROOF

Edge Cases and Gotchas

1. Zero Hash Collisions

The sparse tree uses pre-computed zero hashes. Make sure your computeZeroHashes function matches exactly what the Compact contract expects.

2. Context Binding

The nullifier is hash(secret || context). Use distinct contexts for different operations:

const VOTE_CONTEXT = "governance-vote-q2-2026";
const AIRDROP_CONTEXT = "token-airdrop-genesis";

3. Tree Capacity Planning

A depth-20 tree supports ~1M members. Each additional level doubles capacity but increases proof generation time linearly.

Testing

describe('ZK Allowlist', () => {
  it('should verify valid membership proof', async () => {
    const tree = new MerkleTree(20);
    tree.insertLeaf(hashLeaf('alice-secret'));
    const proof = tree.generateMerkleProof(0);
    expect(verifyProof(tree.root, proof, hashLeaf('alice-secret'))).toBe(true);
  });
});

What's Next?

This system handles the core membership proof flow. Production deployments should consider batch root updates, Merkle tree snapshots, circuit optimization, and frontend integration.

The complete source code is available in the companion repository linked in the PR.

This tutorial is part of the Midnight Network bounty program. For more developer resources, visit docs.midnight.network.

Building an AI-Powered Identity Manager

Me Y — Sat, 02 May 2026 13:05:23 +0000

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

What I Built

I built the AI Business Card Architect, a comprehensive identity management platform that goes beyond simple design. It utilizes the Imagen API to generate unique, minimalist brand logos based on company names.

The app features a "Guest First" approach with an optional CS50-inspired local authentication system, allowing users to manage multiple profiles (Personal, Business, Family) each with its own independent vault. Key prompts focused on "Professional minimalist logo synthesis" and "Smart contrast accessibility logic" to ensure every generated card is print-ready and digitally accessible.

Demo

https://ai-business-card-architect.vercel.app/

Key Features Screenshots:

AI Forge: Instant logo generation using Imagen.
Multi-Profile Switcher: Managing different identities seamlessly.
3-in-1 Bulk Archive: Exporting Standard, Centered, and Modern Split layouts in one click.

My Experience

Working through this track was an eye-opener regarding the synergy between Generative AI and traditional application logic.

What I learned: I learned how to bridge the gap between "Guest" usage and "Authenticated" persistence without friction. Integrating the Imagen API taught me the importance of prompt engineering for consistent branding.

What was surprising: The most surprising part was how effectively Gemini 3 Flash handled complex "Smart Contrast" algorithms, automatically flipping text colors to maintain readability based on the generated image's relative luminance. It felt less like coding and more like "Architecting" a brain for the app.

How React Works (Part 5)? The React Lifecycle From the Inside: When Things Actually Run

Sam Abaasi — Sat, 02 May 2026 13:03:02 +0000

The React Lifecycle From the Inside: When Things Actually Run

Series: How React Works Under the Hood
Part 1: Motivation Behind React Fiber: Time Slicing & Suspense
Part 2: Why React Had to Build Its Own Execution Engine
Part 3: How React Finds What Actually Changed
Part 4: The Idea That Makes Suspense Possible
Prerequisites: Read Parts 1–4 first.

A Puzzle Most React Developers Get Wrong

Quick quiz. What order do these log?

function App() {
  useLayoutEffect(() => {
    console.log('layout effect');
  });

  useEffect(() => {
    console.log('effect');
  });

  console.log('render');
  return <div />;
}

Most people guess: render → effect → layout effect, or render → layout effect → effect.

The answer is: render → layout effect → effect.

But more importantly — why? Why does useLayoutEffect run before useEffect? Why does useEffect run at all after the component already returned? What does "after the browser paints" actually mean, and is that even always true?

This article answers all of that. And by the end, you'll be able to look at any component and predict exactly when each piece of it runs — and why.

The Three Phases of a React Render

Before we get into effects, we need to remember the pipeline from Part 2. Every React update goes through three phases:

Render — React runs your component functions, diffs the trees, figures out what changed. Nothing is written to the DOM yet. This is where console.log('render') fires.

Commit — React takes everything it figured out during Render and applies it to the real DOM. This is synchronous and uninterruptible.

Effects — After the DOM is updated, React runs your effects.

The key insight is that effects are not part of rendering. They're a separate step that happens after the DOM is already updated. This is why you can safely read the DOM inside an effect — by the time it runs, the DOM reflects the current state.

What `useEffect` Actually Is

Here's the mental model most developers have: useEffect is "code that runs after render." That's roughly right but missing the important details.

Here's the more accurate model: useEffect is a declaration that you have side effects to run after React is done with the DOM. You're not scheduling a callback — you're telling React about work that needs to happen, and React decides when to run it.

The distinction matters because React doesn't run effects immediately after commit. It schedules them.

From jser.dev's lifecycle article — here's what actually happens:

After the Commit phase finishes updating the DOM, React schedules your useEffect callbacks as a separate task in the Scheduler's queue — the same Scheduler we covered in Part 2. That means effects run in a new macro task, after the browser has had a chance to paint the updated screen.

This is why the React docs say useEffect runs "after the browser paints." The sequence looks like this:

1. Render phase — your component functions run
2. Commit phase — DOM is updated
3. Browser paints the screen
4. Scheduler fires — useEffect callbacks run

The browser gets step 3 because steps 1-2 are one macro task, and step 4 is a new macro task. Between any two macro tasks, the browser can paint.

The Cleanup: Why It Runs Before the Next Effect

Every useEffect can return a cleanup function:

useEffect(() => {
  const subscription = subscribe(id);
  return () => subscription.unsubscribe(); // cleanup
}, [id]);

When id changes and the effect needs to re-run, React runs the cleanup of the previous effect first, then runs the new effect. Always in that order.

This is also true on unmount — the cleanup runs when the component leaves the tree.

The reason is straightforward: React never wants two instances of the same effect active at the same time. Before setting up the new subscription, it tears down the old one. This is React being deliberate about side effects — always clean up before you set up again.

From jser.dev's effect lifecycle article: cleanups run first in commitPassiveUnmountEffects, then new effects run in commitPassiveMountEffects. Both happen in the same scheduled task, in the same order as the tree (children before parents, same as completeWork).

`useLayoutEffect`: The Synchronous Version

Here's the critical difference: useLayoutEffect runs synchronously inside the Commit phase, before the browser paints.

The sequence with useLayoutEffect:

1. Render phase — component functions run
2. Commit phase — DOM is updated
3. useLayoutEffect callbacks run ← here, synchronously, before paint
4. Browser paints
5. useEffect callbacks run ← here, in next macro task

This is why useLayoutEffect fires before useEffect in our opening quiz — it's not "earlier in the same phase," it's in a completely different phase.

And this is why useLayoutEffect exists at all. If you need to read the DOM after it's updated but before the user sees it — for example, measuring an element's size to position a tooltip — useLayoutEffect is the only place where that's safe and accurate.

// useLayoutEffect — correct for DOM measurements
useLayoutEffect(() => {
  const rect = ref.current.getBoundingClientRect();
  setTooltipPosition({ top: rect.bottom, left: rect.left });
});

// useEffect — would cause a visible flicker for measurements
// because the browser already painted before this runs
useEffect(() => {
  const rect = ref.current.getBoundingClientRect();
  setTooltipPosition({ top: rect.bottom, left: rect.left }); // too late
});

If you use useEffect for a DOM measurement that affects layout, the user will briefly see the wrong layout (before useEffect runs), then see it jump to the correct layout (after). That flicker is exactly what useLayoutEffect prevents.

The "After Paint" Rule Has an Exception

Here's something jser.dev discovered that React's own documentation gets wrong.

The docs say useEffect always runs after the browser paints. But that's not strictly true.

Sometimes React runs useEffect callbacks before paint. This happens when React determines it's more important to show the latest UI as quickly as possible — for example, when a re-render is triggered by a user interaction, or when effects are scheduled under layout effects. In those cases, React won't wait for a paint before running the effects.

From jser.dev's paint timing article:

"I'd explain the timing of running useEffect() callbacks as follows. useEffect() callbacks are run after DOM mutation is done. Most of the time, they are run asynchronously after paint, but React might run them synchronously before paint when it is more important to show the latest UI — for example when re-render is caused by user interactions or scheduled under layout effects, or simply if React has the time internally to do so."

The practical implication: never rely on useEffect to run after paint for correctness. If your code requires running after the browser paints, useLayoutEffect with its explicit synchronous-before-paint guarantee is actually the more predictable choice. And if you truly need to run something after paint for non-DOM reasons, the gap is usually small enough not to matter.

The Dependency Array: What It Actually Controls

The dependency array in useEffect and useLayoutEffect doesn't control whether the effect runs — it controls when it re-runs.

React compares the current values of the dependency array to the previous ones using Object.is (similar to === but handles NaN and -0 correctly). If any value changed, React marks the effect with a flag indicating it should run again. If nothing changed, the effect is skipped this cycle.

useEffect(() => {
  fetchUser(id);
}, [id]); // only re-runs when id changes

Three cases:

No dependency array — re-runs after every render. The effect has no conditions.

Empty array [] — runs once on mount, cleanup runs on unmount. Effect has no dependencies that can change.

Array with values — re-runs whenever any listed value changes between renders.

The important thing to understand: React doesn't track what you use inside the effect. It trusts the dependency array you provide. If you use userId inside the effect but forget to put it in the array, React won't re-run the effect when userId changes — and you get a stale value bug. This is why eslint-plugin-react-hooks exists: it statically analyzes your effect and warns when the array is incomplete.

The Full Lifecycle in One Timeline

The pattern is consistent across every scenario. On mount, the component renders, React commits the DOM, useLayoutEffect fires synchronously before the browser paints, the browser paints, then useEffect runs in the next macro task. On update, cleanups always run before new effects — layout cleanup first, then layout create, then paint, then passive cleanup, then passive create. On unmount, both cleanups run in the same order, layout before passive, with paint in between.

Two things are always true regardless of the scenario: layout effects are synchronous and pre-paint, passive effects are scheduled and post-commit. And cleanups always run before the next effect of the same type — React never has two instances of the same effect active at once.

When to Use Which

Use useEffect for everything by default. Most side effects — data fetching, subscriptions, logging, timers — don't need to happen before the browser paints. Running them after paint keeps the UI responsive and is the right choice in the vast majority of cases.

Reach for useLayoutEffect only when you need to read or modify the DOM before the user sees it — measuring element dimensions, positioning a tooltip relative to another element, or preventing a visual flicker. The practical test is simple: if swapping useLayoutEffect for useEffect causes a visible jump or flash in the UI, you needed useLayoutEffect. If it looks identical, stick with useEffect.

What's Coming in Part 6

In Part 6 we go inside useState — how state is stored on the Fiber, what happens when you call setState, and why calling setState multiple times in one event handler doesn't cause multiple re-renders.

🎬 Watch These

JSer (jser.dev) — The lifecycle of effect hooks in React
The source for the Effect object internals, HookHasEffect tag, flushPassiveEffects, and cleanup ordering in this article.

JSer (jser.dev) — How does useLayoutEffect() work internally?
The synchronous commit-phase timing of layout effects vs passive effects — the source for the timing difference explained here.

JSer (jser.dev) — When do useEffect() callbacks get run? Before paint or after paint?
The surprising finding that React.dev's "always after paint" description is inaccurate — and the real timing rules.

🙏 Sources & Thanks

jser.dev — all timing mechanics in this article come from JSer's source-level analysis. Articles used: The lifecycle of effect hooks in React, How does useLayoutEffect() work internally?, How does useEffect() work internally in React?, and When do useEffect() callbacks get run? — including the quote about React.dev's inaccurate description.
React source — ReactFiberCommitWork.js (commitLayoutEffects, commitPassiveMountEffects, commitPassiveUnmountEffects) and ReactFiberWorkLoop.js (scheduleCallback for passive effects).
Lydia Hallie — for JavaScript visualizations that shaped this series' style.

Part 6 is next — how useState actually works: where state lives, what happens when you call setState, and why multiple calls in one handler don't cause multiple re-renders. 🔧

Tags: #react #javascript #webdev #tutorial

TestSprite — Panduan Cepat (Indonesian Translation)

placecel427-source — Sat, 02 May 2026 12:54:44 +0000

TestSprite — Panduan Cepat

Apa itu TestSprite?

TestSprite adalah platform otomasi testing terpadu untuk aplikasi web modern. Dengan menganalisis UI Anda secara real-time, TestSprite secara otomatis menghasilkan test cases integrasi yang komprehensif dan memeliharanya seiring perubahan aplikasi Anda.

Masalah yang dipecahkan:

Test sulit ditingkatkan saat UI berubah
Tim QA menghabiskan jutaan jam menulis test yang sama berulang kali
Test regresi sering gagal karena selector yang tidak valid
Onboarding engineer testing baru memakan waktu berminggu-minggu

TestSprite menghilangkan 80% dari pekerjaan manual tersebut dengan AI yang memahami aplikasi Anda.

Instalasi

1. Daftar di TestSprite

# Kunjungi dashboard
https://app.testsprite.com/signup

Buat akun dengan email kerja Anda. Verifikasi email, selesai.

2. Hubungkan Aplikasi Anda

Di dashboard TestSprite:

Klik "Add Project"
Masukkan URL aplikasi web Anda (misal: https://myapp.local:3000)
TestSprite akan scan UI Anda

// Optional: Tambahkan snippet ini ke aplikasi Anda untuk integrasi lebih dalam
<script src="https://cdn.testsprite.com/v1/agent.js"></script>
<script>
  TestSprite.init({
    projectId: "YOUR_PROJECT_ID",
    apiKey: "YOUR_API_KEY"
  });
</script>

3. Tunggu Analisis AI

TestSprite memindai aplikasi Anda selama 2-5 menit, memetakan setiap halaman, form, tombol, dan interaksi. Ini adalah satu-satunya setup yang Anda butuhkan.

Test Pertama Anda

Menghasilkan Test Cases Otomatis

Setelah analisis selesai:

Buka tab "Generated Tests"
Lihat test suite yang dibuat AI (sudah terstruktur)
Klik "Run All Tests" untuk validasi awal

# Test akan dijalankan di berbagai browser:
# - Chrome (latest)
# - Firefox (latest)
# - Safari (latest)
# - Edge (latest)

Hasil Test

Setiap test report menampilkan:

✅ Passed: X test
❌ Failed: Y test (dengan screenshot)
⏱️ Waktu eksekusi total

Jika ada kegagalan, TestSprite langsung menunjukkan:

Error: Element dengan selector ".submit-btn" tidak ditemukan
Saran: Gunakan selector alternatif "button[type="submit"]"

Merawat Test Saat UI Berubah

Ini adalah "magic" TestSprite. Ketika Anda update UI:

Skenario: Anda mengganti `.primary-button` menjadi `[data-testid="primary-btn"]`

Tanpa TestSprite (cara lama):

Test gagal ❌
Engineer membuka setiap test file
Mencari .primary-button di 50+ test
Update secara manual
30 menit yang terbuang

Dengan TestSprite:

Test mulai gagal
TestSprite mendeteksi perubahan selector
Secara otomatis menemukan selector baru
Test berjalan lagi ✅
Anda tidak perlu berbuat apa-apa

Proses ini disebut "Self-Healing Tests".

Mengintegrasikan dengan CI/CD

TestSprite bekerja dengan pipeline Anda:

GitHub Actions

name: Run TestSprite Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

      - name: Start Application
        run: npm start &

      - name: Run TestSprite Tests
        uses: testsprite/action@v1
        with:
          project-id: ${{ secrets.TESTSPRITE_PROJECT_ID }}
          api-key: ${{ secrets.TESTSPRITE_API_KEY }}

      - name: Upload Report
        if: always()
        uses: actions/upload-artifact@v2
        with:
          name: testsprite-report
          path: ./testsprite-report.html

GitLab CI

stages:
  - test

testsprite:
  stage: test
  image: testsprite/runner:latest
  script:
    - testsprite run --project-id $TESTSPRITE_PROJECT_ID --api-key $TESTSPRITE_API_KEY
  artifacts:
    paths:
      - testsprite-report.html

Jenkins

pipeline {
  stages {
    stage("TestSprite") {
      steps {
        sh """
          docker run --rm \
            -e TESTSPRITE_PROJECT_ID=$TESTSPRITE_PROJECT_ID \
            -e TESTSPRITE_API_KEY=$TESTSPRITE_API_KEY \
            testsprite/runner:latest \
            testsprite run
        """
      }
    }
  }
}

Kategori Test yang Didukung

TestSprite secara otomatis membuat test untuk:

1. Form Testing

✓ Validasi input (field required, tipe data)
✓ Submit form dengan berbagai kombinasi nilai
✓ Handling error message
✓ Reset form
✓ Penyimpanan draft otomatis

2. Navigation Testing

✓ Link internal (routing)
✓ Breadcrumb navigation
✓ Menu dropdown
✓ Tab switching
✓ Pagination

3. User Interaction Testing

✓ Click events
✓ Hover effects
✓ Keyboard shortcuts
✓ Scroll behavior
✓ Modal/dialog handling

4. Data Presentation Testing

✓ Table rendering (sorting, filtering)
✓ List pagination
✓ Search functionality
✓ Data formatting
✓ Empty state handling

5. API Integration Testing

✓ POST/GET/PUT/DELETE endpoints
✓ Error handling (404, 500, timeout)
✓ Data mismatch detection
✓ Rate limiting behavior

Contoh Test Output

Setelah menjalankan test, Anda melihat:

📊 TestSprite Test Report
══════════════════════════════════════════

Project: My E-Commerce App
Run Date: 2026-05-01 14:35:12 UTC
Duration: 4m 23s

Summary:
  ✅ Passed: 127
  ❌ Failed: 3
  ⏭️  Skipped: 2

Pass Rate: 97.7% ✓

Failed Tests:
─────────────────────────────────────────

1. [FAILED] Login form dengan email invalid
   Expected: Error message muncul
   Actual: Tombol submit tetap aktif
   Screenshot: https://testsprite.com/report/screenshot/1

2. [FAILED] Cart update quantity
   Expected: Total harga update
   Actual: Total harga tetap sama
   Diff: -$15 (expected)

3. [FAILED] Mobile responsive - navigation menu
   Expected: Menu hamburger muncul di width 480px
   Actual: Menu hamburger tidak visible
   Device: iPhone 12 Mini

Konfigurasi Lanjutan

Custom Test Parameters

{
  "testConfig": {
    "browsers": ["chrome", "firefox", "safari"],
    "devices": ["desktop", "tablet", "mobile"],
    "timeout": 30000,
    "retryFailedTests": 2,
    "parallelism": 4,
    "screenshotOnFailure": true,
    "videoRecording": true,
    "apiBaseUrl": "https://api.myapp.com",
    "excludePatterns": [
      "/admin/*",
      "/internal/*"
    ]
  }
}

Environment Variables

# Setup untuk berbagai environment

# Development
TESTSPRITE_ENV=dev
TESTSPRITE_API_URL=http://localhost:3000

# Staging
TESTSPRITE_ENV=staging
TESTSPRITE_API_URL=https://staging.myapp.com

# Production
TESTSPRITE_ENV=prod
TESTSPRITE_API_URL=https://myapp.com

Tips & Trik

1. Jangan Manual Test Lagi

Setelah TestSprite setup, batalkan kebiasaan manual testing. AI lebih cepat dan konsisten.

2. Update Kode dengan Percaya Diri

Refactor tanpa takut memecah sesuatu. TestSprite akan memberi tahu Anda dalam menit, bukan jam.

3. Gunakan untuk Regression Sebelum Deploy

Sebelum production release, biarkan TestSprite memvalidasi seluruh aplikasi dalam 5 menit.

4. Monitor Test Trends

Dashboard menunjukkan:

Pass rate over time
Test execution time trends
Most flaky tests
Coverage by feature

5. Bagikan Laporan dengan Stakeholder

Export report sebagai HTML/PDF dan kirim ke manager/product owner. Mereka ingin bukti bahwa kualitas terjaga.

Troubleshooting

Issue: "Application tidak bisa diakses dari TestSprite runner"

Solusi:

# Jika app berjalan locally, expose dengan ngrok
ngrok http 3000

# Lalu setup TestSprite dengan URL ngrok
https://abcd1234.ngrok.io

Issue: "Test sering timeout"

Penyebab:

API terlalu lambat
Aplikasi hang saat startup
Network unstable

Solusi:

{
  "timeout": 45000,  // Naikkan dari 30s
  "apiWaitTime": 10000
}

Issue: "TestSprite tidak mendeteksi elemen dynamic (lazy-loaded)"

Solusi:

// Tambahkan indikator untuk TestSprite
<div data-testsprite-wait="content-loaded">
  {/* Dynamic content here */}
</div>

TestSprite akan tunggu hingga elemen ini render sebelum test mulai.

Langkah Selanjutnya

✅ Daftar di https://app.testsprite.com
✅ Setup project Anda
✅ Jalankan test pertama
✅ Integrasikan dengan CI/CD
✅ Monitor dashboard setiap hari

Dukungan

📧 Email: support@testsprite.com
💬 Chat: app.testsprite.com/chat
📖 Docs: https://docs.testsprite.com
🐛 Bug Report: https://github.com/testsprite/issues

Selamat testing! 🚀

Also available on GitHub Gist: https://gist.github.com/placecel427-source/ec857abad852411161ad34d1c0b0f68d

Cursor Composer 2: The Cache Economy Behind a 10x Cheaper Coding Agent

Hiroshi Toyama — Sat, 02 May 2026 12:53:01 +0000

Cursor's Composer 2 shipped in March 2026 as the centerpiece of the Cursor 2.0 overhaul. The headline numbers—$0.50/1M input tokens, outperforming frontier models on SWE-bench Multilingual—look like marketing. The cache read mechanism is where the real story is.

Why a Specialized Model at All

Prior Cursor versions proxied Claude or GPT-4. Composer 2 is trained exclusively on coding data via continued pre-training and reinforcement learning. The obvious question is: what's cut?

Everything that isn't code. Composer 2 has no meaningful capability for poetry, history, ethics debates, or anything outside software development. That constraint lets Anysphere run a model that:

Understands intra-repo dependency graphs (if you fix A, B also needs updating)
Navigates hundreds of files in a single long-horizon task
Runs natively in sandboxed terminals and a built-in browser loop
Costs a fraction of what a general-purpose frontier model costs to serve

The pricing reflects this. As of May 2026:

Model	Input (1M tokens)	Output (1M tokens)
Composer 2 Standard	$0.50	$2.50
Composer 2 Fast	$1.50	$7.50
Claude 4.6 Opus	$5.00	$25.00
GPT-5.4	$2.50	$15.00

Standard vs Fast: Same Weights, Different Queue

Anysphere's own language is unambiguous: "Same intelligence." The two variants share identical model weights and parameters. Fast gets priority queue on high-end GPUs (H800/B200 class); Standard runs on lower-priority compute with higher latency tolerance.

This is a deliberate architectural choice. Inference cost scales with compute priority, not model capability. If you can tolerate a 10–30 second response delay, you get the same output for 1/3 the price.

The practical split that Cursor power users have settled on:

Interactive sessions (Fast): You're watching the output in real time. Latency kills flow.
Fire-and-forget tasks (Standard): Refactor 100 test files, generate JSDoc across the repo, migrate an entire API surface. Start it, close the laptop, come back to results.

The Cache Read Economy

This is the mechanism that makes Standard compelling for large codebases.

Every request to Composer 2 sends context: directory structure, recently opened files, conversation history. On the second, fifth, tenth turn of the same session, the majority of that context is identical to what was already sent. That's the cache.

Cache read rates as of May 2026:

Tier	New input	Cache read
Standard	$0.50/1M	$0.20/1M
Fast	$1.50/1M	$0.35/1M

By turn 5 of a non-trivial session, 80%+ of your input tokens are cache reads, not fresh input. Standard's cache read rate ($0.20) is 43% cheaper than Fast's ($0.35), and 60% cheaper than Standard's own new input rate.

Concrete impact: A refactoring session with 10 back-and-forth turns on a large codebase might consume 10M tokens. With Standard and healthy cache hits, that lands around $1.50–$2.00. The same session on Fast: $4.00–$5.00. On Claude 4.6 Opus: potentially $20+.

The Cache Bug (March–April 2026)

The cache story has a footnote worth documenting.

From late March through early April 2026, a backend bug caused Composer 2 Standard to emit cache read counts of zero—every request treated as fresh input at $0.50/1M even when the context was identical to the previous turn. Users reported credit burn rates 10x higher than expected. The irony: switching to Fast (which costs 3x more per token) actually resulted in lower total cost because cache was functioning there.

Cursor's team (Dean and Mohit on the forum thread) acknowledged the bug and pushed a fix around April 7. As of v2.1.116+, the behavior appears stable.

The diagnostic check: open cursor.com/settings → Usage. If Cache Read tokens are consistently below 40% on a multi-turn session against the same codebase, something is wrong. Expected range is 40–90% depending on how varied your requests are.

If you hit zero cache read consistently, copy the Request ID from the chat header and contact support. Cursor has been issuing credit refunds for the overbilling period.

Comparing with Claude Code's Cache

Claude Code (Anthropic's CLI tool) has its own prompt caching via cache_control markers, but with a key structural difference: TTL.

Setting	Write cost	Read cost	TTL
Default	1.25× input	~10% of input	5 minutes
`ENABLE_PROMPT_CACHING_1H=1`	2.0× input	~10% of input	1 hour

The 5-minute default is brutal for any session where you read documentation, test code, or think between turns. The 1-hour option (available since Claude Code v2.1.108) adds to the write cost but eliminates repeated cache misses across the kind of natural pauses that happen in real work.

To enable it:

# ~/.zshrc or ~/.bashrc
export ENABLE_PROMPT_CACHING_1H=1

Verify with usage output during a session—look for ephemeral_1h_input_tokens in the log. If you only see ephemeral_5m_, the variable isn't being picked up.

Note: there were also TTL-related bugs in this period that forced resets to 5-minute behavior. Keep Claude Code at the latest version.

My Usage Data

I exported my own Cursor usage history and analyzed it. Here's what a month looks like across models (442 requests):

Model	Requests	Avg cost/request	Cache read ratio
Composer 2 Standard	73	$0.19	88.3%
Composer 2 Fast	25	$0.32	78.1%
Claude 4.6 Sonnet	212	$0.37	84.7%
Claude 4.6 Opus	93	$0.90	79.5%

The 88.3% cache read ratio on Standard is the headline. For an average request consuming ~390K tokens, 88% of those are cache reads at $0.20/1M rather than fresh input at $0.50/1M. Without that cache hit rate, the average cost per request would be ~$0.40 instead of $0.19.

The top Opus requests peaked at $4.25/request (3.9M total tokens, 3.8M of which were cache reads). Even with excellent cache ratios, Opus's higher base rates mean the same cache-heavy session costs 4–5× more than Composer 2 Standard.

The Actual Decision

Composer 2 is not "Claude but cheap." It's a purpose-built agent runtime that has traded general intelligence for deep coding capability and cost efficiency at the infrastructure level. The Standard/Fast split exists because long-horizon agentic tasks don't need millisecond response times—and charging for that latency premium on 10-turn refactoring sessions is wasteful.

The model choice that makes sense given this:

Default to Standard for any multi-file task where you'll have more than 3–4 turns
Switch to Fast for interactive chat where you're watching output incrementally
Use frontier models (Opus, Claude 4.7) only when Composer 2 hits a genuine capability ceiling—complex algorithmic reasoning, architecture decisions that span non-code domains

The cache makes Standard not just "slower Fast," but a qualitatively different operational mode: background processing with cost amortized over a long context window that grows cheaper the more you reuse it.

Why Software Isn’t Built for AI Agents

Gaurav Talesara — Sat, 02 May 2026 12:52:03 +0000

The next users of your software won’t be humans.
They’ll be agents.

And most software today is completely unprepared for that.

Right now, AI agents are:

Browsing websites
Filling forms
Clicking buttons
Navigating dashboards

That’s not scale. That’s a workaround.

We’re forcing machines to behave like humans—because our systems were never designed for anything else.

The Core Problem

Modern software is built around a simple assumption:

A human will be sitting in front of a screen.

That assumption drives everything:

UI-heavy workflows
Step-by-step interactions
Documentation meant to be read, not executed

But agents don’t need interfaces.
They need interfaces they can reason about and execute against programmatically.

Where Current Systems Break for Agents

Let’s break this down from a systems perspective.

1. UI-First Architecture

Most SaaS products expose functionality through:

Dashboards
Forms
Buttons

Agents interacting with these:

Rely on scraping or automation layers
Break when UI changes
Lack reliability

2. Non-Deterministic Outputs

Agents need:

Structured responses
Predictable schemas

Instead, they get:

HTML pages
Inconsistent API responses
Unstructured data

3. Human-Centric Authentication

Current flows:

OAuth screens
Email verification
CAPTCHA

These are friction points for agents trying to:

Discover tools
Authenticate
Execute tasks autonomously

4. Documentation Isn’t Machine-Readable

Docs today are:

Written for humans
Scattered across pages
Hard to parse programmatically

Agents need:

Structured capability descriptions
Executable contracts
Clear input/output expectations

APIs Alone Are Not the Answer

A common assumption is:

“We already have APIs, so we’re agent-ready.”

That’s not true.

APIs are:

Too generic
Often inconsistent
Not designed for autonomous decision-making

Agents need more than endpoints.

They need:

Action schemas (what can be done, not just how)
Deterministic contracts (guaranteed outputs)
Capability discovery (what tools exist and when to use them)

What “Agent-First Software” Actually Looks Like

If we design systems for agents as first-class users, the architecture changes.

1. Machine-Readable Interfaces

Instead of UI-first:

Structured APIs with strict schemas
Tool definitions with clear contracts
Standardized input/output formats

2. Programmatic Onboarding

Instead of:

Signup → verify → explore

Agents should:

Discover → authenticate → execute

This requires:

Auto-provisioned credentials
Machine-readable pricing/limits
Capability endpoints

3. Permissioned Execution

Agents need controlled autonomy:

Scoped access tokens
Role-based permissions
Execution boundaries

4. Deterministic Execution Layer

Every action should be:

Predictable
Retry-safe
Observable

5. Observability for Agents

Traditional logs aren’t enough.

We need:

Decision tracing
Tool-call lineage
Cost per execution
Latency breakdowns

A Practical Agent-System Architecture

A simplified flow looks like this:

Agent
  ↓
Planner (decides what to do)
  ↓
Tool Registry (what tools are available)
  ↓
Execution Layer (calls APIs/tools)
  ↓
Response Validator (ensures correctness)
  ↓
Memory (stores context + learnings)

Each layer is critical:

Planner → reasoning
Tool registry → discoverability
Execution → action
Validator → reliability
Memory → continuity

This is very different from traditional request-response systems.

Where the Opportunity Is

Most people today are focused on:

“How do we build better agents?”

But the bigger opportunity is:

“How do we build better systems for agents to operate on?”

Every major category is open:

CRM → agent-native workflows
Payments → programmable financial actions
Support → autonomous resolution systems
Analytics → queryable, structured insights

Not as add-ons.
But as core design principles.

What Most People Get Wrong

❌ “APIs are enough”

They’re not.
Agents need structured, reliable, discoverable systems.

❌ “Just add AI on top”

That creates brittle layers, not scalable systems.

❌ “Agents will replace software”

No.
Agents will consume software differently.

The Shift That’s Coming

We’re moving from:

Human-first software → to
Agent-first systems

This isn’t a feature upgrade.

It’s a paradigm shift in how software is designed and consumed.

Final Thought

The companies that win won’t be the ones with the smartest agents.

They’ll be the ones:

Agents prefer to use.

👋 If You’re Building in This Space

I’m currently working on:

Agent-based systems
Automation architectures
AI-native SaaS workflows

If you’re exploring similar problems or thinking about building agent-first products, I’d be interested to exchange ideas.

When Your Training Loss Is Lying to You Building a Tenacious-Specific Sales Outreach Benchmark Eyoel Nebiyu · May 2026

Eyoel Nebiyu — Sat, 02 May 2026 12:51:59 +0000

This post documents a real negative result: my trained model worked… but a well-written prompt worked better.

TL;DR

I built a 266-task evaluation benchmark for B2B sales-outreach agents — something existing benchmarks don’t measure well.

Then I trained a small preference-learning judge model using SimPO.

What happened surprised me:

Training accuracy → 100%
Held-out accuracy → 25%

Classic overfitting.

But the real lesson wasn’t about the model.

It was about the data.

After fixing dataset construction:

Held-out accuracy improved to 0.417 (Delta A +25pp)
A carefully prompted untrained model scored 0.833

👉 Conclusion:
At this scale, judging B2B sales tone is mostly a prompt-following problem, not a preference-learning problem.

Project Links
Dataset: https://huggingface.co/datasets/eyorata/tenacious_bench_v0.1
Judge Model: https://huggingface.co/eyorata/tenacious-judge-simpo-qwen25-3b
Code: https://github.com/eyorata/sales_evaluation_bench

Total experiment cost: $0.041

The Problem: Existing Benchmarks Miss Real Sales Failures

Benchmarks like τ²-Bench retail, MT-Bench, or AlpacaEval are excellent at evaluating:

tool use
reasoning
conversation flow

But they don’t measure what actually kills B2B deals.

The agent I wanted to evaluate had to:

interpret hiring signals (funding, layoffs, leadership changes)
segment prospects correctly
write grounded outreach emails
avoid over-promising capacity
respect opt-outs and booking rules

Retail benchmarks simply don’t test these behaviors.

Example real failures from earlier experiments:

Auto-booking meetings when prospects only said “let me check my calendar.”
Re-engaging after opt-out, risking brand damage.

Those failures cost real money — but no public benchmark grades them.

So I built one.

Designing the Benchmark

The rule I set early:

Every rubric must be machine-gradable.

No vague scoring like “sounds professional.”

Instead, tasks check things like:

banned phrases absent
at least one signal referenced
no unsupported commitments
tone markers satisfied
correct action class detected

Each task returns a numeric score between 0 and 1.

No humans needed during evaluation.

The Dataset

266 tasks across five generation modes:

Mode Why it exists
Programmatic generation deterministic coverage
Trace-derived tasks grounded realism
Multi-LLM synthesis harder edge cases
Hand-authored adversarial stress testing
Style-guide gold pairs real preference ground truth

Partitions:

Train — 50%
Dev — 30%
Held-out — 20%
Preventing Data Leakage

I enforced three contamination checks:

No shared 8-grams between train and held-out tasks
Embedding similarity threshold
Time-window filtering for public signals

Result: 0 contamination violations.

Why I Chose Preference Training (Path B)

Week 10 analysis showed the model could already write fluent emails.

The real problem was:

👉 it couldn’t judge its own output.

So instead of improving generation, I trained a judge model using SimPO.

Setup:

Algorithm: SimPO (reference-free preference learning)
Trainer: TRL CPOTrainer
Backbone: Qwen2.5-3B
LoRA fine-tuning
Hardware: free Colab T4
The First Run: Perfect Training, Terrible Reality

Training looked amazing:

loss dropped smoothly
train accuracy hit 1.00
reward margins increased

But evaluation stayed stuck:

Train accuracy: 1.00
Held-out accuracy: 0.25

This is the moment many ML projects go wrong.

The instinct is:

bigger model
more steps
different hyperparameters

I almost did that.

Instead, I read the data.

The Real Problem Was the Dataset

Training examples used templated synthetic emails:

“Thank you for your interest…”

Held-out examples were real style-guide drafts:

“You closed your $14M Series A in February…”

The model learned a useless shortcut:

👉 prefer one template phrase over another.

It wasn’t learning tone — it was learning templates.

The Fix

I didn’t retrain immediately.

I fixed the data.

Using a stronger model, I rewrote all training “chosen” examples into authentic Tenacious voice, enforcing:

five tone markers
banned phrase rules
grounded signals
evaluator score ≥ 0.7

Cost: $0.04

Same algorithm. Same setup.

Only the data changed.

The Honest Results
Metric v1 v2
Train accuracy 1.00 1.00
Held-out accuracy 0.25 0.417
Delta A vs baseline 0 +25pp
Prompt baseline — 0.833
Latency 258ms 417ms
Finding #1 — Training Helped

The trained judge beat the untrained backbone.

So the methodology worked.

Finding #2 — Prompting Won Anyway

A carefully designed rubric prompt on the same backbone scored:

0.833 accuracy

No training required.

The Real Lesson

At this scale:

B2B tone judgment is a prompt-following problem more than a preference-learning problem.

The base model already understands tone.

It just needs explicit rules.

This is a legitimate negative result — and an important one.

About Delta C

I didn’t claim cross-benchmark improvement.

The model wasn’t trained on retail tasks, so comparing against τ²-Bench retail would be misleading.

Sometimes the honest result is:

improvement is domain-specific.

Limitations (Important)

Only 12 held-out tasks currently contain preference pairs.

That means:

wide confidence intervals
small-n uncertainty

This limitation is documented rather than hidden.

What’s Next
Dataset v0.2
expand preference slice from 12 → 30 tasks
clarify rubric ambiguity detected during calibration
Model v0.2
Qwen2.5-7B SimPO run
same training recipe
Future Ablation

Compare against a strong commercial model using only prompting.

The Big Engineering Lesson

The hardest decision wasn’t choosing the algorithm.

It was not retraining when training metrics looked perfect.

Clean training loss often means:

👉 the model learned something easy, not something useful.

Fixing the data cost $0.04.

Blindly scaling compute would have cost days.

If Your Training Loss Looks Too Good…

It probably is.

Check the data before blaming the model.

Acknowledgements

Work completed within the 10Academy TRP1 program using:

TRL + SimPO
Unsloth QLoRA training
Google Colab T4
OpenRouter multi-LLM routing

@dataset{tenacious_bench_v01_2026,
title = {Tenacious-Bench},
author = {Nebiyu, Eyoel},
year = 2026,
version = {0.1},
license = {CC-BY-4.0}
}

I built a DuckDB extension to handle chemistry data without pandas or RDKit

nk_Enuke — Sat, 02 May 2026 12:50:36 +0000

Idea

While reproducing top solutions of a chemistry data competition, I started building a DuckDB community extension for handling chemistry data directly in SQL.

What it can do

Parse SMILES, InChI, PDB and other chemistry formats directly — no pandas, no RDKit on the side
Plug into DuckDB's native CSV/Parquet/Iceberg/S3/HTTP readers, so ingestion + light preprocessing happens in one query

Background

What is chemistry data, anyway? One of the canonical forms is SMILES, a notation that encodes a molecular structure as a plain string.

The standard library for reading and processing SMILES is RDKit. For example, ethanol is CCO in SMILES, and RDKit will give you the molecular formula C2H6O from it.

RDKit doesn't stop there — molecular weight, fingerprints, descriptors, substructure search, and so on. It's basically the must-have library for chemistry data work. (Internally, the algorithms come from a bunch of different papers...)

So you might say: do we even need a new extension? In practice though, I kept hitting these:

Doesn't always work cleanly on Google Colab (often needs a runtime restart)
pandas version conflicts
To export results, you usually have to bounce through pandas anyway, or pull in yet another tool depending on the feature you want

What I built

So, here's a DuckDB extension that addresses these.

ducksmiles

https://duckdb.org/community_extensions/extensions/ducksmiles

I implemented a mix of features RDKit covers and a few that are awkward with RDKit alone.

Compute molecular formula / weight from a SMILES string and write back to CSV → The most basic chemistry preprocessing flow, in a single SQL line
Decompose an InChI string into its formula / connection / hydrogen / charge / stereo layers, and compare two InChIs at the skeleton level → With RDKit you have to round-trip through a Mol object; ducksmiles pulls the layers straight from the string
Convert SMILES ⇄ SELFIES (a notation that's easier to use for ML models) → Normally you'd need a separate selfies package; this is built in
Aggregate atom / chain / residue counts from PDB / CIF / XYZ (3D structure files) with SQL → Get metadata from heavy structure files without ever opening them in code
Return NULL instead of throwing on invalid SMILES or structures → A million-row batch won't blow up because of one malformed row

Try it out

I'll use two public datasets — DeepChem ESOL CSV and RCSB PDB — and paste the actual CLI output for each of the five capabilities above.

duckdb

INSTALL ducksmiles FROM community;
LOAD ducksmiles;

1. SMILES → formula / weight

SELECT smiles, mol_formula(smiles) AS formula, mol_weight(smiles) AS weight
FROM read_csv_auto('https://deepchemdata.s3-us-west-1.amazonaws.com/datasets/delaney-processed.csv')
LIMIT 5;

┌────────────────────────────────────────────────────────┬───────────┬─────────┐
│                         smiles                         │  formula  │ weight  │
├────────────────────────────────────────────────────────┼───────────┼─────────┤
│ OCC3OC(OCC2OC(OC(C#N)c1ccccc1)C(O)C(O)C2O)C(O)C(O)C3O  │ NULL      │ NULL    │
│ Cc1occc1C(=O)Nc2ccccc2                                 │ C12H11NO2 │ 201.225 │
│ CC(C)=CCCC(C)=CC(=O)                                   │ C10H16O   │ 152.237 │
│ c1ccc2c(c1)ccc3c2ccc4c5ccccc5ccc43                     │ C22H14    │ 278.354 │
│ c1ccsc1                                                │ C4H4S     │ 84.136  │
└────────────────────────────────────────────────────────┴───────────┴─────────┘

The public CSV URL goes straight into read_csv_auto, and you get formulas and weights right there. The first row's complex SMILES returns NULL rather than throwing.

2. Decompose an InChI into its layers

SELECT
  name,
  inchi_formula(inchi) AS formula,
  inchi_connections(inchi) AS connections,
  inchi_hydrogens(inchi) AS hydrogens
FROM (VALUES
  ('Ethanol',  'InChI=1S/C2H6O/c1-2-3/h3H,2H2,1H3'),
  ('Caffeine', 'InChI=1S/C8H10N4O2/c1-10-4-9-6-5(10)7(13)12(3)8(14)11(6)2/h4H,1-3H3')
) AS t(name, inchi);

┌──────────┬───────────┬───────────────────────────────────────┬────────────┐
│   name   │  formula  │              connections              │ hydrogens  │
├──────────┼───────────┼───────────────────────────────────────┼────────────┤
│ Ethanol  │ C2H6O     │ 1-2-3                                 │ 3H,2H2,1H3 │
│ Caffeine │ C8H10N4O2 │ 1-10-4-9-6-5(10)7(13)12(3)8(14)11(6)2 │ 4H,1-3H3   │
└──────────┴───────────┴───────────────────────────────────────┴────────────┘

InChI is a notation that bundles atom connectivity, hydrogen positions, and other facets into a single string, split across labeled sections. For example, ethanol looks like this:

InChI=1S/C2H6O/c1-2-3/h3H,2H2,1H3
        └─────┘ └────┘ └────────┘
        formula  conn.    hydrogens
       inchi_formula  inchi_connections  inchi_hydrogens

Normally you'd round-trip through RDKit's Mol object to extract pieces. With ducksmiles, you pull the section you want straight from the string. The query result above (C2H6O / 1-2-3 / 3H,2H2,1H3) is exactly the substring of those layers in the original InChI.

3. SMILES ⇄ SELFIES roundtrip

Pulling some short SMILES out of ESOL and running SMILES → SELFIES → SMILES:

SELECT
  smiles,
  smiles_to_selfies(smiles) AS selfies,
  selfies_to_smiles(smiles_to_selfies(smiles)) AS roundtrip
FROM read_csv_auto('https://deepchemdata.s3-us-west-1.amazonaws.com/datasets/delaney-processed.csv')
WHERE LENGTH(smiles) < 12
LIMIT 5;

┌───────────┬─────────────────────────────────────────┬───────────┐
│  smiles   │                 selfies                 │ roundtrip │
├───────────┼─────────────────────────────────────────┼───────────┤
│ c1ccsc1   │ [c][Ring1][C][c][c][s][c][Ring1][C]     │ cccsc     │
│ O=C1CCCN1 │ [O][=C][Ring1][C][C][C][C][N][Ring1][C] │ O=CCCCN   │
│ CCCC=C    │ [C][C][C][C][=C]                        │ CCCC=C    │
│ CC(C)Cl   │ [C][C][Branch1][C][C][Cl]               │ CC(C)Cl   │
│ CCC(C)CO  │ [C][C][C][Branch1][C][C][C][O]          │ CCC(C)CO  │
└───────────┴─────────────────────────────────────────┴───────────┘

Both directions of the conversion run inside DuckDB. Normally you'd need a separate Python selfies package on the side.

4. Metadata from PDB structure files

read_text accepts HTTPS URLs and arrays directly, so you can pull three PDB files straight from RCSB and aggregate them in one go:

INSTALL httpfs; LOAD httpfs;

SELECT
  filename,
  structure_atom_count(content)    AS atoms,
  structure_chain_count(content)   AS chains,
  structure_residue_count(content) AS residues,
  structure_model_count(content)   AS models
FROM read_text([
  'https://files.rcsb.org/download/1AKE.pdb',
  'https://files.rcsb.org/download/1CRN.pdb',
  'https://files.rcsb.org/download/4HHB.pdb'
]);

┌──────────────────────────────────────────┬───────┬────────┬──────────┬────────┐
│                 filename                 │ atoms │ chains │ residues │ models │
├──────────────────────────────────────────┼───────┼────────┼──────────┼────────┤
│ https://files.rcsb.org/download/1AKE.pdb │ 3816  │ 2      │ 428      │ 1      │
│ https://files.rcsb.org/download/1CRN.pdb │ 327   │ 1      │ 46       │ 1      │
│ https://files.rcsb.org/download/4HHB.pdb │ 4779  │ 4      │ 574      │ 1      │
└──────────────────────────────────────────┴───────┴────────┴──────────┴────────┘

read_text returns the file content as a content column, so you just feed it to the structure_* functions. You also get filename for free, which makes it easy to keep track of the original file when you scale this to thousands.

5. Bad input returns NULL instead of crashing

SELECT
  smiles,
  mol_is_valid(smiles) AS valid,
  mol_formula(smiles) AS formula,
  mol_weight(smiles) AS weight
FROM (VALUES
  ('CCO'),
  ('not_a_smiles'),
  ('c1ccccc1'),
  (''),
  ('CC(=O)O')
) AS t(smiles);

┌──────────────┬───────┬─────────┬────────┐
│    smiles    │ valid │ formula │ weight │
├──────────────┼───────┼─────────┼────────┤
│ CCO          │ true  │ C2H6O   │ 46.069 │
│ not_a_smiles │ false │ NULL    │ NULL   │
│ c1ccccc1     │ true  │ C6H6    │ 78.114 │
│              │ false │ NULL    │ NULL   │
│ CC(=O)O      │ true  │ C2H4O2  │ 60.052 │
└──────────────┴───────┴─────────┴────────┘

Even with malformed SMILES or empty strings mixed in, those rows just become NULL — the query keeps going. It's built for batch.

Closing thoughts

One thing that struck me while working with chemistry data is just how many formats there are.

SMILES, InChI, SDF... each has its own format, and each tends to want its own dedicated tool.

On top of that, RDKit itself has a huge surface — its "descriptors" alone come in around 200 varieties, each backed by different papers.

What I want ducksmiles to grow into is a single tool that absorbs those plumbing and preprocessing concerns, so you can move faster without juggling toolchains. There's a lot to learn from the prior art, and I plan to chip away at it over time.

Also — DuckDB itself is a general-purpose engine, so it can't cover every domain's specific needs. That's exactly what community extensions are for, and the bar to author one is surprisingly low. If you have a domain pain point that DuckDB doesn't quite cover, please give it a try.

Building WeaveLLM: Why .NET Deserves a Better then LangChain

Harshil Shah — Sat, 02 May 2026 12:49:31 +0000

Building WeaveLLM: Why .NET Deserves a Better LangChain

Tags: dotnet, ai, csharp, llm
Cover image: architecture diagram of WeaveLLM pipeline

Introduction

Here's a thing I keep running into: .NET developers building serious AI features, and the ecosystem basically telling them to just use Python. LangChain, LlamaIndex, DSPy — every major orchestration framework is Python-first. .NET is an afterthought, if it shows up at all.

But C# developers aren't waiting around. They're shipping customer support bots, RAG pipelines, code-review agents — right now, in production. They're just doing it by calling OpenAI's REST API by hand, copy-pasting retry logic into every service class, and hoping nothing throws in an async chain at 2 AM.

LangChain does have a .NET port. I've used it. It's incomplete, the types don't map cleanly to .NET idioms, and it leans on exceptions as its main error-handling strategy — which is genuinely painful to compose in async code. The deeper issue is that LangChain was designed around Python's dynamic type system. Porting it to C# without rethinking the API from scratch gives you a framework that fights the language the entire time.

So I built WeaveLLM instead. Started as a hobby project, turned into something I actually want to use at work. It's a .NET 8 AI orchestration library designed specifically for C# — railway-oriented results, IAsyncEnumerable<T> streaming, an ASP.NET-style middleware pipeline, and fully generic chains that catch type mismatches at compile time rather than in a 3 AM Slack alert. Here are the four decisions that shaped it.

Design Decision 1: `ChainResult<T>` Over Exceptions

Let me describe a problem you've almost certainly hit. You call an LLM, it fails — rate limited, timed out, bad input, provider down — and now you need to handle that failure somewhere. In an exception-based framework, that means try/catch at every composition point. Stack a few chains together and you've got nested try/catch blocks all the way down, each one trying to figure out which exception type maps to which recovery strategy.

It's not that exceptions are wrong. It's that they're invisible. A method signature like Task<string> tells you nothing about whether it can fail and how.

WeaveLLM uses railway-oriented programming. Every chain execution returns ChainResult<T> — a result type where errors are values you work with, not surprises that unwind your stack.

// Errors are data, never thrown
public sealed class ChainResult<T>
{
    public bool IsSuccess { get; }
    public bool IsFailure => !IsSuccess;
    public T? Value { get; }
    public ChainError? Error { get; }
    public TokenUsage? TokenUsage { get; }
    public TimeSpan Duration { get; }
    public IReadOnlyDictionary<string, object> Metadata { get; }

    public static ChainResult<T> Success(T value, TokenUsage? usage = null) { ... }
    public static ChainResult<T> Failure(ChainError error) { ... }
    public static ChainResult<T> Failure(string message, string? code = null) { ... }

    // Projects success value to new type; failure passes through unchanged
    public ChainResult<TNext> Map<TNext>(Func<T, TNext> transform) { ... }

    // Destructure into (isSuccess, value, error)
    public void Deconstruct(out bool isSuccess, out T? value, out ChainError? error) { ... }
}

Errors come with structure too, not just a message string:

public record ChainError(string Message, string Code, Exception? InnerException = null)
{
    public static ChainError Timeout(string msg) => new(msg, "Timeout");
    public static ChainError RateLimited(string msg) => new(msg, "RateLimited");
    public static ChainError InvalidInput(string msg) => new(msg, "InvalidInput");
    public static ChainError ProviderError(string msg, Exception? ex = null)
        => new(msg, "ProviderError", ex);
}

Here's what that looks like at the call site, compared to the try/catch version:

// The old way — try/catch at every layer
try
{
    var response = await chain.ExecuteAsync(input);
    return response.Text;
}
catch (RateLimitException) { /* retry */ }
catch (TimeoutException)   { /* fallback */ }
catch (Exception ex)       { /* log */ throw; }

// WeaveLLM — errors are values you can switch on
var result = await chain.ExecuteAsync(input, context);

var (isSuccess, value, error) = result;
if (!isSuccess)
{
    return error!.Code switch
    {
        "RateLimited" => await fallbackChain.ExecuteAsync(input, context),
        "Timeout"     => ChainResult<string>.Failure(error),
        _             => ChainResult<string>.Failure(error)
    };
}

return result.Map(v => v.ToUpperInvariant()); // transforms success, ignores failure

ChainResult<T> also bundles TokenUsage and a Metadata dictionary that middleware layers write into without breaking the type contract. If you've ever used F# or Rust, this is the same railway pattern — errors short-circuit, successes flow through, and Map() lets you transform values without having to unwrap and re-wrap manually.

Approach	Error handling	Composability	Observability built-in
Raw exceptions	try/catch at every level	Hard to chain	None
LangChain.NET	Mix of exceptions and nulls	Inconsistent	None
WeaveLLM	Values (ChainResult<T>)	Monadic Map/Deconstruct	TokenUsage + Metadata

Design Decision 2: `IAsyncEnumerable<T>` for Streaming

Streaming isn't a polish feature — it's the thing users actually notice. A response that starts rendering in 200ms feels fast, even if the total generation takes 8 seconds. A response that hangs for 8 seconds and then dumps a wall of text feels broken, even if the numbers are the same.

Python gets async generators for this. They work great in Python. In C#, the equivalent is IAsyncEnumerable<T>, which has been in .NET since Core 3.0 and plugs directly into await foreach, LINQ, and ASP.NET Core's response pipeline. WeaveLLM makes it part of the core contract, not an optional add-on.

Every chain has two execution paths: a request/response ExecuteAsync and a token-by-token StreamAsync:

public interface IChain<TInput, TOutput>
{
    string Name { get; }

    Task<ChainResult<TOutput>> ExecuteAsync(
        TInput input,
        ChainContext context,
        CancellationToken cancellationToken = default);

    IAsyncEnumerable<TOutput> StreamAsync(
        TInput input,
        ChainContext context,
        CancellationToken cancellationToken = default);
}

The provider layer exposes the same interface. Here's what consuming it looks like:

public interface IStreamingChatModel : IChatModel
{
    IAsyncEnumerable<string> StreamChatAsync(
        IReadOnlyList<ChatMessage> messages,
        ChatOptions? options = null,
        CancellationToken cancellationToken = default);
}

// Each token prints as it arrives
await foreach (var token in model.StreamChatAsync(messages, cancellationToken: ct))
{
    Console.Write(token);
}

And in ASP.NET Core, wiring up a streaming endpoint with Server-Sent Events is about 12 lines:

app.MapGet("/stream", async (HttpContext http, IChain<string, string> chain) =>
{
    http.Response.ContentType = "text/event-stream";
    var context = new ChainContext();

    await foreach (var token in chain.StreamAsync("Tell me a story", context))
    {
        await http.Response.WriteAsync($"data: {token}\n\n");
        await http.Response.Body.FlushAsync();
    }
});

Compare that to callback-based streaming, which is what a lot of .NET AI libraries still use:

// Callback-based — no backpressure, no real cancellation support,
// can't await async work per-token
await chain.StreamAsync(input, onToken: token =>
{
    Console.Write(token);
});

With IAsyncEnumerable<T> you get CancellationToken integration automatically (the consumer cancels mid-stream and the producer stops), full LINQ support via System.Linq.Async, and no adapter layer between your chain and the framework. It's just the language doing what it already does well.

Streaming model	Backpressure	CancellationToken	LINQ composable	ASP.NET SSE
Callbacks	Manual	Awkward	No	Custom plumbing
Events	No	No	No	Custom plumbing
IAsyncEnumerable	Built-in	Built-in	Yes	Native

Design Decision 3: The Middleware Pipeline

If you've built anything in ASP.NET Core, you already know how middleware works: components that wrap a request, can inspect or modify it, can short-circuit or pass it through, and compose in a predictable order. Every .NET developer has this mental model. It made sense to borrow it directly for LLM chains.

The interface is deliberately close to ASP.NET's RequestDelegate shape:

public delegate Task<ChainResult<TOutput>> ChainDelegate<TInput, TOutput>(
    TInput input,
    ChainContext context,
    CancellationToken cancellationToken);

public interface IChainMiddleware<TInput, TOutput>
{
    Task<ChainResult<TOutput>> InvokeAsync(
        TInput input,
        ChainContext context,
        ChainDelegate<TInput, TOutput> next,
        CancellationToken cancellationToken = default);
}

next is everything downstream. Call it to continue. Skip it to short-circuit — a cache hit, a circuit breaker tripping. Call it and then do something with the result — tracing, cost tracking, PII scrubbing. WeaveLLM ships six middleware implementations out of the box:

services.AddWeaveLLM()
    .AddOpenAI(o => o.ApiKey = config["OpenAI:ApiKey"])
    .AddReActAgent(maxSteps: 5);

var chain = myLlmChain
    .WithMiddleware(new RetryMiddleware(maxRetries: 3, backoffSeconds: 1.5))
    .WithMiddleware(new CacheMiddleware(ttl: TimeSpan.FromMinutes(10)))
    .WithMiddleware(new RateLimitingMiddleware(requestsPerMinute: 60))
    .WithMiddleware(new TracingMiddleware(activitySource))
    .WithMiddleware(new CostMiddleware(pricing))
    .WithMiddleware(new PiiScrubbingMiddleware());

Writing your own is implementing one method. Here's a logging middleware, complete:

public sealed class LoggingMiddleware<TInput, TOutput>
    : IChainMiddleware<TInput, TOutput>
{
    private readonly ILogger _logger;
    public LoggingMiddleware(ILogger logger) => _logger = logger;

    public async Task<ChainResult<TOutput>> InvokeAsync(
        TInput input,
        ChainContext context,
        ChainDelegate<TInput, TOutput> next,
        CancellationToken cancellationToken = default)
    {
        _logger.LogInformation("Chain {Name} starting", context.ChainName);
        var result = await next(input, context, cancellationToken);
        _logger.LogInformation("Chain {Name} finished: {Status} in {Duration}ms",
            context.ChainName,
            result.IsSuccess ? "OK" : result.Error!.Code,
            result.Duration.TotalMilliseconds);
        return result;
    }
}

LangChain's version of this is "callbacks" — a grab-bag of optional hooks (on_llm_start, on_llm_end, on_chain_error) registered globally and fired via reflection. They can't short-circuit. They can't replace the result. They don't compose with each other in any meaningful way. It's a notification system dressed up as a pipeline.

WeaveLLM's middleware is an actual pipeline. Each component decides whether to call next, what to do with the result, and whether to replace or propagate. That's the difference between observability you can build on and hooks you can only listen to.

Design Decision 4: Generic Chains with Compile-Time Type Safety

LangChain chains are stringly typed by default. Inputs and outputs are usually Dictionary<string, string> and the framework resolves what goes where at runtime. In Python, that's fine — you've got a REPL, you find the bug fast. In C#, you find it in production when a downstream chain reaches for a key the upstream chain forgot to set.

It's an unforced error. The type system is right there.

IChain<TInput, TOutput> makes the contract explicit:

public interface IChain<TInput, TOutput>
{
    string Name { get; }
    Task<ChainResult<TOutput>> ExecuteAsync(TInput input, ChainContext context,
        CancellationToken cancellationToken = default);
    IAsyncEnumerable<TOutput> StreamAsync(TInput input, ChainContext context,
        CancellationToken cancellationToken = default);
}

// Connectable variant for fluent Pipe() composition
public interface IConnectableChain<TInput, TOutput> : IChain<TInput, TOutput>
{
    IConnectableChain<TInput, TNext> Pipe<TNext>(IChain<TOutput, TNext> next);
    IConnectableChain<TInput, TOutput> WithMiddleware(IChainMiddleware<TInput, TOutput> middleware);
}

Pipe<TNext>() enforces that the output type of the left chain matches the input type of the right one — at compile time. Not at test time, not in staging. At dotnet build.

record UserQuery(string Text);
record SearchResults(IReadOnlyList<string> Chunks);
record FinalAnswer(string Text, decimal ConfidenceScore);

// This compiles — types line up
IConnectableChain<UserQuery, FinalAnswer> ragPipeline =
    retrievalChain         // IChain<UserQuery, SearchResults>
        .Pipe(rerankerChain)   // IChain<SearchResults, SearchResults>
        .Pipe(generatorChain); // IChain<SearchResults, FinalAnswer>

// This doesn't compile — SearchResults != UserQuery, caught immediately
// retrievalChain.Pipe(generatorChain); // CS ERROR

ComposedChain also handles failure propagation: if the first chain returns a failure, the second never runs and the error forwards unchanged. No null checks, no manual short-circuiting.

The practical payoff shows up when you're actually using the results:

var result = await ragPipeline.ExecuteAsync(
    new UserQuery("What is the WeaveLLM license?"),
    new ChainContext { SessionId = "user-123" });

if (result.IsSuccess)
{
    Console.WriteLine($"Answer: {result.Value!.Text}");
    Console.WriteLine($"Confidence: {result.Value.ConfidenceScore:P0}");
    Console.WriteLine($"Cost: ${result.TokenUsage?.EstimatedCostUsd:F4}");
}

Full IntelliSense, no casting, no as checks. If you rename a property on FinalAnswer, the compiler tells you everywhere it breaks.

Type safety	LangChain (Python)	LangChain.NET	WeaveLLM
Input/output types	Dynamic dict	Dynamic dict	Generic `IChain<TIn, TOut>`
Mismatched pipes caught	Runtime	Runtime	Compile time
IDE completion on results	None	Partial	Full IntelliSense
Refactor safety	None	None	Compiler-enforced

What Ships in v0.1.0-alpha

WeaveLLM v0.1.0-alpha is on NuGet across five packages:

dotnet add package WeaveLLM.Core
dotnet add package WeaveLLM.Providers
dotnet add package WeaveLLM.Memory
dotnet add package WeaveLLM.Observability
dotnet add package WeaveLLM.Extensions.DependencyInjection

Providers — four, all production-tested:

OpenAI (gpt-4o, embeddings, streaming)
Anthropic (claude-sonnet, streaming)
Ollama (local inference, embeddings — no API key needed)
HuggingFace (Inference API, embeddings)

All share IChatModel. Swap provider with one line.

Agents — three patterns:

ReActAgent — Thought → Action → Observation loop until Final Answer
PlanAndExecuteAgent — separate planning and execution phases for complex tasks
AgentGraph<TState> — state machine for multi-agent workflows with typed shared state and conditional branching

Memory and RAG — full pipeline:

IMemoryStore with in-memory, Qdrant, and Postgres (pgvector) backends
DefaultRagPipeline with recursive text splitting, hybrid BM25 + vector search, and Reciprocal Rank Fusion
Document loaders for plain text, Markdown, and directories

Middleware — six built-in:
Retry, caching, rate-limiting, OpenTelemetry tracing, per-request cost estimation, and PII scrubbing.

Observability — baked in, not bolted on:
OpenTelemetry tracing and metrics via the WeaveLLM ActivitySource and Meter. Per-request token usage and estimated USD cost tracked across all providers.

Where It's Going

v0.2.0-alpha (next 6–8 weeks):

Azure OpenAI provider
Multi-modal input (image + text messages)
Streaming agents — IAsyncEnumerable<AgentStep> for real-time reasoning step visibility
Redis memory backend
Structured output support

v1.0.0 — Q4 2026:

Frozen public API with full semver guarantee
Docs site with guides, API reference, and runnable samples
Benchmark suite against LangChain Python — qualitative claims become numbers

Honest Alpha Warning

This is a hobby project that got serious. The core abstractions are stable and I won't break them before v1.0. All four providers are tested and working. Some edge cases are still being hardened and breaking changes are possible in non-core areas before v1.0.

I built this because I was frustrated, not because I had a product roadmap. If you've hit the same frustrations with .NET LLM tooling, that's the target audience — and the best time to shape what v1.0 looks like is right now.

If you want to contribute, good-first-issue labels are a good starting point: adding provider adapters, writing integration tests against real APIs, extending the middleware library. Adding a new provider is just implementing IChatModel — the middleware, streaming, and type-safety machinery comes for free.

Licence

MIT. Use it, fork it, ship it in your own projects. No credit needed.

Copyright (c) 2026 WeaveLLM

The railway result, the async stream, the ASP.NET-style middleware, the generic chain — none of these are Python idioms with a C# skin on top. They're what this kind of library looks like when it starts from C# instead of ending there.

Source code, samples, and NuGet links: github.com/harshil-inspire2/WeaveLLM

Keywords: .NET AI, LangChain alternative, AI orchestration, C# LLM, dotnet AI framework, IAsyncEnumerable streaming, railway-oriented programming, ASP.NET middleware pattern

Além do Código: O Guia Estratégico de Comunicação para Devs Brasileiros no Mercado Americano

Kyousuke Natsume — Sat, 02 May 2026 12:46:59 +0000

Para conquistar o mercado norte-americano de tecnologia, não basta apenas ser um gênio do código. O Brasil se tornou um polo de nearshoring devido à competência técnica e fuso horário favorável, mas o que realmente sustenta essas parcerias é a confiança corporativa

Se você quer parar de ser visto como "apenas um executor" e se tornar um parceiro estratégico, aqui está o guia direto ao ponto para adaptar sua comunicação e comportamento ao estilo dos EUA.

1. Confiança: Esqueça o Cafezinho, Foque no Código

No Brasil, confiamos em quem gostamos (confiança afetiva). Nos EUA, eles confiam em quem entrega (confiança cognitiva).

A lógica americana: "Se o trabalho é bom, a relação é segura".
A adaptação: Priorize marcos técnicos e prazos antes de tentar criar um vínculo pessoal. Deixe o small talk para depois que a entrega estiver garantida.

2. Comunicação: O Fim das "Entrelinhas"

O Brasil é uma cultura de alto contexto (muitas nuances e mensagens implícitas). Os EUA são o oposto: baixo contexto.

Regra de ouro: A responsabilidade de ser entendido é sua, não de quem ouve.
Seja literal: Diga exatamente o que quer dizer. Evite ambiguidades.
Documente TUDO: Acordos verbais não bastam. Envie um e-mail de resumo após cada reunião com decisões, responsáveis e prazos. Isso sinaliza estrutura e profissionalismo.

3. Postura: De "Yes-Man" a Consultor

A hierarquia americana é igualitária. O silêncio em uma reunião não é visto como respeito, mas como falta de iniciativa ou desengajamento.

Ownership: Assuma a responsabilidade pelas tarefas. Não apenas reporte problemas, sugira soluções.
Questione: Se um requisito é tecnicamente inviável, fale! O cliente americano paga pela sua expertise, não por alguém que apenas diz "sim" para tudo.

4. A Santidade do Tempo

Para o americano, "tempo é dinheiro" e pontualidade é um indicador direto de confiabilidade.

2 minutos antes: Entre nas chamadas de vídeo antes do horário.
Previsibilidade: Se vai atrasar um entregável, avise com antecedência (e não no dia do prazo), apresentando uma nova data e o motivo técnico.

5. Dicionário de Sobrevivência: O Perigo do "I'll Try"

Muitas vezes, a tradução literal destrói sua credibilidade. Confira a troca de mindset:

Em vez de dizer... (Baixa Confiança)	Diga isto... (Alta Confiança)	Por que funciona?
"I'll try to have it by Friday."	"I will deliver this by Friday."	Elimina a dúvida e assume compromisso.
"I think we can solve this."	"Based on my analysis, we will implement X."	Troca o "acho" por evidência e ação.
"Maybe we should consider X?"	"I recommend X because it improves scalability by Y%."	Te posiciona como consultor especialista.
"I'm not sure, let me check."	"I will verify the docs and answer by 2 PM."	Fornece um prazo claro para a resolução.

6. Transparência Radical em Crises

Quando um bug crítico aparece, o instinto brasileiro é resolver antes de contar. Para o americano, esse silêncio parece incompetência.

Reporte imediatamente: O cliente prefere saber do problema cedo.
RCA (Root Cause Analysis): Use dados técnicos. Explique a causa raiz e o plano de mitigação.
Fale a língua deles: Use termos como "débito técnico", "trade-offs" e "escalabilidade" para justificar decisões.

TL;DR (Resumo para o dev ocupado):

Para ser respeitado nos EUA: seja pontual, seja explícito, documente suas decisões e trate o cliente como um parceiro igual, não como um chefe inquestionável.

A confiança não é algo que se pede; é algo que se demonstra na consistência das suas ações.

📚 Referências e Leituras Recomendadas

Para quem deseja se aprofundar, recomendo fortemente as fontes que serviram de base para este guia:

The Culture Map (Erin Meyer) – A bíblia para entender a diferença entre confiança cognitiva e afetiva.
- Building Trust Across Cultures - Erin Meyer
Teoria de Contexto Cultural (Edward T. Hall) – Essencial para entender a transição do "Alto Contexto" brasileiro para o "Baixo Contexto" americano.
- High-context and low-context cultures - Wikipedia
Nearshoring no Brasil (Relatórios de Mercado) – Por que o Brasil é o parceiro estratégico ideal para os EUA.
- Why Brazil is a top destination for software development

Sneaky version control trick

Aaron Maxwell — Sat, 02 May 2026 12:45:00 +0000

I was writing a program to process some CSV data, exported from a vendor. And it has a date-time column in some creative, funky format.

To help with ingesting this into a Pandas dataframe, I wrote a converter function: it takes that string, and returns a Python datetime object. Simple, right?

But you know, this is a PERFECT place to write a unit test. And I decided to use Pytest, starting with this simple test:

from datetime import datetime
from myprog import parse_vendor_datetime

def test_parse_vendor_datetime():
    actual = parse_vendor_datetime('12/25/38 1:14am EST')
    expected = datetime(2038, 12, 25, 1, 14)
    assert expected == actual

I run the test, and it fails, like it should. Then I write parse_vendor_datetime(), and the test passes. Great!

Now, what no one ever talks about is how TDD works with version control. The secret is that there's actually a really productive way to do it.

Because after I check this test-passing code into version control, in my private branch... the next thing I do is run my program on some real data. And I find it doesn't handle time zones quite right.

Okay... so here's what I do. I get an example of the problematic data, and add to my test function:

def test_parse_vendor_datetime():
    actual = parse_vendor_datetime('12/25/38 1:14am EST')
    expected = datetime(2038, 12, 25, 1, 14)
    assert expected == actual

    actual = parse_vendor_datetime('08/17/38 11:05pm EDT')
    expected = datetime(2038, 8, 17, 11, 5)
    assert expected == actual

I run it, and verify it fails like it should. And I check THAT into version control - again, in my private branch. Because when I have a correctly failing test for a bug, that's progress. Even if that test isn't passing yet.

But it bugs me that this code is repetitive. Doesn't it bug you? Ugh. Makes my skin crawl, just looking at it.

So I refactor it, to use something Pytest calls "parametrized tests":

@pytest.mark.parametrize(
    'dt_str,expected', [
    ('12/25/38 1:14am EST', datetime(2038, 12, 25, 1, 14)),
    ('08/17/38 11:05pm EDT', datetime(2038, 8, 17, 11, 5)),
    ])
def test_parse_vendor_datetime(dt_str, expected):
    actual = parse_vendor_datetime(dt_str)
    assert expected == actual

See how the test code is not repetitive anymore? Even if you don't now what this "parametrize()" thing is, because I haven't explained it, you still understand this is an improvement. If I need to change something, or add another test case, I only need to change the code in one place.

So now, I check THIS into version control. The test is still failing. But changing the code to be less repetitive - more maintainable - is still forward progress, and worthy of checkpointing.

And: Because I had checked in the code before it too, if I mess up the test somehow, I can always roll back to the point it was correct.

What's fascinating:

When you build on this process, and add a few more ingredients... there's a COGNITIVE benefit.

It's potent. You can actually get into a state of flow very easily. In a way that's easy to maintain, and to keep your focus, and become extremely productive.

Having a blast, as you continue cranking out code. Riding that wave for as long as you want. It comes out of how you use version control along with writing automated tests, and doing test-driven development.

If you liked this, you will enjoy the Powerful Python Newsletter.

Scalar Setup ASP.NET Core Web API

Sharad Aade — Sat, 02 May 2026 12:44:34 +0000

Step - 1
Install NuGet Package
Step - 2
Add Code in - Properties/launchSettings.json

"launchBrowser": true, "launchUrl": "scalar",

Step - 3 Add Code in Program.cs file

if (app.Environment.IsDevelopment()) { app.MapOpenApi(); app.MapScalarApiReference(); }

Step - 4 Run the project

Crypto Forem

Anonymous Membership Proofs on Midnight: Building Privacy-Preserving Allowlists

Anonymous Membership Proofs on Midnight: Building Privacy-Preserving Allowlists

Why Merkle Trees for Allowlists?

The Compact Contract

Witnesses (Secret Inputs)

Recomputing the Merkle Path

Checking Membership

Admin Root Management

The TypeScript Tooling

Sparse Merkle Tree Implementation

The Complete Flow

Step 1: Admin Sets Up the Contract

Step 2: Add Members Off-Chain

Step 3: Push Root On-Chain

Step 4: Member Generates and Submits Proof

Edge Cases and Gotchas

1. Zero Hash Collisions

2. Context Binding

3. Tree Capacity Planning

Testing

What's Next?

Building an AI-Powered Identity Manager

What I Built

Demo

My Experience

How React Works (Part 5)? The React Lifecycle From the Inside: When Things Actually Run

The React Lifecycle From the Inside: When Things Actually Run

A Puzzle Most React Developers Get Wrong

The Three Phases of a React Render

What useEffect Actually Is

The Cleanup: Why It Runs Before the Next Effect

useLayoutEffect: The Synchronous Version

The "After Paint" Rule Has an Exception

The Dependency Array: What It Actually Controls

The Full Lifecycle in One Timeline

When to Use Which

What's Coming in Part 6

🎬 Watch These

🙏 Sources & Thanks

TestSprite — Panduan Cepat (Indonesian Translation)

TestSprite — Panduan Cepat

Apa itu TestSprite?

Instalasi

1. Daftar di TestSprite

2. Hubungkan Aplikasi Anda

3. Tunggu Analisis AI

Test Pertama Anda

Menghasilkan Test Cases Otomatis

Hasil Test

Merawat Test Saat UI Berubah

Skenario: Anda mengganti .primary-button menjadi [data-testid="primary-btn"]

Mengintegrasikan dengan CI/CD

GitHub Actions

GitLab CI

Jenkins

Kategori Test yang Didukung

1. Form Testing

2. Navigation Testing

3. User Interaction Testing

4. Data Presentation Testing

5. API Integration Testing

Contoh Test Output

Konfigurasi Lanjutan

Custom Test Parameters

Environment Variables

Tips & Trik

1. Jangan Manual Test Lagi

2. Update Kode dengan Percaya Diri

3. Gunakan untuk Regression Sebelum Deploy

4. Monitor Test Trends

5. Bagikan Laporan dengan Stakeholder

Troubleshooting

Issue: "Application tidak bisa diakses dari TestSprite runner"

Issue: "Test sering timeout"

Issue: "TestSprite tidak mendeteksi elemen dynamic (lazy-loaded)"

Langkah Selanjutnya

Dukungan

Cursor Composer 2: The Cache Economy Behind a 10x Cheaper Coding Agent

Why a Specialized Model at All

What `useEffect` Actually Is

`useLayoutEffect`: The Synchronous Version

Skenario: Anda mengganti `.primary-button` menjadi `[data-testid="primary-btn"]`

Design Decision 1: `ChainResult<T>` Over Exceptions

Design Decision 2: `IAsyncEnumerable<T>` for Streaming