heycalmdown 2025-09-23 | ความคิดเห็นหลัก | ใน: Backlog.md - ตัวจัดการงานบนพื้นฐาน Markdown สำหรับ Git Repo เพื่อการทำงานร่วมกับ AI (github.com/MrLesk) โอ้.. ดูเข้าท่าดีนะ supermaxi 2025-09-23 | ความคิดเห็นหลัก | ใน: React กำลังชนะเพราะเป็นค่าเริ่มต้น และกำลังทำให้นวัตกรรมฝั่งฟรอนต์เอนด์ช้าลง (lorenstew.art) นักพัฒนารุ่นจูเนียร์จะเลือก React ก็เป็นเรื่องที่หลีกเลี่ยงไม่ได้ แต่ปัญหาคือนักพัฒนารุ่นซีเนียร์กลับหยุดคิดถึงทางเลือกอื่นไปเสียแล้ว supermaxi 2025-09-23 | ความคิดเห็นหลัก | ใน: pgschema - เครื่องมือย้ายสคีมา Postgres แบบประกาศเชิงประกาศสไตล์ Terraform (github.com/pgschema) เป็นเนื้อหาที่น่าสนใจครับ kbumsik 2025-09-22 | ความคิดเห็นหลัก | ใน: ฆาตกรที่มองไม่เห็นของสตาร์ทอัพ: การยึดติดกับบทบาทของผู้ก่อตั้ง (linkedin.com) > ปฏิเสธการดึงคนเก่งที่เหนือกว่าตัวเองเข้ามาร่วมงาน ผมเห็นแบบนี้บ่อยมาก ไม่ใช่แค่ในหมู่ผู้ก่อตั้ง แต่รวมถึงในระดับผู้นำด้วย kofmania 2025-09-22 | ความคิดเห็นหลัก | ใน: ฆาตกรที่มองไม่เห็นของสตาร์ทอัพ: การยึดติดกับบทบาทของผู้ก่อตั้ง (linkedin.com) จากประสบการณ์ ผมเห็นด้วยกับข้อ 3 มาก ahwjdekf 2025-09-22 | ความคิดเห็นหลัก | ใน: แปลง PDF เป็น Markdown ด้วย markitdown และ LLM (velog.io) ฟอร์แมตที่แย่ที่สุด, PDF slowmo 2025-09-22 | ความคิดเห็นหลัก | ใน: โฮสต์เว็บไซต์ด้วยบุหรี่ไฟฟ้าแบบใช้แล้วทิ้ง (bogdanthegeek.github.io) พอคอมเมนต์ไปแล้วก็ทำให้นึกสงสัยขึ้นมาว่า ถ้าเป็นตู้ขายของอัตโนมัติในคาเฟ่ไร้พนักงาน เขาตรวจสอบอายุผู้ซื้อกันยังไงนะ สงสัยว่าที่ตู้มีฟังก์ชันสแกนบัตรประชาชนด้วยหรือเปล่า.. slowmo 2025-09-22 | ความคิดเห็นหลัก | ใน: โฮสต์เว็บไซต์ด้วยบุหรี่ไฟฟ้าแบบใช้แล้วทิ้ง (bogdanthegeek.github.io) ฉันเองก็ไม่สูบบุหรี่เลยไม่รู้มาก่อน แต่ไม่นานมานี้พอเห็นว่าคาเฟ่อัตโนมัติที่เพิ่งเปิดแถวบ้านมีตู้ขายบุหรี่ไฟฟ้าแบบใช้แล้วทิ้งอยู่ด้วยก็เลยได้รู้ ด้านล่างนี้คอมเมนต์ใน Hacker News ครึ่งหนึ่งก็คงเป็นเรื่องการสิ้นเปลืองทรัพยากรอย่างน่าเหลือเชื่อเหมือนกันนะ 555 slowmo 2025-09-22 | ความคิดเห็นหลัก | ใน: ค้นพบอัลกอริทึมเส้นทางสั้นที่สุดแบบใหม่ในรอบ 41 ปี (arxiv.org) ทำให้นึกถึงความทรงจำ(?) ตอนที่ทำงานอยู่บริษัทซอฟต์แวร์ระบบนำทางรถยนต์และพัฒนาโมดูลค้นหาเส้นทางในช่วงปลายยุค 2000 ขึ้นมาเลย Dijkstra ช้าเกินไปสำหรับการค้นหาเส้นทางในระบบนำทางเลยไม่ค่อยใช้กัน แต่จะใช้การค้นหาแบบ A* (A Star) ซึ่งเป็นเวอร์ชันที่ปรับปรุงด้วยฮิวริสติกแทน พอลองค้นดูก็พบว่า A* ไม่ใช่อัลกอริทึม SSSP แต่เป็นอัลกอริทึม SPSP (Single-Pair Shortest Path) นั่นเอง trr245 2025-09-22 | ความคิดเห็นหลัก | ใน: Learn Your Way: พลิกโฉมตำราเรียนด้วย Generative AI (research.google) ในฐานะคนที่เคยลองทำสิ่งนี้มาก่อน ขอบอกว่าการทำให้เป็นแบบเฉพาะบุคคลจำเป็นต้องใช้ข้อมูลมาก อาจมากกว่า 2 กิกะไบต์ kbumsik 2025-09-22 | ความคิดเห็นหลัก | ใน: แปลง PDF เป็น Markdown ด้วย markitdown และ LLM (velog.io) markitdown สะดวกสำหรับการแปลงข้ามฟอร์แมต แต่กับ PDF ไม่ควรใช้เด็ดขาดเลย จริงๆ ทุกวันนี้มีวิธีใช้มัลติโหมด LLM อย่าง Gemini สำหรับการดึงข้อมูลเอกสารออกมาเยอะมากแล้ว และผลบนเบนช์มาร์กก็ค่อนข้างดีทีเดียว เพียงแต่ปัญหาคือค่าใช้จ่าย พวกอย่าง docling ก็ดีเหมือนกันครับ kbumsik 2025-09-22 | ความคิดเห็นหลัก | ใน: pgschema - เครื่องมือย้ายสคีมา Postgres แบบประกาศเชิงประกาศสไตล์ Terraform (github.com/pgschema) ฟังก์ชันหรือแนวทางดูเหมือนจะคล้ายกับ Atlas นะครับ: https://atlasgo.io/ zetbouaka 2025-09-22 | ความคิดเห็นหลัก | ใน: ฆาตกรที่มองไม่เห็นของสตาร์ทอัพ: การยึดติดกับบทบาทของผู้ก่อตั้ง (linkedin.com) เห็นด้วยกับกับดักหลักทั้งสามข้อนี้มาก แค่มี gatekeeper คนเดียวก็ทำให้เกิดผลเสียหลายอย่างแล้วเหมือนกัน preserde 2025-09-22 | ความคิดเห็นหลัก | ใน: React กำลังชนะเพราะเป็นค่าเริ่มต้น และกำลังทำให้นวัตกรรมฝั่งฟรอนต์เอนด์ช้าลง (lorenstew.art) จะเรียกว่าระดับล่างก็ไม่เชิง... ถ้าจะทำฟอร์ม แค่ใช้แท็ก input ของ HTML ก็น่าจะพอแล้ว แต่กลับต้องไปรู้เรื่อง state, JSX, คอมโพเนนต์แบบ uncontrolled/controlled โดยไม่จำเป็น แถมยังต้องเขียนโค้ดเพิ่มอีกมาก ผมเลยคิดว่าสิ่งเหล่านั้นน่าจะเป็นแรงจูงใจของบทความต้นฉบับ preserde 2025-09-22 | ความคิดเห็นหลัก | ใน: โฮสต์เว็บไซต์ด้วยบุหรี่ไฟฟ้าแบบใช้แล้วทิ้ง (bogdanthegeek.github.io) ฉันไม่ได้สูบบุหรี่เลยนึกไม่ออกว่าเขาพูดถึงอะไร ที่แท้กำลังบอกว่าแม้จะเป็นของใช้แล้วทิ้ง แต่กลับใช้ทรัพยากรมากเกินไปนี่เอง cosine20 2025-09-22 | ความคิดเห็นหลัก | ใน: RustGPT: LLM แบบทรานส์ฟอร์เมอร์ล้วนที่สร้างขึ้นใหม่ทั้งหมดด้วย Rust (github.com/tekaratzas) บารมีของคาร์ม่า -47 สุดจัดเลย 555 kayws426 2025-09-22 | ความคิดเห็นหลัก | ใน: Public static void main(String[] args) ตายแล้ว (mccue.dev) ฟังดูเหมือนว่าพอมีวิธีใหม่เพิ่มเข้ามาอีกวิธี ก็เลยบอกว่าวิธีเดิมตายไปแล้ว จริง ๆ แล้วหมายความว่าไม่สามารถใช้วิธีเดิมได้อีกต่อไป และจำเป็นต้องใช้วิธีใหม่เท่านั้นจริงหรือ? heycalmdown 2025-09-22 | ความคิดเห็นหลัก | ใน: Spec Kit ของ GitHub - พัฒนาซอฟต์แวร์คุณภาพสูงได้เร็วขึ้น (github.com/github) ผมเห็นด้วยกับแนวคิดนี้มาก เลยลองทดสอบกับโปรเจ็กต์ใหม่ในช่วงสุดสัปดาห์ดูบ้าง แต่ผลลัพธ์ก็ยังไม่ดีเท่าที่คิดครับ ดูเหมือนว่ายังต้องปรับปรุงอีกมาก อย่างแรก ลำดับการทำงานคร่าว ๆ ก็เป็นแบบที่มีการแนะนำกันมาหลายครั้งแล้วดังนี้: เขียน constitution → เขียน spec → เขียน task → ลงมือ implement ปัญหาคือ ไฟล์ constitution.md เป็นไกด์หลักเกี่ยวกับ "จะพัฒนาอย่างไร" แต่ไม่ได้บรรจุว่า "สุดท้ายแล้วแอปนี้จะเป็นอะไร" spec.md เป็นเอกสารที่อธิบายฟีเจอร์หนึ่งรายการ ไม่มีเอกสารแม่บทที่อธิบายว่า "แอปนี้คืออะไร" พอลองอ่านการถกเถียงที่เกิดขึ้นบน GitHub ก็ดูเหมือนว่า chain of specs จะกลายเป็น source of truth ในที่สุด — ฟังแล้วก็ยังแปลก ๆ แต่พอจะเข้าใจได้คร่าว ๆ มีการสร้างเอกสารจำนวนมากเป็นผลลัพธ์ผ่านคำสั่ง /specify และ /tasaks (ซึ่งก็เป็นผลลัพธ์ที่ต้องการ) แต่เพราะอย่างนั้นก็เลยกิน context เร็วมาก (ตอนนี้ใช้ Claude Code อยู่) พอเริ่มลงมือ implement จริง ก็จะห่างจาก Spec Kit ไปชั่วคราว แล้วสุดท้ายก็ปิดงาน implementation ผ่านการคุยกับ Claude Code แบบที่ทำกันตามปกติ พอใช้ context หมดแล้วทำ compaction หรือเริ่ม session ใหม่ ก็จะลืมการมีอยู่ของเอกสารที่ Spec Kit สร้างไว้ พอทำงานตามที่กำหนดไว้ใน tasks.md ไปเรื่อย ๆ บางทีก็เขียนทับสิ่งที่ก่อนหน้านี้ทำไว้ดีแล้ว และในระหว่างแก้บั๊กก็อาจสร้างฟีเจอร์ใหม่เพิ่มขึ้นมา ทำให้ค่อย ๆ ห่างจาก tasks.md มากขึ้นเรื่อย ๆ ผมเลยไม่เข้าใจว่าการเก็บ tasks.md ไว้ถาวรมีความหมายอะไร สรุปที่ผมได้ในตอนนี้มีดังนี้ ต่อให้ผลลัพธ์ที่ออกมาต่างจากที่คิดไว้ตอนแรก ก็ต้องปิดสเปกนั้นให้จบก่อน แล้วค่อยสร้างสเปกใหม่เพื่อค่อย ๆ ปรับแก้ไปทีละนิด สเปกแรกย่อมต้องใหญ่เป็นธรรมดา แต่สำหรับฟังก์ชันของแอปน่าจะไม่ต้องอธิบายเลย แล้วทำแค่ boilerplate จะดีกว่า ถ้าทำในระดับ PoC ก็น่าจะไม่ใช้ Spec Kit จะดีกว่า kandk 2025-09-22 | ความคิดเห็นหลัก | ใน: ผมเสียใจที่สร้าง Pi AI Cluster ราคา $3,000 (jeffgeerling.com) 55555555555 openman 2025-09-22 | ความคิดเห็นหลัก | ใน: การออกแบบสำหรับ AI - ฟีเจอร์ที่มองไม่เห็น (brajeshwar.com) เห็นด้วยมากครับ ต่อให้ทำได้ดีแค่ไหน ถ้ามาก้าวก่ายก็ทำให้ไม่สบายใจอยู่ดี ทางที่ดีคืออยู่แบบเหมือนไม่มีตัวตน แล้วค่อยโผล่มาช่วยเมื่อรู้สึกว่าจำเป็น แต่ประเด็นสำคัญคงอยู่ที่ว่าจะประเมินสถานการณ์ได้เหมาะสมแค่ไหน แม้แต่มนุษย์เองก็ยังมีทั้งคนที่ทำได้ดีและทำได้ไม่ดี ถ้าปัญญาประดิษฐ์ก้าวข้ามข้อจำกัดนี้ได้ ก็น่าจะเกิดการปฏิวัติขึ้นครับ โหลดความคิดเห็นเพิ่มเติม
โอ้.. ดูเข้าท่าดีนะ
นักพัฒนารุ่นจูเนียร์จะเลือก React ก็เป็นเรื่องที่หลีกเลี่ยงไม่ได้ แต่ปัญหาคือนักพัฒนารุ่นซีเนียร์กลับหยุดคิดถึงทางเลือกอื่นไปเสียแล้ว
เป็นเนื้อหาที่น่าสนใจครับ
> ปฏิเสธการดึงคนเก่งที่เหนือกว่าตัวเองเข้ามาร่วมงาน
ผมเห็นแบบนี้บ่อยมาก ไม่ใช่แค่ในหมู่ผู้ก่อตั้ง แต่รวมถึงในระดับผู้นำด้วย
จากประสบการณ์ ผมเห็นด้วยกับข้อ 3 มาก
ฟอร์แมตที่แย่ที่สุด, PDF
พอคอมเมนต์ไปแล้วก็ทำให้นึกสงสัยขึ้นมาว่า ถ้าเป็นตู้ขายของอัตโนมัติในคาเฟ่ไร้พนักงาน เขาตรวจสอบอายุผู้ซื้อกันยังไงนะ สงสัยว่าที่ตู้มีฟังก์ชันสแกนบัตรประชาชนด้วยหรือเปล่า..
ฉันเองก็ไม่สูบบุหรี่เลยไม่รู้มาก่อน แต่ไม่นานมานี้พอเห็นว่าคาเฟ่อัตโนมัติที่เพิ่งเปิดแถวบ้านมีตู้ขายบุหรี่ไฟฟ้าแบบใช้แล้วทิ้งอยู่ด้วยก็เลยได้รู้ ด้านล่างนี้คอมเมนต์ใน Hacker News ครึ่งหนึ่งก็คงเป็นเรื่องการสิ้นเปลืองทรัพยากรอย่างน่าเหลือเชื่อเหมือนกันนะ 555
ทำให้นึกถึงความทรงจำ(?) ตอนที่ทำงานอยู่บริษัทซอฟต์แวร์ระบบนำทางรถยนต์และพัฒนาโมดูลค้นหาเส้นทางในช่วงปลายยุค 2000 ขึ้นมาเลย
Dijkstra ช้าเกินไปสำหรับการค้นหาเส้นทางในระบบนำทางเลยไม่ค่อยใช้กัน แต่จะใช้การค้นหาแบบ A* (A Star) ซึ่งเป็นเวอร์ชันที่ปรับปรุงด้วยฮิวริสติกแทน พอลองค้นดูก็พบว่า A* ไม่ใช่อัลกอริทึม SSSP แต่เป็นอัลกอริทึม SPSP (Single-Pair Shortest Path) นั่นเอง
ในฐานะคนที่เคยลองทำสิ่งนี้มาก่อน ขอบอกว่าการทำให้เป็นแบบเฉพาะบุคคลจำเป็นต้องใช้ข้อมูลมาก อาจมากกว่า 2 กิกะไบต์
markitdownสะดวกสำหรับการแปลงข้ามฟอร์แมต แต่กับ PDF ไม่ควรใช้เด็ดขาดเลย จริงๆทุกวันนี้มีวิธีใช้มัลติโหมด LLM อย่าง Gemini สำหรับการดึงข้อมูลเอกสารออกมาเยอะมากแล้ว และผลบนเบนช์มาร์กก็ค่อนข้างดีทีเดียว เพียงแต่ปัญหาคือค่าใช้จ่าย
พวกอย่าง
doclingก็ดีเหมือนกันครับฟังก์ชันหรือแนวทางดูเหมือนจะคล้ายกับ Atlas นะครับ: https://atlasgo.io/
เห็นด้วยกับกับดักหลักทั้งสามข้อนี้มาก แค่มี gatekeeper คนเดียวก็ทำให้เกิดผลเสียหลายอย่างแล้วเหมือนกัน
จะเรียกว่าระดับล่างก็ไม่เชิง... ถ้าจะทำฟอร์ม แค่ใช้แท็ก
inputของ HTML ก็น่าจะพอแล้ว แต่กลับต้องไปรู้เรื่อง state, JSX, คอมโพเนนต์แบบ uncontrolled/controlled โดยไม่จำเป็น แถมยังต้องเขียนโค้ดเพิ่มอีกมาก ผมเลยคิดว่าสิ่งเหล่านั้นน่าจะเป็นแรงจูงใจของบทความต้นฉบับฉันไม่ได้สูบบุหรี่เลยนึกไม่ออกว่าเขาพูดถึงอะไร ที่แท้กำลังบอกว่าแม้จะเป็นของใช้แล้วทิ้ง แต่กลับใช้ทรัพยากรมากเกินไปนี่เอง
บารมีของคาร์ม่า -47 สุดจัดเลย 555
ฟังดูเหมือนว่าพอมีวิธีใหม่เพิ่มเข้ามาอีกวิธี ก็เลยบอกว่าวิธีเดิมตายไปแล้ว
จริง ๆ แล้วหมายความว่าไม่สามารถใช้วิธีเดิมได้อีกต่อไป และจำเป็นต้องใช้วิธีใหม่เท่านั้นจริงหรือ?
ผมเห็นด้วยกับแนวคิดนี้มาก เลยลองทดสอบกับโปรเจ็กต์ใหม่ในช่วงสุดสัปดาห์ดูบ้าง แต่ผลลัพธ์ก็ยังไม่ดีเท่าที่คิดครับ ดูเหมือนว่ายังต้องปรับปรุงอีกมาก อย่างแรก ลำดับการทำงานคร่าว ๆ ก็เป็นแบบที่มีการแนะนำกันมาหลายครั้งแล้วดังนี้:
เขียน constitution → เขียน spec → เขียน task → ลงมือ implement
ปัญหาคือ
constitution.mdเป็นไกด์หลักเกี่ยวกับ "จะพัฒนาอย่างไร" แต่ไม่ได้บรรจุว่า "สุดท้ายแล้วแอปนี้จะเป็นอะไร"spec.mdเป็นเอกสารที่อธิบายฟีเจอร์หนึ่งรายการ/specifyและ/tasaks(ซึ่งก็เป็นผลลัพธ์ที่ต้องการ) แต่เพราะอย่างนั้นก็เลยกิน context เร็วมาก (ตอนนี้ใช้ Claude Code อยู่)tasks.mdไปเรื่อย ๆ บางทีก็เขียนทับสิ่งที่ก่อนหน้านี้ทำไว้ดีแล้ว และในระหว่างแก้บั๊กก็อาจสร้างฟีเจอร์ใหม่เพิ่มขึ้นมา ทำให้ค่อย ๆ ห่างจากtasks.mdมากขึ้นเรื่อย ๆ ผมเลยไม่เข้าใจว่าการเก็บtasks.mdไว้ถาวรมีความหมายอะไรสรุปที่ผมได้ในตอนนี้มีดังนี้
55555555555
เห็นด้วยมากครับ ต่อให้ทำได้ดีแค่ไหน ถ้ามาก้าวก่ายก็ทำให้ไม่สบายใจอยู่ดี ทางที่ดีคืออยู่แบบเหมือนไม่มีตัวตน แล้วค่อยโผล่มาช่วยเมื่อรู้สึกว่าจำเป็น แต่ประเด็นสำคัญคงอยู่ที่ว่าจะประเมินสถานการณ์ได้เหมาะสมแค่ไหน แม้แต่มนุษย์เองก็ยังมีทั้งคนที่ทำได้ดีและทำได้ไม่ดี ถ้าปัญญาประดิษฐ์ก้าวข้ามข้อจำกัดนี้ได้ ก็น่าจะเกิดการปฏิวัติขึ้นครับ