ไม่ได้ประชดนะ แต่ซาฟารีเองก็คงปฏิบัติตามข้อกำหนดมากมายพวกนั้นได้ดีอยู่แล้ว...ใช่ไหม?

ฉันเป็นสมาชิก Max แค่อ่านอย่างเดียวก็รู้สึกเหมือนโทเคนถูกดูดไปแล้วนะ

ฉันมาที่นี่เพื่อสร้างผลิตภัณฑ์ ไม่ได้มาเพื่อคลุกกับ Kubernetes ทั้งวัน —> นั่นคือคำพูดที่โง่ที่สุดที่ผมเคยได้ยินมา

2. การทำงานแบบขนานระหว่างเว็บกับเครื่องโลคัล

ดูจากภาพในต้นฉบับ เหมือนเขาเปิดใช้งาน 5 ตัวบนเครื่องโลคัล และ 5 ตัวบนเว็บเพื่อทำงานนะครับ มีเหตุผลอะไรเป็นพิเศษหรือเปล่าที่แบ่งเป็น 5 กับ 5 แบบนี้ แทนที่จะใช้บนเครื่องโลคัล 10 ตัวและบนเว็บ 10 ตัวไปเลย?

เป็นโพสต์เกี่ยวกับ AI ที่ไม่มีเนื้อหาสาระเลย แบบนี้แหละช่วงนี้ผมแทบไม่อ่าน Medium แล้ว

ผมก็ช่วยสนับสนุนอยู่บ้าง... ช่วงนี้กำลังใช้อยู่แล้วรู้สึกว่าสนุกดี
ชอบตรงที่มันให้ความรู้สึกเหมือนตั้งใจแก้แค่จุดที่ใช้ C แล้วไม่สะดวก
เอกสารทางการยังดูไม่ค่อยสุกงอมเท่าไร
(ถ้าจะหาฟีเจอร์ต่าง ๆ บางทีก็ไปอธิบายไว้ในที่แปลก ๆ แบบไม่มีปี่มีขลุ่ยบ่อยมาก...)

อยากรู้อนาคตของ StackOverflow

Excalidraw ดีมากจริงๆ

เอาล่ะ ตอนนี้พวกคลั่งไคล้ MSA กำลังจะแห่กันมาแล้ว

ตอนนี้ก็มีบริการที่แปลและนำเสนอบทความจากเว็บไซต์ที่ลิสต์ไว้ด้านบน...

สรุปได้ดีมาก อ่านแล้วเข้าใจง่าย ขอบคุณครับ

นี่คือโพสต์ที่นำมาจาก Hacker News ครับ/ค่ะ โพสต์ส่วนใหญ่ที่ผมนำมาลงก็มาจากเนื้อหาบน Hacker News

https://news.ycombinator.com/item?id=46469845

อย่างที่คุณบอกไว้.. ดูเหมือนว่าผมควรใส่อ้างอิง Hacker News ด้วยนะครับ/ค่ะ

ปกติจะลงทุกเดือนพฤศจิกายน แต่ปีนี้ผมมาแชร์ช้าไปหน่อยนะ
การคาดการณ์เทคโนโลยีของ CTO Amazon หลังปี 2025
การคาดการณ์เทคโนโลยีของ CTO Amazon หลังปี 2024
การคาดการณ์เทคโนโลยีของ CTO Amazon หลังปี 2023
การคาดการณ์เทคโนโลยีของ CTO Amazon หลังปี 2022

สิ่งที่ผมอยากฝากไว้คือ ผมเห็นว่านี่เป็นความเห็นที่ดูเป็นสไตล์ AI มากและไม่มีแหล่งอ้างอิง จึงอยากเสนอว่าไม่ควรแชร์บทความลักษณะนี้ครับ

ยอดเยี่ยมมาก ^^

ขอบคุณสำหรับคำตอบครับ

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

แล้วการเพิ่มขึ้นของความแม่นยำก็น่าทึ่งมากจริง ๆ!
แม้ว่าประสิทธิภาพของ VLM จะดีขึ้นมากแล้ว แต่ถึงอย่างนั้นตอนนี้ก็ยังสู้ประสิทธิภาพของโมเดล YOLO ที่เทรนมาเพื่อจุดประสงค์เดียวโดยเฉพาะไม่ได้อยู่หรือเปล่าครับ?

ขอบคุณที่ถ่ายทอดเคล็ดลับจากประสบการณ์จริงออกมาเป็นบทความครับ
ถ้าผมเจอปัญหาคล้าย ๆ กันบ้าง ผมจะอ้างอิงวิธีที่คุณใช้ไว้แน่นอนครับ

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

อืม... เหมือนมีอะไรแปลก ๆ นะ
บทความนี้ดูเหมือนเขียนด้วย AI ครับ

1) ความน่าเชื่อถือของบทความน่าสงสัย: มีกลิ่นงานการตลาด/งานที่สร้างโดย AI

ใจความหลัก

• “อันนี้มันเรียบเรียงมาเป็นนิทานสอนใจดีเกินไป” → เลยมีคนสงสัยว่ามันเป็นประโยคที่ปรับมาให้เข้ากับ ‘ละครสอนศีลธรรม’ แบบที่ HN ชอบ
• ในเนื้อหามีลิงก์ไปยังแหล่งข้อมูลแบบเสียเงินแปะเต็มไปหมด จนหลายคนมองว่า “สุดท้ายมันก็เป็นบทความขายของไม่ใช่เหรอ”
• สไตล์การเขียนแบบยัดลิสต์รัวๆ/ใช้อีโมจิ ถูกชี้ว่าเป็นสัญญาณของ “AI slop (คอนเทนต์ AI แบบปั่นหยาบๆ)”

คำพูดตรงแรงๆ (แปล)

“ดูเหมือนทั้งเรื่องมีไว้เพื่อขายแหล่งข้อมูลแบบเสียเงินที่ลิงก์ไว้ และมันก็ให้ความรู้สึกเหมือน AI slop จากการยัดลิสต์มาเต็มไปหมด”
(ต้นฉบับ: Seems like the whole thing is just there to sell you on the linked resources. And it feels like AI slop with all the lists.)

สรุปสั้นๆ

• “ก่อนจะเถียงกันว่าเนื้อหาถูกหรือผิด กลิ่นขายของ + กลิ่น AI มันแรงเกินไป” คือปฏิกิริยาอันดับหนึ่ง

2) วิจารณ์ฝั่งผู้นำ/สถาปนิกระบบ: ปัญหาไม่ใช่เทคโนโลยี แต่คือ ‘โครงสร้างการตัดสินใจ’

ใจความหลัก

• หลายคนมองว่าแค่ “ทีม 4 คนแต่มีสถาปนิกระบบ?” ก็เริ่มผิดทางแล้ว
• โดยเฉพาะบทบาทแบบ สถาปนิกที่ไม่เขียนโค้ด/บทบาท DevOps ที่แยกออกมาต่างหาก ถูกมองว่าเป็นทั้ง ‘คอขวด + การออกแบบเพื่อแต่ง CV’
• น้ำเสียงโดยรวมคือไม่ใช่ microservices ที่ทำบริษัทพัง แต่เป็น “โครงสร้างที่ไม่มีใครรับผิดชอบเรื่อง deploy/operate/เก็บกวาดปัญหาอย่างจริงจัง” ต่างหาก

คำพูดตรงแรงๆ (แปล)

“สถาปนิกที่มีหน้าที่กำหนด ‘กฎ’ กับ ‘แพตเทิร์น’ โดยที่ไม่ได้ลงมือทำอะไรจริง แทบจะเป็นไอเดียที่แย่เสมอ แค่โฟกัสที่การปล่อยของก็พอ... ถ้าคนที่ไม่เขียนโค้ดแม้แต่ 10 บรรทัดจะผูกขาดการตัดสินใจ มันก็พังแน่”
(ต้นฉบับ: Architects who's job it is to define 'rules' and 'patterns' without actually implementing anything are almost always a bad idea. Just focus on shipping...)

สรุปสั้นๆ

• มีคนเห็นค่อนข้างมากว่า ไม่ใช่ MSA ที่เป็นปัญหา แต่เป็น ‘การออกแบบบทบาทที่มีอำนาจตัดสินใจแต่ไม่มีความรับผิดชอบ’

3) มุมมองเชิงธุรกิจ: สตาร์ตอัปล้มเหลวเพราะ MSA จริงหรือ?

ใจความหลัก

• มีคอมเมนต์ที่ไม่เชื่อกรอบเรื่องเล่าแบบ “พังเพราะสถาปัตยกรรม” ตั้งแต่ต้น
• ประเด็นหลักคือ ถ้า PMF/ดีมานด์/การล็อกอินลูกค้า อ่อน ไม่ว่าใช้สแตกไหนก็พังได้อยู่ดี
• โดยเฉพาะรายละเอียดอย่าง “ลูกค้าเห็นว่าช้าลงสองวันก็ย้ายออกทันที?” ทำให้มีคนจี้ว่าจริงๆ แล้วคุณค่าของผลิตภัณฑ์มันอาจอ่อนอยู่แล้วหรือเปล่า
• และยังมีการชี้ความขัดแย้งในบทความเองด้วย: บอกว่า “MSA ฆ่าสตาร์ตอัป” แต่บทสรุปกลับเป็น “รอดมาได้?” → เลยยิ่งน่าสงสัยว่าเป็นการเล่าเรื่องเกินจริง

คำพูดตรงแรงๆ (แปล)

“ที่ฆ่าสตาร์ตอัปคือการทำผลิตภัณฑ์ที่คนไม่ต้องการต่างหาก ไม่ใช่สถาปัตยกรรม เรื่องนี้ก็พอๆ กับการบอกว่าเลือก Python แทน Go เลยทำให้สตาร์ตอัปพัง มันฟังไม่ขึ้น”
(ต้นฉบับ: Pretty sure making a product that people don’t want killed your startup. This is like saying using Python vs Go killed your startup...)

สรุปสั้นๆ

• มีมุมมองหนึ่งอย่างชัดเจนว่า “สถาปัตยกรรมเป็นแค่ข้ออ้าง ส่วน ต้นเหตุจริงอาจเป็นตลาด/ผลิตภัณฑ์/กระแสเงินสด”

4) ข้อคิดทางเทคนิค: คำแนะนำจากประสบการณ์จริงเรื่อง monolith vs MSA (ส่วนที่เป็นประโยชน์จริง)

ใจความหลัก

• “MSA มีภาษีต้นทุนคงที่ (ความซับซ้อนในการปฏิบัติการ)” → หลายคนมีประสบการณ์ตรงว่ามันอาจเป็นหมัดหนักสำหรับทีมเล็ก
• คีย์เวิร์ดสำคัญคือ Premature distribution (กระจายระบบเร็วเกินไป), modular monolith/modulith, และ “จง ‘หาให้ได้’ ก่อนว่าขอบเขตอยู่ตรงไหน”
• เงื่อนไขที่ MSA เริ่มจำเป็นก็ถูกเสนออย่างเป็นจริงเป็นจัง: ตอนที่ทีมใหญ่ขึ้นจนปัญหาเรื่องการชนกันของงาน/deploy/โครงสร้างองค์กรเกิดขึ้นจริง
• ในทางกลับกัน ถ้าเป็นปัญหาเรื่องประสิทธิภาพ/การขยายระบบ หลายคนก็แนะนำว่าโดยมากไม่ใช่ “แก้ด้วย MSA” แต่ควรเริ่มจากดู algorithm/คอขวด/sharding/partitioning ก่อน

คำพูดตรงแรงๆ (แปล)

“ที่ฆ่าสตาร์ตอัปไม่ใช่ microservices แต่คือ ‘การกระจายระบบเร็วเกินไป’ ต่างหาก คุณแยกระบบก่อนที่ขอบเขตจริงจะเกิดขึ้น เลยมีแต่ต้นทุนด้าน latency กับการประสานงาน ควรเริ่มจาก modular monolith แล้วค่อยๆ สร้างขอบเขตให้ชัดก่อนค่อยแยก”
(ต้นฉบับ: Premature distribution killed the startup, not microservices... Start with a modular monolith, earn your boundaries, then extract.)

สรุปสั้นๆ

• บทเรียนที่ชุมชนเห็นพ้องจริงๆ คือข้อนี้:
  “เริ่มจาก monolith แล้วค่อยแยก service ก็ต่อเมื่อขอบเขตมัน ‘เกิดขึ้นเองตามธรรมชาติ’ เท่านั้น”

สรุปภาพรวมของชุมชนในประโยคเดียว

คนส่วนใหญ่เห็นด้วยกับประโยคว่า “เราไม่ใช่ Netflix” แต่ในขณะเดียวกันก็สงสัยแรงเหมือนกันว่า ตัวบทความเองอาจเป็นเรื่องเล่าแบบขายฝันโรค Netflix (=การตลาด/AI) ก็ได้

เพราะสหรัฐฯ ยังมี IPv4 มากพออยู่เลยครับ ประเทศเราก็เหมือนกัน