ในความเห็นส่วนตัวเพิ่มเติม ผมคิดว่าการบังคับให้เปลี่ยน IDE (KIRO) เพียงเพื่อจุดประสงค์เดียวของ SDD นั้นค่อนข้างเป็นข้อเรียกร้องที่มากเกินไป

ส่วนตัวมองว่าหากอยู่ในรูปแบบของ IDE extension, แอปพลิเคชันเสริม หรือ cli ในฐานะเครื่องมือช่วย ก็น่าจะเหมาะสมกว่าหรือไม่

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

 

อ้อ จริงด้วยครับ ผมก็คิดว่าวิธีการแบบ Spec Driven ยังอยู่ในช่วงตั้งไข่ และตัวสเปกเองก็ดูเหมือนยังมีอีกหลายอย่างที่ต้องพัฒนาต่อ

การแชร์เครื่องมือและเอกสารในลักษณะนี้ ดูสำคัญมากในช่วงเวลานี้ครับ

 

เมื่อกี้เพิ่งไปดูชุดเครื่องมือ SDD ที่ชื่อ spec-kit มา แล้วก็ได้เจอ SDD ที่นี่ด้วยเหมือนกัน https://github.com/github/spec-kit

 

จีน อินโดนีเซีย สหราชอาณาจักร ออสเตรเลีย ... เป็นปัญหาที่มีอยู่ตามที่ต่าง ๆ มากกว่าที่คิดนะ

 

จริง ๆ แล้วความเข้ากันได้กับ Docker ยังไม่ค่อยดี เลยทำให้การใช้งานไม่ได้ดีขนาดนั้น...
เพราะคิดเรื่อง rootless เลยย้ายไปใช้ Podman แล้วสุดท้ายก็กลับมาใช้ Docker อีกครับ
อย่างที่ท่านอื่นบอก ถ้าจะใช้กับ Kubernetes ก็ใช้ containerd ไปเลยดีกว่า

 

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

 
aer0700 2025-09-08 | ความคิดเห็นหลัก | ใน: 996 (lucumr.pocoo.org)

ผมทำแบบ 775 อยู่เหมือนกัน... บางทีก็ 776 ด้วย 996... เอาจริง ๆ ถ้าให้เข้างาน 6 โมงผมว่าน่าจะพอไหวนะ แต่ถ้าให้เลิกงาน 3 ทุ่มนี่คงหนักเกินไปมากครับ

 
kallare 2025-09-08 | ความคิดเห็นหลัก | ใน: 996 (lucumr.pocoo.org)

ถ้าเทียบกับเกาหลีที่เคยตะโกนกันว่า จันทร์อังคารพุธพฤหัสศุกร์ศุกร์ศุกร์...
อย่างน้อยก็ยังให้หยุดได้ตั้งหนึ่งวันเลยนะ

 
codemasterkimc 2025-09-07 | ความคิดเห็นหลัก | ใน: 996 (lucumr.pocoo.org)

อยากทำงานแบบ 777 แต่เพราะกฎหมายเลยไม่มีบริษัทไหนให้ทำแบบนั้นเลย ฮือฮือ

 

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

 

ปัญหาคือ AI ทำสิ่งพวกนี้ได้ง่ายเกินไปก็จริง แต่ที่จริงแล้วสิ่งที่ทำให้เหนื่อยล้าคือฟีดแบ็กที่ขาดความใส่ใจมากกว่า AI เสียอีก

มันยังเป็นปัญหาของระบบ issue/PR แบบเปิดด้วย
เมื่อก่อนผมเคยรู้สึกสงสารอยู่บ่อย ๆ เวลามองดูเมนเทนเนอร์หลักเพียงคนเดียวที่ค่อย ๆ เหนื่อยล้าและกลายเป็นด้านมืด จาก issue และ bug report ที่ซ้ำซ้อนและขาดความใส่ใจมาโดยตลอด

 

ทุกวันนี้แม้แต่ Windows ที่ผมจ่ายเงินซื้อเอง เวลามีอัปเดตแต่ละครั้งก็ยังเหนื่อยกับการถูกชักจูงด้วย dark pattern ให้เปิดฟีเจอร์แปลก ๆ อยู่เรื่อย ๆ

 

"ว้าว คุณพูดได้ ตรงประเด็น จริง ๆ"

 

จริง ๆ แล้วทั้งอุตสาหกรรม 'AI' ก็คงให้อารมณ์แบบนี้แหละ
ไม่ใช่การขับขี่อัตโนมัติ แต่กลับอ้างว่าเป็นการขับขี่อัตโนมัติ
ไม่ใช่ความฉลาด แต่กลับอ้างว่าเป็นความฉลาด

 
ndrgrd 2025-09-07 | ความคิดเห็นหลัก | ใน: 996 (lucumr.pocoo.org)

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

อ้างอิงไว้หน่อยว่า คนงานที่สร้างพีระมิดในอียิปต์โบราณทำงานวันละ 8 ชั่วโมง

 

เท่าที่ทราบ มันน่าจะรองรับฟีเจอร์ด้านเครือข่ายได้เหมือนกับ Docker
ตอนนี้ยังมีอะไรที่ใช้งานได้ไม่สมบูรณ์อยู่ไหม?

 

ก็ Docker ไม่รองรับ network นี่นา

 

สำหรับนักพัฒนาแบบ 10x ก็อาจกระโดดขึ้นไปได้ราว 12x ด้วยความช่วยเหลือจาก AI นั่นแหละครับ