อาจจะยังไม่ได้เข้าใจอย่างถ่องแท้นัก แต่ก็รู้สึกว่าเข้าใจอารมณ์คร่าว ๆ ว่าเป็นยังไงครับ

ขอบคุณครับ

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

ตั้งแต่วินาทีที่เลือกใช้ SQLite สำหรับเซิร์ฟเวอร์โปรดักชัน ก็ต้องคอยกังวลอยู่ตลอดว่าเมื่อไรควรย้ายไปใช้ตัวอื่น
สมัยก่อน ต้นทุนของตัว DB เอง (ค่าเครื่องเซิร์ฟเวอร์, IDC, ค่าไลเซนส์ ฯลฯ) สูง จึงพอมีเหตุผลให้ต้องคิดหนัก
แต่ทุกวันนี้มันตั้งค่าใช้งานได้ง่ายแบบที่เขาเรียกกันว่าคลิกเดียว แล้วจำเป็นต้องมานั่งกังวลเรื่องนี้จริง ๆ ไหม?

บทความนี้เองก็ไม่ Agile!

เห็นด้วยครับ

แค่เรื่องการทลายการตัดสินใจแบบบนลงล่าง และการปรับปรุงซ้ำ ๆ ในรอบสั้น ๆ ก็ทิ้งสารที่มีความหมายไว้ให้เราอย่างมากแล้ว (แน่นอนว่าเทคนิค/เครื่องมือการจัดการโปรเจ็กต์ก็เช่นกัน)

บทสรุปที่ว่า 'ตัว Agile เองไม่ได้มอบมุมมองใหม่ และเหมารวมคนที่สนับสนุน Agile ทั้งหมดว่าเป็นพวกคลั่ง Agile แบบไร้เหตุผล' ดูจะรุนแรงเกินไปหน่อยครับ

คงจะดีไม่น้อยถ้า codex รองรับโทเคน oauth เหมือนกับ claude ด้วย

นั่นสิ ผมก็สงสัยว่าจะมีอินไซต์อะไรใหม่ไหม เลยไปดูต้นฉบับมาแล้วเหมือนกัน แต่นี่มันอะไรกัน...

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

ทั้งที่ขาย DB อยู่แท้ ๆ แต่ก็ยังเขียนบทความประมาณว่า 'เราเป็นคนขาย DB แต่ DB ไม่ได้จำเป็นเสมอไปนะ!' แบบไม่เคอะเขิน เลยชวนให้สงสัยว่าอยากทำการตลาดหรือเปล่า -_-... ต่อให้พยายามมองในแง่บวก บางทีก็อดจะประชดนิด ๆ ไม่ได้เหมือนกัน

อย่างน้อยก็ถือว่าได้ benchmark มาก็แล้วกัน

อ่านแล้วดีมากครับ รวมถึงเนื้อหาที่คุณเขียนไว้ในบล็อกด้วยนะครับ ไม่แน่ใจว่าอุปมานี้จะเหมาะไหม แต่ผมคิดว่านี่คล้ายกับเหตุผลที่บทเรียนแรกสุดของภาษาโปรแกรมต่าง ๆ คือ Hello World! และในอดีตเวลาศึกษาการพัฒนาเว็บ เรามักเรียนรู้ด้วยการทำเว็บบอร์ดกับร้านค้าออนไลน์ ซึ่งสุดท้ายก็ดูจะอยู่ในแนวเดียวกับที่คุณพูดไว้เหมือนกัน เมื่อก่อนผมเคยคิดแบบนั้นนะครับว่า ถ้ามีเทคนิคมากพอจะสร้างเว็บบอร์ดและร้านค้าออนไลน์ได้ ก็แทบจะสร้างเว็บส่วนใหญ่ได้แล้ว และท้ายที่สุดแล้ว การเขียนโปรแกรมก็มีเพียง Input กับ Output เท่านั้น

ผมว่าบทสรุปค่อนข้างแรงไปหน่อยนะครับ ปัญหาอาจอยู่ที่การทำให้เป็นเชิงพาณิชย์หรือทำให้เป็นแบบแผนมากเกินไป แต่ก็ไม่ได้แปลว่าเครื่องมืออย่าง sprint หรือ backlog จะหมดประโยชน์ไปเสียทีเดียว อีกทั้งมันยังช่วยให้วัฒนธรรมการประชุมที่เป็นแนวราบและมุ่งเป้าไปที่เป้าหมายตั้งหลักได้ด้วยครับ จริงอยู่ว่า SDD มีความสำคัญมากขึ้น แต่ตัวสเปกนั้นเองก็ยังสามารถเขียนร่วมกับ AI ได้อย่างรวดเร็วและร่วมมือกันอยู่ดี ดังนั้นก็ยังคงเป็น agile อยู่ครับ เพียงแค่ sprint ที่เคยยาว 2 สัปดาห์ถูกย่นเหลือไม่กี่ชั่วโมงเท่านั้น แต่แก่นแท้ของการขัดเกลาแบบวนซ้ำก็น่าจะยังเหมือนเดิมครับ

เป็นบทความที่งี่เง่านะครับ ประเด็นสำคัญคือเราต้องเขียน spec. ให้มีความ agile ตั้งแต่ตัวมันเอง... Agile คือการปรับตัวให้เข้ากับการเปลี่ยนแปลงของความต้องการจากลูกค้าอย่างรวดเร็ว

เพราะมีคนที่มีความเข้าใจผิดและจินตนาการแบบครึ่ง ๆ กลาง ๆ เกี่ยวกับ Agile แบบนี้แหละ ทั้ง Agile และวัฒนธรรมการพัฒนาถึงได้ค่อย ๆ ผิดเพี้ยนไป

นี่มันพูดบ้าอะไรเนี่ย
คิดว่าใช้ db เพราะเรื่องประสิทธิภาพเหรอ

ลิงก์ถูกใส่ผิดเป็นโดเมน com นะครับ
นี่คือลิงก์ประกาศที่เกี่ยวข้อง
[แจ้งให้ทราบ] 04/16 (พฤหัสบดี) เกิดปัญหาการเข้าถึงบริการ ▶ ดำเนินการแก้ไขแล้ว

ถึงจะอยู่ได้โดยไม่มีตู้เย็น แต่ก็คงไม่สะดวกใช่ไหมครับ
ในเมื่อใช้ตู้เย็นได้ ก็ไม่มีเหตุผลที่จะไม่ใช้มัน

จริงด้วย ไม่ใช่ Apache 2.0 นี่นา

ขอบคุณมากครับ!!

อันนี้ไลเซนส์ต่างจาก gemma4 ต้นฉบับนะ

น่ากลัวตรงที่ดูเหมือนจะเห็นบ่อยที่สุดเลย...

ว้าว ตอนที่ผมเห็นเมื่อปี 2020 ยังมีไลบรารีที่จัดการ hwp ได้ไม่มากนัก แต่ช่วงหลังมานี้เพิ่มขึ้นแบบก้าวกระโดดเลยนะครับ

นี่ดันรองรับเฉพาะ macOS อีกแล้ว.. แอบน่าเสียดายนิดหน่อย T_T มีเซิร์ฟเวอร์ว่างอยู่ตั้งหลายเครื่องแต่ทั้งหมดเป็นพื้นฐาน Linux ซะงั้น...

ในบางเกณฑ์ ทุกคนก็ล้วนเป็น Agile กันทั้งนั้นนะครับ ไม่รู้ว่าเคยมีช่วงเวลาไหนที่เราปล่อยขึ้นใช้งานได้เร็วและรับฟีดแบ็กได้เหมือนยุคนี้หรือเปล่า