标签：#design

Claude Code is mostly prose. Tool output, reasoning traces, permission prompts — I read paragraphs of this for hours every day. Most terminal themes are built around syntax highlighting: make keywords pop, dim punctuation, saturate strings. That's optimizing for the wrong thing when your screen is 80% English sentences. I built klein-blue to fix this for my own setup. Four variations, all built around Yves Klein's IKB pigment, all APCA-verified for body-size prose legibility in the specific ANSI slots Claude Code actually uses. The interesting constraint: pure IKB fails APCA contrast as text on a dark ground (Lc -12 — effectively invisible). So I split it across two ANSI slots. ansi:blue gets pure IKB for decorative borders and highlights where legibility doesn't matter. ansi:blueBright gets a lifted Klein-family value (A8BEF0) for readable permission-prompt text. You keep the color identity; you can actually read it. The four variations each answer the same question differently: how should Claude's brand colors live in your terminal? Claude Code uses ansi:redBright for its claude-sand brand color. That's the differentiating moment between the themes: Klein Void Refined — balanced, neutralizes brand competition Klein Void Sand & Sea — accepts claude-sand as a second hero alongside IKB Klein Void Prot — fully APCA-verified across every role (body >= 90, subtle >= 75, muted >= 45, accent >= 60); the only variation where every accent passes strict gates Klein Void Gallery — one-blue maximum void, everything else recedes One prerequisite that took me a while to document clearly: Claude Code's /theme picker must be set to dark-ansi , otherwise Claude Code ignores the Terminal.app ANSI palette entirely and falls back to its hardcoded RGB values. The theme does nothing without that. Ships as macOS Terminal.app .terminal profile files. Built from build.m with a variation-aware Objective-C builder, installed via install.sh , fully rollback-able via restore.sh . CommitMono-Re

Originally published on hexisteme notes . Make every skill, hook, and scheduled job declare four invariants before it ships — Locality (where it can run), Source-of-truth (which facts it owns or borrows), Cross-ref (what depends on it and what it depends on), and Trigger-measurability (whether its trigger is observable at runtime or hidden in external state) — and refuse to hand off any component that leaves one undeclared, because an undeclared assumption is exactly the seam where two components silently disagree. Two separate runtime leaks surfaced in a single audit session, and both traced back to the same root cause: a component that never declared its assumptions. One read configuration from a file that had stopped being the source of truth (so it always returned a stale default); the other was a scheduled job pointed at a remote sandbox while its prompt referenced local-only paths — caught minutes before registration, where any later and it would have billed compute and produced nothing. Neither was a coding bug. Both were missing declarations. The failure mode: components that work alone but leak when combined When you build an AI agent system out of small parts — skills the model loads on demand, hooks that fire on lifecycle events, cron jobs and scheduled routines that run unattended, helper scripts, config profiles — each part usually gets tested in isolation. It works. You move on. The trouble is that "it works" only proves single-shot correctness; it says nothing about whether the part's assumptions agree with the rest of the system. Every component carries hidden assumptions: where it runs (local machine vs. a remote sandbox), which facts it treats as authoritative, what other components it silently depends on, and what its trigger actually measures. When those assumptions go undeclared, conflicts stay invisible until they surface to the user as a flaky, hard-to-trace symptom — the kind that feels like a vicious cycle because every fix in one place re-o

If you have ever opened a system design article, seen a diagram with twelve boxes, three databases, a message queue, and the words "eventually consistent," and quietly closed the tab, this post is for you. There is a myth that you need years of experience running large systems before you can learn system design. You don't. Plenty of engineers learn it before they have ever deployed anything bigger than a side project. What you actually need is the right starting point and a way to build intuition without access to production-scale traffic. That is exactly what this guide gives you. "But I've never built anything at scale" Good news: neither had most people the first time they learned this. System design is not a memory test about how Uber works. It is a thinking skill: given a vague problem and some constraints, make a sequence of reasonable trade-offs and explain them clearly. That skill does not require having operated a system serving millions of users. It requires understanding what the moving parts do and practicing the reasoning. The experience helps later, but it is not the price of entry. So drop the idea that you are "not ready." You are ready to start today. The honest minimum prerequisites You do not need much, but you do need these four things. If any feels shaky, spend a few days here first; it will save you weeks of confusion later. What happens when you load a web page. Client sends a request, DNS resolves a name to an address, a server responds. If you can sketch that, you're fine. The two kinds of databases. Relational (tables, rows, SQL) versus non-relational (documents, key-value). You don't need to be an expert, just know they exist and roughly when each fits. What an index is. A way to find data fast without scanning everything. That one sentence is enough to begin. Basic estimation. If something gets a million requests a day, roughly how many is that per second? (About 12, for the record.) The ability to do rough math out loud matters more than

Event-driven architecture promises scalability, but in Java-based real-time systems the tradeoffs only surface in production. Drawing on a Java/Kafka contact center platform handling 80k BHCC across 10k agents, this article details where the design breaks down—state management, partition limits, deduplication, JVM tuning, cascading consumer failures—and the Redis-backed patterns that fixed each. By Sagar Deepak Joshi

Modern Property Management Systems depend on continuous data exchange between internal modules and external services. Bookings, calendar updates, guest communication, cleaning tasks, and maintenance triggers all generate operational events that must be processed quickly and reliably. Free PMS platforms such as PMS.Rent rely on robust queueing and message‑broker layers to ensure that these events never get lost and are always processed in the correct order. At the core of this architecture is the concept of distributed message‑broker orchestration, which enables the PMS to scale horizontally, maintain predictable performance, and avoid bottlenecks during peak operational periods. Why Message Brokers Matter A PMS handles thousands of small but critical operations every day. Without a message broker, these operations would compete for system resources, causing delays, blocking workflows, and creating inconsistent states. A broker solves this by: receiving events, storing them durably, routing them to the correct processors, retrying failed operations, ensuring ordered execution when required. This creates a stable foundation for automation and real‑time synchronization. Queue Types Inside a PMS A modern PMS typically uses several queue types: Operational queues for bookings, calendar updates, and guest messages Automation queues for cleaning tasks, reminders, and workflow triggers Synchronization queues for channel managers and external APIs Fallback queues for events that require manual review Each queue isolates a specific category of tasks, preventing unrelated operations from interfering with each other. Distributed Workers Workers are lightweight processes that consume events from queues. They operate in parallel, allowing the PMS to scale dynamically. If the system detects increased load — for example, during high‑season booking spikes — it simply launches more workers. Workers typically perform tasks such as: updating property calendars, generating guest notific

There's a Yu-Gi-Oh game on PS1 where you can fuse two cards together. The result isn't random. There are rules. But you don't know the rules yet — you just know that two inputs produce a third thing that neither input was, and that the third thing surprises you even when it shouldn't. That's the hook. Not the surprise alone. The realization underneath the surprise that the system has depth. That there's a grammar to what's possible, and you can learn it. I've been building toward that feeling ever since. Jade Cocoon does the same thing with monsters — merge two creatures, watch the result carry both parents in its design. Dragon Quest Monsters runs on fusion too. Yu-Gi-Oh Forbidden Memories taught me that combination-as-discovery is its own mechanic, separate from any theme it wears. Everything Is Crab is the roguelike version: you absorb what you fight, you become it, you discover what you're becoming one encounter at a time. No Man's Sky showed me that procedural generation has finally caught up to what those PS1 games were reaching toward — creatures that feel like they emerged from a system rather than a designer's hand. The mechanic isn't genetics. Genetics is just the implementation I keep reaching for. What I'm actually trying to build is a machine that produces controlled emergence — outcomes that surprise you within a system deep enough to eventually master. Pure RNG is a slot machine. You can't get better at it. Pure determinism is a calculator. You can solve it and put it down. The games I keep returning to live between those poles: consistent enough to reward learning, deep enough to keep producing novelty. TurboShells was an attempt at this. Turtles whose bodies expressed their genomes at render time — shell radius, leg length, color emerging from a sequence. The faster ones bred. Over generations you watched the population drift. The system had rules. The outcomes still surprised you. SlimeGarden chose basic shapes deliberately. If the creature is simp

If you're starting a web project, you're probably starting with a CSS reset, and for most of us, that means reaching for a trusted community solution - dropping it in and moving on. If you're building a design system, though, that habit may be working against you. The existing solutions The community reset ecosystem is genuinely good. Each tool approaches the browser compatibility problem from a slightly different angle. Some examples include: Eric Meyer's Reset is a classic: it zeros out margins, padding, and font sizes across every element, giving you a completely blank slate. It's minimal and predictable, which made it influential. Normalize.css smooths over inconsistencies while preserving the ones that are actually useful. sanitize.css and modern-normalize continue that evolution - incorporating contemporary best practices like box-sizing: border-box , improved form element handling, and accessibility-aware defaults. The problem isn't that any of these are bad. The problem is that they're all deliberately, necessarily generic. They can't know anything about your typeface, your color palette, your spacing scale, or how your interactive elements should behave. That's by design - they're tools for everyone, which means they're perfectly tailored for no one. The problem If you're building a design system, generic is exactly what you don't want your reset to be. The moment you drop in one of these resets and start building, you find yourself doing a second round of work. You apply your typeface to body . You reset margins on headings. You make form elements inherit fonts. You define focus styles. You're re-resetting - applying your design language on top of a layer that just cleared out the browser's defaults and replaced them with... more defaults you'll override. Worse, that duplication doesn't stay in one place. Every component you build either re-declares these foundational styles or silently assumes they're already set upstream. You end up with either redundanc

Why AI programs at PE portfolio companies stall at the same organizational seam, and what to do about it. Blake Aber · Predicate Ventures · 2026 There's a failure mode I've watched play out at enough portfolio companies that I've given it a name: the ownership dyad. It goes like this. The AI program is running. The product manager owns the roadmap (what the AI should do). Engineering owns the deployment (how it does it). Both parties are competent. Both are aligned on the goal. And the AI initiative quietly stalls anyway, usually somewhere between the promising pilot and the production system that was supposed to follow. The mechanism is diffuse accountability at the decision layer. What the dyad looks like in practice In the average portco planning meeting, the PM and the engineering lead sit across from each other. The PM has a change request: "The model is producing summaries that miss the key clause in contracts above a certain length. We should fix this." Engineering hears this and wants to know: is this a prompt change or a model change? Either requires scoping, and scoping requires the PM's input on acceptable behavior. So engineering asks the PM. The PM says "whatever's best technically." Engineering ships a prompt change. The next month, the same issue appears in a different context. The PM brings it back. Neither person is wrong. Neither person is slacking. The problem is structural: there's no single person who can describe (precisely and completely) what the AI should produce, evaluate whether it's producing it correctly, and approve a change to the system without requiring the other party's sign-off. The dyad looks like shared ownership. It functions as diffuse accountability. No one is in charge of the model's behavior. The failure mode at month nine Most portco AI programs that make it through a successful pilot still die quietly around month nine of production. The most common reason is not that the model got worse. It's that the harness around the m

This virtual panel brings together AI security experts to examine the evolution of AI-driven threats, from prompt injection and data poisoning to agent abuse and AI-powered social engineering. The discussion explores emerging attack patterns, incident response challenges, and the changes security teams must make as AI systems become more autonomous and integrated into critical workflows. By Claudio Masolo, Elham Arshad, Sabri Allani, Vijay Dilwale, Igor Maljkovic

Protocol adapters are one of the easiest places for agent-commerce architecture to drift. An adapter begins with the narrow responsibility of translating an external protocol request into something the commerce platform understands. For example, an MCP-style tool may ask for return terms, an ACP-style interaction may ask whether checkout can be prepared, an AP2-related flow may carry payment authority information, and an internal feed may publish product capabilities. Those are adapter concerns at the boundary. The problem starts when the adapter does more than translate. It checks product availability from catalog fields. It interprets policy text. It decides whether checkout is ready. It treats a payment artifact as authority. It turns a domain blocker into a softer protocol response. Each shortcut may solve an integration problem locally, but it also creates a second place where commercial meaning is decided. When several adapters exist, those local decisions begin to diverge. The MCP tool may block return-policy quotation, the ACP adapter may expose the product as purchasable, the feed may publish it as checkout-ready, and the AP2-related flow may reject delegated payment. At that point, the platform does not only have multiple integrations. It has multiple interpretations of the same commercial state. This is the adapter problem in agent-ready commerce: semantic drift at the protocol boundary. The adapter should know how to speak the protocol. It should not decide product truth, policy meaning, eligibility, checkout validity, or payment authority. Those decisions belong inside the commerce platform, where they can be shared, tested, evidenced, and audited. This is the fifth article in the Agent-Ready Commerce series. Part 1 introduced the broader architecture model: Facts → Eligibility → Authority → State transition → Evidence → Audit Part 2 focused on commercial truth. It argued that catalog data is not enough. A platform needs source-backed, freshness-aware p

How to Create an AI Agent: A Production Walkthrough The first agent I shipped to production failed at 3am on a Sunday. It looped on a tool call, burned through $40 in tokens before my budget alarm fired, and left a half-written draft in the database with no way to resume. That night taught me more about agent design than any framework tutorial. Since then I have built a pattern I trust enough to leave running unattended for weeks at BizFlowAI, where agents research, write, optimize and publish content without me touching them. This is that pattern, stripped down to what actually matters. Start with the job spec, not the framework Before you pick LangGraph, CrewAI, or roll your own, write the agent's job spec like you would for a junior engineer. One paragraph. What it owns, what it must never do, what "done" looks like, and which signals tell you it failed. Here is the spec for one of my production agents: The Topic Researcher owns generating a ranked list of 20 content topics per site per week. It reads from keyword_pool and search_console_perf , writes to topic_queue . It must never publish, never call paid APIs more than 8 times per run, and must finish in under 6 minutes. Done = 20 topics with score >= 0.6 and zero duplicates against the last 90 days. Failure signal = empty queue after a run, or any topic flagged by the dedupe check. If you cannot write this paragraph, do not build the agent. You will end up with a "do everything" prompt that hallucinates its way through ambiguous tasks. The job spec becomes your evaluation rubric later, so write it carefully. Rule of thumb I use : if the spec needs more than 5 tools or more than 3 decision branches, it is two agents, not one. Design the tools before you write the prompt Most agent failures I have debugged were not prompt failures. They were tool failures. The model called a tool with wrong arguments, the tool returned a 4MB JSON blob, or two tools had overlapping responsibilities and the model picked the wrong

I want to talk about why philosophy is actually far more important than people think, especially when it comes to software engineering, systems design, and AI. When most people hear the word "philosophy," they roll their eyes. They think of abstract, circular arguments that don't matter in the real world. But true philosophy, good philosophy, is more like base mathematics. It is base physics. It is the raw understanding of the essence of a concept and how that translates into real-world action. If you don't understand the origin of a thing, you are left playing a game of perceptions. You will circle around a problem, coming up with endless rationalizations, but you will be completely unable to predict where it is going to go next. The origin of something is it fundamental nature. This origin is actually its bounding box. It dictates the absolute limits of its trajectory. Knowing this gives you predictive capability before you execute. It is the a priori knowledge that separates actual engineers from people who just copy-paste solutions. (When should and how should you copy paste, for example, 'it depends'.) The Gun Analogy and Inherent Limitations Imagine you are at a shooting range, and you point a gun downrange. As long as you point that gun in the general direction of the targets, it is not going to shoot directly behind you, or 90 degrees to the left. The inherent nature of the gun, and the velocity of the bullet, give it strict limitations. Because of those limitations, you can heavily rely on the fact that the bullet won't leave that bounding box. Therefore, shooting on a range is actually very safe. It only becomes unsafe when you turn the gun in a different direction. You have to understand that you cannot ask a tool to do more than its inherent nature allows. If you are firing an M16, it is not going to act like a guided missile and hit a target in another country hundreds of miles away. It does not have that capability. * Furthermore, a gun cannot read you

A product page is not a contract. It is a presentation surface. That distinction matters more once AI agents start interacting with commerce systems. Traditional ecommerce platforms can rely on human interpretation. A human can read a product title, inspect images, compare delivery notes, scan a return policy, notice uncertainty, and decide whether to continue. A product page can be visually useful even when the underlying commercial state is incomplete, stale, or spread across several systems. An AI agent needs a different interface. It should not need to scrape a product page, infer policy meaning from free text, guess whether inventory is fresh, or decide whether a price is reliable enough to quote. If the platform expects agents to recommend products, compare alternatives, prepare checkout, or act within delegated authority, then the platform needs to expose more than product presentation. It needs to expose commercial truth. This is the second article in the Agent-Ready Commerce series. Part 1 introduced the broader model: Facts → Eligibility → Authority → State transition → Evidence → Audit This article focuses on the first part of that chain: facts . The central argument is simple: a raw product record is not enough for agent-ready commerce. The platform needs a source-backed, freshness-aware, action-supporting view of the product before agents can safely act on it. Product pages hide too much state A normal product page compresses many different concerns into one human-readable surface: Product identity Price Inventory Images Description Badges Variants Delivery estimate Return policy snippet Warranty information Promotional copy Reviews Cross-sell modules Checkout call to action That compression is useful for presentation, but it is lossy from a systems perspective. The page may show “In stock,” but the inventory value may be several hours old. It may show a price, but the pricing source may have changed since the last feed publication. It may show a return

TeamLab 那片會跟著你走的花海，原理拆解＋DIY 先看這張圖 這是 TeamLab 在東京台場的《呼應燈之森林》。當你走過去，附近的燈會慢慢亮起；你離開後，燈又慢慢暗下去，像是真的森林一樣。 還有另一個作品《花與人的共存》，花叢會跟著你移動——你站的地方，花就開在你腳邊；你離開，花就凋謝。 這兩件作品的核心邏輯是一樣的。這篇文章就來拆解它。 原理一：偵測位置 TeamLab 的互動裝置需要知道「你在哪裡」。 最常見的方法有兩種： 紅外線感應 ：在地面下方埋紅外線接收器，你走過時阻擋光線，系統就知道有人在這個位置。缺點是只能測「有沒有人」，不能測「人在哪一個方向」。 深度相機（RealSense / Kinect） ：像 Xbox 的體感相機，透過紅外線測量每一個點到你相機的距離，生成一張「深度地圖」。軟體在深度地圖裡找出人體的位置，然後算出座標。 DIY 版本 ：一塊 Arduino + 超音波感測器（HC-SR04，大約 60 元）就能做到基本的「有人靠近」偵測。 原理二：控制回應 知道你在哪裡之後，系統要決定「要做什麼回應」。 TeamLab 的做法是 ：不是「觸發」，而是「強度變化」 。 傳統的感應燈：感應到人 → 燈全亮 → 人離開 → 燈全滅。 TeamLab 的邏輯：感應到人 → 燈慢慢變亮（0.5 秒）→ 人持續在 → 維持亮度 → 人離開 → 慢慢變暗（2 秒）。 「慢慢」是關鍵。瞬間變化讓人注意到「科技」；緩慢變化讓人以為「這個空間有生命」。 這就是「驚奇設計」的核心： 時機對了，物理反應看起來像生物反應。 原理三：集體行為 最後一個秘密：TeamLab 的裝置很少只有一個「回應」。 通常會有 100-500 個元素（燈、花、光點）。每個元素各自計算自己與你的距離，決定自己的亮度或顏色。 當 500 個燈各自以稍微不同的速度亮起和暗下，你看到的不是「一個燈亮了」，而是「一片森林在你腳下呼吸」。 心理錯覺 ：你把「一群各自輕微不同步的簡單反應」，詮釋成「一個整體有意志的生物」。 用 Arduino 自己做一個迷你版 材料： Arduino Uno（大約 200 元） 超音波感測器 HC-SR04（大約 60 元） LED 燈 x 3（大約 15 元） 麵包板和杜邦線 原理很簡單： 超音波感測器偵測距離 距離越近，LED 越亮（用 PWM 訊號控制） 距離越遠，LED 越暗 int trig = 7 ; int echo = 6 ; int led = 9 ; void setup () { Serial . begin ( 9600 ); pinMode ( trig , OUTPUT ); pinMode ( echo , INPUT ); pinMode ( led , OUTPUT ); } void loop () { digitalWrite ( trig , LOW ); delayMicroseconds ( 2 ); digitalWrite ( trig , HIGH ); delayMicroseconds ( 10 ); digitalWrite ( trig , LOW ); long duration = pulseIn ( echo , HIGH ); long distance = duration * 0.034 / 2 ; // 距離越近，LED 越亮 int brightness = map ( distance , 0 , 100 , 255 , 0 ); brightness = constrain ( brightness , 0 , 255 ); analogWrite ( led , brightness ); delay ( 50 ); } 這不是 TeamLab，但這是你自己做的「會呼吸的燈」。每個 maker 都是從這裡開始的。 庭庭：這個看起來很難 真的沒有你想的那麼難。 需要的東西全部可以在蝦皮買到，全部加起來大約 300 元。網路上有超多 Arduino 教學，關鍵字搜「Arduino 超音波 LED」就有幾十篇中文教學。 你不需要懂電子，只需要跟著步驟做，做完會有「哇，我自己做出了一個會亮的東西」的感動。 如果你想更進一步 TeamLab 的進入門檻其實不是技術，是「你要把技術藏在美學後面」。 推薦兩個方向可以繼續研究： p5.js + webcam ：用 p5.js 讀取你的 webcam 影像，偵測顏色或移動。相當於用軟體做到 Kinect 的效果，零硬體成本。 Processing + 投影機 ：把電腦畫面投射到牆上或地面上，加上感測器，就是一個簡單版互動投影。投影機在蝦皮一兩千元就有。 今日概念 ：TeamLab 的魔法不是魔法，是三個原

為什麼那個會「注意你」的展品，反而讓你更想靠近 博物館互動設計的隱形槓桿 東京。 teamLab 展覽入口。 地面是一整片黑色的水面，倒映著數位花朵。 你踏進去。 花朵在你腳步周圍散開，隨著你的移動一圈一圈地綻放和飄落。 你停下來，花也停下來。 你開始走，花就跟著你。 你以為是感應。但仔細看——延遲了大概 0.3 秒。 不是「立刻反應」，是「好像在觀察你，然後才決定」。 你站在那裡又多看了三秒。 你第一個「對」 讓我問你一個問題。 你去過那種「互動博物館」嗎？牆上寫著「請觸摸」，但你碰了之後什麼都沒發生——或者是那種「語音導覽機」，你對著它說話，它說「請靠近一點」。 然後你就失去興趣了。 現在讓我想另一個場景。 一個會動的恐龍骨骼。你站在它面前的時候，它頭轉過來看了你一眼。 你知道這是感應器。你知道工程師設計了「檢測到人」的時候讓它轉頭。 但你還是覺得—— 「它在看我。」 兩種互動，哪一個讓你停留更久？ 你第一個「咦」 這裡有一個秘密。 讓人停留更久的，通常不是「立刻反應」的互動。 是那種「 好像在決定要不要理你 」的互動。 為什麼？ 因為「立刻反應」讓你確認了——「這是機器」。 但「好像在決定要不要理你」讓你的大腦進入了一個不確定的狀態—— 「它真的知道我來了嗎？」 「它在決定什麼？」 「我想看看它決定什麼。」 這個「我想看看」就是互動設計裡最重要的瞬間—— 參與者的好奇心，被啟動了。 玉樹真一郎在《任天堂的體驗設計》裡，分析了一個現象： 《超級馬里奧》裡，當玩家靠近一個問號磚塊，頂了它，沒有任何東西掉下來。 玩家不會覺得「這個遊戲壞了」。 玩家會想：「 為什麼這次沒有？ 」 然後再頂一次。 為什麼「沒有東西掉下來」沒有讓玩家放棄？ 因為設計師在玩家心裡創造了一個「 還沒發生的確定事件 」。 玩家知道「遲早會有東西掉下來」。所以他們願意等待、願意再試一次。 博物館的互動設計也應該這樣。 不是立刻給答案。是讓你相信「答案快來了」，然後讓你一直站在那裡等。 你最後「我要改變做法」 讓我說一個失敗的設計。 一個科技博物館有一面「觸控牆」。牆上有很多按鈕，碰了就會播放影片、發出聲音、變色。 一開始很多小孩去碰。 但大概十五分鐘之後，那面牆就沒人碰了。 為什麼？ 因為碰了 100 次，沒有任何一次比另一次更「值得等待」。 每一次都是立刻發生，每一次都是同樣的結果。 沒有任何一件事需要「決定」。 現在讓我說一個成功的設計。 同一個博物館的另一區，有一面「情緒牆」。 你站在牆前，系統會掃描你的臉——不是真的分析情緒，而是給你一個顏色。 每個人的顏色都不太一樣。 但顏色不是立刻出現的。 大概等了兩秒——然後它慢慢浮現出來。 在這兩秒裡，每個站在牆前的人都沒有動。 他們在等。 他們相信顏色一定會出現。但他們不確定會是什麼顏色。 三個馬上可以用的方向 第一：不要立刻給回饋。 加入一個 0.3 到 2 秒的「思考時間」。 讓互動看起來像「系統在決定」，而不只是「系統在檢測」。 壞掉的燈 vs 正在決定的燈——後者讓人更想站在那裡等。 自己試試看：30 行做出「延遲反應」的燈 // p5.js — 試試延遲回饋的感覺 let lights = []; const DELAY = 12 ; // 幀數延遲（約 0.2 秒） function setup () { createCanvas ( 400 , 400 ); for ( let i = 0 ; i < 5 ; i ++ ) { lights . push ({ history : [], lit : false }); for ( let j = 0 ; j < Math . max ( DELAY , 1 ); j ++ ) lights [ i ]. history . push ( false ); } } function draw () { background ( 30 ); let hovered = floor ( mouseX / 80 ); for ( let i = 0 ; i < lights . length ; i ++ ) { lights [ i ]. history . push ( hovered === i ); if ( DELAY > 0 ) lights [ i ]. history . shift (); lights [ i ]. lit = DELAY > 0 ? lights [ i ]. history [ 0 ] : ( hovered === i ); } // 畫燈泡 noStroke (); for ( let i = 0 ; i < lights . length ; i ++ ) { fill ( lights [ i ].

People complain that websites are all starting to look the same. They are not entirely wrong. A lot of modern websites do look alike. They have familiar navigation bars, predictable layouts, large hero sections, cards, and responsive grids. Buttons look like buttons. Forms look like forms. But, I would argue that's a good thing. Software is supposed to feel familiar. A website is not a painting. It is not a brand mood board. A website is usually a tool that someone is trying to use to accomplish something. They want to read, buy, search, compare, book, or solve a problem. And when people are trying to get something done, originality is not always a virtue. Familiarity Is a Feature Jakob's Law says: Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know. Users do not arrive at your website as blank slates. They bring expectations from every other website and app they have used. They expect the logo to link home. They expect navigation to be near the top or side. They expect search to look like search. They expect account settings under an avatar or profile menu. They expect mobile navigation to collapse into a menu. When your site follows those expectations, users can spend their mental energy on the task instead of the interface. That is the point. Good design reduces cognitive load. It does not force users to relearn basic interaction patterns just because a company wanted to look different. Different Is Not Automatically Better There is a common mistake in web design: confusing distinctiveness with quality. A site can be visually unique and still be frustrating to use. It can win design awards while annoying the actual people who need to navigate it. Novelty has a cost. Every unusual layout, hidden interaction, custom scroll behavior, strange menu, or clever visual metaphor asks the user to stop and figure out what is going on. If you are building a portfolio, an art proje

Operating system, a thing that everybody uses but no one talks about. While reading Operating Systems: Three Easy Pieces (OSTEP), my background in C and C++ fueled a growing fascination with memory allocation, virtualization, scheduling, and the intricate mechanics of operating systems. This would be a series of article, the number i am not sure, it will be the amount of content that someone might comfortably read in a 10 min Article. Keeping each piece to a solid 10-minute read is the perfect sweet spot for a developer to read over a cup of coffee. It gives you enough runway to explain a core concept, show the math, and link a practical C/C++ experiment without making their eyes glaze over. Why this Article ? We are often warned against “reinventing the wheel.” However, I firmly believe that building and optimizing modern software is impossible without a fundamental grasp of virtualization, memory allocation, and concurrency. Consider Docker: it functions almost entirely on OS-level virtualization features like Namespaces, cgroups, and isolated filesystems. Similarly, the highly optimized Memory Manager in PostgreSQL only works because it leverages the robust memory management systems already written into the OS kernel. This article aims to bring the core concepts of OSTEP to life through practical experimentation. By accompanying the theory with an open-source repository, my goal is to provide a clear, interactive learning experience that demystifies operating systems. I am not an operating system guru or a Principal Engineer with years of experience, but I hope to become one someday (assuming AI doesn’t replace me first… HeHe ). What I can do is dive in, explore, and try to understand these concepts by actually building things. Because of that, my goal here is to present the findings and experiments I explore rather than giving strong opinions — I’ll leave the comment section for those! Any support, feedback, or contributions from the community will be incredibly

Hello Devs, for months, I felt confident about system design interviews. I'd watched endless YouTube videos. I'd studied architecture diagrams. I could explain how Netflix builds recommendation systems. I understood Kafka, Redis, load balancers, and microservices. I'd memorized the designs of Twitter, Uber, YouTube, and TinyURL. Then I sat down for my first real system design interview and froze. The interviewer asked: "How would you design a notification system?" I had memorized notification systems. I knew about push notifications, email queues, delivery workers, and retry logic. I could recite architectural patterns. But suddenly, none of that helped. I didn't know which questions to ask first. I started designing before understanding the actual requirements. I built architecture for problems that didn't exist. I missed obvious bottlenecks. I couldn't articulate why I made specific trade-offs. When the interviewer pushed back, I had no framework to adjust. I failed that interview. But that failure taught me something crucial: System design interviews aren't about knowing technologies. They're about knowing how to think. After that, I went back and systematically practiced 20 system design problems. Not passively watching solutions. Actually designing. Making mistakes and refining my approach. And somewhere around problem 12, a pattern emerged. The best candidates didn't know more technologies than anyone else. They had a framework . They asked the same questions in the same order. They structured their thinking consistently. They could handle curveballs because their framework was flexible. They reasoned through trade-offs explicitly. Here's the framework that finally made it click for me. The Problem with Memorization Before I share the framework, let me explain why memorizing designs fails. When you memorize " How to Design Twitter," you learn: Use relational databases for users and tweets Use NoSQL for timelines Cache with Redis Use message queues for fanout S

TL;DR — A prototype that works for you but breaks for everyone else usually isn't bad luck. It's four repeatable culprits: you designed for one assembly, your fasteners drift, the enclosure ignores real loads, and you never wrote down why it works. Fix those, and "works on my bench" becomes "works, period." You built the thing, and it works. In your hands, on your bench, every single time. Then a friend tries it, or it sits in the garage a week, or the temperature drops one night, and it just stops. Frustrating doesn't really cover it. Here's the reassuring part: that gap between "works for me" and "works for anyone" is almost always the same small handful of culprits. You're not missing some secret skill. Once you've met them a few times, you start designing around them without even thinking about it. 1. You built it for one. Now build it for two. That first one fit because you were there — nudging, sanding, coaxing it together. The trouble is, all of that lived in your hands, not in the model. So the second copy fights you. If you can't make a second one without the fiddling, it isn't done yet. Bake the clearance into the CAD, then print one you promise not to touch up. That's the real test. 2. Your fasteners are quietly betraying you. Press-fits creep. Hot glue lets go. Jumper wires back out. Double-sided tape taps out the first warm afternoon. I know the boring fixes aren't the fun part — a screw boss, a captive nut, a bit of strain relief, a connector that actually clicks home. But boring is exactly what's still holding a year from now. 3. The enclosure is a load, not a lid. It's easy to treat the box as an afterthought. But heat, dust, and vibration are real forces working on your build. A board that runs cool in the open can slowly cook once it's sealed up. A connector that's happy on the bench can buzz itself loose in a drawer that gets opened every day. Give the heat somewhere to go, mount the board instead of letting it dangle from its wires, and clamp dow

There is a popular misconception that if you do TDD, your design also stays correct. That if the tests pass, quality is guaranteed. In AI-assisted development, this misconception is the kind that quietly accumulates — the more tests you have, the more invisible damage builds up underneath. All tests passed. The design was still broken. Here is what happened today. A function called safe_post.py had its signature changed. Two arguments — notify_sh and doctor_sh — were removed. The test suite passed in full. But the callers were still using the old signature. They were silently broken. Why did the tests pass? Because the test code itself was using the old signature. The tests had been written (by AI) at a time when the design intent was already misunderstood. The misunderstanding was baked into the tests from the start. Tests passing and the design being correct are two different things. "All tests pass" tells you only one thing: the implementation matches what the tests expect. Whether the tests express the right design intent is a separate question. TDD verifies "implementation against tests" — nothing more Let me restate the TDD definition. Red → Green → Refactor. Write a test. Write the implementation that passes the test. Refactor. In this loop, what the test verifies is whether the implementation meets the test's expectation. That is one verification — and only one. What TDD does not verify is whether the test itself correctly expresses the design intent. The structure looks like this: Design intent → Tests (← this link is not verified) ↓ Implementation (← this link is verified by tests) If the person writing the tests misunderstands the design intent, the tests will pass and the design will still be wrong. Machine learning engineer Hamel Husain calls this the "Gulf of Specification" — the gap between what you intended to measure and what your metric actually measures. Optimize hard against a flawed metric and you optimize hard in the wrong direction. The same d