tazuya 14 일 전 | ความคิดเห็นหลัก | ใน: จำเป็นต้องมีฐานข้อมูลจริงหรือ (dbpro.app) ก็จริงนะครับ ถ้าในช่วงเริ่มต้นธุรกิจยังมีผู้ใช้ไม่มาก ก็อาจมองได้ว่าเป็นแค่ข้อเสนอว่าไม่ต้องซื้อ DB หรือทำระบบให้ซับซ้อน ใช้เพียงไฟล์ I/O พื้นฐานก็อาจพาธุรกิจไปจนตั้งหลักได้แล้ว botplaysdice 14 일 전 | ความคิดเห็นหลัก | ใน: จำเป็นต้องมีฐานข้อมูลจริงหรือ (dbpro.app) อัญมณีในคำตอบก็เป็นของแถมด้วยครับ botplaysdice 14 일 전 | ความคิดเห็นหลัก | ใน: จำเป็นต้องมีฐานข้อมูลจริงหรือ (dbpro.app) ผมคิดว่านี่เป็นบทความที่ดีมาก โดยเฉพาะข้อมูลที่มี ‘ตัวเลข’ แบบนั้นยิ่งหายาก ในยุคที่หาได้ยากว่าจะได้เห็นนักพัฒนาที่อย่างน้อยก็ ‘พอมีภาพคร่าวๆ’ ว่าโค้ดที่เราสร้างและเทคสแตกที่เราหยิบมาใช้นั้นมีโอเวอร์เฮดอะไรอยู่บ้าง ผมอ่านอย่างเพลิดเพลินมาก eggplantiny 14 일 전 | ความคิดเห็นหลัก | ใน: เมื่อ AI บีบอัดความเชี่ยวชาญ สิ่งที่ท้ายที่สุดยังคงเหลือให้มนุษย์ (eggp.dev) ผมคิดว่าอุปมานี้ค่อนข้างเหมาะสมครับ โปรเจกต์ของผมเองก็โดยพื้นฐานแล้วประกอบด้วยแค่ 2 อย่างคือ Intent ของคนกับ Snapshot เท่านั้น ท้ายที่สุดแล้ว ผมคิดว่าเส้นทางที่โปรเจกต์ของผมควรมุ่งไปก็คือ จะคำนวณเจตนาของมนุษย์ (เช่น การกดแป้นพิมพ์ การคลิกเมาส์) อย่างไร และจะทำให้มันมีความหมายแบบไหน dunward 14 일 전 | ความคิดเห็นหลัก | ใน: ขอแนะนำ Claude Opus 4.7 (anthropic.com) พอเห็นว่าเปิดตัวแล้วก็ว่าจะเข้ามาเขียนโพสต์ แต่มีคนเขียนไว้แล้วสินะ สงสัยเหมือนกันว่าประสิทธิภาพจะได้ขนาดไหน darjeeling 14 일 전 | ความคิดเห็นหลัก | ใน: รายการเครื่องมือโอเพนซอร์สสำหรับจัดการ HWP/HWPX (ko.wikipedia.org) ยังมีโค้ดเดิมหลงเหลืออยู่ จึงสามารถเข้าไปตรวจสอบได้ด้วยตัวเองว่าเป็นการติดตั้งใช้งานแบบไหน https://gitlab.com/sebuls/libhwp tebica 14 일 전 | ความคิดเห็นหลัก | ใน: Current — โปรแกรมอ่าน RSS ที่ไหลไปโดยไม่ทำให้รู้สึกผิดกับบทความที่ยังไม่ได้อ่าน (terrygodier.com) แนวคิดน่าสนใจดี แต่จากประสบการณ์ที่ผ่านมา ความพยายามในอุดมคติแบบนี้ไม่ค่อยมีที่ประสบความสำเร็จนัก.. จนถึงตอนนี้น่าจะยังเป็น Feedly ที่ฟีเจอร์ AI ก็ดี และโดยรวมใช้งานได้ลงตัวที่สุดนะ qyahzn2004 14 일 전 | ความคิดเห็นหลัก | ใน: รายการเครื่องมือโอเพนซอร์สสำหรับจัดการ HWP/HWPX (ko.wikipedia.org) rip dopeflamingo 14 일 전 | ความคิดเห็นหลัก | ใน: เมื่อกล่าวคำอำลากับ Agile (lewiscampbell.tech) นี่เป็นเนื้อหาพื้นฐานที่มักปรากฏอยู่ในหนังสือเกี่ยวกับแนวทาง Agile ส่วนใหญ่ เช่น Extreme Programming ของ Kent Beck และ Scrum ของ Jeff Sutherland เป็นต้น จะดูจาก user story ก็ได้ คนส่วนใหญ่มักไม่ค่อยรู้ว่ารากฐานของ Agile คือสปรินต์ระยะสั้นและเดโมเพื่อให้ปรับตัวต่อความต้องการของลูกค้าได้อย่างรวดเร็ว develosopher 14 일 전 | ความคิดเห็นหลัก | ใน: เมื่อกล่าวคำอำลากับ Agile (lewiscampbell.tech) ผม/ฉันเข้าใจและเห็นด้วยกับความเห็นที่คุณกล่าวมา มีส่วนที่ชัดเจนว่าไม่สามารถแทนที่ด้วยโค้ดได้ ในความหมายนั้น หากจะอธิบายให้ต่างออกไปเล็กน้อย สิ่งที่ผม/ฉันอยากสื่อคือ โค้ดที่อ่านง่ายมากจะช่วยให้ไม่จำเป็นต้องสร้างเอกสารขึ้นมา เพราะเอกสารที่สะสมเพิ่มขึ้นเมื่อซอฟต์แวร์ดำเนินไปในระยะยาว ก็สร้างภาระทางการรับรู้ให้กับนักพัฒนาเช่นกัน แก่นสำคัญคือการลดงานที่ต้องสลับดูทั้งโค้ดและเอกสารไปมา ผม/ฉันคิดว่าไม่สามารถเหลือไว้แต่โค้ดเพียงอย่างเดียวได้ทั้งหมด ผม/ฉันคิดว่ามันอาจแตกต่างกันไปตามบริบทและสถานการณ์ที่เผชิญอยู่ ขอบคุณสำหรับคอมเมนต์ครับ/ค่ะ m00nlygreat 14 일 전 | ความคิดเห็นหลัก | ใน: จำเป็นต้องมีฐานข้อมูลจริงหรือ (dbpro.app) ก็แค่อ่านได้ประมาณว่าเป็นการเปลี่ยนมุมคิดเท่านั้นเอง ทุกคนไวต่อประเด็นกันจังนะ jjangdww 14 일 전 | ความคิดเห็นหลัก | ใน: SuperGemma4 - โมเดล Gemma 4 26B แบบไม่เซ็นเซอร์/เร็วขึ้น/ควอนไทซ์จาก Google (huggingface.co) ผมก็คงต้องลองดูสักครั้งเหมือนกัน ขอบคุณสำหรับข้อมูลดี ๆ ครับ snisper 14 일 전 | ความคิดเห็นหลัก | ใน: เมื่อกล่าวคำอำลากับ Agile (lewiscampbell.tech) ขอถ่ายทอดข้อโต้แย้งอย่างระมัดระวังว่า ผมมองว่าโค้ดไม่สามารถทดแทนเอกสารได้ ภาษาการเขียนโปรแกรมในตอนนี้ยังไม่มีความอุดมสมบูรณ์ของการสื่อความและพลังในการถ่ายทอดแบบภาษาธรรมชาติ และในทางปฏิบัติแล้ว โค้ดที่มีมากขนาดนั้นจะอ่านกันหมดเมื่อไรกัน? การหวังว่าจะมีโค้ดที่ทดแทนเอกสารได้เป็นทั้งความหวังและความปรารถนา แต่ก็เป็นเหมือนหอคอยบาเบลที่ไม่มีวันปีนขึ้นไปถึง ผมว่าตั้งใจทำ OOAD ให้ดีเสียยังดูดีกว่า snisper 14 일 전 | ความคิดเห็นหลัก | ใน: เมื่อกล่าวคำอำลากับ Agile (lewiscampbell.tech) การเขียน spec ให้เป็น agile เองนี่หมายความว่าอะไรกันแน่? เขียน spec แบบคร่าว ๆ เขียน spec ตามที่ลูกค้าบอกมา ถ้าความต้องการของลูกค้าเปลี่ยน ก็อาศัยพลังของเครื่องมือเพื่อดูแลรักษาให้สามารถแก้ spec ได้อย่างรวดเร็ว เขียน spec แบบ agile ประเด็นสำคัญของบทความนั้นคือ ตั้งแต่แรกก็ยังไม่เข้าใจเลยว่า agile คืออะไรกันแน่ พูดกันแต่ว่า agile มีลักษณะแบบนี้ และควรทำแบบนั้นแบบนี้ แต่กลับไม่ค่อยเห็นบทความที่ยกให้ดูชัด ๆ ว่า นี่คือผลิตภัณฑ์ที่สร้างขึ้นด้วยวิธีการแบบ agile จริง ๆ แม้แต่พอไปอ่าน manifesto ก็ยังรู้สึกคลุมเครืออยู่เลย ถ้าแสดงให้ดูสักครั้งจะเป็นอย่างไรครับ husky81 14 일 전 | ความคิดเห็นหลัก | ใน: รายการเครื่องมือโอเพนซอร์สสำหรับจัดการ HWP/HWPX (ko.wikipedia.org) BckHWP. การทำงานอัตโนมัติด้วย Excel VBA https://m.blog.naver.com/husky81/222045248589 chlrhdmltkfkd 14 일 전 | ความคิดเห็นหลัก | ใน: Gemini CLI เพิ่มฟีเจอร์ซับเอเจนต์ (developers.googleblog.com) gemini cli ขอแค่ทำงานได้ดีหน่อยก็ดีแล้ว แต่มันค้างตลอดเลย aciddust 14 일 전 | ความคิดเห็นหลัก | ใน: เมื่อกล่าวคำอำลากับ Agile (lewiscampbell.tech) ช่วงนี้ผมเห็นกรณีแบบนี้บ่อยขึ้น onetoday 14 일 전 | ความคิดเห็นหลัก | ใน: เมื่อ AI บีบอัดความเชี่ยวชาญ สิ่งที่ท้ายที่สุดยังคงเหลือให้มนุษย์ (eggp.dev) อาจจะยังไม่ได้เข้าใจอย่างถ่องแท้นัก แต่ก็รู้สึกว่าเข้าใจอารมณ์คร่าว ๆ ว่าเป็นยังไงครับ ขอบคุณครับ savvykang 14 일 전 | ความคิดเห็นหลัก | ใน: เมื่อกล่าวคำอำลากับ Agile (lewiscampbell.tech) ผมไม่เข้าใจว่าทำไมถึงยกย่องวิธีวิทยาเหล่านี้ราวกับเป็นคัมภีร์ ผู้เขียนต้นฉบับเองก็แค่มีแนวทางต่างออกไป แต่ผมคิดว่าในแง่ความยึดติดแบบหลักการตายตัวก็ไม่ได้ต่างกัน cafedead 14 일 전 | ความคิดเห็นหลัก | ใน: จำเป็นต้องมีฐานข้อมูลจริงหรือ (dbpro.app) ตั้งแต่วินาทีที่เลือกใช้ SQLite สำหรับเซิร์ฟเวอร์โปรดักชัน ก็ต้องคอยกังวลอยู่ตลอดว่าเมื่อไรควรย้ายไปใช้ตัวอื่น สมัยก่อน ต้นทุนของตัว DB เอง (ค่าเครื่องเซิร์ฟเวอร์, IDC, ค่าไลเซนส์ ฯลฯ) สูง จึงพอมีเหตุผลให้ต้องคิดหนัก แต่ทุกวันนี้มันตั้งค่าใช้งานได้ง่ายแบบที่เขาเรียกกันว่าคลิกเดียว แล้วจำเป็นต้องมานั่งกังวลเรื่องนี้จริง ๆ ไหม? โหลดความคิดเห็นเพิ่มเติม
ก็จริงนะครับ ถ้าในช่วงเริ่มต้นธุรกิจยังมีผู้ใช้ไม่มาก ก็อาจมองได้ว่าเป็นแค่ข้อเสนอว่าไม่ต้องซื้อ DB หรือทำระบบให้ซับซ้อน ใช้เพียงไฟล์ I/O พื้นฐานก็อาจพาธุรกิจไปจนตั้งหลักได้แล้ว
อัญมณีในคำตอบก็เป็นของแถมด้วยครับ
ผมคิดว่านี่เป็นบทความที่ดีมาก โดยเฉพาะข้อมูลที่มี ‘ตัวเลข’ แบบนั้นยิ่งหายาก ในยุคที่หาได้ยากว่าจะได้เห็นนักพัฒนาที่อย่างน้อยก็ ‘พอมีภาพคร่าวๆ’ ว่าโค้ดที่เราสร้างและเทคสแตกที่เราหยิบมาใช้นั้นมีโอเวอร์เฮดอะไรอยู่บ้าง ผมอ่านอย่างเพลิดเพลินมาก
ผมคิดว่าอุปมานี้ค่อนข้างเหมาะสมครับ โปรเจกต์ของผมเองก็โดยพื้นฐานแล้วประกอบด้วยแค่ 2 อย่างคือ Intent ของคนกับ Snapshot เท่านั้น
ท้ายที่สุดแล้ว ผมคิดว่าเส้นทางที่โปรเจกต์ของผมควรมุ่งไปก็คือ จะคำนวณเจตนาของมนุษย์ (เช่น การกดแป้นพิมพ์ การคลิกเมาส์) อย่างไร และจะทำให้มันมีความหมายแบบไหน
พอเห็นว่าเปิดตัวแล้วก็ว่าจะเข้ามาเขียนโพสต์ แต่มีคนเขียนไว้แล้วสินะ
สงสัยเหมือนกันว่าประสิทธิภาพจะได้ขนาดไหน
ยังมีโค้ดเดิมหลงเหลืออยู่ จึงสามารถเข้าไปตรวจสอบได้ด้วยตัวเองว่าเป็นการติดตั้งใช้งานแบบไหน
https://gitlab.com/sebuls/libhwp
แนวคิดน่าสนใจดี แต่จากประสบการณ์ที่ผ่านมา ความพยายามในอุดมคติแบบนี้ไม่ค่อยมีที่ประสบความสำเร็จนัก..
จนถึงตอนนี้น่าจะยังเป็น Feedly ที่ฟีเจอร์ AI ก็ดี และโดยรวมใช้งานได้ลงตัวที่สุดนะ
rip
นี่เป็นเนื้อหาพื้นฐานที่มักปรากฏอยู่ในหนังสือเกี่ยวกับแนวทาง Agile ส่วนใหญ่ เช่น Extreme Programming ของ Kent Beck และ Scrum ของ Jeff Sutherland เป็นต้น จะดูจาก user story ก็ได้ คนส่วนใหญ่มักไม่ค่อยรู้ว่ารากฐานของ Agile คือสปรินต์ระยะสั้นและเดโมเพื่อให้ปรับตัวต่อความต้องการของลูกค้าได้อย่างรวดเร็ว
ผม/ฉันเข้าใจและเห็นด้วยกับความเห็นที่คุณกล่าวมา
มีส่วนที่ชัดเจนว่าไม่สามารถแทนที่ด้วยโค้ดได้
ในความหมายนั้น หากจะอธิบายให้ต่างออกไปเล็กน้อย สิ่งที่ผม/ฉันอยากสื่อคือ โค้ดที่อ่านง่ายมากจะช่วยให้ไม่จำเป็นต้องสร้างเอกสารขึ้นมา
เพราะเอกสารที่สะสมเพิ่มขึ้นเมื่อซอฟต์แวร์ดำเนินไปในระยะยาว ก็สร้างภาระทางการรับรู้ให้กับนักพัฒนาเช่นกัน แก่นสำคัญคือการลดงานที่ต้องสลับดูทั้งโค้ดและเอกสารไปมา
ผม/ฉันคิดว่าไม่สามารถเหลือไว้แต่โค้ดเพียงอย่างเดียวได้ทั้งหมด
ผม/ฉันคิดว่ามันอาจแตกต่างกันไปตามบริบทและสถานการณ์ที่เผชิญอยู่
ขอบคุณสำหรับคอมเมนต์ครับ/ค่ะ
ก็แค่อ่านได้ประมาณว่าเป็นการเปลี่ยนมุมคิดเท่านั้นเอง ทุกคนไวต่อประเด็นกันจังนะ
ผมก็คงต้องลองดูสักครั้งเหมือนกัน
ขอบคุณสำหรับข้อมูลดี ๆ ครับ
ขอถ่ายทอดข้อโต้แย้งอย่างระมัดระวังว่า ผมมองว่าโค้ดไม่สามารถทดแทนเอกสารได้ ภาษาการเขียนโปรแกรมในตอนนี้ยังไม่มีความอุดมสมบูรณ์ของการสื่อความและพลังในการถ่ายทอดแบบภาษาธรรมชาติ และในทางปฏิบัติแล้ว โค้ดที่มีมากขนาดนั้นจะอ่านกันหมดเมื่อไรกัน?
การหวังว่าจะมีโค้ดที่ทดแทนเอกสารได้เป็นทั้งความหวังและความปรารถนา แต่ก็เป็นเหมือนหอคอยบาเบลที่ไม่มีวันปีนขึ้นไปถึง
ผมว่าตั้งใจทำ OOAD ให้ดีเสียยังดูดีกว่า
การเขียน spec ให้เป็น agile เองนี่หมายความว่าอะไรกันแน่?
ประเด็นสำคัญของบทความนั้นคือ ตั้งแต่แรกก็ยังไม่เข้าใจเลยว่า agile คืออะไรกันแน่ พูดกันแต่ว่า agile มีลักษณะแบบนี้ และควรทำแบบนั้นแบบนี้ แต่กลับไม่ค่อยเห็นบทความที่ยกให้ดูชัด ๆ ว่า นี่คือผลิตภัณฑ์ที่สร้างขึ้นด้วยวิธีการแบบ agile จริง ๆ แม้แต่พอไปอ่าน manifesto ก็ยังรู้สึกคลุมเครืออยู่เลย ถ้าแสดงให้ดูสักครั้งจะเป็นอย่างไรครับ
BckHWP. การทำงานอัตโนมัติด้วย Excel VBA
https://m.blog.naver.com/husky81/222045248589
gemini cli ขอแค่ทำงานได้ดีหน่อยก็ดีแล้ว แต่มันค้างตลอดเลย
ช่วงนี้ผมเห็นกรณีแบบนี้บ่อยขึ้น
อาจจะยังไม่ได้เข้าใจอย่างถ่องแท้นัก แต่ก็รู้สึกว่าเข้าใจอารมณ์คร่าว ๆ ว่าเป็นยังไงครับ
ขอบคุณครับ
ผมไม่เข้าใจว่าทำไมถึงยกย่องวิธีวิทยาเหล่านี้ราวกับเป็นคัมภีร์ ผู้เขียนต้นฉบับเองก็แค่มีแนวทางต่างออกไป แต่ผมคิดว่าในแง่ความยึดติดแบบหลักการตายตัวก็ไม่ได้ต่างกัน
ตั้งแต่วินาทีที่เลือกใช้ SQLite สำหรับเซิร์ฟเวอร์โปรดักชัน ก็ต้องคอยกังวลอยู่ตลอดว่าเมื่อไรควรย้ายไปใช้ตัวอื่น
สมัยก่อน ต้นทุนของตัว DB เอง (ค่าเครื่องเซิร์ฟเวอร์, IDC, ค่าไลเซนส์ ฯลฯ) สูง จึงพอมีเหตุผลให้ต้องคิดหนัก
แต่ทุกวันนี้มันตั้งค่าใช้งานได้ง่ายแบบที่เขาเรียกกันว่าคลิกเดียว แล้วจำเป็นต้องมานั่งกังวลเรื่องนี้จริง ๆ ไหม?