การประชุมที่กลับมาหาเจอได้จริง ๆ: รีลีส Timeline

พอถึงเดือนมกราคม 2026 ผู้ใช้ GeekBye ก็มีปัญหาเรื่องประวัติการประชุม แอปอัดเสียงและวิเคราะห์การประชุมได้ดีไม่มีที่ติ — แล้วก็เอาผลลัพธ์ไปเก็บใส่ dropdown ซึ่ง dropdown น่ะโอเคอยู่ถ้ามีสามรายการ แต่พอถึงการประชุมที่สิบห้า "สัมภาษณ์เมื่อวันอังคารที่แล้วอันนั้น" ก็กลายเป็นภารกิจขุดค้นทางโบราณคดีท่ามกลางแถวที่หน้าตาเหมือนกันไปหมด v1.7.3 — 64 คอมมิตระหว่างกลางเดือนธันวาคมถึง 16 มกราคม — คือรีลีสที่ทำให้การประชุมกลายเป็นสิ่งที่กลับมาหาเจอได้จริง ๆ เสียที

(ขอจดบันทึกทางบัญชีไว้สักหน่อย เพราะประวัติ git นั้นซื่อสัตย์แม้เลขเวอร์ชันจะไม่: ไม่มี tag รีลีส v1.7.2 อยู่จริง เวอร์ชันถูก bump ไปแล้ว แต่ tag ถัดไปที่ได้ ship คือ v1.7.3 งานแก้ฝั่ง Windows ยุค v1.7.2 จึงติดรถมากับรีลีสนี้ด้วย)

จาก dropdown สู่ timeline

การเปลี่ยนแปลงพาดหัวคือ pull request เดียว: 12 ไฟล์, +640 บรรทัด ส่วนใหญ่คือคอมโพเนนต์ใหม่ MeetingsTimeline ขนาด 381 บรรทัด dropdown กลายเป็น timeline แบบเลื่อนได้ของการ์ดการประชุม จัดกลุ่มเป็นสี่หมวด — Today, Yesterday, This Week, Older — พร้อมวันที่ที่แสดงแบบเดียวกับที่มนุษย์พูดกันจริง ๆ: Today, 2:30 PM, Yesterday, 2:30 PM, Mon, 2:30 PM สำหรับสัปดาห์นี้ และ Jan 5, 2:30 PM สำหรับที่เก่ากว่านั้น กด Cmd/Ctrl+K เพื่อโฟกัสช่องค้นหาที่กรองตามชื่อเรื่อง หน้ารายละเอียดการประชุมกลายเป็นหน้า navigation ของจริง ปุ่ม back และ forward บน navbar จึงมีความหมายขึ้นมาเสียที และ breadcrumb ก็เลิกเขียนว่า "Meetings / Meeting" แล้วหันมาเขียนว่า "Meetings / Interview with John" (ตัดท้ายด้วย ellipsis เพราะยังไงก็ต้องมีคนตั้งชื่อการประชุมยาวราวกับนิยาย)

มีของเพิ่มคุณภาพชีวิตชิ้นเล็ก ๆ สองชิ้น ship มาด้วยกัน: ปุ่มลบภายในหน้าการประชุม (ซึ่งพาคุณกลับไปที่ timeline หลังลบเสร็จ แทนที่จะทิ้งคุณไว้บนหน้าที่ตายไปแล้ว) และ auto-navigation — เมื่อ session การฟังจบลงพร้อมเนื้อหา transcript จริง ๆ แดชบอร์ดจะเปิดตรงเข้าหน้ารายละเอียดของการประชุมนั้นทันที วางสายปุ๊บ เห็นการประชุมปั๊บ ส่วน session ที่จบแบบว่างเปล่าจะถูกลบไปเงียบ ๆ แทนที่จะมารก timeline

race ที่คุณสร้างขึ้นเองจากการปรับปรุง navigation

นี่คือส่วนที่ changelog ไม่บอกคุณ รายการประชุมแบบเก่ามีนิสัยอยู่อย่างหนึ่ง: ทุกครั้งที่โหลด มันจะ auto-select session ที่ใหม่ที่สุด ไม่มีพิษภัยตอนที่รายการยังเป็น dropdown ที่แทบไม่ได้แตะ แต่กลายเป็นเรื่องคอขาดบาดตายทันทีที่การประชุมกลายเป็นหน้าที่คุณ navigate ได้: คลิกการประชุม #5 แล้ว background refetch ทำงานเสร็จพอดี รายการก็ "หวังดี" เลือกการประชุมที่ใหม่ที่สุดให้ — ทับตัวเลือกที่คุณเพิ่งกดไปเมื่อสองวินาทีก่อน ตัวแก้ไม่ใช่ guard ที่ฉลาดกว่าเดิม แต่คือการลบ auto-select ทิ้งทั้งยวง รายการใดก็ตามที่เลือกของแทนผู้ใช้ สุดท้ายจะต้องสู้กับผู้ใช้เอง

พอถอดมันออกก็เผยให้เห็น race ตัวที่สอง auto-navigation กระโดดไปที่การประชุมวินาทีที่ session ของมันจบ — ซึ่งอาจเกิดก่อนที่ session นั้นจะเขียนลงฐานข้อมูล SQLite ในเครื่องเสร็จ navigate เร็วเกินไปก็จะไปถึงการประชุมที่ยังไม่มีตัวตน ตัวแก้ที่ ship ออกไปคือดีเลย์ 500 มิลลิวินาทีก่อนโหลด sessions เมื่อมาถึงหน้ารายละเอียด และตัว handler ของ navigation ก็มีเบาะรองกันกระแทกของตัวเอง — รอ did-finish-load ของหน้าต่างบวกอีก 100ms ถ้าแดชบอร์ดเพิ่งถูกสร้าง หรือ 50ms ถ้ามันเปิดอยู่แล้ว มุมมองของเรา: การ navigate ตอน session จบต้องข้ามโดเมนเวลาสามโดเมน — การเขียนฐานข้อมูล การโหลดหน้าต่าง และการ mount ของ React — และแต่ละโดเมนก็ได้ดีเลย์เล็ก ๆ ไปคนละก้อน มันใช้งานได้ และเราขอพูดตรง ๆ ว่ากอง magic number แบบนี้คือหนี้ทางเทคนิคที่รับสภาพกันซึ่ง ๆ หน้า ไม่ใช่ชัยชนะ

screenshot ที่เกิดก่อนการประชุมของตัวมันเอง

สมมติฐานอีกข้อหนึ่งตายลงในรีลีสนี้: "screenshot เป็นของ session ก็ต่อเมื่อถูกถ่ายระหว่าง session เท่านั้น" ฟังดูมีเหตุผลเป๊ะ แต่ผิด ผู้ใช้ตัวจริงกด Cmd+H ใส่ประกาศรับสมัครงาน วาระการประชุม โค้ดที่กำลังจะคุยกัน — ก่อนกดปุ่ม Start แท็บ Report จับคู่ screenshot กับช่วงเวลาของ session แบบเคร่งครัด screenshot เตรียมงานพวกนั้นจึงหายไปจากรีพอร์ตที่มันถูกถ่ายมาเพื่อสิ่งนั้นแท้ ๆ ตัวแก้คือขยายหน้าต่างการจับคู่ออกไป 60 วินาทีก่อน session เริ่ม (ตัวกลไก time-range เองนั้นเก่ากว่านั้น — มัน ship มาเงียบ ๆ ตั้งแต่ v1.6.15 สิ่งที่ v1.7.3 เพิ่มเข้ามาคือการสอนมันว่าการประชุมเริ่มก่อนเวลาที่มันเริ่มอยู่นิดหน่อย)

แก้ 5 ครั้งใน 28 นาที

เรื่องเล่าจากสนามจริงของรีลีสนี้ไม่ได้อยู่ใน timeline เลย — มันอยู่ใน overlay ของ onboarding บน Windows และมันคือเชน "แก้ทับตัวแก้" ระดับตำราเรียน: 5 คอมมิตระหว่าง 10:50–11:18 ของเช้าวันเดียวกัน

หน้าต่างหลักของ GeekBye ใช้ mouse passthrough — hook ตัวหนึ่งที่สลับ setIgnoreMouseEvents ของ Electron ทุกครั้งที่เมาส์ขยับ เพื่อให้คลิกทะลุผ่านพื้นที่โปร่งใสลงไปได้ ระหว่าง onboarding บน Windows hook ตัวนั้นตีกันกับ overlay ของ tutorial และที่ขั้นตอนที่หน้าต่างแดชบอร์ดโผล่ขึ้นมา แอปก็ ค้าง ตัวแก้ที่หนึ่ง: ให้ hook ไม่ต้องทำอะไรเลยระหว่างที่ onboarding ทำงานอยู่ สงบศึกด้วยการวางอาวุธ

เว้นแต่ว่าคราวนี้ปุ่มของ onboarding กลับไม่ตอบสนอง เพราะ event forwarding ส่งคลิกไปให้หน้าต่างแดชบอร์ดที่อยู่ข้างใต้ overlay ตัวแก้ที่สองและสามไปนั่งจูน forward: false ทีละ wizard แล้วก็มาถึงคอมมิตที่เจอต้นตอตัวจริง: ตอนที่หน้าต่างแดชบอร์ดเปิดขึ้น drag handler ของมันจะรีเซ็ตหน้าต่างหลักกลับเป็นโหมด click-through — และตัวแก้แรกได้ทำให้ passthrough hook กลายเป็น passive ไปเรียบร้อยแล้ว แปลว่า ไม่เหลือใครที่จะคอยแก้การแทรกแซงนั้นได้อีก ตัวแก้ของจริงพลิกกลยุทธ์กลับด้าน: ตอนนี้ hook จะยืนยัน setIgnoreMouseEvents(false) ซ้ำอย่างแข็งขันทุกครั้งที่เมาส์ขยับระหว่าง onboarding ก็เพราะโค้ดภายนอกสามารถรีเซ็ตมันได้ทุกเมื่อนั่นแหละ พร้อมกันนั้นก็ลบ workaround ต่อ wizard ของรอบก่อนหน้าออกไป 75 บรรทัด

แล้วถึงอย่างนั้นก็ยังมีคอมมิตที่ห้า เพราะชนะสงคราม input ไม่ได้แปลว่าชนะสงคราม z-order: overlay กับแดชบอร์ดนั่งอยู่ที่ระดับ always-on-top เดียวกัน และ Windows จะยกหน้าต่างไหนก็ตามที่ได้โฟกัสขึ้นบนสุด overlay จึงย้ายไปอยู่ระดับหน้าต่างที่สูงกว่า และยกตัวเองขึ้นซ้ำแบบหน่วงเวลาหลังแดชบอร์ดโผล่ขึ้นมา เส้นเรื่องนี้ควรค่าแก่การจดจำ: ตัวแก้แบบ passive ที่ปลดอาวุธผู้พิทักษ์เพียงคนเดียวของคุณ แย่ยิ่งกว่าศึกตั้งต้นเสียอีก

สามสิ่งที่รีลีสนี้สอนเรา

1. การอัปเกรด navigation ขุดบั๊กเรื่อง state ขึ้นมาให้เห็น race ของ auto-select มีอยู่ก่อน v1.7.3 อยู่แล้ว แค่ dropdown ไม่เคยเปิดโอกาสให้คุณรู้สึกถึงมัน ทันทีที่การประชุมกลายเป็นหน้าที่คุณตั้งใจ navigate เอง โค้ดทุกชิ้นที่เลือกอะไรแทนคุณก็กลายเป็นบั๊ก
2. ขอบเขตเวลารอบเจตนาของผู้ใช้ต้องมีระยะเผื่อ sessions, การอัดเสียง, รีพอร์ต — ผู้ใช้ลงมือก่อนและหลังหน้าต่างเวลาอย่างเป็นทางการของเครื่องอยู่เล็กน้อยเสมอ บัฟเฟอร์ screenshot 60 วินาทีคือโค้ดบรรทัดเดียวที่สะท้อนพฤติกรรมจริงของคน
3. อย่าทำให้โค้ดที่มีหน้าที่แก้สถานการณ์กลายเป็น passive เด็ดขาด อาการค้างบน Windows กินไป 5 การแก้ ก็เพราะตัวแก้แรกปิดกลไกเดียวที่ต้านการแทรกแซงจากภายนอกได้ ถ้าโค้ดอื่นสามารถทำลาย invariant ของคุณได้ทุกเมื่อ งานของคุณคือยืนยันมันซ้ำอย่างต่อเนื่อง ไม่ใช่วางมือ

สำหรับบทก่อนหน้าของเรื่องราวยุค v1 — การสร้างแอปสองแบรนด์จากโค้ดเบสเดียวนี้ — ดูโค้ดเบสเดียว สองแอป: วิธีทำ white-label โดยไม่ต้อง fork (v1.7.1); และสำหรับภาพรวมทั้งเส้นเรื่อง ดูกายวิภาคของการส่งมอบซอฟต์แวร์ให้สมบูรณ์แบบ