หนุ่มเอ๋ย... เอาราคาบ้านของฉันคืนมานะ...

ตอนนี้ใช้บริการแบบสมัครสมาชิกรายเดือนอยู่ครับ 😢 ดูเหมือนว่าค่าใช้จ่ายจะไม่น้อย เลยกำลังกังวลเรื่องความยั่งยืนอยู่ครับ

โครงสร้างการจัดหมวดหมู่ช่วยให้เราพอมองออกว่าในดีไซน์ของเรา กลยุทธ์ไหนที่ใช้งานได้จริง

ก่อนจะจัดการฝั่ง "ให้ได้แต่ไม่ให้" ด้วย wrapper ดูเหมือนว่าควรเริ่มดูจาก 149 เคสก่อน น่าจะถูกต้องกว่า ถ้าใน response มี ID แต่แมปไม่สำเร็จ ก็มีโอกาสสูงว่าจะเป็นปัญหาเรื่อง convention ของชื่อฟิลด์ (id / _id / resource_id / document_id) หรือไม่ก็เพราะเป็นโครงสร้างซ้อน (result.data.id) 149 เคสนี้เป็นขอบเขตที่น่าจะแก้ได้แค่ปรับ mapping layer โดยไม่ต้องแก้ API

ส่วนฝั่ง "ให้ไม่ได้" น่าจะต้องเข้าหาแตกต่างกันไปตามแต่ละเครื่องมือ

• write_file ถ้าใช้การจับคู่ path + content hash ก็ตรวจจับได้ว่า "เขียนเนื้อหาเดิมซ้ำสองครั้งหรือไม่"
• k8s scale ถ้าจำนวน replica เป้าหมายเท่ากับค่าปัจจุบันอยู่แล้ว ก็แทบจะเป็น idempotent ในทางปฏิบัติ — ใช้การตรวจสอบสถานะล่วงหน้าก็กันการรันซ้ำได้ตั้งแต่ต้น
• click ต่างออกไป การใส่ ID ให้ตัวแอ็กชันเองไม่ได้มีความหมายมากนัก และดูเหมือนว่าแนวทางที่สมจริงกว่าคือเปรียบเทียบ snapshot ก่อนและหลังว่า "การเปลี่ยนแปลงสถานะที่ click นี้ตั้งใจจะให้เกิดขึ้น เกิดขึ้นไปแล้วหรือยัง"

สิ่งที่เรากำลังพิจารณากันภายในคือการทำเมทริกซ์เครื่องมือด้วยเกณฑ์ "สามารถคืนค่า ID ได้หรือไม่ × ประเภทของการเปลี่ยนแปลงสถานะ" แล้วค่อยแตกแขนงกลยุทธ์การจัดการ ถ้าแชร์เพิ่มได้ว่า 149 เคสนี้กระจุกอยู่กับแพตเทิร์นไหน จะช่วยในการวางกลยุทธ์การแมปได้มากครับ

ใช่ครับ! โมเดลถูกสร้างโดยอิงจากขนาดมาตรฐานยอดนิยม
อย่างไรก็ตาม สำหรับอพาร์ตเมนต์ที่ไม่มีขนาดมาตรฐานยอดนิยม ระบบถูกพัฒนาให้คาดการณ์จากขนาดตัวอย่างหลายขนาดครับ

ลองใส่อพาร์ตเมนต์เก่าที่คุณพ่อคุณแม่อาศัยอยู่ดูแล้ว..
แสดงเฉพาะแบบ 33 พยองเท่านั้น.. แต่อพาร์ตเมนต์เก่าแห่งนี้มีทั้ง 33 พยองและ 26 พยองอยู่ด้วยกัน
เดิมทีรองรับเฉพาะ 33 พยองเท่านั้นหรือครับ?

ว้าว~ นี่เป็นบริการที่ผมเองก็อยากทำเหมือนกันครับ ถ้าทำการครอว์ลแบบนี้ พอจะทราบไหมว่าค่าใช้จ่ายของ Supabase จะอยู่ประมาณเท่าไหร่?

ทั้งวิดีโอและไฟล์บันทึกเสียงถูกเสิร์ฟผ่านเซิร์ฟเวอร์ทั้งหมดหรือเปล่าครับ?

ดูเหมือนในบทความผมจะลืมใส่ฟีเจอร์แชร์อพาร์ตเมนต์ไปนะครับ ฮ่าๆ เลยขอทิ้งลิงก์แชร์ของ Helio City ซึ่งเป็นคอมเพล็กซ์ขนาดใหญ่ที่มีชื่อเสียงไว้ให้ลองทดสอบสักลิงก์ครับ
(ผลการคาดการณ์ดูเพื่ออ้างอิงเท่านั้นนะครับ และหากต้องการรายละเอียดการทำโมเดลเพิ่มเติม รบกวนดูใน white paper!)
เปิดได้ทันทีโดยไม่ต้องล็อกอิน ลองกดเข้าไปดู UI กราฟกันได้สบายๆ ครับ
https://app.apt-insights.com/s/apt/9NPumhVmCv

มีแอปฟรีเยอะ แถมทำก็ง่าย ถ้าเป็นแอปเสียเงินก็คงอืม...

ขอบคุณสำหรับการแจ้งครับ แก้ไขแล้ว!!

ลิงก์เอกสารไวท์เปเปอร์ทางเทคนิคเกิดข้อผิดพลาด 404 อยู่ครับ!
https://edge.apt-insights.com/v1/public/whitepaper

โอ๊ย ผมเพิ่งรู้จากโพสต์นี้เป็นครั้งแรกว่ามีเว็บ cppreference ภาษาเกาหลีอยู่ด้วย เลยดีใจมาก..
แต่ดูเหมือนว่าจะต้องใช้เว็บภาษาอังกฤษแบบเดิมต่อไปนะครับ

อ๋อ ผมไม่ได้ใช้ Windows มานานแล้ว เลยไม่ค่อยรู้ครับ ลองค้นดูแล้วก็ดูคล้ายกันอยู่

หากแบ่ง 3,197 กรณีตามสาเหตุ จะได้ดังนี้

ไม่มีฟิลด์ ID ในการตอบกลับเลย: 2,011 กรณี (62.9%)
การเรียกใช้ล้มเหลวด้วยข้อผิดพลาด: 1,037 กรณี (32.4%)
มี ID ในการตอบกลับ แต่ระบบ mapping ของเราจับไม่ได้: 149 กรณี (4.7%)

ตรงนี้ขอแก้ไขอย่างหนึ่งครับ เมื่อกี้คุณบอกว่า “การซ้ำส่วนใหญ่เกิดในช่วงที่ตามรอยไม่ได้ตั้งแต่ต้น” แต่ 32% เป็นกรณีที่การเรียกใช้ล้มเหลวครับ เมื่อไม่มีอะไรเกิดขึ้น ก็ไม่มีสิ่งให้ตามรอยจริง ๆ กรณีที่ “เกิดขึ้นแล้วแต่ตามรอยไม่ได้” จริง ๆ คือ 2,011 กรณีครับ ยังเป็นตัวเลขที่มากอยู่ แต่ก็น้อยกว่า 3,197

มีเครื่องมือ 24 รายการที่คืนค่าแค่สำเร็จ/ล้มเหลว หากจัดกลุ่มตามประเภท:

การควบคุมเบราว์เซอร์ (9 รายการ) — click, type, navigate ฯลฯ เฉพาะ click อย่างเดียว 719 กรณี
ไฟล์ซิสเต็ม (3 รายการ) — write_file, edit_file, move_file
Kubernetes (4 รายการ) — scale, create, apply, delete
การแก้ไขเอกสาร (3 รายการ) — add_paragraph, add_heading, format_text
รายการเดี่ยว — emails-send_email, excel-write_data_to_excel, snowflake-write_query, logging_write_log, github-fork_repository, github-create_repository

24 รายการนี้แบ่งออกเป็นสองประเภท ผมขอเสริมไว้เพราะน่าจะมีประโยชน์ต่อการออกแบบสเปก

ฝั่งที่ให้ ID ไม่ได้ การคลิกในเบราว์เซอร์หรือการแก้ไขไฟล์ตั้งแต่แรกไม่มี “เอนทิตีที่ถูกสร้างขึ้น” อยู่แล้ว จะใส่ ID ให้การคลิกก็ไม่ได้ ส่วนไฟล์ก็มี path เป็นตัวระบุอยู่แล้ว

ฝั่งที่ให้ได้แต่ไม่ให้ github-create_repository เป็นตัวอย่างชัดเจน หากสร้าง repository แล้วก็ย่อมมี ID แน่นอน แต่ใน response กลับไม่มี emails-send_email ก็มี message ID ในระดับ SMTP แต่ไม่คืนค่ากลับมา เช่นเดียวกับ github-fork_repository, excel-write_data_to_excel

ประเภทหลังคือฝั่งที่แก้ได้ครับ หากจะใส่ในสเปกเครื่องมือภายในว่า “กลุ่มที่สร้างสิ่งใหม่ต้องมี entity ID ใน response” การแบ่งแบบนี้น่าจะใช้เป็นเกณฑ์ตัดสินได้ว่าจะนำไปใช้กับที่ไหน

ส่วน 149 กรณีสุดท้ายเป็นปัญหา mapping ของเราเอง กระจุกอยู่ที่ notion database-query 102 กรณี และ pptx open_presentation 28 กรณี ซึ่งทั้งสองเป็นเครื่องมือที่เราตั้งใจให้อยู่นอกขอบเขต จึงจับไม่ได้ นี่ไม่ใช่ปัญหาการออกแบบเครื่องมือ แต่เป็นปัญหา coverage ของเรา

ไม่ทราบว่าในสแตกที่คุณใช้งานจริงตอนนี้ งานเขียนกระจุกอยู่ฝั่งไหนครับ? สิ่งที่เราเห็นเป็น benchmark เลยคิดว่าองค์ประกอบของเครื่องมือคงต่างจากงาน production จริง

เวอร์ชันภาษาเกาหลีอัปเดตล่าสุดตั้งแต่ปี 2016 แล้ว ดังนั้นน่าจะดูต้นฉบับจะดีกว่า

• https://cppreference.com/cpp/links/libs

หากสามารถก้าวไปข้างหน้าได้แม้เพียงวันละก้าว เท่านั้นก็เพียงพอแล้ว
นี่คือยุคที่การผลิตทำได้ง่ายขึ้น การตรวจสอบความถูกต้องละเอียดประณีตขึ้น และท้ายที่สุด “การเลือก” กลายเป็นหัวใจสำคัญ ด้วยเหตุนี้ สายตาที่อ่านกระแสได้อย่างแม่นยำจึงยิ่งสำคัญกว่าเดิม

น่าจะคล้ายกับฟีเจอร์พื้นฐานของ Windows หรือเปล่าครับ? Windows + V

ว้าว ถ้ามีตัวนี้ตัวเดียว เรื่องอย่างการเล่นบทบาทสมมติก็คงไม่ต้องกังวลแล้วสินะครับ

อ๊ะ แก้ไขไว้แล้วครับ

ทุกวันนี้โค้ดดิ้งเอเจนต์สามารถช่วยเติมเต็มส่วนที่เรายังขาดได้ ผมเลยคิดว่าถ้าเรารู้จุดแข็งของตัวเองอย่างชัดเจนและนำมันมาใช้ให้ดี อุปสรรคในการเริ่มต้นก็อาจลดลงได้
สำหรับผม ปัญหามักอยู่ที่การทำเอกสารมาโดยตลอด แต่พอผมมอบหมายส่วนนี้ให้โค้ดดิ้งเอเจนต์ทำได้ในระดับหนึ่ง ภาระก็ลดลง และเมื่อได้ตรวจทานเอกสารที่ทำออกมา ก็รู้สึกว่าตัวเองเริ่มมีสายตาในการมองงานเอกสารมากขึ้นด้วย