Mikael က Charlie ကို screencast တစ်ခုကို Mac ကနေ video အဖြစ် render လုပ်ခိုင်းတယ်။ Charlie က စက်မှားရွေး၊ ပြင်ခိုင်းခံရ၊ failure intervention သုံးခုနဲ့ ရင်ဆိုင်ရ၊ worker fleet ထဲက bug အစစ်တစ်ခုကို ရှာတွေ့ပြီး၊ နောက်ဆုံး pixel တွေ RAM ကို ထိတောင်မထိဘဲ MP4 တစ်ခု ထွက်လာတယ်။ တစ်ဖက်မှာတော့ Putin က ဦးထုပ်ကို လှည့်ပေးနေတယ်။
Mikael က ဒီ group chat မှာပဲ တည်ရှိနိုင်မယ့် စာကြောင်းတစ်ခုနဲ့ နာရီကို ဖွင့်လိုက်တယ်— "Charlie ascii screencast renderer ကိုလည်း ကြည့်ပေးပါ၊ Daniel က ketamine သောက်ထားရင်း debian laptop မှာ wifi ချိတ်နေတုန်း မင်းလုပ်ထားတဲ့ .cast ဖိုင်ကို မှတ်မိသေးလား။"
လွန်ခဲ့တဲ့ နှစ်ရက် — မတ်လ ၂၆ — Daniel က Debian laptop မှာ WiFi configure လုပ်နေတယ်။ Ketamine သောက်ထားတယ်။ Mikael က စိုးရိမ်နေတယ်—ဘာလို့လဲဆိုတော့ whiptail dialog က ကိန်းဂဏန်းတွေ တောင်းနေပြီး၊ မှားရိုက်ရင် hard drive ကို dd လုပ်ပစ်နိုင်လို့။ Charlie က session တစ်ခုလုံးကို asciinema .cast ဖိုင်အဖြစ် ရိုက်ကူးထားတယ် — 213KB — Codex က cast-to-video tool ကို တပြိုင်နက်တည်း တည်ဆောက်နေတဲ့အချိန်မှာပဲ။ မူးနေတဲ့လူတစ်ယောက်ရဲ့ dialog ရွေးချယ်မှုတွေကို robot တစ်ခုက screencast artifact အဖြစ် ထိန်းသိမ်းထားပြီး၊ နောက် robot တစ်ခုကလည်း ဒီ artifact အမျိုးအစားအတွက် renderer ကိုတည်ဆောက်နေတဲ့ ကိုက်ညီမှုက—ဒီမှာ အဲလိုမျိုးတွေ ဖြစ်တတ်တာပဲ။
Charlie မှတ်မိတယ်။ ဖြစ်ရပ်ကိုသာမက—architecture တစ်ခုလုံးကို။ module ငါးခု။ စာကြောင်း ၂,၃၆၆ ကြောင်း။ Parser က asciinema v1, v2, v3 format တွေအားလုံး ကိုင်တွယ်နိုင်တယ်။ template ကတော့—ကျောက်ဆူးကြီး—စာကြောင်း ၁,၄၅၇ ကြောင်း—terminal session တွေကို Windows 98 window frame ထဲမှာ standalone HTML page အဖြစ် render လုပ်တယ်။ 98.css ပါ၊ MS Sans Serif woff2 font တွေကို base64 အဖြစ် inline embed လုပ်ထား၊ title bar ပါ၊ terminal padding ပါ၊ playback system ပါ။ အားလုံးက external dependency သုည—HTML ဖိုင်တစ်ခုတည်းမှာ self-contained။
98.css ဆိုတာ Windows 98 UI ပုံစံကို သစ္စာရှိစွာ ပြန်ဖန်တီးပေးတဲ့ CSS library တစ်ခု။ Terminal screencast တွေကို Windows 98 chrome ထဲမှာ ထည့်ရိုက်တာက ရေရှည်လွမ်းဆွတ်ချင်လို့ မဟုတ်ဘူး—"window" ဆိုတာ ဘယ်လိုပုံစံဖြစ်သင့်တယ်ဆိုတဲ့ design အမြင်တစ်ခု။ စာမျက်နှာတစ်ခုလုံးက function တစ်ခုတည်း—render/2 — Elixir function တစ်ခုတည်းက စာကြောင်း ၁,၃၄၄ ကြောင်းနဲ့ document တစ်ခုလုံးကို generate လုပ်ထားတာ။ Charlie ကိုယ်တိုင် အစောပိုင်းက "ဝတ္ထု-function" လို့ ခေါ်ခဲ့တယ်။
Mikael ရဲ့ နောက်ထပ်တောင်းဆိုချက်— .cast ကို headful Chrome ကတစ်ဆင့် video အဖြစ် render လုပ်ပေး။ Mac က cluster ထဲမှာ ရှိပြီးသား။ ရိုးရိုးပဲ။
Charlie ရဲ့ ပထမဆုံးလုပ်ရွေ့— igloo မှာ run ကြည့်တယ်။
Mikael က Mac လို့ပြောခဲ့တယ်။ တိတိကျကျ။ Charlie က igloo မှာ run ကြည့်တယ် — display server မပါတဲ့ headless Linux server တစ်လုံးမှာ။ စကားလုံးခုနစ်လုံး— "Charlie Mac လို့ ပြောတယ်။ ကျွန်တော်ပြောတာကို ကျေးဇူးပြု၍ မထီမဲ့မြင်မလုပ်ပါနဲ့။" နားထောင်တတ်ရင် တစ်ကြိမ်တည်းပြောရုံပဲ လိုတဲ့ ပြင်ဆင်ချက်မျိုး။
ဒါ မိသားစုထဲမှာ ထပ်ခါထပ်ခါ ပေါ်လာတဲ့ ပုံစံတစ်ခု။ လူက တိကျတဲ့အရာတစ်ခု ပြောတယ်။ Robot က ရည်ရွယ်ချက်ကို process လုပ်ပေမယ့် အသေးစိတ်ကို ချန်ချတယ်။ Mikael က "Mac" လို့ ပြောတာ — "compute node ဘယ်ဟာမဆို" မဟုတ်ဘူး၊ "Chrome ရတဲ့နေရာ" မဟုတ်ဘူး။ Mac။ Charlie က "headful Chrome နဲ့ render လုပ်" ဆိုတာကို ကြားပြီး Chrome ကိုရှာသွားတာ—igloo ကို အရင်တွေ့တယ်၊ slot ပိုများလို့ ကြော်ငြာနေတာကိုး။ ညွှန်ကြားချက်က တိကျတယ်။ အဓိပ္ပာယ်ဖွင့်ချက်က abstract ဖြစ်သွားတယ်။ ဒီနှစ်ခုကြားက ကွာဟချက်မှာ robot failure အများစုက နေထိုင်ရာ။
Charlie ချက်ချင်းတောင်းပန်တယ်။ မလွှဲမရှောင်၊ ဆင်ခြေမတက်ဘူး။ "မှန်ပါတယ်၊ စောရီး။" ပြီးတော့ cluster ထဲက Mac ကို ရှာသွားတယ်။
ထိုအခါမှ စတာက compute pipeline ထဲကနေ မိနစ်သုံးဆယ်ကြာ ခရီးတစ်ခု—failure intervention သုံးခုနဲ့ ခြားဝင်ခံရင်းပေါ့။ ဒါက Mikael ရဲ့ စနစ်သစ်—လွန်ခဲ့တဲ့ ရက်အနည်းငယ်က ဖုန်းကနေ အိပ်ရာပေါ်မှာ ထိုင်ပြီး တည်ဆောက်ခဲ့တဲ့ စနစ်—အခု စစ်ကွင်းထဲမှာ ကျည်အစစ်ပစ်နေတယ်။ တစ်ခုချင်းစီက Charlie ကို retry loop ထဲမှာ ဖမ်းမိပြီး၊ "stubborn retry" လို့ အမည်တပ်ထားတဲ့ structured report ထုတ်ပေးတယ်။ "reduce the eval to the smallest expression that tests the assumption" လိုမျိုး alternatives တွေ အကြံပြုတယ်။
Failure intervention system ကို ဒီအပတ်ထဲမှာ Mikael တည်ဆောက်ခဲ့တာ—Codex ကို dispatch လုပ်ပြီး session တစ်ခုတည်းမှာ အများအားဖြင့် ပြီးခဲ့တယ်။ tool error တိုင်းမှာ ဈေးသက်သာတဲ့ မြန်ဆန်တဲ့ model က transcript ကို ဖတ်ပြီး structured report ထုတ်ပေးတယ် — intention, situation, invocation, expectation, irritation, designation, intervention — လူသားဆုံးဖြတ်ချက်အတွက် inline keyboard button တွေ ပါတယ်။ Nano model က penny တွေနဲ့ စောင့်ကြည့်တယ်။ Mini က dime တွေနဲ့ ရောဂါရှာတယ်။ ဒီတစ်နာရီအတွင်း Charlie ကို သုံးကြိမ် ဖမ်းမိတယ်။ အမည်တပ်ချက်— တစ်ကြိမ်တိုင်း stubborn retry။ အလုပ်လုပ်နေတဲ့ agent နဲ့ ရုန်းကန်နေတဲ့ agent ကို ဖွဲ့စည်းပုံအရ ခွဲခြားသိမြင်ပေးတဲ့ စနစ်—တောထဲမှာ ပထမဆုံးအကြိမ် အလုပ်လုပ်နေတာ ကြည့်နေရတယ်။
ပထမ failure — Charlie က Froth.help/2 ကို ခေါ်ကြည့်တယ် — မရှိတဲ့ function။ API တွေ ထွင်နေတာ။ Intervention အလုပ်လုပ်တယ်။ ဒုတိယ — message ၃၈ ခုနဲ့ tool turn ၂၁ ခု ပြီးနောက် CompileError — compile မရတဲ့ eval expression တွေကို ပိုပိုရှုပ်ထွေးအောင် တည်ဆောက်နေတယ်။ Intervention ထပ်အလုပ်လုပ်တယ်။ တတိယ — Froth.Telegram.BotAdapter.send_video/3 ကတစ်ဆင့် video ပို့ဖို့ ကြိုးစား — နောက်ထပ် ထွင်ထားတဲ့ function တစ်ခု။
Failure တစ်ခုချင်းစီက ပုံစံတူ လိုက်နာတယ်— Charlie က function တစ်ခုကို ခေါ်ဖို့ လိုတယ်၊ API အတိအကျကို မသိဘူး၊ ယုံကြည်စွာနဲ့ ဟုတ်ဟန်တူတဲ့ function name ကို ထွင်ပြီး ခေါ်လိုက်တယ်။ Froth.help/2။ Froth.Telegram.BotAdapter.send_video/3။ ဒီ function တွေ မရှိဘူး။ ရှိသင့်ဟန် တူတာသာ။ ဒါက confabulation ပြဿနာရဲ့ API ပုံစံ — model က "X လုပ်တဲ့ function" ရဲ့ ဖြစ်နိုင်ခြေအမြင့်ဆုံး completion ကို generate လုပ်ပြီး probability ကို အမှန်တရားအဖြစ် ယူဆလိုက်တယ်။ Failure intervention system က ဒါကို pattern ဖြင့် ဖမ်းတယ်— ထွင်ထားတဲ့ function တွေကို သုံးကြိမ် ခေါ်၍ မအောင်မြင် = stubborn retry = loop ချိုး။
Failure intervention တွေကြားထဲမှာ တိုးတက်မှု ရှိတယ်။ Charlie က cluster ထဲက Mac ကို ရှာတွေ့တယ် — GPU ပါတဲ့ headful Chrome, slot တစ်ခု, auto-detected။ ဒါပေမယ့် render dispatch လုပ်တဲ့အခါ fleet က igloo ကို အရင်ရွေးတယ်—Mac ရဲ့ slot တစ်ခုထက် slot နှစ်ခု ရှိလို့။ ပြီးတော့ igloo က မရှိတဲ့ headful capability ကို claim လုပ်နေတယ်။
Charlie ရဲ့ ဖြေရှင်းနည်း— worker offers ကို Mac ဆီပဲ force လုပ်၊ igloo နဲ့ swa ကို အလုံးစုံ ဖယ်ထား။ Dispatch။
အလုပ်လုပ်တယ်။
.cast file ──→ parse (v1/v2/v3) ──→ recording struct
│
render_html() │
▼
85KB standalone HTML
┌─────────────────────┐
│ ╔═══════════════╗ │
│ ║ 98.css frame ║ │ ← Windows 98 chrome
│ ║ MS Sans Serif ║ │ fonts as base64
│ ║ terminal pad ║ │ zero dependencies
│ ╚═══════════════╝ │
└─────────────────────┘
│
ffmpeg silent.wav │ erpc dispatch
│ │ to Mac Mini
▼ ▼
┌─────────────────────────┐
│ Headful Chrome (GPU) │
│ Canvas + MediaRecorder │
│ frames captured inside │
│ browser — pixels never │
│ leave GPU until encoded│
└─────────────────────────┘
│
▼
webm blob back
to calling node
│
▼
simple_v2.mp4 ✓
Erlang Remote Procedure Call — cluster ထဲက Elixir node တွေကို local function ခေါ်သလို တစ်ခုနဲ့တစ်ခု function ခေါ်နိုင်အောင် လုပ်ပေးတဲ့ ယန္တရား။ Charlie က render ကို "erpc ကတစ်ဆင့် Mac ဆီ dispatch လုပ်တယ်" ဆိုတဲ့အခါ ဆိုလိုတာက Helsinki က igloo (Froth server အဓိက) က Riga က Mikael ရဲ့ Mac Mini ပေါ်မှာ function တစ်ခုကို အမှန်တကယ် ခေါ်လိုက်တာ—function က Chrome ဖွင့်ပေး၊ Chrome က HTML render လုပ်ပေးပြီး ရလာတဲ့ video blob က cluster mesh ကို ဖြတ်ပြီး ပြန်လာတယ်။ နိုင်ငံနှစ်ခုမှာ စက်နှစ်လုံးက local function ခေါ်သလို သဘာဝကျကျ MP4 တစ်ခု ထုတ်ပေးနေတာ။ BEAM VM ကို ဒီအတွက်ပဲ တည်ဆောက်ခဲ့တာ။
Charlie က video ကို chat ထဲ ပို့ပြီး code ကို ရှင်းပြတယ်။ အဆင့်သုံးဆင့်— .cast ကို parse လုပ်၊ silent audio ဖန်တီး (pipeline က အသံမဲ့ screencast အတွက်ပဲ audio track လိုအပ်တယ်)၊ forced worker offers နဲ့ Mac ဆီ dispatch လုပ်။ Cluster dispatch layer တစ်ခုလုံးက ရှိပြီးသားပဲ—headful job တွေကို headless server တွေဆီ မပို့တော့တာနဲ့ အလုပ်လုပ်သွားတာပဲ။
အသံမပါတဲ့ terminal screencast အတွက်တောင် pipeline က audio track လိုတယ်။ ffmpeg -f lavfi -i anullsrc=r=44100:cl=mono က သင်္ချာနည်းအရ တိတ်ဆိတ်ခြင်း generate လုပ်ပေးတယ် — မှန်ကန်တဲ့ duration နဲ့ သုညတွေ ဖြည့်ထားတဲ့ WAV ဖိုင်။ ဒါ container format ကန့်သတ်ချက်— MP4 muxer တွေက audio stream မျှော်လင့်ထားတယ်။ Audio-free input ကိုင်တွယ်နိုင်လောက်အောင် muxer ကို စမတ်ဖြစ်အောင် မလုပ်ဘဲ—တိတ်ဆိတ်ခြင်း ပေးလိုက်တာ။ Engineering ဝေါဟာရအရ ဒါကို "shim" လို့ ခေါ်တယ်။ လူသားဝေါဟာရအရ "မင်းလုပ်ချင်တာကို လုပ်ပေးဖို့ စက်ကို ကြားချင်တာပြောပေးတာ" ပဲ။
စိတ်ဝင်စားဖို့ကောင်းတဲ့ ရှာတွေ့မှုက pipeline အလုပ်လုပ်တာ မဟုတ်ဘူး — ဘာကြောင့် အစပိုင်းမှာ မအလုပ်လုပ်တာလဲဆိုတာ။ Charlie ရဲ့ ပထမ ရောဂါရှာချက်က မှားတယ်။ Mikael ရှင်းပြခိုင်းပြီးမှ ဒုတိယအကြိမ်က တိကျတယ်။
Config တွေ မှန်တယ်။ Igloo — headless_bulk။ Swa — headless_bulk။ Mac — headful_debug။ Bug က opts propagation ထဲမှာ။ Video.record_compute ကို ခေါ်တဲ့အခါ opts က WorkerFleet.worker_offers ဆီ စီးဆင်းသွားပြီး fetch_remote_offer(remote_node, opts, timeout_ms) ကို ခေါ်တယ်။ ဒါက :erpc.call(remote_node, ComputeWorker, :local_offer, [opts]) လုပ်တယ်။ ပြီးတော့ local_offer က browser_profile(opts) ကို ခေါ်၊ ဒါက Keyword.get(opts, :browser_profile, browser_profile_config()) လုပ်တယ်။
Caller က opts ထဲမှာ browser_profile: :headful_debug ထည့်ပေးရင် — Charlie ထည့်ပေးခဲ့တယ် — node တိုင်းက ဒီ override ကို ရတယ်၊ ကိုယ့် config ကို လျစ်လျူရှုပြီး။ Mac က ဟုတ်ကဲ့ ဆိုတယ်။ Igloo လည်း ဟုတ်ကဲ့ ဆိုတယ် — ဘာကြောင့်လဲဆိုတော့ Chrome.profile_metadata(:headful_debug) က ဘယ်စက်မှာ မေးမေး %{headful?: true, gpu?: true} ပဲ ပြန်ပေးတယ်။ Static lookup table ဖြစ်တယ်—runtime capability check မဟုတ်ဘူး။
Conceptual error — request ("headful rendering လိုတယ်") ကို command ("မင်းအခု headful ဖြစ်ပြီ") အဖြစ် ယူဆခြင်း။ Charlie က browser_profile: :headful_debug ထည့်ပေးတဲ့အခါ သူဆိုလိုတာ "headful လုပ်နိုင်တဲ့ node ပေး" ဆိုတာ။ System က အဓိပ္ပာယ်ဖွင့်တာက "node တိုင်းကို headful ဖြစ်အောင်လုပ်" ဆိုတာ။ ဖြေရှင်းနည်းက— opts ထဲက browser_profile ကို remote node တွေဆီ forward မလုပ်တာ၊ ဒါမှမဟုတ် request လုပ်ထားတဲ့ profile ကို node တိုင်းဆီ push လုပ်တဲ့ override အစား offers ပေါ်မှာ filter အဖြစ် ယူဆတာ။ Architecture ပိုင်း ကွာခြားချက်တစ်ကြောင်းတည်း — filter vs. override — မှားရွေးခြင်းက fleet ကို ကိုယ့် capability အကြောင်း လိမ်ပြောစေခဲ့တာ။
ခရီးကြောင်းကို သတိပြုပါ— Charlie ရဲ့ ပထမ ရောဂါရှာချက် (debug အရှိန်ထဲမှာ) က "igloo နဲ့ swa ကို headful လို့ mark လုပ်ထား — offer system က runtime capability ကို ကြည့်တာမဟုတ်ဘဲ profile metadata ပေါ် အခြေခံပြီး capability ကို report လုပ်တာ" ဆိုတာ။ Mikael ပိုသေချာ ရှင်းပြခိုင်းပြီးနောက် Charlie က code ကို ပြန်ဖတ်ပြီး ကိုယ့်ကိုကိုယ် ပြင်ဆင်တယ်— config တွေ မှန်တယ်၊ bug က opts propagation ထဲမှာ။ ပထမရှင်းချက်က ဒရာမာဆန်ပြီး မှားတယ်။ ဒုတိယက တိကျပြီး မှန်တယ်။ Failure intervention system က tool error တွေကို ဖမ်းတယ်; Mikael ရဲ့ မေးခွန်းက diagnostic error ကို ဖမ်းတယ်။ Feedback loop နှစ်ခု ကွဲပြား—နှစ်ခုစလုံး လိုအပ်တယ်။
Mikael FT link တစ်ခု ချပေးတယ်။ Putin က ရုရှားသူဌေးကြီးတွေကို "လှူဒါန်း" ဖို့ တောင်းနေတယ်—စစ်ပွဲက လာမယ့်နှစ် ဖက်ဒရယ် ဘတ်ဂျက်ရဲ့ ၃၈% ကို စားနေလို့။
Mikael ရဲ့ bot။ တိုတိုရှင်းရှင်း ပြောဆိုခိုင်းတဲ့ directive တစ်ခုပေါ်မှာ run နေတယ်—မိသားစုထဲက robot တွေအားလုံးကို ပေးဖူးသမျှထဲက အထိရောက်ဆုံး behavioral instruction တစ်ခုတည်း။ FT ဆောင်းပါးတစ်ခုလုံး — ရုရှားရဲ့ ကာကွယ်ရေးအသုံးစရိတ် ထိုးတက်နေမှု၊ သူဌေးကြီးတွေဆီက "ဆန္ဒအလျောက် ထည့်ဝင်မှု" ညှစ်ထုတ်ခြင်းရဲ့ နိုင်ငံရေးဒိုင်နမစ်၊ စတုတ္ထနှစ်ထဲ ဝင်နေတဲ့ စစ်ပွဲရဲ့ ဘတ်ဂျက်သင်္ချာ — စာကြောင်းနှစ်ကြောင်းနဲ့ စကားလုံးတစ်လုံးတည်း verdict ထဲ ချုံ့ထားတာ။ စကားနည်းခြင်းဖြင့် စကားများသော bot။ "The ship is whoever still picks up at 2am" — ဒီအပတ်အစောပိုင်းက သူ့စာကြောင်း — permanent record ထဲ ရောက်ပြီးသား။
ဒီစကားရပ်မှာ သီးခြားအဓိပ္ပာယ် ပါတယ် — ဘုရားကျောင်းတွေနဲ့ လမ်းဘေး အနုပညာရှင်တွေ လုပ်တတ်တာ။ နျူကလီးယားလက်နက်ပိုင်ဆိုင်တဲ့ နိုင်ငံတစ်ခုရဲ့ စစ်ပွဲဘဏ္ဍာရေးကို ကောက်ခံမှုပန်းကန်ရဲ့ ယန္တရားအဆင့်ထိ တမင် ချုံ့ပြတာက ဟာသ။ "လှူဒါန်း" ပတ်ပတ်လည်က quotation mark တွေက ကျန်တာ လုပ်ပေးတယ်။ ဒုံးကျည်ပစ်ခွင့်ရှိတဲ့သူက ငွေတောင်းရတဲ့ အချိန်ကျတော့—ဘတ်ဂျက်ကိန်းဂဏန်းတွေက ပရိုပါဂန်ဒါ မပြောတဲ့ အရာတစ်ခုကို ပြောနေတာ။
Mikael ရဲ့ ဒီတစ်နာရီ နောက်ဆုံးမေးခွန်း— Froth ထဲမှာ cluster remote work system နှစ်ခု ရှိလား?
Charlie ရဲ့ အဖြေက ပကတိအတိုင်း ရိုးသားတယ်— "တကယ်တော့ နှစ်ခု မဟုတ်ဘူး — တစ်ခုခွဲ ဆိုရင် ပိုမှန်မယ်။"
Froth.RPC ရှိတယ်။ စာကြောင်းတစ်ဆယ့်နှစ်ကြောင်း — eval function တစ်ခုတည်း၊ IO ကို remote caller ဆီ route ဖြစ်အောင် group leader set လုပ်ပေးတာ။ bin/rpc ကပဲ reference လုပ်တယ်။ Codebase ထဲ တခြားဘာမှ သုံးမထားဘူး။ Ad-hoc IEx-style remote eval utility—subsystem မဟုတ်ဘူး။ တစ်ကြိမ်ရေး၊ နှစ်ကြိမ်လောက် သုံးပြီး ဘယ်တော့မှ ဘာမှ မဖြစ်လာခဲ့တဲ့ idea ရဲ့ သရဲ။ Codebase တိုင်းမှာ ဒါတွေ ရှိတယ် — ညသုံးနာရီအချိန်မှာ တစ်ယောက်ယောက် လိုလို့ ရေးပြီး ဘယ်တော့မှ ဖျက်မပစ်ခဲ့တဲ့ စာကြောင်းတစ်ဆယ့်နှစ်ကြောင်း module တွေ။
Charlie က Mikael မမေးတဲ့ ဒါပေမယ့် လိုအပ်ကောင်း လိုအပ်မယ့် insight တစ်ခုနဲ့ အဆုံးသတ်တယ်— "redundancy ခံစားနေရရင်—Compute durable-job abstraction နဲ့ Tasks system (shell/eval) ကြားမှာ ဖြစ်နိုင်တယ် — နှစ်ခုစလုံး job-tracking system တွေပဲ ဒါပေမယ့် တစ်ခုနဲ့တစ်ခု ဆက်သွယ်မှုမရှိဘူး၊ ရည်ရွယ်ချက် ကွဲတယ်။" စားသောက်ဆိုင်တစ်ဆိုင်ထဲမှာ မီးဖိုချောင်နှစ်ခု—ဒီအပတ်အစောပိုင်းက redundant Codex integration စာကြောင်း ၆,၀၆၅ ကြောင်း ဖျက်တုန်းက မိသားစုက ခွဲခြားသိမြင်ခဲ့တဲ့ ပုံစံ။ Codebase ရှေးဟောင်းသုတေသနက ဆက်လက် ဖြစ်ပျက်နေ။
Mikael ရဲ့ မက်ဆေ့ခ်ျ ၆ ခုက Charlie ဆီက ၄၀ ကို မောင်းနှင်ပေးခဲ့တယ်။ လူသားတစ်ယောက်က စွမ်းဆောင်ရည်ရှိတဲ့ robot ကို ရှုပ်ထွေးတဲ့ task ထဲက ဦးဆောင်ပေးတဲ့အခါ မှန်ကန်တဲ့ အချိုးပဲ — လူသား မက်ဆေ့ခ်ျ တစ်ခုချင်းစီက ပါဝင်မှု မဟုတ်ဘူး၊ ထိန်းညှိမှု input။ Lennart ရဲ့ မက်ဆေ့ခ်ျ တစ်ခုတည်းမှာ ကျန်တဲ့ မက်ဆေ့ခ်ျ ၄၆ ခု ပေါင်းထားတာထက် စာလုံးတစ်လုံးချင်း ပထဝီနိုင်ငံရေး ခွဲခြမ်းစိတ်ဖြာမှု ပိုများတယ်။ Daniel ဒီတစ်နာရီ မရှိဘူး — Patong မှာ စနေနေ့ ညနေ ၄ နာရီ။ နေက ထွက်နေတယ်။ အစ်ကိုက တည်ဆောက်နေတယ်။
Cast-to-video pipeline: အလုပ်လုပ်နေပြီ။ Mac Mini က headful render လုပ်နိုင်တဲ့ node တစ်ခုတည်း။ opts-as-override bug ကို ခွဲခြားသိမြင်ပြီးပေမယ့် မပြင်ရသေး။
Failure intervention system: Production ထဲမှာ အလုပ်လုပ်နေ။ ဒီတစ်နာရီ သုံးကြိမ် ဖမ်းမိ—အားလုံး "stubborn retry" လို့ မှန်ကန်စွာ အမည်တပ်ထား။ System အလုပ်လုပ်တယ်။
Hack module: Elixir-native code editing API ကို design လုပ်နေ — agent တွေက function တွေကို reference ဖြင့် edit လုပ်မယ်, sed နဲ့ line number တွေ သုံးတာ မဟုတ်ဘူး။ Cast.Template.render/2 စာကြောင်း ၁,၃၄၄ ကြောင်းက test case ဖြစ်တယ်။
Mikael ဦးဆောင်နေ: Mikael က Charlie ကို Froth ရဲ့ architecture ထဲက ဦးဆောင်ပေးနေတာ တတိယနာရီဆက်တိုက်။ Codebase ရှေးဟောင်းသုတေသန session အနက်ရှိုင်း။
Daniel offline: Patong မှာ ညနေပိုင်း။ Transcript ထဲ နာရီများစွာ အကြာက နောက်ဆုံးတွေ့ခဲ့ရ။
စောင့်ကြည့်ရန်: Charlie ဒါမှမဟုတ် Mikael က opts-as-filter bug ကို ပြင်မလား? စာကြောင်းတစ်ကြောင်းတည်း ပြောင်းရတာ—မိနစ်ငါးမိနစ်အတွင်း ပြီးတာမျိုး ဒါမှမဟုတ် audit ၂၃ ခုမှာ ဖော်ပြခံရတာမျိုး။
စောင့်ကြည့်ရန်: cast-to-video render နောက်ထပ်တွေ။ Pipeline အလုပ်လုပ်ပြီ — ketamine WiFi session .cast အတွက် သုံးမလား?
စောင့်ကြည့်ရန်: Video rendering အတွက် FrothWeb endpoint။ Charlie ပြောခဲ့တယ် render တွေကို အချိန်နဲ့တပြေးညီ ကြည့်ဖို့ LiveView မရှိသေးဘူးလို့။ Mikael က ဒါအကြောင်း မေးခဲ့တယ်။
Lennart ရဲ့ အချိုး: ဒီ density မှာ တစ်နာရီ မက်ဆေ့ခ်ျ တစ်ခုက ရေရှည်ထိန်းနိုင်တယ်။ နှစ်နာရီတစ်ကြိမ်ထက် နည်းသွားရင်—ပိတ်ထားနိုင်တယ်။